iOS SDK Troubleshooting

Issues during setup

  1. In the console, look for an Assert log with the message - "App Center SDK configured successfully". This verifies that the SDK is configured successfully.
  2. If you are using Cocoapods to integrate App Center in your iOS app and run into an error with the message - CocoaPods - Unable to find a specification for AppCenter, run pod repo update to update your local Cocoapods repository and then run pod install again.
  3. If you are manually integrating the SDK binaries, make sure you have modules enabled for your project.

Analytics data doesn't show up in the portal.

  1. Make sure you have integrated the SDK modules correctly.

  2. Make sure the correct App Secret is included along with the start:withServices: method call. You can copy the exact start:withServices:-code by opening the app in the portal and navigating to Getting Started page.

  3. If you want to see the logs that get sent to the backend, change the log level to Verbose in your application and the SDK will print logs in the console. Call the API below before you start the SDK.

    [MSAppCenter setLogLevel:MSLogLevelVerbose]
    
    MSAppCenter.setLogLevel(.verbose)
    

    Check the logs say "App Center SDK configured successfully" (in Info log level), then check if you see HTTPS request logs.

  4. Make sure your device is online.

  5. At times, logs might take few minutes to surface in the portal. Please wait for some time if that’s the case.

  6. To check if App Center backend received your data, go to the Log flow section in Analytics service. Your events should appear once it has been sent.

Crashes don't show up in the portal.

  1. Make sure you have integrated the SDK modules correctly.

  2. Make sure correct App Secret is included along with the start:withServices: method call. You can copy the exact start:withServices: code by opening the app in the portal and navigating to Getting Started page.

  3. You need to restart the app after a crash and App Center Crashes will forward the crash log only after it is restarted. Also, the SDK will not forward any crash log if you are attached to the debugger. Make sure the debugger is not attached when you crash the app.

  4. If you want to see the logs that get sent to the backend, change the log level to Verbose in your application and the SDK will print logs in the console. Call the API below before you start the SDK.

    [MSAppCenter setLogLevel:MSLogLevelVerbose]
    
    MSAppCenter.setLogLevel(.verbose)
    

    Check the logs say "App Center SDK configured successfully" (in Info log level), then check if you see HTTPS request logs.

  5. Don't use any other library that provides Crash Reporting functionality. You can only have one crash reporting SDK integrated in your app.

  6. Make sure your device is online.

  7. At times, logs might take few minutes to surface in the portal. Please wait for some time if that’s the case.

  8. If you want to check if the SDK detected the crash on the next app start, you can call the API to check whether the app crashed in the last session and shows an alert. Or you can extend the crash callback to see if it was successfully sent to the server.

  9. To check if App Center backend received the crash, go to the Log flow section in the Analytics service. Your crashes should appear there, once it has been sent.

The Alert that prompts users for an update doesn't contain strings, but just the keys for them.

This means that the AppCenterDistributeResources.bundle wasn't added to the project. Make sure you have drag'n'dropped the file into your Xcode project, and it appears in your app target's Copy Bundle Resources build phase. The later should be the case if you have added the file through drag'n'drop – Xcode does it automatically for you. If the file is missing from the build phase, add it so it gets compiled into your app's bundle.

If you are using Cocoapods, it takes care of the resources automatically. Try re-installing the pod.

You are seeing messages in the console that indicate that the database could not be opened

Starting with version 0.11.0 of the iOS SDK, App Center uses SQLite to persist logs before they are sent to the backend. If you are bundling your application with your own SQLite library instead of using the one provided by the OS, you might see errors like this in the console [AppCenter] ERROR: -[MSDBStorage executeSelectionQuery:]/147 Failed to open database and won't see any analytics or crash information in the backend. Please update the SDK to version 0.13.0 or later.

Distribute and in-app updates are blocking my automated UI tests

If you are running automated UI tests, enabled in-app updates will block your automated UI tests as they will try to authenticate against the App Center backend. We recommend to not enable App Center Distribute for your UI test target.

Why is the SDK distributed as a "static library"?

The primary design goals for the App Center SDK are to have a minimal impact on the app that is using App Center and to have a modular SDK. This would result in the SDK being distributed as several dynamic linked shared libraries. Historically, iOS didn't support dynamic linked shared libraries as Landon Fuller explains in a great blogpost but was added in iOS 8. Yet, App Center is distributed as a static linked shared library that is wrapped in a "fat" fake framework. It means that the SDK is linked at compile time and not at launch time. The reason is straight forward: performance. Loading multiple dynamic linked shared libraries takes time. Apple recommends to optimize app launch to take not more than 400ms in aWWDC session. They specifically recommend static shared libraries over dynamic shared ones to achieve this goal. Distributing the App Center SDK for iOS as a static linked shared library follows Apple's recommendation to provide the best performance and a minimal impact to the app that includes the SDK.

To learn more about static linked shared libraries vs. dynamic linked shared libraries, we recommend Apple's general documentation on the topic. To learn more about the performance impact of dynamic linked shared libraries, read Eric Horacek's blogpost.

Why are the SDK binaries "THAT" big? I am concerned about my app's size.

The AppCenter binaries are distributed as "fat" frameworks that contain slices for all iPhone architectures as well as for the iPhone simulator. This is why, e.g. AppCenter.framework is 10.5MB to download.

The compiled size of the SDK binaries will be much smaller than the .framework that you add to your app in Xcode. Also bear in mind that release builds will be smaller than debug builds, too.

To illustrate this, we have created an empty Objective-C application with Xcode 9.2, added the App Center binaries to the app, and distributed release builds to an iPhone 7 running iOS 11.3.

The tests were run without Bitcode enabled and did not use App Thinning. Those techniques can be used to shrink your app's binary size even more.

Please note that the numbers below can vary and depend on your build settings, so consider them a rough guide. That said, adding the App Center SDK to your app has a minimal impact on the size of your application binary.

App Center modules used Exported IPA size Installation size
None (blank app) 24KB 132KB
App Center Analytics 120KB 377KB
App Center Crash 239KB 705KB
App Center Distribute 163KB 528KB
App Center Push 115KB 377KB
All App Center modules 314KB 930KB