TL;DR
To publish on the Apple App Store you need: (1) Apple Developer Program membership ($99/year), (2) a signed build uploaded to App Store Connect, (3) TestFlight if you want beta testing, and (4) a complete App Store listing + privacy disclosures, then submit for review. Apple states that on average 90% of submissions are reviewed in less than 24 hours, but incomplete submissions can be delayed.
If you set this up once, you can automate most of it with Fastlane or Expo EAS (build + submit), turning future releases into a repeatable pipeline.
The hard truth about App Store deployment
You don’t need a developer to submit an app. You need (a) patience, (b) attention to detail, and (c) a consistent signing/build workflow.
Where founders usually fail:
- signing identity is inconsistent (wrong bundle ID/cert/profile chain)
- privacy disclosures don’t match the SDKs/features actually used
- metadata is incomplete (support URL, screenshots, demo account)
- the app feels like a repackaged website (minimum functionality)
Apple’s App Review page explicitly warns review may be delayed or fail if the submission is incomplete.
Prerequisites: what you need before you start
1) Apple Developer Program membership ($99/year)
Apple states the Apple Developer Program is $99 USD per membership year (local currency may vary).
2) A build you can upload
You need a signed iOS build that can be uploaded to App Store Connect (whether it’s produced locally, by a contractor, or via cloud build). Apple documents “Upload builds” methods in App Store Connect help.
3) Store assets (don’t start without these)
- App icon: 1024×1024 PNG
- Screenshots for the device families you support
- Short + long description, subtitle
- Support email + support URL
- Privacy Policy URL
- Privacy disclosures (what data you collect + how it’s used)
Apple requires you to provide privacy practice information (including third-party partners’ code you integrate) in App Store Connect.
Step 1: Certificates, IDs, profiles (the annoying part)
What these are (simple model)
- Certificate: proves the publisher identity
- App ID / Bundle ID: your app identity (e.g.,
com.company.app) - Provisioning profile: ties certificate + app identity + distribution type
Fast path vs manual path
Option A — Xcode automatic signing (if you have a Mac)
Xcode can manage signing automatically for your team.
Option B — Managed signing via build platform (if you don’t have a Mac)
If you’re using Expo EAS or a managed mobile builder, you can avoid most manual CSR/profile setup and keep signing consistent across builds.
Step 2: Building your app (Mac vs no Mac)
If you have source code (React Native)
High-level reality: building iOS locally typically requires macOS tooling. If you’re non-technical, your realistic choices are:
- cloud build (Expo EAS Build)
- CI with macOS runners
- contractor generates the build for you
If you don’t have a Mac (recommended path for non-technical founders)
Expo EAS Build + EAS Submit is explicitly designed to build and submit app binaries from the command line using a hosted service.
Important correction: do not claim “$29/month unlimited builds.” Expo’s pricing includes plan credits and then usage-based billing.
Practical commands (example):
npm install -g eas-cli
eas build --platform ios
eas submit --platform ios
Expo documents EAS Submit as a hosted service for uploading/submitting binaries to the app stores.
Step 3: TestFlight (beta testing)
Why use TestFlight
- catch crashes and onboarding issues before public users
- test on real devices and OS versions
- share a build without App Review for every internal iteration (depending on your workflow)
Tester limits (sourced)
Apple states you can invite up to 10,000 external testers per app.
Apple’s TestFlight overview also states you can add up to 100 internal testers (App Store Connect users with access).
TestFlight setup (step-by-step)
- Go to App Store Connect → My Apps → New App
- Create the app record (name, bundle ID, SKU)
- Upload a build to App Store Connect (Xcode/Transporter/CI/EAS Submit path)
- Open TestFlight tab
- Add internal testers first
- For external testing: create an external group, add the build, invite testers (email or public link)
Apple documents external testing workflow and limits in App Store Connect help.
Step 4: App Store submission (the part that actually gets you approved)
Required fields you must get right
App Store Connect listing includes:
- App Information: name, subtitle, categories
- Pricing and Availability
- App Privacy details (data collection + tracking disclosures)
- Screenshots and (optional) preview video
- Support URL + Privacy Policy URL
- Build selection (choose the build you uploaded)
Privacy disclosures are not optional. Apple states you must provide privacy practice info including third-party partners’ code integrated in the app.
Step 5: App Review (timelines + what they check)
Review timeline (sourced)
Apple states: “On average, 90% of submissions are reviewed in less than 24 hours.”
Apple also notes incomplete submissions can be delayed or may not pass review.
What Apple checks (practically)
- crashes and broken flows
- misleading metadata (screenshots don’t match)
- privacy disclosure accuracy
- minimum functionality (especially “repackaged website” risk)
Step 6: Handling rejection (normal process)
When rejected:
- read the reason carefully
- open Resolution Center in App Store Connect
- fix the exact issue
- resubmit If you think Apple is wrong: appeal with factual evidence and keep it short.
Step 7: Post-launch maintenance
Every update repeats the same loop:
- upload a new build
- (optional) TestFlight sanity check
- submit update
- review
- release
What to monitor:
- crash rate spikes
- ratings drop patterns
- repeated complaints that indicate a broken flow
Automation: stop doing this manually
Option 1: Fastlane (open source)
Fastlane’s upload_to_testflight (Pilot) automates uploading and distributing builds via App Store Connect.
Example lane concept (high-level):
- build
- upload to TestFlight
- optionally submit metadata
Option 2: Expo EAS (build + submit)
Expo documents EAS Submit as a hosted service to submit binaries to Apple App Store and Google Play Store using EAS CLI.
Option 3: CI/CD (GitHub Actions / other CI)
Best when you want: “push code → pipeline builds → pipeline uploads → pipeline notifies.”
Android (the easier comparison)
Google Play Console requires a $25 one-time registration fee.
Process: create listing → upload .aab → complete policy forms → submit for review. (Review times vary; don’t promise a fixed number.)
Costs breakdown (corrected)
Required:
- Apple Developer Program: $99/year
- Google Play Console: $25 one-time
Optional:
- Expo EAS: plans + credits + usage-based pricing (not “unlimited $29”)
- Fastlane: free/open-source automation
Tools that handle this for you (so you don’t live in certificates)
- Hire a deployment specialist (one-time setup) They configure signing + upload + automation. You keep ownership of the Apple account.
- Use Expo EAS Build + Submit Cloud build + store submission from CLI.
- Use a mobile-first builder that outputs real native code + a deployment path This matters because web-only builders do not solve App Store deployment.
Final checklist (copy/paste)
Before you start:
- Apple Developer Program membership active ($99/year)
- Build path decided (contractor / EAS / CI / Mac)
- Icon 1024×1024, screenshots, descriptions ready
- Support URL + Privacy Policy URL ready
- App privacy disclosures prepared (including SDK partners)
Deployment steps:
- Create the app record in App Store Connect
- Ensure bundle ID + signing identity are consistent
- Upload a build to App Store Connect
- TestFlight: internal testers, then external if needed (up to 10,000 external)
- Complete metadata + screenshots + privacy disclosures
- Submit for review (expect most reviews <24h on average, but delays happen)
- If rejected: fix exactly what’s flagged, resubmit
Post-launch:
- automate (Fastlane or EAS Submit)
- monitor crashes/ratings
- update privacy disclosures when SDKs/features change
Closing
If you’re a non-technical founder, the real cost isn’t “submission.” It’s the weeks lost to broken signing, unstable builds, and unclear deployment paths.
If you want to ship native apps without living in toolchains, use a builder that is explicitly mobile-first and outputs maintainable React Native code with a clean route to builds and store submission.
Bilt is built for that: native React Native output (not a web wrapper), fast iteration, and a deployment-oriented workflow so you can go from “idea” to “TestFlight/App Store submission” without rebuilding everything by hand.
Frequently Asked Questions
Do I need a Mac to publish iOS apps?
Not strictly — but it depends on how you build.
- If you build locally with Xcode, you need macOS.
- If you use a cloud build service (for example, Expo EAS Build), you can generate and submit iOS builds without owning a Mac.
- If you hire someone or use a mobile-first builder that handles signing and build pipelines, you may never need a Mac directly.
The requirement is not “own a Mac.” The requirement is: your app must be compiled and signed in a macOS environment at some point.
How long does App Store review take?
Apple states that on average, 90% of submissions are reviewed in less than 24 hours.
Source: Apple App Review page.
https://developer.apple.com/distribute/app-review/
However:
- First-time submissions may take longer.
- Incomplete metadata or privacy disclosures delay review.
- Holidays and major iOS releases can slow things down.
Plan for 24–48 hours. Do not promise launch-day approval publicly.
How many TestFlight testers can I invite?
Apple allows:
- Up to 100 internal testers (App Store Connect users on your team)
- Up to 10,000 external testers per app
Source: Apple TestFlight documentation.
https://developer.apple.com/testflight/
External testing may require a brief review by Apple before testers can install the build.
Can I publish an app without TestFlight?
Yes.
TestFlight is not technically required for public release. You can upload a build and submit it directly for review.
However, skipping TestFlight increases rejection risk because:
- You may miss crashes.
- You may miss broken onboarding flows.
- You may miss device-specific bugs.
Best practice: run at least internal TestFlight testing before submission.
Why does Apple reject apps for “Minimum Functionality” (Guideline 4.2)?
Apple’s App Store Review Guidelines state that apps must provide value beyond a simple repackaged website.
Common triggers:
- WebView-only apps with no native interaction.
- Apps that duplicate existing content without added value.
- Template apps with minimal differentiation.
If your app is essentially your website inside a wrapper, rejection risk increases.
Guidelines reference:
https://developer.apple.com/app-store/review/guidelines/
What is the most common reason apps get rejected?
From real-world patterns, the most common issues are:
- Crashes or broken flows
- Privacy disclosure mismatches
- Incomplete metadata
- Minimum functionality concerns
- Missing demo accounts for login-based apps
Apple also warns that incomplete submissions may delay review or fail approval.
https://developer.apple.com/distribute/app-review/
How much does it actually cost to publish an app?
Minimum required cost:
- Apple Developer Program: $99/year
- Google Play Console: $25 one-time
Optional costs:
- Cloud build tools (depends on provider plan/usage)
- CI/CD setup
- Freelancer deployment help
You can publish for under $150 if you handle the process yourself.
Can I update my app after it’s approved?
Yes.
Every update:
- Requires a new build upload
- Goes through review again
- Can include metadata changes
Updates are usually reviewed faster than first-time submissions.
Can I automate App Store deployment?
Yes.
After your first successful release, you can automate:
- Build generation
- TestFlight upload
- App Store submission
Common tools:
- Fastlane (open-source automation)
- Expo EAS Submit (hosted submission service)
- CI/CD pipelines (GitHub Actions, etc.)
Once configured, deployment becomes repeatable and takes minutes instead of hours.