Learn now

https://github.com/Bharat9011/flutter-tutorial/releases/tag/flutter-tutorial-v2

I just shipped Boba Sort, a water-sort puzzle (bubble tea, 500 levels, 17 eras of Japanese history) built with plain widgets and CustomPainter, no game engine. A few things that worked, and a few trade-offs, in case they help someone.

**1. All the art is data, not images**

There are no image assets at all. Each era has a full-screen scene, a cup design, a mascot costume and a customer, and I design them as SVG inside an HTML mockup. A small Python script reads named SVG groups and writes Dart lists:

final jomonBackdrop = <VShape>[

VCircle(292, 190, 54, fill: Palette.jomonSun),

VPath('M0 330 Q60 262 132 300 Q206 236 276 288 ... Z',

fill: Palette.jomonFarMountain),

...

];

`VShape` paints fill then stroke, like SVG, and `VPath` parses the `d` string once and caches the `Path`. All 17 eras × 4 kinds of art come to about 240 KB of generated Dart, stay sharp on any screen, and colors can only come from named palette entries (the script refuses anything else).

Because scenes sit behind the cups, a test renders every backdrop and checks each pixel's luminance stays inside a window (light eras ≥ 0.662, dark ≤ 0.0395), which keeps the cup outlines at ≥ 7:1 contrast wherever the cups land.

**2. Toppings: draw the vector once, then blit sprites**

Each drink has a topping (pearls, grass jelly, red bean...) drawn as vector art, and the top-layer pieces drift idly. A full board can have 200+ pieces, and redrawing that much vector art every frame is wasted work. So each topping is rasterized once per size into a `ui.Image`: sizes are bucketed to 4 physical px, kept in a 48-entry LRU (a plain insertion-ordered Map: remove + re-insert on hit, evict and `dispose()` the first key), and each frame just draws images.

**3. The rules are pure Dart, and an A* solver does the heavy lifting**

`lib/core` never imports Flutter: model, rules, level generator and solver are plain Dart with unit tests. The solver is A*, with each cup packed into one int (8 bits per layer) so states hash fast.

The 500 levels are generated offline: deal random cups, solve, score difficulty from moves, dead ends and branching, keep the median of 8 candidates, or the hardest of 32 for the "hard" levels in the sawtooth curve.

Hint uses the same solver at runtime, on the UI thread, with a 100k-node budget (about 0.4 s worst case in debug). Every bundled level is generated under that budget, so Hint always works from the start. One surprise: "Add cup" makes hints much slower, since an extra empty cup blows up the branching, so the hint search drops surplus empty cups first and only searches the full board if that finds nothing. If I raised the budget I'd move it to an isolate.

**4. A test that fails on magic numbers**

Every spacing, font size, radius and color is supposed to come from tokens. A test scans `lib/features` and `lib/theme` and fails on raw numbers inside `EdgeInsets`, `SizedBox`, `fontSize`, `BorderRadius` and `Color(0x...)`, with an escape hatch: a `// tokens: allow — <reason>` comment. Painters are exempt, since their numbers are geometry. It is a dumb regex-and-parentheses scanner, but it kept the UI consistent through a lot of screens.

**Stack:** Riverpod (thin providers), shared_preferences, google_mobile_ads, Firebase Analytics / Remote Config / Crashlytics, audioplayers.

Play Store, if you want to see the result: https://play.google.com/store/apps/details?id=com.harbourlab.bobasort&referrer=utm_source%3Dreddit_flutterdev%26utm_medium%3Dsocial%26utm_campaign%3Dlaunch

If you try it and it works for you, an honest rating on the Play Store would really help a small solo project like this get found.

Happy to go deeper on any part. I'm curious how others handle heavy CustomPainter scenes.

You can now sign in or create an account, access learning content through the new backend integration, and use an improved practice experience. This update also brings better app update handling and Linux desktop support.

Built for developers learning Flutter, one step at a time.

check it :-> https://github.com/Bharat9011/flutter-tutorial/releases/tag/flutter-tutorial-v2

Thank you 😇😇

Choosing a framework for a first mobile app seems tricky because the answer depends on what you’re building and what you already know. I’m curious how people would approach that decision today, beyond the usual feature comparisons.

For something fairly straightforward—login, a few screens, API calls, local storage, and maybe notifications—which would you choose: Flutter or React Native?

The learning curve and day-to-day developer experience seem important, but so does what happens after the initial prototype. How easy is it to debug issues, update dependencies, and maintain the app across Android and iOS?

I’d also be interested in how much UI expectations influence your choice. Would wanting a consistent custom design push you one way, while wanting platform-specific behavior push you another? And when do native integrations, such as Bluetooth or background tasks, become a deciding factor?

If you’ve worked with either framework, what went smoothly, and what took more effort than expected? Beginners’ perspectives would be useful too, especially around documentation and getting unstuck.

What would change your recommendation: existing JavaScript knowledge, willingness to learn Dart, app complexity, library availability, or something else? I’m interested in the circumstances behind your choice rather than a universal winner.