SDK mobile - vue d'ensemble

Le principe

Toute l'UI est native et vit dans le SDK. Ton app fournit un point d'entrée - un onglet, un bouton - et le SDK dessine le reste : le fil, les commentaires, les profils, le messenger.

C'est le modèle Intercom. Il a une conséquence directe et assumée : tu ne composes pas les écrans. En échange, tu n'as ni à les maintenir, ni à les retraduire, ni à republier ton app quand une fonctionnalité évolue.

La personnalisation passe par le dashboard, pas par le code : couleurs, police, arrondis, fonctionnalités actives, longueurs maximales, modération. Le SDK relit sa configuration à chaque ouverture, donc un changement côté studio s'applique sans redéploiement.

Architecture

Texte brut
┌──────────────────────────────────────────────────────┐
│ Ton app (Swift / Kotlin / React Native / Flutter)    │
└───────────────┬──────────────────────────────────────┘
                │  configure(appId:) une fois
                ▼
┌──────────────────────────────────────────────┐
│         AppwinCore (Swift + Kotlin)          │
│    Identité appareil · session · réseau      │
└───────────────┬──────────────────────────────┘
                │  partagé
        ┌───────┴────────┬────────────────┐
        ▼                ▼                ▼
  AppwinCommunity   AppwinSupport   AppwinNotifications

AppwinCore porte ce qui est commun : l'identifiant d'appareil persisté, la session authentifiée, le client HTTP, le realtime. Il est la raison pour laquelle un configure unique suffit, et pour laquelle un end-user identifié l'est simultanément dans tous les produits.

Il existe en deux implémentations, Swift et Kotlin, avec le même contrat : mêmes noms de méthodes, mêmes en-têtes, mêmes garanties. Une équipe qui a intégré une plateforme n'a pas à réapprendre l'autre.

Une différence à connaître tout de même : le trousseau iOS survit à une désinstallation, donc l'identifiant d'appareil aussi. Rien n'offre cette garantie sur Android - le SDK y utilise des préférences chiffrées, incluses dans la sauvegarde automatique, donc l'identifiant revient après une réinstallation si la sauvegarde est active. Sinon l'utilisateur repart avec un nouveau profil anonyme.

Les modules produit en dépendent et n'ont aucune connaissance l'un de l'autre. Tu n'installes que ceux dont tu as besoin.

Ce que le SDK fait

  • Reconnaît l'appareil sans inscription, de façon stable dans le temps
  • Ouvre et renouvelle la session authentifiée, sans que tu manipules de jeton
  • Rend l'UI native, thémée depuis ton dashboard
  • Met en cache ce qu'il faut pour que le premier écran ne clignote pas
  • Applique les kill switches : une fonctionnalité désactivée côté studio disparaît de l'interface

Ce que le SDK ne fait pas

  • Aucune UI composable. Tu ne peux pas réarranger un écran ni injecter un composant. Si un écran ne convient pas, c'est une discussion produit, pas un paramètre.
  • Aucun stockage de données personnelles au-delà du nécessaire. Le SDK ne lit pas ton carnet d'adresses, ne pose pas de tracker publicitaire.
  • Aucun rendu React Native. Le paquet @appwin/react-native est un pont vers les SDK natifs, pas une réécriture : le fil et le messenger restent du SwiftUI et du Compose. Un troisième rendu des mêmes écrans divergerait des deux autres à la première évolution produit.

Versions minimales

Version
iOS16.0
Swift6.0 (SDK compilé en mode concurrence stricte)
Android7.0, API 24
Kotlin2.1, JDK 17 pour la compilation
React Native0.73+
Flutter3.3+
Dart SDK3.9.2+

Côté iOS, les modules se distribuent par Swift Package Manager, le gestionnaire d'Apple intégré à Xcode. Pas de CocoaPods : plus de Podfile à tenir à jour ni d'étape d'installation à part. Une cible de déploiement sous iOS 16 ne compile pas - le SDK utilise SwiftUI et async/await.

Côté Android, les modules sont des AAR Maven (io.appwin:appwin-core, appwin-support, appwin-community, appwin-notifications), bâtis sur Compose et Material 3.

React Native et Flutter passent par des paquets de pont - @appwin/react-native d'un côté, appwin_core plus appwin_support / appwin_community de l'autre - qui exposent les écrans natifs sans les réécrire. Les deux plateformes mobiles sont couvertes dans les deux cas.

Suite