6 Best Mobile In-App Tour Libraries in 2026

The quick answer

Quick answer: your framework picks the library, not a feature table. React Native — react-native-copilot for the fullest option, rn-tourguide for something lighter. Flutter — tutorial_coach_mark for overlay tours, showcaseview for per-widget coach marks. Native Android — TapTargetView. Native iOS — Instructions. Check the last commit date and open-issue count before the API, because this category has an unusual number of libraries that were the right answer three years ago and have not been touched since.

Mobile breaks the web assumptions

A web tour ships when you deploy and the DOM is queryable. Neither holds on mobile. Tour content lives inside a binary, so a copy fix is a release and a review queue unless you built remote configuration on purpose. Layout varies far more than the web does — dynamic type, notches, split screen, foldables — so anything anchored to a coordinate rather than to a view will eventually point at empty space. And the app is interrupted constantly: a call, a notification, a backgrounding mid-step. A tour that does not survive suspension resumes into a state that no longer matches its own copy.

At-a-glance comparison

Maintenance status checked September 2026 and it moves — verify the last release on each project before you take the dependency, not after.

The libraries, honestly

react-native-copilot is the most complete React Native option and the usual starting point: step definitions, a walkthrough overlay, and enough control to fit a real app. rn-tourguide is the lighter alternative and quicker to reason about when the requirement is genuinely a short linear tour.

In Flutter, tutorial_coach_mark and showcaseviewsolve adjacent problems. The first is an overlay tour with focus cutouts across a sequence; the second attaches coach marks to individual widgets and leaves sequencing to you. Both anchor to widget keys, which is the right model — anchoring to a coordinate is what breaks under dynamic type.

On native, TapTargetView on Android and Instructions on iOS are both mature and both single-platform. That is a feature if you are native on one side and a real cost if you ship both, because you are maintaining two tour implementations that will drift.

What a library makes you build on mobile

Everything from the web version, plus three that are specifically worse here. Release-independent content: without remote configuration, every copy change is a release and a review. Interruption survival: what happens when the app is backgrounded on step three, covered in our offline and interruption recovery plan. And cross-device continuity: a user who starts onboarding on a phone and opens the tablet should not start again, which needs server-side state rather than local storage — our completion synchronization policy covers the conflict rules.

PLG OS sits on the other side of that line and we would rather name the trade than bury it. A library is clearly the right call when a developer owns a handful of tours and shipping every two weeks is fine; the dependency is small and you own the code. It stops being the right call when a non-developer needs to change a tour without a release, or when you need the same onboarding measured consistently across iOS, Android and web. On mobile the deciding factor is almost always release cadence rather than rendering.

FAQs

Which library should I use?
Whichever matches your framework. Check maintenance status first — last release, open issues, whether it supports your current framework version.

Why is mobile harder than web?
Content ships in a binary, layout varies far more, and the app gets interrupted. Each one breaks an assumption that web tour libraries take for granted.

Build or buy?
Build with a library when a developer owns a few tours and a two-week release cycle is acceptable. Buy when copy changes must not wait for app store review, or when onboarding needs measuring the same way across platforms.