Applications mobiles · iOS et Android
Développement d’application iOS et Android : une app, deux stores
Une seule application Flutter pour iPhone et Android, publiée sur l’App Store et Google Play. Chez AppliWin, je prends en charge le développement, les comptes, les fiches, la validation et la conformité.
Profil vérifié Codeur.com
Note moyenne : 4,87/5
- Projets réalisés
- 18
- Projets terminés
- 100 %
Une base de code pour iPhone et Android
Le développement d’une application iOS et Android ne demande plus deux projets séparés. Chez AppliWin, avec Flutter, j’écris une seule base de code, compilée en application native pour l’iPhone et pour Android, puis publiée sur l’App Store et Google Play. Vous payez une fonctionnalité une fois, et vos deux publics reçoivent les mêmes mises à jour.
Une application multiplateforme n’est pas une application au rabais. L’interface respecte les conventions de chaque système (navigation, gestes, typographie) et les fonctions du téléphone restent accessibles : caméra, notifications, géolocalisation, biométrie, Apple Pay et Google Pay. Les raisons de ce choix technique sont détaillées sur la page développeur Flutter freelance.
Cette page se concentre sur ce qui distingue vraiment les deux plateformes : leurs outils, leurs règles de publication, leurs exigences de conformité et leur rythme de mises à jour. Pour le panorama complet, des types d’applications aux budgets, consultez le guide de la création d’application mobile.
Ce qui reste propre à chaque plateforme
Un code commun ne signifie pas zéro différence. Quelques éléments demandent un travail spécifique, que j’intègre dès le départ plutôt que de les découvrir à la soumission :
- Autorisations : textes justifiant l’accès à la caméra ou à la position côté iOS, permissions déclarées dans le manifeste côté Android.
- Notifications : Firebase Cloud Messaging s’appuie sur le service d’Apple (APNs) pour l’iPhone, avec ses propres certificats.
- Liens profonds : Universal Links chez Apple, App Links chez Google, pour ouvrir l’app depuis un e-mail ou un site.
- Paiement natif : Apple Pay d’un côté, Google Pay de l’autre, chacun avec sa configuration marchand.
Natif, cross-platform ou PWA : comparatif
Trois approches existent pour une application iOS et Android : le natif, avec deux codes en Swift et Kotlin ; le cross-platform, avec une seule base de code Flutter ou React Native ; et la PWA, un site web installable. Pour une app publiée dans les stores avec un budget maîtrisé, le cross-platform l’emporte dans la majorité des cas.
| Critère | Natif (Swift, Kotlin) | Cross-platform (Flutter) | PWA |
|---|---|---|---|
| Présence dans les stores | Oui | Oui | Non, sauf cas particuliers |
| Bases de code | Deux | Une | Une, en technologies web |
| Accès au téléphone | Complet | Quasi complet | Limité, surtout sur iPhone |
| Notifications push | Oui | Oui | Sur iPhone, seulement une fois ajoutée à l’écran d’accueil |
| Coût de développement | Le plus élevé | Intermédiaire | Le plus bas |
| Mises à jour | Deux projets à publier | Un code, deux publications | Instantanées, sans validation |
La PWA garde du sens pour un outil interne ou un service consulté occasionnellement, quand la présence dans les stores n’apporte rien. Le natif se justifie pour un jeu exigeant ou une intégration matérielle pointue. Pour tout le reste, une création d’application iPhone et Android en Flutter offre le meilleur équilibre entre coût, qualité et maintenance.
iOS : App Store Connect, TestFlight et Human Interface Guidelines
Pour publier sur iPhone, il faut un compte Apple Developer Program, une compilation sur macOS et App Store Connect pour gérer la fiche, les versions et les tests. TestFlight distribue les versions bêta à vos testeurs avant la sortie, et les Human Interface Guidelines fixent les conventions d’ergonomie qu’Apple attend de toute application.
- Compte : Apple Developer Program, 99 € par an. Pour une entreprise, le compte est ouvert au nom de la société, avec un numéro D-U-N-S.
- Signature : certificats, identifiant de l’application et capacités activées (notifications, Sign in with Apple, achats intégrés).
- TestFlight : jusqu’à 10 000 testeurs externes, après une revue légère de la première version bêta.
- Human Interface Guidelines : navigation, gestes, typographie et tailles de zones tactiles propres à iOS.
La compilation iOS exige macOS : j’utilise Codemagic pour compiler, signer et envoyer chaque version vers TestFlight automatiquement. Vous recevez une invitation, installez l’application de test sur votre iPhone et suivez l’avancement au fil des versions.
Pour l’ergonomie, Flutter fournit des composants au style iOS (Cupertino) et reproduit les comportements attendus d’un iPhone, comme le retour par glissement depuis le bord de l’écran ou le défilement élastique. Une application iPhone réussie respecte ces réflexes : l’utilisateur ne doit jamais avoir l’impression d’utiliser une app pensée pour un autre système.
Android : Play Console, tests fermés et Material Design
Côté Android, tout passe par la Google Play Console : un compte à 25 $ réglés une seule fois, une vérification d’identité, puis des pistes de test interne, fermé et ouvert. Sur un compte personnel récent, Google exige un test fermé d’au moins 12 testeurs pendant 14 jours avant toute mise en production.
- Compte : 25 $ une seule fois. Un compte d’organisation demande lui aussi un numéro D-U-N-S et n’est pas soumis à l’obligation de test fermé.
- Format : Android App Bundle (AAB), que Google Play optimise pour chaque appareil.
- Pistes de test : interne pour l’équipe, fermée pour une liste de testeurs, ouverte pour un public plus large.
- Material Design : le langage visuel de Google, que Flutter implémente nativement avec Material 3.
Android, c’est aussi une grande diversité d’appareils : tailles d’écran, versions du système, puissance très variable. Les tests sur des téléphones réels révèlent ce qu’un émulateur cache. Sur l’application LSF-CFB, un Android de milieu de gamme dont le décodeur plafonnait au 1080p a imposé un réencodage automatique des vidéos en H.264. Sur Android, le téléphone du développeur n’est jamais un échantillon représentatif.
Publication : comptes, fiches, validation et ASO
Publier une application, c’est préparer deux fiches complètes : nom, sous-titre, description, captures d’écran, icône, catégorie, politique de confidentialité et compte de démonstration pour les examinateurs. Apple valide généralement en un à deux jours, Google parfois plus longtemps pour une première publication. L’ASO travaille ensuite votre visibilité dans les stores.
- Ouvrir les comptes au nom de votre entreprise, le plus tôt possible : les vérifications d’identité prennent parfois plusieurs jours.
- Préparer les fiches : textes, captures pour chaque taille d’écran exigée, icône, vidéo de présentation facultative.
- Remplir les déclarations : confidentialité, classification par âge, public visé, accès au compte de démonstration.
- Soumettre la version, répondre aux questions des examinateurs, corriger si nécessaire.
- Publier, au besoin de façon progressive, puis suivre les plantages et les avis des utilisateurs.
La publication progressive est une sécurité sous-estimée. Apple propose de diffuser une mise à jour par paliers sur sept jours, Google de choisir le pourcentage d’utilisateurs qui la reçoivent. Si un problème apparaît sur un modèle de téléphone, la diffusion s’interrompt avant de toucher tout le monde.
| Étape | Délai indicatif |
|---|---|
| Ouverture et vérification des comptes Apple et Google | Quelques jours, davantage si le numéro D-U-N-S manque |
| Test fermé obligatoire (compte Google personnel récent) | 14 jours minimum |
| Validation Apple | Un à deux jours en général |
| Première validation Google | Quelques jours |
L’ASO (App Store Optimization) est le référencement des stores : le nom, le sous-titre, les mots-clés, la qualité des captures et la note moyenne influencent la position de l’application dans les recherches. Ma formation de spécialiste SEO me sert ici directement. Les guides pas à pas pour publier une application sur l’App Store et publier sur Google Play détaillent chaque écran.
Conformité : App Privacy, Data safety, suppression de compte, achats intégrés
Apple et Google imposent des règles précises : déclarer les données collectées (App Privacy chez Apple, section Data safety chez Google), permettre la suppression du compte depuis l’application, proposer une connexion respectueuse de la vie privée comme Sign in with Apple si vous offrez Google ou Facebook, et utiliser leurs achats intégrés pour le contenu numérique.
| Exigence | App Store (Apple) | Google Play |
|---|---|---|
| Données collectées | Étiquettes App Privacy | Section Data safety |
| Suppression de compte | Possible depuis l’application | Possible depuis l’application et via un lien web |
| Connexion via un compte tiers | Option équivalente respectueuse de la vie privée, comme Sign in with Apple | Pas d’obligation équivalente |
| Contenu numérique vendu | Achats intégrés Apple | Google Play Billing |
| Biens et services physiques | Paiement libre : Stripe, Apple Pay | Paiement libre : Stripe, Google Pay |
Les achats intégrés entraînent une commission de 15 à 30 % selon votre chiffre d’affaires et le type d’achat. Dans l’Union européenne, le Digital Markets Act ouvre des alternatives, avec leurs propres conditions : je vous aide à arbitrer selon votre modèle économique. Côté RGPD, la politique de confidentialité, le consentement aux traceurs et la minimisation des données se préparent dès les maquettes, pas la veille de la soumission.
La CNIL a d’ailleurs publié en 2024 des recommandations dédiées aux applications mobiles, actualisées en 2025 : information claire au bon moment, consentement pour tout traitement non nécessaire au service, répartition des responsabilités entre l’éditeur, le développeur et les fournisseurs de SDK. Je m’en sers comme grille de lecture pour chaque bibliothèque tierce intégrée à l’application.
Mises à jour d’iOS, d’Android et targetSdk
Une application publiée vieillit avec les systèmes. Apple impose chaque année de compiler avec un SDK récent, et Google exige de cibler une version récente d’Android : depuis le 31 août 2026, toute nouvelle application ou mise à jour doit viser Android 16 (API 36). Sans maintenance, une app finit par ne plus pouvoir évoluer.
- Chaque année chez Apple : une version majeure d’iOS à l’automne, puis l’obligation de compiler avec le SDK correspondant pour publier.
- Chaque année chez Google : une version majeure d’Android et une échéance targetSdk fin août pour les nouvelles versions.
- En continu : mises à jour de Flutter, des packages et des services tiers (paiement, notifications), à suivre pour la sécurité.
Une application qui ne respecte plus le niveau d’API exigé ne peut plus publier de mise à jour, et devient invisible pour les nouveaux utilisateurs des téléphones récents. C’est l’objet de la maintenance d’application mobile : mises à jour techniques, tests sur les nouvelles versions des systèmes, corrections et évolutions.
Combien coûte une application iOS et Android ?
Avec Flutter, une application iOS et Android coûte bien moins que deux applications natives. À titre indicatif, comptez 3 500 à 7 000 € HT pour une application vitrine et 6 000 à 14 000 € HT pour une application e-commerce ou de réservation, pour un délai de deux à cinq mois selon le périmètre.
S’ajoutent les frais des stores (99 € par an chez Apple, 25 $ une seule fois chez Google), l’hébergement du back-office et la maintenance annuelle. Ces fourchettes sont indicatives : le devis définitif suit un cadrage gratuit. Le détail des postes est dans le guide du prix d’une application mobile, et vous pouvez demander un devis pour votre application iOS et Android dès maintenant.
Questions fréquentes sur les applications iOS et Android
Faut-il développer deux applications pour iOS et Android ?
Non, plus dans la grande majorité des cas. Avec un framework cross-platform comme Flutter, une seule base de code produit deux applications natives, une pour l’App Store et une pour Google Play. Les fonctionnalités, les corrections et les évolutions sont écrites une fois. Seuls quelques éléments restent propres à chaque plateforme : la signature, les fiches des stores, certaines autorisations et, parfois, une adaptation d’interface. Développer deux applications natives séparées ne se justifie que pour un jeu exigeant, une intégration matérielle très spécifique ou une grande équipe déjà spécialisée par plateforme.
Combien coûtent les comptes développeur Apple et Google ?
Le compte Apple Developer Program coûte 99 € par an ; Apple en exonère, sur demande, certaines associations, établissements d’enseignement et administrations. Le compte Google Play Console coûte 25 $, réglés une seule fois. Pour une entreprise, les deux comptes s’ouvrent au nom de la société et demandent un numéro D-U-N-S, gratuit, qu’il faut parfois quelques jours pour obtenir. Je recommande de les ouvrir à votre nom dès le début du projet : l’application vous appartient ainsi dans les stores, et je n’y interviens qu’en tant que développeur invité.
Qui publie l’application, et sur quel compte ?
Je prends en charge la publication : fiches des stores, soumission, suivi de la validation et conformité. Je recommande d’ouvrir les comptes Apple et Google à votre nom dès le début du projet : j’y interviens en tant que développeur invité, et l’application vous appartient dans les stores. Les motifs de refus et les délais d’examen sont détaillés dans mon guide refus App Store et validation.
