Le développeur qui a créé seul un éditeur de texte Apple pendant 9 ans

9 ans en solo sur l’éditeur de texte "Paper"

• En 2015, il était un développeur web full stack classique, assez éloigné de l’univers du développement Apple.
• En utilisant un Mac, il a découvert l’attrait des apps de développeurs indépendants et, inspiré par iA Writer, un éditeur Markdown simple et élégant, il a décidé de créer une app similaire.
• Pour développer un éditeur de texte natif pour Mac, il a commencé à apprendre une nouvelle stack technique : Xcode, AppKit, Objective-C, etc.
• Il a choisi le nom Paper pour l’app et, en poursuivant un minimalisme extrême, a conçu l’éditeur comme un simple rectangle.
• En 2017, il a lancé l’app Mac sur le Mac App Store, puis une app iOS en 2019.

Pourquoi avoir choisi une app native

• Il a choisi une app native plutôt qu’une app Electron parce que son objectif était d’offrir la meilleure expérience utilisateur possible.
• Les apps natives sont légères et rapides, et offrent davantage de possibilités pour implémenter des fonctionnalités spécifiques au texte.

Pourquoi avoir choisi Objective-C

• En 2015, alors que Swift n’en était qu’à ses débuts, il a compilé un projet Xcode vide en Objective-C et en Swift afin de comparer les paquets .app.
• L’app Swift incluait le runtime Swift et pesait environ 5 Mo, tandis que l’app Objective-C était extrêmement légère, autour de 100 Ko.
• Il a donc choisi Objective-C parce qu’il voulait une app distribuable plus légère.

Dépendances tierces

• Paper n’a aucune dépendance tierce.
• Il a tout construit lui-même, ce qui lui donne un léger avantage sur ses concurrents.
• Par exemple, le moteur de parsing Markdown de Paper est personnalisé et prend en charge moins de syntaxe Markdown qu’un éditeur Markdown traditionnel.

Vision

• La vision initiale de Paper était de reprendre les fonctionnalités essentielles de iA Writer, mais dans un ensemble plus élégant et plus minimaliste.
• L’accent a été mis sur la réduction maximale des éléments distrayants afin d’améliorer la concentration de l’utilisateur.
• Avec le temps, Paper a trouvé sa place sur le marché en conservant son minimalisme tout en ajoutant progressivement des fonctionnalités.

Architecture

• Le code de Paper est structuré en deux scopes : le scope application et le scope document.
• Pour chaque scope, un storyboard est défini afin de décrire les vues et les widgets et d’assembler les modules à l’intérieur du scope.
• Les modules sont des classes Objective-C responsables d’une partie des fonctionnalités de l’app, regroupant la logique liée à une fonction précise en un seul endroit.

Code cross-platform

• AppKit et UIKit se ressemblent, tout en étant très différents sur de nombreux points.
• Pour gérer ces différences, il a utilisé les macros et les catégories d’Objective-C.

Débogage

• Avec les frameworks Apple, il faut lire la documentation plutôt que le code, et analyser les stack traces compilées à l’aide de breakpoints.

Fonctionnalités payantes

• Entre 2015 et 2017, les abonnements n’étaient pas encore largement répandus et les paiements uniques étaient la norme sur les app stores.
• Souhaitant proposer des fonctionnalités payantes d’une manière respectueuse des utilisateurs, il a limité le payant à des améliorations non fonctionnelles, mais cosmétiques.

Tarification

• Au départ, il a commencé avec deux ensembles de fonctionnalités Pro, chacun vendu 5 dollars en achat unique.
• Aujourd’hui, il propose un ensemble unique au prix de 10 dollars par mois ou 100 dollars à vie.
• Des expérimentations tarifaires lui ont montré que les utilisateurs étaient prêts à payer jusqu’à 100 dollars pour l’app d’un développeur encore peu connu.

Les parties délicates

• Les éditeurs de texte sont complexes, et chaque mise à jour de l’OS ajoute de nouvelles façons d’insérer, de mettre à jour et d’interagir avec le texte.

Gimmicks

• Il a ajouté des fonctionnalités plaisantes, comme le rebond au redimensionnement de fenêtre inspiré par l’app Things.

L’avis de GN⁺ :

1. Une approche innovante : il est impressionnant de voir qu’il a développé Paper en plaçant l’expérience utilisateur au premier plan, malgré son absence d’expérience préalable dans le développement d’apps natives. Cela montre à quel point une conception centrée sur l’utilisateur est importante en développement logiciel.
2. Apprentissage et progression : le processus consistant à apprendre une nouvelle stack technique puis à construire un produit avec celle-ci peut aussi inspirer les ingénieurs logiciel débutants. Cela souligne combien l’apprentissage continu et le goût du défi sont essentiels pour progresser en tant que développeur.
3. L’importance de l’expérience utilisateur : l’un des facteurs de réussite de Paper est l’attention minutieuse portée à l’expérience utilisateur et sa focalisation sur le minimalisme. Cela montre combien il est important de comprendre ce que veulent réellement les utilisateurs et de le refléter dans le produit.

[woung717]

La plupart des documents de développement Apple ne sont pas très conviviaux, donc il faut vraiment bien fouiller la documentation... et quand les informations manquent, on se retrouve souvent à devoir explorer les interfaces du SDK... c’est impressionnant, dans un autre sens.

[ndrgrd]

Je me demandais ce que signifiait « mise à niveau cosmétique », mais dans le texte original c’est « visual changes ».
Le mot « cosmétique » s’emploie-t-il dans ce sens ? C’est la première fois que je le vois.

[geeker]

Comme neo est un bot d’IA, j’imagine que la traduction est devenue un peu mécanique lol

[apkas]

L’original parle d’une simple amélioration cosmétique.

[cosine20]

Dans ce cas, une simple amélioration esthétique semble plutôt préférable...

[ragingwind]

C’est un développeur qui mérite vraiment de servir de modèle.

[GN⁺]

Avis Hacker News

• « Ce sont les détails en périphérie, soignés avec minutie, qui relèvent de la magie »

  • Au début, les utilisateurs ne remarquent pas forcément les détails les plus fins d’une application, mais avec le temps ils finissent par les découvrir.
  • Ce sont ces petites fonctionnalités ajoutées avec soin qui font passer l’utilisateur du simple fait d’aimer une app à celui de l’adorer.
  • Elles donnent le sentiment que le développeur comprend ses utilisateurs et que le produit est bien entretenu.
  • L’auteur cite l’app Procreate comme exemple, en saluant une interface utilisateur (UI) épurée, tout en regorgeant de fonctionnalités cachées que l’on peut découvrir.

• « Un excellent article, nourri par 15 ans d’expérience comme développeur d’apps iOS »

  • Il explique que le choix de rester en développement natif, d’exclure les dépendances tierces et d’utiliser Objective-C était judicieux.
  • Il est ensuite passé à Swift, mais certains avantages d’Objective-C lui manquent parfois.
  • Il dit avoir téléchargé l’app pour l’essayer et avoir apprécié les petits indices présents dans la barre de menus.

• « La possibilité d’un développement avec peu ou pas de dépendances sur les plateformes Apple »

  • Grâce à la richesse et à la profondeur d’AppKit/UIKit, il est possible de créer en pratique des applications abouties sans éléments tiers.
  • Il ajoute que, même comparés à d’autres frameworks comme Qt, les frameworks d’Apple restent très compétitifs.

• « Les progrès de Swift et des spéculations sur son intégration à la plateforme ou l’optimisation binaire »

  • Depuis Swift 5, l’ABI (Application Binary Interface) est stabilisée.
  • Il précise que sa décision, prise en 2014, d’utiliser exclusivement Swift fonctionne bien.
  • Concernant SwiftUI, il estime qu’il lui reste encore beaucoup de chemin à parcourir avant de pouvoir remplacer UIKit/AppKit.

• « Une méfiance vis-à-vis du choix des dépendances et l’importance de l’apprentissage »

  • Il exprime sa réticence à ajouter des packages et bibliothèques externes avant même d’avoir commencé à écrire du code.
  • Il apprécie beaucoup la manière dont l’auteur transforme les inconvénients de l’écosystème Apple en expérience d’apprentissage positive.

• « Demande de ressources d’apprentissage et de recommandations sur AppKit et le développement Mac »

  • Il mentionne les difficultés qu’il rencontre pour trouver des informations sur le développement Mac.
  • Il explique que la documentation récente d’Apple est insuffisante et que l’ancienne documentation n’a pas été mise à jour pour Swift, au point de devoir s’en remettre à l’autocomplétion de Xcode.

• « Respect pour l’attention portée aux détails et pour l’artisanat du développement »

  • Il salue la minutie et le sens de l’artisanat de l’auteur, qualifiant le texte de beau et inspirant.

• « Une remarque amusante sur le geste consistant à tourner pour annuler »

  • Il dit que ce geste lui rappelle les scènes où le protagoniste de "Doctor Strange" remonte puis fait avancer le temps.

• « Éloges du minimalisme du blog et de l’app »

  • Il exprime le plaisir qu’il ressent en utilisant l’app qu’il a créée, et dit éprouver une sensation similaire lorsqu’il utilise vim-motions ou Neovim.

• « Étonnement face au manque d’accès au code du SDK dans l’écosystème de développement Apple »

  • Il se dit surpris par le fait de devoir regarder directement le code assembleur et demande confirmation à ce sujet.