You've built a polished app in Rork Max—and now you're blocked by a code signing error, an ITMS validation failure, or an App Store review rejection. These are the most technically demanding parts of the app publishing process, and they have a reputation for being opaque.
EAS Build Code Signing Errors
Error Category 1: Certificate Issues
Symptom: Error: No matching signing credentials found for com.yourapp.bundleid
Your Apple Distribution Certificate isn't configured in EAS Credentials.
Resolution
Check your current credential state:
eas credentials
# Or view at: https://expo.dev/accounts/[username]/projects/[slug]/credentialsIf no certificate exists, let EAS manage it automatically—this is the simplest path:
// eas.json
{
"build": {
"production": {
"ios": {
"credentialsSource": "remote"
}
}
}
}Then regenerate:
eas credentials --platform ios
# Select "Remove credentials" → then "Set up credentials"Symptom: Certificate has expired or is not yet valid
Apple Distribution Certificates are valid for one year. This error means yours has expired.
eas credentials --platform ios
# Navigate to "Distribution Certificate" → "Generate new certificate"You may also need to delete the expired certificate from the Apple Developer Console first to avoid conflicts.
Error Category 2: Provisioning Profile Issues
Symptom: Provisioning profile doesn't match the bundle identifier
The app's Bundle Identifier in app.json doesn't match the profile.
# Verify in app.json
# ios.bundleIdentifier must exactly match what's in Apple Developer Console
# Regenerate the provisioning profile
eas credentials --platform ios
# → "Provisioning Profile" → "Create a new provisioning profile"Symptom: Device is not included in the provisioning profile (development builds only)
The test device's UDID isn't registered in the provisioning profile.
# Register the device
eas device:create
# Sync devices into provisioning profile
eas credentials --platform ios
# → "Provisioning Profile" → "Sync devices from Apple portal"Error Category 3: App Store Connect API Key
EAS needs an App Store Connect API key to automatically upload builds. Without it, you'll get authentication errors during the submit step.
Set up the API key
1. Go to https://appstoreconnect.apple.com/access/api
2. Click "+" to create a new key
3. Name: "EAS Build" (or similar), Role: "App Manager"
4. Download the .p8 file — this can only be downloaded once
5. Copy the Key ID and Issuer ID
eas credentials --platform ios
# → "App Store Connect API Key" → "Add an API key"
# Enter: path to .p8 file, Key ID, Issuer IDApp Store Connect Submission (ITMS) Errors
After a successful EAS Build, the upload to App Store Connect can still fail with ITMS errors.
Common ITMS Errors
ITMS-90725: Minimum SDK version not met
App Store's current minimum deployment target requirement isn't satisfied.
// app.json — update to current Apple requirement
{
"expo": {
"ios": {
"deploymentTarget": "16.0"
}
}
}ITMS-90426: Invalid code signing entitlements
The entitlements in your binary don't match what's configured in your App ID.
Open the Apple Developer Console, find your App ID, and verify that every capability your app uses (Push Notifications, In-App Purchases, Sign in with Apple, etc.) is enabled there. Mismatches cause this error.
ITMS-90161: Swift version too old
The build toolchain is outdated. Update your EAS build image:
// eas.json
{
"build": {
"production": {
"ios": {
"image": "latest"
}
}
}
}App Store Review Rejections
A successful upload doesn't guarantee approval. Here are the most common rejection categories and what to do about each.
Guideline 4.x: Design and Functionality Rejections
4.2 / 4.3: Minimum Functionality
Apple considers the app to have insufficient unique value or functionality. Apps built with Rork Max that are very simple or closely mirror an existing website are at risk.
The most effective response is to incorporate at least one meaningful native capability—push notifications, camera access, location services, or on-device processing. Update the App Review notes to clearly articulate the app's unique value and use case.
Crash During Review
An immediate rejection. Any crash during the review process results in a 4.2 rejection. Test thoroughly on a physical device before submitting. Use the distribution build (not the development build) for final testing.
Guideline 5.x: Legal and Content Rejections
5.1.1: Privacy Policy Missing or Inaccessible
Any app that collects user data—including analytics, advertising, or even crash reporting—requires a privacy policy URL. This must be a live, accessible URL, not a placeholder.
5.1.2: Vague Permission Descriptions
Usage description strings in Info.plist must specifically explain why the app needs the permission.
// app.json — specific, honest permission descriptions
{
"expo": {
"ios": {
"infoPlist": {
"NSCameraUsageDescription": "Used to take and upload your profile photo",
"NSLocationWhenInUseUsageDescription": "Used to show nearby locations relevant to your search"
}
}
}
}Descriptions like "required for app functionality" are no longer accepted.
Pre-Submission Checklist
Run through these before every production submission.
Technical validation Test on a physical iPhone and iPad. Zero crashes across all screens. All network requests succeed or fail gracefully. App functions without an internet connection where expected.
Content review Privacy policy URL is live and accurate. App description matches actual functionality. Screenshots reflect the current UI (not old designs). Age rating is appropriate for the content.
App Store Connect configuration Category is accurate (affects discoverability). Pricing and regional availability are set correctly. Promotional text and what's new section are complete.
Responding to Rejections
When a rejection arrives, find the specific guideline number in the Resolution Center notification in App Store Connect. This tells you exactly what needs to change.
Address the issue and explain your fix in the Resolution Center before resubmitting. If the rejection reason is unclear, you can ask for clarification directly through the Resolution Center—Apple's review team does respond.
For Guideline 4.x rejections, a phone call through the Apple Developer Program support line often resolves ambiguity faster than message-based back-and-forth.
Looking back
App Store publishing failures with Rork Max fall into three phases: EAS Build code signing, App Store Connect upload validation, and App Store review.
Code signing errors are almost always credential configuration problems—regenerating certificates and provisioning profiles through eas credentials resolves most of them. ITMS upload errors come from mismatches between your build settings and Apple's current requirements—update deploymentTarget, build images, and entitlements to match. Review rejections require reading the specific guideline cited, making a targeted fix, and communicating clearly what you changed.
When you're stuck, paste the exact error message into Rork and ask what it means and how to fix it. The combination of this guide and Rork's AI response gets most issues resolved without needing external help.