u/Prior-Dependent-5563

I keep having the same conversation with devs who are still defaulting to React Native out of habit. Not saying RN is bad ,but the performance argument for Flutter feels more and more settled at this point.

Where I think Flutter genuinely wins for startups: one codebase, Skia-based rendering so you're not at the mercy of native widget quirks, and the DX on hot reload is still better than anything I've used in the RN ecosystem. For a small team shipping fast, that matters.

The state management story is still a mess though. Riverpod is great but there's a learning curve, and I've seen teams end up in some genuinely weird places with Provider still floating around legacy code. That's a real onboarding friction point.

Platform channel complexity also comes up the moment you need anything non-trivial with native hardware ,. camera pipelines, Bluetooth, background tasks. It's solvable but it's not zero cost.

That said, the production deployments I've seen in the last year have been pretty solid. The "Flutter apps feel off" criticism from a few years ago feels less true now.

What's the biggest thing holding your team back from Flutter, or pushing you toward it?

I'm curious how everyone are navigating the current moment in Android.

Jetpack Compose has finally hit a point where I don't feel like I'm fighting the framework. The early days of fighting recomposition bugs and mystery performance issues feel mostly behind us. I'd say it's actually a better UI model than what we had with Views , it just took a while to trust it.

Kotlin Multiplatform is where I'm less sure. The pitch is compelling but I keep hearing mixed things about teams actually sharing business logic at scale. Anyone running KMP in production on a non-trivial app? What does the reality look like?

The on-device AI stuff is moving fast. MediaPipe and the Gemini Nano integrations are interesting, but I'm still trying to figure out where this actually belongs in app architecture vs just being a feature bolt-on. Offline-first apps with local inference feel genuinely useful for the right use cases, but the model size and battery tradeoffs are real.

Biggest thing I keep coming back to: developer productivity has improved a lot , better tooling, better language, better architecture guidance , but the fragmentation problem never really went away.

What's the thing you think is most under appreciated or underused in Android right now?

We've been debating this internally at GeekyAnts for new projects. Both are mature now, but the teams that use each tend to feel strongly.

Our rough breakdown after shipping 50+ Flutter apps:

Bloc camp likes:
- Explicit event/state separation makes code reviews easier
- Works great for complex flows with many transitions
- Easier to enforce in large teams (less creative freedom = less inconsistency)

Riverpod camp likes:
- Compile-time safety catches a whole class of runtime errors
- Much less boilerplate for simple features
- Easier to test in isolation

What we can't agree on: Riverpod's flexibility is either its best or worst feature depending on who you ask. Junior devs tend to misuse it; senior devs love it.

What's your team using in 2025? Has anyone switched from one to the other mid-project?

Kotlin Multiplatform in Production: What Teams Are Actually Running Into

As more teams push KMP into legacy migration territory, the real tradeoffs are becoming clearer.

SQLDelight migrations are painful. Teams migrating apps with years of Room-based schemas consistently report that migration scripts don't port cleanly. GeekyAnts (a Bangalore-based mobile consultancy) recently shared that they had to rewrite 14 migration scripts migrating a 6-year-old FinTech app — and this is a recurring theme in KMP postmortems community-wide.

BLE is still DIY. KMP has no native BLE abstraction, so anything hardware-facing falls into expect/actual territory fast. Most teams end up owning that wrapper layer themselves — a hidden cost in IoT or health-tech products.

iOS + Coroutines is the silent killer. The MainScope threading model doesn't map intuitively to iOS concurrency, and failures tend to be intermittent production crashes, not clean compile errors. SKIE and KMP-NativeCoroutines exist largely because so many teams hit this.

The wins are real though. GeekyAnts reported ~40% shared business logic and iOS feature parity compressing from weeks to days. That tracks with what other teams publish , Cash App and Philips have run KMP at scale with similar outcomes.

Not talking about calling an API. I mean a model actually running on the device, offline, in a real app that real users have installed.

Seen a lot of demos. Seen a lot of blog posts. But I'm struggling to find examples of this in actual production ,not a side project, not a research prototype.

Curious because model sizes, memory limits, and thermal throttling on mid-range devices seem like massive barriers nobody talks about seriously.

Have you shipped something like this? What model, what device floor did you target, and what broke first?

Text recognition? Works great. Object detection on-device? Solid. But the moment you try to do anything custom , like running a TFLite model with meaningful input preprocessing —,you're basically on your own.

Tried this with a client project and ended up writing more native platform code than Flutter code. The plugin ecosystem here just hasn't kept up.

Things that surprised me:

• No official way to pass byte arrays cleanly to TFLite
• Camera feed → model inference requires three different packages that barely cooperate
• Android vs iOS behavior diverges way earlier than you'd expect

Is this just me or is on-device AI in Flutter genuinely painful right now?

Been trying to actually understand what Gradle does under the hood instead of just trusting it. So I stripped everything back and built a basic Hello World APK using only the raw Android SDK tools from the command line , aapt2, javac, d8, apksigner, the whole pipeline manually.

No IDE. No build system. Just commands.

Honestly it's been the most useful thing I've done to understand Android builds. Some things that surprised me:

1. aapt2 does a LOT more than I thought. Compiling resources and generating R.java is its own whole step before you even touch your Java files.
2. d8 converting .class files to .dex is where "Android bytecode" actually becomes real.
3. Signing is not optional even for local testing ,I had to generate a debug keystore manually and sign with apksigner before adb would install it.

Next step is wiring Gradle into this same pipeline and watching it automate everything I just did by hand. Then finally Android Studio.

Anyone else gone down this rabbit hole? Would love to know if there are steps I missed or parts of the pipeline I misunderstood.

I've used both and honestly Koin feels faster to set up and debug for smaller apps. But my team keeps defaulting to Hilt just because Google recommends it. Has anyone actually run into a real problem with Koin at scale that pushed them to switch? Or is the Hilt preference more of a 'safe corporate choice' thing?

Hot reload is great until it isn't , I keep running into weird state bugs where a hot reload leaves the app in an inconsistent state and I have to full restart anyway. Is this just a 'skill issue' or do others deal with this constantly? Any patterns for structuring your app that make it more hot-reload-friendly

My Flutter app's APK is sitting at around 22MB for something that's honestly not that complex. I know Flutter bundles the engine but I wasn't expecting this. Has anyone gotten significant size reductions beyond the usual 'use flutter build apk --split-per-abi' advice? Feels like there should be more I can do.

I’m planning a mobile app for a startup idea and trying to understand the best development approach.

Some suggest going with a cross-platform framework like Flutter or React Native for faster MVP development, while others recommend native development for better long-term scalability.

For those who have built or worked on real-world apps, what approach worked best for you when balancing speed, cost, and scalability?

I’ve been working with Flutter for a while and have used Provider and Riverpod in a few small projects. I’m trying to understand what people prefer for larger production apps.

Some developers say Riverpod is more scalable, while others still stick with Provider for simplicity. I’ve also seen Bloc used in enterprise apps, but it feels a bit heavy for my current use cases.

For those who have worked on real-world Flutter apps, what state management approach do you prefer and why? Would be great to hear your experience with scaling apps.