Architecture des SDK
Un Core, des produits : comment les SDK appwin sont construits, sur les quatre plateformes
Les SDK appwin permettent à un studio d'intégrer les produits appwin (Analytics, Support, Community, Notifications) dans ses apps mobiles. Cette page explique comment ils sont organisés ; chaque produit a ensuite sa propre page pour le détail de ce qui se passe sous le capot.
L'idée centrale : un Core, des produits
Tout repose sur une brique fondation, Core (AppwinCore), qui porte ce que
tous les produits partagent : l'identité du device, la session serveur, le
client HTTP, la disponibilité des produits. Chaque produit est une façade
posée sur Core : une petite API publique (AppwinAnalytics,
AppwinSupport...) qui expose le produit, pendant que la mécanique vit dans
Core ou dans le module du produit.
Deux règles en découlent, valables partout :
- Jamais d'API produit sur
AppwinCore. Core est une fondation, pas un produit : si une méthode concerne un produit, elle vit sur sa façade. - Un produit non adopté n'existe pas. Tant que l'app n'appelle pas le
initialize()d'un produit, rien de ce produit ne tourne : pas de capture, pas de mémoire, pas de réseau.
Les quatre plateformes, un seul modèle
Le même découpage existe sur chaque plateforme, avec un miroir strict entre iOS et Android : toute constante ou comportement modifié d'un côté doit l'être de l'autre. Flutter et React Native sont des ponts au-dessus du natif.
| Plateforme | Dépôt | Forme |
|---|---|---|
| iOS | sdk/appwin-ios | un paquet SPM, un produit par module (AppwinCore, AppwinAnalytics...) |
| Android | sdk/appwin-android | un module Gradle par artefact (io.appwin:appwin-core, io.appwin:appwin-analytics...) |
| Flutter | sdk/appwin-flutter | ponts sur le natif |
| React Native | sdk/appwin-react-native | ponts sur le natif |
Le studio n'ajoute que ce qu'il utilise : une app qui n'a que l'Analytics ne linke ni le messenger du Support ni le SDK TikTok.
Le démarrage : configure puis initialize
AppwinCore.configure() est 100 % local : il pose l'identité du device et
la configuration, sans aucun appel réseau ni ligne créée en base. C'est chaque
produit qui, par son initialize(), interroge le serveur : l'availability
répond si le produit est actif pour cette app (plan de l'org + toggle dans le
dashboard). Refus = le produit reste inerte.
La session serveur (le bearer que portent tous les appels) est ouverte paresseusement par le premier appel qui en a besoin. Un 401 en cours de route déclenche une réouverture unique puis un retry - le motif est partagé par tous les composants qui parlent au serveur.
Ce que Core fournit aux produits
- Identité : un UUID stable par device, persisté ; le rattachement à un
customer se fait par
identify(). - Session : ouverture, renouvellement sur 401, un seul appel réseau même si plusieurs composants la demandent en même temps.
- Client HTTP (
ApiClient/ClientApi) : headers canoniques, seam de test. - Availability : le verdict serveur par produit, mis en cache par app.
- Consentements : le consentement analytics (opt-out) et le consentement advertising (opt-in) - deux finalités, deux interrupteurs (détail dans la page attribution).
- Point d'extension ad-signals : la découverte des adapters réseaux optionnels (TikTok), sans code côté studio.
Les pages produit
- Analytics : le pipeline d'événements, de
track()à ClickHouse. - Attribution : les signaux d'acquisition (conversion values SKAN, référent Play, identité publicitaire, adapter TikTok).
- Support, Community, Notifications : à écrire.