# The App Center SDK for Apple is a modular client for analytics, crashes and distribution > The App Center SDK for iOS, macOS and tvOS is a collection of separate modules you can adopt one at a time, covering session analytics, crash reporting and in-app update distribution through a service-side API. It suits an Apple developer who wants App Center telemetry without adopting the whole service, and it is a client for a hosted backend that the repository does not contain. **microsoft/appcenter-sdk-apple** — Development repository for the App Center SDK for iOS, macOS and tvOS. - Repository: https://github.com/microsoft/appcenter-sdk-apple - Stars: 580 · Forks: 227 - Language: Objective-C - License: NOASSERTION - Published: 2026-10-22 · Updated: 2026-10-22 · Language: en - Canonical page: https://hysenlabs.com/projects/microsoft-appcenter-sdk-apple ## Three separate modules, and you take only the ones you want The SDK uses a modular architecture so you can use any or all of the listed services, and that phrase is the practical summary of how to adopt it. App Center Analytics helps you understand user behaviour and customer engagement, and the SDK automatically captures session count and device properties such as model and OS version, while custom events can be defined to measure what matters, with everything captured available in the App Center portal for analysis. App Center Crashes automatically generates a crash log every time the app crashes, the log is first written to the device's storage and sent to App Center when the user starts the app again, and collecting crashes works for both beta and live apps, meaning those submitted to the App Store. App Center Distribute lets users install a new version of the app when you distribute it, and the SDK presents an update dialog offering download or postpone, then starts the update once the user chooses. The three features are also three separate directories in the repository, AppCenterAnalytics/, AppCenterCrashes/ and AppCenterDistribute/, alongside the shared AppCenter/ core. ## Distribute is the module with the platform and distribution caveats App Center Distribute comes with two stated limitations that decide whether it is useful to you at all. The first is that this feature is automatically disabled on versions of your app deployed to the Apple App Store, so if your users install from the App Store the update dialog never appears. The second is that it is not available for macOS and tvOS, which the README marks with an asterisk. So the module that installs new builds over the air exists for iOS only, and only for builds distributed outside the App Store. That covers the beta and enterprise distribution case, which is where it earns its keep, and leaves App Store applications with nothing here. The other two modules have no such restriction, which is why the practical adoption pattern in most apps is Analytics and Crashes with Distribute left out. ## Crash reports are written to disk first and uploaded on the next launch The crash pipeline is worth understanding because it explains a behaviour people find surprising. The log is first written to the device's storage, and when the user starts the app again the crash report is sent to App Center. Nothing is uploaded at crash time, which is the right design, since the process is dying and the network may be gone. The visible consequence is that a crash that happens on the last run before the user closes the app for good is only reported the next time the app is opened, and the reports therefore lag the incident. The documentation also notes that crash logs contain valuable information to help fix the crash, which is the argument for enabling the module at all. The repository layout shows where the machinery lives, with a CrashLib/ directory for the crash handling code, a Sasquatch/ directory for the test application used in development, and SasquatchMac/ and SasquatchTV/ as the platform variants of that test app. ## The repository ships CocoaPods and SwiftPM packaging side by side Distribution of the SDK itself is set up two ways, which is what a modern Apple project has to do. There is an AppCenter.podspec at the top of the tree, and the README carries a CocoaPods badge pointing at the AppCenter pod, so the project is consumable through CocoaPods. There is also a Package.swift, so Swift Package Manager is supported, and the peer dependency of the pod and the package structure follow the modular layout, meaning a consumer can depend on one module rather than the whole SDK. A few other things in the tree are worth knowing about. The .azure-pipelines/ directory holds the build pipeline configuration, the Config/ directory holds build configuration, Scripts/ holds helper scripts including appcenter-post-clone.sh at the root, and Localization/ holds the localised strings for the SDK's own user interface. ThirdPartyNotices.txt and cgmanifest.json handle third party attribution, and there is a SECURITY.md alongside a CHANGELOG.md and a Documentation/ directory. ## Getting started is a documentation link, not a code sample The README is short and points outward for the actual setup, which tells you the onboarding lives on Microsoft's own documentation site rather than in the repository. The getting started documentation is at the App Center SDK getting started page for iOS, and the detailed documentation is a separate link, with the claim being that onboarding an app takes minutes. There is no code block in the repository readme showing the initialisation call, so the exact API for starting a service is something you have to look up rather than read off the page, and that is worth flagging for anyone evaluating quickly. The support path is also service-side rather than community-side. App Center SDK support is provided directly within the App Center portal, where a chat button in the lower-right corner of any page reaches the support team, with additional information in the App Center Help Center. The README notes the project is looking forward to contributions via pull requests. ## Contributing means signing a Microsoft contributor licence agreement The contribution terms are the part of the readme that is most likely to surprise an outside contributor. Beyond the Microsoft Open Source Code of Conduct, which is the standard one and points to its own FAQ, a Contributor License Agreement must be signed before submitting a pull request. The process is to submit a request through the CLA form and then electronically sign the agreement when the email with the document link arrives, and the README makes the scope clear by noting that the signature is needed only once to cover submission to any Microsoft open source project. That is a meaningfully different path from the permissive licence most community Apple libraries use, and it means the contribution barrier is a legal step rather than a code review one. The licence on the repository itself is marked MIT in the badge and in the LICENSE file, and the hosting metadata describes it as a custom licence that GitHub cannot classify, so the badge and the metadata disagree and the LICENSE file is the place to look. ## Where the App Center SDK is the wrong choice Three situations argue against it. The first is a team that needs to own its telemetry, because this SDK is a client for a hosted service and the repository contains no server component, so the option of running the backend yourself does not exist here. A self-hosted crash reporter or an open source analytics stack gives you that, at the cost of operating it. The second is a macOS or tvOS application that relies on over the air distribution, since Distribute is not available on those platforms and is disabled on App Store builds, so the feature set differs by target in a way the modular design makes explicit but does not solve. The third is an application with an existing telemetry setup, where adding a second analytics pipeline means two session models, two identifiers to reconcile and two privacy consent flows, which is a cost the modular design does not reduce. The realistic alternative is to use the SDK only for the one capability that is hard to build, which for most teams is crash reporting with symbolicated stacks, and to leave session analytics to whatever the app already sends. One more practical point: the test applications in the tree are still named Sasquatch, SasquatchMac and SasquatchTV, and the default branch is develop rather than master, so the published release is the thing to depend on. ## Conclusion Adopt the App Center SDK for Apple when you want App Center Analytics, Crashes and Distribute in an existing iOS, macOS or tvOS app and can pick only the modules you need, and skip it if you want a self-hosted crash reporter. Verify first which module you actually need, since Distribute is not available on macOS and tvOS and is disabled automatically on App Store builds, and note that the default branch is develop, so you should depend on a published release rather than the branch tip. ## FAQ ### What is the App Center SDK for Apple? It is the development repository for the App Center SDK for iOS, macOS and tvOS, and the SDK uses a modular architecture so you can use any or all of App Center Analytics, App Center Crashes and App Center Distribute. ### Which App Center services can I use independently? Any or all of them. App Center Analytics automatically captures session count and device properties and lets you define custom events, App Center Crashes writes a crash log to device storage and sends it on the next app start, and App Center Distribute presents an update dialog to users. ### Is App Center Distribute available on every Apple platform? No. The README states that the feature is automatically disabled on versions of your app deployed to the Apple App Store, and that it is not available for macOS and tvOS. It therefore only applies to iOS builds distributed outside the App Store. ### How do I add the App Center SDK to an Apple project? The repository ships both an AppCenter.podspec for CocoaPods and a Package.swift for Swift Package Manager, and the modular layout means you can depend on a single module. The README itself points to the getting started documentation for the initial setup, so the exact initialisation call is documented there rather than in the repository. ### Is the App Center SDK for Apple still maintained? The repository is not archived and the last push was on 2026-07-08, with the most recent releases being 5.12.1 on 2026-07-08, 5.12.0 on 2025-12-19 and 5.10.0 on 2025-11-24. The default branch is develop, the badge shows an MIT licence, and contributions require signing a Microsoft Contributor License Agreement. ## Sources - [Issues](https://github.com/microsoft/appcenter-sdk-apple/issues) - [microsoft/appcenter-sdk-apple on GitHub](https://github.com/microsoft/appcenter-sdk-apple) - [README](https://github.com/microsoft/appcenter-sdk-apple/blob/develop/README.md) - [Releases](https://github.com/microsoft/appcenter-sdk-apple/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/microsoft-appcenter-sdk-apple