"I just subscribed to Rork Max — when can I publish the Android version?" That question keeps landing in my inbox. Here is the short answer: Rork Max emits SwiftUI, so it is iOS-only by design. There is no built-in path to generate an Android binary from the same Rork Max session today.
That is a deliberate scoping choice rather than a missing feature. Rork Max optimizes for shipping native-quality iOS apps as fast as possible. But it does not mean your Android plans are stuck — it just means you need to use the other tool in the Rork ecosystem, alongside Rork Max, when you want both platforms. I have been doing exactly that for my own indie apps, and this guide shares what I have learned the practical way.
Rork and Rork Max have different output targets
A lot of confusion comes from assuming the two tools are tiers of the same product. They are not.
- Rork (vanilla) outputs React Native + Expo. One codebase, both iOS and Android. Designed for cross-platform from day one
- Rork Max outputs SwiftUI. Pure native Apple code, iOS only
The Rork Max launch post explains the SwiftUI choice as a bet on shipping support for the latest Apple APIs (Apple Intelligence, WidgetKit, ARKit, Live Activities) on day one. React Native wrappers usually trail those APIs by weeks or months. Rork Max chose not to accept that lag — and the cost of that decision is that Android falls outside its scope.
For Android, you reach for vanilla Rork and let the React Native pipeline do the cross-platform work.
Three realistic strategies for indie developers
If you want both platforms, three practical paths show up in real projects:
Strategy 1: Use vanilla Rork to ship both platforms at once
Simplest by far. The chat session generates a React Native + Expo codebase, and you build for both iOS and Android with a single EAS Build command.
# Build iOS and Android in parallel on EAS cloud
npx eas build --platform all --profile production
# Or build them separately
npx eas build --platform ios --profile production
npx eas build --platform android --profile productionThis assumes you have already authenticated with Expo Application Services. The build runs on EAS infrastructure and emails you the download links for each platform when it finishes.
The win is obvious: one codebase, every feature lands on both platforms simultaneously, and for most indie apps this is plenty. The cost is that bleeding-edge iOS features (the newest WidgetKit additions, Live Activities variations, certain ARKit modes) wait for React Native wrapper support before you can use them.
Strategy 2: Run Rork Max for iOS and vanilla Rork for Android in parallel
This is the choice when iOS must feel native. You build the iOS app in Rork Max (SwiftUI), the Android app in vanilla Rork (React Native), and treat them as two implementations of the same product.
Implementing every feature twice is not actually the hardest part. The hardest part is keeping the spec in sync. UI flows, transition timings, copy, and onboarding ordering will drift between the two unless you decide upfront which decisions are platform-specific and which are universal.
In my own projects, I keep navigation patterns (push vs modal, back-button placement) aligned with each platform's conventions, but I lock down the core product logic — pricing tiers, payment flow, push notification copy — so that both versions behave identically there. That split has worked well.
Strategy 3: Ship iOS first with Rork Max, then Android with vanilla Rork
If shipping speed is everything, build the iOS version with Rork Max, get it on the App Store, watch what early users actually do, and only then start the Android version in vanilla Rork.
The economics often favor this. Even in markets where iOS and Android user counts are roughly equal, iOS monetization rates tend to be higher. Validating product-market fit on iOS first means you avoid spending Android development time on a product nobody is paying for.
That said, there are gotchas with this order — covered below.
Three things that bite you when adding Android later
If you go with strategy 3, here is what tripped me up:
First, billing implementations diverge sharply. iOS uses StoreKit 2; Android uses Google Play Billing Library. They are not just different APIs — the developer experience is different, the receipt validation is different, and the subscription state model is different. Vanilla Rork projects can wrap both behind react-native-iap or RevenueCat. SwiftUI code from Rork Max that calls StoreKit 2 directly does not port over.
Second, push notifications take more thought than expected. APNs (iOS) lets you control presentation styles in fine-grained ways. FCM (Android) uses a different payload structure, and rich notifications with images need a separate implementation path. Vanilla Rork using Expo Notifications papers over most of this; ported native code does not.
Third, UI primitives behave differently. A SwiftUI surface using .background(.ultraThinMaterial) has no direct Android equivalent. You end up rebuilding the look with Material 3 — androidx.compose.material3.Surface plus tonal elevation gets you close, but it is not a free translation. Vanilla Rork's React Native output sidesteps this because it generates UI that already considers cross-platform aesthetics from the start.
How I decide between the three
For most indie developers, my recommendation is strategy 1: just ship both platforms with vanilla Rork.
The reason is brutal but simple: time is the bottleneck for solo developers. One codebase means one place to fix bugs and one place to add features. The compounding effect over a year of maintenance is enormous.
Strategy 2 (the dual-build approach) is worth it only when iOS-only experiences are core to your business — Apple Vision Pro integration, full WidgetKit layouts, deep Apple Pencil support in a drawing app. If you can answer "would removing this feature kill the product?" with yes, then strategy 2 makes sense.
Strategy 3 (iOS-first) is the right call when you are launching a brand-new product and validating the idea matters more than launch-day platform parity. Spending three weeks building Android polish for an app nobody downloads is the worst use of indie time.
For pricing comparisons across the strategies, Rork Max Pricing 2026: An Indie Developer's Decision Guide walks through the cost models. If you are still weighing React Native against Flutter, Rork vs Flutter / React Native: 2026 Comparison has the breakdown.
Surprising Android wins worth knowing
A small note from launching Android versions: I was surprised by how often Android users requested home-screen widgets and app shortcuts. iOS WidgetKit gets the spotlight in marketing, but Android's widget culture is older and stickier. Users notice when you do widgets well.
In vanilla Rork on Android, combining expo-router deep links with app shortcuts noticeably improved review sentiment. Worth keeping in your back pocket if you are going Android-second.
Wrapping up
Subscribing to Rork Max does not lock you into iOS-only thinking. Treating Rork and Rork Max as complementary roles inside the same ecosystem — rather than as two competing products — multiplies what one developer can ship.
The one concrete step worth taking today: pick the app idea you are working on right now and ask, "is the iOS-native experience actually core to this product?" If the answer is no, vanilla Rork on both platforms is your fastest path. If the answer is yes, plan an iOS-first launch with Rork Max and budget the Android port for after you have early user signal.