Rork Max gets you to a working app fast. The submission process is where the friction shows up — and it's a specific mix of React Native paperwork and AI-generated code quirks that standard publishing guides don't cover.
This is the checklist I work through before submitting any Rork Max-generated app. It's built from rejection patterns I've seen repeatedly.
App Store Submission Checks
Privacy Permissions in Info.plist
This is the most common rejection cause. Rork Max generates camera, location, and photo library access code correctly, but the corresponding Usage Description strings in Info.plist are often missing or too vague:
<!-- Info.plist — all of these must be present if used -->
<key>NSCameraUsageDescription</key>
<string>Used to capture your profile photo</string>
<key>NSPhotoLibraryUsageDescription</key>
<string>Used to select photos from your library</string>
<key>NSLocationWhenInUseUsageDescription</key>
<string>Used to show nearby locations in the app</string>The reverse is also a rejection: if Info.plist declares permissions for features that aren't implemented, Apple will reject for "excessive permissions." Run:
grep -r "NSCamera\|NSPhoto\|NSLocation" ios/…and verify each declared permission maps to actual code that uses it.
App Tracking Transparency (ATT): If you're using AdMob (which Rork Max can set up), ATT permission request flow is required on iOS 14.5+. This step is easy to skip when focused on the main app flow — don't.
Privacy Policy URL
Nearly every App Store category requires a publicly accessible privacy policy URL. Apps get stuck at the submission form if this isn't ready. Have at minimum a minimal-but-valid policy hosted and available before you start the submission process.
Screenshot Requirements (2026)
- iPhone: 6.9-inch (iPhone 16 Pro Max) or 6.7-inch screenshots required
- iPad: Required if the app supports iPad
- Localization: If the app is localized, localized screenshots may be required per market
Rork Max's in-app preview doesn't produce App Store-compliant screenshot dimensions. Use the iOS Simulator with the correct device selected and take screenshots from there.
Build Number Management
EAS Build handles the build process, but build number incrementation is your responsibility:
// app.json
{
"expo": {
"version": "1.0.0",
"ios": {
"buildNumber": "1" // Must increment on every submission
},
"android": {
"versionCode": 1 // Same requirement
}
}
}Submitting with a duplicate build number fails immediately. The cleanest solution is to let EAS auto-increment:
eas build --platform ios --auto-submit --non-interactiveGoogle Play Submission Checks
Target API Level
Google Play has an enforced minimum target API level that updates annually. As of 2026, API level 34 (Android 14) or higher is effectively required for new submissions.
// app.json
{
"expo": {
"android": {
"targetSdkVersion": 34
}
}
}Rork Max sometimes generates apps with older API levels. Always verify this before building for submission.
Permission Minimization
Google Play flags apps that declare more permissions than they actually use. Check android/app/src/main/AndroidManifest.xml and remove any permissions that aren't actively used:
<!-- Remove if not actually used -->
<!-- <uses-permission android:name="android.permission.READ_CONTACTS" /> -->
<!-- <uses-permission android:name="android.permission.CAMERA" /> -->Rork Max tends to generate with permissions included "just in case." Go through them and remove any that don't map to a feature you're shipping.
Data Safety Section
The Data Safety section in Google Play Console is required and must accurately reflect what your app collects. Rork Max commonly sets up Firebase Analytics, AdMob, and Google Sign-In — all of which require specific disclosures:
- Firebase Analytics → Device ID collection, analytics purpose
- AdMob → Advertising ID collection, advertising purpose
- Firebase Crashlytics → Crash log collection, app functionality purpose
Inaccurate Data Safety declarations can result in removal after approval, which is worse than a rejection.
Both Stores: Critical Checks
API Key Exposure
Rork Max occasionally hardcodes API keys directly in generated code. Check before pushing to any public repository:
// ❌ What sometimes appears in generated code
const API_KEY = "AIzaSy...actualkey...";
// ✅ What it should look like
const API_KEY = process.env.EXPO_PUBLIC_API_KEY;Use .env files locally (git-ignored) and EAS Secrets for CI/CD builds:
eas secret:create --scope project --name EXPO_PUBLIC_API_KEY --value "your-actual-key"GitHub's secret scanning will catch exposed keys and alert you — but better to catch it before the push.
Device Testing Before Submission
Simulator-green doesn't mean device-green for React Native apps. Before submitting, test on a physical device for:
- Any native feature (camera, location, Bluetooth, biometrics)
- Offline behavior — does the app degrade gracefully?
- Layout on devices with different screen sizes (notch, Dynamic Island)
EAS Build Log Review
eas build --platform all --profile productionEAS will show a "success" status even when the build log contains warnings about deprecated APIs. Check the full log. Deprecation warnings are tomorrow's crashes when OS versions advance, and it's much easier to fix them before shipping than after.
One Thing That Catches People After Submission
Hermes engine compatibility: React Native uses Hermes by default, and most packages support it — but not all. If you're seeing post-launch crashes that look unrelated to your code changes, check whether any npm package in the stack has Hermes compatibility issues. It shows up in crash reports as Hermes stack frames.
Rork Max gets you past the hardest part — the app itself. But the submission layer has enough required detail that it's worth treating as its own project phase. Once you've been through it once or twice, it becomes routine — and this checklist is the shortcut to that second time feeling faster than the first.