Les apps Android : merci, au revoir

Après 3 ans de développement Android, il me semble bon d’en arrêter là.

Morin Innovation ne concevra plus aucune autre application Android que celle où elle est engagée (que mes clients actuels se rassurent, le job sera fait).

Les raisons de cette décision

Cette décision n’a pas été prise à la légère. Elle est le fruit de plusieurs mois de réflexion.

Un niveau qualitatif insuffisant

Bien que le travail des ingénieurs Google soit tout à fait honorable, la plateforme Android ne répond pas à autant de critère de qualité que ses concurrents.

La conséquence immédiate de cette légèreté : les utilisateurs sont moins bien servis, et les clients sont déçus lorsqu’ils comparent avec les autres plateformes.

Malgré une tentative louable, Android n’atteint absolument pas le niveau requis. A quelque niveau que ce soit.

Les outils ne sont pas terribles : on a toujours l’impression d’avoir une version « beta », ce qui nuit à la productivité.

Le kit de développement est correct dans le sens où il est complet. Pour le reste, c’est basique, mais acceptable.

L’ergonomie est très moyenne.

D’autant qu’il faut composer avec les anciennes versions Android, ce qui ne garantit pas une cohérence optimale. Ça fait des lustres qu’on nous promet des améliorations : rien ne vient. On doit être compatible avec des OS datant de 2012 (4 ans!). Autant dire, une éternité dans le monde mobile.

Bref : la qualité est moyenne et en plus ça prend plus de temps, donc ça coûte plus cher pour tout le monde.

La cerise sur le gâteau : la sécurité

Après une étude approfondie d’un problème qui est d’actualité, il s’avère que la sécurité Android est au niveau minimum. Même sur les versions récentes du système (et celles en développement aussi d’ailleurs).

Je ne souhaite pas que les informations concernant les utilisateurs de mes apps soient divulguées ou du moins facilement accessible. Je me suis fait entendre dire plus d’une fois : « Oui, mais on s’en fout de la sécurité des données des utilisateurs. Qui s’en préoccupe ? ». C’est pour moi un manque de respect. On se doit d’offrir le meilleur.

Je souhaite également éviter la propagation des informations sensibles concernant les développements réalisés pour mes clients. Je protège tous mes appareils (chiffrage de disque, etc) et les codes sources que je partage avec mes clients sont stockés sur des plateformes sécurisées, dont l’accès nécessite une sécurité à facteurs multiples (envoi d’un code par SMS pour accéder aux données protégées, certificats SSL pour accéder au code source, identification par signature GPG des développeurs, etc).

De la même manière, je fais en sorte de ne stocker aucun identifiant dans mes codes sources, de sorte à ne pas donner le moindre indice à un potentiel hacker.

Et je met également en application, dans la mesure du possible, l’intégralité des recommandations OWASP disponibles.

Ceci est possible sur iOS, au sein de Ruby on Rails, mais pas vraiment sur Android dont la plateforme ne correspond plus aux critères de sécurité actuels. Pour ceux qui en doutent, je rappelle à leur bon souvenir le temps qu’il a fallu au FBI pour accéder à un appareil Apple moyennement protégé alors que la sécurité Android saute en quelques heures tout au plus.

De plus, en quelques heures (2 minutes devant l’ordi qui va fonctionner tout seul pendant quelques heures), on peut récupérer une version du code source allant de lisible à difficilement compréhensible. Mais il est extrêmement compliqué et coûteux de réellement bien protégé une app Android. A contrario, une app iOS ou Windows est sécurisée par défaut. Le code source n’est pas accessible. Et, de surcroit, il est possible de ne pas y intégrer d’informations sensibles.

À l’instar de la qualité d’usage, qui est peut être subjective, la qualité en matière de sécurité est un critère on ne peut plus factuel. Et cette réalité va en grandissant au fur et à mesure que le temps passe.

Je ne prendrai pas cette responsabilité.

Les alternatives

Les alternatives pour les clients et les utilisateurs sont les suivantes.

Pour les clients

Honnêtement, il y a beaucoup de faux dans les téléchargements et exécutions d’apps Android. J’ai moi-même vu des statistiques Analytics avec des applications étant téléchargées et non lancées. Ou des applications étant lancées une fraction de seconde. Ce n’est pas un comportement d’utilisateur « normal » et encore moins un comportement « rentable ».

Autant disposer d’applications natives de très bonne qualité et un très bon compromis pour la version web. Le HTML5 fait aujourd’hui de très bonnes choses dans un cadre relativement sécurisé. Certes, cela ne permet pas forcément de disposer de toutes les possibilités du natif, mais cela reste mieux qu’une app de qualité moyenne.

Si vous souhaitez vraiment avoir une app Android, je vous recommande donc de consulter un développeur Android avec un niveau senior et de très solides compétences dans le domaine de la sécurité. Pour vous et pour vos utilisateurs.

Pour les utilisateurs

Vous avez un Android et entendez des promesses d’amélioration depuis des années ? C’est normal : la publicité et le marketing, c’est le domaine de Google.

Quand vous téléchargez une app, assurez-vous qu’elle est très bien protégée (Comment ? Je l’ignore) et utilisez l’authentification à multiples facteurs quand c’est possible.

Sinon, si vous avez un budget à partir de 500 € en appareil nu (sans abonnement), l’iPhone SE est une petite bombe. Vous pouvez avoir des iPhone chez Free Mobile pour moins de 20 € par mois. Et chez Orange, avec un abonnement, on peut avoir un iPhone à partir de 1 €. Un iPhone SE sera au top pendant environ 3-4 ans.

Les Windows Phone récents (surtout Windows 10) tiennent bien la route aussi en matière de sécurité.

Si vous êtes sur Android, de manière générale, préférez les applications web aux applications natives : elles ont plus de chances d’être sécurisées.

Et l’avenir ?

L’avenir s’annonce radieux. 🙂

Morin Innovation va se focaliser sur un développement web (sites + services web) de bonne qualité grâce à Ruby on Rails.

Le tout fonctionnant en parfaite harmonie avec des applications Apple (iOS, tvOS, watchOS, macOS OS X) répondant aux mêmes critères de qualité et de sécurité.

Je continuerai de faire de la veille sur Android, notamment pour assurer un niveau de sécurité adéquat vis à vis des services web que je mettrai en place. Mais c’est tout.

L’expérience Android se termine ici.

Merci Google et au revoir.

De la légèreté des apps iOS

Depuis bientôt 8 ans d’existence, les apps iOS ont connu de nombreuses évolutions. Les amenant à prendre de l’embonpoint.

Depuis l’arrivée de iOS 9 en 2015, ces dernières ont subi quelques allègements. Il existe également quelques astuces permettant d’alléger le tout. Vous pouvez obtenir une réduction de poids d’environ 20 à 40 % en utilisant ces méthodes.

Les causes d’embonpoint d’une app

Une app ne grossit pas par la force des choses. Plusieurs sources sont en cause.

La compatibilité Retina

Il existe 3 types d’écrans pour les apps iOS :

  • classique (1 pixel d’image = 1 pixel à l’écran)
  • Retina (2 pixels d’image = 1 pixel à l’écran)
  • RetinaHD (3 pixels d’image = 1 pixel à l’écran)

Le principe est vulgarisé, mais si on souhaite profiter de manière optimale de la qualité de l’écran, une image de 300×300 en mémoire représentera un carré de 150×150 en Retina et 100×100 en RetinaHD.

Et, bien sûr, il faut obligatoirement les 3 types d’images, car sinon on subit une augmentation de l’utilisation de la mémoire.

Qui dit 3 types d’images dit 3 fichiers dans l’application pour un même contenu : ça fait mal !

La compatibilité avec les différentes architectures

Que l’ont ait un processeur ARM classique ou un processeur « Apple », une architecture 32 ou 64 bits, avec tel ou tel GPU, le constat est le même d’année en année : les applications grossissent pour être compatibles avec un maximum d’appareils.

Les applications universelles

Beaucoup d’applications sont compatibles iPhone et iPad. Ce qui amène un nouveau problème : les 3 variantes d’images sont bien souvent dupliquées. Ce qui amène à 6 variantes, avec des fichiers souvent plus lourds.

Les ressources annexes

Si on souhaite développer un jeu, on souhaitera permettre le déblocage de nouveaux niveaux, nouvelles armures.

Si on développe une application bien-être, on intègrera des exercices à débloquer. Qui sont souvent sous forme de vidéos.

Si on développe un GPS, il s’agira des cartes.

Ça grossit encore…

Les solutions

Evidemment, tout problème a sa solution si on se creuse un peu la tête.

Limiter l’usage des images

La solution la plus simple pour intégrer un visuel est d’utiliser une image PNG. Ça se fait en 2 minutes.

Pourtant, les graphistes et autres designers proposent souvent aux développeurs des fichiers vectoriels qui sont – par définition – compatible avec toutes les dimensions d’écrans et toutes les qualités d’écran.

Certains outils permettent de transformer les contenus issus d’Illustrator ou les fichiers SVG en code Swift ou Objective-C directement exploitable par une application iOS.

Parmi ceux-ci, il y a notamment le fameux PaintCode qui fait un travail remarquable.

La qualité des visuels de votre application sera meilleure et le poids sera également allégé de manière importante. Quand c’est possible, mieux vaut utiliser ces procédés.

Optimisez les images

Par défaut, XCode optimise les images PNG utilisées comme assets de sorte à réduire leur poids.

Pour autant, rien ne vous empêche d’utiliser des outils complémentaires en amont. Cela ne peut pas faire de mal.

Et surtout, veillez à vous assurer que les images ont bien une définition de 72dpi. Une définition supérieure n’apportera rien. Si ce n’est du poids supplémentaire.

Utilisez des images redimensionnables

Depuis iOS 7, XCode permet d’exploiter les images redimensionnables. Vous limitez ainsi le poids de l’image en définissant des zones « étirables ».

Inutile d’entrer dans le détail, la documentation officielle parle d’elle-même.

L’app slicing de iOS 9

Depuis iOS 9, les applications sont « découpées » sur l’App Store de sorte à ne télécharger que le contenu adapté à l’appareil. La cure d’allègement est drastique.

Les appareils sous iOS 8 devront eux télécharger tout le contenu.

Le bitcode

Pour faire simple, le bitcode est un code universel. Il s’agit du code exécuté par votre app. La partie optimisée du code est générée par l’App Store.

En gros, une app sur un iPhone 64bits ne contiendra ni les instructions 32bits, ni les spécificités de l’iPad.

Et, cerise sur le gâteau, si une nouvelle architecture matérielle fait son apparition il n’y aura pas besoin d’envoyer une nouvelle version de l’app sur l’App Store : Apple se charge d’optimiser le tout.

Les ressources à la demande

Un autre procédé introduit récemment par Apple est le principe des ressources à la demande.

Plutôt que tout télécharger d’un bloc, les ressources supplémentaires sont téléchargées à la demande par l’app. Et tout le processus est simplifié pour les développeurs.

Pour conclure

S’il est possible de voir le poids de son app exploser facilement, il y a tout de même des solutions permettant de réduire son poids.

Aujourd’hui, une application « light » peut peser entre 10 et 20 Mo. (Periscope est à 17 Mo, Tinder est à 20 Mo, Avertinoo seulement 4,9 Mo !)

Avec l’arrivée de iOS 10, il y a de bonnes chances pour que les apps soient optimisées dès cet été pour iOS 9 au minimum, iOS 8 étant de moins en moins présent. Ce qui signifie que les téléchargements d’apps devraient être plus rapides. Et les apps plus performantes, car automatiquement optimisées.

Le tout est que chacun joue le jeu pour offrir le meilleur aux utilisateurs iOS.

Ruby : le développement agile

Chez Morin Innovation, société orienté « startup », nous travaillons à 100 % en mode agile. L’enjeu est de pouvoir être réactif tout en sécurisant le travail. Un bon équilibre en qualité et productivité.

Pour cela, nous nous appuyons sur Ruby, un langage orienté agilité de par sa conception.

Idée reçue n°1 : tout projet peut être mené quel que soit le langage utilisé

Cette idée, souvent répandue par les chefs de projets qui n’ont pas forcément de connaissances techniques, est théoriquement vraie. Mais théoriquement seulement.

Je peux théoriquement construire une maison en bois avec beaucoup d’allumettes. La maison sera théoriquement aussi solide. Mais il sera plus rapide et plus adapté d’utilisé le matériau adéquate.

Pour le développement, c’est pareil. C’est dans cet esprit qu’a été conçu Ruby dès ses origines : pour le développement agile.

Le langage et son environnement permettent de réaliser très rapidement des développements robustes. Dans la limite de ce que permettent les langages de script.

Idée reçue n°2 : les performances du langage déterminent les performances de l’application

Ne confondons pas performances et efficacité. Si l’interpréteur Ruby n’est pas le meilleur (ni le pire) en termes de performances, il permet un développement rapide. Et son environnement lui permet d’être optimal en termes d’efficacité.

Rien ne sert de courir, il faut partir à point.

Ruby propose une syntaxe optimale et minimaliste pour le développement. La relecture en est donc simplifiée. La correction de bugs est plus rapide. L’optimisation est également plus facile car plus simple à appréhender.

Également, le gain de temps obtenu sur la réalisation permet, si nécessaire, de passer du temps sur l’optimisation.

De plus, Ruby possède un système de packages (des composants à installer) qui fournissent du code open-source très simple à intégré et déjà optimisé.

Car, s’il y a une force dans Ruby, c’est également son système de plugins natifs, qui permet d’appeler du code natif (performant) depuis le langage Ruby. Idéal pour les portions de code critique (analyse de contenu XML/HTML, génération d’images, etc).

Enfin, le code Ruby peut être exécuté au travers d’une machine virtuelle Java (JVM) grâce à JRuby, ce qui apporte un gain de performances conséquent tout en profitant de l’efficacité de l’outil.

Ruby en environnement agile

Passées ces idées reçues, venons-en aux faits. En quoi Ruby est-il meilleur qu’un autre en environnement agile (SCRUM ou autres) ?

Développement souple et rapide

Comme évoqué, la syntaxe même de Ruby lui permet de faciliter le travail du développeur, que ce soit seul ou en équipe.

Un petit bout de code « pour tester » peut être très rapidement déployé. En quelques minutes, on peut avoir un outil d’extraction de données ou de quoi tester un service web.

Adapté aux tests unitaires

Que ce soit via ses modules de tests intégrés (Test::Unit) ou via des outils externes plus élaborés (RSpec), les tests unitaires sont une partie intégrante de l’environnement de développement Ruby.

Au delà de l’apport évident en termes de sécurité et de fiabilité du code, c’est un atout majeur pour le travail en équipe et le développement par les tests (Test Driven Development) qui est un des socles du développement agile.

Bien entendu, de nombreux outils permettent une intégration continue optimale et naturelle, ce qui est également un atout des méthodes de travail agiles.

Idéal pour le travail en équipe

Le code étant basé sur le script, son intégration dans les dépôts de code source (Git et autres) est totalement adapté.

Egalement, son système de packages (les gems) et la configuration des dépendances via le fameux Gemfile permettent d’installer rapidement l’environnement de développement adapté au projet.

Egalement, les gems pouvant être privés et stockés sur Git, le partage de code entre les projets est totalement optimisé.

Un atout majeur pour rejoindre les équipes. Que l’on travaille sur un même réseau ou à distance. Et dans un environnement de travail hétérogène.

Ruby on Rails : le développement web agile

Ruby on Rails est un framework web conçu en Ruby.

Son avantage est sa structure, copiée par de nombreux autres projets dans d’autres langages (Symfony, Play! et autres) : mais la copie ne vaut jamais l’original. Cette structure permet non seulement de s’y retrouver dans son propre code, mais permet également de facilement intégrer des développeurs sur un projet. Et, par extension, faciliter la reprise du code.

Ruby on Rails intègre évidemment les tests unitaires, un impératif pour l’intégration continue (via Codeship par exemple).

Le tout en profitant des atouts de Ruby. Et d’une logique orienté efficacité plus que performances.

La souplesse de l’outil permet un déploiement en environnement « scalable » très simple. Notamment grâce à des solutions comme Heroku, qui proposent un hébergement sans ce soucier de l’aspect administration réseau (tout se fait au travers d’un simple dépôt Git sécurisé).

La sécurité est au rendez-vous, avec un respect scrupuleux des recommandations OWASP.

Les performances « effectives » sont également au RDV, grâce – notamment – à des mécanismes de mise en cache simplifiés.

Success Stories

Travaillant en marque blanche (invisible pour le client final), je ne peux présenter les success stories de Morin Innovation. Je peux juste dire que Ruby nous permet de tenir nos délais de manière systématique (sauf rares exceptions indépendantes de l’équipe), tout en ayant une réactivité maximale sur la correction de bugs et avec des performances très honorables. (on a pu monter jusqu’à 1000 utilisateurs simultanés sur un projet web sans blocage ni lenteur)

Plusieurs sociétés se sont développées grâce à Ruby, et plus particulièrement Ruby on Rails :

  • Twitter
  • Shopify
  • LinkedIn
  • GitHub
  • Basecamp
  • Drivy
  • Airbnb
  • et bien d’autres.

Quid des autres solutions ?

D’autres solutions se développent, bien souvent en « copiant » le modèle de Ruby on Rails, mais dans d’autres langages.

NodeJS, par exemple, est à la mode. On entend souvent des responsables de projets informatiques en faire la promo en amont, dire ensuite que c’est génial… mais ne jamais le déployer à grande échelle. CQFD 🙂

En PHP, Symfony s’approche de Ruby on Rails. En Java (Scala), c’est Play qui reprend le même modèle.

Mais bon, la syntaxe joue beaucoup. Le langage Python, et son framework web Django, est probablement un des seuls à être du niveau de Ruby en termes d’efficacité.

L’évolution en environnement Java

Bien souvent, de nombreuses structures se sont orientées vers Java. Et elles souhaitent ensuite évoluer vers des solutions plus agiles.

L’avantages de Ruby est qu’il possède son environnement d’exécution Java : JRuby.

Non seulement JRuby peut s’exécuter dans un environnement Java, mais en plus on peut appeler du code Java depuis JRuby et vice versa.

Et maintenant ?

Je vous ai présenté l’environnement de développement Ruby.

Si vous souhaitez en savoir plus, n’hésitez pas à contacter Morin Innovation.

La cité niortaise devient la cité des startups et de l’innovation. Ce sera un plaisir pour nous de contribuer à l’accélération de vos développements.