OneSignal's iOS SDK is a set of thin wrappers around a push notification service

What the SDK is for, and what OneSignal actually is

The README describes OneSignal as a free email, sms, push notification and in-app message service for mobile apps, and the plugin's job is to make it easy to integrate your native iOS app with OneSignal. That distinction matters for how you evaluate the dependency. The SDK is not a notification framework you host, it is the client half of a hosted service, and adopting it means adopting the service as well. What you get in exchange for that coupling is a single integration covering four channels, so a team that would otherwise assemble a push library, an in-app message view controller, an SMS gateway and an email sender ends up with one SDK and one dashboard. The README is candid that the API reference itself lives off the repository, on OneSignal's Mobile SDK reference page, which is where the list of all available methods is documented. The repository holds the client code, the wrappers and the release history, not the API contract.

The wrapper directories, one per platform capability

The top-level layout explains the architecture better than any prose would, and it is unusual. Alongside the core directories there are seven wrapper directories, each named for a capability: OneSignalExtensionWrapper, OneSignalFrameworkWrapper, OneSignalInAppMessagesWrapper, OneSignalLiveActivitiesWrapper, OneSignalLocationWrapper, OneSignalNotificationsWrapper, OneSignalOSCoreWrapper, OneSignalOutcomesWrapper and OneSignalUserWrapper. The main source sits in an iOS_SDK directory, and there is an examples/demo directory. Two packaging manifests are present, OneSignal.podspec and OneSignalXCFramework.podspec, and the README badges show the distribution channels: CocoaPods, Carthage compatible and SwiftPM compatible. A separate OneSignal-KMP-SDK directory points at Kotlin Multiplatform, and the .gitmodules file suggests it is pulled in as a submodule rather than vendored. The wrapper split is the design decision worth understanding, because it is what lets an app link only the capabilities it uses instead of pulling in everything.

Installing it: three package managers, one pod

The README does not give a command, and it points instead at OneSignal's iOS Native SDK Setup Guide for documentation. The distribution badges are the practical instruction. The CocoaPods pod is named OneSignal, so a CocoaPods project adds that pod. The SwiftPM route is a Package.swift at the repository root, and the Carthage badge indicates the project can be built for Carthage consumers as well, with the XCFramework podspec covering the binary distribution. The README also carries a Travis CI build status badge, which is a leftover from an older continuous integration setup rather than a current one, since the repository has a .github directory for its own workflows. The .swift-version file pins the Swift toolchain used for development, .swiftlint.yml configures linting, and there is a CHANGELOG file plus a CONTRIBUTING.md. Note what the README does not contain. There is no App ID, no registration snippet and no permission request example anywhere in this file, which is why the setup guide is the authority for the first run.

Supported platforms and language mix

The supports list is short and specific. Swift and Objective-C projects are supported, and the supported range is iOS 15 to iOS 26. The primary language of the repository is recorded as Objective-C, which is a legacy choice worth understanding rather than a bug. A push SDK has to talk to APNs and to the various iOS notification extension points, and the parts of that surface that predate Swift still live in Objective-C, while the public API is exposed to Swift callers. The .swiftlint.yml file exists because the Swift side is linted, and the presence of a OneSignal-KMP-SDK directory indicates that Kotlin Multiplatform consumers are served from a separate module rather than from a Swift-only API. For an existing Objective-C codebase, an SDK that does not force a rewrite is a practical advantage; for a new Swift-only project, the Swift API is the layer you will actually touch, and the README does not document the shape of that surface at all.

Migration from v4, and where the change log lives

The README carries a dedicated callout for anyone arriving from an older integration: if you are migrating from v4 or earlier, there is a Migration Guide file in the repository, MIGRATION_GUIDE.md, with detailed instructions for upgrading to the 5.x.x line. The 5.x releases are recent, with 5.8.0 published on 2026-10-08, 5.7.0 on 2026-09-22 and 5.6.3 on 2026-09-21, and the last push to the repository was on 2026-10-19. The complete change log of every released version is not in the repository either. The README directs you to the repository's release tags for that. The GettingStarted.md file at the root is the other document you would look at, and it is the piece the README does not link, which suggests the setup guide and the reference documentation are the maintained entry points. A major version boundary at 5.x, with a migration guide written for it, means an existing v4 integration is doing more than a version bump.

Where the OneSignal iOS SDK is the wrong choice

Three limits, and the first one is not technical. The licence is recorded as a custom one that GitHub cannot classify, with the terms in the LICENSE file, so unlike an MIT or Apache SDK you cannot infer what you are allowed to do without reading it. For a dependency you ship inside a commercial app, that reading is not optional. The second limit is the service coupling. Every channel this SDK offers routes through OneSignal's hosted infrastructure and its dashboard, which means account management and support requests go to OneSignal support from the OneSignal.com dashboard, while SDK-specific bug reports and feature requests go to this repository's GitHub issue tracker. Those are two different support paths, and the split is a deliberate boundary between the client code and the service. The third limit is scope of control. If you need to route notifications through your own backend, own the delivery infrastructure, or avoid a third-party service in the notification path, then this SDK is the wrong shape regardless of how well it works, and the alternative is talking to APNs directly. For a team that only needs plain push with no in-app messages, no SMS and no email, the SDK may be more machinery than the job requires.

Editorial conclusion

Adopt the OneSignal iOS SDK if you want push notifications, in-app messages, SMS and email behind one API and one dashboard, since the wrapper split means you only link the capabilities you use. Skip it if you need a self-hosted notification stack or you only need APNs directly, since the SDK is a client for a hosted service. Before you commit, read the LICENSE file yourself, because GitHub cannot classify it, and check the v4 to v5 migration guide if you are upgrading an existing integration.

Frequently asked questions

Official sources

1. Issues
2. OneSignal/OneSignal-iOS-SDK on GitHub
3. README
4. Releases