Pourquoi une seule personne crée des apps Apple natives

Il y a dans la feuille de style de la page d’accueil de ZaatarLABS un commentaire que j’aime plus que la plupart du code qui l’entoure :

/* wraps because eight icons no longer fit one row on a phone */
.loader-stage { display:flex; gap: 18px; flex-wrap: wrap; justify-content: center;
                max-width: min(600px, 88vw); }

Quand le site se charge, les icônes des apps viennent se placer en ligne l’une après l’autre pendant qu’une barre de progression se remplit. Pendant un temps, cette ligne tenait sur un écran de téléphone. Puis elle n’a plus tenu. Personne n’a signalé de bug. Je l’ai remarqué moi-même, parce que je suis le seul à regarder.

La correction tenait en une ligne, flex-wrap: wrap. Le commentaire est là pour la prochaine fois où je me demanderai pourquoi les icônes sont sur deux lignes. C’est aussi le résumé le plus honnête que j’aie de ce qu’est ce studio. C’est une seule personne, l’étagère est devenue trop grande pour une seule ligne, et cette personne revient sans cesse corriger les petites choses.

Cet article explique comment ça fonctionne, et où ça ne fonctionne pas.

Ce qu’il y a sur l’étagère

La page d’accueil le dit simplement : des apps Apple intelligentes pour les cabinets, les coachs et les entreprises. Ce sont des apps natives pour les plateformes Apple, créées par moi. Je ne les porte pas depuis une autre plateforme et je n’emballe pas une vue web dans une icône.

Je ne vais pas énumérer ici les apps et leurs fonctionnalités. Chacune a sa page pour cela. Ce que je veux expliquer, c’est le raisonnement qui me pousse à les créer de cette façon, parce qu’un seul développeur qui fait beaucoup d’apps, ça ressemble à la recette idéale pour beaucoup d’apps à moitié finies. Parfois, on n’en est pas loin.

Pourquoi du natif, alors que je suis seul

Le conseil habituel pour un développeur solo est de choisir une seule technologie multiplateforme, d’écrire le code une fois et de le publier partout. Cela fait gagner du temps, et je comprends pourquoi on le fait.

J’ai pris le chemin inverse, pour une raison bien précise. Les personnes à qui ces apps s’adressent, comme un cabinet, un coach ou une petite entreprise, vivent déjà dans les outils d’Apple. Quand une app se comporte comme le reste du système, il y a moins à apprendre et moins d’erreurs possibles. Quand ce n’est pas le cas, elles le remarquent, même si elles seraient incapables de dire ce qui cloche.

Le coût est réel. Tout ce que je crée est lié aux plateformes Apple. Quand Apple change quelque chose, je l’absorbe dans chaque app de l’étagère, une par une. Il n’y a pas d’équipe pour se partager ce travail.

Le bénéfice est réel lui aussi, et il s’accumule. Ce que j’apprends en créant une app passe directement dans la suivante, parce qu’elles sont toutes construites avec les mêmes outils. Une correction trouvée pour une app peut souvent être reportée sur les autres. C’est la seule raison pour laquelle une seule personne peut faire vivre plus d’une ou deux apps.

Où tourne l’IA

Une partie de ce travail utilise Apple Intelligence. Je veux être précis sur l’endroit où elle s’exécute, parce qu’il est facile de se tromper dans un texte marketing. Nos apps exécutent leur IA sur Private Cloud Compute d’Apple. Elles ne l’exécutent pas sur l’appareil, et je ne prétendrai pas le contraire.

C’est un choix délibéré. Utiliser l’infrastructure d’Apple signifie que je n’envoie pas vos données à un fournisseur d’IA tiers que j’aurais choisi. La contrepartie, c’est que je dépends de ce qu’Apple propose et du moment où il le propose. Si une capacité n’existe pas, je ne peux pas la contourner avec le modèle de quelqu’un d’autre tout en tenant cette promesse.

Un studio, plusieurs palettes

Voici une décision plus modeste qui m’a appris quelque chose.

Chaque app a ses propres couleurs. The Smart Budget, par exemple, a une palette bronze. Le studio lui-même, c’est-à-dire le logo, le site web et tout ce qui porte le nom ZaatarLABS plutôt que celui d’une app, est vert.

J’ai découvert à quel point les deux se mélangent facilement. Quand j’ai créé une bannière pour le studio, elle est sortie en bronze, parce que c’était la palette ouverte le plus récemment. Elle avait l’air bien, et elle était fausse. Cette bannière était pour le studio, et le studio est vert.

C’est une petite erreur, mais elle est typique de la façon dont un studio d’une seule personne déraille. Le travail ne part pas en vrille de manière spectaculaire. Il dérive, parce que ce que vous avez touché en dernier déteint sur ce que vous touchez ensuite. La solution a été d’écrire la règle : les couleurs de chaque app restent avec leur app, et tout ce qui concerne l’entreprise est vert. Je ne me fais pas confiance pour m’en souvenir un jour chargé.

La même chose est arrivée avec les icônes. Un fichier de logo qui traînait dans un dossier marketing n’était pas la vraie icône de l’app. Désormais, quand le studio a besoin de l’icône d’une app, elle vient du projet de l’app lui-même. Le dossier marketing n’est pas une source fiable.

Ce que je dirais à un autre développeur solo

Je ne pense pas que créer beaucoup d’apps seul soit une stratégie à copier telle quelle. Ce que je transmettrais est plus limité.

Choisissez la contrainte qui correspond à vos utilisateurs, pas celle qui vous fait gagner le plus de temps ce mois-ci. Pour moi, ce sont les apps Apple natives, parce que c’est là que se trouvent déjà les personnes pour qui je crée.

Écrivez les petites règles : quelle couleur appartient à qui, où se trouve la vraie icône, pourquoi la ligne passe à la ligne. Quand vous êtes le seul développeur, une règle écrite est ce qui ressemble le plus à un collègue.

Soyez précis sur ce que votre logiciel fait et ne fait pas, surtout avec l’IA. « Fonctionne sur Private Cloud Compute » et « fonctionne sur votre appareil » ne sont pas la même affirmation, et vos utilisateurs méritent la vraie.

Et regardez votre propre travail sur un téléphone de temps en temps. Personne d’autre ne vous dira que les icônes ne tiennent plus.