Expertise · Applications mobiles
Nous construisons des applications natives iOS en Swift, avec des capteurs et HealthKit, et des applications à un seul code pour iOS, Android et le web lorsque le projet ne demande pas de capteurs. Le noyau logique est testé séparément de l’écran.
Déjà construitSunt trei implementări proprii, nu una. Un depozit cu cinci ținte de aplicație (patru iOS și una macOS) definite în `project.yml`, ale cărui teste de logică le-am rulat azi: 160 din 160 trec. O a doua aplicație iOS, în alt proiect, cu 40 de fișiere Swift și HealthKit. Și o a treia direcție, cu un singur cod pentru iOS, Android și web, a cărei variantă web răspunde astăzi. Rezerva care schimbă răspunsul la întrebarea pe care o pune orice cumpărător înainte de toate: niciuna dintre aplicațiile noastre nu este publicată în App Store sau Google Play. Motivul e unul singur și are nume — `DEVELOPMENT_TEAM` este gol în configurația de proiect, adică lipsește identificatorul de echipă din Apple Developer Program. Mașina are o identitate de semnare validă, suficientă pentru instalare pe dispozitiv propriu, insuficientă pentru distribuție în magazin. E o problemă de cont, nu de cod, dar rămâne o problemă și o scriem aici, nu la subsol.
Une application mobile a deux parties qui se cassent différemment. La partie qui lit les capteurs et calcule quelque chose — un angle, un score, un état — et la partie qui dessine des écrans. Nous les gardons séparées, et pas pour des raisons esthétiques : dans notre principal dépôt iOS, les fichiers du noyau n’importent pas l’interface, si bien qu’ils peuvent être compilés directement avec `swiftc` sur Mac et exécutés comme un programme ordinaire, sans simulateur et sans téléphone. La suite compte 160 vérifications regroupées en 16 étapes ; nous l’avons exécutée aujourd’hui et elle passe intégralement. C’est la raison pour laquelle nous pouvons dire ce que fait exactement un algorithme, au lieu de dire qu’il « fonctionne bien ».
Sur iOS, nous travaillons en Swift 6, avec une cible minimale iOS 17. Le même dépôt définit cinq applications comme cibles séparées : quatre pour iPhone et une pour macOS, et la version macOS réutilise quinze fichiers du noyau de l’iOS, sans copie. Les capteurs sont lus à la source : l’interface Apple pour les capteurs des écouteurs expose l’orientation de la tête, et l’application compare l’angle courant à une position que l’utilisateur calibre au début de la session. Les seuils ne sont pas des « réglages internes » : en dessous de 7° c’est droit, entre 7° et 13° c’est une inclinaison, au-dessus de 13° maintenu trois secondes déclenche l’alerte, et le lissage utilise une moyenne exponentielle avec le coefficient 0,15. Les quatre valeurs se trouvent dans quatre lignes de code consécutives et peuvent être montrées.
Quand le projet n’a pas besoin de capteurs, nous ne recommandons pas le natif. La troisième direction du portefeuille est un seul code qui se compile pour iPhone, Android et navigateur — React Native avec Expo — et la version web est publiée et répond aujourd’hui. La différence pratique pour le client : un questionnaire, un calculateur ou un tableau de bord ne justifie pas deux équipes et deux dépôts ; une application qui écoute un capteur à vingt mesures par seconde, oui.
Ce que nous ne pouvons pas encore. Aucune de nos applications n’est dans l’App Store ou Google Play. Pas parce qu’elles ne compilent pas — elles compilent, s’installent sur le simulateur et passent les tests — mais parce que, dans la configuration du projet, l’identifiant d’équipe Apple est vide, c’est-à-dire qu’il n’existe pas d’inscription au Apple Developer Program liée à ces builds. Sur Mac, il existe une identité de signature valide, de type développement, qui suffit pour l’installation sur son propre appareil et ne suffit pas pour la boutique. Pour un projet client, le compte développeur est ouvert au nom de la société cliente et lui appartient — c’est la discussion qui doit avoir lieu au début, pas à la fin.
Ce que cela comprend
Sur iOS, nous utilisons directement les interfaces Apple : `CMHeadphoneMotionManager` pour l’orientation de la tête à partir des écouteurs, avec un délégué pour la connexion et la déconnexion, et une vérification explicite de l’état d’autorisation avant de lancer le flux. Si le capteur n’est pas disponible, l’état passe à `waiting`, pas à une erreur silencieuse.
Les fichiers d’analyse, de calibrage, d’historique et de politiques sont du Swift simple. Ils se compilent avec `swiftc` avec le fichier de tests et s’exécutent comme un binaire en ligne de commande. Résultat d’aujourd’hui : 160 vérifications, 16 étapes de 10, toutes passées. Un test qui s’exécute en deux secondes sur Mac s’exécute à chaque modification ; un test qui exige un simulateur, non.
SwiftUI pour les deux. La cible macOS du même dépôt inclut quinze fichiers du noyau iOS comme sources partagées, et non comme fichiers copiés, donc une correction dans l’algorithme arrive simultanément dans les deux applications.
Expo au-dessus de React Native, avec `react-native-web` pour la version navigateur, des polices chargées depuis le paquet et des icônes d’application séparées pour Android, y compris la variante monochrome exigée par le système. La même application fonctionne sur téléphone et dans la page, à partir d’un seul dépôt.
Nous ne « lisons pas HealthKit », mais un tableau dans le code : onze types de données (angles posturaux, mouvement brut depuis les écouteurs, pouls et variabilité, sommeil, marche, exposition audio, séances guidées et autres) et cinq régimes possibles (local uniquement, lecture depuis HealthKit, écriture d’entraînement, écriture de séance de relaxation, écriture de parcours). Chaque type reçoit explicitement l’un des régimes. La deuxième application iOS du portefeuille, issue d’un projet privé, utilise la même approche sur 40 fichiers Swift.
Quatre cibles ont `PrivacyInfo.xcprivacy` inclus comme ressource de build, pas ajouté à la hâte après le premier rejet. Les descriptions d’utilisation pour le mouvement, la caméra, le microphone, HealthKit et les notifications sont rédigées en roumain, dans la configuration du projet, non générées automatiquement.
La recherche de `URLSession` dans les sources de la cible iOS renvoie zéro résultat. L’historique est enregistré sur l’appareil, via `FileManager` et `UserDefaults`, avec option de suppression du fichier. Le seul code réseau du dépôt se trouve dans une fonction de l’application macOS, dans un fichier séparé. Quand une application n’a pas besoin de serveur, nous ne lui en mettons pas un.
L’onboarding comporte 24 étapes avec des identifiants uniques et ordonnés, et certaines étapes demandent une confirmation explicite (les limites du capteur, le fonctionnement au premier plan, la confidentialité, la préparation) sans laquelle le bouton de continuité reste bloqué. L’état est encodé et repris. Dix des 160 tests vérifient exactement cela.
Nous vérifions quel compte développeur existe, au nom de quelle société, qui l’administre et ce qui manque pour que la build puisse être signée pour le magasin. C’est une liste courte et ennuyeuse, mais c’est la différence entre une application qui fonctionne sur notre téléphone et une autre qui arrive jusqu’aux utilisateurs.
À quoi cela ressemble
La question n’est pas de goût, mais de matériel : l’application a-t-elle besoin de mouvement, de santé, de Bluetooth, de caméra en temps réel, d’arrière-plan ? Si oui, natif. S’il s’agit de formulaires, de calculs, de listes et d’un tableau de bord, un seul code pour iOS, Android et le web fait le même travail avec la moitié de la maintenance. Nous livrons la décision écrite, avec le motif.
L’algorithme, les seuils, les états et la persistance. Les tests se compilent directement sur Mac et s’exécutent en quelques secondes. Nous livrons la suite et son résultat, pas une promesse de qualité.
SwiftUI sur iOS et macOS, ou React Native quand nous avons choisi le code commun. Nous vérifions le parcours de départ, les permissions et le comportement lorsque le capteur manque ou se déconnecte au milieu de la session — le cas qui se casse souvent en pratique.
Identifiant de paquet, version, icônes, fichier de confidentialité, descriptions des permissions, identifiant d’équipe du Apple Developer Program. C’est ici que se bloquent les projets qui n’ont pas discuté du compte dès le début — y compris les nôtres, ce qui est précisément la raison pour laquelle nous mettons cette étape sur papier.
Les données
Les questions que pose toute personne ayant un délégué à la protection des données — posées ici avant qu'il ne les pose.
Un cas
La situation
Un projet propre, non celui d’un client : un chronomètre de concentration qui observe à quel point la tête s’est inclinée par rapport à une position calibrée par l’utilisateur au début de la session. Nous avions besoin d’un cas où les affirmations sur l’algorithme puissent être montrées, pas décrites.
Ce que nous avons construit
J’ai séparé le noyau de l’interface et j’ai écrit les seuils dans le code, pas dans la documentation : en dessous de 7° droit, entre 7° et 13° dérive, au-delà de 13° maintenu pendant trois secondes, cela déclenche l’alerte haptique, avec un lissage exponentiel au coefficient 0,15. Les données proviennent de l’interface Apple pour les capteurs des écouteurs, avec gestion explicite de la déconnexion. L’onboarding comporte 24 étapes, dont quatre demandent la confirmation des limites avant de laisser l’utilisateur continuer. J’ai construit à partir du même noyau une variante pour macOS.
Ce qui en est sorti
La suite logique se compile avec `swiftc` et s’exécute sur Mac en quelques secondes : 160 vérifications en 16 étapes, toutes passées lors de la dernière exécution. L’application s’installe et se lance sur le simulateur. Toute affirmation du paragraphe ci-dessus peut être vérifiée en ouvrant quatre lignes de code.
Ce que le cas ne dit pas
Elle n’est pas dans l’App Store. La configuration du projet a l’identifiant d’équipe Apple vide, donc la build ne peut pas être signée pour la distribution — une absence d’inscription au programme Apple, pas une absence de fonctionnalité. Et encore une limite, du produit et non du code : elle mesure l’inclinaison de la tête, pas la santé de la colonne vertébrale, et fonctionne avec les écouteurs qui exposent des capteurs de mouvement via l’interface Apple.
Questions
Non. Aucune de nos applications n’est dans l’App Store ni sur Google Play, et il est juste de poser cette question d’abord. Ce que nous pouvons montrer : cinq cibles d’application définies dans le même projet, dont quatre pour iPhone et une pour macOS, qui compilent et s’installent sur le simulateur, plus la suite logique de 160 vérifications, exécutée à la demande devant vous. Le blocage de publication est `DEVELOPMENT_TEAM` vide dans la configuration du projet, c’est-à-dire l’absence d’un identifiant d’équipe du Apple Developer Program. Sur Mac, il existe une identité de signature valide, de type développement — suffisante pour une installation sur son propre appareil, pas pour l’App Store.
De rien, si vous demandez une preuve de publication — nous n’en avons pas et nous n’en inventons pas. Ce que vous pouvez vérifier, c’est le reste de la chaîne : du code qui compile, des tests qui passent, des fichiers de confidentialité présents, des permissions déclarées, des icônes et des versions configurées. L’étape qui manque est une inscription payante dans un programme Apple, faite au nom de la société qui détient l’application. Dans un projet client, ce compte est celui du client et il est ouvert au début, précisément pour que ce ne soit pas l’étape qui surprenne quelqu’un à la fin.
Cela dépend des capteurs. Si l’application lit le mouvement, la santé, le Bluetooth ou la caméra en temps réel, native — ces interfaces sont celles de la plateforme et toute couche intermédiaire ajoute de la latence et de nouveaux modes de panne. Si l’application est essentiellement des formulaires, des calculs et des écrans de résultat, un seul code couvre iOS, Android et le navigateur à partir d’un dépôt. Nous avons les deux variantes dans notre portefeuille et nous les choisissons avec un argument écrit, pas par défaut.
Par le code commun, oui : le même projet Expo produit un build pour Android, avec l’icône adaptative et la variante monochrome requise par le système, déjà configurées. Android natif, en Kotlin, n’est pas dans notre portefeuille — si un projet l’exige, nous le disons avant, pas après la signature.
Par le fait que le noyau ne dépend pas de l’écran. Les fichiers d’analyse se compilent séparément, avec le compilateur Swift, et s’exécutent comme programme sur Mac. La suite actuelle comporte 160 vérifications en 16 étapes et s’exécute en quelques secondes. Ce qui ne peut pas être vérifié ainsi — la sensation d’une vibration, l’apparence d’un écran sur un téléphone précis, le comportement des écouteurs quand ils sortent d’une oreille — se teste sur l’appareil, et l’on dit ce qui est quoi.
Seulement si vous les approuvez, type par type, dans l’écran Apple, et uniquement celles déclarées. Dans le code, la politique est explicite pour chaque type de donnée : certaines restent seulement sur le téléphone, d’autres sont lues depuis HealthKit, d’autres peuvent être réécrites comme entraînement ou comme séance de relaxation. Il n’y a pas de diagnostic, et les données ne nous parviennent pas.
Elles restent sur le téléphone. Dans l’application iOS de référence de notre portefeuille, il n’y a aucun appel réseau — la recherche de `URLSession` dans les sources de cette cible renvoie zéro résultat. L’historique est écrit dans un fichier local et peut être supprimé depuis l’application. Lorsqu’un projet a besoin d’un serveur, nous le construisons, mais nous ne le mettons pas par réflexe.
Cela commence par une vérification de compatibilité, pas par une offre : quelle version de plateforme elle cible, quelles dépendances elle a et lesquelles sont encore maintenues, si le build se reproduit sur une machine propre, qui détient le compte développeur et les clés. Il existe des projets où la réponse honnête est que réécrire le noyau coûte moins cher que le maintenir.
Sur macOS, oui, et à partir du même noyau : dans notre dépôt principal, la cible macOS réutilise quinze fichiers de logique de l’application iPhone, comme sources partagées. Windows n’est pas dans le portefeuille.
10 d'entre elles sont du code et des fichiers de nos dépôts. Nous n'en publions ni le nom ni la ligne : réunies sur une seule page, elles décriraient trop précisément comment sont construits des systèmes qui ne sont pas seulement les nôtres. Nous les parcourons avec vous, dans le dépôt, sur demande — la vérification reste possible, elle se fait simplement lors d'un échange.
Racontez-nous votre processus. Ensemble, nous décidons ce qui vaut la peine d'être construit, ce que nous pouvons connecter et comment nous vérifions le résultat.