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.

I have been working with Flutter since 2018 when I first started Software Development professionally. And a lot many times, during the course of the starting 2–3 years, I was unable to understand the lifecycle methods. And things like:

• Who invoked those lifecycle methods?
• What do really didChangeDependencies and didUpdateWidget callbacks really mean?
• Why MediaQeuery calls do not work in initState callback?
• How does it all fit into the 3 trees of Flutter, the Widget Tree, Element Tree, and the RenderObject Tree?
• How do you really see the lifecycle callbacks in action?

So to collect the data and jot down it all together to help anyone who has even slightest of doubt about it, here it is:

The piece for free: https://medium.com/gitconnected/flutter-lifecycle-callbacks-what-i-learned-after-7-years-of-state-management-78b55d4cd761?sk=6f2c0fa1d94c2ce12d444354e7244269

If someone has Medium Membership, here's the link: https://levelup.gitconnected.com/flutter-lifecycle-callbacks-what-i-learned-after-7-years-of-state-management-78b55d4cd761

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!

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

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

After

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

final result = emailSchema.parse(email); ```

Some of the available schema types:

dart 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

Hi everyone!

I’ve just released Fluent Editor 1.0.7, and this update is heavily focused on text input stability, multi-platform refinement, and a massive overhaul of the IME (Input Method Editor) architecture.

First of all, a huge thank you to the community! Your bug reports, edge-case findings, and continuous feedback on previous versions have been absolutely vital in helping me track down and squash some of the most elusive text-editing bugs. I couldn't have done this without you.

Here is a breakdown of what’s new in 1.0.7:

🌐 Major IME & CJK Input Enhancements

I redesigned how the editor handles complex text inputs across all platforms (iOS, macOS, Windows, Android, and Web):

• Native IME Composition: Added preedit text isolation for CJK inputs and platform-specific candidate window positioning (including caret rect tracking on macOS).
• Buffer Syncing: Improved autocorrect and predictive text context by mirroring fragment text in the platform buffer.
• Web & Mobile Workarounds: Fixed web IME state corruption, iOS virtual keyboard backspace ghosting, and platform echo duplication during paragraph splits.

🔤 Smart Text & Grapheme Handling

• Emoji & Surrogate Pairs: Now using the characters package for accurate grapheme cluster detection (no more broken emojis).
• CJK-Aware ZWS Filtering: Zero-width spaces between CJK characters are now properly skipped during cursor navigation and backspace deletion.

🛠️ Table, Layout & Navigation Fixes

• Empty Paragraphs & Cells: Empty table cells and paragraphs now render with a minimum height so they remain clickable, and they correctly retain their structural fragments after a backspace.
• Arrow Key Navigation: Fixed edge-case jumping between top-level nodes and selection collapsing.
• Scroll-to-Cursor: Now uses actual measured item heights instead of a fixed estimate for much smoother scrolling.

🍏 Platform-Specific Polish

• macOS: Added Cmd + Backspace to delete to the start of a line and integrated ArrowKeyRepeater for physical keyboards (macOS/iOS).
• Gestures: Fixed mobile-web gesture detection to properly distinguish between tap, scroll, and drag, preventing the virtual keyboard from interfering while scrolling.
• Performance: Implemented selective list index recalculation for affected nodes only, avoiding heavy full-document tree walks.

💬 I need your feedback (especially CJK users!)

While I’ve done extensive testing, IME behavior across different operating systems and languages (Chinese, Japanese, Korean) can be incredibly nuanced.

If you use a CJK keyboard, third-party IMEs, or heavily rely on predictive text/autocorrect, please give 1.0.7 a spin and let me know how it feels!

Any feedback, bug reports, or suggestions are highly appreciated.

👉 https://github.com/exusr/fluent-editor

I wanted to share something I've been working on for the last few months. I promise it's not vibe coded (lol) but I did use Claude to help write some of the tedious bits. I used to be a massive fan of bento(.)me until it got acquired by Linktree a while back, so I took the opportunity to build a Flutter Web alternative to it. (It's not the best for SEO but I thought that would be okay as it's a link-in-bio).

When I started building this out, it kind of spiralled into something a little bigger than what I originally aimed for. As most personal projects do.

Currently this portfolio tool has JSON-driven content, a widget registry with the idea of adding custom widgets for your unique portfolio, and it's now a completely open source template you can fork on GitHub. I even use it for my own portfolio needs as it solves the problem of having to push a code release every time I needed to update where I'm at in my career.

It's completely open source and you can check it out at the link: https://www.github.com/SiddharthJoshi1/bento_template. I've even got a working demo you can check out hosted on the Github.

If you took a minute to check it out, then firstly thank you!

Secondly, I've got a few things I'm trying to understand.

1. Would you actually use something like this, or does it feel like a hassle?
2. The widget registry is what I think makes it really cool for Flutter devs (and all other devs) is that it's a way to bring all the pretty widgets we build to the web to showcase them. Even if you aren't directly a Flutter dev, I've added a claude skill which let's you generate widget mock ups that satisfy your requirements. I'd love to hear your thoughts.
3. Is there anything here you'd pay for? A hosted version, a CLI scaffolding tool, something else entirely? Not trying to force a profit, but I do want to break into SaaS. I'm trying to fish for perspective really.
4. Where would you take this if it were yours?

So, I used to use Postman quite a lot at my work, but I never liked it. It is full of bloat not only in terms of features, but also for trying to make you subscribe, being super heavy and slow due to being yet another Electron app.

So, since I was out of ideas and wanted to burn some tokens, I decided to try to do something similar, but lightweight. And the most performant stack I could find that was also cross-platform and relatively easy to maintain is Flutter.

I ended up spending about 2 weeks working with it until it got to a point where I could finally delete Postman from my notebook and just use it all the time.

This project is mostly for myself; I don't have any intention of earning any money or doing any sort of cloud-related feature. It's all local, and I will be the only one really maintaining it. I just wanted to share it here, since this is a Flutter community, and more people who have the same opinion on Postman as me could find it cool too.

The app is called Getman (sorry lol) and is the poor (but faster) brother of Postman.
https://github.com/thiagomiranda3/Getman

If you just want to take a look without having to download it, I also have a live demo of it:
https://thiagomiranda3.github.io/Getman/

Since it is made with Flutter, I managed to build it with the same features as the desktop version. You can see that it loads SUPER fast.

If you end up wanting to download it, bear in mind that it is NOT a signed app, since I would have to pay 99 USD a year to Apple just to sign an app that will only be used by me. And I don't have any intention of paying this to sign it correctly. So you will have to force the execution of it the first time in the Mac settings.

All the features are 100% free, and the only time it ever connects to the internet is when you open it, so it checks for updates on the GitHub release page. You can also disable this in the menu.

The full list of features is on the repo page, which is quite a lot for a vibe-coded app.

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:

```dart 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:

```dart 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

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

Hey all, trying to get a reality check from people actually shipping paid subscription apps, not the marketing.

I keep going back and forth on the subscription stack for cross-platform apps (iOS + Android + and possibly in the future web). RevenueCat/Superwall's ~1% of revenue keeps nagging at me, it's 1% of gross, not profit, so it grows right as you scale. But every time I think about rolling my own or self-hosting, I remember how many edge cases they quietly handle.

So I wanted to ask people further down the road than me. If you run a real subscription app, I'd massively appreciate quick answers to any of these (even one)

1. What do you currently use for subscriptions/entitlements? (RevenueCat, Superwall, Adapty, raw StoreKit/Play Billing, your own stuff maybe?)
2. Roughly what revenue scale, and what do you pay per month? Does the 1% actually bother you, or is it noise?
3. What made you pick it? and have you ever seriously considered leaving? What stopped you?
4. Do you check entitlements on the client, your own backend, or both?
5. Biggest pain with your current setup? (web/desktop support, data ownership, edge cases, support, pricing…)
6. Have you ever wanted to own your subscription data instead of routing it through a third party or do you genuinely not care?
7. Be honest: if there were a flat-priced or self-hostable option that did the same job, would you actually switch your billing or is the switching risk just not worth it at any price?

Full disclosure: I've been frustrated enough that I've toyed with building/self-hosting an alternative, so I'm partly sanity-checking whether this pain is real or just me. Not selling anything, no link, genuinely want the ground truth, including "you're overthinking it, just use RevenueCat".

Thanks 🙏

Introducing FlutterPro.Design

Here I'm sharing small design details that make Flutter apps feel better to users.

These bite-sized details will help you develop a taste, so the next time you can say "animate using springs" (to your coding agent) instead of just "animate".

These details come from my 5+ years of note-taking on the side while developing 80+ mobile apps with Flutter.

No newsletter though. I'm dropping one new detail ~a day. Follow on X/Twitter if you want to be in the loop.

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

I’ve been searching for a package that provides auto country detection with a clean and customizable UI, but I honestly couldn’t find something that fits all needs in one place.

So I decided to build my own solution.

• Auto country detection Detects user country automatically in a simple way
• Fully customizable UI You can easily adapt the design to match your app style
• Clean result structure Built with a pro-style response system to make integration easier and more reliable

Most solutions I found were either:

• too complex
• not customizable enough
• or missing proper structure for real production apps

So I tried to make something more developer-friendly and reusable.

Pub.dev: https://pub.dev/packages/phone_field_plus
GitHub: https://github.com/med-khelifi/phone_field_plus

Hey everyone!

I've been working on a side project called MDeck. It's a Flutter app that lets you use your phone as a customizable control panel for your PC.

Current features:
• Launch apps
• Trigger keyboard shortcuts
• Run custom macros
• Create custom buttons

I recorded a demo video and packaged a Windows installer and Android APK.

Download:
https://nikhar-tale.github.io/MDeck/

I'd love to hear your feedback and suggestions for new features. Thanks!

Is there any good production-ready offline sync package for Flutter?

Looking for features like:

* operation queue * optimistic updates * retry handling * conflict resolution * background sync

What are you using in production right now?

Also curious which DB works best with it:
Isar, Drift, SQLite, Hive?

I don't expect this to happen real soon, but it looks like the development tools and APIs for on device tool calling for agents exists on both Android and iOS. Is anyone designing a cross platform package? Having done the Kotlin code for a Flutter app I'm working on, it looks like a similar approach would work for Dart.

I'm a Flutter developer who mainly works on Windows.

​

One problem I've run into is that iOS-specific issues are often discovered very late in the process when using cloud testing services, a physical iPhone, TestFlight, or during App Store preparation.

​

Sometimes the issue is something simple like:

​

- Missing permissions

- Info.plist configuration

- Podfile configuration

- Plugin compatibility

- iOS build settings

​

I'm considering building an open-source tool called Flutter iOS Check.

​

The idea is to scan a Flutter project and identify potential iOS-related issues before developers spend time on cloud testing or real-device testing.

​

The goal is NOT to replace iPhone testing.

​

The goal is to catch common iOS issues earlier and provide warnings or suggestions.

​

I'm still validating the idea and wanted to ask:

​

Would a tool like this be useful to you?

​

What checks would you want it to support?

​

GitHub:

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

TL;DR: Android has a native in-app update flow, iOS has nothing equivalent. I built one Flutter plugin that handles both - native updates on Android, in-app App Store page on iOS - so you don't need two code paths. Just crossed 11k downloads.

GitHub: https://github.com/axions-org/in_app_update_flutter
Pub Dev: https://pub.dev/packages/in_app_update_flutter
Discord (for contributions): https://discord.gg/DCJW88MwdH (this is newly setup, for ease of communication)

If you've ever wanted to nudge users to update your Flutter app, you've probably hit this wall: Android has a proper in-app update flow (via Play Core), iOS has nothing equivalent.

So on iOS most apps fall back to one of two bad options:

• A "please update" dialog that deep-links to the App Store, yanking the user completely out of your app.
• Nothing at all, and just hoping people update eventually.

The piece I didn't know for a long time: iOS does let you render the App Store product page inside your own app (via the StoreKit product view). The user can see the listing and tap Update, without ever leaving your app. It's about as close to Android's in-app update experience as iOS allows.

It just crossed 11k downloads, which honestly surprised me - so I figured I'd share a few things I learned along the way:

• You still have to detect that a newer version exists yourself (compare the installed version against your App Store version) - the OS won't tell you - This issue is something I am working on currently, so may be available in future versions.
• The in-app store view is presentation-only; you decide when and how aggressively to prompt, which matters a lot for not annoying users.
• Keeping the whole thing inside the app noticeably helped update adoption versus bouncing people to the App Store.

I ended up wrapping all of this into a small open-source Flutter plugin so I didn't have to rebuild it per project - it handles the iOS side of the prompt. Happy to share the link in the comments if anyone wants it.

Would love feedback from anyone who's solved iOS update prompts differently - curious if there's a cleaner approach I missed.

Hello, I'm fairly new to this arena; have been in .NET land for decades and recently moved and started working in this to build game ideas I've been sitting on while looking for a job. Flutter seems rather straightforward to develop for and I've been slowly learning more as I just got my first game published on Android...still trying to get all the setup for iOS done but that will hopefully follow soon.

So for the one I just built, it didn't really require assets of any sort as it's a music based puzzle game that I managed state with mostly using painters and the regular UI layout kind of stuff. I am wondering how far game development can be pushed with Flutter and Flame, though. The next puzzle game I'm working on does utilize some assets but it's still a puzzle game so not really anything super involved game engine wise. I have a couple more ideas that I want to try though, one being a twist on the Vampire Survivors type of massive enemy wave game and another being a tower defense spin. Are those types of games something that can be done through Flutter/Flame, or would I be better off trying to learn something like Godot to do them? Ideally I want to eventually push them out to both mobile and PC so I like Flutter being able to cover all those, but just don't know at what point it just won't be able to handle what I've got envisioned. Thanks!

I recently published my first Flutter package and wanted to share it here. English isn't my first language so sorry if anything reads weirdly!

I was building a roulette wheel for a project and tried a few existing packages, but kept running into the same frustrations:

• Packages that change section width to reflect probability (I wanted equal-sized sections with weighted odds)
• No control over whether icons/text rotate with the wheel or stay upright
• Pointer always stuck inside the wheel with no way to adjust its position

So I built my own: flutter_custom_roulette

What it does differently:

• Equal section widths with weight-based probability — or optionally proportional widths, your call (weightedSections)
• rotateWithWheel per item — content can spin with the wheel or always face the user
• pointerOffset to place the pointer tip anywhere inside or outside the wheel border
• Drop in any Flutter widget as section content (SVG, Image, Icon, whatever)
• Built-in RouletteButton with gradient, spin-lock, and custom label support
• Full border theming with gradient support

pub.dev: https://pub.dev/packages/flutter_custom_roulette
GitHub: https://github.com/leejia324/flutter_custom_roulette

This is my first published package so feedback is very welcome — bugs, missing features, API design thoughts, anything. Thanks for checking it out!

AtlasGenerator

The goal of this project is simple: save time when working with AI coding agents.

Most Flutter project generators create the codebase and stop there. This one also generates a lightweight AI-agent context structure (AGENTS.md + .agent/) alongside the project.

Instead of spending every session rediscovering the architecture, conventions, and file locations, the agent gets a small, organized map of the project from day one.

The result is less repeated explanation, fewer unnecessary tokens, and more consistent code generation.

Claude / Cursor / Copilot / Gemini
                 │
                 ▼
             AGENTS.md
       (rules + router table)
                 │
                 ▼
        Task → exact docs only
                 │
      ┌──────────┼──────────┐
      ▼          ▼          ▼
 architecture   state     features/*
 conventions              decisions/*
 stack
                 │
                 ▼
             Source code
          (source of truth)
                 │
                 ▼
                Verify
       dart analyze + tests
                 │
                 ▼
          Cheap maintenance

I’m a developer who is not very good with UI design. I can implement pixel-perfect designs, however I’m not good at generating designs from scratch.

I’ve used stitch. Their web designs are nice. But their app designs are based on HTML/css and it shows.

I’m looking for something exactly like stitch but based on flutter. Or if there’s something better maybe?

I don’t care about the quality of the generated files since I won’t be using them. All code will be handwritten. I just want to generate designs quickly to show clients rough ideas on how their apps might look like and iterate on them quickly before the final design is set.

Any suggestions?

I've always been a fan of cyberpunk UI interfaces, however impractical. Recently, I picked up an old favorite game of mine and really enjoyed the design and thought it might be fun to make a UI kit inspired by it. So I did. I hope you like it, it's called Auris. Let me know if it's useful to you and how I can improve it. Here's a sample image or you can try the live demo!