A step-by-step guide to adding the Sentry Cocoa SDK to a Swift iOS app with Swift Package Manager and initializing it with your DSN so crashes and errors start flowing to your dashboard.
Before adding Sentry, make sure you have a few things in place. You need a working iOS app project in Xcode built with Swift or SwiftUI, and a recent version of Xcode. You also need a Sentry account, which you can create on the free developer tier, and within it a project configured for the Apple platform. When you create the project in Sentry, it generates a DSN, short for Data Source Name. The DSN is a URL that encodes your organization, project, and a public key, and it tells the SDK exactly where to send events. Keep that DSN handy; you will paste it into your initialization code. You do not need any special provisioning or entitlement changes to use Sentry, and you do not need to disable any Xcode features. Because the SDK ships events over the network, you should also confirm your app already has, or will request, standard outbound network access, which nearly every app has by default. It also helps to note your Sentry organization slug and project slug now, since you will reference them later when you automate debug symbol uploads. If you work in a team, decide early whether each developer uses their own Sentry login or a shared project, because that affects how you store the auth token used for those uploads. With those prerequisites met, the actual integration takes only a few minutes.
Swift Package Manager is the recommended way to add Sentry and requires no extra tooling. In Xcode, open your project, then go to File and choose Add Package Dependencies. In the search field at the top right of the dialog, paste the Sentry Cocoa repository URL, https://github.com/getsentry/sentry-cocoa. Xcode will resolve the package and show its available versions. Choose the dependency rule you prefer; pinning to Up to Next Major Version is a sensible default that picks up bug fixes without surprise breaking changes. Click Add Package, and when Xcode presents the list of package products, add the product named Sentry to your app target. For most apps that single product is all you need. If you use SwiftUI and want the optional SwiftUI performance instrumentation helpers, you may also see and add the SentrySwiftUI product, but it is not required for basic crash reporting. Xcode will fetch and link the package. Once resolution finishes, the SDK is available to import anywhere in your codebase.
If your project already uses CocoaPods rather than Swift Package Manager, integration is equally straightforward. Open your Podfile in the project root and add the Sentry pod to your app target, for example by adding a line reading pod 'Sentry'. If you want the SwiftUI helpers you can additionally add pod 'SentrySwiftUI'. Save the Podfile, then run pod install from the directory containing it in Terminal. CocoaPods will download the SDK, integrate it, and update your workspace. From that point forward, open the generated .xcworkspace file rather than the .xcodeproj so that the pods are linked correctly. Running pod update Sentry later will bring the SDK up to a newer version when you are ready. Whether you choose Swift Package Manager or CocoaPods makes no difference to how you write the initialization code; only the dependency mechanism differs. For new projects, Swift Package Manager is the simpler choice because it is built into Xcode and avoids managing a separate workspace and Podfile.
The SDK must be started as early as possible in your app's lifecycle so that it can install its crash handlers before anything else can crash. In a SwiftUI app, the natural place is the initializer of your App struct. Import the SDK with import Sentry, then call SentrySDK.start inside an init method. A minimal configuration looks like this: SentrySDK.start { options in options.dsn = "YOUR_DSN_HERE"; options.debug = true }. Replace the placeholder with the DSN from your Sentry project. Setting options.debug to true during development prints helpful logging to the Xcode console so you can confirm the SDK initialized and is sending events; turn it off for release builds. In a UIKit app, place the same SentrySDK.start call at the very top of application(_:didFinishLaunchingWithOptions:) in your AppDelegate, before any other setup. The key rule is placement: start Sentry first. If you initialize it late, crashes that happen during earlier startup work will not be captured because the handlers are not yet installed.
A bare DSN works, but a few extra options make the data far more useful. Set options.environment to a string like "production", "staging", or "development" so you can filter events by where they came from and avoid mixing test noise with real user data. The SDK automatically infers your release from the app's version and build number, but you can override options.releaseName if you use a custom versioning scheme. If you plan to use performance monitoring, set options.tracesSampleRate to a value between 0.0 and 1.0; a value like 0.2 captures twenty percent of transactions, which keeps event volume and cost under control while still giving you representative data. You can leave it unset or at 0.0 if you only want crash and error reporting for now. There are many additional options for attaching stack traces to non-fatal messages, controlling breadcrumbs, and scrubbing sensitive data. Start minimal, confirm events arrive, then layer in configuration deliberately rather than enabling everything at once.
Once the SDK is initialized, verify it end to end before assuming you are done. The quickest check is to capture a test message: somewhere that runs on launch, call SentrySDK.capture(message: "Test event from setup"). Run the app on a simulator or device, then open your Sentry project dashboard and look under Issues. Within a short time the test event should appear, confirming that your DSN is correct and events are reaching Sentry. To test actual crash capture, you can deliberately trigger a crash, for example with fatalError("Sentry test crash"), but there is an important catch: when the Xcode debugger is attached it intercepts crashes before Sentry can handle them, so the event may not be sent. Run the crash test with the app launched independently, not from Xcode's run button, or detach the debugger. After a crash, the event is usually sent on the next app launch because the SDK flushes stored crash reports at startup. Seeing both a message event and a crash event confirms the integration is healthy. One more sanity check is worth doing: confirm the event you see carries the environment and release you expect, not a stale value from an earlier test. If the release shows as unknown, the SDK could not read your version and build number, which is worth fixing before you rely on release health.
With events flowing, the most important follow-up is dSYM symbolication. Right now your crash traces will contain raw memory addresses rather than function names until you upload your debug symbol files, so setting up an automated dSYM upload with sentry-cli, an Xcode build phase, or the Fastlane plugin should be your next task. After that, consider enriching events with user context by calling SentrySDK.setUser, adding custom tags and breadcrumbs around important user actions, and wiring up alert rules in the Sentry dashboard so your team is notified when a new issue appears or a crash spikes. If you want latency insight, enable performance tracing and, for SwiftUI, add view transaction tracking. Finally, before shipping, review what data you are sending and update your app's privacy disclosures accordingly, since crash and performance events include device and usage context. Basic integration is quick, but these follow-ups are what turn Sentry from a raw event pipe into a genuinely useful production monitoring setup for your Swift app.
In your Sentry dashboard, open the project, go to Settings, then Client Keys (DSN). Sentry generates the DSN automatically when you create a project. It is a URL containing your public key, organization, and project ID, and it is safe to embed in a client app.
Initialize it as early as possible. In a SwiftUI app, call SentrySDK.start in your App struct's init. In a UIKit app, call it at the very top of application(_:didFinishLaunchingWithOptions:). Early initialization ensures crash handlers are installed before any startup code can crash.
Both work identically for the SDK itself. Swift Package Manager is built into Xcode and simpler for new projects, requiring no extra tooling or workspace. Use CocoaPods only if your project already depends on it. The initialization code is the same regardless of which you choose.
The most common reason is that the Xcode debugger was attached and intercepted the crash before Sentry could handle it. Run the app independently, not from Xcode's run button, then relaunch it. Sentry flushes stored crash reports on the next launch, so the event appears after you reopen the app.
No. The Sentry product alone provides crash and error reporting and most performance features. SentrySwiftUI is an optional helper for instrumenting SwiftUI view rendering with performance spans. Add it only if you want that specific SwiftUI view tracing; it is not needed for basic setup.