Home

Tech

What we think

Why Redpapr Chose Jetpack Compose & SwiftUI Over React Native or Flutter

Go Back

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:

  1. Minimal app size—especially critical for learners on limited storage.
  2. Fast, seamless UX—even on low-end or older devices.
  3. 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.