Every mobile app in our portfolio — Koinonia, Edify, Edify's Audio Bible companion, MyChurchApp PRO — is built on Flutter, and that wasn't a decision we made once and forgot about. It's one we keep re-validating every time we start a new product.
The practical case is simple: one codebase, two platforms, and a UI toolkit fast enough to keep animations smooth even on the mid-range Android devices most of our users actually carry. For a small studio maintaining six live products, that consistency compounds — a fix or a pattern learned on one app transfers almost directly to the others.
That transfer effect is bigger than it sounds from the outside. When we solved the resume-playback-position problem for Koinonia's audio player, the same underlying approach — and a meaningful chunk of the actual code — carried over almost directly into Edify's audio chapters. A caching strategy refined for one app's offline reading mode became the starting point for another app's offline listening mode. None of that reuse would be nearly as clean across separate native Android and iOS codebases maintained independently for each product.
It's not a free choice. Flutter has real limits around certain native integrations, and we've had to work around them more than once. Background audio playback with reliable lock-screen controls, for instance, has needed platform-specific code on both Android and iOS rather than a pure Flutter solution — the framework gets us most of the way there, not all the way, and knowing where that boundary sits is part of using it responsibly rather than treating it as a universal answer.
We also weigh the hiring and knowledge-continuity side of this, not just the technical one. A small team where every engineer can read and contribute to every product's codebase, because they all share the same language and framework conventions, is worth more to us long-term than picking the theoretically optimal framework for any single app in isolation. Fragmenting across native Android, native iOS, and a web stack per product would mean specialists who can't easily cover for each other — a fragile setup for a studio our size.
For the category of apps we build — content-heavy, mobile-first, Android-majority — the trade-off has consistently favoured Flutter over maintaining separate native codebases we don't have the team size to support well. We revisit this decision periodically rather than treating it as settled forever. So far, every review has ended the same way: Flutter stays.