Why Redpapr Chose Jetpack Compose & SwiftUI Over React Native or Flutter
When it came time to build Redpapr’s mobile app, we faced a familiar dilemma: cross-platform convenience vs. native performance.
Flutter, React Native, and other frameworks promised “write once, run anywhere.” But we’ve always believed in doing what’s best for our learners—even if it means more effort on our side.
That’s why we chose to go fully native with Jetpack Compose for Android and SwiftUI for iOS.
Our Goals
We had 3 clear priorities:
- Minimal app size—especially critical for learners on limited storage.
- Fast, seamless UX—even on low-end or older devices.
- Clean, modern codebases—easy to maintain and iterate on.
After months of prototyping and testing, Compose + SwiftUI came out ahead.
The Problems with Cross-Platform Frameworks
We explored Flutter, React Native, and even Kotlin Multiplatform Mobile (KMM). Each had strengths—but also some serious tradeoffs.
🧱 Bloat
- Flutter apps often ship with large runtimes (~10–20MB baseline), even for simple UIs.
- React Native brings its own JS engine, plus third-party native bridges that can quickly balloon in size.
For Redpapr, every megabyte counts—especially in bandwidth-constrained regions.
🐢 Performance Gaps
- Smooth scrolling? Gesture response? Subtle animations? Cross-platform UIs often lag on low-end devices.
- Bridging to native APIs introduces complexity and latency—especially with offline features or background tasks.
We wanted an experience that felt snappy and native everywhere.
🧩 Complex Dev Environments
- React Native and Flutter require extra tooling layers—Metro bundler, Dart SDK, native modules, etc.
- Debugging becomes harder. CI/CD pipelines get more complex. Teams spend more time fixing build issues than shipping features.
We wanted less friction, not more.
Why Compose + SwiftUI Are Better (For Us)
✅ Modern Native Frameworks
Jetpack Compose and SwiftUI bring a declarative, reactive programming model without sacrificing platform features or performance. You get the best of both worlds:
- Native APIs and tooling
- Fast build times with previews
- Unified UI logic and state handling
- Clean, readable codebases
🎯 Designed for Today’s Devices
Both frameworks were designed from the ground up for modern UIs, and:
- Run lean on memory and CPU
- Play nice with existing navigation, accessibility, and native sensors
- Offer tight integration with platform conventions
This makes a huge difference in the learner experience—especially on entry-level Android phones or older iPhones.
💼 Yes, Two Codebases—but Worth It
Managing separate Android and iOS projects does mean:
- More testing
- More coordination
- More upfront effort
But we gain:
- Total control over UX per platform
- Zero compromise on speed or polish
- Fewer bugs caused by abstraction mismatches
It’s a tradeoff we’re happy to make.
Real-World Impact
Since moving to Compose + SwiftUI:
- 📉 App sizes dropped by 30–50% compared to Flutter builds
- 🚀 Launch times improved noticeably on older phones
- 🧪 Development felt faster and cleaner thanks to native tooling
- 🙌 Users reported smoother experiences—especially around animations, input, and offline use
Conclusion: Native Is the Right Choice—for Redpapr
We’re not against cross-platform frameworks—they’re great for many teams.
But for Redpapr’s mission—building a lightweight, beautiful, and reliable learning app for all devices—Compose and SwiftUI are simply a better fit.
Two codebases. One goal: an uncompromised experience for every learner.
Got questions about our mobile architecture or how we ship native updates efficiently? Drop us a message—we’re happy to share what we’ve learned.