Soumettre une app privacy-first à l'App Store : ce qu'ils ne vous disent pas

Il y a trois semaines, j'ai enfin cliqué sur "Submit for Review" pour Inner Gallery après des mois de développement. Ce n'était pas ma première soumission App Store, mais c'était ma première pour un coffre-fort photos privacy-first où toute la proposition de valeur repose sur le stockage local uniquement.

La préparation a révélé des défis qu'aucun guide générique ne couvre.

Les décisions Bundle ID comptent plus que vous ne le pensez

Ma plus grosse erreur initiale : j'ai commencé avec com.junglelabs.inner. Nom du studio en premier, convention développeur classique.

Trois mois avant la soumission, j'ai réalisé que c'était faux. Inner Gallery doit exister indépendamment de Jungle Labs. Si je vends l'app, la licence, ou rebrand simplement le studio, le bundle ID devrait rester stable.

J'ai migré vers io.innerapp.inner. Centré produit, future-proof. Changement simple dans Xcode, non ?

Raté.

La migration a nécessité :

• Nouvelle entrée App Store Connect from scratch
• Re-générer tous les certificats et profils de provisioning
• Mettre à jour les App Groups pour l'extension de partage
• Re-tester toutes les fonctionnalités device (auth biométrique, accès fichiers, communication inter-app)
• Nouvelles invitations TestFlight pour les bêta-testeurs

Leçon : choisissez votre bundle ID comme vous choisissez un nom de domaine. Produit d'abord, pas studio d'abord.

Privacy Manifests : plus qu'une case à cocher

Les exigences de privacy manifest d'Apple sont devenues obligatoires en 2024. Pour la plupart des apps, c'est une simple divulgation. Pour les apps de confidentialité, c'est tout votre différenciateur.

Mon fichier PrivacyInfo.xcprivacy :

<key>NSPrivacyCollectedDataTypes</key>
<array></array>
<key>NSPrivacyAccessedAPITypes</key>
<array>
    <dict>
        <key>NSPrivacyAccessedAPIType</key>
        <string>NSPrivacyAccessedAPICategoryUserDefaults</string>
        <key>NSPrivacyAccessedAPITypeReasons</key>
        <array>
            <string>CA92.1</string>
        </array>
    </dict>
</array>

Ce tableau vide NSPrivacyCollectedDataTypes ? C'est le point. Zéro collecte de données, zéro analytics, zéro tracking. Mais le prouver à l'équipe de review d'Apple a demandé plus de réflexion que prévu.

Le défi : comment démontrer que votre app fonctionne comme prévu quand votre fonctionnalité principale est que vous ne savez rien de la façon dont les utilisateurs l'utilisent réellement ?

Compatibilité iPad : l'exigence inattendue

La validation App Store a signalé qu'Inner Gallery manquait de support iPad. Je l'avais construite uniquement iPhone intentionnellement — les coffres-forts photos semblent plus personnels sur téléphone.

Mais les guidelines d'Apple sont claires : les nouvelles apps iOS doivent supporter toutes les familles de devices sauf s'il y a une limitation technique.

"Je n'ai pas designé pour iPad" n'est pas une limitation technique.

Ajouter le support iPad pour une app local-first a créé des problèmes spécifiques :

• Pas de sync signifie des silos de device : les photos importées sur iPhone restent sur iPhone
• Patterns d'interaction différents : le pinch-to-zoom fonctionne différemment sur tablette
• Surface d'écran : les grilles de photos qui marchent sur iPhone semblent vides sur iPad

Ma solution : embrasser la limitation. L'iPad devient un espace séparé, privé. Pas de sync requis si vous le positionnez comme du design de confidentialité intentionnel.

Code Signing pour apps de confidentialité

La signature de code standard fonctionne pour la plupart des apps. Les apps de confidentialité nécessitent une attention supplémentaire.

Ma configuration App Store Connect :

• Hardened Runtime : activé pour la compatibilité macOS Catalyst
• Signature automatique désactivée : contrôle manuel des entitlements
• App Groups configurés : requis pour la communication d'extension de partage
• Pas de CloudKit : intentionnellement exclu pour prévenir les dépendances cloud accidentelles

L'extension de partage a nécessité un soin particulier. Elle s'exécute dans un processus séparé et a besoin d'accès au stockage chiffré de l'app principale. Les App Groups fournissent le pont, mais la setup d'entitlement est fragile.

Échec commun : l'extension de partage se build mais ne peut pas communiquer avec l'app principale. Vous découvrez ça pendant les tests TestFlight, pas la simulation Xcode.

Pièges de Local Authentication

Inner Gallery utilise Local Authentication pour l'accès biométrique. Les apps de confidentialité touchent des edge cases spécifiques :

Le bug de double évaluation : iOS peut déclencher Face ID deux fois en succession rapide si vos événements background/foreground de l'app se chevauchent. Les utilisateurs voient Face ID, s'authentifient, puis le voient immédiatement à nouveau. Confus et cassé.

Mon fix : passer un LAContext persistant au lieu d'en créer de nouveaux :

private let authContext = LAContext()

func authenticateWithContext() async throws -> Bool {
    return try await authContext.evaluatePolicy(.deviceOwnerAuthentication, 
                                               localizedReason: "Accéder à votre espace privé")
}

Bypass biométrique pendant lockout : si un utilisateur entre un PIN incorrect de façon répétée, l'app le verrouille. Mais l'auth biométrique peut quand même se déclencher et réussir, bypassant le lockout. Trou de sécurité.

Solution : vérifier l'état de lockout avant d'offrir les options biométriques.

Stratégie de Review : mener avec la confidentialité

La plupart des apps optimisent les listings App Store pour la conversion. Les apps de confidentialité font face à un défi différent : communiquer la valeur sans pouvoir montrer de vraies données utilisateur.

Ma stratégie de review :

• Screenshots avec contenu démo : vraies vues de galerie, photos manifestement fausses
• Copy privacy-first : mener avec "stockage local uniquement" avant de lister les features
• Détails techniques clairs : mentionner CryptoKit, architecture no-network, zéro analytics
• Comparaison concurrents : comparaison honnête avec alternatives cloud

Le plus dur : démontrer des features sophistiquées sans données utilisateur sophistiquées. Les coffres-forts photos deviennent intéressants avec des centaines de photos. Les screenshots démo avec 3 images génériques ne transmettent pas l'expérience.

J'ai résolu ça avec des signaux de crédibilité technique : mentionner CryptoKit, spécifier les algorithmes de chiffrement (ChaCha20-Poly1305), linker vers la documentation d'architecture.

Ce que les guides génériques ratent

Les conseils standard de soumission App Store optimisent pour les apps mainstream avec architectures standard. Les apps privacy-first font face à des trade-offs différents :

Les analytics sont interdites : vous ne pouvez pas A/B tester les flux d'onboarding ou tracker l'usage des features. Les décisions de design reposent sur l'intuition et le feedback utilisateur.

Les dépendances cloud cassent votre proposition de valeur : les SDKs qui "phone home" contredisent les promesses local-first. Chaque intégration tierce nécessite un audit.

Le reporting d'erreur est limité : les crash reports vont bien, mais les analytics de comportement utilisateur violent les principes de confidentialité.

Le marketing devient plus dur : pas de données d'usage signifie pas d'optimisation de conversion, pas d'analyse de rétention, pas de métriques de funnel.

Dette technique pendant la soumission

Mon git log de la semaine de soumission finale :

feat: add privacy manifest and legal section for App Store submission
fix: resolve App Store validation errors for iPad compatibility  
refactor: migrate bundle ID from com.junglelabs to io.innerapp.inner
chore: add code signing and supported orientations for App Store submission

Chaque ligne représente des heures de travail qui n'existaient pas dans ma timeline originale. Dette technique cachée dans "juste soumettre à l'App Store."

Le plus gros time sink : la compatibilité iPad. Ce qui a commencé comme "ajouter des screenshots iPad" est devenu "redessiner la navigation pour les patterns d'interaction tablette."

Erreurs que j'ai faites (pour que vous ne les fassiez pas)

Commencer le bundle ID avec le nom du studio : plus dur à migrer plus tard, crée des dépendances business.

Retarder le support iPad : plus facile de designer universellement dès le début que de rétrofiter.

Supposer que les privacy manifests sont simples : ils sont votre différenciateur principal, pas une case de conformité.

Ne pas tester les extensions de partage sur device : le simulateur ne catch pas les problèmes d'entitlement App Group.

Builder uniquement pour les tailles d'écran iPhone : la compatibilité iPad nécessite de repenser les layouts, pas juste les étirer.

La suite

Inner Gallery est actuellement "In Review." La période d'attente donne le temps de préparer l'après-lancement : optimisation ASO, collecte de feedback utilisateur (via email, pas analytics), et planification de la première mise à jour.

Si vous construisez des apps privacy-first, le processus de soumission révèle des décisions de design que vous ne saviez pas que vous preniez. Stratégie bundle ID, philosophie de compatibilité device, storytelling privacy manifest — ces choix façonnent votre produit autant que les décisions de features.

Le processus de review App Store force la clarté. C'est précieux, même quand c'est frustrant.

Lectures connexes :

• Pourquoi j'ai construit Inner Gallery
• Apps Local-First : confidentialité par architecture
• Zéro dépendances : quand ça compte
• Construire des produits en parallèle

Découvrir Inner Gallery