Utilitaire
Une tâche précise, faite vite : un convertisseur, un minuteur, un scanner.
Build With Me / Apple / iOS
Construisons votre app iOS.
D’une idée sur papier à une application que des gens utilisent vraiment.
Une app iPhone native se construit en Swift et SwiftUI, dans Xcode sur un Mac, puis se teste avec TestFlight et se publie via App Store Connect après la validation d’Apple. Avant d’écrire du code, vérifiez que le problème existe et que le natif est nécessaire : une application web adaptée au téléphone suffit souvent pour une première version. Cette page donne le parcours complet, en vingt étapes, avec les règles qui font refuser une app.
Vérifié le
En bref
- Langage et interface
- Swift et SwiftUI ; les exemples ici visent iOS 17 (@Observable, SwiftData)
- Outil
- Xcode, sur Mac uniquement ; publication avec Xcode 26 ou plus récent depuis le 28 avril 2026
- Compte
- Apple Developer Program : 99 USD par année d’adhésion (ou monnaie locale) pour TestFlight et l’App Store
- Bêta
- TestFlight : 100 testeurs internes, 10’000 externes, builds testables 90 jours
- Validation
- Selon Apple : 50 % des soumissions examinées en moins de 24 h, 90 % en moins de 48 h — la décision reste à Apple
Trois façons de construire
Apprendre, construire ensemble, ou faire réaliser.
01 · Apprendre et construireRessources disponibles — Un guide sur ce site et la documentation officielle.
Apprendre le développement iOS
Le parcours en vingt étapes ci-dessous, chaque étape reliée à une ressource officielle d’Apple, et le constructeur de projet pour votre feuille de route. Build School enseigne la construction de produits web, pas Swift : pour iOS, ce sont ces guides et les tutoriels d’Apple.
02 · Construire ensembleSur demande — Étudié au cas par cas, sans prix ni délai promis.
Construire votre app iOS ensemble
Vous construisez ; Bynilson relit votre périmètre, votre architecture et vos étapes, par écrit. Étudié au cas par cas : il n’y a pas encore d’app native publiée dans le portfolio Bynilson, et la réponse peut être une orientation vers un spécialiste iOS.
03 · Le faire réaliserNon proposé — Bynilson ne le fait pas ; voici ce qui aide à la place.
Faire développer votre app iOS
Bynilson ne réalise pas d’apps mobiles natives. Ce qui aide à la place : le constructeur de projet produit une feuille de route et un brief à confier à un studio iOS spécialisé, et le guide « recruter ou externaliser » aide à choisir comment l’équiper.
Bynilson ne réalise pas d’applications mobiles natives : le parcours vous donne la feuille de route et le brief à confier à un studio spécialisé. Une demande d’accompagnement (vous construisez, avec un regard extérieur) est étudiée au cas par cas.
01 — Pourquoi iOS
Quand une app iPhone native est le bon choix
- Le produit vit dans la poche : on l’ouvre plusieurs fois par jour, quelques secondes à chaque fois.
- Il dépend du téléphone : caméra, localisation, données de santé, notifications, widgets, Raccourcis.
- Il doit fonctionner sans réseau, ou mieux qu’un site quand le réseau est mauvais.
- Vos utilisateurs cherchent ce genre d’outil dans l’App Store, et y payer est pour eux naturel.
02 — Natif ou multiplateforme
SwiftUI natif, React Native, Flutter, ou le web ?
Aucune approche n’est la meilleure partout. Le bon choix dépend des appareils visés, des fonctions système nécessaires et de l’équipe qui maintiendra le code.
| Approche | Langage | Points forts | Limites | Adaptée quand |
|---|---|---|---|---|
| Natif : SwiftUI (iOS), Kotlin et Jetpack Compose (Android) | Swift ; Kotlin | Accès complet et immédiat aux API de chaque système, interface fidèle aux conventions, performances | Deux bases de code si vous voulez aussi Android | iPhone d’abord, ou fonctions système profondes (santé, widgets, caméra) |
| React Native, souvent avec Expo | JavaScript / TypeScript | Un code pour iOS et Android, composants d’interface natifs ; Expo propose un service hébergé qui compile les apps | Les API récentes ou rares passent par des modules natifs ; une couche de plus à mettre à jour | iOS et Android ensemble, équipe déjà à l’aise en TypeScript |
| Flutter | Dart | Un code pour iOS, Android, web et desktop ; rendu identique partout | Interface dessinée par Flutter, pas par le système : les conventions Apple sont à reproduire | Une même interface de marque sur toutes les plateformes |
| Application web adaptée au téléphone (PWA) | HTML, CSS, JavaScript | Pas de store, pas de validation, une seule version, installable sur l’écran d’accueil | Accès plus limité aux fonctions du téléphone, pas de présence dans l’App Store | Valider une idée, un outil surtout fait de formulaires et de contenus |
Et Android ? Le natif Android s’écrit en Kotlin avec Jetpack Compose et se publie via la Play Console de Google ; les cours officiels de Google partent de zéro. Comme pour iOS, Bynilson ne réalise pas d’apps Android : le constructeur de projet produit la feuille de route et le brief.
03 — Types d’apps
Ce qui change selon le type d’app
Le type d’app décide des frameworks, des règles de l’App Store qui s’appliquent et des risques de refus.
Productivité
Listes, notes, suivis, documents — utilisés tous les jours.
Social
Profils, fils, messages, contenus publiés par les utilisateurs.
Éducation
Leçons, exercices, progression.
Business
Un outil pour une équipe ou pour les clients d’une entreprise.
Voyage
Itinéraires, réservations, cartes, documents hors ligne.
Santé et bien-être
Suivi d’activité, d’habitudes, de symptômes.
Commerce
Vendre des produits ou des services.
Outils créatifs
Photo, vidéo, dessin, musique.
Expériences IA
Résumer, générer, reconnaître, converser.
04 — Technologies
Les briques d’une app iPhone
SwiftUI
L’interface, décrite comme une fonction de l’état.
Quand : Toute nouvelle app.
Pas quand : Un composant manque : intégrez un élément UIKit plutôt que de tout réécrire.
Observation (@Observable)
Le suivi des changements d’état qui rafraîchit les vues (iOS 17+).
Quand : Le modèle partagé entre plusieurs écrans.
Pas quand : Une app qui doit tourner avant iOS 17 : il faut alors l’ancienne approche ObservableObject.
NavigationStack
La navigation par valeurs, avec des liens qui ne dépendent pas des écrans (iOS 16+).
Quand : Listes et détails, parcours en plusieurs étapes.
SwiftData
Le stockage local de vos modèles Swift (iOS 17+), synchronisable avec iCloud.
Quand : Données hors ligne, brouillons, cache.
Pas quand : Des données partagées entre utilisateurs : elles vivent sur un serveur.
Authentication Services
La connexion : Sign in with Apple, passkeys, connexion à des services web.
Quand : Dès qu’il y a des comptes.
Pas quand : Une app sans fonction liée à un compte : laissez-la utilisable sans connexion (5.1.1(v)).
StoreKit
Achats intégrés et abonnements.
Quand : Contenu ou fonctions numériques payants (3.1.1).
Pas quand : Biens physiques et services consommés hors de l’app (3.1.3(e)).
User Notifications
Notifications locales, ou envoyées par votre serveur.
Quand : Un rappel ou une information attendus.
Pas quand : Du marketing sans accord explicite (4.5.4).
WidgetKit et App Intents
Widgets, Live Activities, contrôles ; actions pour Siri, Spotlight et Raccourcis.
Quand : Une information à consulter d’un coup d’œil, une action répétée.
Pas quand : Avant que le parcours principal fonctionne.
Core Location, AVFoundation, PhotoKit
Position, caméra et audio, photothèque.
Quand : Quand la fonction principale en dépend.
Pas quand : « Au cas où » : chaque autorisation demandée sans raison inquiète et peut faire refuser l’app.
Keychain
Le stockage chiffré des jetons et mots de passe.
Quand : Tout jeton de connexion.
Pas quand : Jamais de secret dans UserDefaults.
Swift Testing
Le framework de tests de Swift (Xcode 16+).
Quand : Les règles métier, le modèle, les calculs.
05 — Le parcours
De l’idée à l’App Store, en vingt étapes
Chaque étape renvoie à une ressource officielle. Faites-les dans l’ordre : sauter la validation ou le périmètre coûte plus cher que n’importe quelle ligne de code.
- 01
Valider le problème
Parlez à cinq personnes qui ont le problème. Notez ce qu’elles font aujourd’hui à la place de votre app, et ce que ça leur coûte. Pas de code tant que ce n’est pas clair.
DisponiblePrototype ou v1 ?
- 02
Définir la première version (MVP)
Une phrase pour le résultat, trois fonctions au maximum, et la liste de ce qui attendra. Ce qui n’est pas dans la liste n’est pas construit.
DisponibleBuild OS — les 22 étapes d’un produit, de l’idée à l’exploitation
- 03
Comprendre l’écosystème Apple
Lisez « Concevoir pour iOS » : tailles d’écran, navigation, gestes, accessibilité. Une app qui suit ces conventions paraît évidente à ses utilisateurs.
DisponibleConcevoir pour iOSApple
- 04
Installer et configurer Xcode
Installez Xcode depuis le Mac App Store, créez un projet « App » avec l’interface SwiftUI, lancez-le dans le simulateur, puis sur votre iPhone avec un compte Apple gratuit.
- 05
Apprendre les bases de Swift
Types, optionnels, structures et classes, fonctions, gestion des erreurs. Les tutoriels « Develop in Swift » d’Apple partent de zéro.
DisponibleTutoriels « Develop in Swift »Apple
- 06
Construire l’interface avec SwiftUI
Vues, mise en page, listes, formulaires. Construisez d’abord les écrans avec des données d’exemple, sans serveur.
DisponibleTutoriels SwiftUIApple
- 07
Gérer l’état de l’app
Un modèle @Observable partagé, @State pour l’état local d’un écran. Une seule source de vérité par donnée.
DisponibleObservation (@Observable)Apple
- 08
Mettre en place la navigation
NavigationStack pour les listes et les détails, des onglets s’il y a plusieurs espaces. Naviguez par valeurs, pas en imbriquant des écrans.
DisponibleNavigationStackApple
- 09
Enregistrer les données
SwiftData pour ce qui reste sur l’appareil. Décidez tôt ce qui doit aussi exister sur un serveur.
DisponibleSwiftDataApple
- 10
Connecter des API
Appels réseau avec URLSession et async/await, décodage JSON avec Codable, états de chargement et d’erreur visibles. Les clés secrètes restent sur votre serveur, jamais dans l’app.
DisponibleURLSession (appels réseau)Apple
- 11
Ajouter l’authentification
Seulement si le produit a des fonctions liées à un compte. Prévoyez la suppression du compte dans l’app (5.1.1(v)) et, avec une connexion Google ou Facebook, une option équivalente (4.8).
DisponibleAuthentication Services (connexion)Apple
- 12
Ajouter les paiements, quand c’est pertinent
Achats intégrés pour le numérique, autre moyen de paiement pour le physique. Testez les achats dans l’environnement de test de StoreKit avant de vendre.
DisponibleStoreKit (achats intégrés)Apple
- 13
Gérer la confidentialité et les autorisations
Un texte d’explication pour chaque autorisation, les détails de confidentialité dans App Store Connect, un manifeste de confidentialité si vous utilisez des API « à raison requise ».
- 14
Tester sur simulateurs et appareils
Plusieurs tailles d’écran dans le simulateur, puis un vrai iPhone : réseau lent, mode avion, grande taille de texte, VoiceOver.
- 15
Préparer les éléments App Store
Captures d’écran qui montrent l’app en usage (2.3.3), description, mots-clés, classification par âge, URL de support et politique de confidentialité.
DisponibleAide App Store ConnectApple
- 16
Distribuer avec TestFlight
D’abord des testeurs internes, puis externes. Recueillez les retours dans TestFlight et corrigez avant la soumission.
DisponibleTestFlight — vue d’ensembleApple
- 17
Soumettre via App Store Connect
Build envoyé depuis Xcode 26 ou plus récent, fiche complète, notes pour la validation avec un compte de démonstration si l’app demande une connexion.
- 18
Traiter les retours de la validation
Un refus cite une règle : corrigez précisément ce point, répondez dans App Store Connect, ou expliquez si c’est un malentendu. La décision appartient à Apple.
DisponibleRègles de validation de l’App Store (App Review Guidelines)Apple
- 19
Suivre les plantages et les retours
Rapports de plantage dans l’Organizer d’Xcode, avis sur l’App Store, retours TestFlight. Corrigez d’abord ce qui bloque le parcours principal.
DisponibleRécupérer les rapports de plantageApple
- 20
Itérer après le lancement
Une nouvelle version d’iOS chaque année, des exigences de publication qui montent : planifiez une mise à jour annuelle, et lisez la page des exigences à venir.
DisponibleExigences à venir (SDK, Xcode)Apple
06 — Exemple
Une petite app SwiftUI complète
Une liste d’habitudes avec un écran de détail : un modèle @Observable, une NavigationStack, aucune dépendance. Pour l’essayer, créez un projet « App » SwiftUI dans Xcode, remplacez le contenu du fichier « …App.swift » par le second fichier, ajoutez le premier et supprimez ContentView.swift.
import Foundation
import Observation
struct Habit: Identifiable, Hashable {
let id = UUID()
var name: String
var isDoneToday = false
}
// @Observable (iOS 17+) : les vues qui lisent une propriété se mettent à jour quand elle change.
@Observable
final class HabitStore {
var habits: [Habit] = [
Habit(name: "Lire 10 pages"),
Habit(name: "Marcher 20 minutes"),
]
func habit(with id: Habit.ID) -> Habit? {
habits.first { $0.id == id }
}
func toggle(_ id: Habit.ID) {
guard let index = habits.firstIndex(where: { $0.id == id }) else { return }
habits[index].isDoneToday.toggle()
}
}Typechecked with Xcode 27.1 (iOS SDK 27.1), target iOS 17, Swift 5 and Swift 6 language modes — 2026-10-23
import SwiftUI
@main
struct HabitsApp: App {
@State private var store = HabitStore()
var body: some Scene {
WindowGroup {
HabitListView(store: store)
}
}
}
struct HabitListView: View {
let store: HabitStore
var body: some View {
// NavigationStack (iOS 16+) : la navigation suit des valeurs, pas des vues.
NavigationStack {
List(store.habits) { habit in
NavigationLink(value: habit.id) {
Label(habit.name, systemImage: habit.isDoneToday ? "checkmark.circle.fill" : "circle")
}
}
.navigationTitle("Habitudes")
.navigationDestination(for: Habit.ID.self) { id in
HabitDetailView(store: store, id: id)
}
}
}
}
struct HabitDetailView: View {
let store: HabitStore
let id: Habit.ID
var body: some View {
if let habit = store.habit(with: id) {
VStack(spacing: 24) {
Text(habit.name).font(.title2)
Button(habit.isDoneToday ? "Marquer comme non fait" : "Marquer comme fait") {
store.toggle(id)
}
.buttonStyle(.borderedProminent)
}
.padding()
.navigationTitle("Aujourd’hui")
} else {
ContentUnavailableView("Habitude introuvable", systemImage: "questionmark.circle")
}
}
}Typechecked with Xcode 27.1 (iOS SDK 27.1), target iOS 17, Swift 5 and Swift 6 language modes — 2026-10-23
07 — Planificateur
Cadrer votre app iOS
Choisissez le type d’app et les fonctions dont elle a besoin : le planificateur indique les frameworks, les règles de l’App Store qui s’appliquent et les points à prévoir, avec la raison de chaque ligne.
Répondez à une question pour voir ce qui s’applique à votre app.
08 — App Store
Prête pour la soumission ?
Les points qui font le plus souvent refuser ou retarder une première version, d’après les règles d’Apple.
Checklist de soumission App Store
09 — TestFlight
Faire tester avant de publier
- Testeurs internes
- Jusqu’à 100 membres de votre équipe App Store Connect, sans validation préalable.
- Testeurs externes
- Jusqu’à 10’000 personnes, par email ou lien public. Le premier build envoyé à des externes peut nécessiter une validation par Apple.
- Durée
- Chaque build est testable 90 jours.
- Délais de validation
- Apple indique examiner au moins 50 % des soumissions en moins de 24 heures et 90 % en moins de 48 heures.
10 — Après le lancement
Une app publiée est un produit à faire vivre
- Lire les rapports de plantage chaque semaine au début, puis à chaque version.
- Répondre aux avis et classer les retours : bug, confusion, demande de fonction.
- Mesurer le parcours principal sans collecter plus que nécessaire — et le déclarer dans les détails de confidentialité.
- Recompiler et retester à chaque version majeure d’iOS ; suivre la page des exigences à venir d’Apple.
Questions fréquentes
Combien coûte le développement d’une app iOS ?
Cela dépend du nombre d’écrans, d’un serveur éventuel, des comptes, des paiements et des fonctions système. Bynilson ne publie pas de prix pour les apps natives et n’en invente pas. Les frais fixes connus : l’Apple Developer Program, 99 USD par année d’adhésion (ou monnaie locale). Le constructeur de projet produit un brief à faire chiffrer par des studios iOS.
Peut-on créer une app iPhone sans savoir coder ?
Certains outils sans code produisent des apps mobiles ; vérifiez ce qu’ils génèrent (une simple page web emballée risque un refus, règle 4.2) et que vous pouvez récupérer vos données. Pour apprendre, les tutoriels « Develop in Swift » d’Apple partent de zéro.
SwiftUI ou React Native ?
SwiftUI si l’iPhone est la cible principale ou si l’app dépend des fonctions du système. React Native (souvent avec Expo) si vous visez iOS et Android ensemble avec une équipe à l’aise en TypeScript. Flutter si vous voulez la même interface partout. Le tableau plus haut détaille les compromis.
Comment publier une app sur l’App Store ?
Adhérez à l’Apple Developer Program, créez la fiche dans App Store Connect, envoyez un build depuis Xcode 26 ou plus récent, remplissez les détails de confidentialité et les captures, testez avec TestFlight, puis soumettez à la validation. La checklist de cette page couvre les points qui font refuser une première version.
À quoi sert TestFlight ?
À faire tester une version avant de la publier : jusqu’à 100 testeurs internes et 10’000 externes, chaque build testable 90 jours. Le premier build envoyé à des testeurs externes peut nécessiter une validation par Apple.
Faut-il un Mac ?
Pour une app native, oui : Xcode ne fonctionne que sur Mac. Avec React Native et Expo, un service hébergé peut compiler l’app iOS, mais il faut toujours un compte Apple Developer pour publier.
Bynilson peut-il développer mon app iOS ?
Non, Bynilson ne réalise pas d’apps mobiles natives. Vous pouvez construire avec un accompagnement écrit, étudié au cas par cas (décrire votre projet), ou confier le brief du constructeur à un studio iOS — le guide recruter ou externaliser aide à choisir.
Mon app sera-t-elle acceptée ?
Personne d’autre qu’Apple ne peut le dire. La checklist réduit les refus évitables ; un refus cite une règle précise, que l’on corrige avant de soumettre à nouveau.
Sources
- Documentation SwiftUIAppleVérifié le 23 oct. 2026
- Observation (@Observable)AppleVérifié le 23 oct. 2026
- NavigationStackAppleVérifié le 23 oct. 2026
- SwiftDataAppleVérifié le 23 oct. 2026
- Authentication Services (connexion)AppleVérifié le 23 oct. 2026
- StoreKit (achats intégrés)AppleVérifié le 23 oct. 2026
- User NotificationsAppleVérifié le 23 oct. 2026
- WidgetKitAppleVérifié le 23 oct. 2026
- Core LocationAppleVérifié le 23 oct. 2026
- Keychain Services (trousseau)AppleVérifié le 23 oct. 2026
- Swift TestingAppleVérifié le 23 oct. 2026
- Concevoir pour iOSAppleVérifié le 23 oct. 2026
- Lancer son app sur simulateur ou appareilAppleVérifié le 23 oct. 2026
- Tutoriels « Develop in Swift »AppleVérifié le 23 oct. 2026
- Tutoriels SwiftUIAppleVérifié le 23 oct. 2026
- URLSession (appels réseau)AppleVérifié le 23 oct. 2026
- Détails de confidentialité sur l’App StoreAppleVérifié le 23 oct. 2026
- Aide App Store ConnectAppleVérifié le 23 oct. 2026
- TestFlight — vue d’ensembleAppleVérifié le 23 oct. 2026
- Distribuer son app (bêta et versions)AppleVérifié le 23 oct. 2026
- Règles de validation de l’App Store (App Review Guidelines)AppleVérifié le 23 oct. 2026
- Récupérer les rapports de plantageAppleVérifié le 23 oct. 2026
- Exigences à venir (SDK, Xcode)AppleVérifié le 23 oct. 2026