From Flutter to Native: Challenges and Lessons — From a 1.6 Rating to 4.0
summary
A Flutter app converted to native Android crashed the app rating from 4.2 to 1.6 due to crashes, layout and font issues (including landscape bugs), missing error flows, poor Jetpack Compose recomposition handling, and an inefficient startup that created SharedPreferences 34 times. Recovery used Kotlin + Jetpack Compose with Material 3 components, unified API design via OpenAPI/YAML as a single source of truth, new map APIs that fetch region counts instead of all markers, frequent Slack feedback and in‑app review prompts to drive the rating back toward 4.0.
AI-written summary · about
chapters (11)
- 0:00Introduction
- 3:12Flutter app history
- 5:00Native migration reasons
- 8:17Native bugs and ratings
- 9:01Root cause analysis
- 15:51Dev improvements and Material 3
- 19:52Team collaboration and API
- 23:01Feedback groups and safety
- 31:13Store search performance
- 36:58Results and review fixes
- 38:46Summary
related talks
36mWhat I learnt by building the exact same app in Kotlin (Native Android), Nativescript and Flutter
33mShould We Flutter?
28mHow a Nearly-Naive Flutter Team Replaced a Native App with Flutter in Six Months
41mCross-Platform Fireside Chat
45mImpact of Framework Choice on your Application: A Reverse Engineering Perspective
34mProduction Fluttering
34mAndroid with a side of Flutter, please
39mFlutter for Android developers!