L'Histoire Derrière Maps Address Book

Ou : Comment l'Application la Plus Simple s'est Transformée en la Chose la Plus Difficile que Nous Ayons Jamais Construite

Chapitre 1 : Il N'est Jamais Trop Tard (pour Avoir des Ennuis)

J'avais presque 50 ans, avec une carrière épanouissante dans la production médiatique derrière moi, et un carnet rempli d'idées sur lesquelles je n'avais jamais agi. L'une de ces idées était un jeu vidéo de trading boursier, mais j'avais besoin de quelque chose de plus petit pour commencer. Quelque chose de simple. Quelque chose qu'on ne pouvait pas rater.

Dernières paroles célèbres.

Un Problème si Stupide qu'il Fallait le Résoudre

Tout a commencé avec un trajet. Même itinéraire, mêmes jours, même heure : traverser la ville pour rencontrer mon partenaire commercial, Nicolas. Ouvrir Google Maps. Taper son nom. Rien.

Bizarre.

J'essaye Apple Maps. Toujours rien.

Je l'avais dans mes contacts. J'avais marqué son endroit comme favori. J'y étais allé des dizaines de fois. Et pourtant, les deux applications se comportaient comme si elles n'avaient jamais entendu parler de cet endroit.

Il s'avère que les deux applications traitent les favoris comme des coordonnées étiquetées. Pas comme des personnes. Si vous n'étiquetez pas les choses exactement comme il faut, vous ne pouvez pas les rechercher. Mais attendez, sur l'écran des favoris, il n'y a même pas de barre de recherche.

C'est là que j'ai réalisé que nous avions besoin d'un carnet d'adresses pour les cartes. Pas un truc enfoui dans une application de contacts, mais quelque-chose conçu spécifiquement pour ça.

Et comme ça, Maps Address Book est né.

L'Utilitaire Manquant de l'App Store

Quand j'ai demandé autour de moi, il s'est avéré que tout le monde avait le même problème. Les gens faisaient des captures d'écran d'adresses, s'envoyaient des notes par texto, ou mémorisaient des noms de rues juste pour obtenir des directions vers des endroits familiers.

Nous avons vérifié l'App Store : rien de semblable à ce que nous avions en tête. Même le nom était disponible. Nous n'arrivions pas à y croire.

Le principe était d'une simplicité mortelle :

• Sauvegarder des lieux par nom
• Les rechercher instantanément
• Appuyer pour lancer les directions

Nous ne réinventions pas la roue. Nous réparions un pneu crevé.

Design d'Abord, Panique Ensuite

J'ai commencé à esquisser des maquettes sur ma Supernote. Interface propre. Gros boutons. Gros doigts bienvenus. J'ai ajouté le tri, un bouton d'appel, peut-être un glisser-pour-appeler. Soudain, l'application "simple" n'était plus si simple.

Alors nous avons réduit. La version 1.0 devait être minimaliste. Juste des adresses, des notes, et une liste propre. Nous écouterions les commentaires et grandirions à partir de là.

Qu'est-ce qui pouvait mal se passer ?

Chapitre 2 : Ah Oui, Tout

La Surprise Swift 6

Quand Nicolas a commencé le développement dans Xcode, il visait le Swift moderne. Mais le Swift moderne avait d'autres plans.

📍 Le Problème : Le Protocole Sendable de Swift 6

Avec iOS 18 et Swift 6, Apple a introduit une application stricte au moment de la compilation du protocole Sendable pour assurer la sécurité des threads. Ça sonne bien sur le papier—jusqu'à ce que tout votre graphe d'objets se casse parce que ReferenceWritableKeyPath ne se conforme plus.

Tout type utilisé dans les requêtes SwiftData devait être rendu Sendable. Cela signifiait des refactorisations en cascade à travers chaque modèle associé—adresses, coordonnées GPS, métadonnées de contact, vous nommez.

Ce qui était autrefois une requête d'une ligne est devenu une saga de migration. Nous avons passé des jours à démêler les chaînes de propriétés, à envelopper les types non sécurisés, et à diviser la logique juste pour satisfaire le compilateur.

Le bon côté ? Notre application est maintenant robustement sécurisée pour les threads et prête pour l'avenir. Le processus était douloureux, mais le résultat est une couche de données solide comme le roc.

Quand CloudKit ne Plaisante Pas

Une fois que nous avons maîtrisé Swift 6, il était temps d'implémenter la synchronisation entre appareils. Entrez : CloudKit.

☁️ Le Problème : L'Enfer des Schémas et la Perdition des Relations

CloudKit promettait une synchronisation transparente entre appareils. Ce qu'il nous a vraiment donné : des champs optionnels partout, des relations bidirectionnelles qui pouvaient faire planter l'application s'ils étaient mal gérés, et aucun support pour les contraintes d'unicité.

Migrer notre schéma SwiftData existant a nécessité de repenser comment les relations, les valeurs par défaut, et l'identité des objets fonctionnaient. Chaque attribut devait être nullable. Chaque relation inverse devait être définie manuellement. La prévention des doublons est devenue un problème de logique fait maison.

Et ne parlons pas de tester l'état de synchronisation à travers les appareils et les conditions réseau. Ou les bugs invisibles causés par les conflits entre les modifications hors ligne et la synchronisation en ligne.

Est-ce que ça valait la peine ? Oui. Mais seulement parce que les nerfs de Nicolas n'ont pas lâché.

Du Apple classique : 90% de magie, 10% de désastre non documenté.

Chapitre 3 : Les Détails qui N'étaient Pas Optionnels

Design d'Icône : AKA Trois Semaines de Crise Existentielle

Vous penseriez que concevoir une icône prendrait une journée. Essayez trois semaines.

Elle devait être belle sur un aperçu App Store plein écran, et toujours avoir du sens comme un petit carré sur un téléphone de 4 pouces. La plupart des icônes générées par IA avaient l'air fantastiques—jusqu'à ce que vous les réduisiez. Alors elles se transformaient en bouillie de pixels.

Alors j'ai pris mon stylet et j'ai fait à l'ancienne. Nous avions besoin :

• D'une carte
• De quelques onglets ou lettres (pour le carnet d'adresses)
• D'une forme de livre

Un croquis plus tard, nous l'avions. Une icône simple et claire qui fonctionnait en grand et en petit.

J'ai lancé mon fidèle ancien workflow Stable Diffusion, j'ai entré "icône d'application Maps Address Book" et voici la toute première image qui est sortie :

À l'époque, nous avons pensé... Oh wow, c'est parfait ! Hélas, même si ça avait l'air génial au premier regard, dès que nous l'avons affichée à la taille d'icône sur mobile, nous avons réalisé que ça ne convenait pas du tout : trop petit ; faible contraste ; la carte n'est pas visible du tout. Alors je suis reparti de zéro, et j'ai fait de mon mieux pour faire quelque chose de plus percutant, vif et... visible.

Après quelques centaines d'essais, j'avais un meilleur concept. Plein écran, ça avait l'air fantastique, mais à chaque fois il y avait quelque chose qui clochait : impossible de voir les onglets ; perspective décalée ; carte de couverture pas assez visible ; trop jeu-vidéo ; trop IA ; trop moyen... Alors j'ai pris tous les concepts que j'avais trouvés jusqu'alors, et je les ai tous mis ensemble dans une icône à fort contraste et haute visibilité. Et maintenant nous l'avions, la version finale :

Il a fallu beaucoup d'essais, sur de nombreux écrans différents à différentes tailles, du compositing et beaucoup de frustration, mais j'y suis finalement arrivé. Il s'avère que les diffuseurs sont cool, mais ils ne comprennent rien à l'accessibilité. Du tout.

Leçon : L'IA peut aider. Mais elle ne comprend pas les contraintes visuelles. Il faut encore un œil humain.

Localisation : Le Niveau Boss Caché

Nous savions que nous voulions que Maps Address Book atteigne au-delà du Canada. Alors nous avons localisé.

Il s'avère que "localisation" ne signifie pas juste traduire le texte. Ça signifie :

• Traduire tout, y compris les images et les pages App Store
• Tenir compte des dispositions RTL (bonjour l'arabe)
• Corriger les bugs de police (coréen, on te voit)
• Copier-coller les chaînes traduites dans Photoshop pour chaque langue, puis exporter chaque image à nouveau

Même utiliser Claude pour générer des traductions contextuelles n'était pas suffisant. Des locuteurs natifs devaient encore tout réviser. Et l'App Store exige des captures d'écran dans toutes les langues principales.

Si vous voulez jamais comprendre l'âme d'une langue, essayez d'espacer du texte d'interface traduit à travers 12 modèles de captures d'écran avec des polices alignées à droite. Dans Photoshop.

Chapitre 4 : Ce que Nous Avons Appris

Nous avons commencé ce projet en pensant : "Ce sera facile. C'est juste un simple utilitaire."

Voici ce que nous avons appris à la place :

Écoutez tôt. Les commentaires des utilisateurs nous ont sauvés de construire les mauvaises choses. Les gens ne voulaient pas de fonctionnalités tape-à-l'œil—ils voulaient juste leurs foutues adresses.

Aucun projet n'est simple quand on se soucie de la qualité.

Le codage représente 20% du travail. Les 80% restants sont le design, l'UX, le marketing, le support, l'internationalisation, et les tests.

L'App Store compte. Une bonne description, des localisations, et des captures d'écran polies ne sont pas optionnelles.

Concevez pour la découvrabilité. Une interface claire ne suffit pas—les gens doivent sentir comment l'utiliser.

Les LLM aident. Claude a aidé avec la syntaxe Swift, l'architecture, et les traductions. Mais il ne pouvait pas prendre de décisions ou résoudre l'UX nuancée. L'IA est votre copilote, pas votre capitaine. Le 'Vibe Coding' ? Quelle blague. Le sang et les larmes, voilà ce qui nous a menés à la ligne d'arrivée.

Épilogue : Alors, Ça Valait le Coup ?

Absolument.

En une année de construction de Maps Address Book, j'ai appris plus sur la psychologie, l'UX globale, et la stratégie produit qu'en 20 ans de production audiovisuelle.

Ce n'était pas l'application que nous pensions construire. Mais c'était l'application dont nous (et apparemment tout un tas d'autres personnes) avions besoin.

Et la prochaine fois que quelqu'un vous dit "Je veux faire une app," donnez-lui cet article.

Puis servez-lui un verre.