MJ
MobileFlutterArchitecture

Building mobile apps that last: a senior engineer's checklist

How to build iOS and Android apps with Flutter that stay fast, stable and easy to change years after launch, from architecture to releases.

MJ

Maher Jaafar

· 2 min read

Launching a mobile app is the easy part. Keeping it fast, stable and easy to change two years later is where most apps struggle. Since 2018 I have built Flutter apps for iOS and Android, as a consultant and in product teams, and this is the checklist I use to build apps that last.

Pick a boring, clear architecture

Separate the layers: UI, state, domain logic and data. Whether you use BLoC, Riverpod or something else matters less than using it consistently. A new developer should be able to guess where a piece of code lives without asking.

Keep business logic out of widgets

Widgets should describe the interface, not make decisions. Put logic in plain Dart classes that can be tested without a device. This makes the app easier to test, easier to reuse on other platforms and easier to reason about.

Design for offline and bad networks

Mobile networks are unreliable, and users are often offline. Cache what matters, queue actions that can wait, show clear states for "loading", "offline" and "failed", and never lose user input because a request timed out.

Test the right things

  • Unit tests for business logic: fast, many, run on every commit.
  • Widget tests for important components and states.
  • A few integration tests for the critical paths: sign-in, the main flow, payment.

You don't need 100% coverage. You need confidence that the important things don't break silently.

Automate builds and releases

Set up CI/CD from the first week: analysis, tests, builds for both platforms, and automated distribution to testers. Release to the stores in stages. Manual releases do not scale and always break at the worst moment.

Watch performance from day one

Measure startup time, frame rendering and app size early, on real mid-range devices, not just the newest phone. Performance problems are cheap to prevent and expensive to fix later.

Monitor in production

Crash reporting, basic analytics and structured logs are not optional. You can't fix what you can't see, and users rarely report bugs; they just leave.

Manage dependencies carefully

Every package is code you now depend on. Prefer well-maintained packages, pin versions, update regularly in small steps, and wrap critical third-party APIs behind your own interfaces so you can replace them.

Plan for the long term

Write a README that explains how to run, test and release the app. Document key decisions. Keep the codebase consistent. The best compliment an app can get is not "it looks great" but "it was easy to work on".

Why Flutter

For most products I recommend Flutter because one codebase covers iOS, Android, web and desktop, with native performance. That means a smaller team, faster releases and a consistent product everywhere, as long as you apply the same engineering discipline you would to any serious codebase.

Need help building or rescuing a mobile app? Tell me about your project.

Keep reading