Firebase + XCode
Il est courant maintenant d’utiliser Firebase dans les applications mobiles. Que ce soit pour la partie statistiques, les notifications ou le reporting des crashes. L’intégration est très facile, mais peut devenir compliquée dès lors qu’on manipule des target différentes avec des configurations différentes. Cet article va vous détailler une façon simple mais efficace de gérer ces différences.
Multiples fichiers plist
Les fichiers plist sont des fichiers XML de configuration pour XCode.
Lors de la création d’un projet dans Firebase, il est possible de récupérer une version générée contenant les bonnes variables pour votre projet.
Le problème qui peut se produire est lorsqu’on génère plusieurs livrables avec des configurations qui doivent être différentes grace aux target.
Il n’est pas possible, ni confortable, de gérer le cas de plusieurs fichiers plist dans les sources.
La redéfinition du nom du fichier à faire utiliser par Firebase ne marche pas à tous les coups et il a tendance à aller lire la valeur par défaut GoogleService-Info.plist.
L’idée est donc d’utiliser un script au build qui se chargera de configurer correctement le fichier plist qui sera inclu dans le livrable.
Première étape : variabilisation
Pour être capable de générer le fichier plist correctement, il est nécessaire de le variabiliser.
Dans mon cas, j’ai identifié les valeurs suivantes qui devaient être variabilisées:
-
GOOGLE_APP_ID
-
BUNDLE_ID
-
CLIENT_ID
-
REVERSED_CLIENT_ID
J’ai donc ajouté des variables à la configuration de mon build pour représenter ces valeurs qui doivent être personnalisées.
J’utilise des fichiers .xcconfig mais ceci fonctionne également avec l’ajout manuel (dans Build Settings > + > Add User-Defined settings)
En plus de ça, j’ai modifié le fichier GoogleService-Info.plist téléchargé sur Firebase pour enlever les éléments qui allaient être remplacés à terme.
Plus exactement, j’ai remplacé les valeurs par des chaînes du type WILL BE REPLACED AT BUILD TIME, qui me permettent facilement de me rendre compte d’un oubli de configuration.
Deuxième étape : génération du fichier
Une fois le fichier et l’environnement préparé, il ne reste qu’à générer la version finale.
Pour se faire, je me base sur le système de build de XCode qui permet de définir simplement des étapes.
Les variables définies dans la configuration du projet sont en effet disponibles simplement lors de l’exécution des étapes de build.
En utilisant l’outil defaults inclu dans macOS pour la manipulation des fichiers plist, il est donc facile de définir les valeurs attendues dans le fichier.
J’ai ainsi rajouté une étape shell script correspondant à ceci dans le processus de build.
defaults write "${BUILT_PRODUCTS_DIR}/${PRODUCT_NAME}.app/GoogleService-Info.plist" GOOGLE_APP_ID ${GOOGLE_APP_ID}
defaults write "${BUILT_PRODUCTS_DIR}/${PRODUCT_NAME}.app/GoogleService-Info.plist" BUNDLE_ID ${PKG_IDENTIFIER}
defaults write "${BUILT_PRODUCTS_DIR}/${PRODUCT_NAME}.app/GoogleService-Info.plist" CLIENT_ID ${CLIENT_ID}
defaults write "${BUILT_PRODUCTS_DIR}/${PRODUCT_NAME}.app/GoogleService-Info.plist" REVERSED_CLIENT_ID ${REVERSED_CLIENT_ID}Enfin, il faut ordonner cette étape de build après celle de copie des ressources, pour effectuer la modification uniquement dans le fichier binaire de l’application et non dans les sources du projet.
Bénéfices
Il est donc facile de disposer de configuration différente de Firebase entre le debug et la release par exemple. Ainsi vous pouvez tester l’envoi de notification, par exemple, sans risquer de polluer des utilisateurs de production, ou activer le crash reporting uniquement en production par exemple.
