Aller au contenu principal

iOS - Dépannage

Dans cet article, vous découvrirez les erreurs les plus courantes lors de l’implémentation de la bibliothèque Notificare pour iOS.

Activer les journaux de débogage​

Il arrive que le niveau de journalisation par défaut ne soit pas suffisant pour diagnostiquer certains problèmes.
Vous pouvez activer les journaux de débogage en ajoutant l’option suivante dans le fichier NotificareOptions.plist.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>DEBUG_LOGGING_ENABLED</key>
	<true/>
</dict>
</plist>

Gestion de l’état de l’application​

Les données importantes de l’application, telles que les informations sur l’appareil actuel et l’état des notifications push, sont stockées dans le UserDefaults standard.
Il est essentiel d’éviter de supprimer manuellement ces données, car cela pourrait provoquer des effets secondaires inattendus, en ramenant notamment l’application à un état partiellement réinitialisé.
Il est donc recommandé d’utiliser les fonctions appropriées en fonction de votre cas d’usage, telles que disableRemoteNotifications() ou unlaunch().

Clés d’application mal placées​

Lors de l’implémentation de Notificare, le fichier de configuration de la bibliothèque (fourni dans votre TransferBox) doit contenir les éléments suivants :

  • l’Application ID,
  • la Clé d’application (Application Key),
  • le Secret d’application (Application Secret).

Comme APNS utilise les serveurs sandbox lorsque vous construisez l’application directement depuis Xcode sur un appareil, et les serveurs de production lors d’une distribution OTA (Ad Hoc, App Store ou Enterprise),
il est fortement recommandé de créer deux applications dans Notificare : une pour le développement et une pour la production.
Cela facilite la gestion des environnements.
Pour en savoir plus, consultez cet article.

Passage à la production​

Vérifiez toujours que le fichier NotificareServices.plist correct est bien inclus dans votre application.
Lorsque vous construisez l’application directement depuis Xcode sur un appareil, vous utilisez les serveurs sandbox d’APNS : les clés d’application doivent alors pointer vers un compte DEV.
En revanche, si vous archivez l’application pour une distribution Ad Hoc, App Store ou Enterprise, vous devez vous assurer que les clés correspondent à un compte PROD.

Une mauvaise configuration à ce niveau empêchera l’envoi de notifications aux bons tokens d’appareils, car des tokens invalides seront alors enregistrés.

Certificats expirés​

Les notifications push nécessitent des certificats valides et non expirés pour fonctionner correctement.
Sans certificats valides, il sera impossible d’envoyer des notifications ou de générer des cartes, rendant cette fonctionnalité inutilisable.
Assurez-vous de renouveler vos certificats à temps et d’en informer les équipes Actito pour qu’elles puissent les mettre à jour et éviter toute interruption de service.

SwiftUI​

Lorsque vous utilisez le nouveau cycle de vie d’application SwiftUI, le AppDelegate n’est pas accessible, sauf si un intercepteur est spécifié.
Notre bibliothèque doit être configurée dans la méthode didFinishLaunchingWithOptions.

Dans le point d’entrée principal de votre application, ajoutez un UIApplicationDelegateAdaptor.

@main
struct SampleApp: App {
    // add the interceptor
    @UIApplicationDelegateAdaptor(AppDelegate.self) var appDelegate

    var body: some Scene {
        WindowGroup {
            ContentView()
        }
    }
}

Créez le fichier AppDelegate.swift et configurez la bibliothèque.

class AppDelegate: NSObject, UIApplicationDelegate {
    func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey : Any]? = nil) -> Bool {
        // Configure Notificare.
        Notificare.shared.configure()

        // ...

        return true
    }
}

Extension du service de notification​

Inclure la bibliothèque NotificareNotificationServiceExtensionKit via Cocoapods fonctionne comme prévu lorsque vous utilisez use_frameworks! dans votre fichier Podfile.

Cependant, inclure la bibliothèque en liaison dynamique entraîne deux erreurs possibles :

  • L’application échoue à la compilation si la bibliothèque est ajoutée à la cible principale mais pas à la cible de l’extension ;
  • Ou bien l’image sur l’écran verrouillé ne s’affiche pas si la bibliothèque est uniquement ajoutée à la cible de l’extension, car elle n’est alors pas intégrée dans l’application.

Dans l’état actuel, Cocoapods ne parvient pas à ajouter correctement la XCFramework comme framework dynamique lorsqu’elle est déclarée dans les deux cibles.
Pour contourner ce problème, nous vous recommandons d’utiliser Swift Package Manager pour inclure NotificareNotificationServiceExtensionKit dans votre application.

Capacité « Protection des données »​

Activer la capacité Protection des données pour votre application définira par défaut le niveau de protection des fichiers sur « complète ».
Cela a pour effet, entre autres, que le système restreindra l’accès à la base de données, ce qui est nécessaire au bon fonctionnement de nos bibliothèques.

Apple recommande d’appliquer une protection sécurisée uniquement aux fichiers contenant des données sensibles, plutôt que de l’activer pour l’ensemble de l’application.
Cependant, si vous choisissez malgré tout cette option, vous risquez de rencontrer des erreurs d’accès aux fichiers.

Comme nos bibliothèques nécessitent un accès à la base de données même lorsque l’appareil est verrouillé (ex. : pour traiter une notification entrante),
vous pouvez remplacer le niveau de protection des fichiers pour la base de données en activant l’option suivante dans votre fichier NotificareOptions.plist.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>OVERRIDE_DATABASE_FILE_PROTECTION</key>
	<true/>
</dict>
</plist>