sentry-cocoa: crash reporting for every Apple platform, with one caveat

One SDK across the Apple platforms, and the footnote on watchOS

sentry-cocoa is the official Sentry SDK for iOS, tvOS, macOS, watchOS, iPadOS and visionOS, and the project description makes a point of covering the whole family rather than just the phone. The target user is an Apple developer who wants error and crash reporting in their app and does not want to maintain a different integration per platform. The cost of that coverage is stated in a footnote under the platform list, where watchOS is marked as having limited symbolication support and no crash handling. That is a real constraint rather than a caveat to be waved away, because symbolication without crash handling means the SDK can help you read stack traces you already have but will not deliver you the crash itself. The main branch is the latest development version of the v9 release, and the v8.x branch holds the previous line, so a team on v8 has a documented upgrade target rather than a rewrite. The current release is 9.30.2 from 2026-10-14, and the last push to the repository was on 2026-10-19.

The wizard, SPM and XCFrameworks, and the end of CocoaPods

Installation has three routes and one removal. The recommended one is a command line wizard that patches your project and configures the SDK automatically:

brew install getsentry/tools/sentry-wizard && sentry-wizard -i ios

The second is Swift Package Manager, either by adding the repository in Xcode under File > Add Packages, or by declaring the dependency in Package.swift:

dependencies: [
    .package(url: "https://github.com/getsentry/sentry-cocoa", from: "9.24.0"),
],
targets: [
    .target(name: "YourApp", dependencies: [
        .product(name: "SentrySPM", package: "sentry-cocoa"),
    ]),
]

The third is pre-built XCFrameworks, either through the separate sentry-apple-binaries repository for static binaries via SPM, or downloaded directly from the GitHub releases, and the full installation docs cover Objective-C, dynamic linking and manual install. The removal is the one that will cause work. The README states that CocoaPods support has been dropped, that the last version available that way is 9.19.1, and asks you to migrate to SPM or XCFrameworks. For a project still on a pod-based dependency workflow, that is a migration with a floor on the version you can move to.

Initialization is a closure, in Swift or Objective-C

The SDK is started with a configuration closure, and the guidance is to call it as early in the application life cycle as possible, ideally in applicationDidFinishLaunching in the AppDelegate. In Swift the shape is a static start method taking a block that configures the options:

import Sentry

// ....

SentrySDK.start { options in
    options.dsn = "___PUBLIC_DSN___"
    options.debug = true // Helpful to see what's going on
}

The Objective-C interface mirrors it, using a startWithConfigureOptions block and Objective-C property assignment for the DSN and the debug flag. The debug flag is described as helpful to see what is going on, which is the sort of setting a developer will want off in production and on while integrating. The two-language surface is not an accident of history but a product decision, since the SDK is written in Swift with an Objective-C interface, and the topics list both languages. For an existing Objective-C codebase, that means the modern SDK is still usable without a rewrite.

Logging integrations are separate packages on purpose

The SDK forwards logs from popular logging libraries into Sentry Logs, and the design choice here is worth noticing: each integration is a separate Swift package, so you only pull in the dependencies you actually use. The list covers swift-log with the sentry-apple-swift-log package, CocoaLumberjack with sentry-apple-cocoalumberjack, Pulse with sentry-apple-pulse, and SwiftyBeaver with sentry-apple-swiftybeaver. The reasoning is the same one that governs the rest of the repository's packaging decisions. A crash reporting SDK that is already in your app's process is not a place to add a second logging abstraction, so the SDK offers integrations that forward to its own logs feature rather than asking you to replace the logger you already have. It also keeps the dependency graph small for teams that do not want a logging bridge at all.

The repository shows a serious release process

The tree is what a well-run SDK repository looks like, and it tells you more about maintenance than the README does. There is Package.swift plus [email protected] and [email protected], which is how a Swift package supports multiple Swift language versions, and an Sentry.xcodeproj and Sentry.xcworkspace for the Xcode side. Sources/ holds the SDK, Tests/ and SentryTests/ hold the test suite, SentryTestUtils/ and SentryTestUtilsDynamic/ are test helper packages, and TestApps/ contains applications used for testing. There is a 3rd-party-integrations/ directory, a distribution/ directory, a schema/ directory and linters/, plus .swiftlint.yml for linting and .clang-format for the Objective-C parts. The release process is visible too, with a .craft.yml for release automation and fastlane/ for distribution. A Makefile wraps the developer commands and pins the simulator matrix, with an iOS simulator OS defaulting to 18.4 and the device to iPhone 16 Pro, a tvOS device named Apple TV, a visionOS device named Apple Vision Pro and a watchOS device named Apple Watch SE 3 (44mm), each overridable through environment variables. MIGRATION.md and two changelogs, CHANGELOG.md and CHANGELOG_V10.md, are the documents to read before a version bump.

Where the SDK is the wrong choice

The main limit is the platform coverage of the crash pipeline itself, since watchOS gets symbolication but no crash handling, so a team shipping a watch app cannot rely on this SDK to deliver crash reports. The second is the packaging migration, because a project that has standardised on CocoaPods cannot simply add a version, it has to change its dependency workflow, and the last pod-installable release is 9.19.1, so anything you want from the v9 line requires SPM or XCFrameworks. The third is the version arithmetic. The main branch tracks the v9 development line while a separate v8.x branch carries the previous release, so pinning means choosing a tag and accepting that a major version change will involve reading MIGRATION.md rather than bumping a number. The fourth is the general shape of a hosted service SDK. The library is MIT licensed and open, but the DSN points at a Sentry project, so the value of the SDK is bound to the service, and the self-hosted option carries the operational cost of running that service yourself. Nothing in the repository suggests the SDK is useful without a Sentry project behind it.

Editorial conclusion

Adopt sentry-cocoa if you ship Apple software and want crash and error reporting with a single SDK across iOS, iPadOS, tvOS, macOS, watchOS and visionOS, and you are willing to move off CocoaPods. Do not adopt it if you depend on CocoaPods, since support has been dropped and the last available version is 9.19.1, and do not expect crash handling on watchOS, which the project limits to symbolication support. Before you upgrade, read MIGRATION.md and the CHANGELOG, and check which platform you actually target against the SDK version you plan to pin.

Frequently asked questions

Official sources

1. getsentry/sentry-cocoa on GitHub
2. License: MIT
3. Project website
4. README
5. Releases