Les conseils du créateur de NetNewsWire pour développer une app rapide

Nicolas Furno |

NetNewsWire est un client RSS pour macOS et iOS qui se distingue sur plusieurs points, mais notamment par sa rapidité. L’interface très simple et proche des standards de chaque plateforme évite au maximum les animations, ce qui donne une impression de vitesse à l’usage, mais l’app est aussi vraiment plus rapide que ses concurrentes dans toutes ses tâches. Brent Simmons, son principal développeur, explique sur son blog comment il a créé une app rapide.

N’espérez pas y trouver une solution facile, il n’y a pas de miracle : NetNewWire est une app rapide, parce que son créateur en a décidé ainsi dès le départ et parce qu’il a toujours fait très attention à ce point. Cela paraît évident, mais beaucoup de développeurs commencent par créer une app sans se soucier des performances ils ne s’intéressent à ce sujet que dans un deuxième temps.

NetNewsWire sur iPadOS.

Si vous suivez cette stratégie, votre app sera au mieux rapide qu’une partie du temps, quand vous avez le temps de vous pencher sur la question. Alors que Brent Simmons a décidé dès le départ que la performance sera au cœur de l’app, ce qui l’a obligé à prendre des décisions en respectant toujours ce critère. NetNewsWire a ainsi été rapide dès le premier jour et il devrait toujours le rester. En tout cas, tous les choix de développement sont liés à ce critère, ce qui n’est pas le cas de la majorité des apps.

L’article contient malgré tout quelques conseils pratiques utilisés pour NetNewsWire. Ils ne s’appliqueront pas forcément à votre app dans le détail, mais ils peuvent donner une idée des pistes à suivre pour placer la rapidité en tête des priorités. Par exemple, Brent Simmons a écrit son propre moteur pour lire le contenu des flux RSS, et il a utilisé pour cela une API de bas niveau, plus complexe et contraignante à mettre en place, mais qui offre des performances inégalées.

Autre exemple, NetNewsWire n’utilise pas CoreData pour stocker ses données, mais une base de données SQLite qui permet d’optimiser les requêtes ou encore d’avoir un système de cache très performant. Pour une app comme celle-ci, qui se résume en gros à extraire des informations depuis des flux RSS, les stocker dans une base de données et les afficher dans une interface, optimiser le stockage des données est un point essentiel.

L’autre point important concerne l’interface justement et Brent Simmons recommande de ne jamais utiliser les Stack Views et d’éviter d’utiliser Auto Layout dans les listes. Ces outils fournis par Apple simplifient le développement d’une app, mais ils ne sont pas aussi performants que des alternatives. C’est pourquoi les listes de flux RSS et d’articles dans NetNewsWire sont créées à la main, ce qui est plus fastidieux, mais c’est à ce prix que le défilement est aussi fluide.

Un extrait du code source de NetNewsWire affiché dans Xcode.

Les développeurs trouveront d’autres détails encore dans son article, mais on peut résumer l’esprit général en donnant deux points :

  • Penser aux performances dès le début et toujours garder cet objectif en tête ;
  • Mesurer continuellement les performances d’apps en utilisant les outils fournis par Apple et notamment Instruments, une app fournie avec Xcode qui peut servir à repérer les composants les plus lents d’une app.

NetNewsWire étant une app open-source codée en Swift, vous pouvez aussi consulter son code sur GitHub pour voir exactement comment ses développeurs ont réussi à créer une app rapide. Et si vous êtes juste un utilisateur, vous pouvez tester l’app en la téléchargeant gratuitement sur le site officiel pour les Mac ou sur l’App Store pour les iPhone et iPad.

avatar frankm | 

D’ailleurs son lecteur RSS est fantastique, sobre, et gratuit sans pub.

avatar Ded77 | 

Ne pas utiliser les stack view, ne pas utiliser Core Data…

D’ailleurs, pourquoi utiliser les UIView quand on peut utiliser directement des CALayer ?
Pourquoi utiliser UIKit quand on peut refaire son propre framework plus rapide ?
Pourquoi utiliser Swift quand on peut écrire directement du bitecode ?

L’informatique est une histoire de compromis coût / temps / performance 😊

avatar garba50 | 

@Ded77

Je plussois.

avatar Ded77 | 

D’ailleurs, pré-optimiser son code est plutôt une mauvaise pratique.

Mieux vaut écrire le plus simplement au départ puis ensuite mesurer (avec Instruments par exemple) pour corriger les « vrais » bottleneck pas ceux qu’on « pensait vrai ».

On peut ensuite mettre en place des tests unitaires de performance pour s’assurer qu’on ne va pas ralentir tel bout de l’application au fil du temps.

avatar jerome74 | 

"pré-optimiser son code est plutôt une mauvaise pratique": Heu… certainement pas! Il faut avoir en tête la question de la performance dès le début, et éviter d'utiliser des outils pas conçus pour l'usage qu'on va en faire, etc… Après c'est sûr, ça ne sert à rien de passer des semaines à optimiser un truc sans être sûr que c'est là-dedans que le programme passera le plus clair de son temps…

avatar iGeek07 | 

@Ded77

Tout à fait… et je pense que c'est aussi ce que Brent préconise, c'est juste qu'avec le temps ils ont trouvé où sont les bottlenecks dans UIKit/Appkit pour les apps qui ressemblent à un lecteur RSS, et qu'ils partagent ces trouvailles pour éviter une iterations aux autres développeurs concernés 😉

avatar Fanagame | 

@Ded77

Complètement d’accord

avatar byte_order | 

> D’ailleurs, pré-optimiser son code est plutôt une mauvaise pratique.

Le code, oui.

Le design, non.
Certains choix fait trop rapidement à cette étape peuvent coûter très très cher à corriger ensuite si les impacts de performance sont jugés non tolérables.
Cela peut passer des tests unitaires jugés suffisants alors que les utilisateurs finaux, eux, iront nettement plus loin, sans avoir conscience que l'app n'a pas (encore) été conçu avec une telle enveloppe de performance en tête.

Mais pour cela, faut-il avoir une bonne connaissance préalable de la pile techno utilisable, ses atouts et ses défauts. Et ça, ça prend du temps, soit en apprentissage sur le tas soit en recherche préalable, prototypage, etc. Comme c'est couteux, c'est difficile à justifier.

avatar garba50 | 

De toutes les façons les designers fournissent des prototypes sans se soucier du coup cpu/ram pour afficher ombres, animations et autres lubies de design.

avatar byte_order | 

on parle de graphistes dans ce cas là. Le design, c'est pas que l'aspect.

avatar tchek | 

Depuis la disparition du formidable et regretté "MacReporter" de Wilfried de Denterghern, j'utilise "baRSS" dont je suis pleinement satisfait avec Mojave et Catalina.
https://github.com/relikd/baRSS/releases

avatar AKZ | 

Sur iOS (je n’ai pas la version Mac) ils ont eu la très bonne idée de réunir toutes les images d’un article en mode zoom et on peut naviguer entre elles.
Je n’ai jamais vu une application de lecture de flux proposer cela.
Et les développeurs répondent vite au retours que j’ai pu leur faire sur des bugs ou des suggestions d’améliorations.
Je n’en dirait pas autant de la star « Reeder » qui ne sais toujours pas afficher les images en plein écran et dont le développeur ne daigne jamais répondre.

avatar fransik | 

...excellent billet de blog, merci MacG(!)

Maintenant comme j’aimerai que Mark Zuckerberg applique ces principes pour toutes les applications de Facebook...

0k, il y a probablement beaucoup d’autres applications aussi lourdes — Allô Apple Rappels/ Apple Calendrier(!?), et peut-être plus utiles , mais voilà, ce pourrait être pour moi une autre raison d’installer/ d’utiliser Facebook à nouveau.

Quoique.
Enfin, pour vous autres qui l’utilisez, ce serait certainement bien.
Allez, bonne nuit

avatar cham | 

Est-ce que iGen applique ces bonnes pratiques ?

CONNEXION UTILISATEUR