Guide de démarrage iOS

En quelques minutes, votre app iOS lira un vrai feature flag — avec la mise en cache, le repli hors ligne et l’identité d’appareil gérés pour vous.

Requiert iOS 17, macOS 14 ou visionOS 1. Le SDK n’a aucune dépendance propre.

1. Installez

Le SDK vit dans un dépôt public sur GitHub — ajoutez-le directement depuis là comme un package Swift, dans Xcode (File → Add Package Dependencies…) ou dans Package.swift :

.package(url: "https://github.com/FortressFlag/FortressFlag_SDK_ios.git", from: "1.0.0")

2. Démarrez le SDK

Une fois, au lancement — pour SwiftUI, l’init de votre App est l’endroit naturel :

import FortressFlag

FortressFlag.start(
    Configuration(
        sdkKey: "ffc_prod_…",                          // depuis l’écran Clés SDK de votre projet
        environment: .production,
        keychainAccessGroup: "com.acme.fortressflag"   // la même chaîne dans chaque app que vous livrez
    )
)

start rend la main dès que les valeurs en cache sont chargées, et le SDK interroge les changements en arrière-plan à partir de là. La clé est une clé client — elle est embarquée dans votre app par conception.

3. Lisez un flag

N’importe où, y compris dans un body SwiftUI :

if FortressFlag.isEnabled("new-checkout") {
    NewCheckoutView()
} else {
    LegacyCheckoutView()
}

Les flags chaîne et nombre se lisent de la même façon — FortressFlag.stringValue("checkout-cta", default: "buy-now") — et vous pouvez observer les changements avec FortressFlag.onChange.

C’est tout — votre flag est en ligne. Basculez-le dans le tableau de bord et l’app suit lors de son prochain polling.

Si FortressFlag est en panne, votre app ne l’est pas

Aucun appel de cette API ne lève d’exception, ne bloque, ni ne peut faire planter votre app. Chaque lecture se résout par une cascade — les dernières valeurs reçues, puis le cache durable des exécutions précédentes, puis la valeur par défaut de votre point d’appel — de sorte qu’une panne, un réseau mort ou une clé révoquée n’atteint jamais vos utilisateurs.

Configurez le partage de trousseau — ne pas le faire vous coûte de l’argent

FortressFlag facture par appareil, pas par app. Un téléphone qui exécute trois de vos apps est un siège — mais seulement si les trois s’accordent sur une seule identité d’appareil, ce qui sur iOS signifie un groupe d’accès au trousseau partagé :

1. Dans chaque cible d’app : Signing & Capabilities → + Capability → Keychain Sharing.
2. Ajoutez le même groupe à chacune de vos apps — par exemple com.acme.fortressflag.
3. Passez cette chaîne (sans le préfixe d’équipe) comme keychainAccessGroup.

Sautez cette étape et tout fonctionne encore, mais chaque app stocke sa propre identité : un appareil compte comme trois appareils facturables. Le SDK journalise un avertissement une fois quand c’est le cas.

Une note de plateforme : l’identité vit dans le trousseau, donc sur iOS elle survit aux désinstallations de l’app — et elle n’est jamais synchronisée avec iCloud, donc elle ne voyage jamais dans une sauvegarde vers un second appareil.

Déboguer une intégration

Le package fournit une seconde bibliothèque, FortressFlagDebugUI, avec FlagListView — un écran SwiftUI montrant chaque flag que cet appareil détient, sa valeur et d’où elle vient, en direct. C’est la réponse la plus rapide à « est-ce que le SDK parle seulement au serveur ? ».

Où aller ensuite

• Comment les flags arrivent à votre app — ce que fait ce polling en arrière-plan
• Identité d’appareil et facturation — l’identité que vous venez de configurer
• Configurez un déploiement progressif — livrez d’abord à 10 %