AppIntro: a carousel onboarding library for Android, and where it stops

What AppIntro solves, and who it is aimed at

A first-run carousel is a small feature that eats a disproportionate amount of Android work: pager wiring, indicator state, back-button handling, permission prompts mid-flow, and the decision about when to stop showing the intro. AppIntro packages those pieces. The README describes it as an Android library that helps you build a carousel intro and that has support for requesting permissions, with the claim that it helps you create an onboarding experience in a couple of minutes. The audience is Android developers who already have fragments and want a standard intro screen without writing a pager from scratch. It is not a design system, and it does not generate slides from a JSON file. You supply fragments; AppIntro supplies the container, the navigation controls and the skip and done callbacks.

How the slide flow is assembled

The mechanism is inheritance rather than composition. You create an Activity that extends AppIntro, and inside onCreate you call addSlide with your fragments. The README uses AppIntroFragment.createInstance to build pre-built slides with a title and a description, and notes that you can also use AppIntroCustomLayoutFragment for your own layout. The superclass owns the content view, which is why the README states in capitals that you must not call setContentView; the AppIntro superclass takes care of it. Navigation events are delivered through overrides such as onSkipPressed and onDonePressed, where the README's example calls finish(). That means the lifecycle of the intro is your Activity's lifecycle. The README also warns that you must override onCreate with a single Bundle parameter and not a variant such as onCreate(Bundle, PersistableBundle), which is the kind of constraint that comes from the superclass doing setup work in that specific method.

The configuration surface is wider than the basic example suggests. The README's table of contents lists a slide transformer with a custom variant, a color transition, a multiple windows layout, indicators, vibration, a wizard mode, immersive mode, system back button behaviour, system UI control for the status and navigation bars, and a bottom bar margin. Permission handling has its own section, with a Slide Policy subsection.

Installing AppIntro from JitPack and building a first intro

AppIntro is distributed through JitPack, not Maven Central, so the repository has to be declared in the module build file. The README is explicit that this goes in the build.gradle of the module where you use AppIntro, not the root file. The current stable version in the release list is 6.3.1, which is the AndroidX-capable line. The README also lists 4.2.3 as the latest version compatible with the old Support Library, and notes that since AppIntro 5.x the library supports AndroidX.

repositories {
    maven { url "https://jitpack.io" }
}

dependencies {
    implementation 'com.github.AppIntro:AppIntro:6.3.1'
}

With the dependency in place, the smallest real intro is an Activity that extends AppIntro and adds two slides. The README's example uses named arguments for title and description. Do not add setContentView, and keep the onCreate signature to a single Bundle parameter.

class MyCustomAppIntro : AppIntro() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        addSlide(AppIntroFragment.createInstance(
                title = "Welcome...",
                description = "This is the first slide of the example"
        ))
        addSlide(AppIntroFragment.createInstance(
                title = "...Let's get started!",
                description = "This is the last slide, I won't annoy you more :)"
        ))
    }
}

The last step is the manifest entry. The README shows a plain activity declaration with a name and a label. It also suggests not declaring the intro as your first Activity unless you want it to launch on every start, and says you should show it once and hide it after completion, using a flag in SharedPreferences. That flag is your responsibility, not the library's.

<activity android:name="com.example.MyCustomAppIntro"
    android:label="My Custom AppIntro" />

The release line is the real constraint

AppIntro 7.0.0 exists only as 7.0.0-beta02, published on 2023-07-24, the same day as the 6.3.1 stable release. Anyone reading the repository in 2026 sees a beta that is three years old and a stable line that is just as old, while the last push to the default branch was on 2026-10-29. That combination is worth stating plainly: the code is being touched, but the published artifact a new project would depend on has not moved to a new stable release. If you adopt AppIntro today, the practical choice is 6.3.1 and the beta is a separate risk decision. The README's Migrating section covers only moving from v5.x to v6.x.

Where AppIntro is the wrong tool

The library assumes a linear sequence of slides. If your onboarding depends on the user's answers, or if slides must be inserted and removed at runtime based on server configuration, the addSlide model in onCreate is a poor fit; you would be building the sequencing logic yourself on top of a container that wants a fixed list.

There is also an ownership problem with the content view. Because AppIntro manages the layout and forbids setContentView, anything that expects to inflate its own root view inside the same Activity has to be reconciled with the library's structure. If your intro collects state that must survive a restart, verify that yourself before shipping. Finally, the permission support is a convenience, not a substitute for the runtime permission model;.

Alternatives and how they differ in approach

Android showcase libraries such as FancyShowCaseView, MaterialShowcaseView, and TapTargetView solve a different problem. AppIntro is a full-screen, multi-page intro that owns an Activity and ends with a skip or done action. Showcase and tap-target libraries overlay a highlight on top of an existing screen to point at a button or a menu item, and the user stays in the app's normal navigation. If your goal is to explain the app before the user reaches the home screen, AppIntro is the closer fit. If your goal is to explain a control the user is already looking at, an overlay library is the closer fit and AppIntro would be the wrong shape.

Licence, upgrade cost and what to check before you commit

AppIntro is licensed under Apache-2.0, which permits commercial use and modification provided the licence and notices are preserved. That is a permissive licence with no copyleft obligation on your app, but it is not legal advice and your own compliance process decides what notices you ship. The upgrade cost is the sharper issue. The README's Migrating section covers only v5.x to v6.x, the 7.x line is still beta, and the stable artifact is 6.3.1. Pinning that version and treating an upgrade as a project rather than a version bump is the realistic plan. The repository also carries a renovate.json and ktlint configuration, which suggests dependency updates and formatting are automated on the maintainer side, but that says nothing about the API stability you will experience.

Editorial conclusion

AppIntro fits teams that want a first-run carousel with permission slides and are willing to pin a version and read the source when the README is silent. It is the wrong tool if you need branching slide sets or a stable 7.x API. Before adopting, verify that com.github.AppIntro:AppIntro:6.3.1 resolves from JitPack in your build, that your Activity overrides onCreate with a single Bundle parameter, and that you have not called setContentView, since the README states the superclass handles it.

Frequently asked questions

Official sources

1. AppIntro/AppIntro on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases