Mickael Romaniello, le développeur qui construit les applications Mickael Romaniello 30 minutes, sans slides, rien à préparer.

Développement application iOS

Les utilisateurs iOS dépensent davantage dans les applications que les utilisateurs Android, et l'App Store est le plus strict des deux : la règle 4.2 refuse à elle seule tout ce qui n'est qu'un site web reconditionné. Je construis des applications iOS natives en Swift qui passent la review du premier coup.

Réservez un appel gratuit →

Ce que vous obtenez

1 Swift + SwiftUI

Stack Apple moderne avec des animations à 60fps et des transitions fluides.

2 Publication sur l'App Store

Taux de passage à la première soumission. Je connais les critères des reviewers Apple.

3 HealthKit, Core Data, StoreKit

Intégration profonde avec iOS quand votre produit en a besoin.

4 Apple Watch + iPad

Optionnel mais puissant. Applications universelles bien faites.

5 Architecture respectueuse de la vie privée

Les règles Apple sont strictes. Votre app sera conforme dès le départ.

Ce que la revue d'Apple vérifie vraiment

Un refus n'a presque jamais de rapport avec la qualité du code. Les motifs qui reviennent sont prévisibles : un compte de test qui ne fonctionne pas ou qu'on a oublié de fournir, une permission demandée sans explication écrite, une fonction annoncée dans la fiche mais absente de l'application, un lien de paiement qui contourne le système d'Apple, une politique de confidentialité qui ne correspond pas à ce que l'application fait. La règle 4.2 est la plus brutale : une application qui n'est qu'un site web reconditionné est refusée. Ça se prépare avant de soumettre, pas après le refus.

L'écosystème Apple : quand il vaut le détour

Apple Watch, iPad, widgets, raccourcis Siri : chacun est une application supplémentaire à concevoir, à tester et à maintenir, pas une case à cocher. Ça vaut le coup quand l'usage le demande vraiment — un suivi qu'on consulte au poignet pendant l'effort, un outil de saisie qui gagne à la surface d'un iPad. Ça ne vaut pas le coup pour afficher la même chose en plus petit. Je préfère une application iPhone qui fait bien son travail à quatre déclinaisons qui se partagent le même budget de tests.

La vie privée est une contrainte de conception, pas une case

Sur iOS, suivre un utilisateur d'une application à l'autre demande son autorisation explicite, et une grande partie des gens la refuse — un modèle économique qui repose là-dessus doit le savoir avant qu'on écrive une ligne. La fiche de confidentialité du store doit par ailleurs décrire exactement ce que l'application collecte, y compris via les bibliothèques tierces qu'on y ajoute. Chaque permission demande un texte d'explication, et un texte vague fait refuser l'application. Autant décider tôt ce qu'on collecte : c'est aussi ce qui simplifie le RGPD.

Choisissez votre ville

Chaque ville a sa propre page dédiée avec des conseils, études de cas et un formulaire de contact.

Monaco (1)

Découvrez les autres services

Besoin de discuter de votre projet ?

En 30 minutes, vous saurez par où commencer. Sans engagement. Sans jargon technique.

Réservez un appel gratuit →

À propos de l'auteur

Mickael Romaniello — Ingénieur produit mobile basé dans le Sud de la France. 12 ans d'expérience en développement d'applications iOS, Android et desktop. Plus de 15 projets livrés pour des startups, ETI et grands comptes. LinkedIn.

Dernière mise à jour:

Standards et références

Apple Human Interface Guidelines · Google Material Design · web.dev (Google) · MDN Web Docs · OWASP Mobile Top 10