In this page you'll learn what are the most common mistakes when implementing the Notificare library for iOS.

Misplaced App Keys

When implementing Notificare, the library configuration file (located at NotificareServices.plist) must contain the Application ID, Application Key and the Application Secret. Because APNS will use the sandbox servers when building directly from Xcode in the device and production servers when you distribute over-the-air, we strongly recommend you to create two apps in Notificare, one for development and another for production. This will make it easier to switch between environments. Please read more about the configuration file here.

In this page you'll learn what are the most common mistakes when implementing the Notificare library for iOS.

Switching to Production

Always check if the correct NotificareServices.plist is being included in your app. Whenever you build your app directly from Xcode in a device you will be using APNS sandbox servers so the app keys must target a Notificare DEV application. If you archive your application for Ad Hoc, App Store or Enterprise distribution you should make sure the app keys target a Notificare PROD application. Failing to set this correctly will prevent Notificare from sending notifications to the correct device tokens, since you will be registering invalid device tokens in Notificare.

Expired Certificates

Functionality like APNS and Loyalty, require certificates that have an expiration date to function properly. Notificare keeps track of these certificate's expiry date will send you reminders by email and web push notifications to the dashboard. Without valid certificates, Notificare will not be able to send notifications or generate passes rendering useless this functionality. Make sure you renew and upload these certificates to Notificare in time to avoid that these features stop working.

Conflicts with other libraries

When using the managed approach of our library, you may encounter conflicts with other libraries. The most common clash you may have is with Firebase Analytics. Because Firebase also proxies methods in your App Delegate to their own class you may experience weird behaviour with application:openURL:options: method of your delegate. When that is the case, you will have 2 options, you can disable Firebase App Delegate proxy, by setting the FirebaseAppDelegateProxyEnabled property to NO in your app's Info.plist or instead disable our App Delegate proxy by setting the property SWIZZLING_ENABLED to NO in the Notificare.plist and use our non-managed methods.

By default, our library will also collect all your application exceptions. But if you are using other libraries for this purpose, like Crashlytics, you might want to disable it by setting the property CRASH_REPORTING_ENABLED to NO in the NotificareOptions.plist.


When using the new SwiftUI App Lifecycle, the AppDelegate is not accessible unless an interceptor is specified. Our library needs to be configured in the didFinishLaunchingWithOptions method.

In the main entrypoint of your app, add an UIApplicationDelegateAdaptor.

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

    var body: some Scene {
        WindowGroup {

Create the AppDelegate.swift file and configure the library.

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

        // ...

        return true