OnboardingKit: onboarding triggers and pages as SwiftUI types

The idea: the trigger is a type, not a flag

OnboardingKit is a SwiftUI SDK for creating onboarding experiences on all major Apple platforms, and its design decision is visible in the way it names things.

The library has different Onboarding types, and each type defines a unique onboarding experience behaviour. There is Onboarding, which is presented right away and only once. There is Onboarding.Conditional, presented when a certain condition returns true. There is Onboarding.CorrectBehavior, presented when a user is not behaving as intended. There is Onboarding.Delayed, presented after a certain number of presentation attempts.

Read as a list, those four types cover the situations every app runs into. The user is new, so show the intro once. The user has not finished setup, so show it conditionally. The user has skipped the permission prompt three times, so show it as corrective guidance rather than as an intro. The user has dismissed it twice already, so wait until the third attempt.

The value of encoding that as types is that the decision moves out of scattered application code. A check on a user defaults flag inside a view's onAppear is invisible to the type checker and easy to duplicate. A type that says when it appears is part of the hierarchy, and the compiler can tell you that you used a type that does not exist in this version of the library.

The project is MIT licensed, by Daniel Saidi, and the sponsor link and the release badge sit at the top of the README. The last push to the repository was on 2026-08-06, and the current release is 10.0.0 from the same day.

The four Onboarding types in detail

The four types are the heart of the library, and it is worth reading them as a set of policies rather than as four classes.

Onboarding itself is the simplest and the strictest. It is presented right away, and only once. There is no condition and no retry, which makes it the right type for a first launch welcome sequence and the wrong type for anything that depends on the user reaching a particular state.

Onboarding.Conditional takes a predicate. It is presented when a certain condition returns true, and that is the type that covers the case where onboarding is only relevant to some users, such as a feature that only new accounts see, or a hint that appears after a particular event in the app.

Onboarding.CorrectBehavior is the corrective case, presented when a user is not behaving as intended. The distinction from Conditional is intent. A conditional onboarding is a normal part of the experience that some users reach, while corrective onboarding is a nudge about something the user is getting wrong, which means it belongs after the behaviour has been observed rather than at a fixed point in a flow.

Onboarding.Delayed is the patience case, presented after a certain number of presentation attempts. It is the mechanism for not nagging. The user is offered the flow, dismisses it, and the library counts the attempts so the same flow can wait until the attempt count you have configured.

Having these as distinct types means a code reviewer can see the intent of an onboarding flow in the view hierarchy, and it means the conditions themselves are ordinary Swift closures you can test.

The presentation components: pages, slideshow and intro screen

The trigger types decide when, and the view components decide what the user sees. Three are named in the README.

OnboardingPageView presents manually scrolling pages, which is the ordinary case where the user moves through the sequence at their own pace and can go back.

OnboardingSlideshow presents an automatically progressing slideshow, which is the case where the content is a pitch rather than an instruction, and where making the user tap through four screens of marketing is the wrong interaction.

OnboardingIntroScreen presents a welcome screen on first app launch, which is the narrowest of the three and the one that maps most directly to the Onboarding type that fires right away and only once.

The library also has OnboardingScreen, which can wrap any onboarding flow. That is the piece that makes the components composable. The screen takes the flow you assembled from a type and a view, and handles presenting it, so the parent of the flow does not need to know whether the content is a page view or a slideshow.

The README points at the online getting started guide for more, and the documentation site is the place where the wiring details live. The repository also ships a Demo folder containing an app that lets you explore the library, which is the fastest way to see the components with real content in them before you write the integration.

Installation and the platform floor

Installation is through the Swift Package Manager, and the README gives the repository URL to add.

https://github.com/danielsaidi/OnboardingKit.git

The platform requirements are the part to check first, because they are the highest floor of any library in this space. OnboardingKit supports iOS 17, macOS 15, tvOS 17, watchOS 10 and visionOS 1, and the badge in the README header names Swift 6.2.

That is a wide set of minimums, and each one is recent enough to rule out an older deployment target. An app that still supports iOS 16 cannot adopt this version, and an internal corporate build with a lower macOS floor has the same problem. There is no list of older supported versions in the README, so the answer for an app on an older floor is to check the release notes and the earlier tags rather than to expect a compatibility mode.

The repository layout is a normal Swift package with a Package.swift manifest, a Package.resolved file, Sources, Tests, Resources, a Demo application and a scripts directory, plus a .swiftlint.yml so the code style is enforced by a linter rather than by convention. RELEASE_NOTES.md sits at the root next to the README, which is where the upgrade information lives.

Version 10 and the upgrade cost

The release history shows a major version change in the recent past, and for a Swift package that is the thing to look at before adopting.

The releases listed are 10.0.0 from 2026-08-06, 9.2.1 from 2026-05-20 and 9.2.0 from 2026-02-07. So the project moved from a 9.x line to a 10.0.0 in August 2026, with the last push to the repository on the same day, which suggests the major bump was recent work rather than a long-planned rename.

Swift package versioning follows semantic versioning, and a major bump means the API is allowed to break. The consequences for you are concrete. If you adopt 10.0.0, your code is pinned to the new API and you get the fixes that came with it. If you stay on 9.x, you keep the old API and you keep the old behaviour, and you do not get whatever the 10.0.0 work fixed.

The cost of a major upgrade for a library of this size is a read of RELEASE_NOTES.md and an afternoon of compiler errors, which is a manageable but real cost. It is also the reason to look at the number before choosing a version, since the same API in 9.2.1 and in 10.0.0 is not the same API.

The project publishes release notes and the README carries a version badge, so both the current version and the history of changes are visible without digging through issues.

Where OnboardingKit stops

Three boundaries are worth naming.

The first is platform. This is an Apple platform SDK, and it covers iOS, macOS, tvOS, watchOS and visionOS. There is no Android, no web, and no cross platform story, which is not a criticism so much as a description of what a SwiftUI SDK is.

The second is that the library is about presentation, not measurement. The types decide when to show a flow and the views decide what it looks like, and nothing in the documentation describes analytics hooks, funnel reporting, or the ability to vary onboarding content per experiment group. If your onboarding needs to be measured, that instrumentation is yours to build on top of the components, and the library will not tell you when to fire an event.

The third is the documentation boundary. The README is a short overview, and the real documentation lives on the documentation site, with a getting started guide and more articles and code examples. The offline repository is the library, the tests and the demo app. So the learning curve is paid online, which is normal for a modern package but worth knowing if you are working behind a proxy or an offline build.

The sponsor link in the README is the author's own open source funding page, and the project is maintained by one person, so issue response time and roadmap priority are personal decisions.

Editorial conclusion

Adopt OnboardingKit if your SwiftUI app shows onboarding and you want the decision about when to show it expressed as a type in your view hierarchy rather than as a scattered check on a stored flag, because that is the part of the design the library gets right. Do not adopt it if your onboarding needs analytics, experiment variants or server driven content, since nothing in the library covers that. Before you upgrade, read RELEASE_NOTES.md, because the project moved to a 10.0.0 release and the API is versioned with the major number rather than kept stable across it.

Frequently asked questions

Official sources

1. danielsaidi/OnboardingKit on GitHub
2. License: MIT
3. Project website
4. README
5. Releases