When a Rork app is ready to ship, the tempting move is to do iOS first, Android later. I made that decision on my first app. On the second one, I tried going to both stores at once — and hit enough friction that I think it's worth writing down exactly what happened.
Rork's cross-platform support is real. The code runs on both platforms without much change. The friction shows up in the submission process, not in the app itself.
Screenshot Specs Are Surprisingly Different
The first thing that slowed me down was screenshots. App Store and Google Play have different requirements, and the gap is bigger than you'd expect.
Apple requires at least one screenshot matching a 6.7-inch iPhone (iPhone 15 Pro Max dimensions). If your app also supports iPad, you need those screenshots too. Google Play requires at least one screenshot and a Feature Graphic — a 1024×500px banner that appears in search results and category listings.
The screenshots from Rork Companion running on a 6.1-inch iPhone don't satisfy Apple's 6.7-inch requirement. You'll need to either grab screenshots from an iPhone 15 Pro Max (or the Simulator at that resolution) or resize your existing screenshots in Figma. Neither option is hard, but it's time you weren't expecting to spend.
The Google Play Feature Graphic is easy to skip — the form doesn't mark it as required — but without it, your listing looks noticeably less polished in search results. Worth making one before you submit.
Android's Target SDK Level Matters
Google Play requires new apps to target Android 14 (API Level 34) or higher as of 2026. Since Rork is built on Expo, apps created with recent templates should already satisfy this. The issue comes with older projects or templates that were created when the threshold was lower.
Before you kick off an EAS Build for Android, confirm what's in your app.json:
{
"android": {
"targetSdkVersion": 34,
"minSdkVersion": 24
}
}If targetSdkVersion is set to something like 31 or 33, your Play Store submission will be rejected. Updating it and rebuilding adds time to your release cycle — time you don't want to burn if you're trying to ship to both stores on the same day.
iOS Privacy Manifest Is Not Optional
Since iOS 17, Apple requires apps to include a privacy manifest (PrivacyInfo.xcprivacy) declaring which system APIs they use. This covers camera, microphone, location, and photo library access — but also lower-level things like UserDefaults, which many apps use without thinking of it as a "privacy-sensitive" API.
The React Native libraries that Rork generates often include third-party dependencies with their own API usage. If your privacy manifest doesn't account for these, App Store review will flag it.
The practical approach is to run your EAS Build and watch for privacy manifest warnings in the output. Rork Max users can also check Rork's support channels for the most current template configuration. Better to catch this before review than after.
Review Timing Doesn't Line Up
App Store review typically takes 24–48 hours, though first-time submissions or apps with significant new functionality can take longer. Google Play is sometimes faster on repeat submissions, though initial review can take a few days.
When I tried to release simultaneously, my App Store review completed two days before Google Play finished. The iOS app was live on the App Store before Android was approved — not exactly simultaneous.
If aligned launch timing matters to you, use the App Store's "Manual Release" option in App Store Connect. This lets you hold the iOS app in an approved state and release it manually when you're ready — for example, once Google Play also approves. It's under the "Version Release" section when you create your app version.
Data Safety and Privacy Questions Are Separate Forms
App Store Connect has its own privacy questionnaire. Google Play has a Data Safety form. They ask about similar things — what data you collect, how you use it, whether you encrypt it — but they're filled out separately and don't cross-populate.
The question that catches people off guard on the Google Play side is around data deletion. Google asks how users can request deletion of their data. If your app collects any user data (even just account creation) and you don't have a documented process for handling deletion requests, it can flag during review.
Worth thinking through before you start filling out the forms, rather than while you're doing it.
After Launch: Crash Monitoring on Both Platforms
Once both apps are live, you're looking at two separate crash reporting streams. App Store Connect has a Crashes tab; Firebase Crashlytics or Sentry give you a unified view across both platforms.
React Native apps share most of their code, so a crash on one platform often means a crash on the other. But native module behavior, OS version differences, and hardware-specific issues can produce platform-specific crashes that won't show up in the other store's data.
The first 48 hours after launch are the window where most early crashes surface. Checking both dashboards once a day during that period keeps you ahead of anything that needs a fast hotfix.
Both Stores Is 1.3x the Work, Not 2x
The actual code for a Rork app is shared across iOS and Android — that part is free. The extra work for dual-platform submission is mostly about store assets (screenshot specs, feature graphics), configuration (SDK targets, privacy manifests), and timing management (review windows, manual release options).
Once you've been through it once, the pattern becomes clear and the second launch goes much faster. The first time, budget an extra day or two compared to a single-platform release. The things that trip you up aren't the same as building the app — they're the operational details around submission.
If you haven't shipped to both platforms yet, the best way to learn the specifics is to try it on a small app where the stakes are low. The surprises are manageable, and the dual-platform reach is worth it.