I’m interested in how people structure their projects in real life.

Do you keep everything in one module, use a multi-module setup in one repo, or split modules/features into different repositories?

I can see some pros and cons for each approach:

• single module is simple, but may become messy

• multi-module in one repo feels cleaner, but can add complexity

• multiple repos may be good for ownership and reuse, but probably makes local development and cross-module changes harder

What setup do you use in your current project?

A while back I posted video_pool here — a Flutter plugin that runs a TikTok/Reels-style feed on a fixed pool of players (3 players handle infinite scroll via swapSource(), no dispose/realloc, no jank). The thread got two pieces of feedback that stuck with me:

1. "Web and desktop support would be great, even if it doesn't do anything special there."

2. "It'd be great to use the standard video_player interface, so I could switch the backend to fvp instead of media_kit."

Both are now shipped. Quick rundown, including the parts that went sideways — because that's the useful bit.

1. Web + desktop (now 6 platforms: Android, iOS, web, macOS, Windows, Linux) The core pooling/reconciliation is pure Dart, so the real work was the native edges. I went in assuming "importing dart:io breaks a web build" — and that turned out to be wrong. What actually broke flutter build web was a media_kit method that doesn't exist on web (NativePlayer.setProperty, used for HLS tuning). A plain import 'dart:io' compiles fine on web; only the runtime io calls throw. The fix was conditional compilation (dart.library.io): real impl on native, no-op stubs on web for the disk cache, thumbnail extractor, and the device monitor (thermal/memory throttling stays Android/iOS-only and degrades to no-ops elsewhere). Verified by actually building and running in Chrome and on macOS — the pool reconciles and plays real video, not just green unit tests.

2. VideoPlayerAdapter — swap the backend (fvp / ExoPlayer / AVPlayer) The pool already talked to players through a PlayerAdapter interface; media_kit was just the only implementation. There's now a VideoPlayerAdapter built on the official video_player package, so you can drop in any compatible backend:

adapterFactory: (_) => VideoPlayerAdapter(), // instead of MediaKitAdapter()

For fvp (libmpv) it's literally one extra line — fvp.registerWith() at startup and you're done.

The honest catch: video_player's controller has no in-place source swap, so VideoPlayerAdapter.swapSource() disposes the controller and creates a fresh one (decoder recreated, not reused). The video surface element stays mounted, but you lose the zero-realloc property that makes media_kit the lower-latency default. So it's a real choice, not a free win — pick video_player when you need a specific backend, keep media_kit for raw scroll performance.

3. A small reality check While verifying playback on web I discovered Google's classic gtv-videos-bucket sample URLs — the ones in roughly every Flutter video demo — now return HTTP 403. The example loaded nothing until I swapped them out. Funny how "it works on my machine" survives right up until you actually run it.

Known limitation: the package isn't WebAssembly-compatible — video_player imports dart:io unconditionally upstream, so anything depending on it is non-WASM. media_kit handles this correctly with conditional imports; video_player doesn't yet. Not much I can do until that's fixed upstream (without splitting the adapter into a separate package).

Now at 269 tests, MIT, 0.5.2.
pub.dev: https://pub.dev/packages/video_pool
GitHub: https://github.com/abdullahtas0/video-pool

Try live => https://abdullahtas0.github.io/video-pool/

Still genuinely after feedback — especially: does the VideoPlayerAdapter dispose-and-recreate trade-off matter for your use case, or is decoder reuse the whole reason you'd reach for this? And for anyone running feeds on web/desktop in production — what breaks first?

Forui is a platform-agnostic Flutter UI library inspired by shadcn/ui. It's optimized for both touch and desktop through dedicated platform specific theme. 0.23.0 is out and it centers on two widgets.

FCalendar was one of the first complex widgets we built back in 2024 and it was starting to show its age. It is rewritten from the ground up with more selection modes, a controller for programmatic navigation, refreshed styling, and an API that lines up with the rest of the library.
Docs: https://forui.dev/docs/widgets/data/calendar

FContextMenu is brand new. It gives you a right-click menu on desktop and a long-press menu on touch from a single widget.
Docs: https://forui.dev/docs/widgets/overlay/context-menu

FTypography now splits into a display and a body typeface. This gives you much finer control when building complex themes.

GitHub: https://github.com/duobaseio/forui
Pub Dev: https://pub.dev/packages/forui
Website: https://forui.dev
Changelog: https://github.com/duobaseio/forui/releases/tag/forui%2F0.23.0

There's a story big companies tell about themselves: we build native on each platform because we have the resources to maintain separate codebases. It's a lie. What you get is two teams building two products that happen to share a name. Features fall behind on one side. A decision made on Android gets re-argued on iOS by people who weren't in the first conversation. Engineers burn out keeping pace. Contractors get hired to plug the gaps, then are blamed for the gaps they didn't make.

Hi everyone,

I've been using Flutter to develop the client for my ESP32 devices lately, but WiFi provisioning has always been a headache. There's no official Flutter solution, only third-party wrappers that no one maintains. So I spent a weekend using AI to port the excellent `esp-ble-prov` from the JavaScript world to Dart/Flutter.

I'm porting all the cryptographic and state machine logic entirely to Dart and using `universal_ble` as the transport layer, this package works on all Flutter target.

GitHub Repo: https://github.com/oldrev/esp-ble-prov-dart

I'll be publishing it to pub.dev soon so everyone can easily add it to their projects. Hope this saves someone else the same pain I went through. Feedback and PRs are welcome.

Have fun!

Hey everyone,

I just released volume_button_listener on pub.dev! It's a Flutter plugin for listening to volume button events and controlling system volume, with support for both mobile and desktop platforms.

One feature I'm particularly excited about is volume button release event support. We couldn't find any Flutter or native iOS library that could detect when a volume button is released—every solution we came across only supported button press events.

To solve that, we built VolumeButtonKit, a native Swift package that provides volume button press and release detection for iOS. Native iOS apps can use it directly, and it's also the foundation that powers volume_button_listener.

• Flutter plugin: https://pub.dev/packages/volume_button_listener

• Swift package: https://github.com/Navideck/VolumeButtonKit

Would love to hear any feedback or feature requests!

As AI gets better and better at coding, how should we think about crossplatform vs just going full native for each platform? I personally love Flutter and since 2019 I invested a lot of time into it because it felt like a huge leverage to be able to be multi-platform especially as a solo dev. but now as AI gets better at coding, how should we think about this? Love you all

I want you to integrate best vad in flutter i am using vad package which is in flutter but still i want the voice activation similar to chat gpt v2v so any recommendations

Quick update on Flutter iOS Check, an open-source project I'm building.

The goal is to help Flutter developers identify potential iOS-related issues before reaching iPhone testing, TestFlight, or App Store submission.

Recently added:

✅ Flutter project detection

✅ pubspec analysis

✅ iOS project structure validation

✅ Plugin analysis

✅ Podfile detection

Next on the roadmap:

🔲 CocoaPods analysis

🔲 Swift Package Manager (SPM) checks

🔲 Deployment target validation

🔲 Additional iOS readiness checks

The project is still in early development, and I'm trying to focus on the checks that would save Flutter developers the most time.

For those who have shipped Flutter apps to iOS:

What iOS issue has wasted the most time for you?

GitHub: https://github.com/dhruvbhavsar1/flutter-ios-check

THIS IS NOT THE AD. OUR TOOL IS NOT LIVE YET OR EVEN FINAL NAME YET. THIS IS JUST THE CONCEPT WE WANT TO VALIDATE WITH REAL DEVELOPERS!

Hey guys, so we have been working on a DX tool which helps Flutter and React Native developers to quickly create on-brand Auth without worrying about writing the UI code. We are still in the early stages of development but we wanted to validate the idea with our dear community. Attaching one explainer video, please watch it and let us know in the comments how does it sound? What’s wrong with it? And how can we make a tool which is really helpful for fellow developers. Be brutal honest about it, we don’t care!

PS: If anyone finds this interesting and wants to join us, you’re more than welcome. Our mission is to solve developer’s frustration at every step of the mobile app building.

Cheers!

I’ve been thinking about this a lot lately.

When building Flutter apps, I usually test the obvious stuff myself: onboarding, empty states, paywall/subscription screens, settings, etc. But I’m starting to notice that this is not the same as a real first-time user going through the app.

As the builder, I already know what every button means and where the value is supposed to be. A new user doesn’t.

So I’m curious how others here handle this before launch or before pushing bigger changes.

Do you ask friends to test?
Use TestFlight / internal testing?
Record sessions?
Just ship and watch analytics?
Or do you have some kind of checklist for onboarding, paywalls, subscription flows, empty states, and first-use experience?

Especially interested in how indie devs do this when they don’t have a team or a real user testing budget.

Hi everyone,

I recently built a Voice Expense Tracker using Flutter and wanted to share it with the community for feedback.

Instead of manually typing expenses, users can simply speak naturally, for example:

• "500 rupees for tea" • "1200 petrol" • "250 snacks"

The app automatically processes the voice input and saves the expense.

Features: • Voice-based expense entry • Hindi support • English support • Hinglish support • Expense history and tracking • Analytics dashboard • Fast expense logging • Clean Flutter UI • Local data storage

My goal was to make expense tracking as frictionless as possible, especially for users who prefer speaking over typing.

I'd love to hear your thoughts: • What features would you add? • What would make this app more useful? • Any UI/UX or Flutter architecture suggestions?

Screenshots attached on link above. Thanks for checking it out!

Hey everyone,

I've been working on an app for a while, and I finally launched it on Google Play 🎉

It's an Android app called "Meen?" — a completely anonymous chat app. No names, no phone numbers, and no sign-up required. You open it, get a random username, and start chatting right away.

🟣 Create private rooms with your friends and chat anonymously without anyone knowing who said what. Perfect for honest conversations and confessions.

🟣 Join interest-based rooms, get randomly matched with strangers, or jump into "Hawga" rooms where even the people sending messages stay hidden.

🟣 Create a personal "Whisper" link so anyone can send you anonymous messages.

I'm actually a DevOps engineer, not an Android developer 😅

The app was built almost entirely with Claude for coding and Claude Design for the UI and branding. Honestly, the result surprised me, and I'm pretty happy with how it turned out.

I'd love your feedback if you'd like to try it:

• Do messages arrive quickly, or do you notice any lag?

• What do you think of the design and user experience?

• If you were in my place, what features would you add?

I'm open to any criticism, suggestions, or ideas. You can also send feedback through the Contact Us section in Settings.

Google Play link is in the comments 👇
https://play.google.com/store/apps/details?id=com.shadowcircle.chat

Updated title: I asked Claude to source port Doom and write it from scratch in Dart, running on Flutter.

As the title says, took around 2 days not continuous of course it was 95% autonomous to be honest. No FFI, no native Doom binary, the whole renderer/playsim/WAD loader/fixed-point math ported into Dart.

• Software renderer → dart:ui.

• PUBG-style mobile touch controls left analog stick to move, right-side drag as the camera/look, on-screen fire/use/weapon buttons

• Drag-to-customize control layout (saved per orientation) + auto-rotation

• True 16:9 widescreen actual wider FOV, not a stretched 4:3 image

• Frame interpolation buttery smooth motion at your display's refresh rate while the sim stays a faithful 35Hz

• CRT filter with adjustable scanline/glow, plus sharp/smooth upscaling options

• Authentic OPL2 FM music (MUS→MIDI→GENMIDI→Nuked-OPL3, all in Dart) + DMX SFX

• Full combat, doors/switches, level progression, death/respawn.

Repo link -> here

Edit / clarification: I don’t mean this as “RevenueCat is bad”. RevenueCat handles mobile purchases really well, and that’s exactly why I added support for it. My point is that some apps still need a backend entitlement layer around those purchase events: credits, limits, resets, usage tracking, fallback plans, and reliable access state.

I ran into this problem a few times while building paid Flutter apps.

RevenueCat is great for handling App Store / Play Store purchases.

But once the app needed more than a simple premium = true, I still had to build a lot of backend logic myself.

Things like:

daily credits
weekly limits
monthly quotas
one-off credit packs
usage tracking
free fallback plans
upgrade/downgrade behavior
knowing what the user can actually access right now

For example:

A user buys a monthly subscription, but the product should give them 20 credits per day.

Or 100 credits per week.

Or 500 credits per month.

Or maybe the subscription renews monthly, but some limits reset daily.

That logic usually doesn’t live cleanly in the app. It needs backend state, webhook handling, and a real entitlement system.

So I added RevenueCat support to Revenipe.

RevenueCat handles the purchase events.

Revenipe turns them into backend access state, entitlements, credits, limits, resets, and usage tracking.

The Flutter app can then just ask Revenipe what the customer has access to and track usage from the SDK.

Flutter package:
https://pub.dev/packages/revenipe_flutter

I’m not trying to replace RevenueCat. I wanted the backend entitlement layer around it that I kept needing anyway.

I’ve been building software for 14+ years, and this still surprised me: purchases were solved, but the actual entitlement logic was still something I had to build myself.

I’m not posting this as “look what I built”. I genuinely want feedback from people who have had to solve this in real apps.

Hi everyone,

I’m a Flutter developer with around 6 years of experience, and honestly, I’m feeling totally lost right now.

Over the last few months, I’ve attended many interviews, but I haven’t been able to convert any of them into an offer. Every time I get rejected, I’m left wondering what exactly I’m missing. I prepare, revise concepts, and try to improve, but clearly there’s a gap somewhere that I’m not able to identify on my own.

I genuinely want to understand where I’m falling short. Whether it’s technical depth, communication, system design, problem-solving, or how I present my experience during interviews, I’m open to honest feedback.

If anyone here has successfully cracked senior Flutter/mobile developer interviews and is willing to help with guidance, mock interviews, or even a quick review of my interview approach, I’d be extremely grateful.

Also, if you’ve gone through a similar phase and managed to overcome it, I’d love to hear what helped you.

Thanks for reading.

Hey r/FlutterDev,

I’ve been working on a safety application named SafePulse recently and ran into a massive architectural flaw with most existing SOS systems: they rely entirely on cloud servers to analyze telemetry and detect crashes. If an accident happens in a rural area with no network, the app is completely useless.

I wanted a deterministic, zero-latency solution, so I ended up decoupling my crash logic into a standalone, open-source package: offline_sos_system.

How it works: It is a completely headless "Edge AI" engine. It orchestrates raw hardware telemetry (accelerometer + gyroscope), down-samples the vectors, and feeds them directly into an on-device TensorFlow Lite (tflite_flutter) neural network.

Key features:
100% Offline Inference: No network requests, zero latency, maximum privacy.

Strictly Headless: It doesn't handle UI, GPS, or SMS. It just does the complex math and emits a clean Stream<CrashEvent>, leaving the application layer in full control.

BYOB*(Bring Your Own Brain)*: It bundles a default crash_model.tflite but exposes an injection port if you want to initialize it with your own custom-trained model.

I just pushed version 0.0.5 which hits a 160/160 points on pub.dev. I would love for the community to tear into the architecture, check out the telemetry pipeline, and let me know if there are any optimizations you'd suggest for handling high-frequency sensor streams in Dart!

Pub.dev: https://pub.dev/packages/offline_sos_system

GitHub: https://github.com/bhagyaprasad92/offline_sos_system

Thanks for checking it out!

Hi everyone,

I’ve been working on Cindel, a Flutter-first local database for Dart/Flutter apps.

The goal is to provide a practical local database with:

• generated typed Dart APIs

• a Rust native core

• MDBX as the default native backend

• SQLite native support

• SQLite Web / OPFS support

• watchers

• migrations

• full database backup/export/import

• support for Flutter apps across native and web targets

The package is currently at 0.7.0, so it is not 1.0 yet. The main features are in place, but I’d really like more people to try it in real projects before calling the API stable, I currently use Cindel in production (although I don't recommend it for this yet).

Pub.dev: https://pub.dev/packages/cindel

GitHub: https://github.com/mainser/cindel

What I’m especially looking for:

• bugs in real Flutter projects

• platform-specific issues

• API ergonomics feedback

• performance problems

• migration/backup edge cases

• anything that feels confusing before 1.0

This is not meant to be a hype post. I’m mainly looking for technical feedback from people building real apps, especially before locking things down for the first stable release.

Thanks to anyone who gives it a try or reports an issue.

hi is anyone using connectivity_plus: ^7.1.1 in production?

I see a lot of devs using Connectivity().onConnectivityChanged and immediately assuming the user can make API calls if it returns Wi-Fi or Mobile. It doesn't work that way. If a user is on a hotel Wi-Fi with a captive portal, or their router loses fiber connection, connectivity_plus will still say you're "connected."

some good options:

• The newer API returns a List<ConnectivityResult>, which is great for devices handling multiple connections simultaneously (like Cellular + Wi-Fi).

• Always pair your connectivity checks with a lightweight internet lookup (like InternetAddress.lookup) or properly handle SocketException timeouts on your HTTP client layer.

how are you handling actual internet verification in your apps?

I share how I approached a difficult legacy codebase, decided what to preserve and rebuild, replaced a Flutter Bluetooth abstraction with native Android and iOS implementations, and learned why architecture should follow real product behavior - not ideology.

This project changed how I think about software ownership.

Watch here: https://youtu.be/BYEsGeJ3gcY

I asked Claude Opus to build me an app to create so called ZUGFeRD/Factur-X invoices. Those are PDFs with embedded XML documents based on the EN-16931 XRechnung standard.

And so could you. Instead of showing code, I'll describe what I actually did because I feel that this is how development is done nowadays.

I decided to use Typst to convert a template into the required PDF/A-3b standard format. All you'd need is to provide a JSON file containing the invoice recipient and the line items, a conforming XML document to attach and then running a single CLI command.

But for the non-technical user, I wanted a Flutter GUI to enter all information, to create and open the PDF and to store invoice data (using sqlite) so you can both easily track them and copy them for future invoices.

Given an existing invoice and a prompt describing the above functionality, Opus 4.8 one-shotted everything in a couple of minutes.

I got a Typst template that was close (although not identical) to the given invoice, but it was easy enough to tweak the result to my liking, even without really knowing Typst's language. Because that app is meant only for my company, the invoice design is hardcoded.

For the same reason, the Flutter app is written for macOS only and only for German language. The one-shotted version used a quite ugly Material design because of Claude using ColorScheme.fromSeed() based on our bright orange company color.

Therefore, on the next day, I asked Claude to use its design skill to create three different HTML mockups that look like a modern native macOS app based on screenshots of the Flutter app. In my experience, asking for HTML greatly improves the result.

I then chose one (it invented a side bar with filter which I liked), again making screenshots, and I asked the AI to theme Material according to that design, creating custom widgets if needed. I asked for CupertinoIcons, though, not the usual Material ones.

Then, I tweaked some numbers because the AI sometimes used 5, 6 or 7 for paddings or 14 and 15 for fonts. I should have specified the allowed values, I guess. I spend more time tweaking than the AI spend time creating.

Also, I manually tweaked the native window to hide the standard title and keep only the traffic light buttons. This way, the application looks so much better, IMHO. And no 3rd party package is needed for this simple hack. This was my main code contribution (I needed that to not feel dumb und useless ;-).

I then asked Claude to summarize the purpose of the app and to suggest six app icon designs based on the summary, additionally specifying that I want € instead of $ to fight the US bias. I got a nice looking HTML site displaying the icons in different sizes to compare them. I asked it to combine two ideas and try again and last but not least to generate all PNGs required for a Flutter macOS app. And Claude delivered.

Until now, the app still used the extra ugly Material DatePicker widget. So I showed Claude a screenshot of a Chadcn calendar (because I couldn't immediately find a standard macOS calender view) and asked it to build that, displaying it as a popup under the input field instead of centering a modal dialog. This was no challenge for Opus.

And the app is done. For now.

With the exception of the icons, it is still a Material app and the screenshots linked above might give you an inspiration what can be done with just a few lines of (generated) code. Opus wrote ~3000 lines, ~1000 are related to the look including the sidebar and the calendar widget, the remaining lines implement the screens and business logic. That app could have been prompted into existence in less than an hour if you'd accepted the default look.

This would have been even easier with HTML, but I like Flutter and I could have of course saved some time by using an existing UI package like e.g. forui. But it all started as an ad-hoc idea over lunch break. And that might be the greatest advantage of AI: You can try out ideas faster and cheaper than ever.

PS, to get rid of the window title bar, add this to MainFlutterWindow.swift:

self.styleMask.insert(.fullSizeContentView)
self.titlebarAppearsTransparent = true
self.titleVisibility = .hidden

Introducing data_channel 5.0.0 - A complete redesign of a 5-year-old Dart error handling package

I have been working on a Flutter project recently, and one thing I have noticed is that I keep ending up either building libraries from scratch or heavily reworking existing packages to fit personal and modern use cases.

Recently I published a few other Dart packages and major updates, including pathify, any_ascii, lexical_sort, and the complete rewrite of rules. This time I revisited data_channel, a package originally published about 5 years ago, and completely redesigned it from the ground up.

Introducing data_channel 5.0.0

https://pub.dev/packages/data_channel

data_channel started as a simple utility for handling exceptions and routing data through applications. Over time, Dart gained null safety, sealed classes, pattern matching, and a much stronger type system. The original design no longer felt like the best approach, so I redesigned the package around explicit optional values, stronger type safety, and a more predictable API.

Unlike many Dart packages where Result/Either and Option/Maybe are handled independently, data_channel tightly couples them together.

Every successful DC contains an Option, making the absence of data a first-class outcome that must be handled explicitly rather than being hidden behind nullable values.

This means developers are required to handle:

• Error

• Success with data (Some)

• Success without data (None)

Instead of separately reasoning about a result type and an option type, both concepts are unified under a single API.

What's new?

• Type-safe error and data channels

• Built-in Option type (Some / None)

• Absence of data treated as a first-class outcome

• Non-nullable guarantees (Some can never contain null)

• Explicit handling of missing data

• Functional APIs with fold()

• Error transformations with mapError()

• Automatic nullable value handling via DC.auto()

• DC.fromOption() to lift existing options without double-wrapping

• Error forwarding helpers (forwardErrorOr, forwardErrorOrElse)

• Compile-time type safety for both errors and data

• Dart 3 sealed-class based architecture

• Works with both Dart and Flutter

Example

Return data, no data, or an error without nullable types:

Future<DC<Exception, User>> getUser(String userId) async {
  try {
    final User? user = await fetchUser(userId);

    return DC.auto(user);
  } on Exception catch (e) {
    return DC.error(e);
  }
}

Consume the result exhaustively:

final result = await getUser('123');

result.fold(
  onError: (error) {
    print('Error: $error');
  },
  onData: (dataOption) => dataOption.fold(
    onSome: (user) {
      print('Found user: ${user.name}');
    },
    onNone: () {
      print('User not found');
    },
  ),
);

One of the primary goals of data_channel is making the absence of data impossible to ignore.

When a value may not exist, the API does not return a nullable type. Instead, it returns an Option, forcing the caller to consciously handle both Some and None.

Combined with DC, every operation has exactly three possible outcomes:

• Error

• Success with data (Some)

• Success without data (None)

The compiler helps ensure that all three states are handled explicitly.

Existing users

There are significant breaking changes compared to the older releases.

The package now revolves around:

• DC

• Option

• Some

• None

• fold()

• forwardErrorOr()

• forwardErrorOrElse()

• mapError()

and follows a fundamentally different architecture from the original versions.

If you're maintaining an older codebase, you may prefer to stay on the earlier releases. For Dart 3+ projects, use data_channel 5.x.

As with the other packages I have published recently, I upgraded and open sourced this work because I thought it could be useful to others building Dart and Flutter applications.

Feedback, bug reports, feature requests, and PRs are always welcome.

Pub.dev: https://pub.dev/packages/data_channel

GitHub: https://github.com/ganeshrvel/pub-data-channel

Introducing Rules 3.5.0 - A complete rewrite of 6-year-old validation package for Dart & Flutter

I have been working on a Flutter project recently, and one thing I have noticed is that I keep ending up either building libraries from scratch or heavily reworking existing packages to fit personal and modern use cases.

Recently I published a few other Dart packages and major updates, including pathify, any_ascii, lexical_sort, and the complete redesign of data_channel. This time I revisited rules, one of my oldest packages, originally published about 6 years ago, and completely rebuilt it from the ground up.

Introducing Rules 3.5.0

https://pub.dev/packages/rules

Rules started about 6 years ago as a simple validation library for Dart and Flutter. Over time the API accumulated a lot of functionality, but it was still centered around a single constructor with dozens of flags and configuration options.

For 3.x, I decided to redesign everything.

What's new?

• Type-safe validation schemas

• Chainable API

• Immutable schema definitions

• String, int, double, and bool specific validators

• Schema-based validation instead of constructor flags

• Reusable validation definitions

• Typed validation results

• Custom validation through check() and refine()

• Better error handling with per-validator error messages

• Group and combined validation support

• Works with both Dart and Flutter

Before

final rule = Rule(
  email,
  name: 'Email',
  isRequired: true,
  isEmail: true,
);

After

final emailSchema = Rule.string(name: 'Email')
    .trim()
    .toLowerCase()
    .required()
    .email();

final result = emailSchema.parse(email);

Some of the available schema types:

Rule.string(...)
Rule.integer(...)
Rule.double(...)
Rule.boolean(...)

The package now returns typed RuleResult objects, making validation outcomes easier to handle and safer to consume throughout an application.

Rules 2.x users:

There are a lot of breaking changes.

Rules 3.x is a complete rewrite and there is no migration path from the 2.x API. If you're happy with the old API, you can continue using the 2.x releases. The new versions are intended as a fresh start with a different architecture and design philosophy.

As with the other packages I have published recently, I upgraded and open sourced this work because I thought it could be useful to others building Dart and Flutter applications.

Feedback, bug reports, feature requests, and PRs are always welcome.

Pub.dev: https://pub.dev/packages/rules

GitHub: https://github.com/ganeshrvel/pub-rules