DEV Community: Noa Tubić

Four Claude Code skills to audit a Flutter app

Noa Tubić — Wed, 14 Oct 2026 21:03:04 +0000

Before a release I used to run the same mental checklist. Is the privacy manifest there? Is anything in pubspec.yaml abandoned? Did someone hardcode a string again? Is a token sitting in the source?

A checklist in your head gets skipped when the deadline is close. So I turned mine into four Claude Code skills. Each one reads the project, works through a fixed list of checks, and writes a Markdown report with a fix for every finding.

The four skills

Security: /owasp-mobile-audit covers all ten OWASP Mobile Top 10 (2024) categories plus six newer checks, like hardcoded secrets, data leaking into logs, and unsafe sharing. It works on Flutter, native Android, and native iOS code.

Dependencies: /flutter-dependency-audit looks at seven things in your packages: outdated and abandoned ones, duplicates that do the same job, license conflicts, known CVEs, loose version constraints, and leftover dependency overrides.

Localization: /flutter-localization-audit runs eight checks: hardcoded strings, missing ARB keys, the l10n setup, plural and gender forms, RTL layouts, locale-aware dates and numbers, broken interpolation, and the fallback locale.

Store readiness: /flutter-store-readiness runs eight checks for App Store and Google Play: the iOS Privacy Manifest, Android Data Safety, permission strings, screenshots, age rating, metadata limits, and the platform configs such as signing and targetSdk.

Try it

Install the ones you want:

npx skills add NoaTubic/owasp-mobile-audit-skill
npx skills add NoaTubic/flutter-dependency-audit-skill
npx skills add NoaTubic/flutter-localization-audit-skill
npx skills add NoaTubic/flutter-store-readiness-skill

Then, inside Claude Code, in your Flutter project:

/flutter-store-readiness

Each skill saves its report in the project root, for example store_readiness_report.md. You can also run only the checks you care about:

/owasp-mobile-audit M9,AE2
/flutter-dependency-audit security,licenses
/flutter-localization-audit hardcoded,arb
/flutter-store-readiness ios

What a report looks like

Every report uses the same shape. It opens with a summary: a count per severity, from Critical to Info. The store readiness report also gives each platform a status of ready, issues found, or blocking.

Then each category gets its findings. A finding has the file and line, the evidence, and one sentence on how to fix it. The report also lists what's already done right, so you don't "fix" something that works. It ends with the three to five fixes that matter most.

The severity scale is about consequences, not style. In the store readiness skill, Critical means an automatic rejection, like a missing Privacy Manifest or debug signing on a release build. In the security skill, Critical means something directly exploitable, like a hardcoded credential or disabled TLS.

A few things they catch that people miss

A Privacy Manifest that exists but leaves out a Required Reason API your code or an SDK uses
Permission strings like "This app needs the camera", which Apple tends to reject as too vague
A package that hasn't had a release in years, with an active alternative
Dates shown with DateTime.toString() instead of a locale-aware formatter
An API key in source, or a token written to the logs

What they are and aren't

These are skills, so Claude does the reading. That means they understand context a regex can't, like whether a string is user-facing or a log tag. It also means a finding is a well-argued suggestion, not a proof. Check each one before you act on it, and keep your real scanners and your store review in the loop. The skills are there to catch the obvious misses early.

Try it yourself

Run /flutter-store-readiness on your app before the next release and fix the Critical items first. The skills, their checks, and the full report templates are here:

NoaTubic / owasp-mobile-audit-skill

OWASP Mobile Top 10 (2024) security audit skill for Claude Code — covers all 10 categories + 6 emerging checks, with per-rule filtering

OWASP Mobile Audit Skill

A Claude Code skill that performs a comprehensive OWASP Mobile Top 10 (2024) security audit on mobile codebases and produces a structured, actionable markdown report.

Covers all 10 official OWASP Mobile categories plus 6 additional emerging checks, with each finding mapped to a severity level and concrete remediation advice.

What it audits

ID	Category
M1	Improper Credential Usage
M2	Inadequate Supply Chain Security
M3	Insecure Authentication / Authorization
M4	Insufficient Input/Output Validation
M5	Insecure Communication
M6	Inadequate Privacy Controls
M7	Insufficient Binary Protections
M8	Security Misconfiguration
M9	Insecure Data Storage
M10	Insufficient Cryptography
AE1	Data Leakage (emerging)
AE2	Hardcoded Secrets (emerging)
AE3	Insecure Access Control (emerging)
AE4	Path Overwrite / Path Traversal (emerging)
AE5	Unprotected Endpoints (emerging)
AE6	Unsafe Sharing (emerging)

Installation

npx skills add NoaTubic/owasp-mobile-audit-skill

Or add it manually by copying SKILL.md and references/ into your Claude Code skills directory.

Usage

Full audit (all

…

View on GitHub

NoaTubic / flutter-dependency-audit-skill

Flutter/Dart dependency audit skill for Claude Code — checks outdated packages, abandoned libs, license conflicts, CVEs, and version pinning issues

Flutter Dependency Audit Skill

A Claude Code skill that performs a comprehensive dependency audit on a Flutter/Dart project and produces a structured, actionable markdown report.

Covers 7 audit categories — from outdated and abandoned packages to license conflicts, known CVEs, and version pinning issues.

What it audits

ID	Category
D1	Outdated Packages
D2	Abandoned / Unmaintained Packages
D3	Duplicate Functionality
D4	License Conflicts
D5	Security Advisories / Known CVEs
D6	Version Pinning Issues
D7	Dependency Overrides

Installation

npx skills add NoaTubic/flutter-dependency-audit-skill

Or add it manually by copying SKILL.md and references/ into your Claude Code skills directory.

Usage

Full audit (all 7 checks)

/flutter-dependency-audit

Audit specific categories only

Pass a comma-separated list of category IDs:

/flutter-dependency-audit security
/flutter-dependency-audit outdated,licenses
/flutter-dependency-audit security,pinning,overrides

Only the listed categories will be run. The report header notes which categories were in scope.

Output

The skill saves a dependency_audit_report.md file in your project root containing:

Executive Summary…

View on GitHub

NoaTubic / flutter-localization-audit-skill

Flutter/Dart localization audit skill for Claude Code — finds hardcoded strings, missing ARB keys, RTL issues, broken plural forms, and locale-unaware formatting

Flutter Localization Audit Skill

A Claude Code skill that performs a comprehensive localization audit on a Flutter/Dart project and produces a structured, actionable markdown report.

Covers 8 audit categories — from hardcoded strings and missing ARB translations to RTL support, plural forms, and locale-unaware date formatting.

What it audits

ID	Category
L1	Hardcoded Strings
L2	ARB File Completeness
L3	intl / l10n Setup
L4	Pluralization & Gender
L5	RTL Support
L6	Date, Time & Number Formatting
L7	String Interpolation Issues
L8	Locale Fallback Configuration

Installation

npx skills add NoaTubic/flutter-localization-audit-skill

Or add it manually by copying SKILL.md and references/ into your Claude Code skills directory.

Usage

Full audit (all 8 checks)

/flutter-localization-audit

Audit specific categories only

Pass a comma-separated list of category IDs:

/flutter-localization-audit hardcoded
/flutter-localization-audit arb,rtl
/flutter-localization-audit hardcoded,arb,plurals,rtl

Only the listed categories will be run. The report header notes which categories were in scope.

Output

The skill saves a localization_audit_report.md…

View on GitHub

NoaTubic / flutter-store-readiness-skill

App Store & Google Play submission readiness audit skill for Claude Code — checks iOS Privacy Manifest, Android Data Safety, permissions, screenshots, age rating, and metadata limits

Flutter Store Readiness Skill

A Claude Code skill that performs a comprehensive App Store and Google Play submission readiness audit on a Flutter project and produces a structured checklist report.

Covers 8 audit categories — iOS Privacy Manifest, Android Data Safety, permissions, screenshots, age rating, metadata limits, and platform-specific configs — so you catch every rejection reason before Apple or Google does.

What it audits

ID	Category	Platform
S1	iOS Privacy Manifest (PrivacyInfo.xcprivacy)	iOS
S2	Android Data Safety section	Android
S3	Permissions justification	Both
S4	Screenshots & store assets	Both
S5	Age rating & COPPA compliance	Both
S6	Metadata length limits	Both
S7	iOS-specific checks (Info.plist, signing, entitlements)	iOS
S8	Android-specific checks (targetSdk, signing, bundle, ProGuard)	Android

Installation

npx skills add NoaTubic/flutter-store-readiness-skill

Or add it manually by copying SKILL.md and references/ into your Claude Code skills directory.

Usage

Full audit (all 8 checks, both platforms)

/flutter-store-readiness

Audit specific categories only

…

View on GitHub

Feedback and issues are welcome on GitHub.

A health check for your Flutter translations

Noa Tubić — Wed, 14 Oct 2026 20:54:22 +0000

Translation files only grow. Features get removed, screens get rewritten, but nobody deletes the old keys, because nobody is sure they are unused.

I ran into this on a production Flutter app with about 2,900 Dart files and 2,400 translation keys. 365 keys were never used. 38 were missing in one of the languages. 247 strings in Dart code never went through localization at all. And 10 translations had invisible zero-width characters hiding in them.

The analyzer doesn't report any of that, and neither does the code generator. So I wrote a small tool that does.

What it does

l10n_health reads your .arb files and your Dart code together and reports:

keys that no code uses
keys missing in one language, or identical to the template (likely never translated)
placeholders that differ between languages, like {name} vs {userName}
broken ICU messages and plural forms a language needs, like Croatian few
hardcoded text that should be a translation, and the existing key to use when there is one
invisible Unicode: zero-width spaces, bidi controls, look-alike spaces

It works with Flutter's gen_l10n and with flutter_intl, and it finds your setup on its own. A full run on that big app takes about a quarter of a second.

Try it

dart pub global activate l10n_health
l10n_health

Or as a dev dependency, so the whole team runs the same version:

dart pub add --dev l10n_health
dart run l10n_health

This is the output on the small example project in the repo:

Placeholder mismatches (placeholder_mismatch)  1
  error lib/l10n/app_de.arb:4:3  Placeholders in "greeting" differ from en: missing {name}, unexpected {userName}

Hardcoded strings (hardcoded_string)  2
  warn  lib/main.dart:22:9  Hardcoded text "Please select a pharmacy" bypasses localization (prose, en)
  warn  lib/main.dart:24:9  Hardcoded "Close"; use the existing key "close"

Unused keys (unused_key)  2
  warn  lib/l10n/app_en.arb:11:3  Key "legacyBanner" is never used in Dart code
  warn  lib/l10n/app_en.arb:12:3  Key "close" is never used in Dart code

For a report you can open in the browser or attach in CI:

l10n_health --format html -o l10n.html

Deleting keys without fear

Finding dead keys is half the job. Removing them is where people get nervous, so prune is careful:

l10n_health prune          # dry run, writes nothing
l10n_health prune --apply  # removes the keys from every language

It edits the files as text, so your diff is only the removed lines. Every file is checked to be valid JSON before anything is written. If a key also appears as a plain string somewhere, it might be looked up dynamically, so it is held back and listed for you to review instead of deleted.

After pruning, regenerate and build. If a key was still used, you find out at compile time, not from a user.

In CI

Record the current state once, then fail only on new problems:

l10n_health --update-baseline
l10n_health --fail-on warning

There are also --format gitlab and --format github outputs, so findings show up inline in merge requests and pull requests.

Try it on your project

Run l10n_health once in your app and look at the unused keys first. They're usually the quickest win. Everything else is documented here:

NoaTubic / l10n_health

Health check for the translation layer of Dart and Flutter apps: unused and missing ARB keys, placeholder mismatches, hardcoded strings, invisible Unicode, safe prune.

l10n_health

A health check for the translation layer of Dart and Flutter apps.

l10n_health reads your .arb files and your Dart code together, and reports what neither the analyzer nor the code generator will tell you keys nobody uses, translations that are missing or were never translated placeholders that differ between languages, text that bypasses localization entirely, and invisible characters hiding in your strings. It can then prune the dead keys for you, safely.

It works with Flutter's built-in gen_l10n, with flutter_intl / intl_utils, and with any other ARB-based setup. Configuration is optional; the setup is detected from l10n.yaml or pubspec.yaml.

$ l10n_health
l10n_health  flutter_intl · template de · 2439 keys · 2931 Dart files · strict usage · 235 ms
  Locales   de 2434  en 2406

Placeholder mismatches (placeholder_mismatch)  2
  error lib/l10n/intl_en.arb:313:3  Placeholders in "hint1" differ from de: missing {day} {month} {year}, unexpected {DateTime}
  ...
Malformed ICU

…

View on GitHub

https://pub.dev/packages/l10n_health

Feedback and issues are welcome on GitHub.

Write your Flutter lint rules in YAML

Noa Tubić — Wed, 14 Oct 2026 20:52:03 +0000

Every codebase has house rules. Use the design tokens, not Colors.grey. Don't let domain/ import presentation/. Never call ref.watch from a button handler.

They live in a style guide or a wiki page, and nothing checks them. So they drift. The worst kind is a design token typo: 'Text/bdy' instead of 'Text/body'. Token lookups usually fall back to a default color, so nothing fails. The diff looks fine in review, and a pink widget ships.

The Dart analyzer can't express rules like these. The usual answer is a custom analyzer plugin: a second package, Dart code per rule, and upkeep every time the analyzer changes. For a handful of project conventions, that felt like too much. So I wrote house_rules, where a rule is a few lines of YAML.

What it does

rules:
  avoid_palette_colors:
    severity: error
    exclude: [lib/theme/**]
    palette: Colors
    allowed: [transparent, white]

That's the whole rule. It ships with ten of them, all configured from one house_rules.yaml:

known_design_tokens: every token you look up by string must exist
layer_boundaries: which folders may import which
no_watch_in_callback: no ref.watch inside handlers and listeners
no_widget_returning_function and no_method_in_build
avoid_palette_colors, avoid_raw_colors, avoid_inline_text_styles and magic_spacing for design system discipline
unjustified_ignore: a suppression comment has to say why

Try it

dart pub global activate house_rules
house_rules init              # writes a starter house_rules.yaml
house_rules                   # see what it finds
house_rules --update-baseline # accept what is already there

After the baseline, only new problems fail. It needs Dart 3.11 or newer.

What a finding looks like

This is the output on the example project in the repo:

lib/features/cart/presentation/widgets/cart_row.dart
  12:12    ERROR   avoid_palette_colors
           `Colors.grey` bypasses the design tokens

  21:48    ERROR   known_design_tokens
           'Text/bdy' is not a defined design token
           did you mean:
             'Text/body'
             'Text/headline'

Each finding says why the rule exists and, where it can, what you probably meant. known_design_tokens reads your token map, so it knows the real names and catches the typo before it ships.

Fast enough to run on every save

It only parses files and never resolves types. That is a real limit, but it keeps a scan cheap. On a 2,937-file Flutter app with all ten rules, the compiled binary checks the whole project in 0.285 seconds, and a single file in 0.08 seconds.

That makes it practical as an editor or agent hook:

house_rules --hook "$CHANGED_FILE"

It stays silent when the file is clean and exits with code 2 when it isn't. If the linter itself crashes, it exits 0. A broken linter should never be the reason someone can't commit.

Adopting it on an old codebase

Turning on a new rule in an existing project usually means hundreds of findings on day one. --update-baseline records them, so CI stays green and only new violations fail.

The baseline is keyed by a hash of the offending code, not by line numbers, so it survives dart format and unrelated edits. For rules where every finding is a real bug, set baseline: false and they can never be hidden.

There are also Markdown, HTML, JSON and GitLab Code Quality reports, and a --check-docs mode that fails when your written guidelines and your config disagree.

Try it on your project

Run house_rules init, keep the two or three rules you already agree on, and baseline the rest. You can tighten it later. The code and the docs for every rule are here:

NoaTubic / house_rules

Write your project's lint rules in YAML instead of building a custom_lint plugin. Design tokens, layering, widget and state-management rules.

house_rules

Write your project's lint rules in YAML.

Every codebase has house rules. Use the design tokens, not Colors.grey Don't let domain/ import presentation/. Never call ref.watch from a button handler. They end up in a style guide, a wiki page, a CONTRIBUTING.md — and nothing checks any of them, so they drift.

The Dart analyzer can't express rules like these. The usual answer is to write a custom_lint plugin, which means a second package, Dart code per rule, and a plugin that has to be kept in step with the analyzer. For a handful of project conventions, that is a lot of ceremony.

house_rules gives you the same enforcement as four lines of YAML:

rules:
  avoid_palette_colors:
    severity: error
    exclude: [lib/theme/**]
    palette: Colors
    allowed: [transparent, white]

lib/features/cart/widget.dart
  88:14  ERROR  avoid_palette_colors
         `Colors.grey` bypasses the design tokens
         A literal palette colour will not follow

…

View on GitHub

https://pub.dev/packages/house_rules

Feedback and issues are welcome on GitHub.

Block rooted and jailbroken devices in Flutter

Noa Tubić — Wed, 14 Oct 2026 20:51:15 +0000

If your app handles payments, health data, or anything else worth stealing, a rooted phone is a problem. Root access lets other apps read your storage, hook your code, and change what your app sees.

Most teams agree they should check for this. Then the check ends up scattered across main(), a splash screen, and a few platform channels, with no clear rule for when to block and when to just log.

I wanted one place for it. So I wrote device_integrity_guard.

What it does

It runs a set of checks before runApp, and then either starts your app or shows a block screen.

Root on Android: known su binaries, root apps, and a writable system folder
Jailbreak on iOS: known jailbreak files and write access outside the app sandbox
Emulators, from the device info Android and iOS report
An attached debugger

A policy decides what each signal means. You can block it, only log it, or allow it, and you can switch all of it off in debug builds.

Try it

flutter pub add device_integrity_guard

Then wrap your app in main():

Future<void> main() async {
  final guard = DeviceIntegrityGuard(
    policy: DeviceIntegrityPolicy(
      allowDebugMode: !kReleaseMode,
      blockOnCompromise: kReleaseMode,
    ),
    onViolation: (result) => debugPrint('${result.blockedSignals}'),
  );
  await runGuardedApp(app: const MyApp(), guard: guard);
}

That's the whole setup. In a release build, a rooted or jailbroken device gets the block screen instead of your app. In debug, the checks are skipped, so you can still work on an emulator.

Block, log, or allow

The part I use most is the policy. Not every signal deserves the same answer.

A rooted phone in production is usually a block. An emulator in your QA build is expected. A debugger attached to a release build is worth knowing about, even if you don't block it yet.

So each detector can be switched on or off, each kind of signal can be allowed or not, and onViolation hands you the full result. That includes every signal, the reason for each one, and how long the scan took. Send it to your analytics first, see what real users trigger, and only then turn on blocking.

Your own screen and your own checks

The default block screen shows a short English message and the list of what was found. You can pass your own widget instead, or a builder that receives the summary of what was found:

await runGuardedApp(
  app: const MyApp(),
  guard: guard,
  blockedBuilder: (summary) => MyBlockedScreen(summary: summary),
);

Checks are pluggable too. Implement IntegritySignalDetector for anything specific to your app, like an APK signature check, and add it next to the built-in ones.

What it can't do

These checks run on the device, so a determined attacker can hide from them. Treat this as your first line, not your only one. For anything that really matters, pair it with server-side attestation: Play Integrity on Android and App Attest on iOS. The guard keeps casual tampering and test devices out of production. Attestation lets your backend refuse requests from a device it can't trust.

One iOS detail: the jailbreak check also asks whether the cydia:// URL scheme can be opened. iOS only answers that if cydia is listed under LSApplicationQueriesSchemes in your Info.plist, so add it there.

Try it yourself

Add the package, ship it with blocking off and logging on for one release, and look at what your users actually trigger. The example app and the full API are here:

NoaTubic / device_integrity_guard

Reusable toolkit that lets you stop a Flutter application before it boots when the runtime environment looks unsafe. It bundles common integrity detectors (emulator, root, jailbreak, debugger) and gives you a cohesive policy + UI surface to decide whether suspicious signals should block the UX, simply be logged, or be ignored in specific builds.

Device Integrity Guard

device_integrity_guard is a reusable toolkit that lets you stop a Flutter application before it boots when the runtime environment looks unsafe. It bundles common integrity detectors (emulator, root, jailbreak, debugger) and gives you a cohesive policy + UI surface to decide whether suspicious signals should block the UX, simply be logged, or be ignored in specific builds.

Highlights

🔐 Configurable policy – Toggle each detector, decide if emulators/root/jailbreak/debuggers are acceptable, and bypass checks entirely in debug builds.
🧪 Swappable detectors – Implement the IntegritySignalDetector interface to plug in custom probes (e.g., corporate MDM, binary signatures). Default detectors live under src/detection/.
🧭 Actionable results – DeviceIntegrityGuard.checkAndMaybeBlock() returns a DeviceIntegrityResult that lists all IntegritySignals plus how long scanning took.
🖥️ Built‑in blocking UI – CompromisedEnvironmentScreen ships with sensible English copy and can be replaced with any widget at runtime.
🚀 Drop-in bootstrap helper – runGuardedApp runs the…

View on GitHub

https://pub.dev/packages/device_integrity_guard

Feedback and issues are welcome on GitHub.

A Riverpod 3 architecture for Flutter apps

Noa Tubić — Wed, 14 Oct 2026 20:50:13 +0000

Riverpod tells you how to hold state. It doesn't tell you how a feature should be put together. So every project, and often every developer, ends up with a different answer.

Almost every screen still does the same thing. Show a spinner, call the API, then show the data or an error. Without a shared structure, every notifier writes that again, slightly differently each time.

After a few projects I stopped reinventing it. riverpod_architecture is the structure I now start every Flutter app with.

What it does

Each feature follows the same path: a repository returns either a failure or the data, a notifier turns that into state, and the screen renders the state. The package gives you the pieces for each layer:

Mappers that turn API responses into your own models, and forms into requests
BaseNotifier: one execute() call sets loading, then data or error
PaginatedNotifier: infinite lists with next page, refresh, and errors that keep the items already loaded
Global loading, failure, and info messages for the whole app
Sealed states, so the compiler checks you handled every case

It's built on Riverpod 3 and uses Either for results, so a failure is a value you return, not an exception you hope someone catches.

Try it

flutter pub add riverpod_architecture flutter_riverpod either_dart

Your repository returns either a failure or the data:

EitherFailureOr<User> getUser(int id) async {
  try {
    return Right(User.fromJson(await api.getUser(id)));
  } catch (error, stackTrace) {
    return Left(Failure(title: 'Could not load user', error: error, stackTrace: stackTrace));
  }
}

The notifier is a few lines:

class UserNotifier extends AutoDisposeBaseNotifier<User> {
  @override
  void prepareForBuild() {}

  Future<void> fetchUser(int id) => execute(
        ref.read(userRepositoryProvider).getUser(id),
        globalFailure: false, // show errors on this screen
      );
}

And the screen switches over the state:

switch (ref.watch(userNotifierProvider)) {
  BaseInitial() || BaseLoading() => const CircularProgressIndicator(),
  BaseError(:final failure) => Text(failure.title),
  BaseData(:final data) => UserCard(user: data),
}

Forget a case and it won't compile.

One call, many behaviors

execute() takes a few switches for the cases that come up again and again:

await execute(
  repository.saveProfile(profile),
  withLoadingState: false, // keep the form on screen
  globalLoading: true,     // dim the whole app instead
  globalFailure: true,     // show the error as a snackbar
);

Saving a form is the classic example. You don't want the form replaced by a spinner. You want an overlay, and an error message that leaves the user's input alone. That's one call instead of a page of state handling.

By default, failures go to a single BaseWidget near the top of your app, so you decide once how errors look. Pass globalFailure: false when a screen should show its own error, like the user screen above.

Pagination without the edge cases

Paginated lists are where hand-written notifiers usually break. You load page 2 twice, or an error wipes out the 40 items already on screen.

PaginatedNotifier handles that. You write one method that loads a page:

@override
PaginatedEitherFailureOr<User> getListOrFailure(int page, [void parameter]) =>
    repository.getUsers(page: page);

The notifier tracks the page, ignores duplicate "load more" calls, and keeps the loaded items when a page fails. Your screen calls getNextPage() when the user nears the end, and refresh() for pull to refresh.

When you don't need it

For a small app with two or three screens, Riverpod's own AsyncNotifier and AsyncValue are enough. Adding base classes there is more structure than the app needs.

It pays off when you have dozens of screens and want them to load, fail, and paginate the same way. It also helps when a new teammate should be able to open any notifier and know where everything is.

The package started as a Riverpod 3 port of Q Agency's Q-Architecture, and the credit for the original design is theirs.

Try it yourself

Pick one screen that loads data and move its notifier to BaseNotifier. If it feels lighter, do the next one. The example app has a single user screen and a paginated list:

NoaTubic / riverpod_architecture

A Flutter state management architecture built on Riverpod 3.0, providing reusable notifier classes and utilities for clean, scalable applications. This package reduces boilerplate by providing standardized patterns for handling state, errors, pagination, and data mapping.

Riverpod Architecture

A Flutter state management architecture built on Riverpod 3.x, providing reusable notifier classes and utilities for clean, scalable applications. This package reduces boilerplate by providing standardized patterns for handling state, errors, pagination, and data mapping.

Features

Modern Riverpod 3.x: Fully migrated to latest Riverpod with Notifier base classes
State Management: BaseNotifier for handling initial/loading/error/data states
Pagination: Built-in PaginatedNotifier with infinite scroll support
Error Handling: Functional error handling with Either<Failure, T>
Global Providers: App-wide loading, failure, and info notifications
Data Mapping: Mappers for API responses, forms, and requests
Type Safety: Sealed classes with pattern matching
Auto Dispose: Memory-efficient with auto-dispose variants

Installation

Add to your pubspec.yaml:

dependencies:
  riverpod_architecture: ^1.0.6
  flutter_riverpod: ^3.2.1
  either_dart: ^1.0.0

Then run:

flutter pub get

Quick Start

1. Add `BaseWidget` through `MaterialApp.builder`

BaseWidget shows the global loading overlay and reports global failures…

View on GitHub

https://pub.dev/packages/riverpod_architecture

Feedback and issues are welcome on GitHub.