DEV Community: Hamber

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.