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
┌──────────────────────────────────────────────────────┐
│ 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-nativeest 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 | |
|---|---|
| iOS | 16.0 |
| Swift | 6.0 (SDK compilé en mode concurrence stricte) |
| Android | 7.0, API 24 |
| Kotlin | 2.1, JDK 17 pour la compilation |
| React Native | 0.73+ |
| Flutter | 3.3+ |
| Dart SDK | 3.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
- Installation
- Identité
- Community - le premier produit à brancher