Flutter Web has evolved considerably in recent years, becoming a viable option for building high-performance Progressive Web Apps (PWAs), dashboards, admin panels, SaaS platforms, and enterprise applications. What was once dismissed by some developers as an impractical choice for web development is now powering real-world production applications. Its single-codebase approach, comprehensive widget ecosystem, and growing support for WebAssembly make it an increasingly attractive option for building sophisticated web products.

Despite these improvements, Flutter Web apps can still struggle with slow initial loading, large JavaScript bundles, and poor Core Web Vitals scores when performance optimization is overlooked. These challenges become more noticeable as applications grow in complexity. Features that make an application powerful—offline-first databases such as Drift and Floor, high-resolution images and videos, platform-specific integrations, real-time synchronization with backends like Supabase, and extensive screen collections—can also introduce significant performance bottlenecks if they aren't implemented carefully. An application that loads almost instantly on a high-end device may take several seconds to become interactive on a mid-range laptop with an unreliable internet connection.

In this guide, we'll examine practical strategies for optimizing Flutter Web performance, reducing loading times, and delivering a smoother user experience. Rather than focusing on a simple demo or counter application, we'll explore techniques suited to real-world projects with complex features, substantial data requirements, and growing codebases.

Why Flutter Web Performance Matters

Website speed directly affects:

• User engagement — users abandon apps that feel sluggish
• Bounce rate — slower pages lose visitors before they ever interact
• SEO rankings — Core Web Vitals are a ranking signal
• Conversion rates — every extra second of load time costs revenue
• Accessibility — fast, responsive UIs are usable on low-end devices and poor networks
• Overall user satisfaction — performance is the experience

Even a one-second improvement in page load time can significantly increase user retention.

Common Performance Problems

Typical Flutter Web applications encounter issues such as:

• Large initial bundles
• Slow first paint
• Excessive widget rebuilds
• Large image assets
• Un-optimized fonts
• Heavy third-party packages
• Blocking API calls

Advanced apps add their own bottlenecks on top of these: offline-first databases that stall startup, animated media that leaks memory, sync engines that flood the UI with updates, and plugins that silently break under WebAssembly.

Fortunately, most of these problems can be resolved with proper optimization—and this guide walks through each of them.

1. Start with the Renderer: CanvasKit vs. WASM vs. Skwasm

The renderer you choose sets the performance ceiling for everything else.

CanvasKit compiles Skia to WebAssembly and delivers consistent rendering across browsers. It is excellent for graphics-intensive apps, but it carries a larger initial download and higher memory usage. The Flutter team acknowledges that CanvasKit’s inherent file size (around 1.5 MB) can be a drawback when initial load time is critical, because all widgets must wait for it to fully load before the app becomes interactive.

WASM (dart2wasm) is now the recommended production default for Flutter web. It compiles Dart to WebAssembly, reduces app size compared to CanvasKit, and starts up faster than JavaScript. The caveat: WASM requires browsers with WasmGC support, so a CanvasKit fallback is still necessary for legacy browsers.

Skwasm is an experimental WebAssembly renderer that often beats CanvasKit on startup time and frame performance, especially in multi-threaded mode. It is worth tracking if your app is rendering-bound.

Practical rule: Build with flutter build web --wasm for modern browsers, and ship a CanvasKit fallback. Do not optimize for the lowest common denominator by default—your analytics will tell you how many users actually need the fallback.

2. Bundle Size Is the First Bottleneck: Split, Shake, and Lazy-Load

A default Flutter web release build can easily ship a 2–5 MB main.dart.js plus a CanvasKit payload. For a feature-heavy app, this is the single biggest threat to time-to-interactive and Core Web Vitals. The progremmo guide lists large initial bundles, slow first paint, and heavy third-party packages as the most common performance problems in Flutter web apps.

Deferred loading (code splitting)

Dart’s deferred as keyword splits your app into on-demand JS chunks. The Flutter documentation explains that deferred imports let you split your code and load parts of it only when needed, reducing initial load time. Instead of bundling every screen into the initial download, only the home screen ships upfront; each route loads its own chunk when visited.

The impact is dramatic. In a real 12-screen Flutter web app, initial JS transfer dropped from ~3.2 MB to ~780 KB (−76%), and Time to First Contentful Paint dropped from ~4.1 s to ~1.0 s on Slow 3G.

// Before
import 'screens/dashboard_screen.dart';

// After
import 'screens/dashboard_screen.dart' deferred as dashboard;

Wrap the route builder with a lazy loader (or use flutter_lazy_load_web to avoid boilerplate):

GoRoute(
  path: '/dashboard',
  builder: lazy(dashboard.loadLibrary, dashboard.DashboardScreen.new),
)

Unawaited function calls

A subtle but high-impact optimization from the Flutter team: to reduce the time taken to display the initial widget, do not await costly futures before calling runApp. Some futures can be left un-awaited so they update the UI after they complete, using Dart’s unawaited function to satisfy the linter.

void main() {
  WidgetsFlutterBinding.ensureInitialized();
  unawaited(_warmUpAnalytics()); // do not block first frame
  runApp(const MyApp());
}

Tree shaking and release mode

Tree shaking complements deferred loading. In release builds, dart2js removes unreferenced code. The biggest win is often Material Icons—switching from the full icon set to only-used icons saves hundreds of kilobytes. The progremmo checklist recommends removing unused packages, avoiding unnecessary library imports, splitting large features, and tree-shaking icons before deployment.

3. Asset Management: Images, Video, and the Memory Trap

Media is where advanced apps get into trouble on the web—especially because the renderer’s memory model differs from mobile. The progremmo guide warns that large image assets and un-optimized fonts are among the most common causes of slow first paint.

Serve modern formats and size correctly

Use WebP or AVIF instead of PNG/JPEG, and always request the size you actually render. The colinchflutter optimization guide specifically recommends WebP for better compression efficiency and suggests tools like cwebp or imagemin for pre-deployment optimization. Flutter’s cacheWidth parameter resizes decoded images to the width you specify, avoiding full-resolution decodes for small UI elements.

Image.network(
  'https://cdn.example.com/hero_1920w.webp',
  width: 800,
  cacheWidth: 800, // decode at display size
)

Use a dedicated image pipeline with caching

For a media-heavy app, do not rely on Image.network alone. Packages like Piksel provide a three-tier cache (memory LRU, disk cache, raw download cache), scroll-aware prefetching, and support for SVG, AVIF, GIF, and video frames through one pipeline. On web, disk tiers persist in IndexedDB, which is critical for repeat visits.

Pre-cache the first screen, not everything

Pre-caching warms both the browser cache and Flutter’s in-memory cache, eliminating font swaps and blank images on first paint. Combine HTML <link rel="preload"> hints in index.html with precacheImage in Dart. Pre-cache only what the user will see in the next one or two screens—the logo, hero image, main font variants, and the first API request.

The animated-image memory leak

This is a web-specific trap that does not exist on mobile. On web, when an animated image (GIF or animated WebP) remains in the ImageCache, its _ForwardingImageStreamCompleter keeps a listener on the inner completer even after the widget is removed from the tree. The animation keeps decoding frames at its own frame rate, consuming CPU and growing the WASM heap.

In one production feed, 14 off-screen animations were still decoding at 8–11 fps each, costing about one CPU core in Firefox and 0.7 in Chrome while the app sat idle. The CanvasKit WASM heap grew to 224 MB.

Mitigation: call imageCache.clear() when navigating away from media-heavy screens, or use a package that manages completer lifecycle correctly.

4. Offline-First Databases on the Web: Drift, Floor, and Friends

Offline-first is no longer just a mobile concern—users expect instant loads and reliable edits regardless of network state. But not all Flutter databases have equal web support.

Drift: the production-grade SQL choice

Drift runs on the web by compiling SQLite to WebAssembly. You place a prebuilt sqlite3.wasm file and a drift_worker.js worker into your web/ directory, then open the database with WasmDatabase.open. The worker shares the database across tabs, and the database persists in IndexedDB. Drift’s documentation notes that the web build requires sqlite3.wasm, COOP, and COEP headers to function correctly.

This is the most mature SQL option for web-capable offline-first apps that need joins, migrations, and reactive queries.

Floor: the Room-inspired alternative

Floor provides a neat SQLite abstraction inspired by Android’s Room persistence library, with automatic mapping between in-memory objects and database rows while still allowing full SQL control. It is a strong choice if your team prefers the Floor API or is porting an existing mobile codebase.

However, Floor does not officially list web among its supported platforms—its documented targets are iOS, Android, Linux, macOS, and Windows. Because Floor is built on top of sqflite, web support is technically possible by switching to the sqflite_common_ffi_web database factory, which implements sqflite on the web using sqlite3 compiled to WebAssembly, with persistence in IndexedDB and SQLite running in a shared worker. This path is experimental: the sqflite_common_ffi_web package itself describes its status as “slow, not fully tested, bugs,” and notes limitations such as lack of deleteDatabase support on WASM.

If you choose Floor for web, budget time for this integration and test thoroughly across browsers. If web is a first-class target and you need SQL guarantees, Drift is the safer bet.

The repository pattern keeps web and mobile logic aligned

The core architectural principle is the Repository Pattern. Your UI talks to a repository, which orchestrates an ApiClientService (remote HTTP) and a DatabaseService (local persistence). The UI never knows whether data came from cache or server.

For reads, the Stream-based approach is the gold standard for responsive UIs: the repository immediately yields locally cached data (instant paint), while a network call runs in the background and updates the database; the stream then emits fresh data and the UI updates seamlessly.

PWA service workers for shell caching

Flutter web’s default service worker uses an offline-first strategy: it eagerly caches the application shell and lazily caches subsequent assets as they load. You can control this with flutter build web --pwa-strategy=offline-first, which pre-caches all assets for reliable offline startup.

A common production strategy is network-first for API calls, cache-first for static assets—so the shell loads instantly even on a flaky connection, while data stays fresh when the network is available. The progremmo guide emphasizes caching images, fonts, API responses, static assets, and JavaScript files through service workers to provide offline support and efficient asset management.

5. Syncing with Supabase: Connecting Your Local Database to the Cloud

If your app uses Supabase as its backend, you need a deliberate sync strategy. Supabase provides authentication, Postgres, real-time subscriptions, and row-level security, but offline-first behavior is not automatic—you must pair it with a local database and a sync layer.

The architecture: local DB + Supabase + sync engine

The reliable pattern is:

1. Local database (Drift or Floor) holds the source of truth for the UI.
2. Supabase acts as the remote source of truth and real-time event source.
3. A sync engine reconciles the two: pull changes on startup and on connectivity regain, push queued local writes when online, and resolve conflicts deterministically.

Several packages implement this pattern. syncitron transforms an online-only Supabase app into an offline-first platform by handling bidirectional synchronization, with the local store being SQLite, Hive, Drift, or Isar, and remote adapters connecting to Supabase. dynos_sync is a production-grade sync engine that works with Drift + Supabase and supports delta pulls and background isolate offloading for large datasets. PowerSync also offers a Flutter library that keeps an embedded database in sync with Supabase in the background.

Key Supabase sync practices for web

• Queue writes offline. Every insert, update, and delete should be written locally first and appended to an offline write queue. When connectivity returns, flush the queue in order. supabase_flutter_ultra, for example, adds an offline write queue and delta sync on top of the standard Supabase APIs—but check its platform support carefully, because some versions depend on sqflite and may not support web.
• Use delta sync, not full table downloads. Pull only rows changed since the last sync timestamp or cursor. Full-table syncs on web are a fast path to memory pressure and slow startup.
• Handle conflicts explicitly. Decide your conflict resolution policy up front—last-write-wins, server-wins, or a custom merge—and encode it in the sync engine, not scattered across repositories.
• Leverage Supabase Realtime selectively. Realtime subscriptions are powerful, but on web they hold open WebSocket connections and consume memory. Subscribe only to tables that truly need live updates, and unsubscribe when the relevant screen is disposed.
• Keep auth tokens fresh without blocking. Supabase’s client handles token refresh, but do not await auth restoration before runApp. Restore the session asynchronously and let the UI render a loading or cached state immediately.

Web-specific Supabase caveat

Supabase’s official Flutter SDK works on web, but many “offline-first wrapper” packages are mobile-first and may not list web support. Before adopting a sync package, verify its platform support on pub.dev and test the IndexedDB/WebAssembly path. If a wrapper is not web-ready, you can still use the core supabase_flutter package for remote calls and implement the sync loop yourself against Drift or Floor.

6. Responsive Design: Breakpoints, Not Guesswork

A feature-heavy mobile app ported to web often looks like a stretched phone UI. Responsive design on Flutter web is not optional—it is a performance and usability requirement. The colinchflutter guide stresses using LayoutBuilder and media queries to dynamically adjust the UI based on available space, and optimizing Flex and Expanded widgets to ensure efficient space distribution and avoid unnecessary renderings.

Use MediaQuery.sizeOf(context) for whole-window decisions and LayoutBuilder for parent-constraint decisions (especially in multi-window and foldable contexts). Define explicit breakpoints for phone, tablet, and desktop, and switch navigation patterns (bottom nav → navigation rail → side drawer).

Performance note: Responsive layouts that rebuild large widget subtrees on every resize event can cause jank. Debounce breakpoint changes, and use const widgets wherever possible. The progremmo guide explicitly recommends reducing widget rebuilds with const constructors, splitting large widgets, using selectors, and managing state efficiently.

7. Web-Specific Plugins and Native Interop

Not every Flutter plugin supports web. Before committing to a plugin, check its platform support matrix. For plugins that lack web implementations, you have two paths:

1. Use a web-compatible alternative that exposes a unified API.
2. Write a thin web implementation using dart:js_interop and package:web.

The modern interop stack replaces the legacy dart:html library and is fully compatible with WASM builds. The Flutter team specifically notes that dart:html is not supported when building with WASM, whereas package:web works with both dart2wasm and dart2js.

import 'dart:js_interop';
import 'package:web/web.dart';

final input = document.querySelector('#email') as HTMLInputElement;
input.value = 'user@example.com';

Caution: Native features that rely on device APIs (file system, Bluetooth, biometrics) often have no direct web equivalent. Design your architecture so that these features degrade gracefully on web—hide unavailable UI, provide browser-based alternatives (File System Access API, Web Bluetooth), and never block the entire app on a missing plugin.

8. SEO and Discoverability: The Flutter Web Elephant

Out of the box, Flutter web serves an app shell with minimal crawlable HTML. Search engines and social bots that do not execute JavaScript see a blank canvas.

For app-like routes behind authentication, this may be acceptable. For public-facing pages—marketing, documentation, product listings—it is a significant limitation.

Practical SEO strategies

• Pre-render critical routes to static HTML. Tools like flutter_prerender load each route in headless Chrome and emit real <h1>, <p>, <a>, meta tags, and a sitemap.
• Inject meta tags dynamically per route using dart:js_interop to update document.title and meta description as the user navigates.
• Use a hybrid architecture: pre-render public pages as static HTML and mount the Flutter app for authenticated, app-like experiences. This gives you SEO where it matters without sacrificing the Flutter development model for the core product.

9. Measure, Profile, and Iterate

Optimization without measurement is guesswork. The colinchflutter guide highlights Flutter DevTools for profiling CPU usage, memory allocation, and network requests to identify bottlenecks. The progremmo guide adds Lighthouse, Chrome DevTools, and WebPageTest as essential tools for monitoring Core Web Vitals and validating improvements.

Two metrics to anchor on:

• Lighthouse: Target LCP < 2.5 s, FID < 100 ms, and CLS < 0.1.
• WASM heap profiling: Pay special attention to the WASM heap when using CanvasKit or Skwasm—memory leaks in image and canvas lifecycles are common on web.

Build a performance budget into CI: if a pull request increases the initial bundle by more than a threshold, fail the build. The progremmo production checklist is a useful starting point: enable release mode, optimize images, compress assets, enable HTTP caching, lazy-load features, remove unused dependencies, use const widgets, optimize fonts, and test Lighthouse scores before every deploy.

Key Takeaways (Short and Actionable)

1. Pick the right renderer. Use WASM for modern browsers; keep CanvasKit as a fallback.
2. Split your bundle per route. Deferred loading cuts initial JS by 70%+ and first paint to about 1 second on 3G.
3. Don’t block runApp. Use unawaited for warm-up tasks so the first frame renders sooner.
4. Optimize media. WebP/AVIF, display-size decoding, and an image cache lifecycle that doesn’t leak animations.
5. Choose Drift for SQL-first offline web apps. Floor is viable via sqflite_common_ffi_web, but its web support is experimental—test carefully.
6. Sync Supabase deliberately. Local DB + queue + delta sync + explicit conflict policy. Verify web support of any sync wrapper before adopting it.
7. Design for breakpoints from day one. A stretched mobile UI is both a UX and performance failure.
8. Measure with Lighthouse and DevTools. Treat performance as a CI-enforced feature, not an afterthought.

Conclusion

Optimizing a feature-heavy Flutter app for the web is not a single switch—it is a series of deliberate trade-offs. The good news is that every bottleneck discussed in this guide has a proven remedy:

• Renderer choice sets the ceiling. Build with --wasm for modern browsers and keep CanvasKit as a fallback .
• Bundle size is the first thing users feel. Deferred loading turns a multi-megabyte initial download into per-route chunks, cutting time-to-interactive dramatically .
• Media demands a pipeline, not an Image.network call. WebP/AVIF, display-size decoding, and lifecycle-aware caching prevent the silent memory leaks that animated images cause on web.
• Offline-first databases work on web—Drift is the production-grade SQL choice via sqlite3.wasm, while Floor is viable through sqflite_common_ffi_web if you accept its experimental status .
• Supabase syncing requires a local-first architecture: write locally, queue offline mutations, delta-sync on reconnect, and resolve conflicts explicitly. Packages like synclayer_supabase, supabase_flutter_ultra, and PowerSync’s Supabase integration implement this pattern so you do not have to build it from scratch .
• Responsive design and performance measurement are not polish—they are requirements. Lighthouse and DevTools close the loop, and a CI performance budget keeps optimizations from regressing.

The Flutter team’s own guidance reinforces this: measure rendering performance in profile/release mode, avoid unnecessary widget rebuilds, and treat deferred loading and tree shaking as first-class optimization tools . The Flutter Material team’s experience optimizing the Flutter Gallery app confirms that these techniques deliver measurable wins in production .

Flutter web can absolutely handle a feature-heavy, offline-first, media-rich application. The difference between a frustrating experience and a seamless one is not the framework—it is the discipline of optimizing the bottlenecks that advanced apps inevitably introduce.

References and Further Reading

Flutter Web Performance (Official)

• Flutter — Performance best practices: https://docs.flutter.dev/perf/best-practices
• Flutter — Improving rendering performance: https://docs.flutter.dev/perf/rendering-performance
• Flutter — Optimizing performance in Flutter web apps with tree shaking and deferred loading (Flutter Material team series): https://docs.flutter.dev/perf/web-performance

WebAssembly and Renderers

• Flutter — Support for WebAssembly (Wasm): https://docs.flutter.dev/platform-integration/web/wasm
• Flutter — Build and release a web app (including --wasm): https://docs.flutter.dev/deployment/web

Deferred Loading / Code Splitting

• Flutter — Deferred components for Android and web: https://docs.flutter.dev/perf/deferred-components
• Dart — Lazily loading a library (deferred imports): https://dart.dev/language/libraries#lazily-loading-a-library
• flutter_lazy_load_web package: https://pub.dev/packages/flutter_lazy_load_web

Offline-First Databases

• Drift — Web setup (sqlite3.wasm + drift_worker.js): https://drift.simonbinder.eu/platforms/web/
• Drift — Official site: https://drift.simonbinder.eu/
• sqlite3.wasm binaries (used by both Drift and sqflite web): https://github.com/simolus3/sqlite3.dart/releases
• Floor — Package: https://pub.dev/packages/floor
• sqflite_common_ffi_web — Experimental web implementation for sqflite/Floor: https://pub.dev/packages/sqflite_common_ffi_web

Supabase and Offline Sync

• Supabase Flutter — Official package: https://pub.dev/packages/supabase_flutter
• synclayer_supabase — Supabase adapter for SyncLayer (offline-first, delta sync, conflict resolution): https://pub.dev/packages/synclayer_supabase
• supabase_flutter_ultra — Offline-first wrapper with write queue and delta sync: https://pub.dev/packages/supabase_flutter_ultra
• PowerSync — Offline-first sync with Supabase (FlutterFlow integration guide): https://blog.flutterflow.io/introducing-a-local-database-that-auto-syncs-with-supabase/
• dynos_sync — Drift + Supabase sync engine: https://pub.dev/packages/dynos_sync

Web Interop and Plugins

• Dart — dart:js_interop documentation: https://dart.dev/interop/js-interop
• package:web: https://pub.dev/packages/web

Articles and Community Guides

• Flutter — Best practices for optimizing Flutter web loading speed: https://flutter.dev/blog/best-practices-for-optimizing-flutter-web-loading-speed
• Colinchflutter — Optimizing Flutter web performance: https://colinchflutter.github.io/2023-09-26/10-10-14-784390-optimizing-flutter-web-performance/

I had just been from rewriting SwahiLib my Swahili dictionary app from Flutter to native using Kotlin and Jet Pack Compose. It was not easy and neither was it hard because I eventually finished it in record 4 months. I even wrote about the migration in my previous article: Rewriting My Flutter App to Native Android: A Side-by-Side Architecture Breakdown. This is a follow up on the article with a diversion into the already exhausted topic of modularising. I hope by the end of this article I would have impacted something on you.

SwahiLib — the Swahili dictionary app I'd already rewritten once, from Flutter to native Kotlin and Compose — had grown into a single app module holding every screen, every repository, every database query. It worked. But sadly as Kotlin compilation would have it, it also meant that fixing a typo in the Proverb screen recompiled the Idiom screen, the Saying screen, the Word screen, and everything else along with it, every single time. I didn't know that precisely having been in Flutter developer for a long time since covid times until when I complained about it on X.

https://x.com/SiroFitsKe/status/2044658023436583303

I remember Brian Orwe commenting with just one word: Kotlin to which I responded with ?? I think he thought I would figure it out once from just that but I needed more explanation. His next reply sent chills down my nerves into what I have been avoiding ever since I started writing Kotlin code for fun.

https://x.com/BrianOrwe/status/2044683909804294432?s=20

I told him I have always looked at that DroidconKe app and I just get tired to be honest of the numerous modules in it, I also looked at the codebase of Streeeka by one Mambo Brian and while both apps would build and run fine when all dependancies were fetched and gradle synced I just would not buy into the idea of modularising every single feature and so forth. I love simplicity esp for a small app like mine.

But Brian replied with the sentence that ended my denial:

"Your app might be getting big that you might start to need to consider the complexity that comes with separation of modules as a reasonable consequence, verses long compile times because you changed a single line."

After careful consideration, I knew he was right, which was almost the annoying part. I'd looked at modularising SwahiLib before and backed away from it every time. This is the story of the three weeks it took me to stop backing away.

Why I'd Been Avoiding It

I like simple apps. SwahiLib isn't huge — a dictionary of Swahili idioms, proverbs, sayings, and words, with search, history, a settings screen, a light/dark theme. One app module had been enough for a long time, and "enough" is a comfortable place to live.

The few times I'd poked at modularising, I'd gone looking at Google's Now in Android for a template, the way half of Android Twitter does. NiA is a genuinely excellent reference app — and a lot: convention plugins, Jacoco wiring, Spotless tasks, Gradle managed devices, a feature module split into API and implementation, a dependency graph generator. I'd get three folders deep and close it again, half convinced modularising meant all of that or none of it. For an app I maintain alone, that felt like the exact over-engineering I was trying to avoid. Brian's tweet didn't tell me anything I didn't already suspect — it just purged my excuse for sitting on it.

Attempt 1: Copying the Image, Not the Idea

I began the difficult journey by opening a feature-modularisation branch and did what most people do the first time: split the app along the architecture diagram's layers. Four new modules went in — core, data, domain, presentation — and almost everything in app got moved into one of them. I was tired enough to call the commit more modularisation, which undersold it; it touched over 100 files in one go.

Each module, because Android Studio generates a full library module whether you need one or not, came with its own AndroidManifest.xml, launcher icons in five densities, light/dark theme XML, and a proguard-rules.pro. Four copies of an app icon nobody would ever see, since none of these were app modules. That should have been my first sign I was modularising by template rather than by need.

A week later I realized I needed a build-logic module — a convention-plugins setup, lifted straight from NiA: a Kotlin Gradle plugin per concern, so modules wouldn't repeat the same android {} block and dependency wiring. 30 files landed in one commit, titled simply build-logic, mostly airlifted, with a vague plan to trim what I didn't need once the build worked.

Friction came fast. I tried to finally get App Flavours done right, something I'd always wanted in every project. Somewhere in there, an entire staging flavour's resource set got deleted — icons, themes, manifest extras, all of it. Turns out you get a lot more opinionated about which module owns what once you're not the only module in the project.

A day later, exhausted but happy, I wrote the commit message I'm most fond of in this whole history: getting it to run after a number of iterations. 9 files massaged — the understatement doing a lot of work. The same day, data module lost about 20 files, most of which had landed only the day before: code I'd just relocated, deleted again because the dependency graph between modules wasn't behaving the way I'd assumed. Sentry broke in the move and had to be patched back before I could proceed further.

The Reset

The next day I did the thing that's hardest to do after a week and a half of work: I admitted attempt one wasn't working and reverted it. 2 PRs landed that day. The first Fixing the modularisation — generous, in hindsight. The second one was blunter: removing core, data, domain and presentation modules. Over 250 files were purged. Every module I'd built over the previous ten days, gone, back to the one app module.

I want to be honest about what that commit represents, because I think it's the most useful part of this whole story for anyone reading this before they start their own modularisation: the layer-based split — one module each for core, data, domain, presentation — didn't actually fix the problem that started this. presentation still held every screen in the app. Touching the Idiom screen still meant recompiling the module that also contained Proverb, Saying, Word, Home, and Settings. I'd added module boundaries without adding the isolation I was modularising for.

Round 2: Hitting the Same Wall Again

After a weekend cycling with friends, I started the week with fixing ktor, then the rebuild itself followed — committing more modularisation again, the exact same message that opened attempt one, like muscle memory typing itself in before I'd noticed. core, data, domain, presentation came back, this time with DI wired more sensibly per module instead of dumped into core. A cleaner version of the same shape. fixing dependencies closed out the day, the now-familiar texture of a networking layer arguing with module boundaries.

It was still wrong in the way that mattered: one presentation module, every screen inside it. I'd fixed the craftsmanship of attempt one without questioning its premise.

Then nothing for a week, despite doing things differently this time, save for that repeated commit message. I won't pretend the gap was strategic — I looked at the app, got tired the way I get tired of this particular problem, and did other things for a few days to relax from the whole modularisation headache.

What Actually Clicked

More than a week later, I came back and landed the commit fully modularised and done properly. This time the message wasn't an understatement — it actually fixed the build-time problem I'd set out to solve in the first place.

The fix wasn't more modules. It was modularising along a completely different axis.

• Instead of cramming every screen into one presentation module, each screen got its own feature module.

• Instead of one core module holding everything that wasn't UI, core got split by what each piece actually did — not by which architectural layer it was supposed to belong to.

app/
core/
  common/
  data/
  database/
  designsystem/
  network/
  ui/
feature/
  home/
  idiom/
  init/
  proverb/
  saying/
  settings/
  splash/
  word/

settings.gradle.kts ended up reading roughly like this:

include(":app")

include(":core:common")
include(":core:data")
include(":core:database")
include(":core:designsystem")
include(":core:network")
include(":core:ui")

include(":feature:home")
include(":feature:idiom")
include(":feature:init")
include(":feature:proverb")
include(":feature:saying")
include(":feature:settings")
include(":feature:splash")
include(":feature:word")

The shape matters more than the names

Feature modules don't need to depend on each other — feature:idiom has no business knowing feature:word exists. Each one only reaches down into the core modules it actually needs: core:database for Room, core:network for the API client, core:designsystem for shared theming, core:ui for shared composables and resources. app sits on top, wiring navigation between features and not doing much else.

This is the real difference from the previous 2 attempts:

Gradle's incremental build only recompiles a module and whatever depends on it.

• When every screen lived in presentation, any screen change recompiled presentation entirely.

• Now, a change in feature:idiom only recompiles feature:idiom and app. feature:word, three folders over, stays untouched.

Generic names disappeared

core, data, and domain as catch-all labels are gone:

• The domain repository-interface layer — one interface, one implementation each — got dropped. It's ceremony that earns its keep at Google's scale and mostly adds indirection at mine.

• What survived moved into modules named for what they actually hold: Room and its DAOs into core:database, the few genuinely cross-feature repositories (mainly theme preference) into core:data.

build-logic got pruned hard — the part of attempt one I'm glad I tried and glad I didn't keep, since trying it taught me what to cut.

So what Survived? After all was done I remained with 4 plugins, applied consistently across fourteen modules:

• a library convention plugin

• a Compose-library plugin

• a single AndroidFeatureConventionPlugin

• a Hilt plugin —

What was cut? A lot of files, deleted in the commit that finally made it work:

• The app-level convention plugin (no point sharing config across app modules that don't exist).

• The feature API/implementation split (built for cross-feature dependencies I don't have)

• Jacoco, dedicated Lint and Test plugins,

• Room and Networking plugins,

• Subscriptions and Supabase plugins, a RootPlugin

• NiA's tooling helpers — badging, Gradle managed devices, dependency graph generator, Spotless.

None of that tooling is bad — most of it's well built. It's tooling for a team, and I'm not one. Keeping it would have been the over-engineering I was avoiding all along, just arrived at by copying instead of choosing.

app itself shrank to almost nothing: MainActivity.kt, the SwahiLibApp application class, a top-level AppNavHost stitching feature nav graphs together, and one DI module for network config. That's it. Everything else lives where it's used.

The Last Mile

fully modularised and done properly is a confident commit message, and it was nearly true. A few loose ends followed. The cleanup that week had swept away app/proguard-rules.pro along with everything else — and a release build doesn't run without it. Four files: one restored proguard config, one added release script.

Modularisation doesn't end on the commit where you say it's done. It ends a day later, when you try to ship a release build and find out what you forgot.

Did Builds Actually Get Faster?

I don't have a formal before-and-after benchmark to hand you, and I'd rather say that plainly than make up an impressive-sounding number for a blog post. What I can tell you, structurally, is why this should be faster — and it matches what I feel day to day: a one-line change in feature:idiom no longer has any reason to touch the other seven feature modules, since Gradle only recompiles a module and whatever sits above it in the dependency graph. Those eight modules can also compile in parallel rather than waiting on each other, since none of them depend on one another at all.

If you've got your own Gradle build scan or --profile output from a before-and-after like this, it's worth more than my word for it — paste it in below.

Conclusion of the Matter

A few things, if I could send them back to April 20th to my old me:

• Modularise along feature boundaries first — that's the axis that actually isolates what gets rebuilt. Splitting by architectural layer instead (core, data, domain, presentation) looks like progress but barely touches build times, since all your screens are still sitting in one module together.

• Don't adopt a reference app's entire tooling surface just because it's the reference app. Convention plugins paid off almost immediately; Jacoco, Spotless, and managed-device test plugins didn't. The only way I found that line was installing all of it once and watching what I never touched.

• Expect to delete code you just wrote. The 252-file revert wasn't the project going wrong — it was the project finding its actual shape.

• Budget real calendar time, even for a small app. Hilt, KSP, and Gradle's manifest merger all have opinions about module boundaries you won't discover until you've crossed one.

Brian Orwe, if you're reading this — thanks for the push. I'd have gotten here eventually, but probably not in three weeks, and probably not without a tweet in my replies reminding me I'd been avoiding it.

This isn't a "Flutter bad, native good" post. Flutter did its job — it got SwahiLib to market fast and it ran the same logic on two platforms: Android and iOS with just one codebase. But after maintaining it for a while, I started covetting the things native side of the platforms gives you that Flutter, by design, can't:

• zero-bridge access to platform APIs,

• a UI toolkit that's a first-class citizen instead of a guest renderer,

• a much smaller gap between "what the OS does" and "what my code does."

In this article I will be taking you through a practical, code-level comparison of the two codebases — same app, same features, same Supabase backend, two completely different architectures. I have written this from the perspective of someone who's done the rewrite, not someone theorizing about it, so I'll point out where native actually paid off and where it cost me something I didn't expect.

The app, briefly

SwahiLib is an offline-first Swahili dictionary (Kamusi) app that gives users access to words (maneno), idioms (nahau), proverbs (methali), and sayings (misemo). After the install data is seeded locally, everything is searchable offline, allowing the app to work seamlessly without needing an internet connection.

The app uses Supabase as its BaaS. Data is fetched once, stored locally, and kept in sync through efficient batching and caching strategies. With a dataset of approximately 17,000 records, optimizing local storage, search performance, and synchronization is a key part of the application's design.

Both the Android and iOS versions solve the same core challenges: fetching data from Supabase, persisting it locally, providing fast offline search and filtering, displaying detailed content screens, and supporting light and dark themes.

Start from dependencies: what each side actually pulls in

This is the first thing that hits you when you put both pubspec.yaml and build.gradle.kts side by side — the shape of the dependency list tells you the architectural story before you've read a line of business logic.

Flutter (pubspec.yaml):

dependencies:
  floor: ^1.5.0                  # SQLite ORM with DAO pattern
  flutter_bloc: ^8.1.6            # State management
  get_it: ^8.0.2                  # Service locator
  injectable: ^2.5.0               # DI code generation on top of get_it
  http: ^1.3.0
  supabase_flutter: ^2.8.3
  sentry_flutter: ^8.5.0
  shared_preferences: ^2.3.3
  freezed_annotation: ^2.4.4       # Immutable unions for BLoC states/events
  json_annotation: ^4.9.0

dev_dependencies:
  build_runner: ^2.4.13
  floor_generator: ^1.5.0
  freezed: ^2.5.7
  json_serializable: ^6.8.0

Kotlin (libs.versions.toml / build.gradle.kts):

implementation(libs.androidx.room.runtime)       // SQLite ORM
ksp(libs.androidx.room.compiler)
implementation(libs.hilt.android)                 // DI
ksp(libs.hilt.compiler)
implementation(libs.squareup.retrofit)
implementation(platform(libs.jan.tennert.supabase.bom))
implementation(libs.jan.tennert.supabase.postgrest)
implementation(libs.ktor.client.android)
implementation(libs.kotlinx.serialization.json)
implementation(libs.androidx.compose.bom...)      // Compose BOM + UI artifacts
alias(libs.plugins.io.sentry)

A few things jump out immediately:

• One dependency manager generation step disappears entirely. Flutter's floor, freezed, and json_serializable all run through build_runner, a single generic codegen pipeline you invoke manually (dart run build_runner build --delete-conflicting-outputs) whenever you touch an annotated class. Kotlin's ksp (Kotlin Symbol Processing) does the equivalent for Room and Hilt, but it's wired directly into the Gradle build graph — it runs automatically as part of compileDebugKotlin, incrementally, without you remembering to invoke it. This sounds small until you've lost like 30 minutes to a stale .g.dart file that the IDE didn't regenerate in your Flutter build.

• get_it + injectable becomes just Hilt. In Flutter, dependency injection is two libraries glued together: get_it is the actual service locator, injectable is a code-gen layer that writes the registration boilerplate for you by scanning @injectable/@singleton annotations. In Kotlin, Hilt (which itself wraps Dagger) does both jobs as one Gradle plugin, and critically, it's compile-time validated — if you forget to provide a dependency, the build fails with a clear graph error instead of a runtime Bad state: GetIt: Object/factory not registered.

• No freezed. Kotlin's sealed class / data class plus when exhaustiveness checking gives you most of what freezed exists to bolt onto Dart. You see this directly comparing state modeling below.

• RevenueCat and Billing only show up in the Kotlin version — not because Flutter couldn't do subscriptions, but because the rewrite was also the point where I added a paywall. Worth flagging so you don't think this is a 1:1 feature port; it's an architecture port with some product evolution riding along.

Dependency injection: get_it/injectable → Hilt

Flutter's DI setup is annotation-driven but still requires an explicit init call at app startup:

// injectable.dart
final getIt = GetIt.instance;

@InjectableInit(initializerName: r'initGetIt', generateForDir: ['lib'])
Future<void> configureDependencies(String environment) async {
  await getIt.initGetIt(environment: environment);
  await getIt.allReady();
}

@module
abstract class RegisterModule {
  @singleton
  @preResolve
  Future<SharedPreferences> prefRepo() => SharedPreferences.getInstance();

  @singleton
  @preResolve
  Future<AppDatabase> provideAppDatabase() async => await $FloorAppDatabase
      .databaseBuilder(await AppConstants.databaseFile)
      .build();
}

And then main.dart has to explicitly await it before runApp():

await configureDependencies(Environments.production);
await SentryFlutter.init(
  (options) => options.dsn = sentryUrl,
  appRunner: () => runApp(const SentryWidget(child: MyApp())),
);

In the Kotlin rewrite, Hilt modules just declare what they provide, and the Application class is a one-line annotation:

@HiltAndroidApp
class SwahiLibApp : Application() {
    override fun onCreate() {
        super.onCreate()

        SentryAndroid.init(this) { options ->
            options.dsn = BuildConfig.SentryDsn
            options.tracesSampleRate = 1.0
        }
    }
}

@InstallIn(SingletonComponent::class)
@Module
object DatabaseModule {
    @Provides @Singleton
    fun provideDatabase(@ApplicationContext appContext: Context): AppDatabase =
        Room.databaseBuilder(appContext, AppDatabase::class.java, "SwahiliLibrary")
            .fallbackToDestructiveMigration()
            .build()

    @Provides
    fun provideWordDao(database: AppDatabase): WordDao = database.wordsDao()
}

There's no await getIt.allReady() step to forget, no async resolution race to reason about. Hilt builds the dependency graph at compile time via annotation processing, and @AndroidEntryPoint / @HiltViewModel wire injection directly into Android's component lifecycle (Activity, ViewModel) rather than through a global service locator you query manually. The trade-off: Hilt's compiler errors, when something's wrong, are notoriously verbose stack traces full of generated class names. get_it's runtime failures are friendlier to read but you only find them by actually hitting that code path.

Local persistence: Floor → Room

This is the most mechanical migration in the entire rewrite, almost a find-and-replace, because Floor is explicitly modeled after Room — Marco Cattaneo built it that way on purpose for Flutter devs coming from Android. If you've ever wondered which one to learn first, it doesn't matter; the concepts transfer almost annotation-for-annotation.

// Flutter — Floor
@Entity(tableName: AppConstants.wordsTable)
@JsonSerializable()
class Word {
  @PrimaryKey()
  int? id;
  int? rid;
  String? title;
  String? meaning;
  // ...
  factory Word.fromJson(Map<String, dynamic> json) => _$WordFromJson(json);
}

@dao
abstract class WordsDao {
  @Query('SELECT * FROM ${AppConstants.wordsTable} WHERE id = :id')
  Future<Word?> findWordById(int id);

  @Insert(onConflict: OnConflictStrategy.replace)
  Future<void> insertWord(Word word);

  @Query("DELETE FROM ${AppConstants.wordsTable}")
  Future<void> deleteAllWords();
}

// Kotlin — Room
@Entity(tableName = Collections.WORDS, indices = [Index(value = ["rid"], unique = true)])
data class Word(
    @PrimaryKey val rid: Int = 0,
    @ColumnInfo(name = "title") val title: String? = null,
    @ColumnInfo(name = "meaning") val meaning: String? = null,
    // ...
) : Parcelable

@Dao
interface WordDao {
    @Query("SELECT * FROM ${Collections.WORDS} WHERE rid = :rid")
    fun getById(rid: String): Flow<Word>

    @Insert(onConflict = OnConflictStrategy.Companion.REPLACE)
    suspend fun insertAll(words: List<Word>)

    @Query("DELETE FROM ${Collections.WORDS}")
    fun delete()
}

Same @Entity/@Dao/@Query vocabulary, same OnConflictStrategy, same raw-SQL-with-named-params approach. Two differences worth calling out for anyone doing this migration:

1. Room DAOs return Flow<T> natively. Floor's DAO methods return Future<T> — a one-shot read. If you want reactive, auto-updating queries in Floor you have to explicitly declare a Stream<List<Word>> return type and Floor generates the observer wiring for you, which works but is opt-in per query. In Room, returning Flow<List<Word>> is the idiomatic default and plugs directly into StateFlow/Compose's collectAsState() with no extra ceremony.

2. @Parcelize matters more on the native side because Compose Navigation passes complex objects between composables via SavedStateHandle, and Word : Parcelable makes that free. In Flutter, since everything lives in one Dart isolate by default, you just pass the object reference directly through the navigator — there's no parcel/serialize boundary to cross for in-process navigation.

Networking and sync: same Supabase, different client ergonomics

Both versions talk to the same Postgres-backed Supabase project, but the client libraries shape the sync code differently. Here's the Flutter side syncing on first launch:

class DataInitBloc extends Bloc<DataInitEvent, DataInitState> {
  DataInitBloc() : super(const _DataInitState()) {
    on<FetchData>(_onFetchData);
    on<SaveData>(_onSaveData);
  }

  final _dataRepo = DataInitRepository(Supabase.instance.client);

  void _onFetchData(FetchData event, Emitter<DataInitState> emit) async {
    emit(const DataInitProgressState());
    final idioms = await _dataRepo.fetchIdioms();
    final proverbs = await _dataRepo.fetchProverbs();
    final sayings = await _dataRepo.fetchSayings();
    final words = await _dataRepo.fetchWords();
    emit(DataInitFetchedState(idioms, proverbs, sayings, words));
  }

  void _onSaveData(SaveData event, Emitter<DataInitState> emit) async {
    emit(const DataInitSavingState('Inapakia maneno (words) 16,641 ...', 0));
    for (int i = 0; i < event.words.length; i++) {
      int progress = (i / event.words.length * 100).toInt();
      emit(DataInitSavingState(progressDesc(progress), progress));
      await _dbRepo.saveWord(event.words[i]);
    }
    // ...repeats for idioms, proverbs, sayings
    emit(const DataInitSavedState());
  }
}

And the Kotlin equivalent, using the supabase-kt client (the official Kotlin Multiplatform SDK, built on Ktor):

@HiltViewModel
class InitViewModel @Inject constructor(
    private val idiomRepo: IdiomRepo,
    private val proverbRepo: ProverbRepo,
    private val sayingRepo: SayingRepo,
    private val wordRepo: WordRepo,
    private val prefsRepo: PrefsRepo,
) : ViewModel() {
    fun initialize(context: Context) {
        viewModelScope.launch {
            _uiState.emit(UiState.Loading)
            if (NetworkUtils.isNetworkAvailable(context)) {
                val idiomInit = async { idiomRepo.fetchRemoteData() }
                val proverbInit = async { proverbRepo.fetchRemoteData() }
                val sayingInit = async { sayingRepo.fetchRemoteData() }
                val wordInit = async { wordRepo.fetchRemoteData() }

                idiomInit.await(); proverbInit.await()
                sayingInit.await(); wordInit.await()

                prefsRepo.isDataLoaded = true
                _uiState.emit(UiState.Saved)
            } else {
                _uiState.emit(UiState.Error("Loo! Hapa bila muunganisho wa intaneti..."))
            }
        }
    }
}

And inside WordRepo, the actual fetch is paginated explicitly against Supabase's range():

suspend fun fetchRemoteData(): Result<Int> = withContext(Dispatchers.IO) {
    runCatching {
        var offset = 0L
        val pageSize = 2000
        val allWords = mutableListOf<Word>()

        while (true) {
            val batch = supabase[Collections.WORDS]
                .select { range(offset, offset + pageSize - 1) }
                .decodeList<WordDto>()
            if (batch.isEmpty()) break
            allWords.addAll(batch.map(MapDtoToEntity::mapToEntity))
            if (batch.size < pageSize) break
            offset += pageSize
        }
        saveWords(allWords)
        Result.success(allWords.size)
    }.getOrElse { Result.failure(it) }
}

The structural difference here isn't really Flutter-vs-Kotlin, it's BLoC-vs-coroutines as a concurrency model:

• BLoC's _onSaveData runs the four-collection save sequentially, await-ing each _dbRepo.save*() call in a loop, because events in a single BLoC handler execute linearly by design — that's the whole point of the event-to-state contract.

• The Kotlin version explicitly fires all four fetchRemoteData() calls as parallel coroutines via async {}, then await()s them together. kotlinx.coroutines structured concurrency makes "do these four things at once, then proceed" a two-line pattern. You can do this in Dart with Future.wait([...]), but BLoC's event-driven model doesn't naturally nudge you toward it the way viewModelScope.launch { async {} } does — I had to deliberately reach for it.

This wasn't a one-for-one logic port — it's a case where the new architecture made an actual performance improvement (parallel fetch instead of serial) obvious enough that I took it. That's worth calling out to readers planning their own rewrite: don't treat the rewrite as a literal transliteration. Use it as a checkpoint to fix things you'd accumulated debt around.

State management: BLoC events/states → ViewModel + StateFlow

This is the part of the migration that touches the most files, because it's the core interaction pattern for every single screen.

Flutter's BLoC pattern is explicitly an event-sourcing-flavored state machine: you define a sealed Event type, a sealed State type, and a Bloc that maps one to the other.

@freezed
sealed class HomeEvent with _$HomeEvent {
  const factory HomeEvent.fetchData() = FetchData;
  const factory HomeEvent.appUpdates() = CheckAppUpdates;
}

class HomeBloc extends Bloc<HomeEvent, HomeState> {
  HomeBloc() : super(const _HomeState()) {
    on<FetchData>(_onFetchData);
    on<CheckAppUpdates>(_onCheckAppUpdates);
  }

  final _dbRepo = getIt<DatabaseRepository>();

  void _onFetchData(FetchData event, Emitter<HomeState> emit) async {
    emit(const HomeProgressState());
    final idioms = await _dbRepo.fetchIdioms();
    final proverbs = await _dbRepo.fetchProverbs();
    final sayings = await _dbRepo.fetchSayings();
    final words = await _dbRepo.fetchWords();
    emit(HomeFetchedDataState(idioms, proverbs, sayings, words));
  }
}

The widget dispatches events (context.read<HomeBloc>().add(const HomeEvent.fetchData())) and rebuilds via BlocBuilder listening for new states. It's explicit, testable, and the freezed union types give you exhaustive switch matching — but every single screen needs its own Event file, State file, and Bloc file (three files minimum, often four with the generated .freezed.dart), and the indirection between "user did X" → "event fired" → "handler ran" → "new state emitted" → "widget rebuilt" is a lot of hops for what's often a direct cause-and-effect.

The Kotlin/Compose version collapses that into a ViewModel exposing StateFlow directly, no separate event type required for simple cases:

@HiltViewModel
class HomeViewModel @Inject constructor(
    private val idiomRepo: IdiomRepo,
    private val proverbRepo: ProverbRepo,
    private val sayingRepo: SayingRepo,
    private val wordRepo: WordRepo,
    private val prefsRepo: PrefsRepo,
) : ViewModel() {
    private val _uiState: MutableStateFlow<UiState> = MutableStateFlow(UiState.Loading)
    val uiState: StateFlow<UiState> = _uiState.asStateFlow()

    private val _allWords = MutableStateFlow<List<Word>>(emptyList())
    private val _filteredWords = MutableStateFlow<List<Word>>(emptyList())
    val filteredWords: StateFlow<List<Word>> get() = _filteredWords

    fun fetchData() {
        _uiState.tryEmit(UiState.Loading)
        viewModelScope.launch {
            _allWords.value = wordRepo.fetchLocalData()
            _filteredWords.value = _allWords.value
            // ...idioms, proverbs, sayings follow the same shape
            _uiState.tryEmit(UiState.Filtered)
        }
    }

    fun filterData(tab: HomeTab, qry: String) {
        val query = qry.lowercase()
        when (tab) {
            HomeTab.Words -> _filteredWords.value =
                _allWords.value.filter { it.title?.startsWith(query) == true }
            // ...
        }
    }
}

And UiState is just a plain sealed class — no annotation processor required:

sealed class UiState {
    object Idle : UiState()
    object Loading : UiState()
    object Loaded : UiState()
    object Filtered : UiState()
    class Error(val message: String) : UiState()
}

The Compose screen calls viewModel.fetchData() directly (a method call, not an event dispatch) and observes uiState.collectAsState(). There's no Emitter, no separate Event sealed class to maintain in lockstep with the State one, and Kotlin's when over a sealed class gives you the same compiler-enforced exhaustiveness freezed's pattern matching gives Dart — just without a code generation step.

Trade-off to be honest about: BLoC's event/state separation genuinely shines in larger apps with complex cross-cutting concerns (undo/redo, event replay, time-travel debugging, multiple producers feeding one consumer). For a CRUD-shaped dictionary app like SwahiLib, that separation was overhead I was paying for without using. If your app's domain logic is actually event-sourced in nature, don't read this section as "ViewModel is strictly simpler" — it's simpler for this shape of app.

Navigation: imperative Navigator → Compose NavHost

Flutter's navigation here uses the classic imperative Navigator with named routes and a manual route table:

static Route? onGenerateRoute(RouteSettings settings) {
  final Map<String, WidgetBuilder> routes = {
    RouteNames.splash: (context) => const SplashScreen(),
    RouteNames.dataInit: (context) => const DataInitScreen(),
    RouteNames.home: (context) => const HomeScreen(),
    RouteNames.settings: (context) => const SettingsScreen(),
  };
  // ...
}

Compose Navigation is declarative and, importantly, ties each route directly to its hiltViewModel() instance and typed arguments:

@Composable
fun AppNavHost(navController: NavHostController = rememberNavController(), themeRepo: ThemeRepository) {
    NavHost(navController = navController, startDestination = Routes.SPLASH) {
        composable(Routes.SPLASH) {
            val viewModel: SplashViewModel = hiltViewModel()
            SplashScreen(navController = navController, viewModel = viewModel)
        }
        composable(route = Routes.WORD) {
            val word = navController.previousBackStackEntry
                ?.savedStateHandle?.get<Word>("word")
            val viewModel: WordViewModel = hiltViewModel()
            WordScreen(navController = navController, viewModel = viewModel, word = word)
        }
        // ...
    }
}

Two things changed in practice: passing a full Word object between screens now goes through SavedStateHandle (hence @Parcelize on every entity, mentioned earlier), and every screen gets its ViewModel scoped automatically to its NavBackStackEntry via hiltViewModel() — no manual BlocProvider wrapping needed at each route like the Flutter RepositoryProvider/BlocProvider widgets required.

Theming: ThemeData → Material 3 ColorScheme

Both apps are light/dark themeable, but the Kotlin rewrite moved onto full Material 3 semantic tokens (primaryContainer, surfaceVariant, outlineVariant, etc.) rather than Flutter's older-style ColorScheme with fewer slots:

static ThemeData lightTheme() {
  return ThemeData(
    scaffoldBackgroundColor: ThemeColors.accent1,
    colorScheme: const ColorScheme(
      brightness: Brightness.light,
      primary: ThemeColors.primary,
      secondary: ThemeColors.primary1,
      surface: Colors.white,
      // fewer semantic slots
    ),
  );
}

private val LightTheme = lightColorScheme(
    primary = LightColors.primary,
    primaryContainer = LightColors.primaryContainer,
    secondary = LightColors.secondary,
    secondaryContainer = LightColors.secondaryContainer,
    tertiary = LightColors.tertiary,
    surfaceVariant = LightColors.surfaceVariant,
    outlineVariant = LightColors.outlineVariant,
    inverseSurface = LightColors.inverseSurface,
    // ...full Material 3 token set
)

This isn't strictly a Flutter-vs-Kotlin limitation — flutter_bloc's ThemeData can express the full Material 3 token set too. It's more that rebuilding the theme from scratch was a natural moment to adopt the fuller token system properly rather than carry forward a partial one.

What I actually gained going native

• No bridge, no engine. Flutter renders through its own Skia/Impeller engine sitting on top of a platform view — gorgeous for consistency across iOS/Android, but it means every "drop down to platform" moment (deep notification customization, certain WorkManager edge cases, specific widget/launcher integrations) goes through a MethodChannel. In native Kotlin, there's no channel to cross. Room, WorkManager, Compose — all the same process, same language, same stack trace.

• Faster runtime, smaller footprint. No bundled Flutter engine binary, no Skia/Impeller runtime shipped inside the APK. The app is leaner and cold-start is noticeably snappier.

• Debugging is one language stack, not two. Flutter's stack traces routinely span Dart and, when something breaks at the platform boundary, Kotlin/Java/ObjC underneath. Native Android crashes are Kotlin top to bottom (with Java interop, but no cross-VM bridge).

• First-class access to new platform APIs on day one. Compose's Material 3 components, Predictive Back, the new edge-to-edge APIs — I'm not waiting on a Flutter plugin maintainer to wrap them.

The honest trade-off nobody warns you about: build times

Here's the promise I made you in the title, and I'm not going to bury it.

After several months of writing Kotlin full-time on this project, the app runs faster — but building it is not faster than Flutter was. Flutter's hot reload, for all its engine overhead at runtime, gives you sub-second iteration on UI changes. Kotlin with KSP processing Room and Hilt annotations, plus Compose's own compiler plugin doing work on every recomposition-touching change, means a meaningfully slower edit-compile-deploy loop, especially on a clean or non-incremental build.

This isn't a "Kotlin the language is slow" problem — it's a single-module Gradle build problem. Right now this entire app lives in one :app module, which means Gradle has no way to parallelize compilation across independent units of code, and KSP has to reprocess the whole annotation graph more often than it should. The fix for this is well-established in the native Android world: splitting the codebase into Gradle modules (:core, :data, :domain, :presentation, feature modules) so Gradle's build cache and parallel task execution actually have something to work with.

I was already feeling the cost of not having done this from day one, and it became the next piece of work on this app. So — I'll be back with a follow-up article specifically on modularizing this Android codebase the proper way, and what it actually does to build times once :app stops being a single monolithic compilation unit. If you're rewriting your own Flutter app to native and want to skip the pain I'm about to go fix, that's the one to watch for.

If you're planning this migration yourself

A short, opinionated checklist based on what actually mattered here:

1. Start from dependencies, not screens. Map your Flutter package list to its native equivalent first (Floor→Room, get_it+injectable→Hilt, flutter_bloc→ViewModel+StateFlow). It tells you the shape of the rewrite before you write a line of UI.

2. Don't transliterate BLoC into ViewModel 1:1. If your states don't need event-sourcing semantics, you're carrying unnecessary indirection forward. Let the new architecture simplify what it can.

3. Use the parallelism the new concurrency model gives you for free. async {} + awaitAll() in coroutines is a much shorter path to "do these in parallel" than most BLoC-shaped code naturally falls into.

4. Plan your module structure before you have 80+ files in one :app module. I didn't, and I'm paying for it in build times right now. Don't repeat that mistake — or if you do, budget time to fix it early rather than late.

5. Treat the rewrite as a checkpoint, not a port. This is your one good opportunity to fix accumulated debt — theming systems, half-finished token sets, repository patterns you were never happy with. I took it for the Material 3 token migration and the parallel sync fetch; you'll find your own equivalents.

That's the architecture side of the story. Next up: modularizing this thing properly and finding out how much of that build-time pain Gradle modules actually buy back.

SwahiLib-Flutter Github Repo

SwahiLib-Android Github Repo

Android App on Google PlayStore

SwahiLib is a Swahili-English dictionary app for Android, built under the Futuristic Ke brand by me. If you're going through a similar Flutter-to-native migration and want to compare notes, find me in the comments.

Flutter keeps evolving, and this latest release is all about helping you build faster, smarter, and with more polish than ever before. With over 1100 commits from 168 contributors (including 39 first-timers!), Flutter 3.35 is another huge step forward for the framework and the community behind it.

This update is packed with features that make your day-to-day development smoother — from stateful hot reload on the web now being stable by default, to the experimental launch of Widget Previews, giving you a whole new way to design, test, and iterate on your widgets. On top of that, the team has shipped important accessibility upgrades, refined core widgets, boosted engine performance, and expanded IDE support to bring a more seamless experience across platforms.

In short, Flutter 3.35 is built to supercharge your productivity while raising the bar on quality and accessibility. Whether you’re coding your first app or scaling a product across platforms, this release has something for you. Let’s dive in and see what’s new!

Web

⚡ Hot Reload on the Web — Now Default!

One of Flutter’s most-loved features has officially leveled up: stateful hot reload is now stable and enabled by default on the web. No more flags, no extra steps — just build, save, and watch your changes come to life instantly in the browser.

This milestone was made possible thanks to the incredible feedback from the community during the experimental phase. The Dart and Flutter web teams took that input, ironed out performance issues, and expanded the range of code changes that can be hot reloaded successfully.

The vision? A seamless hot reload experience across every platform, so whether you’re building for mobile, desktop, or web, you enjoy the same snappy workflow. While you can still turn it off with --no-web-experimental-hot-reload, the plan is to eventually make it a permanent default.

🧪 Wasm Dry Runs

Another big step forward is preparation for WebAssembly (Wasm) as Flutter’s default web build target. Starting in 3.35, every JavaScript build now includes a “dry run” compilation to Wasm.

What does that mean? Flutter checks if your app is Wasm-ready and reports any warnings straight to the console. Think of it as a friendly heads-up before the full switch happens. You can control this behavior with the --wasm-dry-run or --no-wasm-dry-run flags.

🎉 So What Changed?

Before: You had to manually enable web hot reload with the experimental flag.
Now: Just run your app in dev mode (from the command line, IDE, or coding agent) and hot reload is ready out of the box.

The --web-experimental-hot-reload flag is now history — feel free to remove it from your configs.

By the way since every developer’s environment is unique, you can temporarily disable it using --no-web-experimental-hot-reload, if hot reload causes hiccups in your setup.

Desktop

🪟 Multi-Window Support Takes Shape

Good news to those developers building desktop experiences with Flutter like myself and 99 others: multi-window support is officially on the horizon thanks to Canonical! 🎉

This release includes the foundational engine logic needed to create and update multiple windows on Windows and macOS.

What does this mean for you? It’s the first big step toward letting your Flutter apps open more than one window at a time — think productivity tools, editors, or any app where extra screens boost the user experience.

And this is just the beginning:

• Future updates will extend support to Linux, completing the desktop trifecta.

• Experimental APIs are coming soon, so you can start playing around with multi-window functionality directly from your app code.

Android

Sensitive Content Protection

Flutter on Android now supports protecting sensitive user content during media projection. With API 35+, you can use the new SensitiveContent widget to automatically obscure your app’s screen during screen shares — helping safeguard private data from exposure or theft.

See the Protect sensitive content guide for setup instructions.

iOS

iOS 26 + Xcode 26 Beta Compatibility

The Flutter team is actively preparing Flutter for iOS 26 and Xcode 26 beta. You can help accelerate this effort by testing your apps and plugins against the latest betas and filing any issues you encounter.

To follow our progress (including a running list of known issues), check out the dedicated GitHub project.

Engine Updates

Flutter 3.35 brings a series of performance and compatibility improvements across Impeller, iOS, Android, and desktop platforms.

🔧 General Engine

• Optimization: Faster app startup thanks to initialization on a new thread.

• iOS: Adoption of UISceneDelegate for better integration with iOS app lifecycles.

• Tooling: Additional improvements to support debugging and profiling.

🎨 Impeller

• Optimization: MSAA has been removed from intermediate targets for efficiency.

• Fidelity: Lossy texture has been disabled compression by default.

• Fix: Resolved a stuck MaskFilter bug in certain draw calls.

• Optimization: Path rendering performance has been improved.

• New: Support for Vivante GPUs has been added.

• Optimization: DrawImageNine now uses faster Porter-Duff blends.

• Fix: Patched memory leak in VideoPlayer.

• Fidelity: Enhanced blur radius calculation for smoother large-sigma blurs.

🍏 iOS

• Fix: Crash resolved in WebView when wrapped with ClipRSuperellipse.

• Fix: Image decoding now works when apps launch from background notifications.

• Revival: Live Text (OCR) support returns to text fields.

🤖 Android

• Migration: Default template upgraded to Android 24.

• Fix: Crash fix for Android ≤ 14 caused by background image readers.

• Fix: Corrected uniform array handling in OpenGLES Impeller shaders.

• Fix: Upside-down fragment shader passes in OpenGLES Impeller.

• Fix: Crash fix in FlutterEngineGroup.

💻 macOS

• Fix: Corrected Display P3 color rendering for higher visual fidelity.

DevTools and IDEs

Dart & Flutter MCP Server graduates to stable 🎉

The Flutter team just announced that the Dart and Flutter MCP Server is now available in the stable channel of the Dart SDK! 🎊 This is a huge step forward in the vision of building a highly productive, AI-assisted development experience for every Dart as well as a Flutter developer.

AI with context — not just autocomplete

The Dart and Flutter MCP Server acts as a bridge between your project and AI coding assistants, giving them far richer context than ever before. Instead of just suggesting snippets, your AI assistant can now understand your project structure, dependencies, and widget tree — and even take meaningful actions on your behalf.

With the MCP Server, you can ask your AI assistant to:

• 🛠️ Fix runtime errors: Inspect the live widget tree, spot a RenderFlex overflow, and apply the right fix automatically.

• 📦 Manage dependencies: Find the best package on pub.dev, add it to pubspec.yaml, and run pub get — all in one step.

• ✍️ Write and correct code: Generate boilerplate for a new feature, then self-correct any analysis errors it introduces.

Works with your favorite AI tools 🤝

You can connect the MCP Server to tools like Gemini Code Assist, Firebase Studio, Gemini CLI, GitHub Copilot, and Cursor — unlocking a new level of productivity with the editor you already love.

👉 To dive deeper, you can check out the guide here: Supercharge Your Dart & Flutter Development Experience with the Dart and Flutter MCP Server.

DevTools keeps getting better 🛠️

The Flutter team has continued polishing DevTools with UX improvements, performance boosts, and bug fixes across versions 2.46.0, 2.47.0, and 2.48.0. Full details are in the release notes.

Widget Previews

One of the most requested features from the community is finally here — Widget Previews (experimental) are now available in stable!

Hot reload is still a developer’s best friend when iterating quickly, but Widget Previews take it a step further:

• 🖼️ Preview widgets in isolation, separate from a full app.

• 🎨 Test components across different screen sizes, themes, and text scales — side by side.

• ⚡ Perfect for building out design systems or verifying complex UI variations quickly.

This is an early experimental release, and your feedback will directly shape its future. The Flutter team is already planning:

• ✨ Tighter IDE integration — embed previews directly inside VS Code, Android Studio, and IntelliJ.

• 🎨 Generic theming support — as the team decouples Material and Cupertino libraries, Widget Previews will adapt to any design system.

👉 Try it now: Getting Started with Flutter Widget Previewer (Experimental)

Faster analysis with AOT snapshot ⚡

The dart command-line tool now uses the AOT-compiled analysis server snapshot for commands like dart analyze, dart fix, and dart language-server.

What this means for you:

• ✅ No functional change — but a big performance win.

• 📈 In tests, short commands finish in a fraction of the time.

• ⏩ Long-running tasks like project analysis are nearly 50% faster.

This makes everyday workflows — including CI test runs — feel much snappier.

Flutter plugin for JetBrains IDEs expands 🌍

With the release of Flutter IntelliJ Plugin M87, you now get:

• ✅ Support for Android Studio Meerkat and Narwhal

• ✅ Installation on CLion, GoLand, PyCharm, and more JetBrains IDEs 🎉

👉 To update: Settings > Plugins > Flutter > Update

Framework

🌍 A More Inclusive and Accessible Flutter

Accessibility isn’t an afterthought in Flutter — it’s a core principle. With every release, the Flutter team is making sure Flutter apps feel welcoming, usable, and delightful for everyone. Flutter 3.35 brings a big set of accessibility upgrades, new tools for developers, and refinements across platforms and core widgets. Let’s dive in.

1. Richer Semantics on the Web

   Flutter web apps now communicate more effectively with screen readers and assistive tools. For international users, we’ve added support for semantics locales, ensuring accessibility features respect the user’s preferred language.

2. New Tools for Accessible Widgets

   Developers now have more control when building accessible experiences:

   • SemanticsLabelBuilder: Combine multiple data points into a single, coherent announcement for screen readers without messy string concatenation.

   • SliverEnsureSemantics: Wrap slivers so they’re always represented in the semantics tree — even when scrolled out of view. Perfect for complex scrollable views.

3. Core Widget & Platform Polish

   Accessibility fixes and improvements across iOS, Android, and Flutter’s core widgets:

   iOS:

   • CupertinoSliverNavigationBar now respects accessible text scaling.

   • VoiceOver tab activation behaves correctly.

Android:

• TalkBack now works with platform views, fixing a key issue for apps embedding native components.

Framework-wide:

• CustomPainter semantics properties are now backfilled, making custom-drawn UI fully accessible.

• The text selection toolbar is properly aligned in right-to-left (RTL) languages, improving global support.

🎨 Material & Cupertino now have More Power and More Polish

The design libraries also got a major round of improvements — from brand new components to smoother, higher-fidelity interactions. These upgrades don’t just make your apps look and feel better; they also simplify your workflow.

In fact, many community packages that developers previously relied on to fill gaps in the design system are now redundant, as the core Flutter libraries provide these capabilities out of the box. Less dependency management, more time to focus on building your app.

1. New & Enhanced Components

   • DropdownMenuFormField: Easily integrate Material 3 dropdown menus into forms.

   • Scrollable NavigationRail: Perfect for apps with many destinations.

   • NavigationDrawer header & footer: Adds layout flexibility.

   • CupertinoExpansionTile: Expandable and collapsible list items with Cupertino styling.

2. Higher Fidelity & Interactivity

   • Cupertino widgets now use the RSuperellipse shape for the signature iOS continuous-corner look.

   • Added haptic feedback to CupertinoPicker and CupertinoSlider.

   • Sliders can now be configured to always show the value indicator.

⚙️ More from the Framework

1. More Powerful Slivers

   • Developers can now control the paint order (z-order) of slivers, unlocking advanced effects like overlapping sticky headers.

2. Navigation & Forms

   • Fullscreen dialogs: The fullscreenDialog property is now supported in ModalRoute and showDialog.

   • Form reset callbacks: FormField now includes onReset, making form clearing logic easier.

3. Text Input & Selection Refinements

   • Unified gesture system: PositionedGestureDetails standardizes gesture details, making pointer-based gesture handling more generic.

   • iOS: Single-line text fields are no longer scrollable, aligning with native behavior.

   • Android: Added support for Home and End keys.

🔮 Looking Ahead: Decoupling Design Libraries

As Flutter grows, the Material and Cupertino libraries are moving toward becoming standalone packages. This means:

• Faster innovation: Updates won’t be tied to Flutter’s quarterly release cycle.

• Community-driven contributions: More flexibility for the community to shape the design libraries.

• Stronger core: The Flutter framework itself becomes leaner, more stable, and more focused.

For now, nothing changes in your workflow. This is the start of a long-term project, done in the open with community input.

• To read the detailed vision and rationale, see: Decoupling Design in Flutter.

• To provide feedback and help coordinate the work, please join the discussion on GitHub.

In the next article I will address the Breaking changes and deprecations.

Introduction

Migrating your Flutter app to native Android (Kotlin + Jetpack Compose) and iOS (Swift + SwiftUI) while using Supabase requires:

1. Dependency Setup

• Flutter: Use supabase_flutter (built-in client, no manual client creation).

• Android: Add Supabase, Ktor, Room, and Hilt dependencies in build.gradle.kts.

• iOS: Add supabase-swift and Swinject via Swift Package Manager.

1. Access Credentials

• Flutter:

  • Use --dart-define (secure, CI-friendly) or .env (dev-friendly) to inject SUPABASE_URL and SUPABASE_ANON_KEY.

• Android:

  • Store credentials in local.properties and expose via BuildConfig using buildConfigField.

• iOS:

  • Store credentials securely in Secrets.plist (excluded from version control) and load at runtime.

1. Project Architecture Consistency: maintain the same layered architecture:

   • Core: DI, utils, configs.

   • Data: DTOs, models, local/remote sources.

   • Domain: Entities, repositories.

   • Presentation: Screens/views, view models (or BLoCs), reusable components.

This keeps your mental model consistent across Flutter, Android, and iOS, easing onboarding and maintenance.

1. Supabase Client Initialization

   • Flutter: Initialize in main.dart with Supabase.initialize(...) and access globally via Supabase.instance.client.

   • Android: Manually create SupabaseClient in a SupabaseModule using Hilt, and inject it where needed.

   • iOS: Manually create and manage SupabaseClient within a SupabaseService injected via Swinject.

2. Invoking Supabase in your code

   Flutter:

   final result = await Supabase.instance.client.from('fruits').select();
   

   Android:

   val result = supabase["fruits"].select().decodeList<FruitDto>()
   

   iOS:

   let results: [FruitDTO] = try await supabase.client.from("fruits").select().execute().value
   

3. Data Mapping (DTO → Entity)

• Flutter: No explicit mapping needed, use Fruit.fromJson(item) directly.

• Android: Use mappers to convert FruitDto (network layer) to Fruit (domain layer) for type safety and clean separation.

• iOS: Use mappers to convert FruitDTO to Fruit, handling optionals and ensuring SwiftUI views get clean, non-optional data.

Key Benefits of This Approach:

• Consistency: Maintain the same structure across platforms, simplifying maintenance and future feature expansion.

• Testability: Clear separation of concerns with DI and explicit layers allows unit testing and easy mocking.

• Scalability: Supports future growth (adding new features or endpoints) without architectural rewrites.

• Supabase-centric simplicity: Leverage Supabase’s powerful Postgres + Auth while retaining native platform strengths.

Final Thought:

Migrating a Flutter app to native platforms with Supabase is straightforward if you:

• Plan your architecture,

• Handle credentials securely,

• Use clear dependency management,

• And maintain consistency across platforms.

This lets you fully leverage native platform capabilities while maintaining your backend could be Supabase or any other you are using, enabling you to build scalable, maintainable, and testable native apps with a clean developer experience.

Project Setup

a) Android

Start by creating a new Android project in Android Studio. Once your project is initialized, follow these steps to configure Supabase:

1. In your app/build.gradle.kts, ensure you have:

dependencies {
    // Networking - Supabase & Ktor
    implementation(platform(libs.jan.tennert.supabase.bom))     //  Supabase BOM
    implementation(libs.jan.tennert.supabase.postgrest)     //  Supabase PostgREST support
    implementation(libs.ktor.client.android)     //  Ktor HTTP client for Android
    implementation(libs.kotlinx.serialization.json)     //  Kotlin Serialization for Android  //  Compose JUnit4 test support
}

2. Now sync your project in readiness for the next setup of your project

b) iOS

Start by creating a new iOS project in Xcode using Swift + SwiftUI. Once your project is initialized, follow these steps to configure Supabase:

1. Add Dependencies via the Swift Package Manager by going to:
   File → Add Packages

1. Add Supabase by entering:

    https://github.com/supabase/supabase-swift.git
   

   and select the latest stable version.

Access Credentials

1. Go to Supabase and signup or sign in to your account.

2. After creating an account you'll be prompted to create an organization.

3. After creating an organization you'll be prompted to create a project. You can edit the project name, add a database password and change the database region closest to you and click on Create new project

4. To create the fruits table enter the following sql query the query editor and click on Run

    create table public.fruits (
      id bigint generated by default as identity not null,
      title text null,
      description character varying null,
      color text null,
      "createdAt" timestamp with time zone not null default now(),
      "updatedAt" timestamp with time zone null,
      constraint fruits_pkey primary key (id)
    ) TABLESPACE pg_default;
   

5. Create an RLS policy for the table so that it can be accessed in public.

6. Now that you have fully setup your supabase backend we need the api url and key to continue.

7. On the top navigation menu click on Connect

   

8. On the pop dialog that appear click on App Frameworks

   

In my flutter app I have 2 ways of accessing the access credentials.

1. Using keys.json + String.fromEnvironment.

   • Credentials are passed at build time using --dart-define flags:

flutter run --dart-define=SUPABASE_URL=https://xyz.supabase.co --dart-define=SUPABASE_ANON_KEY=abc123

• Load and access in main.dart:

const supabaseUrl = String.fromEnvironment("SUPABASE_URL");
const supabaseAnonKey = String.fromEnvironment("SUPABASE_ANON_KEY");
await Supabase.initialize(url: supabaseUrl, anonKey: supabaseAnonKey);

Advantages:

• Secure for different build environments (dev, staging, prod) without changing files.

• Credentials do not live in the codebase or files that could leak into version control.

• Works seamlessly with CI/CD pipelines and flavor setups.

• Tree-shakable since unused constants are removed in production builds.

Disadvantages:

• Requires manual setup of --dart-define flags or using a tool like Flutter Flavorizr for management.

• Cannot easily check or view values during development without printing them.

• If you forget to pass the flags, the values will be null or empty at runtime.

2. Using .env + flutter_dotenv package.

   • Store credentials in a .env file:

    SUPABASE_URL=https://xyz.supabase.co
    SUPABASE_ANON_KEY=abc123

• Load and access in main.dart:

    await dotenv.load(fileName: ".env");
    final supabaseUrl = dotenv.env['SUPABASE_URL'];
    final supabaseAnonKey = dotenv.env['SUPABASE_ANON_KEY'];
    await Supabase.initialize(url: supabaseUrl!, anonKey: supabaseAnonKey!);

Advantages:

• Simple and developer-friendly during local development.

• Easy to switch environments by changing the .env file or using .env.staging, .env.production, etc.

• No need to pass build flags manually during local testing.

• Easy to view and edit credentials when debugging.

Disadvantages:

• Does not work out of the box for web builds (requires workarounds).

• Credentials still live in local files, requiring careful management across environments.

• Harder to handle securely in CI/CD without additional scripts for injecting environment files.

Now away from how I access my credentials in my flutter app here is how to on Android and iOS

a) Android

1. Copy the NEXT_PUBLIC_SUPABASE_URL & NEXT_PUBLIC_SUPABASE_ANON_KEY into your local.properties file in your and as below:

    SUPABASE_URL=
    SUPABASE_ANON_KEY=
   

2. In your app/build.gradle.kts add this:

val configProperties = Properties()
val configFile = rootProject.file("gradle/config/config.properties")
if (configFile.exists()) {
    configProperties.load(configFile.inputStream())
}

and in your defaultConfig inside android add the properties

android {
    defaultConfig {
        val properties = Properties()
        properties.load(project.rootProject.file("local.properties").inputStream())
        buildConfigField("String", "SupabaseUrl", "\"${properties.getProperty("SUPABASE_URL")}\"")
        buildConfigField("String", "SupabaseKey", "\"${properties.getProperty("SUPABASE_ANON_KEY")}\"")
    }
}

b) iOS

1. Create a Secrets.plist (not checked into version control)

2. Add your access credentials as below

    <?xml version="1.0" encoding="UTF-8"?>
    <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
    <plist version="1.0">
    <dict>
        <key>SUPABASE_URL</key>
        <string></string>
        <key>SUPABASE_ANON_KEY</key>
        <string></string>
    </dict>
    </plist>
   

3. Load these values into your app at runtime using:

   
    struct SupabaseSecrets {
        static let url: String = {
            guard let path = Bundle.main.path(forResource: "Secrets", ofType: "plist"),
                  let dict = NSDictionary(contentsOfFile: path),
                  let value = dict["SUPABASE_URL"] as? String else {
                fatalError("Missing SUPABASE_URL in Secrets.plist")
            }
            return value
        }()
   
        static let anonKey: String = {
            guard let path = Bundle.main.path(forResource: "Secrets", ofType: "plist"),
                  let dict = NSDictionary(contentsOfFile: path),
                  let value = dict["SUPABASE_ANON_KEY"] as? String else {
                fatalError("Missing SUPABASE_ANON_KEY in Secrets.plist")
            }
            return value
        }()
    }
   

   Using the Supabase Client

In Flutter, the Supabase client comes built into the official supabase_flutter package, so you don’t need to create the client manually. Instead, you initialize it directly in the main.dart as I had already shared earlier:

await Supabase.initialize(url: supabaseUrl, anonKey: supabaseAnonKey);

Once initialized, you can access the client globally via:

final supabase = Supabase.instance.client;

However in android and ios you need to create a client manually as follows:

a) Android (Kotlin)

On Android, using the Kotlin Supabase SDK, you manually create and provide the SupabaseClient using dependency injection (Hilt or Koin).

@Module
@InstallIn(SingletonComponent::class)
object SupabaseModule {

    @Provides
    @Singleton
    fun provideSupabaseClient(): SupabaseClient {
        return createSupabaseClient(
            supabaseUrl = BuildConfig.SupabaseUrl,
            supabaseKey = BuildConfig.SupabaseKey
        ) {
            install(Postgrest)
        }
    }

    @Provides
    @Singleton
    fun provideSupabaseDatabase(client: SupabaseClient): Postgrest {
        return client.postgrest
    }
}

b) iOS (Swift)

On iOS, you create the SupabaseClient explicitly and manage its lifecycle within a service class:

final class SupabaseService: SupabaseServiceProtocol {
    let client: SupabaseClient

    init() {
        let urlString = SupabaseSecrets.url
        let anonKey = SupabaseSecrets.anonKey

        guard let url = URL(string: urlString), !anonKey.isEmpty else {
            fatalError("Invalid Supabase URL or anon key. Check Secrets.plist.")
        }

        self.client = SupabaseClient(
            supabaseURL: url,
            supabaseKey: anonKey
        )
    }
}

Invoking Supabase in your Repository

After setting up the Supabase client, the next step is using it to invoke your Supabase backend consistently across platforms. In Flutter, I just invoke the table directly:

final result = await Supabase.instance.client.from('fruits').select();

Wrapped in a repository:

class FruitRepository {
  final SupabaseClient supabase;

  FruitRepository(this.supabase);

  Future<List<Fruit>> fetchFruits() async {
    logger('Now fetching fruits');
    try {
      final result = await supabase.from('fruits').select();
      final fruits = (result as List)
          .map((item) => Fruit.fromJson(item))
          .toList();
      logger('${fruits.length} fruits fetched');
      return fruits;
    } catch (e) {
      logger('Unable to fetch fruits: $e');
      return [];
    }
  }
}

From this Direct, readable API call I can get a list of strongly typed Fruit objects for the UI.

a) Android (Kotlin)

Using the Supabase Kotlin SDK, I invoke my table with:

val result = supabase["fruits"].select().decodeList<FruitDto>()

Wrapped in a repository with dependency injection:

@Singleton
class FruitRepository @Inject constructor(
    private val supabase: Postgrest,
) {
    fun fetchFruits(): Flow<List<Fruit>> = flow {
        try {
            Log.d("TAG", "Now fetching fruits")
            val result = supabase["fruits"].select().decodeList<FruitDto>()
            val fruits = result.map { MapDtoToEntity.mapToEntity(it) }
            Log.d("TAG", "Fetched ${fruits.size} fruits")
            emit(fruits)
        } catch (e: Exception) {
            Log.d("TAG", "Unable to fetch fruits: ${e.message}")
        }
    }
}

This request Uses Kotlin Flows for reactive streams after which it maps DTOs (Data Transfer Objects) to domain entities for clean separation.

b) iOS (Swift)

Using the Supabase Swift SDK, I invoke my table with:

let results: [FruitDTO] = try await supabase.client.from("fruits").select().execute().value

Wrapped in a repository:

class FruitRepository: FruitRepositoryProtocol {
    private let supabase: SupabaseServiceProtocol

    init(supabase: SupabaseServiceProtocol) {
        self.supabase = supabase
    }

    func fetchFruits() async throws -> [Fruit] {
        do {
            let results: [FruitDTO] = try await supabase.client.from("fruits").select().execute().value
            let fruits = results.map { MapDtoToEntity.mapToEntity($0) }
            print("✅ Fruits fetched: \(fruits.count)")
            return fruits
        } catch {
            print("❌ Failed to fetch fruits: \(error.localizedDescription)")
            throw error
        }
    }
}

This request uses Swift's async/await for clean asynchronous code after which it maps DTOs to domain entities, maintaining clear architecture.

Mapping DTOs to Domain Entities

Migrating my Flutter apps like SwahiLib and SongLib to native Android and iOS taught me the value of clean, explicit data handling. In Flutter, dynamic fromJson decoding was enough, but on Android and iOS, explicit DTO-to-entity mapping became essential for type safety, testability, and clean architecture, especially when syncing with Supabase or Core Data. This step ensured that backend changes or differences in local storage structures would not tightly couple or break my app’s business logic and UI layers.

Using DTOs to mirror backend data and mapping them into clean domain entities makes your code safer, clearer, and easier to maintain. It allows you to add computed properties or handle nulls gracefully while keeping your presentation and business logic clean. Whether working with Kotlin’s data classes and mappers or Swift’s Codable structs and transformation layers, this explicit mapping ensures your app can scale confidently while maintaining flexibility across Flutter, Android, and iOS environments.

Please take time to read more about how I did the mapping in my previous article: Flutter to Native Migration: Data Handling and Mapping

In the next article, I will talk about the highlights of this migration of Flutter to Native code

I learned the hard way that migrating my Flutter app to native platforms demands clean, explicit data handling. In Flutter, I relied on the dynamic fromJson approach, but when I migrated SwahiLib (which uses Supabase as a backend), I realized that Android and iOS required explicit DTO-to-entity mapping for type safety, testability, and maintainability.

For my other app, SongLib (which uses MongoDB with a custom backend), the Android setup worked fine with minimal mapping. However, on iOS, I still needed to map data explicitly to and from CoreDataManager whenever I wanted to sync local data, reinforcing the need for clear data handling even when using different backend services.

Why Use DTOs and Mappers?

• DTOs (Data Transfer Objects): Mirror the structure returned by the backend service e.g Supabase/Postgres.

• Domain Entities: Clean app-facing models used in your presentation/business layers.

• Mappers: Convert DTOs → Entities to isolate your app logic from backend changes.

In Flutter, the supabase_flutter SDK returns data as Map<String, dynamic>, which you can directly pass into your model's fromJson constructor:

Fruit.fromJson(item);

No explicit mapping layer is needed since Dart’s dynamic typing and JSON decoding handle shape alignment directly.

However, in Android (Kotlin) and iOS (Swift), it is best practice to separate the raw DTOs fetched from Supabase from your domain models. This separation ensures:

• Type safety across layers.

• Clean handling if the Supabase schema changes (without breaking your app immediately).

• Flexibility to add computed properties or transformations in your domain models without affecting your DTOs.

a) Android (Kotlin)

FruitDTO: represents exactly what Supabase returns:

@Serializable
data class FruitDto(
    val id: Int = 0,
    val title: String? = null,
    val description: String? = null,
    val color: String? = null,
    val createdAt: String? = null,
    val updatedAt: String? = null,
)

Fruit (Model): Your clean, app-facing entity:

@Keep
data class Fruit(
    val id: String? = null,
    val title: String? = null,
    val description: String? = null,
    val color: String? = null,
    val createdAt: String? = null,
    val updatedAt: String? = null,
)

MapDtoToEntity (Mapper): helps to map the DTO to your domain model to keep your presentation layer and business logic decoupled from backend structure:

MapDtoToEntity {
    fun mapToEntity(entity: FruitDto): Fruit {
        return Fruit(
            id = entity.id,
            title = entity.title,
            description = entity.description,
            color = entity.color,
            createdAt = entity.createdAt,
            updatedAt = entity.updatedAt,
        )
    }
}

• Ensures consistent types (Int id in DTO mapped to String id in domain if needed).

• Allows DTO to evolve without tightly coupling your app logic.

b) iOS (Swift)

FruitDTO: Matches the structure returned by Supabase:

struct FruitDTO: Codable {
    let id: String?
    let title: String?
    let description: String?
    let color: String?
    let createdAt: String?
    let updatedAt: String?
}

Fruit Model: Used in your SwiftUI views and logic

struct Fruit: Identifiable, Codable {
    let id: Int
    let title: String
    let description: String
    let color: String
    let createdAt: String
    let updatedAt: String
}

MapDtoToEntity Mapper: You map from FruitDTO to Fruit, handling defaults and type transformations:

struct MapDtoToEntity {
    static func mapToEntity(_ dto: FruitDTO) -> Fruit {
        Fruit(
            id: Int(dto.id ?? "0") ?? "",
            title: dto.title ?? "",
            description: dto.description ?? "",
            color: dto.color ?? "",
            createdAt: dto.createdAt ?? "",
            updatedAt: dto.updatedAt ?? ""
        )
    }
}

✅ Allows you to handle missing or optional fields gracefully.
✅ Keeps SwiftUI clean by providing non-optional properties for use in views.

Benefits of Explicit Mapping:

• Decouples my app’s structure from the backend schema.

• Handles optional/null safely.

• Enables computed properties and transformation logic.

• Makes your codebase scalable and testable.

In the next article, I will cover Supabase setup and implementation across Android, and iOS while comparing it against my Flutter setup, including credential handling, client initialization, and practical fetching examples.

Migrating a Flutter app to native Android (Kotlin + Jetpack Compose) and iOS (Swift + SwiftUI) with MongoDB with custom backend as the backend can unlock native capabilities while retaining your scalable backend. Planning your architecture and project setup properly ensures a smooth transition.

Project Setup

a) Android

Start by creating a new Android project in Android Studio. Once your project is initialized, follow these steps to configure dependancies:

1. In your root/build.gradle.kts, ensure you have:

plugins {
    alias(libs.plugins.android.application) apply false     // Android application plugin
    alias(libs.plugins.kotlin.android) apply false      // Kotlin support for Android
    alias(libs.plugins.kotlin.compose) apply false      // Jetpack Compose compiler plugin
    alias(libs.plugins.dagger.hilt) apply false     // Hilt for dependency injection
    alias(libs.plugins.devtools.ksp) apply false     // Kotlin Symbol Processing (used by Room and Hilt packages)
}

2. In your app/build.gradle.kts, ensure you have:

plugins {
    alias(libs.plugins.android.application)
    alias(libs.plugins.kotlin.android)
    alias(libs.plugins.kotlin.compose)
    alias(libs.plugins.dagger.hilt)
    alias(libs.plugins.devtools.ksp)
    kotlin("plugin.serialization") version "2.1.21"
}

at the top and in the depencies you may want to organize them this way

dependencies {
    // Core AndroidX & Lifecycle
    implementation(libs.androidx.core.ktx)      // Kotlin extensions for core Android APIs
    implementation(libs.androidx.lifecycle.runtime.ktx)      // Lifecycle-aware components
    implementation(libs.androidx.core.splashscreen)      // Splash screen API

    // Jetpack Compose - BOM
    implementation(platform(libs.androidx.compose.bom))      // Compose Bill of Materials (BOM)

    // Jetpack Compose - Core UI
    implementation(libs.androidx.activity.compose)      // Activity support for Compose
    implementation(libs.androidx.ui)      // Core Compose UI elements
    implementation(libs.androidx.ui.graphics)      // Compose graphics primitives

    // Jetpack Compose - Material Design
    implementation(libs.androidx.material3)      // Material 3 UI components
    implementation(libs.androidx.compose.material)      // Material 2 components (legacy support)
    implementation(libs.androidx.icons.extended)      // Extended material icons

    // Jetpack Compose - Navigation & State
    implementation(libs.compose.navigation)      // Navigation support in Compose
    implementation(libs.compose.hilt.navigation)      // Hilt + Navigation integration
    implementation(libs.androidx.compose.livedata)      // LiveData support in Compose

    // Jetpack Compose - Tooling & Preview
    implementation(libs.androidx.ui.tooling.preview)      // Compose UI preview support
    debugImplementation(libs.androidx.ui.tooling)      // Compose UI tools (debug only)
    debugImplementation(libs.androidx.ui.test.manifest)      // Manifest for Compose UI tests (debug)

    // Navigation (Non-Compose)
    implementation(libs.androidx.navigation)      // AndroidX Navigation components

    // Room Database
    implementation(libs.androidx.room.runtime)      // Room runtime
    ksp(libs.androidx.room.compiler)      // Room annotation processor (KSP)
    annotationProcessor(libs.androidx.room.compiler)      // Annotation processor (for fallback/tests)

    // Hilt for Dependency Injection
    implementation(libs.hilt.android)      // Hilt core
    ksp(libs.hilt.compiler)      // Hilt code generation
    kspAndroidTest(libs.hilt.android.compiler)      // Hilt codegen for instrumentation tests

    // Networking (Retrofit + OkHttp)
    implementation(libs.squareup.retrofit)      // Retrofit for networking
    implementation(libs.squareup.retrofit.gson)      // Gson converter for Retrofit
    implementation(libs.squareup.okhttp3.logging)      // OkHttp logging interceptor

    // Testing - Unit Tests
    testImplementation(libs.junit)      // JUnit for unit testing

    // Testing - Android Instrumentation Tests
    androidTestImplementation(libs.androidx.junit)      // AndroidX JUnit extensions
    androidTestImplementation(libs.androidx.espresso.core)      // Espresso UI test framework
    androidTestImplementation(platform(libs.androidx.compose.bom))      // Compose BOM for tests
    androidTestImplementation(libs.androidx.ui.test.junit4)      // Compose JUnit4 test support
}

3. Now sync your project in readiness for the next setup of your project

b) iOS

Start by creating a new iOS project in Xcode using Swift + SwiftUI. Once your project is initialized, follow these steps to configure dependencies:

1. Add Dependencies via the Swift Package Manager by going to:
   File → Add Packages

   

2. Add Swinject by entering:

    https://github.com/Swinject/Swinject.git
   

   and select the latest stable version. All other packages are added that way.

Project Architecture

After setting up dependencies and basic wiring, it is important to have a clean architecture that can scale and remain testable across Android, and iOS.

I worked maintaining similar layering that was already using in Flutter:

Maintaining similar layering across Android and iOS

• Core – Dependency injection, constants, environment configurations, helpers, utilities.

• Data – Data models, data sources (local and remote), mappers, DTOs.

• Domain – Entities, repositories (interfaces and implementations).

• Presentation – Screens/views, view models/BLoCs, UI components, themes.

This was my flutter setup

lib
├── core
│   ├── di
│       ├── injectible.dart
│   ├── utils
├── data
│   ├── models
│       ├── song.dart
│   ├── sources
│       ├── local
│           ├── daos (Domain Access Objects)
│           ├── app_database.dart
│       ├── remote
├── domain
│   ├── repository
│       ├── song_repository.dart
├── presentation
│   ├── blocs
│       ├── selection
│       ├── home
│   ├── screens
│       ├── selection
│       ├── home
│   ├── widgets
├── app.dart (boostrapper)
└── main.dart (app launcher/initializer)

• Uses BLoC for state management.

• Local data (Floor) and remote data (backend client).

• Dependency injection via Injectable and GetIt.

• Keeps UI logic in screens, while reusable pieces of code in widgets.

• Environment and constants in core/utils/env.

a) Android (Kotlin, Jetpack Compose)

app
├── core
│   ├── di
│   ├── ├── AppModule.kt
│   ├── ├── NetworkModule.kt
│   ├── utils
├── data
│   ├── models
│       ├── Song.kt
│   ├── samples
│   ├── sources
│       ├── local
│           ├── AppDaos.kt (Data Access Objects)
│           ├── AppDatabase.kt
│       ├── remote
│           ├── ApiService.kt
├── domain
│   ├── entity
│       ├── UiState.kt
│   ├── repository
│       ├── SongRepository.kt
├── presentation
│   ├── components
│   ├── screens
│       ├── selection
│       ├── home
│   ├── theme
│   ├── viewmodels
│       ├── SelectionViewModel.kt
│       ├── HomeViewModel.kt
├── MainActivity.kt
└── SongLibApp.kt

• Uses ViewModel + StateFlow for state management.

• Dependency Injection via Koin/Hilt.

• Room for local caching, Retrofit for remote.

• UI uses Jetpack Compose with components for reusable UI blocks.

b) iOS (SwiftUI)

MyNewApp
├── Core
│   ├── Di
│       ├── DependencyMap.swift
│       ├── DiContainer.swift
│   ├── Utils
├── Data
│   ├── Models
│       ├── Song.swift
│   ├── Samples
│   ├── Sources
│       ├── Local
│           ├── CoreDataManager.swift
│           ├── SongDataManager.swift
│           ├── MyNewApp.xcdatamodelId
│       ├── Remote
│           ├── ApiService.swift
│           ├── EndPoint.swift
├── Domain
│   ├── Entity
│   ├── Repository
│       ├── SongRepository.swift
├── Presentation
│   ├── Components
│   ├── Views
│       ├── Selection
│       ├── Home
│   ├── Theme
│   ├── ViewModels
│       ├── SelectionViewModel.swift
│       ├── HomeViewModel.swift
├── Assets.xcassets
├── ContentView.swift
└── SongLibApp.swift

• Uses ObservableObject + @Published or Combine for state management.

• Dependency injection via lightweight DependencyMap and DiContainer.

• Uses Core Data for local, ApiService.swift for remote.

• SwiftUI structures with Views and reusable Components.

• DTO and Core Data entity mapping handled explicitly in Mappers.

Strengths in a clean structure:

1. Consistent Layering: Core, Data, Domain, Presentation clearly separate concerns hence its easy to understand and maintain.

2. Alignment Across Platforms: The same mental model applies for Flutter (BLoC), Android (ViewModel + StateFlow), and iOS (ObservableObject/Combine). DTOs and entity mappers handled explicitly, ensuring testability and separation of network vs. app models.

3. Testability & Modularity: Dependency Injection handled cleanly (Injectable, Koin/Hilt, DependencyMap/Container). Local storage handled (Floor, Room, Core Data) while ApiService remains the source of truth.

4. UI Organization: Presentation is split into screens/views, view models/BLoCs, and reusable components/widgets, keeping screens clean.

5. Bootstrap & Entry Separation: main.dart/MyNewApp.kt/MyNewApp.swift as app launchers. app.dart/ContentView.swift as bootstrap entry, further isolating setup.

6. Mappers: You explicitly handle DTO ↔ Entity ↔ Local mappings in dedicated files across all platforms. This prevents leaky abstractions and future issues when the API or local storage changes.

7. Sample Data: The samples folder is clean for seeding/testing, consider documenting its purpose in your repo for contributors.

8. Future Expansion: Consider having a usecases subfolder inside domain if you add business logic later, but for a small iOS project.

In the next article, we will cover Data Handling and Mapping strategies, including DTOs, entities, and why mapping layers matter when migrating.

Juggling both projects taught me a lot about platform nuances, UI patterns, and managing shared logic across native ecosystems. Now, both apps are live on Google Play and the App Store! In this series of articles, I share the complete process, key insights, and what I'd approach differently to help others considering the same journey from Flutter to native development.

Introduction: Why Rewrite a Flutter App?

1. Need for a new Challenge, after the initial Flutter success

When I developed SongLib and SwahiLib back in Covid time, I chose Flutter for its powerful ability to create apps for both Android and iOS from a single Dart codebase. The framework's rapid development cycle enabled efficient creation of functional apps without the need for separate platform-specific codebases. But as a person who loves new challenges (I want problems) I started thing about going native for these two apps.

2. Mentorship-Driven Learning

As a mentor frequently helping others with mobile development, I have been regularly debugging and enhancing Android apps written in Kotlin and Java. These hands-on experiences, including reviving old Java projects and modernizing Kotlin applications, sparked curiosity about native development and revealed gaps in expertise that could limit my mentoring effectiveness.

3. Professional Skill Expansion

My decision to rewrite my Flutter apps into native code was also driven by my desire to become a more versatile developer capable of providing comprehensive guidance across Flutter, Kotlin, and Swift. By mastering native development, I am aim to strengthen hands-on mentorship abilities and remain competitive in a field where diverse technical expertise is increasingly valuable.

4. Personal Technical Challenge

When I started working with Flutter I was forced there by the steep learning curve that Objective C demanded if I was to develop iOS apps. I relied on my friends’ Macs to build my app for iOS which means to learn Objective C I would need to own a Mac so that I could spend quality time to learn. Over the years I was able to own a Mac on which now Xcode is installed and has been lying dormant except maybe when am building my app on iOS.

5. Tapping into the rich ecosystem of Android and iOS

Native development unlocks access to the full spectrum of platform-specific features and optimizations that may be limited or less efficient in cross-platform frameworks. Android's ecosystem offers advanced capabilities like highly customizable push notifications with rich media and actions, robust background processing through WorkManager and foreground services, interactive home screen and lock screen widgets, and significantly smaller app sizes due to platform-optimized compilation. iOS provides sophisticated notification systems with custom UI extensions, background app refresh capabilities, Today widgets and App Clips for lightweight functionality, and efficient app thinning that delivers only necessary resources to users' devices.

By developing natively, apps can achieve optimal performance with smaller APK/IPA sizes, implement platform-specific user experience patterns that feel natural to users, and leverage immediate access to new OS features as they're released, all while maintaining the performance benefits of platform-optimized code compilation.

Trade-offs of Moving from Flutter to Native Development

Advantages:

• Superior Performance: Direct access to platform APIs without Flutter's rendering layer, resulting in faster app startup times, smoother animations, and optimal memory management

• Significantly Smaller App Sizes: Native compilation produces smaller APK/IPA files compared to Flutter's bundled framework, with platform-specific optimizations like Android's ProGuard and iOS's app thinning

• Full Platform Feature Access: Unrestricted use of advanced capabilities like customizable push notifications, robust background processing (WorkManager/Background App Refresh), interactive widgets, and deep system integrations

• Authentic User Experience: Native implementation of platform-specific design patterns (Material Design for Android, Human Interface Guidelines for iOS) that feel natural and familiar to users

• Rich Ecosystem Access: Immediate availability of cutting-edge platform features upon OS release, extensive native libraries, and seamless integration with platform services (Google Services, Apple ecosystem)

Disadvantages:

• Doubled Development Complexity: Requires learning and maintaining expertise in multiple languages (Kotlin/Java and Swift), development environments (Android Studio and Xcode), and platform-specific concepts

• Significant Maintenance Overhead: Maintaining separate codebases doubles development time, testing requirements, and bug fixing efforts across platforms

• Increased Development Costs: Need for Mac hardware for iOS development, multiple development tools, and potentially separate development teams or extended timelines

• Platform Fragmentation Challenges: Android's diverse device ecosystem and iOS's hardware variations require extensive testing and platform-specific optimizations

• Slower Feature Delivery: Implementing features twice means longer development cycles compared to Flutter's single codebase approach, potentially delaying time-to-market for new functionality

In this article I explain why I took this path as well as the trade offs that came with it just in case there is someone looking to do this one day. I next article I will be talking about the code itself from an setup perspective.

You open the repo, clone it, and—build fails. Curious, you check the Git logs—the last meaningful commit was made about three years ago. Flutter has changed a lot since then. You’re staring at a massive codebase that still uses pre-null safety syntax, probably hardcoded dependencies, and maybe even deprecated widgets.

It’s a mammoth project. Starting from scratch isn’t an option—it’s too big, too risky, and there’s pressure to deliver fast. And of course, you did say in your interview that you're "very experienced with Flutter," right? So now your boss is expecting magic.

But before you can even think about adding new features, you’ve got one job:

Make. It. Run.

This guide walks you through exactly how to do that—without touching the code.

Step 1: Getting the Right Flutter Version

The first and most critical step is ensuring you're using the same Flutter version the project was built with. A lot changes in 3+ years—Dart syntax, APIs, dependency constraints—and the older the code, the more likely it is to break on a modern Flutter SDK.

You have two main options for setting up the correct Flutter version:

Option 1: Using FVM (Flutter Version Management) — Recommended

FVM allows you to install multiple Flutter versions and switch between them per project, without interfering with your global setup.

🔧 Installing FVM:

dart pub global activate fvm

Or, if you're on macOS with Homebrew:

brew tap leoafarias/fvm  
brew install fvm

🔍 Identify the Required Flutter Version:

• Check .metadata in the project root (look for version: 2.0.6).

• If .metadata is missing, check pubspec.lock or the oldest Git commits.

📥 Install & Use the Correct Version:

fvm install 2.0.6  # Replace with your version  
fvm use 2.0.6

🚀 Run the Project:

fvm flutter pub get  
fvm flutter run

⚙️ IDE Setup (VS Code/Android Studio):

• VS Code: Install the FVM extension and select the correct version.

• Android Studio: Configure the Flutter SDK path to point to fvm’s cached version.

Option 2: Manually Install and Use a Separate Flutter Version (No FVM)

If you prefer not to use FVM, you can manually download and switch versions.

1. Download the desired Flutter version from Flutter SDK releases.

2. Extract it to a safe location (e.g., ~/flutter_versions/flutter_2_0_6/).

3. Update your PATH:

   Temporarily (for current session):

    export PATH=~/flutter_versions/flutter_2_0_6/bin:$PATH
   

   Permanently (add to ~/.zshrc or ~/.bashrc):

    echo 'export PATH=~/flutter_versions/flutter_2_0_6/bin:$PATH' >> ~/.zshrc  
    source ~/.zshrc
   

4. Verify the version:

    flutter --version
   

5. Run the project:

    flutter pub get  
    flutter run
   

Step 2: Taming the Gradle Beast

If the project is 3–4 years old, the Android build system (Gradle) is likely ancient and will fight you. Here’s how to make it cooperate—without modifying the code.

1. Check the Existing Gradle Setup

Navigate to android/ and inspect:

• gradle-wrapper.properties → Tells you the Gradle version.

    distributionUrl=https\://services.gradle.org/distributions/gradle-6.7-all.zip
  

• build.gradle (Project-level) → Tells you the Android Gradle Plugin (AGP) version.

    classpath 'com.android.tools.build:gradle:4.1.0'
  

This means:

• Gradle 6.7

• AGP 4.1.0

2. Let Gradle Use Its Own Version (Best for Isolation)

Run from the android/ directory:

./gradlew wrapper --gradle-version 6.7  
./gradlew build

This ensures the project uses its original Gradle version, even if your system has a newer one.

3. Common Errors & Fixes

🚨 Kotlin Version Incompatibility

Error:

Kotlin version '1.3.50' is incompatible with the Kotlin Gradle plugin.

Fix:

• Check android/build.gradle for the Kotlin version.

• Install the correct version (don’t upgrade yet).

🚨 JDK Version Issues

Gradle 6.x + AGP 4.x usually require JDK 8 or 11. If you're on JDK 17+, downgrade temporarily:

export JAVA_HOME=$(/usr/libexec/java_home -v 11)  # macOS  
# OR  
export JAVA_HOME=/usr/lib/jvm/java-11-openjdk-amd64  # Linux

🚨 AndroidX Migration Issues

If the project is pre-AndroidX, run it on an emulator/device with API ≤ 28 (Android 9 or older).

Pro Tip: Avoid flutter build Initially

Start with:

flutter clean  
flutter pub get  
flutter run

Avoid flutter build apk or flutter build appbundle—they trigger stricter checks.

Step 3: Let Android Studio Do the Heavy Lifting

Even if you prefer VS Code, opening the project in Android Studio helps resolve Gradle/JDK issues automatically.

Why Android Studio?

✅ Detects & installs missing JDK versions.
✅ Helps with Android SDK components (e.g., legacy build tools).
✅ Resolves Gradle plugin compatibility issues.

What to Do in Android Studio

1. Open the android/ folder as a standalone project.

2. Let it sync—it may prompt you to install the correct JDK.

3. Fix JDK path (if needed):

   • Go to Preferences > Build, Execution, Deployment > Build Tools > Gradle.

   • Under Gradle JDK, select JDK 8 or 11.

4. Sync again—Gradle should now work.

Step 4: Handling iOS (If Applicable)

If the project includes iOS, you might face:

1. CocoaPods Version Issues

Older Flutter projects may need CocoaPods ≤ 1.10.

sudo gem install cocoapods -v 1.10.0

2. Xcode Compatibility

• Use Xcode 12-13 for older projects.

• Open ios/Runner.xcworkspace (not .xcodeproj).

• Set the iOS Deployment Target to match Podfile.

Final Checklist

✅ Flutter version matches .metadata.
✅ Gradle & AGP versions are correct.
✅ JDK is set to 8/11 (not 17+).
✅ Android Studio syncs without errors.
✅ CocoaPods version is compatible.

What If It Still Doesn’t Work?

If you’ve followed all steps and still hit errors:

1. Check pubspec.lock for exact dependency versions.

2. Run in verbose mode for detailed logs:

    flutter run -v
   

3. Ask the team if they have an old setup guide.

Conclusion

You didn’t write this code, but you can make it run. By locking the Flutter version, taming Gradle, and letting Android Studio help, you’ll resurrect the project without rewriting it.

Now go ahead—make that ancient Flutter app breathe again. 🚀

(And then, maybe, slowly start upgrading it…)

INTRODUCTION

Memory leaks occur when your app retains memory that is no longer needed, leading to performance issues, crashes, and excessive resource usage.

I know that most of us in Flutter might have been thinking that memory leaks only impact app size, but they quietly degrade performance. Beyond consuming storage, memory leaks slow down your app, cause crashes, and harm user experience. By implementing the right strategies, you can keep your Flutter apps fast, responsive, and reliable across all platforms.

Common Causes Memory Leaks in Flutter

Efficient memory management is crucial for maintaining a smooth and responsive Flutter app. By identifying common causes, applying platform-specific optimizations, and following best practices, you can prevent memory leaks and enhance app performance.

1. Unreleased Streams & Listeners 🔌

Active stream subscriptions and event listeners can persist in memory if not properly disposed of, leading to memory leaks. Always cancel stream subscriptions and remove listeners in the dispose() method of a StatefulWidget:

@override
void dispose() {
  myStreamSubscription.cancel();
  myController.dispose();
  super.dispose();
}

2. Mismanaged Async Operations ⚡

Async tasks such as HTTP requests and database queries can consume memory if not handled correctly. Use CancelToken to abort HTTP requests when no longer needed:

CancelToken cancelToken = CancelToken();

void fetchData() {
  Dio().get('https://api.example.com/data', cancelToken: cancelToken);
}

@override
void dispose() {
  cancelToken.cancel();
  super.dispose();
}

For streams, use takeWhile to automatically cancel subscriptions when the widget is disposed:

stream.takeWhile((_) => mounted).listen((data) {
  // Process data
});

3. Overuse of setState() 🔄

Calling setState() excessively can cause unnecessary widget rebuilds, leading to performance issues. Optimize state updates by:

• Updating only when necessary.

• Using const widgets to prevent unnecessary re-renders.

• Leveraging state management solutions like Provider, Riverpod, or BLoC.

4. Retaining Large Data Objects 📂

Large assets such as images, files, or cached data can lead to excessive memory usage if not properly managed:

• Release large assets when no longer needed.

• Optimize images by setting cacheWidth and cacheHeight in Image.asset or Image.file to reduce memory consumption:

Image.asset('assets/image.png', cacheWidth: 200, cacheHeight: 200);

5. Singletons & Global Variables 📌

Singletons and global variables persist throughout the app’s lifecycle, potentially leading to memory leaks. Properly manage their lifetimes by implementing disposal mechanisms:

class MySingleton {
  static final MySingleton _instance = MySingleton._internal();
  factory MySingleton() => _instance;
  MySingleton._internal();
  void dispose() {
    // Cleanup resources
  }
}

Dependency injection frameworks like get_it or riverpod can also help manage object lifetimes more effectively.

6. Web-Specific Memory Leaks 🌐

Web-based Flutter applications can suffer from memory leaks if DOM elements and event listeners are not properly removed:

• Dispose event listeners when widgets are destroyed.

• Optimize UI for web: Some mobile-specific animations may cause performance issues in browsers. Use simpler animations or conditionally disable them on web:

if (kIsWeb) {
  // Use simpler animations for web
}

7. Platform-Specific Optimizations 📱

• Efficient List Handling

  For large datasets, prefer ListView.builder over ListView to render only visible items, conserving memory:

ListView.builder(
  itemCount: items.length,
  itemBuilder: (context, index) {
    return ListTile(title: Text(items[index]));
  },
);

• Reducing Animation Complexity

  On lower-end devices or web applications, simplify complex animations to improve performance:

if (!kIsWeb && Platform.isAndroid) {
  // Apply full animations
} else {
  // Use lightweight animations for web and older devices
}

How to Detect Memory Leaks in Flutter

Identifying memory leaks in your Flutter app can be challenging, but with the right tools and techniques, it's achievable. Here’s how you can detect and fix memory leaks effectively:

1. Use Flutter DevTools

Flutter DevTools is a powerful debugging and performance monitoring tool for Dart and Flutter applications. It allows you to analyze your app’s memory usage. To access it, run:

flutter pub global run devtools

2. Capture Heap Snapshots

Taking heap snapshots at different points in time helps monitor memory usage and detect leaks. These snapshots can reveal objects that aren’t being garbage collected as expected, indicating a possible memory leak.

3. Review Your Code

Carefully analyze your code to ensure objects are properly disposed of when no longer needed. Pay special attention to controllers, as they are a common cause of memory leaks in Flutter. Always dispose of them correctly to prevent unnecessary memory retention.

By leveraging these techniques, you can keep your Flutter app efficient and free of memory leaks.

Best Practices & Tools

1. Always override dispose() in StatefulWidget to clean up controllers, streams, and listeners.

2. Use Flutter DevTools to monitor memory and detect leaks early.

3. Manage object retention: Avoid caching objects indefinitely; use weak references where applicable.

4. Optimize async execution: Properly handle async/await and ensure tasks are canceled when no longer needed.

Let’s create Flutter apps that are not just beautiful but also high-performing! 🚀💡

Performance optimization isn’t just a nice-to-have—it’s a necessity for large scale mobile apps like Airbnb that cater to millions of users across diverse devices. Slow apps frustrate users, increase uninstall rates, and harm brand reputation. Before we dive in into how we can achieve optimization for our Flutter apps we will first look at why we need the optimization to begin with.

Why Performance Optimization Matters

1. User Retention & Engagement

• Fact: 70% of users abandon apps that take more than 3 seconds to load.

• Impact: Slow apps frustrate users, leading to uninstalls. For example, Pinterest improved perceived load times by 40%, boosting user engagement by 15%.

2. Global Market Penetration

• Emerging Markets: Over 60% of smartphone users in regions like India and Africa use low-RAM devices (<4GB). A laggy app alienates this massive audience.

• Case Study: Lite apps have been built specifically for low-end devices, resulting in a 30% increase in installations in emerging markets.

3. Conversion Rates & Revenue

• E-commerce Impact: Amazon found that every 100ms delay in load time cost them 1% in sales.

• App Example: Walmart saw a 2% increase in conversions for every 1-second improvement in load time.

4. Battery Efficiency

• User Loyalty: Apps draining battery life are uninstalled 2.5x faster.

• Technical Angle: Heavy animations and background tasks force CPUs/GPUs to work harder, shortening battery life.

5. Search Engine Rankings (SEO)

• Web Apps: Google’s Core Web Vitals metrics (e.g., Largest Contentful Paint) directly affect SEO rankings. Slow Flutter web apps lose visibility.

• Data: Pages meeting Core Web Vitals thresholds have a 24% lower bounce rate.

6. Competitive Differentiation

• Stand Out: Apps like Instagram and Airbnb prioritize performance to stay ahead. A smooth app can be your unique selling point (USP) in crowded markets.

• Example: TikTok’s success is partly due to its seamless scroll and load times, even on low-end devices.

7. Reduced Support Costs

• Hidden Savings: Poor performance leads to 5x more support tickets for crashes and lag. Optimizing reduces maintenance overhead.

• Netflix Example: By optimizing startup time, Netflix cut support queries by 20%.

8. Accessibility & Inclusivity

• Broader Reach: Slow apps exclude users with older devices or disabilities.

• WCAG Compliance: Performance optimizations (e.g., reduced animations) align with Web Content Accessibility Guidelines (WCAG).

9. App Store Rankings

• Algorithm Boost: Both Google Play and Apple’s App Store prioritize apps with lower crash rates and faster load times.

• Data: Apps with a 5-star rating (often tied to performance) get 4.6x more downloads than 1-star apps.

10. Environmental Impact

• Sustainability: Efficient code reduces energy consumption. For example, Google reduced YouTube’s carbon footprint by 50% via performance tweaks.

Techniques You Apply to Achieve Optimization

The Hidden Cost of Ignoring Performance reveals concerning statistics: 88% of users are less likely to return to a site or app after a bad experience according to Adobe, and a user who uninstalls your app costs 5x more to reacquire than to retain. While Airbnb achieves smooth performance natively, you can accomplish the same in Flutter. In this article, I'll dissect how Airbnb ensures smooth performance in their apps and translate those strategies into actionable steps for Flutter developers. Let's dive in!

1. Detect Performance Bottlenecks Proactively

Monitor Frame Rates with SchedulerBinding.

Airbnb uses real-time metrics to detect lag. In Flutter, you can track frame rendering times to dynamically adjust UI complexity:

void checkPerformance() {
  SchedulerBinding.instance.addPostFrameCallback((_) {
    final frameTime = SchedulerBinding.instance.drawFrameDuration;
    if (frameTime > const Duration(milliseconds: 16)) { // 60 FPS threshold
      setState(() => isLowPerformance = true);
    }
  });
}

Why this works: Flutter targets 60 FPS (16ms per frame). If rendering exceeds this, simplify the UI.

Tools to Profile Performance

• Flutter DevTools: Identify junk with the Performance Overlay (flutter run --profile).

• Firebase Performance Monitoring: Track metrics like startup time and frame rates in production.

2. Optimize Animations for Low-End Devices

Dynamically Disable Animations

Use TickerMode to toggle animations based on device health:

TickerMode(
  enabled: !isLowPerformance,
  child: SlideTransition(
    position: _animationController.drive(CurveTween(curve: Curves.easeOut)),
  ),
);

Alternative Strategies

• Simplify Animations: Replace complex Lottie animations with static SVGs.

• Lower Frame Rates: Reduce AnimationController duration for low-end devices:

_animationController.duration = isLowPerformance 
    ? const Duration(milliseconds: 300) 
    : const Duration(milliseconds: 500);

3. Optimize Resource Management

Efficient List Rendering

ListView.builder is your friend, but go further:

• Use itemExtent: Fix item height to avoid expensive layout recalculations.

• Avoid shrinkWrap: It forces widgets to compute their size upfront, causing delays.

Image Optimization

• Lazy Loading: Use cached_network_image with placeholders:

CachedNetworkImage(
  imageUrl: "https://example.com/image.jpg",
  placeholder: (context, url) => Container(color: Colors.grey[300]),
);

• Resize Images: Serve lower-resolution images for slow devices using URL parameters (e.g., image.jpg?width=400).

4. Offload Heavy Tasks with Isolates

Prevent UI Freezes

Long-running tasks (e.g., data parsing, complex calculations) should run in isolates:

Future<void> processData() async {
  final receivePort = ReceivePort();
  await Isolate.spawn(_heavyTask, receivePort.sendPort);
}

void _heavyTask(SendPort sendPort) {
  // Your compute-heavy logic here
  sendPort.send(result);
}

When to Use Isolate vs compute()

• compute(): Short-lived tasks (< 5 seconds). Simple syntax.

• Isolate: Long-running tasks. More control (e.g., two-way communication).

5. Advanced Optimization Techniques (Airbnb’s Secret Sauce)

A. Shader Precompilation

Avoid first-run junk by pre-warming shaders during app launch:

void warmUpShaders() {
  WidgetsFlutterBinding.ensureInitialized();
  final FlutterView view = WidgetsBinding.instance.platformDispatcher.views.first;
  await FragmentProgram.precompile(view.context, assetKey: 'shaders/my_shader.frag');
}

B. State Management Tuning

• Use const widgets to minimize rebuilds.

• Adopt Provider or Riverpod for granular state updates.

C. Network Optimization

• Batch API Requests: Reduce round trips for data-heavy screens.

• Cache Strategically: Use dio or http with shared_preferences for offline support.

6. Test Like Airbnb: Real-World Validation

• Device Lab Testing: Run on low-end devices (e.g., Android Go Edition).

• User Feedback Loops: Monitor app store reviews for performance complaints.

• Automate Profiling: Integrate performance checks into CI/CD pipelines.

Key Takeaways

1. Monitor Early: Use SchedulerBinding to detect lag before users do.

2. Adapt Dynamically: Simplify UI/animations for low-end devices.

3. Isolate Wisely: Keep the UI thread free for rendering.

4. Test Relentlessly: Performance is a feature—build it into your workflow.

By adopting these strategies, you’re not just coding—you’re engineering resilient, user-first apps. As Airbnb proves, performance optimization isn’t magic; it’s a mindset. Ready to make your Flutter app bulletproof? � Start optimizing today!

Further Reading:

• Flutter Performance Best Practices

• Airbnb Engineering Blog (for native optimization insights)

In Flutter development, there a few challenges that frequently surface: ensuring responsive design across devices and effectively managing resource disposal. Beginners often fall into common traps, such as over-relying on MediaQuery for responsive layouts or defaulting to StatefulWidget for resource management. But what if I told you there are better, smarter ways to handle these issues?

1. Say Goodbye to MediaQuery for Sizing

The Problem with Fractional Sizing

At first glance, MediaQuery seems like a convenient way to scale widgets based on screen size. For instance:

Container(
  width: MediaQuery.of(context).size.width * 0.3,
  child: Text('Click Me!'),
)

At first, this seems practical — the container adapts to screen size. However, this approach comes with significant drawbacks:

• Rigid Layouts: Simply scaling widgets often results in uninspired designs that fail to adapt meaningfully to different devices.

• Missed Opportunities: Larger screens can display additional content or reorganize layouts for better usability. Fractional sizing just makes things bigger or smaller, missing the chance to optimize layouts.

A Better Approach: Constraints and Adaptable Layouts

Flutter provides layout widgets like Flexible, Expanded, and LayoutBuilder to create designs that adapt dynamically to available space. For example:

Row(
  children: [
    Flexible(
      child: Container(color: Colors.blue),
    ),
    Flexible(
      child: Container(color: Colors.red),
    ),
  ],
)

In this example, the two containers share space proportionally, adapting naturally to different screen sizes.

For more complex scenarios, LayoutBuilder gives you control over how your UI changes based on constraints:

Widget responsiveLayout(BuildContext context) {
  return LayoutBuilder(
    builder: (context, constraints) {
      if (constraints.maxWidth > 600) {
        return Row(
          children: [
            Expanded(child: Text('Sidebar')),
            Expanded(child: Text('Main Content')),
          ],
        );
      } else {
        return Column(
          children: [
            Text('Main Content'),
            Text('Sidebar'),
          ],
        );
      }
    },
  );
}

This code dynamically adjusts the layout based on available width, creating a truly responsive experience.

Responsiveness Beyond Scaling

Responsive design isn’t just about resizing widgets; it’s about rethinking the user experience for each device. For example:

• On a phone: Use compact designs and stacked layouts.

• On a tablet: Leverage the extra space for side-by-side views.

• On a desktop: Add more content or features to take advantage of the larger screen.

2. Simplifying Resource Management with Disposer

The Challenges of StatefulWidget

When working with resources like TextEditingController or FocusNode, StatefulWidget is often used to ensure proper disposal:

dartCopy codeclass MyStatefulWidget extends StatefulWidget {
  @override
  _MyStatefulWidgetState createState() => _MyStatefulWidgetState();
}

class _MyStatefulWidgetState extends State<MyStatefulWidget> {
  final TextEditingController _controller = TextEditingController();
  final FocusNode _focusNode = FocusNode();

  @override
  void dispose() {
    _controller.dispose();
    _focusNode.dispose();
    super.dispose();
  }

  @override
  Widget build(BuildContext context) {
    return TextField(
      controller: _controller,
      focusNode: _focusNode,
    );
  }
}

While this works, StatefulWidget can be verbose, less readable, and harder to manage for complex apps. It also violates principles like Single Responsibility and Separation of Concerns, as it combines UI-building logic with state management.

A Smarter Solution: The Disposer Widget

The Disposer widget allows you to use StatelessWidget while still properly disposing of resources. Here’s how it works:

1. Create the Disposer Widget

    Disposer extends StatefulWidget {
      final VoidCallback dispose;
   
      const Disposer({super.key, required this.dispose});
   
      @override
      _DisposerState createState() => _DisposerState();
    }
   
    class _DisposerState extends State<Disposer> {
      @override
      Widget build(BuildContext context) => const SizedBox.shrink();
   
      @override
      void dispose() {
        widget.dispose();
        super.dispose();
      }
    }
   

2. Use It in a StatelessWidget

    DisposerExampleView extends StatelessWidget {
      final TextEditingController controller = TextEditingController();
      final FocusNode focusNode = FocusNode();
   
      void dispose() {
        controller.dispose();
        focusNode.dispose();
      }
   
      @override
      Widget build(BuildContext context) {
        return Scaffold(
          appBar: AppBar(title: const Text('Disposer Example')),
          body: Column(
            children: [
              TextField(
                controller: controller,
                focusNode: focusNode,
              ),
              Disposer(dispose: dispose),
            ],
          ),
        );
      }
    }
   

This setup ensures proper cleanup while keeping your code clean and readable.

Benefits of Using Disposer

• Shorter Code: Eliminate the need for boilerplate-heavy StatefulWidget.

• Improved Readability: Focus on UI and logic without intertwining state management.

• Reusable Logic: The Disposer widget can handle any resource with a dispose method, such as animation controllers or streams.

Bringing It All Together

By combining constraint-based layouts with the Disposer widget, you can create Flutter apps that are not only more responsive but also cleaner and easier to maintain. Here’s a practical example:

ResponsiveAndCleanApp extends StatelessWidget {
  final TextEditingController controller = TextEditingController();
  final FocusNode focusNode = FocusNode();

  void dispose() {
    controller.dispose();
    focusNode.dispose();
  }

  @override
  Widget build(BuildContext context) {
    return LayoutBuilder(
      builder: (context, constraints) {
        return Scaffold(
          appBar: AppBar(title: const Text('Smarter Flutter App')),
          body: constraints.maxWidth > 600
              ? Row(
                  children: [
                    Expanded(child: TextField(controller: controller)),
                    Expanded(child: Text('Tablet Layout')),
                  ],
                )
              : Column(
                  children: [
                    TextField(controller: controller),
                    Text('Mobile Layout'),
                  ],
                ),
        );
      },
    );
  }
}

This app adjusts its layout based on screen size while using the Disposer widget for resource management.

3. Avoid Embedding Too Much Logic in Widgets and Overloading the Build Method

One of the most common pitfalls in Flutter development is overloading the build method with too much logic or embedding non-UI-related logic directly in widgets. This approach can make the code harder to read, maintain, and debug while also leading to unnecessary widget rebuilds and performance issues.

Why It's Bad:

1. Violates Separation of Concerns:

   • Widgets are primarily responsible for building the UI, not managing business logic.

   • Mixing logic and UI tightly couples the two, making it difficult to refactor or test.

2. Decreases Readability:

   • Overloaded build methods become cluttered with conditional logic, loops, and state handling, making it harder for others (or your future self) to understand the code.

3. Causes Unnecessary Rebuilds:

   • When a widget rebuilds, all embedded logic gets reevaluated, even if it doesn't need to change.

What to Do Instead:

1. Separate Business Logic:

   • Extract non-UI-related logic into dedicated classes, controllers, or state management solutions such as Provider, Bloc, or Riverpod.

   • Example: Instead of fetching data directly in the widget, use a state management approach to handle the logic and pass the state to the widget.

2. Break Down Widgets:

   • Divide complex widgets into smaller, reusable components. This not only makes the codebase cleaner but also limits the scope of rebuilds.

   • Example: If a widget has a list and a button, separate the list into its own widget and the button into another.

3. Use Stateless Logic Helpers:

   • For reusable logic or calculations, create helper functions or utility classes that can be called without being tied to the widget lifecycle.

4. Memoize Computations:

   • If the logic in the build method involves expensive calculations, consider memoizing results using techniques like ValueListenableBuilder or Selector to avoid unnecessary recomputation.

Example: From Bad to Better

Bad Practice (Overloaded Build Method):

class ProductList extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    // Fetching data directly in the build method
    final products = fetchProductsFromApi();

    return ListView.builder(
      itemCount: products.length,
      itemBuilder: (context, index) {
        // Business logic embedded in UI
        final discountedPrice = products[index].price * 0.9;
        return ListTile(
          title: Text(products[index].name),
          subtitle: Text('Price: \$${discountedPrice.toStringAsFixed(2)}'),
        );
      },
    );
  }
}

Better Practice (Separated Logic):

class ProductList extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    // Pass data/state via Provider or another state management solution
    final products = context.watch<ProductProvider>().products;

    return ListView.builder(
      itemCount: products.length,
      itemBuilder: (context, index) {
        return ProductTile(product: products[index]);
      },
    );
  }
}

class ProductTile extends StatelessWidget {
  final Product product;

  const ProductTile({required this.product});

  @override
  Widget build(BuildContext context) {
    final discountedPrice = product.price * 0.9;
    return ListTile(
      title: Text(product.name),
      subtitle: Text('Price: \$${discountedPrice.toStringAsFixed(2)}'),
    );
  }
}

Benefits:

• The ProductList widget now only manages the layout and delegates business logic to the ProductProvider and ProductTile.

• The code is cleaner, reusable, and easier to test.

• Changes to business logic (e.g., how discounts are calculated) can be made without touching the UI code.

By avoiding overloaded build methods and separating logic, your Flutter code will be more efficient, maintainable, and easier to debug.

Other Common Poor Habits

Here are some common poor habits in Flutter development that developers should consider ditching for better performance, maintainability, and user experience:

1. Rebuilding Entire Widgets Unnecessarily

   • Decreases app performance, especially when rebuilding expensive widgets unnecessarily.

   • Instead, use const constructors where possible and memoize values to avoid unnecessary builds. Use ValueNotifier or ChangeNotifier for granular updates.

2. Not Leveraging Flutter's Built-In Widgets

   • Reinventing the wheel leads to wasted effort and potential bugs.

   • Instead, use built-in widgets like ListView, GridView, AnimatedBuilder, and others before creating custom solutions.

3. Hardcoding Text Styles and Colors

   • Results in inconsistent design and difficulty in updating themes.

   • Instead, use the ThemeData system and TextTheme for consistency across the app.

4. Ignoring Null Safety

   • Increases the risk of runtime crashes due to null exceptions.

   • Instead, embrace Dart's null safety by using nullable types and non-nullable types appropriately.

5. Overcomplicating Animations

   • Don’t write complex, hard-to-maintain animation code manually.

   • Instead, use Flutter’s animation APIs like AnimatedContainer, TweenAnimationBuilder, or Flare for simpler implementations.

6. Not Optimizing Image and Asset Loading

   • Leads to increased memory usage and slow app performance.

   • Instead, use AssetImage with Image.asset or CachedNetworkImage for efficient image loading and caching.

7. Failing to Use Asynchronous Programming Properly

   • Blocking the UI thread with heavy tasks leads to poor responsiveness.

   • Instead: Use Future, async/await, or Isolate for time-consuming operations.

8. Not Handling Edge Cases

   • Results in unhandled errors or poor user experience.

   • Instead, use error handling with try-catch, FutureBuilder, and StreamBuilder to manage async errors gracefully.

9. Using Magic Numbers

   • Reduces readability and makes updates harder.

   • Instead, define constants or use SizedBox and Padding widgets for spacing.

Conclusion: Build Better Flutter Apps

Flutter's power lies in its flexibility, but with great power comes the responsibility to use it wisely. By ditching poor habits like over-relying on MediaQuery, overloading the build method, and defaulting to verbose approaches like StatefulWidget for resource management, you can create apps that are not just functional but elegant, scalable, and efficient.

This journey begins by embracing best practices:

• Use constraint-based layouts and widgets like Flexible, Expanded, and LayoutBuilder to craft truly responsive designs that enhance the user experience across devices.

• Simplify resource management with smart solutions like the Disposer widget, making your code more concise and maintainable.

• Follow separation of concerns by extracting business logic into dedicated classes or state management solutions, ensuring that your UI remains clean and focused.

• Leverage Flutter’s built-in widgets and embrace null safety, asynchronous programming, and consistent theming for better performance and reliability.

By addressing these common challenges and replacing bad habits with smarter approaches, you’ll not only improve the quality of your code but also ensure a smoother development process and a more satisfying user experience. Flutter development is a journey, and every step towards better practices contributes to building apps that truly shine. So, let’s ditch those bad habits and start creating smarter Flutter apps today!

In this Article

This article dives into essential Flutter best practices, from optimizing widget composition and state management to improving code quality with Dart Code Metrics. It builds upon some 2 articles I wrote sometime back in 2022 on Tips & Tricks to for Your Flutter App's Performance. Whether you're a beginner or an experienced Flutter developer, following these guidelines will help you build apps that are not only efficient but also future-proof. Let’s explore these practices in detail and understand how they can elevate your Flutter projects.

Categorization of the Best Practices

To make this simpler for you I have put down a categorized breakdown of the major points into relevant sections for you.

1. Widget Optimization

1. Use const wherever possible: Reduces rebuilds, improves performance.

2. Choose Widgets Over Methods: Widgets allow better performance and optimization by Flutter’s build system.

3. Widget Composition: Break down complex UIs into smaller, reusable components.

4. Use constant widgets: Prevents unnecessary rebuilds, contributing to performance.

5. Combining Multiple Widgets: Efficiently manage UI by composing widgets instead of over-relying on complex methods.

6. Avoid Deeply Nested Widget Hierarchies: Keep the UI hierarchy shallow to improve readability and performance.

7. Avoid Returning Widgets: Instead of returning widgets directly from functions, use other patterns for better control over the UI.

2. State Management

1. Efficient state management: Use appropriate state management techniques like Provider, Riverpod, or BLoC for better scalability and performance.

2. Use StatefulWidget Wisely: Only use StatefulWidget where the widget's state truly needs to change.

3. Use Streams Only When Needed: Streams are powerful but come with overhead; use them sparingly to avoid complexity and performance bottlenecks.

4. Avoid Rebuilding Widgets Unnecessarily: Carefully manage state to minimize widget rebuilds and improve app performance.

3. Code Quality & Efficiency

1. Follow Flutter Naming Conventions: Adhere to standard naming conventions for better readability and maintainability.

2. Dart Code Metrics: Use tools like Dart Code Metrics to analyze code complexity and quality.

3. Choose Third-Party Packages Carefully: Evaluate packages based on their maintenance, popularity, and impact on performance to avoid bloat.

4. Software Testing: Implement robust testing strategies (unit tests, widget tests, integration tests) to ensure app stability and quality.

4. Core Performance

1. Build Frames in 16 ms: Ensure that each frame renders within the 16 ms frame budget to maintain smooth animations and interactions.

2. Minimize Opacity Use: Overusing opacity can harm performance; use it cautiously, especially in animations.

3. Use the Latest Version of Flutter: Always update to the latest version to benefit from performance improvements and new features.

4. Limit App Size: Keep the app size minimal to ensure faster downloads and better user experience, especially on devices with limited storage.

5. Accessibility & User Experience (UX)

1. Ensure accessibility of your App: Make sure your app is accessible to users with disabilities by following accessibility guidelines.

2. UI Efficiency: Combine practices such as widget composition, minimizing opacity, and using constant widgets for a more efficient UI design.

3. UX: Ensure your app performs well by building frames in 16ms, limiting app size, and following accessibility standards.

Key Benefits of Adhering to Best Practices

Adhering to Flutter best practices provides several key benefits:

1. Improved Performance: Using best practices like const constructors, efficient state management, and avoiding unnecessary widget rebuilds helps reduce the workload on the system, making your app faster and more responsive. Ensuring your app maintains a 16ms frame rate enhances smoothness in animations and user interactions.

2. Maintainability: Practices such as widget composition, following naming conventions, and minimizing nested hierarchies lead to cleaner, more readable code. This makes it easier for developers to manage, update, and scale the app over time, especially in team environments.

3. Scalability: Efficient state management techniques and modular code structures allow the app to grow with new features while maintaining stability and performance. By using third-party packages carefully and avoiding global variables, developers ensure that the app can scale without becoming unwieldy.

4. Reduced Memory Usage: By minimizing widget rebuilds, optimizing opacity use, and keeping the widget tree shallow, you reduce memory consumption, making the app more efficient, particularly on devices with limited resources.

5. Enhanced Developer Productivity: Leveraging Dart Code Metrics, using the latest version of Flutter, and structuring widgets properly speed up the development process by simplifying code maintenance and reducing bugs. The use of constant widgets also makes hot reloads faster, boosting productivity.

6. Accessibility and User Experience: By following best practices around accessibility and app size optimization, developers ensure that their app reaches a broader audience and offers a better user experience, even on lower-end devices or for users with disabilities.

7. Code Reusability: Practices like widget composition and clean code principles make it easier to reuse components across the app, reducing development time for new features and ensuring consistency throughout the project.

Overall, Flutter best practices lead to better app performance, smoother user experience, more maintainable and scalable codebases, and higher developer efficiency. These practices are crucial to building modern apps that can grow and perform well across a wide variety of devices.

Prerequisites

Before we start, ensure you have the following installed on your development machine:

1. Android Studio / IntelliJ IDEA (Up to date version)

2. Xcode (Optional but necessary for iOS development)

3. Node.js (Optional but necessary for web development)

By default if you install the latest version of Android Studio you should have JDK (Java Development Kit) 8 or higher. I could say the same thing for IntelliJ IDEA.

Project Creation

There are 2 ways of creating a KMP project:

1. On JetBrains' website

2. On Your IDE

1. Creating your KMP Project from JetBrains' Website

Using your browser navigate to the address https://kmp.jetbrains.com/ and fill in as well as check the boxes appropriately as in the screenshot below before you can be allowed to download the project to your PC.

After downloading it, extract to your desired location and from there you should be able to open it from Android Studio which will be our main IDE for this project.

2. Creating your KMP Project from Android Studio

You will first have to install the Kotlin Multiplatform Mobile plugin on Android Studio before proceeding. After you are down installing restart Android Studio.

After restarting Android Studi you will find the new project templates based on the plugin you just installed. Select Kotlin Multiplatfrom App and click on next.

Project Structure

A typical Kotlin Multiplatform project structure looks like this:

root
├── commonMain
│   └── kotlin
│       └── common code
├── iosMain
│   └── kotlin
│       └── iOS specific code
├── desktopMain
│   └── kotlin
│       └── desktop specific code
├── jsMain
│   └── kotlin
│       └── web specific code
├── build.gradle.kts
└── settings.gradle.kts

But its worth noting that there is a huge disparity in terms of the project structure created on JetBrains' site and on the IDE.

On the left is the project downloaded from JetBrains' site and on the right is one created via Android Studio. My take is the Android Studio plugins is behind what the website plugin offers. You might experience such differences if you clone someone's code and find its different with what you wanted to work with.

Configuring the Build

If you are coming from Android and Kotlin then this current section will be a walk over for you. But if you are new to Android and Kotlin altogether then let's dive into knowing some crucial files that we shall be working with as we work on our Kotlin Multiplatform project.

1. build.gradle.kts

2. settings.gradle.kts

3. libs.versions.toml

1. build.gradle.kts

The build.gradle.kts file is the main build configuration file for the project. It is written in Kotlin DSL (Domain Specific Language) and is used to configure the build process, dependencies, plugins, and other settings for your project.

Key Responsibilities:

• Plugins Configuration: Specifies which plugins are applied to the project.

• Kotlin Multiplatform Configuration: Defines the targets (e.g., JVM, iOS, JS) and source sets for your KMP project.

• Dependencies: Declares the libraries and frameworks that your project depends on.

• Android Configuration: If your project includes Android, this section specifies Android-specific settings like SDK versions and build types.

You can proceed to open the build.gradle.kts file to configure the build script for your project. Here's a basic example based on my project to get you started:

plugins {
    alias(libs.plugins.kotlinMultiplatform)
    alias(libs.plugins.androidLibrary)
}

kotlin {
    androidTarget {
        compilations.all {
            kotlinOptions {
                jvmTarget = "1.8"
            }
        }
    }

    listOf(
        iosX64(),
        iosArm64(),
        iosSimulatorArm64()
    ).forEach {
        it.binaries.framework {
            baseName = "shared"
            isStatic = true
        }
    }

    sourceSets {
        commonMain.dependencies {
            //put your multiplatform dependencies here
        }
        commonTest.dependencies {
            implementation(libs.kotlin.test)
        }
    }
}

android {
    namespace = "com.sirodevs.mykpmapp"
    compileSdk = 34
    defaultConfig {
        minSdk = 24
    }
    compileOptions {
        sourceCompatibility = JavaVersion.VERSION_1_8
        targetCompatibility = JavaVersion.VERSION_1_8
    }
}

2. settings.gradle.kts

The settings.gradle.kts file is used to configure the overall settings of your Gradle build, including defining the project structure and dependency resolution management.

Key Responsibilities:

• Project Inclusion: Specifies which projects are included in the build.

• Dependency Resolution Management: Configures the version catalogs for managing dependencies.

You can proceed to open the settings.gradle.kts file to configure the build script for your project. Here's a basic example based on my project to get you started:

enableFeaturePreview("TYPESAFE_PROJECT_ACCESSORS")
pluginManagement {
    repositories {
        google()
        gradlePluginPortal()
        mavenCentral()
    }
}

dependencyResolutionManagement {
    repositories {
        google()
        mavenCentral()
    }
}

rootProject.name = "MyKPMApp"
include(":androidApp")
include(":shared")

3. libs.versions.toml

The libs.versions.toml file is part of the Gradle Version Catalogs feature, which allows you to centralize and manage the versions of dependencies and plugins in your project.

Key Responsibilities:

• Version Management: Defines the versions of dependencies and plugins used in the project.

• Libraries and Plugins: Lists the libraries and plugins along with their versions, making it easier to manage and update them.

You can proceed to open the libs.versions.toml file to configure the build script for your project. Here's a basic example based on my project to get you started:

[versions]
agp = "8.5.0"
kotlin = "2.0.0"
compose = "1.5.4"
compose-material3 = "1.1.2"
androidx-activityCompose = "1.8.0"

[libraries]
kotlin-test = { module = "org.jetbrains.kotlin:kotlin-test", version.ref = "kotlin" }
androidx-activity-compose = { module = "androidx.activity:activity-compose", version.ref = "androidx-activityCompose" }
compose-ui = { module = "androidx.compose.ui:ui", version.ref = "compose" }
compose-ui-tooling = { module = "androidx.compose.ui:ui-tooling", version.ref = "compose" }
compose-ui-tooling-preview = { module = "androidx.compose.ui:ui-tooling-preview", version.ref = "compose" }
compose-foundation = { module = "androidx.compose.foundation:foundation", version.ref = "compose" }
compose-material3 = { module = "androidx.compose.material3:material3", version.ref = "compose-material3" }

[plugins]
androidApplication = { id = "com.android.application", version.ref = "agp" }
androidLibrary = { id = "com.android.library", version.ref = "agp" }
kotlinAndroid = { id = "org.jetbrains.kotlin.android", version.ref = "kotlin" }
kotlinMultiplatform = { id = "org.jetbrains.kotlin.multiplatform", version.ref = "kotlin" }
kotlinCocoapods = { id = "org.jetbrains.kotlin.native.cocoapods", version.ref = "kotlin" }
compose-compiler = { id = "org.jetbrains.kotlin.plugin.compose", version.ref = "kotlin" }

How They Affect Your KMP Project

• build.gradle.kts: This file is essential for configuring your project’s build process. It defines how your project is built, including which plugins to apply, how to configure Kotlin Multiplatform, and which dependencies to include. Any change in this file directly impacts how your project is compiled and packaged.

• settings.gradle.kts: This file sets up the structure of your project and manages dependency resolution. It is crucial for defining which subprojects are part of your build and ensuring that all dependencies are correctly resolved using the version catalogs.

• libs.versions.toml: This file provides a centralized way to manage the versions of dependencies and plugins. It makes it easier to maintain consistency across your project by defining all versions in one place. When you need to update a dependency, you only need to change it here, and it will propagate throughout your project.

Writing Common Code

Common code includes business logic, data models, and other functionalities that can be shared across platforms. Let's create a simple shared function in the commonMain source set:

import androidx.compose.animation.AnimatedVisibility
import androidx.compose.foundation.Image
import androidx.compose.foundation.layout.Column
import androidx.compose.foundation.layout.fillMaxWidth
import androidx.compose.material.Button
import androidx.compose.material.MaterialTheme
import androidx.compose.material.Text
import androidx.compose.runtime.*
import androidx.compose.ui.Alignment
import androidx.compose.ui.Modifier
import org.jetbrains.compose.resources.painterResource
import org.jetbrains.compose.ui.tooling.preview.Preview

import mykmpapp.composeapp.generated.resources.Res
import mykmpapp.composeapp.generated.resources.compose_multiplatform

@Composable
@Preview
fun App() {
    MaterialTheme {
        var showContent by remember { mutableStateOf(false) }
        Column(Modifier.fillMaxWidth(), horizontalAlignment = Alignment.CenterHorizontally) {
            Button(onClick = { showContent = !showContent }) {
                Text("Click me!")
            }
            AnimatedVisibility(showContent) {
                val greeting = remember { Greeting().greet() }
                Column(Modifier.fillMaxWidth(), horizontalAlignment = Alignment.CenterHorizontally) {
                    Image(painterResource(Res.drawable.compose_multiplatform), null)
                    Text("Compose: $greeting")
                }
            }
        }
    }
}

class Greeting {
    private val platform = getPlatform()

    fun greet(): String {
        return "Hello, ${platform.name}!"
    }
}

Platform-Specific Code

In a Kotlin Multiplatform project, you typically have a commonMain source set where you define shared code that can be used across different platforms (Android, iOS, desktop, etc.). The MyKMPApp composable function is already defined in the shared module, allowing it to be reused across multiple platforms.

Android

In Android the MainActivity class, is specific to the Android platform. It is responsible for setting up the Android-specific components and displaying the shared composable UI. The setContent function integrates Jetpack Compose with the Android activity lifecycle, allowing you to use the shared composable function within the Android app.

The preview function AppAndroidPreview is useful for development, as it allows you to see how the composable will render on an Android device without having to run the app. This improves development speed and provides immediate visual feedback.

package com.sirodaves.mykmpapp

import MyKMPApp
import android.os.Bundle
import androidx.activity.ComponentActivity
import androidx.activity.compose.setContent
import androidx.compose.runtime.Composable
import androidx.compose.ui.tooling.preview.Preview

class MainActivity : ComponentActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)

        setContent {
            MyKMPApp()
        }
    }
}

@Preview
@Composable
fun AppAndroidPreview() {
    MyKMPApp()
}

iOS

For iOS, Kotlin Multiplatform generates a framework that can be used in Xcode. To use the shared code in your iOS app, do the following:

1. Open the iosMain folder in Android Studio.

2. Write your iOS-specific code in Kotlin.

3. Configure Xcode to use the generated framework.

Create a Swift file in your iOS project to call the shared code:

import androidx.compose.ui.window.ComposeUIViewController

fun MainViewController() = ComposeUIViewController { MyKMPApp() }

Desktop

For desktop applications, your basic code to get your app running on desktop might look like this:

import androidx.compose.foundation.layout.*
import androidx.compose.ui.*
import androidx.compose.ui.unit.dp
import androidx.compose.ui.window.*

fun main() {
    return application {
        Window(
            onCloseRequest = { exitApplication() },
            title = "My KMP App",
            state = rememberWindowState(
                position = WindowPosition.Aligned(Alignment.Center),
                width = 1200.dp,
                height = 700.dp,
            ),
        ) {
            Box(modifier = Modifier.fillMaxSize(), contentAlignment = Alignment.Center) {
                MyKMPApp()
            }
        }
    }
}

Web

For web applications, Kotlin Multiplatform supports Kotlin/JS. You can use Kotlin/JS with React or other JavaScript frameworks. Here's a basic example using Kotlin/JS:

1. Add the dependency in your build.gradle.kts:

implementation("org.jetbrains.kotlin-wrappers:kotlin-react:17.0.2-pre.208-kotlin-1.5.0")
implementation("org.jetbrains.kotlin-wrappers:kotlin-react-dom:17.0.2-pre.208-kotlin-1.5.0")

2. Write your web-specific code in the jsMain source set:

import react.dom.render
import kotlinx.browser.document
import react.RBuilder
import react.dom.h1

fun main() {
    render(document.getElementById("root")) {
        MyKMPApp()
    }
}

Running the Application

Running your app on Android and iOS is pretty much easy based on either Android Studio or Xcode respectively. You can get the app to run on a simulator or a real device. Lets focus on getting it to run on a desktop.

To run your KMP Desktop application directly from Android Studio, you need to set up a run configuration.

• 1. Configure build.gradle.kts

  Make sure your build.gradle.kts file is correctly set up for the desktop target. Here's an example configuration:

    kotlin {    
        jvm("desktop") {
            compilations.all {
                kotlinOptions {
                    jvmTarget = "11"
                }
            }
        }
  
        sourceSets {
            val desktopMain by getting
  
            desktopMain.dependencies {
                implementation(compose.desktop.currentOs)
            }
        }
    }
  
    compose.desktop {
        application {
            mainClass = "MainKt"
  
            nativeDistributions {
                targetFormats(TargetFormat.Dmg, TargetFormat.Msi, TargetFormat.Deb)
                packageName = "com.sirodevs.mykmpapp"
                packageVersion = "1.0.0"
            }
        }
    }
  

  2. Set Up Run Configuration in Android Studio

  1. Open Run/Debug Configurations:

     Go to Run > Edit Configurations... from the top menu.

     

  2. Add a New Configuration:

     • Click the + button to add a new configuration.

     • Select Gradle from the list.

       

• Name: Give your configuration a name, e.g., Run Desktop App.

• Gradle Project: Select your project or root module.

• Tasks: Enter :desktop:run (assuming your desktop module is named desktop).

• Script Parameters: Leave this blank.

• VM Options: Optionally, you can set JVM options if needed.

• Working Directory: This should be set to the root directory of your project.

  3. Apply and Save:

• Click Apply and then OK to save the configuration.

Conclusion

Kotlin Multiplatform allows you to write code once and run it on multiple platforms, significantly improving productivity and maintaining consistency across different environments. By following the steps outlined in this article, you can create a robust Kotlin Multiplatform application that targets iOS, desktop, and web platforms. As the ecosystem grows, more libraries and tools will become available, making Kotlin Multiplatform an even more powerful choice for cross-platform development.

See you in my next one where I will get into more details of making a Droidcon Ke App with KMP!

You've been diligently working on a groundbreaking Flutter app for your client or company, pouring hours into writing and refining code. You're making excellent progress, but suddenly, you hit a snag. As you type or modify code, those familiar red squiggly lines that signal errors or warnings are conspicuously absent. Typically, you rely on these visual cues in VSCode to point out mistakes and guide you toward solutions. Without them, it's like driving without a GPS: you know you're off course, but not exactly where or how to get back on track. You are expecting something like this next image but then it doesn't show up.

This lack of immediate feedback from your trusted IDE can significantly slow down your development process and lead to frustration especially when you rushing to push that PR so that it can be reviewed and merged to stable code. The cop you are expecting to stop you by the roadside and point out your mistake and definitely tell you how to fix it is called the Dart Analysis Server. Now before you what this is I will answer you shortly.

What is a Dart Analysis Server?

The analysis server is a long-running process that provides analysis results to other tools. It is designed to provide on-going analysis of one or more code bases as those code bases are changing.

Key Features of the Dart Analysis Server

1. Real-Time Error Detection and Reporting: it continuously checks your code for syntax errors, semantic errors, and other issues. It provides immediate feedback with underlines and tooltips directly in your VSCode IDE, helping you identify and correct mistakes as you type.

2. Code Completion: it offers intelligent code completions, suggesting methods, properties, and variables that are contextually relevant which accelerates coding by reducing the need to remember every detail of the API or library you are using.

3. Code Navigation: it allows you to navigate through your codebase effortlessly. You can jump to the definitions of classes, methods, and variables, making it easier to understand and manage your code structure.

4. Refactoring Support: it provides tools for safe and efficient code refactoring. You can rename symbols, extract methods, and perform other refactoring operations, with the server ensuring that these changes are applied consistently throughout your codebase.

5. Linting and Style Checks: it enforces coding standards and style guidelines through linting. It highlights code that does not conform to specified rules, helping maintain a consistent and clean codebase.

6. Quick Fixes and Code Actions: it often provides quick fixes and code actions that can be applied with a single click. These suggestions can range from correcting simple typos to more complex refactoring.

How the Dart Analysis Server Works

Now that you know the features of the DAS, I will proceed to tell you how it works so that you may understand how to fix it when it takes an indefinite holiday in the middle of your coding session.

It runs as a background process that communicates with your IDE through a protocol. It maintains an in-memory representation of your project's codebase, which it continuously analyzes as you make changes. This persistent analysis allows it to offer real-time feedback without the need for constant recompilation.

• Initialization: At initializes the moment you open a Dart project on your IDE and begins parsing the project's files.

• Incremental Analysis: As you edit your code, it incrementally analyzes the changes which minimizes latency such that feedback is provided almost instantaneously.

• Communication: It communicates with your IDE using the Language Server Protocol (LSP). This standardized protocol allows the server to send notifications about errors, suggestions, and code completions to the IDE, which then displays them to you.

Benefits of Using the Dart Analysis Server

1. Improved Productivity

2. Enhanced Code Quality

3. Easier Debugging

4. Consistent Refactoring

Troubleshooting Dart Analysis Server Crashes

If you're working with Flutter and Dart in VS Code, you might occasionally encounter issues where the Dart Analysis Server crashes. This can disrupt your development workflow by causing problems like errors not showing up in the editor until you build the project. Here are some steps and tips to help you fix and prevent the Dart Analysis Server from crashing.

1. Ensure You Have the Latest Versions

Update VSCode and Extensions:

• Open VSCode and go to the Extensions view by clicking the Extensions icon in the Activity Bar on the side of the window.

• Search for "Flutter" and "Dart" extensions and check if there are updates available. Update them if needed.

• Additionally, make sure your VSCode installation is up to date by going to Help > Check for Updates.

2. Clear the Dart Analysis Server Cache

Sometimes, corrupted cache files can cause the analysis server to crash. Clearing the cache can help resolve this.

Locate and Delete Cache Files:

• macOS and Linux:

  1. Open a terminal window.

  2. Navigate to your home directory:

      cd ~
     

  3. List all files, including hidden ones:

      ls -a
     

  4. Navigate to the .dartServer directory:

      cd .dartServer
     

  5. Delete the contents of the directory:

      rm -rf *
     

• Windows:

  1. Open File Explorer.

  2. Navigate to your user directory (e.g., C:\Users\YourUsername).

  3. Ensure that hidden files are visible (View > Hidden items).

  4. Find and open the .dartServer directory.

  5. Select all contents and delete them.

3. Restart the Dart Analysis Server

After clearing the cache, restart the Dart Analysis Server to reinitialize it.

Restart the Analysis Server:

1. Open VSCode.

2. Open the Command Palette by pressing Ctrl+Shift+P (or Cmd+Shift+P on macOS).

3. Type and select "Dart: Restart Analysis Server".

4. Adjust VSCode Settings

Certain settings in VSCode can help manage the performance and stability of the Dart Analysis Server.

Enable Auto-Save:

• Go to File > Auto Save to enable auto-saving of your work. This ensures that changes are continuously checked by the analyzer.

Exclude Large or Unnecessary Files from Analysis:

• Open your VSCode settings (File > Preferences > Settings or by pressing Ctrl+,).

• Search for "dart.analysisExcludedFolders" and add paths to folders that you don't need to be analyzed, such as build directories or large dependency folders.

5. Check for Syntax Errors and Linter Configuration

Syntax errors and misconfigured linters can sometimes cause the analysis server to fail.

Check for Syntax Errors:

• Carefully review your code for any syntax errors or typos that might disrupt the analysis process.

Verify Linter Configuration:

• Ensure that you have a proper analysis_options.yaml file in the root of your Flutter project and that it does not contain any rules that might be suppressing error messages or causing conflicts.

6. Reinstall Extensions

If problems persist, try reinstalling the Flutter and Dart extensions.

Reinstall Extensions:

1. Uninstall the Flutter and Dart extensions from the Extensions view.

2. Close and reopen VSCode.

3. Reinstall the extensions from the Extensions view.

7. Create a New Project

Sometimes issues can be project-specific. Creating a new Flutter project can help determine if the problem lies within your current project setup.

Create a New Flutter Project:

1. Open the Command Palette (Ctrl+Shift+P).

2. Select "Flutter: New Project" and create a new project.

3. Check if the new project has the same issue.

Conclusion

By following these steps, you should be able to resolve most issues related to the Dart Analysis Server crashing in VSCode. Keeping your tools up to date, managing your project files effectively, and ensuring proper configuration are key to maintaining a smooth development experience. If the issue persists, consider seeking help from the Flutter community online hoping you are a member of one, otherwise we have StackOverFlow, Github and the official Flutter as well as Dart documentation.

Flutter is an exciting framework that allows you to build beautiful cross-platform mobile applications. If you're new to Flutter, don't worry – setting it up is easier than you think! In this guide, we'll walk you through the installation process on Windows, macOS, Linux, and even Chrome OS. We'll cover both Android Studio, Visual Studio Code and even IntelliJ IDEA to make sure you have the tools you need to start coding.

Installing Android SDK

Installing Android Studio and its SDK is a crucial step for Flutter development. Below, I'll provide a beginner-friendly guide for installing Android Studio on Windows, macOS, and Linux.

1. Download Android Studio:

   • Visit developer.android.com/studio

   • Download the installer for your operating system.

2. Install Android Studio

   1. When it comes to installing depending on the OS you are in instructions may differ as below.

• For Windows, run the .exe installer.

• For macOS, open the downloaded .dmg file and drag Android Studio to the "Applications" folder.

• For Linux, extract and run the installer in the bin directory using ./studio.sh.

• For chromeOS, just follow the Linux instructions after enabling Linux support on your Chromebook.

2. Follow the wizard instructions for installing once the installer is running.

3. Install Android Virtual Device (AVD) during setup.

3. Launch Android Studio

   1. Configure Flutter in Android Studio by installing the Flutter and Dart plugins before restarting the IDE.

   2. Access the SDK Manager, click on "Configure" at the bottom right corner and select "SDK Manager."

   3. Install Command-Line Tools:

      • In the SDK Platforms tab, select "Show Package Details."

      • Look for "Android SDK Command-line Tools" and check the box.

      • Click "Apply" to install.

Installing Flutter SDK

To install the Flutter SDK, follow these general instructions. I'll specify any OS-specific steps where needed:

1. Downloading and Extracting

   1. Download the Flutter SDK from the official website.

   2. Extract the ZIP file to a preffred location on your machine.

2. Adding Flutter to the system Path variable

   For Windows:

   1. Press Win + S to open the search bar.

   2. Type "Environment Variables" and select "Edit the system environment variables" to open it.

   3. In the System Properties window, click the "Environment Variables..." button.

   4. In the Environment Variables window, under the "System variables" section, find and select the "Path" variable. Click "Edit."

   5. Click "New" and add the path to the Flutter bin directory (e.g., D:\Devs\flutter\bin).

   6. Click "OK" to close each window.

   7. Open a new Command Prompt or PowerShell window and run flutter --version to verify that Flutter is in the PATH.

macOS/Linux:

1. Open a terminal window.

2. Depending on your shell (bash, zsh, etc.), open the appropriate profile file. For example:

   • For bash: nano ~/.bashrc or nano ~/.bash_profile

   • For zsh: nano ~/.zshrc

3. Add the following line at the end of the file to add Flutter to PATH:

    export PATH="$PATH:/home/sirodevs/flutter/bin"

4. Replace /home/sirodevs/flutter with the actual path to your Flutter installation.

5. Save the file (press Ctrl + X, then Y, then Enter in nano).

You could also run this on your terminal as a shortcut to avoid opening the nano editor

echo 'export PATH="$PATH:/home/sirodevs/flutter/bin"' >> ~/.bashrc

6. Run source ~/.bashrc (or source ~/.zshrc) to apply the changes and reload the profile.

7. Open a new terminal window and run flutter --version to verify that Flutter is in the PATH.

These instructions should help you add Flutter to the system PATH variable on your specific operating system. After completing these steps, you should be able to use Flutter commands from any directory in the terminal or command prompt.

user in plugdev group; are your udev rules wrong or error: insufficient permissions for device: udev requires plugdev group membership?

echo 'export ANDROID_SDK_ROOT="/home/sirodevs/Developer/Android/Sdk"' >> ~/.bashrc

This article is not finished yet, I will keep updating it and adjusting it as we go along.

After examining the comprehensive comparison between cross-platform and native development, along with exploring the shared principles and complexities inherent in cross-platform development – encompassing coding, compiling, testing, and debugging processes – it is now time to address the elephant in the room.

With 6 distinguished options: Cordova, React Native, Progressive Web Apps (PWAs), Xamarin (C#), Flutter (Dart) and Kotlin Multiplatform (KMP), it can be hard to choose among the cross-platform frameworks, especially if you are a CTO or project manager.

Factors to Consider

1. Framework Evaluation Factors:

   • Cost Considerations: Assess the overall cost of adopting the framework, including licensing fees, development expenses, and potential savings over time.

   • Time-to-Market: Examine how quickly the framework allows you to bring your application to market, considering project timelines and deadlines.

   • Development Costs: Evaluate the overall development costs associated with the framework, including initial setup and ongoing maintenance.

2. Developer's Perspective:

   • Learning Curve: Consider the learning curve associated with each framework. A smoother learning curve can contribute to faster development.

   • Native Platform Knowledge: Examine the level of knowledge of native platforms required. Some frameworks may demand more familiarity with iOS or Android development.

3. Practical Considerations:

   • Development Tools: Assess the available development tools, including integrated development environments (IDEs) and debugging capabilities.

   • Code Maintenance: Explore the feasibility of maintaining a single code base across platforms. Consider factors such as code readability and ease of updates.

4. Team Expertise:

   • Existing Team Skills: Leverage the expertise of your existing team. The skills they possess may heavily influence the choice of a framework.

   • Hands-On Testing: Experiment with each framework to determine how well it aligns with your team's needs and workflow.

5. Real-world Scenario:

   • Current Project Status: Acknowledge that your project might not be starting from scratch. Consider the existing codebase and requirements when making your decision.

The best way to choose

You can try and divide your choosing in phases or steps as below:

1. Exploration/Research:

   • Quality Time Investment: Spend time exploring each cross-platform framework individually to understand their nuances and capabilities.

   • Support System and Documentation: Evaluate the available support system, documentation, and tools provided by each framework.

   • Template and Example Availability: Check if frameworks offer templates or examples that can serve as a starting point for your app development.

2. Research and Comparisons:

   • Framework Websites: Begin your exploration by visiting the official websites of each framework to gather initial insights.

   • Web Search and Opinions: Conduct a web search to find opinions and reviews on each tool, gaining diverse perspectives.

   • Comparison Articles: Seek articles comparing the strengths and weaknesses of each framework in relation to one another.

3. Consider Team's Expertise:

   • Assess Team's Talents: Prioritize evaluating your team's existing skills and expertise before delving into cross-platform frameworks.

   • Tailor Choice to Talents: Align your choice with your team's strengths; for instance, if your team leans towards web development, hybrid frameworks or PWAs may be more suitable.

4. Subjectivity in Decision-Making:

   • Recognize Subjectivity: Acknowledge that framework selection often involves subjective elements, and tailor your choice to your team's strengths.

   • Personalized Approach: Understand that the best decision may differ for each team, and the key is to tailor the choice based on existing talents.

5. Empowerment and Final Steps:

   • Information for Decision: Ensure you have gathered enough information to make an informed decision that suits your team and project needs.

   • Create Your App: Armed with insights, move forward to create your cross-platform app, leveraging the chosen framework that aligns with your team's expertise.

This article aims to empower you with the knowledge needed to embark on your cross-platform app development journey. Good luck in creating that outstanding app for your team!

In my previous article Cross-Platform Development in 2024 2/3 I explored 3 cross platform tools: Cordova, Progressive Web Apps (PWAs) and React Native. In this article I will proceed to explore the other 3: Xamarin, Flutter and Kotlin Multiplatform. So let's jump right into it.

Xamarin

What is Xamarin?

Xamarin, built on the open-source.NET platform and later acquired by Microsoft, is a cross-platform development framework utilizing the C# programming language. With support for iOS, Android, Windows and Mac, it facilitates the creation of native apps. Integrated into Microsoft's Visual Studio, Xamarin primarily leverages this robust integrated development environment, although developers have the technical flexibility to write Xamarin code in various editors. A notable advantage of Xamarin lies in its capacity to segregate shared business logic from the app's user interface, allowing an estimated 70 to 90% of code in the business logic tier to be reused across different platforms.

Xamarin App Architecture

Xamarin offers the Xamarin.Forms package, enabling developers to create the UI using C#, establishing a unified development stack for multiple platforms. The development process for Xamarin apps revolves around C#, utilizing platform-specific libraries to craft business logic for cross-platform applications. Optionally, Xamarin.Forms can be employed to develop the UI for all platforms using C#. The Xamarin framework automates the compilation of apps for supported platforms and is adept at handling memory allocation, garbage collection, and platform interoperability.

The outcome is applications that are frequently likened to native ones, boasting comparable performance and user experience on both iOS and Android mobile development platforms. A Xamarin app comprises shared business logic, often covering aspects like database and network access in C#. The UI can be coded in C# using Xamarin.Forms or natively, inside or outside of Visual Studio, resulting in a Platform Native App compatible with platforms such as Android, iOS, Windows, and Mac.

Xamarin's Strength

1. Unified Development: It offers a single entry point for mobile development across various platforms, enabling developers to use one language (C#) and one tool (Visual Studio) to target iOS, Android, Windows and Mac. This results in a comprehensive end-to-end solution in the cross-platform market space.

2. Performance Parity: Xamarin apps deliver performance comparable to native apps in Java, Objective-C, or Swift, ensuring a seamless user experience.

3. Consistent UI: Xamarin provides UI components through Xamarin Forms or native UI development, ensuring that Xamarin apps maintain the look and feel of native apps across platforms.

4. Device Functionality: Xamarin apps seamlessly integrate with common device functionality across platforms using plugins and specific APIs, eliminating hardware compatibility issues.

5. Native Libraries Linking: Xamarin supports linking with native libraries, allowing for better customization and the incorporation of native-level functionality with minimal overhead.

6. Open Source and Backed by Microsoft: The Xamarin SDK is open source and backed by Microsoft, ensuring continuous support and development. Microsoft's commitment to building apps for Android and iOS positions Xamarin as a key player in this ecosystem.

7. Strong Developer Community: Xamarin benefits from a strong community of developers skilled in C# and the .NET platform, making it comparable to finding developers for writing native apps. Xamarin developers can target multiple platforms, unlike native developers who usually focus on a single platform.

8. Integrated and a Cross-Platform Development in Visual Studio: Xamarin development is primarily done in Visual Studio, offering first-class support for creating Xamarin apps. Visual Studio allows building native UIs for Android and iOS seamlessly using drag-and-drop tools. For those new to Visual Studio, it provides a unified environment for creating cross-platform native apps without the need for patching together various tools.

9. Xamarin Live Player: This tool enables continuous deployment, testing, and debugging directly on iOS and Android devices, streamlining the development and testing process.

Flutter

What is Flutter?

Flutter, a cross-platform native app framework developed by Google, is an open-source solution that generates native apps for Android, iOS, web, Linux, Windows and Mac. Its seamless integration with development tools such as Android Studio, IntelliJ and Visual Studio is facilitated by plugins dedicated to the Flutter framework and Dart programming language.

Flutter App Architecture

Flutter employs a unified set of tools and technologies for diverse platforms, primarily utilizing the Dart language to construct Flutter widgets. These widgets, written in Dart, are compiled into native apps by the Flutter framework, delivering applications compatible with Android, iOS, web and desktop platforms.

Flutter's Strengths

1. High-Speed Deployment: Similar to React Native, Flutter excels in delivering fast, native-speed applications. By generating native apps, Flutter ensures performance comparable to other native apps on the device, eliminating the slower nature of hybrid apps running within platform-specific web components.

2. User Interface Development: At its core, Flutter is a user interface development tool that revolves around the concept of widgets. Every element in a Flutter app is a widget, enabling developers to compose custom widgets as needed. These widgets are compiled to utilize the same UI components as regular iOS, Android apps web apps or desktop apps, with Dart replacing Swift, Objective-C, or Java or Javascript or C/C++ for assembly.

3. Declarative Programming with Dart: Flutter employs Dart, a modern and expressive programming language that adopts a declarative approach. Declarative languages enable developers to focus on the "what" rather than the "how," streamlining the development process. This approach allows Flutter developers to maintain a single code base for both Android and iOS.

4. Platform Independence: Flutter effectively manages platform differences, freeing developers to concentrate on the app's functionality rather than the intricacies of various platforms. This results in a unified development experience across Android and iOS platforms.

5. Hot Reload Feature: Flutter incorporates a powerful feature called hot reload, allowing developers to experiment with code modifications while the app is running. It facilitates real-time debugging and correction of crashes without interrupting the development flow.

6. Modern Framework with Built-in Widgets: As a modern framework reminiscent of React, Flutter includes a 2D rendering engine and pre-built widgets that adhere to material design for Android and Cupertino themes for iOS. This approach streamlines the development of visually appealing and consistent applications.

7. Integration with Developer Tools: Flutter has strong ties with popular developer tools, including Android Studio, IntelliJ and Visual Studio. This integration enhances the development environment, making it convenient for developers to work seamlessly within their preferred IDEs.

Kotlin Multiplatform (KMP)

What is KMP? What is KMM?

Kotlin Multiplatform (KMP) is a technology developed by JetBrains that allows you to write code in Kotlin that can be shared and run across multiple platforms like Android, iOS, web (JavaScript), desktop (Windows, macOS, Linux).

Kotlin Multiplatform Mobile (KMM) is extension of KMP, specifically tailored for mobile application development with a primary focus on Android and iOS.

KMP App Architecture

KMP aims to address the challenge of developing and maintaining separate codebases for different platforms, which can be time-consuming and error-prone. With KMP, you can write common business logic, data models, and utility functions in Kotlin and then target specific platform-specific implementations for user interfaces, networking, and other platform-dependent features.

Sharing code between mobile platforms is a major Kotlin Multiplatform use case. With Kotlin Multiplatform, you can build cross-platform mobile applications that share code between Android and iOS projects to implement networking, data storage and data validation, analytics, computations, and other application logic.

KMP's Strengths

1. Shared Code: Develop the essential logic of your application or library in Kotlin, creating code that can be shared across diverse platforms. This code, usually platform-agnostic, encompasses business logic, algorithms, and data models.

2. Shared Interfaces: Define shared interfaces or APIs with Kotlin Multiplatform, enabling different implementations on each platform. This ensures a consistent API while accommodating platform-specific requirements.

3. Gradle Integration: Manage Kotlin Multiplatform projects seamlessly with the Gradle build system. Gradle facilitates the configuration and building of shared code and platform-specific implementations.

4. Code Sharing: Reuse code across platforms to minimize duplication, enhance maintainability, and potentially expedite development. While some platform-specific code may still be necessary for an optimal user experience, Kotlin Multiplatform aims to maximize code reuse.

5. Platform-Specific Code: Tailor platform-specific implementations for each target platform (e.g., Android, iOS, JavaScript), addressing interactions with the platform’s APIs, UI components, and other features.

Other Options

Having looked at a few of the more popular Cross-platform frameworks, I would like to briefly mention some that you may not have heard of or know little about:

1. Corona SDK: For Cross-platform game development, explore Corona SDK. It's a gaming engine that utilizes the Lua Programming Language to construct Cross-platform apps, providing full access to the native system.

2. NativeScript: This is a Cross-platform JavaScript framework generating platform-native UIs with Angular, TypeScript, and JavaScript. Developers can choose their preferred tools, and NativeScript can be installed as a Visual Studio plugin. Learn more at the NativeScript homepage.

3. Ionic Framework: An open-source framework for hybrid mobile apps, Ionic is built on Cordova and supports Angular JS, TypeScript, HTML, CSS, and JavaScript for app development. It offers starter templates, additional native plugins, and app themes. Visit the Ionic Framework website for more details.

4. Codename One: If you're a Java developer, Codename One is worth checking out. It functions as a plugin for Eclipse, NetBeans, and IntelliJ, offering a second-generation drag-and-drop GUI builder. It's free and open source, allowing you to stay within the Java language for your development needs.

In another article I plan to talk about how you can choose a cross platform to use in your next massive cross platform project: Choosing a Cross Platform Tool in 2024. So see you there.

In my previous article Cross-Platform Development in 2024 1/3 I explored the realm of cross-platform app development, highlighting:

• Its benefits such as skill set consolidation, code re-usability, streamlined maintenance, and cost savings.

• Insights into when cross-platform development may not be ideal, such as specific platform targeting or low-level hardware requirements.

• Details of the construction of hybrid cross-platform apps using HTML, CSS, and JavaScript, and drawing a parallel to Java applications.

• Cross-Platform Native Apps, categorizing them into two types based on business logic and UI code.

This is a continuation of that article in a 3 part series of articles intended to help you choose a cross-platform framework for your next mobile app project. I plan to explore five of the most popular cross-platform frameworks, Cordova, React Native, Xamarin, Flutter, and Progressive web apps. For each of the platforms, we'll talk about the tools and technologies used by the platform and where the framework excels. So let's proceed and address 3 of them.

Cordova

What is Cordova?

Cordova is an open-source command line tool that enables mobile app developers to create hybrid apps for various platforms using web technologies like HTML5, CSS3, and JavaScript. It functions as a build tool, transforming web applications into native apps for supported platforms.

Cordova App Architecture

Cordova's key feature lies in enhancing the native web view component on each platform, establishing a link through plugins to provide access to the device's native capabilities for the app via JavaScript. In essence, Cordova acts as a bridge, seamlessly integrating web technologies into native app development, making it a versatile solution for cross-platform hybrid applications.

Cordova's Strengths

1. Cross-Platform Efficiency:

   • It enables mobile developers to target multiple platforms with a single code base using HTML, CSS, and JavaScript.

2. Web App Conversion:

   • Ideal for web developers looking to convert existing web apps into native apps, leveraging existing code for diverse platforms supported by Cordova.

   • Provides the opportunity to showcase apps in platform app stores without the need to learn complex platform-specific tools.

3. Extensive Platform Support:

   • Supports a wide range of platforms, allowing developers to write a single app for various phones and tablets.

   • Check the Cordova platform support page for a comprehensive list of supported platforms and features.

4. Versatile Build Tool:

   • Acts as a robust build tool, taking web applications as input and producing native apps as output.

   • Specifies required device capabilities and integrates plugins to enable these capabilities, offering flexibility in app development.

5. Mature and Established:

   • One of the oldest cross-platform tools, Cordova benefits from extensive bug fixing and has served as the foundation for other frameworks.

   • Boasts a large development community and extensive documentation, making it a reliable and well-supported choice.

6. Language Familiarity:

   • Developers can leverage HTML, CSS, and JavaScript, languages they likely already know, to build Cordova apps.

   • Eliminates the need to learn additional programming languages like Java, C#, Objective-C, or Swift.

7. Editor and IDE Independence:

   • Cordova doesn't impose a specific editor or integrated development environment (IDE), offering flexibility in choosing development tools.

   • Unlike IDEs, Cordova focuses on the build process and doesn't include features like debugging tools or project-based organization.

8. Ease of Learning:

   • Cordova's simplicity lies in its short list of commands, making it easy to learn and use for developers familiar with web technologies.

   • Eliminates the need to invest time in learning new programming languages or complex IDEs.

Progressive Web Applications (PWAs)

What are PWAs

Today's modern browsers have overcome the limitations of native apps and hybrid frameworks by incorporating features that address various shortcomings. These browsers now support offline content loading, standardized technologies like responsive design, and web push notifications. Notably, they allow users to add web apps to their home screens on mobile devices, providing an app-like experience. Progressive web apps (PWAs) take advantage of these advancements, functioning as websites leveraging new web technologies such as web app manifests and JavaScript service workers. PWAs prioritize responsiveness, ensuring they adapt seamlessly to diverse platforms and screen sizes like any other responsive website.

PWAs Checklist

1. Responsive: Prioritize responsiveness to ensure the PWA seamlessly adapts to various platforms and screen sizes.

2. Secure: Ensure the PWA is served over HTTPS to meet security requirements and protect user data.

3. Available Offline: implementing effective caching strategies to allow offline content loading and offline resource caching.

4. Installable: Enable users to install the PWA on their home screens, providing a more app-like experience.

5. Cross-Browser Compatibility: Test and ensure that the PWA works seamlessly in multiple browsers that support the PWA specification.

More information on the PWA Checklist can be found on the PWA Website.

PWAs' Strengths

1. Data-Friendly: Highly efficient in terms of data usage, often requiring a fraction of the size compared to traditional native apps. Users can interact with the app without the need for a prior installation, and they can decide to install it later.

2. Easy Updates: By updating files on servers, new features or content can be seamlessly integrated. Properly configured PWAs automatically download and install updates on the next launch.

3. Simple Sharing: Sharing PWAs is exceptionally straightforward since they are essentially URLs. These links can be embedded in various platforms, including social media and emails. The process does not involve app store interactions for updates or sharing.

4. No App Store Dependency: Operate independently of app stores, providing a hassle-free environment for updates and sharing. Developers have more control over the distribution process, contributing to a more streamlined experience.

5. Push Notification Support: PWAs include support for push notifications, enhancing user engagement by allowing developers to keep users informed and involved in app updates and relevant content.

6. URL-Based Accessibility: As PWAs are accessed through URLs, users can interact with them directly without navigating through app stores. This simplicity makes PWAs easily accessible and shareable across various platforms.

React Native

What is React Native?

React Native is an open-source cross-platform Native app framework rooted in Facebook's widely used React JavaScript library. This framework emerged as a response to the dissatisfaction of Facebook engineers with the performance of their hybrid mobile app.

React Native app development involves initiation and compilation through a command line interface, resulting in Native Android and iOS apps crafted using JavaScript, ECMAScript, and JSX.

React Native App Architecture

Developers predominantly use a combination of JavaScript, ECMAScript, and JSX, a language allowing XML embedding within JavaScript, to write React Native apps. The framework excels in seamlessly compiling code into Native Android and iOS apps, offering indistinguishable performance from apps crafted with platform-specific tools. This approach integrates business logic in JavaScript with UI code in JSX or ECMAScript, enabling comprehensive app development from a unified code base. Additionally, React Native facilitates the incorporation of platform-specific code if needed, allowing developers to extend and modify the resulting Native app in Android Studio or Xcode.

React Native's Strengths

1. Speed and Performance: React Native excels in delivering fast and efficient apps by generating Native applications rather than relying on hybrid approaches, eliminating the performance lag associated with hybrid apps.

2. User Interface Development: At its core, React Native serves as a powerful user interface development tool. It allows developers to use React Native views instead of HTML or platform-specific UI components, resulting in apps that utilize the same UI components as regular iOS and Android apps.

3. Language Flexibility: React Native empowers developers to use JavaScript, specifically ECMAScript (ES6), for building applications. ES6, the official standard, enhances the capabilities of JavaScript and contributes to the development of robust React Native apps.

4. Testing Efficiency: With the Expo SDK, React Native facilitates efficient app testing on devices without the need for complex tools like Android Studio or Xcode, streamlining the testing process and enhancing overall development efficiency.

5. Single Code Base for Multiple Platforms: Developers can maintain a single code base for both Android and iOS, as React Native handles platform differences, allowing a focus on app functionality rather than intricate platform-specific details.

6. Hot Reload Feature: This feature enables developers to repackage and update launched applications without losing their state, providing a quick and efficient way to test and implement new features.

7. Integration of Native Code: smoothly integrates with Native code, allowing developers to combine it with components written in Objective-C, Swift, or Java, offering flexibility in app optimization.

8. Active Development Community: Leveraging the React JavaScript library's popularity, React Native benefits from a large and active development community, ensuring access to extensive resources and support for developers.

This article has been able to explore 3 of the most popular cross-platform frameworks: Cordova, PWAs and React Native. I'll explore the other 3: Xamarin, Flutter and KMM in the next article: Cross-Platform Development in 2024 3/3. So see you in the next one.