Platforms
Native vs cross-platform app development Shared rules, native hands
Short answer
“Native” here means platform UI toolkits: Kotlin on Android, Swift and SwiftUI on iOS. “Cross-platform” on this site does not mean a React Native or Flutter UI. The cross-platform move RR Tech actually publishes is Kotlin Multiplatform: one core for product rules, native clients for the screens. Choose one platform if you can. Share the core if you cannot afford two sources of truth.
Founders hear “cross-platform” and picture half the cost. Sometimes that is true. Sometimes it means a lowest-common-denominator UI and a plugin matrix you will debug instead of your product. The only honest way to discuss it is to name the architecture.
Three different ideas people mash together
| Idea | What it usually means | What RR Tech publishes |
|---|---|---|
| Native UI | Android views / Compose or iOS SwiftUI, platform conventions | Android is Kotlin-first. iOS is Swift & SwiftUI. FCH is a native Android production app. |
| Shared business logic | One place for session rules, scoring, reminder parsing | Ghost Mode: KMP core across iOS and Android so rules do not drift. |
| One UI codebase for both stores | React Native, Flutter, and similar | Not advertised. We do not claim those stacks on this website. |
When native UI is the default
If v1 is one store, native is the short path: one toolkit, one store review, one set of platform quirks. Fantasy Cricket Hub did not need an iPhone client to prove live fixtures and form. Starting Android-only was the product decision.
Platform-specific jobs also push you native. Ghost Mode’s blocking and session loop is not a marketing site in a WebView. Even with a shared core, the hands on the glass are native clients.
When a shared core earns its keep
Ghost Mode’s published problem was two phones and one product law: duration, blocked apps, streak, Adaptive Sessions. Two unrelated codebases would have doubled the places a 20-minute session could mean something different. KMP is how that law stays one law. Timeline: 4 weeks, in production.
Shared core is not free. You still design two UIs. You still QA two binaries. You save the duplication that actually hurts: rules, validation, the meaning of “session.”
What we will not recommend from this site
- Picking Flutter or React Native because a blog said it is cheaper — we do not have those case studies here.
- Wrapping the website and calling it an app. FCH’s write-up is explicit: production Android, not a web wrapper.
- Sharing a core when there is no second platform in the proposal. That is architecture for a slide.
A practical sequence
- Name the first OS from real users (iOS vs Android).
- Ship that native client with a structure that can grow (how to build an MVP).
- If the second OS is now real demand, share the rules (KMP is the pattern we can point at) instead of cloning the first app by hand.
Web is a different fork: marketing sites and web applications on Next.js / React / TypeScript / Node / Tailwind. Public product case studies remain mobile. Do not force a phone job into a browser because “cross-platform” sounded cheaper.
Need both stores without two products?
If the job is one loop on two phones, we can talk about a shared core and native clients — the pattern Ghost Mode used. If you only have one phone in the room, we will not upsell a second OS.
If this matches the brief: mobile apps for iOS and Android · iOS app development · Android app development
Work Ghost Mode · Fantasy Cricket Hub
Related guides iOS vs Android App Development · How to Build an MVP · How to Choose an App Development Company