Pourquoi nous avons construit pour Apple : confidentialité, sécurité et confiance

Lorsque nous nous sommes lancés dans la construction de KinArchive, nous avions un choix fondamental : utiliser des frameworks multiplateformes pour atteindre le plus large public le plus rapidement, ou construire en natif pour un seul écosystème qui correspondait à nos valeurs. Nous avons choisi Apple—et cet article explique pourquoi.

KinArchive est construit à 100 % sur les technologies Apple. Pas de React Native. Pas de Flutter. Pas de vues web Electron. Du Swift pur, SwiftUI, CloudKit et les frameworks iOS natifs qu'Apple fournit. Voici le raisonnement technique et philosophique derrière cette décision.

L'architecture de confidentialité

Les documents familiaux sont parmi les données les plus sensibles que les gens possèdent. Passeports, dossiers médicaux, polices d'assurance, testaments—ce ne sont pas des photos ou des notes. La mauvaise gestion de ces données n'est pas seulement une violation de la confidentialité ; cela pourrait permettre le vol d'identité, la fraude à l'assurance, ou pire.

Nous avions besoin d'une architecture où :

• Les données utilisateur ne touchent jamais nos serveurs
• Nous ne pouvons pas accéder aux documents utilisateur même si nous le voulions
• Les utilisateurs n'ont pas à nous faire confiance—ils doivent seulement faire confiance à Apple

Base de données privée CloudKit

Lorsque vous utilisez KinArchive, vos documents sont stockés dans VOTRE compte iCloud, utilisant VOTRE quota de stockage iCloud, chiffrés avec VOTRE identifiant Apple. Nous n'avons pas de serveur avec vos documents. Nous n'avons pas de sauvegardes de base de données de vos fichiers sensibles. Nous ne pouvons littéralement pas accéder à vos données.

Ce n'est pas un choix de politique—c'est une contrainte architecturale. La base de données privée est chiffrée de bout en bout, et seuls les appareils authentifiés de l'utilisateur peuvent la déchiffrer.

Aucune analyse tierce

De nombreuses applications incluent des SDK d'analyse tiers qui suivent le comportement des utilisateurs et envoient des données à des services externes. Ces SDK collectent souvent plus que les développeurs ne le réalisent—identifiants d'appareil, données de localisation, modèles d'utilisation.

KinArchive n'inclut aucune analyse tierce. Nous n'utilisons pas Firebase Analytics, Mixpanel, Amplitude ou tout autre service de suivi. Les seules analyses que nous recevons sont les métriques agrégées et anonymisées de l'App Store d'Apple.

Sécurité biométrique : Face ID et le Secure Enclave

KinArchive utilise Face ID (ou Touch ID sur les appareils plus anciens) pour l'authentification. Mais qu'est-ce que cela signifie techniquement ?

Le Secure Enclave

Les appareils Apple contiennent un processeur de sécurité dédié appelé le Secure Enclave. Il s'agit d'une puce séparée avec sa propre mémoire chiffrée, isolée du processeur principal. Vos données biométriques—la représentation mathématique de votre visage ou empreinte digitale—ne quittent jamais le Secure Enclave.

C'est fondamentalement différent des applications qui implémentent leur propre scan biométrique. Nous ne traitons, ne stockons ni ne transmettons aucune information biométrique. Nous demandons simplement à iOS : « Est-ce l'utilisateur autorisé ? » et iOS nous dit oui ou non.

Traitement des paiements : StoreKit 2

KinArchive propose des plans d'abonnement via l'App Store. Nous utilisons StoreKit 2, le dernier framework d'achat intégré d'Apple.

Ce que cela signifie pour vos données de paiement

Remarquez ce qui manque : nous ne voyons jamais votre numéro de carte de crédit, votre adresse de facturation ou vos détails de paiement. Apple gère toute la transaction. Nous recevons un reçu cryptographiquement signé qui prouve que vous avez un abonnement valide—rien de plus.

C'est le modèle standard de l'App Store d'Apple, mais il vaut la peine de souligner : pour une application gérant des documents familiaux sensibles, ne jamais toucher aux données de paiement est une propriété de sécurité importante.

Pourquoi le natif compte

Les frameworks multiplateformes comme React Native et Flutter permettent aux développeurs d'écrire du code une fois et de le déployer sur plusieurs plateformes. Ils sont populaires pour de bonnes raisons—développement plus rapide, bases de code partagées, coûts réduits.

Mais pour une application axée sur la sécurité gérant des documents sensibles, le développement natif offre des avantages critiques :

Accès direct aux API de sécurité

Les frameworks multiplateformes enveloppent les API natives dans des couches d'abstraction. Ces couches peuvent introduire des bugs, prendre du retard sur les mises à jour du système d'exploitation et parfois exposer des vulnérabilités de sécurité qui n'existeraient pas dans le code natif.

En construisant en natif, nous avons un accès direct à :

• LocalAuthentication : Face ID/Touch ID avec intégration complète du Secure Enclave
• Security.framework : Services Keychain pour le stockage des identifiants
• CloudKit : Intégration directe avec le chiffrement iCloud
• CryptoKit : Bibliothèque de cryptographie native d'Apple

Aucune vulnérabilité de pont JavaScript

Les applications React Native communiquent entre JavaScript et le code natif via un « pont ». Ce pont a historiquement été une source de vulnérabilités de sécurité—injection JavaScript, détournement de pont, fuite de données via la couche de pont.

KinArchive n'a pas de JavaScript, pas de pont, pas de vues web. C'est du code Swift compilé s'exécutant directement sur l'appareil.

Optimisations au niveau du système d'exploitation

Les applications natives bénéficient d'optimisations au niveau du système d'exploitation que les applications multiplateformes ne peuvent pas pleinement exploiter :

• Actualisation en arrière-plan : Intégration appropriée avec la gestion de l'alimentation iOS
• Gestion de la mémoire : L'ARC de Swift fonctionne parfaitement avec la gestion de la mémoire iOS
• Performance au lancement : Aucune surcharge d'initialisation de framework
• Intégration de widgets : WidgetKit natif pour les alertes d'expiration sur l'écran d'accueil

L'interface SwiftUI

L'interface utilisateur de KinArchive est entièrement construite en SwiftUI, le framework déclaratif moderne d'Apple. Cela signifie :

• Accessibilité automatique : Support VoiceOver, Dynamic Type et autres fonctionnalités d'accessibilité fonctionnent immédiatement
• Apparence et sensation natives : Boutons, navigation et interactions correspondent aux conventions iOS
• Mode sombre automatique : Les paramètres d'apparence du système sont respectés automatiquement
• Performance : SwiftUI est optimisé pour les pipelines de rendu iOS

Ce que nous avons échangé

Construire en natif pour Apple n'était pas sans coûts :

• Pas de version Android : Nous ne pouvons pas servir les utilisateurs Android (encore)
• Pas d'application web : Les utilisateurs de bureau ne peuvent pas accéder aux documents depuis un navigateur
• Coûts de développement plus élevés : Le développement natif prend plus de temps que le multiplateforme
• Marché adressable plus petit : iOS représente ~27 % du marché mobile mondial

Nous avons fait ces compromis consciemment. Pour une application gérant des documents familiaux sensibles, nous croyons que les propriétés de sécurité et de confidentialité de l'écosystème Apple l'emportent sur la portée des approches multiplateformes.

L'alignement avec l'écosystème Apple

Construire pour Apple ne concerne pas seulement la technologie—c'est une question d'alignement des valeurs.

Apple a misé sa marque sur la confidentialité. « La confidentialité est un droit humain fondamental » n'est pas seulement du marketing ; cela se reflète dans les décisions architecturales tout au long d'iOS : Transparence du suivi des applications, Étiquettes nutritionnelles de confidentialité, traitement sur appareil pour Siri et Photos, et le Secure Enclave.

Lorsque vous utilisez KinArchive, vous étendez la confiance à deux entités : nous (pour la logique de l'application) et Apple (pour la plateforme). En construisant entièrement sur les technologies Apple, nous minimisons la surface de confiance. Vos données restent dans l'écosystème Apple, protégées par le modèle de sécurité d'Apple, chiffrées avec la cryptographie d'Apple.

Nous ne vous demandons pas de faire confiance à un fournisseur cloud tiers, une entreprise d'analyse tierce ou un processeur de paiement tiers. Nous vous demandons de faire confiance à Apple—ce que vous faites déjà en utilisant un iPhone—et à nous pour la logique d'application qui s'exécute par-dessus.

Protection contre l'obsolescence

La plateforme Apple continue d'évoluer. En construisant en natif, nous pouvons adopter de nouvelles technologies dès leur sortie :

• Nouvelles fonctionnalités de sécurité : À mesure que la sécurité iOS s'améliore, KinArchive hérite de ces améliorations
• Nouvelles API : Accès direct aux nouveaux frameworks sans attendre le support multiplateforme
• Améliorations de performance : Les optimisations Swift et iOS nous profitent automatiquement
• Nouveaux appareils : iPad, Mac (via Catalyst ou natif), intégration Apple Watch

Conclusion

Construire KinArchive pour Apple n'était pas le chemin le plus rapide ou le plus facile. Mais c'était le bon chemin pour une application confiée avec les documents les plus sensibles des familles.

Lorsque vous stockez votre passeport dans KinArchive, vous ne confiez pas vos données à un fournisseur cloud inconnu. Vous les stockez dans votre propre compte iCloud, chiffrées avec votre propre identifiant Apple, protégées par votre propre Face ID. Nous avons construit la couche de gouvernance—le suivi des expirations, les permissions, les journaux d'audit—au-dessus de la fondation de sécurité d'Apple.

C'est pourquoi nous avons construit pour Apple. C'est pourquoi vos données sont sûres.