The Problem

Deploying a web app: git push. Done.

Deploying a mobile app:

1. Build the iOS binary (code signing, provisioning)
2. Build the Android binary (keystore, signing)
3. Generate screenshots for 6+ device sizes
4. Write App Store metadata (title, description, keywords, categories)
5. Write Google Play metadata (different format)
6. Upload builds to App Store Connect
7. Upload builds to Google Play Console
8. Fill out content ratings questionnaire
9. Fill out export compliance
10. Fill out privacy questionnaire
11. Submit for review
12. Wait 1-7 days
13. Get rejected → fix → resubmit
14. Repeat

That's 14 steps minimum. Each one has sub-steps. Each one can fail.

The Real Friction

Two Different Stores, Two Different Processes

Apple and Google have completely different:

• Metadata formats
• Screenshot requirements
• Review processes
• Rejection reasons
• Update frequencies

You're maintaining two parallel submission pipelines.

No Rollback

Unlike web deployment, you can't roll back a mobile release instantly. A bad update means:

• Emergency fix
• New build
• New submission
• New review wait
• 2-7 more days

Screenshot Generation

Both stores require screenshots in multiple device sizes. For iOS alone:

• 6.7" (iPhone 15 Pro Max)
• 6.1" (iPhone 15)
• 5.5" (iPhone 8 Plus)
• 12.9" iPad Pro

That's 4 sets × however many screens you want to show.

How AI App Factory Handles It

# One command: build, sign, submit to both stores
pnpm deploy:all

The 8 automation scripts handle:

• Platform-specific builds via EAS
• Code signing and credential management
• Screenshot generation
• Metadata templates
• Store submission API calls

14 manual steps → 1 command.

Related

• Code Signing Hell — the signing part of deployment
• App Store Rejection — what happens after submission
• Expo EAS Build — the build tool