Flutter Sticky Header: SliverPersistentHeader, SliverAppBar and NestedScrollView (2026)

Across the ten industries we ship Flutter in, the sticky header shows up wherever a scrolling list needs to anchor a section title, a category label, or a date row to the top of the viewport as content scrolls past beneath it. The choice between SliverPersistentHeader, SliverAppBar with the pinned flag, the community sticky_headers package, or a hand-rolled OffstageBuilder pattern looks small at design time and turns into a performance, coordination, or M3-conformance question once the app hits real users. This guide walks through the flutter sticky header patterns we actually ship, the Sliver primitives most tutorials skip, and the production-grade fixes worth knowing on every list-heavy Flutter build.

Two framing notes. Flutter ships three native sticky-header primitives in the Material library that cover about 90% of the sticky-header use cases real apps need. SliverPersistentHeader for custom in-list section headers, SliverAppBar with pinned: true for app-bar-style top docking, and SliverGrid plus SliverList combined with NestedScrollView for tabbed scrolling surfaces. Most pub.dev packages predate full Sliver support and have been overtaken by the built-in primitives on the modern Flutter versions our team has shipped against this year. Second: the sticky-header pattern is sensitive to scroll coordination — getting it right inside a TabBarView or a CustomScrollView needs SliverOverlapAbsorber and SliverOverlapInjector, which is where most production bugs live.

When the flutter sticky header is the right pattern (and when it isn't)

Use a sticky header when scrolling content has clear section breaks that benefit from a persistent visual cue, such as a contacts list grouped by first letter, an order history grouped by date, a settings screen with category labels, or a feed broken by content type. The pattern shows up across the production builds we ship most often: chat threads grouped by date, audit logs grouped by status, dashboard sections labeled by KPI category. Whenever a list crosses about 30 rows with a clear grouping structure, a sticky header improves scan time measurably. Sticky headers reduce scroll fatigue and improve scanning. The reason to skip them: when the content has no natural section structure or when the visual weight of a persistent header competes with the content rather than supports it.

SliverPersistentHeader: the built-in sticky primitive for custom in-list section headers

SliverPersistentHeader is the Flutter primitive purpose-built for sticky behavior inside a CustomScrollView. It takes a SliverPersistentHeaderDelegate that defines the header content, its min and max height, and whether it should stay pinned to the top as the user scrolls past. The delegate is a regular Dart class. Override build, minExtent, maxExtent, and shouldRebuild and you have a custom header. The widget exposes pinned and floating flags that work the same way they do on SliverAppBar, so the mental model carries over for teams familiar with the app-bar variant. The widget integrates with the scroll position natively, so the header transitions smoothly between expanded and collapsed states.

class _SectionHeaderDelegate extends SliverPersistentHeaderDelegate {
  final String label;
  const _SectionHeaderDelegate(this.label);

  @override
  double get minExtent => 48;
  @override
  double get maxExtent => 48;

  @override
  Widget build(BuildContext context, double shrinkOffset, bool overlapsContent) {
    return Material(
      color: Theme.of(context).colorScheme.surfaceContainerLow,
      child: Padding(
        padding: const EdgeInsets.symmetric(horizontal: 16),
        child: Align(
          alignment: Alignment.centerLeft,
          child: Text(label, style: Theme.of(context).textTheme.titleSmall),
        ),
      ),
    );
  }

  @override
  bool shouldRebuild(_SectionHeaderDelegate old) => old.label != label;
}

// Inside CustomScrollView:
CustomScrollView(
  slivers: [
    SliverPersistentHeader(pinned: true, delegate: _SectionHeaderDelegate('A')),
    SliverList(delegate: SliverChildListDelegate(aContacts)),
    SliverPersistentHeader(pinned: true, delegate: _SectionHeaderDelegate('B')),
    SliverList(delegate: SliverChildListDelegate(bContacts)),
  ],
);

SliverAppBar with pinned: true: the app-bar sticky pattern for long-scroll screens

When the sticky header is conceptually an app-bar that needs to remain visible while the body scrolls past, SliverAppBar with pinned: true is the right primitive and the easiest sticky pattern to ship. The framework handles the M3 elevation, the surface tint, the back-arrow Hero animation, and the title styling automatically. We use this pattern on screens where the user scrolls a long feed and needs persistent access to the back arrow or a primary action.

Scaffold(
  body: CustomScrollView(
    slivers: [
      SliverAppBar(
        pinned: true,                          // stays visible while body scrolls
        title: const Text('Contacts'),
        actions: [IconButton(icon: const Icon(Icons.search), onPressed: () {})],
      ),
      SliverList(
        delegate: SliverChildBuilderDelegate(
          (ctx, i) => ListTile(title: Text(contacts[i].name)),
          childCount: contacts.length,
        ),
      ),
    ],
  ),
);

NestedScrollView: sticky tabs over a scrolling body with overlap coordination

The hardest sticky-header pattern to get right is a TabBar that stays pinned to the top while the body of each tab scrolls independently. This is the layout most production Pinterest-style and social-feed-style apps reach for, and it is the layout where most community packages give up. NestedScrollView handles this layout with headerSliverBuilder (the slot where you put your SliverAppBar with bottom: TabBar) and body (the slot where you put the TabBarView and the individual tab scroll surfaces). Two things must be wired right for the pattern to behave correctly under aggressive flicks and pull-to-refresh interactions. Every child of the TabBarView needs to wrap its scroll view in a CustomScrollView with SliverOverlapInjector at the top of its slivers list. The SliverAppBar needs SliverOverlapAbsorber as its parent inside the headerSliverBuilder list. Get either of these wrong and the inner scroll positions fight with the outer NestedScrollView, which produces the jumpy scroll behavior most developers blame on Flutter performance.

DefaultTabController(
  length: 3,
  child: Scaffold(
    body: NestedScrollView(
      floatHeaderSlivers: true,
      headerSliverBuilder: (ctx, innerBoxScrolled) => [
        SliverOverlapAbsorber(
          handle: NestedScrollView.sliverOverlapAbsorberHandleFor(ctx),
          sliver: SliverAppBar(
            pinned: true,
            title: const Text('Activity'),
            bottom: const TabBar(tabs: [
              Tab(text: 'Posts'),
              Tab(text: 'Replies'),
              Tab(text: 'Likes'),
            ]),
          ),
        ),
      ],
      body: const TabBarView(
        children: [_PostsTab(), _RepliesTab(), _LikesTab()],
      ),
    ),
  ),
);

class _PostsTab extends StatelessWidget {
  const _PostsTab();
  @override
  Widget build(BuildContext context) => CustomScrollView(
    slivers: [
      SliverOverlapInjector(
        handle: NestedScrollView.sliverOverlapAbsorberHandleFor(context),
      ),
      SliverList(delegate: SliverChildBuilderDelegate((c, i) => ListTile(title: Text('Post $i')), childCount: 50)),
    ],
  );
}

Community sticky_headers package: when is it still worth it in 2026?

The sticky_headers package on pub.dev predates the modern Sliver scroll model and ships a simpler API for list-style sticky sections. The migration to SliverPersistentHeader is typically under 50 lines per screen and saves the package dependency, but the package API is friendlier for teams not already comfortable with the Sliver model. For new builds where the team can invest in learning Slivers, the built-in is the better choice. For legacy screens already on the package, do not migrate until you are touching the surrounding code anyway.

Two more community packages worth knowing about for legacy codebases that already have them installed: flutter_sticky_header (similar API to sticky_headers with extra customization for floating headers) and sticky_grouped_list (handles grouped lists with sticky group labels in one widget). Both packages work but cover use cases that SliverPersistentHeader plus a simple grouping helper can model natively on modern Flutter versions. We do not adopt either on new builds in 2026 because the maintenance burden across major Flutter upgrades has been higher than building the equivalent natively.

Performance: where sticky headers most often make Flutter apps jank

Accessibility: what sticky headers need that the framework default does not ship

The five flutter sticky header bugs we see in code review every month

For the deeper SliverAppBar variant guide plus pinned/floating/snap combinations that pair with sticky headers on real-world Flutter app builds, see our guide to flutter AppBar widgets. For how scroll patterns fit into a production Flutter app (state plus performance plus CI/CD coverage) our Flutter mobile app development field guide covers the practices we apply on every build.

Common questions about the flutter sticky header pattern from our review checklist