DEV Community: Hamber

Your Tests Pass. That Proves Nothing.

Hamber — Sat, 19 Sep 2026 14:02:07 +0000

Writing Flutter tests in the age of AI, where the scarce skill is no longer writing them.

Last year I shipped a fix for an audio glitch in GoGBA — a crackle at the seam where the emulator splices its ring buffer. I wrote four unit tests. All four passed. I committed.

The fix was inert. The tests never called the function that configured it. The ramp length was zero for the entire test run.

Worse: when I later went back and disabled the fix completely, two of those four tests still passed.

That is the story I want to tell, because it is the central problem of testing in 2026. AI has made writing tests nearly free. It has not made them true. The bottleneck moved — from "I don't have time to write tests" to "I have 1400 tests and I don't know which ones are load-bearing."

GoGBA is my GBA/GBC/GB emulator, built solo in Flutter, shipped on both stores. It has 1423 Dart tests that run in about a minute, plus a native C++ suite for the audio path. Most of them were written with AI assistance. This article is about the discipline that makes that number mean something instead of nothing.

1. The Asymmetry Nobody Priced In

Here is what actually changed when coding assistants got good.

Before: writing a test cost 10 minutes. Verifying it was honest cost 30 seconds. Nobody skipped the verification, because it was free relative to the writing.

After: writing a test costs 10 seconds. Verifying it is honest still costs 30 seconds.

The verification step is now 3x more expensive than the thing it verifies. Every incentive in your workflow now points at skipping it. And the output looks identical either way — a green checkmark.

This is not a complaint about AI. The generated tests are usually syntactically perfect, idiomatically correct, and well-named. That is precisely the problem: they are plausible. A test that is plausible and wrong is worse than no test, because it occupies the slot where a real test would have gone and it tells you the slot is filled.

The 2026 rule: a passing test is not evidence. A test that fails when you break the code is evidence.

2. Mutation Testing, By Hand, In 30 Seconds

You do not need a mutation-testing framework. You need a habit.

For every test you keep: break the code it covers, and confirm that specific test goes red.

Let me show you this on real GoGBA code, because the abstract version never lands.

The bug

GoGBA's D-pad has a dead zone — the centre 10% of the radius, so resting your thumb doesn't send phantom inputs. The original onPanStart looked roughly like this:

onPanStart: (details) {
  final localPosition = box.globalToLocal(details.globalPosition);
  // Only "activate" if the initial touch already resolved to a direction.
  if (_calculateDirection(localPosition).isNotEmpty) {
    setState(() => _isActive = true);
  }
  _updateDirection(localPosition);
},

onPanUpdate: (details) {
  if (_isActive) {            // <-- gated on that flag
    _updateDirection(box.globalToLocal(details.globalPosition));
  }
},

Read it and the bug is almost invisible. Play the game and it is brutal: your thumb rests at the centre of the pad. That is where the dead zone is. So the common gesture — land in the centre, push out to the right — starts inside the dead zone, never sets _isActive, and stays inert for its entire life. The D-pad simply does nothing until you lift off and tap again.

The fix is one line: a touch anywhere on the pad owns the gesture.

onPanStart: (details) {
  final localPosition = box.globalToLocal(details.globalPosition);

  // A touch anywhere on the pad owns the gesture, even one landing in
  // the dead zone: the thumb rests at the centre and pushes out from
  // there, and gating this on an initial direction left that whole
  // gesture inert until the user lifted off.
  hintUserInteractionResume(ref);
  setState(() => _isActive = true);
  _updateDirection(localPosition);
},

The test pair

testWidgets('a drag starting in the dead zone still steers', (tester) async {
  final session = await pumpPad(tester);
  final centre = tester.getCenter(find.byType(DPad));

  // Land dead centre, then push onto the right arm.
  final gesture = await tester.startGesture(centre);
  await tester.pump(const Duration(milliseconds: 16));
  await gesture.moveBy(const Offset(50, 0));
  await tester.pump(const Duration(milliseconds: 16));

  expect(
    session.events,
    contains((GBAButton.right, true)),
    reason: 'pushing out of the dead zone must register a direction',
  );

  await gesture.up();
});

testWidgets('resting in the dead zone presses nothing', (tester) async {
  final session = await pumpPad(tester);
  final centre = tester.getCenter(find.byType(DPad));

  // Hold near the centre and jitter inside the dead zone.
  final gesture = await tester.startGesture(centre);
  await tester.pump(const Duration(milliseconds: 16));
  await gesture.moveBy(const Offset(3, -2));
  await tester.pump(const Duration(milliseconds: 16));

  expect(
    session.events.where((e) => e.$2),
    isEmpty,
    reason: 'the dead zone must still swallow thumb jitter',
  );

  await gesture.up();
});

Now actually run the mutation

I did not reason about whether these tests work. I reverted the fix in the real file and ran them:

00:00 +0 -1: a drag starting in the dead zone still steers [E]
00:00 +1 -1: Some tests failed.

Test one went red. Test two stayed green. That is the shape you want:

Test one discriminates — it dies without the fix.
Test two is the anchor — it proves the fix didn't overshoot and delete the dead zone entirely.

Two tests, two independent failure modes, neither redundant. That pair is worth more than twenty generated tests asserting that _calculateDirection returns the right enum for sixteen different angles.

Notice also what the tests are asserting on. Not internal state, not _isActive, not a call count on a private method. They assert on what the emulator core actually received — a recording fake of the session port:

class _RecordingSession implements EmulatorSessionPort {
  final List<(int, bool)> events = [];

  @override
  Future<void> setButtonState(int button, bool pressed) async =>
      events.add((button, pressed));

  @override
  dynamic noSuchMethod(Invocation invocation) => null;
}

That noSuchMethod line is the whole reason this stays maintainable: the port has a dozen methods and the test cares about one. When the port grows, this fake does not break.

3. A Second Mutation: The Bug That Only Exists in the Framework

Some bugs aren't in your logic at all. They live in a framework default you didn't know you were accepting — which makes them exactly the kind AI-generated tests never find, because the AI generated the test from your code, and your code doesn't mention the default.

GoGBA centralizes motion into tokens, so no animation writes a bare Duration:

abstract final class AppDuration {
  static const instant  = Duration(milliseconds: 100);
  static const quick    = Duration(milliseconds: 180);
  static const standard = Duration(milliseconds: 250);
  static const deliberate = Duration(milliseconds: 400);
  static const cartridgeInsert = Duration(milliseconds: 1000);
}

The page transitions used these tokens. And yet navigation felt subtly wrong — pushing a page and popping it back didn't feel like the same motion.

The cause: slideTransition set only reverseTransitionDuration. go_router silently defaults transitionDuration to 300ms. So every forward navigation ran at 300ms and every return leg at 250ms. No error, no warning, no lint. A 50ms asymmetry that you feel and cannot name.

The test doesn't check a constant. It checks a relationship:

// Regression: slideTransition once set only reverseTransitionDuration, so
// go_router defaulted the forward direction to 300ms while the return leg
// ran at 250ms. Enter and exit must travel the same path at the same speed.
for (final entry in <String, CustomTransitionPage<void> Function({
  required GoRouterState state,
  required Widget child,
})>{
  'fadeTransition': PageTransitions.fadeTransition<void>,
  'slideTransition': PageTransitions.slideTransition<void>,
}.entries) {
  testWidgets('${entry.key} is symmetric', (tester) async {
    late CustomTransitionPage<void> page;
    final router = GoRouter(routes: [
      GoRoute(path: '/', pageBuilder: (context, state) {
        page = entry.value(state: state, child: const SizedBox.shrink());
        return page;
      }),
    ]);
    addTearDown(router.dispose);

    await tester.pumpWidget(MaterialApp.router(routerConfig: router));
    await tester.pumpAndSettle();

    expect(page.transitionDuration, page.reverseTransitionDuration);
    expect(page.transitionDuration, AppDuration.standard);
  });
}

Mutation check — I deleted the transitionDuration: line from the real router file:

Failing tests:
  test/theme/app_motion_test.dart: page transitions fadeTransition is symmetric
  test/theme/app_motion_test.dart: page transitions slideTransition is symmetric

Both red. The four AppDuration token tests in the same file stayed green — they cover a different property, so they should stay green. A mutation that turns your whole file red is telling you your tests are entangled.

The lesson generalizes: assert on the invariant, not on the value. expect(duration, 250) would pass for a broken app. expect(forward, reverse) cannot.

4. Where AI Genuinely Wins: Property Coverage

I have been hard on generated tests. Here is where they are outstanding, and where I now use them by default.

Some tests are not about a single failure mode — they are about a combinatorial claim across a set of inputs. Humans write three cases and get bored. AI writes all of them and never gets bored.

GoGBA calls Gemini for on-screen text translation. The model id is Remote Config-driven — which means it changes without a release, and a model generation I have never run can arrive in production at any time. Successive Gemini generations have taken mutually exclusive thinking knobs, and sending the wrong one is not an error: thinking stays at the model default, silently eats the 512-token output budget, and truncates the translation mid-sentence.

This is the class of bug where writing down today's correct answer is worthless — today's answer expires. What you want pinned is the rule for picking the knob, and the guarantee that you never send two.

test('current generations use thinkingLevel', () {
  final config = GeminiTranslator.thinkingConfigFor('gemini-3.5-flash');
  expect(config.thinkingLevel, ThinkingLevel.minimal);
  expect(config.thinkingBudget, isNull);
});

test('a generation newer than any I have run is treated as current', () {
  final config = GeminiTranslator.thinkingConfigFor('gemini-9-flash');
  expect(config.thinkingLevel, ThinkingLevel.minimal);
  expect(config.thinkingBudget, isNull);
});

test('unparseable model id falls back to the legacy knob', () {
  final config = GeminiTranslator.thinkingConfigFor('custom');
  expect(config.thinkingBudget, 0);
  expect(config.thinkingLevel, isNull);
});

// The one that matters most: a property, over the whole input space.
test('the two knobs are never set together', () {
  const ids = [
    'gemini-3.5-flash', 'gemini-9-flash', 'custom', '',
  ];
  for (final id in ids) {
    final config = GeminiTranslator.thinkingConfigFor(id);
    expect(
      config.thinkingBudget == null || config.thinkingLevel == null,
      isTrue,
      reason: 'both knobs set for "$id"; the API rejects that',
    );
  }
});

The first three are enumeration — AI does this perfectly and I let it. The last one is the property, and it is the one that survives a refactor. Note that it covers gemini-9-flash, a model that does not exist. That is deliberate: the model id arrives from Remote Config, so the input space includes ids I have never seen, and the property has to hold across all of them.

Division of labour that works for me:

Task	Owner
Enumerate the cases	AI
Set up fakes, fixtures, harness boilerplate	AI
Port a test to a second platform	AI
Decide what the invariant is	Me
Run the mutation	Me
Delete the redundant tests	Me

The three in bold are the entire job now. They are also the three that feel least like "work," which is why they get skipped.

5. Physical Properties Beat Incidental Values

The hardest bugs in GoGBA are in the audio path, and they taught me the sharpest version of this rule.

The GBA core runs at 32040.5 Hz. Not 32040. That .5 looks like noise. Round it off and you get a 15.6 ppm drift between producer and consumer, the ring buffer slowly fills, and roughly once every few minutes it overflows and clips — an audible pop with no apparent cause.

Now here is the trap that actually bit me. A test like this passes with the bug present:

// BROKEN: producer and resampler both read the same (rounded) constant,
// so the error cancels and the test is green forever.
const int rate = kCoreRate;
producer.configure(rate);
resampler.configure(rate, 48000);

Both sides used one rounded constant, the errors cancelled exactly, and drift was structurally unobservable. The test could never fail. It was, in the most literal sense, testing nothing.

The fix is to read the rate independently on each side, so a rounding error on one side shows up as drift. And then assert on the physical property, not a sample value.

This is the general principle, and it is the one I'd carry to any codebase:

When you can, assert on a property the user can perceive — not on a number that happens to be correct today.

For the audio splice, the assertion that finally caught a real regression was not "the first sample after the seam equals X." It was "the maximum adjacent-sample step across the splice is no larger than the clean waveform's own maximum step." That is the definition of "no click." A first-sample check passed happily while a too-fast fade was still audible; the step-size check killed it immediately.

For the D-pad, the property was "the core received a right-press." For transitions, "forward equals reverse." Every one of these is a sentence you could say to a user. That is the test for whether it's the right assertion.

The native suite runs under sanitizers, which is the same idea applied to memory:

./run_tests.sh          # build + run
./run_tests.sh --asan   # AddressSanitizer + UBSan
./run_tests.sh --tsan   # ThreadSanitizer, checks the ring's locking

with one detail worth stealing:

# Surface the first error instead of stopping at it, and make UBSan fatal --
# by default it only prints and carries on, which would let a real defect pass.
export UBSAN_OPTIONS="print_stacktrace=1:halt_on_error=1"

UBSan defaults to printing and continuing. A default that turns a caught bug into a green build. Check yours.

6. The Tests You Should Delete

A suite where every test passes and no test can fail is a suite with a coverage number and no coverage.

I delete a test when:

No mutation can kill it. Break the code three plausible ways; if it stays green, it is decoration.
Another test strictly dominates it. If test B fails everywhere test A fails, A is noise in your CI log.
It asserts on an implementation detail. Private method call counts, internal flags, widget tree shapes that aren't the user-visible outcome. These break on every refactor and catch nothing.
It was generated to hit a coverage target. Coverage measures which lines ran, not which bugs would be caught. A test with no expect runs plenty of lines.

The GoGBA suite has 1423 tests — it briefly had more, until I applied this section to it. Not one of them exists because a line was uncovered. Each exists because a real failure mode would otherwise go unnoticed — and the project's own rules say so out loud:

Only the necessary tests. One per real failure mode that would otherwise go unnoticed — not one per method. A test must fail without the fix: revert it, watch it go red, put it back.

That last clause is the whole article in one sentence.

7. What the Machine Should Enforce Instead

There is a category of correctness that does not belong in tests at all, and it's the highest-leverage thing you can set up in 2026.

If a rule can be checked statically, a test for it is the wrong tool — it only fires when someone remembered to write the test. A lint fires on every keystroke, for everyone, forever.

GoGBA ships a gogba_custom_lint package. Each rule is a bug class that used to recur:

Rule	The bug it ends
`domain_layer_dependency`	`domain/` importing Flutter or `dart:io`, quietly making pure logic untestable
`presentation_no_data_imports`	UI reaching past the port into a datasource
`no_ref_in_dispose`	Riverpod `ref.read()` on the teardown path → crash
`no_invalidate_app_config`	`invalidate()` after a config write → `AsyncLoading` flash
`no_hardcoded_ui_string`	A string that never reaches the 24 translation files

Plus one script that runs identically on my machine and in CI:

./scripts/check.sh           # format, analyze, custom_lint, repo invariants
./scripts/check.sh --check   # CI mode: no writes

Every stage always runs even if an earlier one fails, so one invocation surfaces every problem rather than making you play whack-a-mole.

The AI angle is the important part: the assistant reads these rules before it writes code. The constraints live in skill.md files the assistant loads at the start of every session, and the lints catch anything that slips through. The rules stop depending on anyone's memory — mine or the model's.

That is the real 2026 workflow. Not "AI writes my tests." It's: encode the rules once, and the cost of following them drops to zero for every future contributor, human or not.

The Checklist

Everything above, compressed:

[ ] For each new test: break the code, watch that test go red, put it back. Non-negotiable. It costs 30 seconds.
[ ] Assert on the physical/perceivable property, not an incidental value.
[ ] Assert on relationships (forward == reverse) over constants (== 250).
[ ] In numeric tests, read each side's inputs independently — shared constants cancel errors and make bugs unobservable.
[ ] Let AI enumerate cases and build fakes. You decide the invariant.
[ ] Delete tests no mutation can kill, and tests another test dominates.
[ ] Move every statically-checkable rule from tests into lints.
[ ] Make sanitizers and checkers fatal — verify their defaults don't print-and-continue.
[ ] One verify script, identical locally and in CI.

Closing

The thing I keep coming back to: AI didn't make testing easier. It made writing testing artifacts easier, which is not the same activity, and the gap between those two is where bugs now live.

The skill that mattered in 2020 was knowing how to write a widget test. That skill is now commoditized and I'm glad — it was never the interesting part. The skill that matters in 2026 is judgment about what a test proves, and it is less commoditized than before, because now there are a thousand plausible tests where there used to be three, and someone still has to know which ones are real.

You get that judgment exactly one way. Break your own code and watch what happens. If nothing turns red, you have just learned something considerably more valuable than a green checkmark.

GoGBA is a GBA/GBC/GB emulator for Android and iOS — Flutter UI over a libretro/mGBA core, with AI on-screen translation. Search GoGBA on the App Store or Google Play.

Six months of running a GBA emulator

Hamber — Mon, 27 Jul 2026 03:12:22 +0000

I shipped GoGBA (Android + iOS) to both stores in late December 2025. Six months in: MAU peaked at 8.3k, currently steady around 7.4k. No paid advertising, ever.

This is a write-up of what the six months actually involved. I'll be specific about the technical work, and equally specific about the mistake that cost me RetroAchievements hardcore certification — because that part is the most useful thing here for anyone building in this space.

Why GBA only

I grew up on a GBA — Super Robot Wars, Fire Emblem, Pokémon, Castlevania, Zelda. Later NDS/3DS/PSP/Vita/Switch arrived and the GBA did its job and retired. On PC the emulator I remember is VisualBoyAdvance.

I've used GBA, NDS and PSP emulators on phones. I kept coming back to GBA, for four reasons that are all practical rather than nostalgic:

Pixel art holds up. Personal taste, no defense offered.
Battery. A GBA game survives a long-haul flight.
Single screen. The remaining screen space is exactly where virtual buttons want to go. NDS dual-screen on a phone is always a compromise.
ROM hacks. The GBA hack scene is the richest of any handheld.

Point 3 is the one that made me build something: GBA is the only handheld whose form factor natively fits a phone. That's a product observation, not sentiment.

What existing emulators get wrong (for me)

I used the main ones on both platforms: Delta and Linkboy on iOS; Pizzaboy, Linkboy and Lemuroid on Android. Lemuroid is open source and a lot of shipped emulators are built on it.

They're all good. Every one of them had small things that annoyed me.

The only genuinely cross-platform one is Linkboy (formerly MyBoy), but its configuration surface is extremely deep — second only to RetroArch in complexity.

That's the gap. Everyone was solving "can it run" and "can it be tuned perfectly." Nobody was solving "pick it up and play."

The methodology was just dogfooding

I'm a Flutter GDE and tech lead for a 40-person cross-platform team; GoGBA was a solo test of that experience. The only rule: if nothing annoys me during real play, users will like it.

That sounds lazy. It's actually a harsh standard, because as a heavy user my tolerance is lower than the average player's.

Two features nobody requested, that came out of actually playing:

Per-orientation button opacity. Most emulators give you one global opacity slider. But in portrait the buttons sit in dead space below the screen and I want them clear; in landscape they overlay the game and I want them faint. So opacity is persisted separately per orientation.

D-Pad haptics as its own toggle. Most emulators have one vibration switch. But haptics belong on discrete actions (A/B), not high-frequency continuous input — a constantly buzzing D-Pad just makes your thumb numb. So it's a separate switch.

You only find these by playing daily.

"It's just an AI-written frontend on a finished core"

This is the objection I want to answer properly, because I think it's wrong in an interesting way.

AI made this dramatically easier. Dramatically easier is not the same as low barrier. Three concrete examples of where the barrier actually sits.

1. The real barrier is telling whether the AI is hallucinating

I fixed three bugs in my own mGBA fork:

MBC6 save null-pointer crash — some MBC6 cartridge games crashed outright
GB MBC RTC state loss — broke real-time-clock games like Pokémon Prism
Pokémon ROM identification off-by-one — boundary error causing misidentification

Those patches were written by AI. I'm saying so plainly, because leaving it out would repeat the exact mistake I describe further down.

But that's the point I actually want to make:

When you point an AI at a twenty-year-old C codebase, the risk isn't that it can't produce a fix. The risk is that it produces one that looks right.

You get a patch that compiles and makes the symptom disappear. That patch may also be:

a null check at the wrong layer, converting a crash into silent save corruption — which the user discovers forty hours later
a hallucinated struct field or function that doesn't exist in mGBA, but compiles anyway because of macro expansion
correct only for the one ROM on my desk, and broken for every other MBC6 cartridge
an off-by-one "fixed" into an off-by-one in the other direction, where my test case happened not to cover the new boundary

So the actual work wasn't writing the patch — it was reviewing it. At which layer does that null check belong? Is the RTC state lost on the save path or the restore path? What does that field mean in mGBA's original design, and who owns its lifetime? The correct off-by-one boundary comes from reading the GBA cartridge header spec, not from asking the model again.

AI drove the cost of writing code to nearly zero, which makes "judging whether the code is correct" the only remaining barrier. And that judgment can't be outsourced back to the AI — you can't ask the thing that hallucinates to verify its own hallucinations.

That's why I'd argue the barrier didn't drop, it moved: from "can you produce it" to "can you recognize the answer that looks right and isn't." The second requires no less knowledge than the first, and unlike the first it's not fakeable — you either know the cartridge header layout or you don't.

One necessary clarification: these three fixes live only in GoGBA's fork. They are not upstreamed into mGBA. So they're GoGBA-specific behavioral differences, not a contribution to the community — your mGBA doesn't have them, and the same MBC6 cartridge will still crash.

2. Where the native/Flutter boundary goes

People say Flutter can't match native performance. True and not true.

Flutter (Dart)   ← all UI, state, config, navigation
   ↓ MethodChannel / EventChannel
Kotlin / Swift   ← rendering, audio, input, save IO
   ↓ JNI / C FFI
libretro mGBA    ← the emulation itself

Rendering is native — OpenGL ES 3.0 on Android, Metal on iOS, framebuffer blitted straight into a Texture, zero copy. Flutter runs zero frames of emulation logic.

Everything else — 24 locales, settings hierarchy, button layout editor, paywall, cloud saves — is Flutter, pixel-identical across both platforms.

There are no good or bad stacks, only correct or incorrect boundaries. Performance-sensitive work goes native; consistency-sensitive work goes Flutter. Choosing where that line falls is the actual engineering.

The native side still bit me plenty. Two that reached production:

EGL teardown race — intermittent SIGABRT (destroyed mutex) on Mali GPUs when exiting a game. Root cause: calling eglTerminate on EGL_DEFAULT_DISPLAY, which is process-wide shared state. You don't tear that down from one instance.
Release-only empty-stack crash — double-tap-to-exit fired twice, popped the navigation stack empty, and matches.last crashed. Not reproducible in debug.

These two differ in kind from the mGBA patches above, and are hard for a related but distinct reason: they don't exist in any environment the AI can observe. One reproduces intermittently and only on Mali GPUs; the other only in release builds. No stack trace, no reliable reproduction — just a SIGABRT line in production Crashlytics. You can't paste that at a model and wait, because working out what the problem even is is the step that has to happen first.

3. Adding features is easy; keeping them from becoming clutter is not

Since launch: 1,499 commits — 276 features, 224 fixes.

Shipped in that window: a Pokémon toolkit (Pokédex / type chart / natures / moves, offline SQLite, 24 languages), offline achievement caching with pending-sync states, a button layout editor with per-button hiding, gesture quick-save (slide-to-unlock interaction), adaptive orientation (portrait menus / landscape gameplay), cloud saves (iCloud + Google Drive), cheats, AI screen translation, and a daily tips card.

Every single one had to answer the same question: does this make "pick it up and play" worse?

Which is why GoGBA is one of the very few emulators with no ads at all. Not on principle — ads structurally conflict with the core experience, so there's nothing to discuss.

The hard part was never adding things. It's keeping a first-time user able to find what they need in three seconds while the feature count grows.

The mistake: I conflated "emulator" with "emulator frontend"

I promoted GoGBA with the line "built an emulator in three days."

That was wrong, and not as a matter of phrasing — as a matter of concept.

An emulator is mGBA. Twenty years of work by many people, cycle-accurate hardware behavior.
An emulator frontend is GoGBA. UI, input, render pipeline, save management, platform integration.

What I built in three days was a prototype of the second thing. Calling it the first thing disrespected every mGBA contributor.

The RetroAchievements community was justifiably angry, and GoGBA's hardcore certification was revoked.

Two things I want to state honestly:

First, on the technical requirements, GoGBA does comply. Hardcore forbids cheats, save states, rewind/fast-forward and memory editing. GoGBA gates all of them behind one shared predicate (RA enabled ∧ authenticated session ∧ effective hardcore), checked independently at every entry point: cheats are not dispatched, the in-game save-state menu entry isn't rendered at all, and the manual slots, the auto-save/auto-resume automation and the free gesture quick-save slot each re-check the gate on their own path — save and load, in both directions. Being free of the paywall doesn't exempt a slot. Rewind and frame advance aren't shipped features. The client User-Agent reports core name and version per RA's spec. The "publicly available for at least six months" eligibility requirement is now also satisfied.

Second, that doesn't matter much. Certification isn't only a technical checklist — it includes community trust. One inaccurate marketing line damaged the second thing. Technical compliance can be fixed by writing code. Trust can only be fixed by time.

I don't know when I'll be allowed to reapply. That call isn't mine to make.

I'm writing it down because if you're building an emulator frontend: get these two words straight on day one. It's professional courtesy, not semantics.

The reviews that got raised back to five stars

Five-star reviews are the best part of this, and I built a page that collects them.

But the ones I care about more are different: reviews that started below five stars and were raised after I fixed that specific user's problem.

The first kind says "you did well." The second says "you're listening."

For a one-person product, the second one is the moat. People didn't stay because GoGBA has the most features. They stayed because reporting a problem results in the problem being fixed. How fast one person can turn that around is the only structural advantage independent development has — and the only one that costs nothing but attention.

GoGBA is on the App Store and Google Play.

There's not much to conclude at the six-month mark. The 7.4k moves every day, the reviews bring new problems every day, and whether RetroAchievements ever takes another look isn't mine to decide. The only thing I know is what's getting fixed in the next build.

If you mostly play late at night or on a plane and don't want to chase anyone's progress, GoGBA was probably built for you. Because it was built for me.

Modern Flutter Best Practices for 2026

Hamber — Sat, 04 Jul 2026 14:35:55 +0000

If you're starting a new Flutter project in 2026, this article covers two things:

What a modern Flutter project should look like (tech stack, architecture, engineering);

The trade-offs between an OPC (One Person Company) project and an enterprise-grade production project.

Everything below is grounded in two real projects:

go_gba — a GBA emulator App built by a single developer (single package, shipped on the App Store / Google Play, now at v3.12). A textbook OPC.

AppX (pseudonym) — a high-traffic consumer App maintained by a large cross-platform team (melos monorepo, multiple flavors, multiple environments). A textbook enterprise-grade project.

Both projects share the same modern Flutter foundation, but make completely opposite bets on "complexity investment." Comparing them tells you far more about when to reach for the heavy machinery than looking at either one alone.

0. The Bottom Line (TL;DR)

In 2026, several choices have moved from "optional" to "default":

Dimension	2026 default	Why
State management	Riverpod 3 (+ code generation)	Compile-time safety, testable, no BuildContext dependency — the de facto community standard
Routing	go_router (declarative + type-safe routes)	Officially recommended; deep links / nested navigation are first-class
Data models	freezed 3 + json_serializable	Immutable, pattern matching, `copyWith` — kills hand-written boilerplate
i18n	slang	Type-safe, compile-time checked, an order of magnitude nicer than the official `intl`
Version pinning	fvm (pin the Flutter SDK version)	The end of "works on my machine"
Code generation	build_runner	freezed / riverpod / slang / routes / assets all depend on it
Lint	Strict lint + custom lint rules	Turns team conventions into machine-enforceable rules
Crash / analytics	Firebase Crashlytics + Analytics (or equivalent)	A production App without observability is flying blind

Details below.

1. Tech Stack: The 2026 "Standard Recipe"

The two projects agree closely on their core libraries, which itself is evidence that consensus has formed.

1.1 State Management — Riverpod 3

Stop agonizing over Provider / Bloc / GetX. Riverpod 3 is already the default answer for new projects.

go_gba: flutter_riverpod: 3.3.2, hand-written providers.
AppX: riverpod_generator + riverpod_annotation, full code generation.

The difference is whether you adopt code generation:

// Hand-written (good enough for OPC, directly readable)
final gameLibraryProvider = FutureProvider<List<Game>>((ref) async {
  return ref.watch(gameRepositoryProvider).loadAll();
});

// Generated (recommended for enterprise; stricter types, safer refactors)
@riverpod
Future<List<Game>> gameLibrary(GameLibraryRef ref) {
  return ref.watch(gameRepositoryProvider).loadAll();
}

Recommendation: Go straight to Riverpod 3 on new projects. Team projects should use the generator (with riverpod_lint enforcing conventions); solo projects are perfectly fine hand-writing — don't add the mental overhead of code generation just to look "advanced."

1.2 Routing — go_router

Both projects use go_router: 17.x. AppX additionally adopts go_router_builder (type-safe routes: route parameters go from String to compile-time-checked objects).

// go_router_builder: routes ARE types, no more string concatenation for navigation
context.go(GameDetailRoute(gameId: game.id).location);

Recommendation: go_router is the only no-brainer. Deep links, Web support, and nested Shell navigation all rely on it. The builder is worth it for team projects; optional for solo.

1.3 Data Models — freezed 3

AppX uses freezed across the board to define immutable models, paired with json_serializable for automatic serialization. This is the default way to handle data classes in 2026: immutability, copyWith, when/map pattern matching, and value equality — all generated for you.

Note the naming convention for generated files (worth copying from AppX):

*.f.freezed.dart — freezed-generated copyWith/when/map

*.f.g.dart — freezed + JSON serialization

*.g.dart — riverpod / standalone json_serializable

Never hand-edit generated files, and exclude them in analysis_options.yaml to avoid lint noise.

1.4 i18n — slang

Both projects abandoned the official intl arb workflow in favor of slang. Reasons: type safety (t.home.title instead of AppLocalizations.of(context)!.homeTitle), compile-time missing-key checks, and support for plurals / parameters / namespaces.

An enterprise-grade detail: AppX's slang output is not committed (strings*.g.dart stays out of the repo) and is generated on demand locally / in CI. This reduces merge conflicts but requires CI to run i18n generation before the build. OPC projects can just commit the output for simplicity.

1.5 Networking

go_gba: plain dio, simple and direct.
AppX: dio + dio_http2_adapter (HTTP/2) + native_dio_adapter (uses the native network stack) + in-house networking / WebSocket infrastructure packages (unified team wrappers).

This is the first classic fork between OPC and enterprise: solo projects use bare dio; teams extract the network layer into standalone packages to unify interceptors, retries, auth, telemetry, and certificate pinning.

2. Architecture: Different "Investment Budgets" for Layering

This is where the two projects diverge the most, and where "complexity is an investment" shows most clearly.

2.1 OPC: feature-by-layer (go_gba)

go_gba uses the classic slice-by-technical-layer directory:

lib/
├── core/          # emulator / services / analytics / errors / theme
├── data/          # datasources / repositories / adapters / platform
├── domain/        # business entities and use cases
├── providers/     # Riverpod providers
├── pages/         # organized by feature page: home / play / settings / toolkit ...
├── widgets/       # shared components
├── router/        # go_router config
└── i18n/          # slang

Characteristics: one package does it all. pages/ has sub-directories per feature; data/domain are shared globally. For a project maintained by one person, this structure carries the lowest mental load — you can fit the whole dependency graph in your head and don't need package boundaries to force decoupling.

2.2 Enterprise: feature-first + Clean Architecture inside each feature (AppX)

AppX is a melos monorepo, split at the top level into three kinds of packages by responsibility:

apps/
└── app/                     # app shell: main_dev / main_prod / main_test (multiple entrypoints)
packages/
├── features/                # business feature packages, each self-contained:
│   ├── home/  feature_a/  feature_b/  auth/  ai/ ...
├── design_system/           # design system: colors/typography/spacing/components/chart
├── data_hub/  router/  routes/  env/  foundation/  push/  flavor_config/
└── lints/                   # team's custom lint rules package
plugins/                     # native plugins: various platform-capability wrappers
third_party/                 # third-party wrappers

And each feature package internally is a full Clean Architecture:

packages/features/home/lib/src/
├── application/    # coordinators / services (use-case orchestration)
├── domain/         # entities / repositories (interfaces)
├── data/           # datasources (local/remote) / dtos / mappers / repositories_impl
└── presentation/   # pages / widgets / controllers

Why go this heavy? Because on a team of dozens:

Package boundaries = enforced decoupling. Feature A cannot directly import Feature B's internal implementation — only its public API. You can't achieve this with directory conventions; you need packages.
Compilation isolation = faster incremental builds. Changing one feature doesn't recompile the world.
No collisions in parallel development. Different squads own different packages, so the conflict surface is small.
An independent design system = a single source of truth for UI consistency (the design_system package), instead of every page hard-coding its own colors.

2.3 The Key Judgment: When Should You Upgrade From an OPC Structure to a Monorepo?

Don't start with a monorepo. This is a hotspot for over-engineering. Upgrade only when the signals appear:

The codebase grows beyond what one person can "hold in their head";
2+ developers need to work on different modules in parallel;
Incremental compilation starts getting noticeably slow;
Arguments over "which module does this logic belong to" start happening;
You need to reuse a single design system / network layer across multiple Apps or flavor outputs.

Until then, go_gba's single-package-with-clear-layering is the most cost-effective structure.

3. Engineering: Turning Conventions Into Machine Enforcement

The maturity of a modern Flutter project is largely reflected in how many conventions are machine-enforced rather than left to human discipline.

3.1 Strict Lint (both projects do it, at different intensities)

go_gba: based on leancode_lint, and it built its own gogba_custom_lint package — encoding project-specific conventions (e.g. "must go through a certain service instead of calling the API directly") as custom lint rules. Worth doing even solo, because it's a guardrail for "future you."
AppX: an extremely strict analysis_options.yaml, promoting many rules from warning to error level:

analyzer:
  language:
    strict-casts: true       # forbid implicit type casts
    strict-inference: true   # forbid inference falling back to dynamic
  errors:
    always_declare_return_types: error
    avoid_void_async: error
    prefer_single_quotes: error
    require_trailing_commas: error   # enforce trailing commas → better diffs and formatting

Recommendation: Max out lint on day one of a new project. strict-casts + strict-inference are two low-cost, high-reward switches. Team projects must have a shared lints package to unify rules.

3.2 Custom Lint — the 2026 Power Move

Both projects do this, and many people overlook it: use custom_lint to compile your team's/project's verbal conventions into static checks.

A convention written in a doc goes unread; written as a lint rule, a violation lights up red. go_gba did this even as a one-person project — proof that the ROI is high enough.

3.3 Version Pinning — fvm Is a Necessity

AppX uses fvm to pin the Flutter SDK to an exact version, committed in .fvmrc. Everyone on the team, CI, and local runs all use the same SDK.

Team projects without fvm periodically bleed time to "it won't compile on my end." Solo projects should use it too, mainly to prevent a global upgrade from breaking the project.

3.4 The Code-Generation Pipeline Must Be "Ordered"

A hard-won lesson from AppX (written in its AGENTS.md): codegen cannot run in parallel. Because packages have dependencies (design_system's generated output is consumed by features), running in parallel causes AssetNotFoundException. So it wrote codegen.sh to generate in dependency-graph order, leaf packages first.

# Correct: in dependency order
melos run codegen   # → bash script/codegen.sh

# Wrong: parallel melos exec build_runner → random failures

Takeaway: monorepo codegen must explicitly manage ordering. Single-package projects don't have this problem — one dart run build_runner build -d does it.

3.5 Git Hooks — Move Discipline Left, Before Push

After melos bootstrap, AppX automatically installs versioned git hooks (pre-push runs a lint attribution check). This way "you must pass validation before committing" isn't something people have to remember — it's intercepted automatically at push time.

Paired with this is a unified verify.sh (format check + per-package analyze across the whole workspace), and local and CI run the exact same script — this is crucial: passing locally = passing CI, eliminating the "green locally, red in CI" finger-pointing.

3.6 Multi-Environment / Multi-Entrypoint (an enterprise trait)

AppX has three entrypoints: main_dev.dart / main_prod.dart / main_test.dart, paired with generated environment variables (env.impl.dart) and per-flavor config (flavor_env.impl.dart). One codebase produces dev/prod, plus different flavor outputs, via build parameters.

go_gba, as a single product, doesn't need any of this. Multi-flavor / multi-channel packaging is a textbook "tax you only pay at enterprise scale."

4. Observability: The Eyes of a Production App

go_gba, despite being a one-person project, does observability thoroughly:

firebase_crashlytics — crash collection
firebase_analytics — user behavior
firebase_remote_config — remote config / gradual rollout switches
firebase_ai — AI capabilities

This is worth emphasizing: observability isn't an enterprise privilege — an OPC needs it more. A solo developer has no QA team and no support agents relaying issues; when something breaks in production, all you have is the Crashlytics stack trace and the Analytics funnel to diagnose it yourself. remote_config lets you kill a broken feature without shipping a release — a lifesaver for indie developers.

Enterprise projects typically use an in-house or heavier APM (AppX uses sentry_flutter), but the core idea is identical: crashes, performance, and behavior — three data streams, none optional.

5. OPC vs Enterprise: A Decision Matrix

Condensing the differences into one table. On the left, "the baseline both should do"; on the right, where they fork.

5.1 The Shared Baseline (do this regardless of scale)

Item	Notes
Riverpod 3 + go_router + freezed + slang	Modern foundation, no compromise
Strict lint (strict-casts / strict-inference)	Max it out on day one
build_runner code generation	Kill boilerplate
Observability (crash + analytics + remote config)	Mandatory in production; OPC needs it especially
Clear layering (data / domain / presentation)	Layer even in a single package
Custom lint rules	High ROI, worth it even solo

5.2 The Fork Points

Dimension	OPC (e.g. go_gba)	Enterprise (e.g. AppX)
Repo structure	Single package, layered directories	melos monorepo, packages as boundaries
Architecture depth	feature-by-layer, globally shared domain	Independent Clean Architecture per feature
State management	Hand-written Riverpod is enough	Riverpod generator + riverpod_lint enforcement
Network layer	Bare dio	Extracted into standalone packages; unified interceptors/auth/HTTP2/WS
Design system	A single theme directory	Standalone `design_system` package (single UI source)
Multi-environment	Single entrypoint	Multiple flavor entrypoints + multi-channel
codegen	One command	Ordered generation script by dependency graph
CI / discipline	Local scripts + store release	git hook + verify script (local = CI) + full pipeline
Dependency versions	Exact pinning is enough	`dependency_overrides` unifies versions across the workspace
Optimization goal	Iteration speed, lowest mental load	Maintainability, parallelism, consistency

5.3 The One-Line Principle

OPC optimizes for "speed of change"; enterprise optimizes for "safety of change."

On a solo project, your biggest cost is your own attention, so cut every bit of complexity that needs "maintaining" (monorepo, extra abstraction layers, multi-channel packaging).
On a team project, your biggest cost is communication and incidents, so pay for "boundaries" and "enforcement" (package isolation, git hooks, unified versions).

6. The Two Most Common Mistakes

OPC over-engineering: one person puts a to-do App on a melos monorepo with four-layer Clean Architecture per feature. The result: 80% of the time spent maintaining scaffolding instead of building features. Complexity is an investment; below the scale threshold, it's pure loss.
Enterprise under-investment: five people cram into one lib/, with no package boundaries, no unified lint, codegen run by hand, and local vs CI scripts out of sync. The result: every merge is a disaster and "it works" is down to luck. Skip the tax you owe, and you'll pay it back later with interest.

To judge which tier you're in, don't look at "how professional I want to seem" — look at your actual current headcount and codebase size. Upgrade when the scale arrives. That's the only correct sequence.

Appendix: 2026 Starter Checklist

Day one of a new project:

[ ] fvm use <version> to pin the Flutter SDK, commit .fvmrc
[ ] Riverpod 3 + go_router + freezed + slang as the foundation
[ ] Max out strict lint in analysis_options.yaml (strict-casts, strict-inference)
[ ] Wire up crash + analytics + remote config (Firebase or equivalent)
[ ] Layered directories (even in a single package): data / domain / presentation
[ ] Generated-file naming convention + .gitignore/exclude handling
[ ] A single verify script, run identically locally and in CI

Additionally for team projects:

[ ] melos workspace + package boundaries (features / design_system / foundation)
[ ] A lints package to unify rules; consider custom lint
[ ] dependency_overrides to unify versions across the workspace
[ ] git hook (pre-push validation)
[ ] Multiple flavor entrypoints, ordered codegen script
[ ] AGENTS.md / CONTRIBUTING spelling out conventions (especially traps like codegen ordering)

Building a Handheld Console with Flutter

Hamber — Tue, 28 Apr 2026 13:11:16 +0000

The Afternoon I Got Stuck on a Japanese Dialogue

One weekend last year, I was playing a classic GBA RPG and hit an NPC conversation I couldn't read — all in Japanese. I screenshotted it, switched to a translation app, looked it up, switched back. The game had already moved on.

That context switch was deeply annoying.

I'm a Flutter GDE, and I happened to have a GBA emulator project called GoGBA sitting on my machine. I thought: what if I could press one button, without ever leaving the game, and have AI read the screen and translate it for me?

This article is the complete story of going from that idea to a shipped feature. The stack: Flutter + mGBA + Firebase AI (Gemini) + Riverpod + Clean Architecture. All real production code.

GoGBA is live on the App Store and Google Play — search GoGBA to download it.

Part 1: Architecture — Can Flutter Actually Run an Emulator?

Why Not Go Native

Emulators are performance-sensitive, so the instinct is "Flutter isn't fast enough." But GoGBA's emulation core is libretro/mGBA — a battle-tested C/C++ engine. Flutter only handles UI and event dispatch; it never touches the emulation logic.

That's what makes cross-platform viable:

Flutter UI (Dart)
      ↓  MethodChannel / EventChannel
Kotlin (Android) / Swift (iOS)
      ↓  JNI / C FFI
libretro mGBA (C/C++)

Flutter renders the game screen using the Texture widget — the native layer writes mGBA's framebuffer into a SurfaceTexture (Android) or CVPixelBuffer (iOS), and Flutter composites it directly. Zero-copy. 60fps with no issues.

Designing the Channel Boundaries

GoGBA uses three channels:

static const MethodChannel _channel =
    MethodChannel('go_gba/emulator');
static const MethodChannel _audioChannel =
    MethodChannel('go_gba/audio');
static const EventChannel _eventChannel =
    EventChannel('go_gba/emulator_events');

_channel: command traffic — load ROM, save state, cheats
_audioChannel: separated to prevent audio calls from blocking the game loop
_eventChannel: native-initiated events — RetroAchievements unlocks, leaderboard updates

The EventChannel is the design decision most people miss. Emulator events happen asynchronously on the native side. Polling with MethodChannel is wasteful. Surfacing them as a Dart Stream via EventChannel means a Riverpod provider can just watch it — fully reactive, no polling, no glue code.

Part 2: Can Clean Architecture Actually Work in Flutter?

Why Bother With Layers

GoGBA's early code was all crammed into PlayPage — emulator calls, save logic, and UI state tangled together. When cloud saves, cheats, and AI translation needed to be added, every change rippled unpredictably.

Clean Architecture's real value isn't aesthetics. It's letting features evolve independently.

GoGBA's layer structure:

pages / widgets / providers   ← Presentation
        ↓
domain/usecases               ← Application (business rules)
        ↓
domain/entities, ports,       ← Domain (pure Dart, no Flutter/dart:io)
repositories (interfaces)
        ↑ implements
data/repositories, core/emulator  ← Data / Infra
        ↓ MethodChannel
Kotlin / Swift / mGBA (native)

The hard rule: domain/ cannot import `package:flutter/, dart:io, or anything from data/`.** Not a suggestion — a rule.

Enforcing Architecture with custom_lint

Code review alone will eventually miss things. GoGBA uses custom_lint to turn these constraints into compile-time errors:

# analysis_options.yaml
analyzer:
  plugins:
    - custom_lint

Two custom rules enforce the boundaries:

gogba_domain_layer_dependencies: blocks flutter / dart:io / data imports in domain
gogba_presentation_no_data_imports: blocks presentation from reaching into data directly

Now if anyone writes import 'package:flutter/material.dart' inside domain/, flutter analyze fails and CI catches it. The rule lives in the toolchain, not in someone's memory.

This is the single most effective architecture enforcement technique I've used in a real Flutter project.

Port/Adapter for Cross-Layer Dependencies

Riverpod providers need to read and write app config — but they shouldn't import ConfigDatasource directly (that's a data-layer type). GoGBA's solution:

// domain/ports/app_config_storage_port.dart (interface, pure Dart)
abstract class AppConfigStoragePort {
  Future<AppConfig> load();
  Future<void> updateConfig(AppConfig config);
}

// data/adapters/ (implementation)
class ConfigDatasourceAppConfigStorageAdapter
    implements AppConfigStoragePort { ... }

// providers/ (composition root)
final appConfigStoragePortProvider = Provider<AppConfigStoragePort>((ref) {
  return ConfigDatasourceAppConfigStorageAdapter();
});

Presentation depends only on the port interface. Tests swap in a fake. Widget tests don't need to touch the filesystem.

Part 3: AI Real-Time Translation — One Button, Three Technical Layers

This is my favorite feature in GoGBA, and the most interesting engineering problem in the project.

Layer 1: Capturing the Game Screen

The GBA screen is a native texture — not a regular Flutter widget. You can't screenshot it the normal way.

GoGBA wraps the game view in a RepaintBoundary, then uses RenderRepaintBoundary.toImage() to capture the current frame. The expensive encoding work runs in a separate isolate:

// lib/core/utils/game_texture_capture.dart
Future<Uint8List?> captureGameTextureAsJpeg(
  GlobalKey key, {
  int? targetWidth,
  int? targetHeight,
}) async {
  final boundary = key.currentContext
      ?.findRenderObject() as RenderRepaintBoundary?;
  if (boundary == null) return null;

  final image = await boundary.toImage(pixelRatio: 1);
  final byteData =
      await image.toByteData(format: ui.ImageByteFormat.png);
  if (byteData == null) return null;

  final pngBytes = byteData.buffer.asUint8List();

  // PNG → resize → JPEG runs in an isolate — main thread stays unblocked
  return compute(_encodePngBytesToJpeg, (
    pngBytes: pngBytes,
    targetWidth: targetWidth,
    targetHeight: targetHeight,
  ));
}

The compute() call is the key detail. Image encoding and resizing happen in a dedicated isolate — the main thread stays responsive and the game keeps running without a hitch.

Layer 2: Gemini Multimodal Translation

GoGBA uses Firebase AI Logic (Vertex AI on Firebase) with the firebase_ai package:

// lib/core/services/game_screen_translation_service.dart
final GenerativeModel _model = FirebaseAI.vertexAI(location: 'global')
    .generativeModel(
      model: 'gemini-3.1-flash-lite-preview',
      generationConfig: GenerationConfig(
        maxOutputTokens: 512,
        temperature: 0.1,
        topP: 0.95,
        // Translation doesn't need reasoning — disable to save latency and tokens
        thinkingConfig: ThinkingConfig.withThinkingBudget(0),
      ),
    );

Future<String> translateJpeg({
  required List<int> jpegBytes,
  required String targetLanguageTag,
}) async {
  final prompt =
      'GBA screenshot: pixel UI. Transcribe all visible on-screen text, '
      'then translate it into "$targetLanguageTag". '
      'Use natural RPG/menu phrasing. '
      'Output only the translation text, no scene summary or extra commentary. '
      'If no readable text, reply exactly: No text detected.';

  final response = await _model.generateContent([
    Content.multi([
      InlineDataPart('image/jpeg', Uint8List.fromList(jpegBytes)),
      TextPart(prompt),
    ]),
  ]);
  return response.text?.trim() ?? '';
}

The prompt engineering choices are deliberate:

Use natural RPG/menu phrasing: keeps translations in-genre — "HP" won't become "Health Points"
Output only the translation text: strips the model's boilerplate preamble
If no readable text, reply exactly: No text detected.: structured fallback the client can match on
temperature: 0.1: translation is a deterministic task; higher temperature just adds noise
ThinkingConfig.withThinkingBudget(0): Gemini 2.x enables thinking by default; for translation it adds latency and tokens with no benefit — explicitly disable it

Layer 3: Monthly Quota Management

AI calls have real costs. GoGBA's AI translation is a separate subscription. Monthly usage limits are served from Firebase Remote Config, so they can be adjusted without a release:

// lib/domain/services/game_screen_translation_quota_service.dart
class GameScreenTranslationQuotaService {
  static String _currentUtcYm() {
    final u = DateTime.now().toUtc();
    return '${u.year.toString().padLeft(4, '0')}'
        '-${u.month.toString().padLeft(2, '0')}';
  }

  Future<bool> isExhausted(int monthlyLimit) async {
    if (monthlyLimit <= 0) return true;
    final uses = await getUsesThisMonth();
    return uses >= monthlyLimit;
  }

  Future<void> recordSuccessfulTranslation() async {
    final prefs = await SharedPreferences.getInstance();
    final count = await _usesForCurrentUtcMonth(prefs);
    await prefs.setInt(_keyCount, count + 1);
  }
}

UTC month, not local time. Users span time zones. Local time means the quota resets at different moments for different people. UTC is the only fair counting window.

Wiring It Together: the UI Layer

// lib/pages/play/widgets/game_translation_bottom_sheet.dart
Future<void> _run() async {
  // 1. Capture the frame
  final jpeg = await captureGameTextureAsJpeg(
    key, targetWidth: vw, targetHeight: vh,
  );

  // 2. Translate with Gemini (follows system language)
  final target =
      LocaleSettings.currentLocale.flutterLocale.toLanguageTag();
  final text = await GameScreenTranslationService.instance.translateJpeg(
    jpegBytes: jpeg,
    targetLanguageTag: target,
  );

  // 3. Show result and record quota
  setState(() {
    _phase = _TranslationPhase.success;
    _resultText = text;
  });
  if (widget.recordUsageOnSuccess) {
    await GameScreenTranslationQuotaService.instance
        .recordSuccessfulTranslation();
  }
}

What the user experiences: press the translate button → bottom sheet slides up → spinner for a second or two → translation appears. Behind that: frame capture, isolate encoding, multimodal AI call, quota write. All async. Game never pauses.

Part 4: AI-Assisted Development — What It Actually Feels Like

GoGBA's development workflow is deeply integrated with Claude Code (Anthropic's AI coding assistant). As a solo developer, it lets me maintain the kind of engineering discipline that normally takes a team.

A few real examples:

Architecture enforcement: The project's SKILL.md documents the domain layer rules and forbidden patterns. Claude Code reads this before every change and won't suggest code that violates the layering — the constraints stay consistent without manual review.

i18n automation: GoGBA ships in 24 languages. When a new feature adds UI strings, Claude Code fills in all language files in l10n/*.i18n.json, then triggers dart run slang to regenerate. What used to take 20 minutes of copy-paste takes seconds.

Fastlane releases: Build number bumps, changelog generation, App Store submission — all scripted. Claude Code runs the sequence and catches problems.

This isn't "AI replacing the developer." It's AI reducing the cost of following your own rules to near zero. Write the standards once; the tool enforces them.

Part 5: Bugs That Taught Me Things

Bug 1: ref.read() inside dispose() crashes

Riverpod's ref.read() and ref.watch() cannot be called after dispose(). The widget is gone; the provider may have already been released. GoGBA had a handful of early crashes from this. The rule is now in SKILL.md and detected by custom_lint.

Bug 2: invalidate(provider) causes an AsyncLoading flash

Calling invalidate after updating config forces the provider to rebuild from scratch, briefly putting the UI into a loading state. Users see a flicker. The fix: update state directly with state = newValue inside the notifier and let Riverpod diff it. No invalidation needed.

Bug 3: Gemini's thinking mode is on by default

The firebase_ai Gemini 2.x models enable extended thinking by default. For translation — a deterministic task — this means longer latency, more tokens, and less predictable output. You have to explicitly disable it with ThinkingConfig.withThinkingBudget(0). The default bit me in early testing.

Closing Thoughts

GoGBA is my testbed for engineering ideas: where Flutter's cross-platform ceiling actually sits, whether Clean Architecture can hold up in a real project without becoming an interview-question abstraction, how to design AI features that are genuinely useful rather than just impressive in a demo.

My conclusions: Flutter is mature enough for this. AI tooling is raising the ceiling for individual developers in ways that weren't possible two years ago.

Every specific choice in this codebase — custom_lint guarding domain boundaries, compute() keeping the main thread clean, UTC-based quota windows — is a scar from a real mistake. I hope some of it saves you the same trouble.

Search GoGBA on the App Store or Google Play. If you play GBA games in Japanese or English and hit a text wall, the AI translation feature is there for exactly that.

Questions about Flutter cross-platform development, Firebase AI Logic integration, or shipping a solo app with an AI workflow? Drop them in the comments.