How to Publish an AI-Built iPhone App to the App Store

Last week, we showed you how we built more than 15 apps with AI.

This guide covers the next, less glamorous milestone: letting somebody else install one.

Corey and Grant walked through the process during The Neuron Live, using real apps, App Store Connect, TestFlight, Codex, Claude Code, and Expo's EAS tools.

Watch the full livestream on YouTube

So these days, launching your own app from scratch means using a coding agent that can write much of the software, prepare the assets for you, configure a build for you to test, and guide you through Apple's quagmire of forms. You still own the final decisions about security, privacy, pricing, and what the app actually does. The agent does the rest.

How, you ask? Well, that's what this guide is for!

We split this guide into two layers. First, there is a compressed runbook with the accounts, downloads, and dashboards linked exactly when you need them. After that comes the full walkthrough, including the prompts, technical explanations, and different release paths.

One important caveat: the App Store is a distribution choice, not the definition of a finished product. A website or Chrome extension may be the faster and safer destination for your first version. The right finish line is the simplest one that lets a real person use the product.

Before you start: open these accounts and downloads

You will not use every tool immediately, but opening these links now will save you from hunting for them halfway through the release:

• Apple Developer Program: The paid Apple membership ($99/year) required to distribute an iPhone app publicly. A free Apple Account is enough to use Xcode and test on your own device, but App Store submission requires the paid program.
• Codex or Claude Code starter guides: A coding agent is an AI tool that can inspect your project, edit files, run commands, and test its work (We recommend the Claude destkop app for using Claude Code, and Codex for ChatGPT, which is in ChatGPT Desktop app, just toggle the button that says ChatGPT to Codex).
• • We recommend the $100 Max (Claude) or $100 Pro (ChatGPT) tier for this.
• GitHub: The cloud-based home for your code (housed in what are called repositories, or repos) and its version history. GitHub gives you a safe checkpoint before release changes begin.
• Xcode: Apple's free Mac app for building, testing, signing, and uploading software. It includes Simulator, which behaves like a virtual iPhone on your Mac.
• Expo and EAS: Use these when your app was built with Expo or React Native. EAS, short for Expo Application Services, can build and sign the iPhone app on a cloud Mac. Claude / Codex can help you set these up in the plan stage depending on what you're trying to do.
• App Store Connect: Apple's web dashboard for your app record, uploaded builds, TestFlight testers, screenshots, privacy answers, App Review, and release status. The App Store Connect mobile app is optional.
• TestFlight: The free Apple app that you and your testers install to try the exact beta build uploaded to Apple.

That's not so bad, right? For those penny pinchers (like me) at home counting the fees, that's $200 upfront and you can publish a basic version of your app, that YOU fully control (unlike other paid services that do this for you), in about a month.*

*Why the asterisk? Well, you also have to have an Apple device. We recommend buying an old M1 or other affordable pre-owned M-series device (year 2020 Mac model onward) for $400 (which is what Corey paid) or as cheap as you can get it, really.

First up, the TL;DR

Here is the full process in ten (not so simple, ask your agent for help) steps.

1. Choose the right release path. Share your idea with Codex or Claude Code, and ask it to make a plan. As part of the plan, ask whether it recommends the product should ship as a web app, Chrome extension, iPhone app, direct-download Mac app, or Mac App Store app. If you have strong opinions here, share them.
2. 1. Pro tip: Pick the simplest route (extension > website > desktop app > mac app) that matches what the product actually needs.
2. Freeze the smallest useful version. Maybe you already have an app prototype, or maybe you're still in the idea stage. Once you have a v1 mvp (minimum viable prototype), stop adding features. The idea is to prove one complete user journey works (more on that below). Save that working version in a GitHub repository, which is a project folder with a permanent history of every saved change.
3. Test it yourself. On your Mac, install Xcode and run the app in Simulator, then install it on a physical iPhone. If the project uses Expo or React Native (depending on what you're doing, the model may recommend this for you; that's what it usually does for Grant), create an Expo account, install the EAS command-line tool, and let EAS prepare a development build (which is a complete version of your app you can test).
4. 1. Weird term alert: A command-line tool is simply software you control by typing instructions into Terminal instead of clicking buttons.
4. Review security and privacy. Have the coding agent inspect exposed passwords, API keys, permissions, data storage, outside services, error handling, and anything that could lose user information BEFORE you try to ship it is key. Fix any "release blockers" like these before creating screenshots or store copy.
5. Create the Apple records. Join the Apple Developer Program using the Apple Account that should permanently own the app. Then open App Store Connect and create the app record, which is the empty store entry that will later hold your build, screenshots, description, privacy answers, and review submission.
6. Build and sign it. Give the app one permanent bundle identifier, such as com.company.appname. This is the app's technical name inside Apple's systems. Next you need a certificate, which proves who built it, and a provisioning profile, which is Apple's permission slip connecting the app, developer account, capabilities, and release method. You can have your agent use Xcode to manage this locally, or use EAS Build to manage it in the cloud for Expo and React Native projects.
7. 1. Pro tip: Don't be intimidated by these technical sounding names of things. Ask the agent to explain them to you as a smart non-technical founder, and have it walk you through it all step by step; if you get stuck, take screenshots of the UI you're looking at and ask it to give you advice for the exact UI you're looking at. On a Mac, take screenshots with Command + Shift + 4.
7. Upload it. Native Apple projects can upload through Xcode. Expo projects can use EAS Submit to send the finished .ipa file to App Store Connect (this is easier IMO).
8. 1. Weird term alert: An .ipa is the packaged iPhone application Apple installs on a device. Uploading creates a build inside Apple's system; it does not publish the app. Have your agent hand hold you through this part.
8. Test through TestFlight. After Apple processes the upload, open the TestFlight tab in App Store Connect. Install the free TestFlight app on your phone and have any friends do the same, invite testers, and make them complete the main task without instructions. TestFlight distributes the same release build you may later submit to the App Store.
9. 1. Pro tip: When you have app edits, you can send them to your agent to implement and then push to Github as well as a new version on App Store Connect.
9. Complete the store page. Return to App Store Connect and add the name, subtitle, description, keywords, screenshots, pricing, age rating, regions, support URL, privacy-policy URL, App Privacy disclosures, and reviewer instructions. Every claim must match the uploaded build.
10. 1. Don't get discouraged by all that: If you're using Codex, it'll actually do all of this for you if you ask it what to do and give it permission to do so after you login, via the ChatGPT Chrome Extension and/or native desktop browser in ChatGPT. Corey couldn't remember which it was, so get the extension to be safe.
10. Submit it to App Review. Select the tested build in App Store Connect, click Add for Review, then Submit for Review. App Review is Apple's human review process. Apple may approve the app, request clarification, or identify a specific problem to fix before release. If approved, you have an app!

Now, let's dive into that with a bit more depth, shall we?

The full walkthrough

The compressed version above gets you moving. The sections below explain why each step exists, where beginners usually get stuck, and what Apple's technical language actually means.

Step 0: Choose the release path before touching Apple's tools

A surprising number of app-release problems begin with building for the wrong destination.

Your choices include:

• Web app: Software opened through a normal browser link. Nothing goes through an app store.
• Chrome extension: A small add-on installed inside Chrome to change or add browser behavior.
• iPhone app: Software installed on an iPhone, usually through Apple's App Store.
• Mac app from your website: A desktop app people download directly. A DMG or ZIP is simply the file that carries it to their Mac.
• Mac App Store app: A Mac app distributed by Apple, with stricter limits on what it can access.

Grant and Corey discuss that decision at 1:02:21.

When do you pick which?

A web app is often enough when people only need a link. A Chrome extension makes sense when the product changes how someone uses the browser. The App Store becomes useful when the experience needs phone features, notifications, offline access, or a familiar consumer installation path.

Give your coding agent the complete destination

Tell the agent every platform you might eventually support. That lets it avoid architecture choices that make a later Android, desktop, or web version unnecessarily painful.

Architecture means the basic way the app's screens, saved information, and outside services fit together. Changing it later can feel like moving plumbing after the walls are finished.

Corey and Grant explain this at 25:22.

Review this project and recommend the simplest safe way to distribute it.

Compare a web app, Chrome extension, TestFlight / iPhone App Store release, direct Mac download, and Mac App Store release where relevant.

Explain which path best matches what the app currently does, what accounts and software it requires, what security restrictions it adds, and how difficult future updates will be.

Our longer-term goal may include these platforms: [list platforms].

Do not change the project yet. Give me a recommended path and a plain-English checklist.

Step 1: Freeze the smallest useful app

An App Store launch is a terrible moment to discover that version one contains eight half-built ideas.

Start with one user, one problem, and one main journey. A user journey is the full path from opening the app to completing its main task.

For Corey's Bean Counter app, that journey was simple:

• Log a coffee.
• Compare its cost with buying one from a shop.
• See how much of the espresso machine's price had been recovered.

The idea started as a personal annoyance, which Corey explains at 22:14.

Before building, confirm:

• Who the app serves
• The single problem it solves
• What the user does first
• What successful completion looks like
• What information must be saved
• What version one deliberately excludes

Avoid accounts, payments, social features, advanced settings, and additional screens unless the central experience requires them.

Claude Code includes Plan Mode, which lets the agent inspect the project and propose work without changing files yet. Other agents can follow the same instruction manually. (Claude Code setup)

I want to build an app that helps [type of user] solve [specific problem].

Start in Plan Mode. Ask only the questions needed to understand the idea.

Then propose the smallest useful version we could build and test quickly. Define the main user journey, essential screens, information the app needs to save, and anything we should deliberately leave out.

Include our possible future platforms in the architecture discussion, but optimize version one for [first platform].

Do not write code yet.

Once the product plan looks right, request an engineering plan: the agent's map of how it will build the app and connect the pieces. Corey describes that handoff at 30:58.

In the prompt below, components are reusable pieces of the app, and dependencies are outside packages the project relies on instead of building everything from scratch.

Turn the approved product plan into a complete engineering plan.

Explain the proposed architecture, data storage, screens, major components, dependencies, testing approach, release phases, and any decisions that could make future platforms harder to support.

Use plain English first, then include the technical details.

Do not begin implementation until I approve the plan.

Step 2: Build the prototype, then use it like a normal person

A prototype is an early working version used to prove the main experience.

Build the smallest working prototype from the approved plan.

Focus only on the main user journey. Keep the interface simple, use sensible temporary design choices, and avoid adding features we did not approve.

Run the app, test the core workflow, and explain how I can open and try it myself.

Then stop watching the agent and use the product.

Try to complete the task without asking where to click. Note:

• Where you hesitate
• What feels unnecessary
• What breaks
• What you expected to happen
• What information fails to save
• What happens after closing and reopening the app

Test on a real phone as early as possible. Xcode includes Simulator, a virtual iPhone running on your Mac. A physical phone reveals awkward keyboards, confusing permissions, tiny buttons, and weak-network problems.

Corey describes installing the app on his phone and sending back numbered feedback at 32:51.

Here is what happened when I tested the prototype:

[paste numbered notes]

Fix only the problems affecting the main user journey. Preserve anything that already works.

Do not redesign the app or add new features.

After fixing it, test the entire journey again and report exactly what changed.

Once the core journey works, add only the basics that make it feel finished:

• Clear navigation
• Saving and reopening
• Useful empty states, meaning what a screen shows before the user adds anything
• Loading indicators while the app waits
• Understandable error messages when something fails
• Confirmation after successful actions
• A usable first-launch experience for brand-new users
• A real app name and icon

Step 3: Save a version you can return to

Before changing signing, build, or release configuration, save a known-good version in GitHub.

A GitHub repository, or repo, is the cloud-tracked project folder. A commit is a labeled save point you can restore later.

Review the project and prepare a clean checkpoint of the current working prototype.

Remove temporary files that should not be saved, confirm secrets and credentials are excluded, document how to run the app, and create a clearly labeled Git commit.

Do not change the app's behavior.

Secrets and credentials means passwords, API keys, and other private values. Keep them out of a public repo.

This step feels boring until the release configuration breaks. Then it becomes the smartest five minutes of the project.

Step 4: Review the app before Apple does

Corey's pre-release process had three passes:

• Test every feature visually.
• Run a code review, which checks the project for mistakes and fragile logic.
• Run a security review, which checks private data, credentials, and powerful permissions.

He walks through that routine at 31:53.

Product and code review

A release blocker is a problem serious enough that the app should not ship until it is fixed.

Ask the agent to find:

• Broken or unfinished features
• Fragile logic
• Missing error handling
• Data-loss risks
• Dependencies likely to cause release problems
• Buttons, links, or forms that fail
• Loading states that never finish
• Screens a new user cannot escape

Review this project as if we plan to give it to real users this week.

Find anything that could break the main workflow, lose user information, confuse a first-time user, or make the application difficult to support.

Rank the findings as blockers, important fixes, and optional improvements.

Explain every problem in plain English. Recommend the smallest safe fixes.

Do not redesign the app or add new features.

Security and privacy review

An API key is a private code one service uses to access another. Authentication is how the app confirms who a user is. A log is a behind-the-scenes record used to diagnose problems.

A third-party service is an outside tool such as OpenAI, Firebase, Stripe, or an analytics provider. Check exactly what information it receives.

Ask the agent to identify:

• API keys or passwords included in the project
• Information stored on the device
• Information sent off the device
• Third-party services receiving information
• Excessive permissions
• Weak authentication
• Sensitive data written to logs
• Claims you will need to make in Apple's privacy forms

Review this application for security and privacy risks before release.

Identify what information it collects, where that information is stored, what leaves the device, which outside services receive it, and which permissions the app requests.

Look for exposed credentials, unsafe authentication, unnecessary access, sensitive logs, and anything that could make our App Store privacy answers inaccurate.

Rank the risks by severity. Explain them before making changes.

For health, identity, financial, payment, or similarly sensitive products, an AI review does not replace an experienced engineer, security professional, or lawyer.

Step 5: Create the Apple account that should own the app

Use the Apple Account that should permanently control the product. The Apple Account is the normal free login; the paid Developer Program gives it permission to distribute apps.

A personal experiment might belong to your individual account. A commercial product should usually be owned by the company rather than an employee's personal account.

Grant covers this decision at 49:03.

Apple's paid Developer Program currently costs $99 per membership year. Individuals appear under their own names. Organizations can use their legal company names after extra verification.

The livestream shows enrollment at 14:58 and discusses the annual fee at 19:13.

Do you need a Mac?

That depends on your route.

Swift is Apple's programming language. A native Swift app is built directly for iPhone and normally uses Xcode on a Mac.

React Native lets one JavaScript-based project share much of its code across iPhone and Android. Expo supplies easier tools around React Native, while EAS builds and uploads the finished app on a remote Mac.

That remote computer produces the app's binary, the machine-readable version an iPhone can run. This means an Expo project can be submitted from macOS, Windows, or Linux. (Expo's iOS submission guide)

A Mac remains useful for direct access to Xcode, and a physical iPhone is still important for meaningful testing.

Step 6: Learn Apple's five confusing nouns

Apple's release process becomes much easier once these terms stop blending together.

App Store Connect

App Store Connect is the control panel for your app record, uploaded builds, TestFlight users, store listing, privacy answers, reviews, sales, and release status.

Corey tours it at 11:11.

Bundle identifier

The bundle identifier is the app's permanent technical name, such as:

com.yourcompany.yourapp

Apple uses it to decide which app an upload belongs to. It must match across your project, Apple's records, signing setup, and uploaded builds. The bundle ID cannot change after a build is uploaded. (Apple's app-information reference)

Grant explains the bundle-ID step at 50:02.

Certificate

A certificate proves who built and signed the software. Think of it as the developer's digital signature on the package.

Provisioning profile

A provisioning profile is Apple's permission slip connecting:

• Your developer team
• The app's bundle identifier
• Its enabled capabilities
• The certificate
• The allowed release method

A capability is an Apple feature the app uses, such as notifications, iCloud, or Sign in with Apple.

EAS can create and manage the distribution certificate and provisioning profile for an Expo or React Native project. (Expo's iOS build documentation)

App Store Connect API key

An App Store Connect API key lets EAS or another service upload on your behalf without repeatedly asking for your password and two-factor code.

It normally includes:

• A private .p8 key file, which acts like a password
• A Key ID, which names that key
• An Issuer ID, which identifies your Apple organization

Keep the .p8 file outside the repository and never show it in a screenshot, livestream, or public chat. Expo stores uploaded keys encrypted when you use its managed service. (Expo's EAS Submit documentation)

Step 7: Create the App Store Connect record

An app record is the empty App Store entry created before the software arrives. It later holds the build, screenshots, description, privacy answers, and review status.

In App Store Connect:

• Open Apps.
• Click the plus button.
• Choose New App.
• Select iOS.
• Enter the app name.
• Choose the primary language.
• Select the bundle identifier.
• Add an internal SKU.

The Account Holder must also accept Apple's latest agreement. (Apple's app-record instructions)

The SKU is a private tracking label customers never see. Something simple such as bean-counter-ios-001 works.

Make every identifier agree

Confirm that these match:

• Bundle identifier in the project
• Bundle identifier in Apple's developer records
• App Store Connect app record
• Apple developer team
• Certificate
• Provisioning profile
• Enabled capabilities
• EAS submission profile, when used

A mismatch usually means, "Apple thinks this build belongs to a different app."

Version number versus build number

The version number is what users see, such as 1.0.0. The build number is Apple's counter for each upload of that version.

You may upload several attempts for version 1.0.0, but every attempt needs a different build number.

Export compliance is Apple's questionnaire about encryption. An EAS profile is a saved recipe describing how to build the app or where to upload it. Managed credentials means EAS creates and stores the signing files for you.

Prepare this Expo project for a production iPhone release using the safest current EAS workflow.

Verify that the bundle identifier, App Store Connect app record, version, build numbering, export-compliance settings, developer team, capabilities, and production submission profile agree.

Prefer managed signing credentials unless there is a strong reason not to.

Explain what you can configure automatically, what information you need from me, and what I must create inside App Store Connect.

Do not upload anything until you have shown me the complete plan and confirmed that every identifier matches.

Grant begins walking through the EAS configuration at 52:08.

Step 8: Build, sign, and upload the app

This part depends on how the app was built.

Route A: Native Swift and Xcode

For a native Apple project, Xcode can compile the project into a runnable app, sign it with your certificate, archive the release package, and upload it.

This route offers direct control but generally requires more hands-on Apple configuration.

Route B: Expo / React Native and EAS

EAS Build creates a temporary remote Mac, installs the project, restores the signing credentials, compiles the app, and produces a signed .ipa file. An .ipa is the packaged iPhone app Apple accepts.

A common production command is:

eas build --platform ios --profile production --auto-submit

In plain English: build the public iPhone version, use the production settings, then upload it to Apple.

That command:

• Builds the production app.
• Signs it using the Apple distribution certificate and provisioning profile.
• Sends the completed build to EAS Submit.
• Uploads it to App Store Connect.
• Places it into Apple's processing pipeline, the automated checks before it appears in TestFlight.

Grant discusses the signing credentials at 53:22 and the build-and-upload process at 54:48.

Auto-submit does not mean public release

EAS's --auto-submit flag uploads the app to App Store Connect. After processing, it becomes available in TestFlight.

It does not complete your screenshots, privacy forms, store description, or final App Review submission. Expo says processing usually takes around 10 to 15 minutes, though wait times vary. (Expo's iOS submission guide)

Build and upload this application using the safest supported production EAS workflow.

Before starting, verify the bundle identifier, version, unique build number, signing credentials, Apple developer team, App Store Connect record, and submission profile.

Stop if anything does not match. Do not interpret a skipped step or warning as success.

After uploading, tell me where the build should appear, what Apple still needs to process, and what remains before testers can install it.

Step 9: Test the uploaded build through TestFlight

A development build is made for the person building the app. A release build is the packaged version inside Apple's distribution system. They can behave differently.

TestFlight has two connected parts. The TestFlight tab inside App Store Connect manages builds and invitations. The free TestFlight app is what testers install.

Corey explains TestFlight at 38:59.

Internal testing

Internal testers are people already added to your App Store Connect team. Apple currently allows up to 100 internal testers per app. (Apple's internal-testing guide)

This is the fastest route for testing an uploaded build with teammates.

External testing

External testers are anyone outside that team. Invite them by email or a public TestFlight link. Apple currently allows up to 10,000 external testers per app.

The first external build for a version goes through TestFlight App Review, a lighter Apple review before outside testers receive it. (Apple's external-testing guide)

Give testers tasks, not instructions

Ask testers to:

• Launch the app for the first time
• Complete its main task
• Grant or deny permissions
• Close and reopen it
• Confirm information was saved
• Try an invalid input
• Use it with weak or missing internet
• Try it on different phone sizes

Then ask:

• What did you expect?
• What happened?
• Where did you hesitate?
• What broke?
• Was anything scary to press?
• Did it make sense without instructions?
• Would you use it again tomorrow?

Prepare this build for a small TestFlight beta.

Create a test plan focused on first launch, permissions, the main user journey, saving and recovering information, error states, different phone sizes, weak-network behavior, and anything likely to behave differently outside development.

Give testers short tasks without explaining where to tap.

Then create a feedback form asking what they expected, what happened, where they hesitated, and what broke.

Fix only the problems testing reveals. Give the next upload a new build number, then repeat the process.

Step 10: Build the actual App Store page

Uploading the software gives Apple the app. It does not create the page customers see.

Metadata is the information around the app, such as its name, description, category, screenshots, and keywords.

In App Store Connect, your listing may need:

• App name
• Subtitle
• Description
• Keywords
• Category
• Age rating
• Pricing
• Available countries or regions
• Screenshots
• Optional preview videos
• Support URL
• Privacy-policy URL
• App Privacy disclosures
• Review notes
• Demo credentials, meaning a test login Apple can use when the app requires an account

Apple limits app names and subtitles to 30 characters. A privacy-policy URL is required, and the privacy disclosure must include data collected through third-party SDKs. An SDK is outside code that adds a feature such as analytics, ads, payments, or crash reports. (Apple's App Privacy guide)

Corey shows the listing fields at 38:06.

Let AI prepare the tedious parts

In Corey's workflow, Codex:

• Opened the simulator
• Put the app into representative states
• Captured screenshots
• Resized them for Apple's required device sizes
• Uploaded them
• Drafted the description and keywords
• Created a support and privacy page using GitHub Pages, a simple website hosted from a GitHub repo

You can watch that workflow at 40:01, with more detail about the upload at 41:42.

Apple currently accepts between one and ten screenshots for each supported device configuration, meaning each screen size or device family. (Apple's screenshot specifications)

Keep the submitted app as the source of truth

The uploaded build should control what the listing says. Describe what the app does today, not what you plan to add next month.

AI can draft:

• Store copy
• Screenshot captions
• A screenshot shot list
• Reviewer instructions
• A privacy questionnaire
• Support-page text

It should not invent:

• Features that do not exist
• Screens that are not in the build
• Data-handling claims it has not verified
• Privacy promises based only on your intention

On-device processing means the information stays on the phone. Off-device processing means it is sent to a server or outside service. Apple's disclosures must match what the app and its partners actually collect. (Apple's privacy-label guidance)

Using the working submitted build as the source of truth, prepare the materials for its App Store listing.

Draft the app name, subtitle, description, keywords, category recommendation, screenshot plan, support information, review notes, and tester instructions.

Inspect the code and dependencies before answering privacy questions.

Do not invent features, interfaces, or privacy claims.

Flag every field that requires confirmation from me.

Step 11: Simulate App Review

Before sending the app to Apple, have the coding agent act like a reviewer seeing it for the first time.

The selected build is the exact uploaded version attached to the submission. Make sure its behavior matches the screenshots and description.

Check:

• The selected build matches the listing
• Screenshots show the current interface
• The main feature is reachable
• Demo login credentials work
• Permissions have clear explanations
• Support and privacy links open
• Privacy answers match the code
• Third-party SDKs are disclosed
• Account deletion exists when required
• No placeholder text remains
• Buttons, forms, and links work
• The reviewer has instructions for unusual hardware or workflows
• You have the rights to all included text, images, music, and other content

Apple's privacy guidelines also require an accessible policy explaining what data is collected, how it is used, how long it is kept, and how users can request deletion or withdraw consent. (Apple's App Review Guidelines)

Act as an Apple App Reviewer evaluating this application for the first time.

Review the selected build, store listing, screenshots, permissions, privacy claims, third-party services, support links, privacy-policy link, reviewer instructions, and demo credentials.

Identify definite submission blockers separately from possible review risks.

Recommend only the smallest changes needed for a credible submission.

Step 12: Select the build and submit it

Inside App Store Connect:

• Open the app version.
• Confirm all required metadata is complete.
• Choose the tested build.
• Click Add for Review, which places everything into a draft review submission.
• Open the draft submission.
• Click Submit for Review, which actually sends it to Apple.

Adding the item alone does not send it. (Apple's submission instructions)

Apple may:

• Approve the app
• Ask for clarification
• Reject the metadata, meaning the listing or supporting information needs work
• Reject the build, meaning the software itself needs a change
• Request a working login
• Point to a specific guideline problem

Some metadata rejections can be fixed without uploading another app. Code changes require a new build number and upload. (Apple's App Review message guide)

Every future version follows the same cycle:

Change → test → new build → TestFlight → listing update → App Review → release.

The Mac detour: direct download and the Mac App Store are different products

The livestream briefly discusses choosing between iPhone, web, Chrome, and desktop releases at 1:02:21.

The detailed Mac release workflow below comes from the episode's supporting material rather than a complete on-air demonstration.

Path A: Distribute a Mac app from your own website

A direct-download Mac app uses a Developer ID Application certificate, the signature for software distributed outside the Mac App Store.

Gatekeeper is the Mac security check that decides whether downloaded software is trusted enough to open. Notarization is Apple's automated scan for malware and signing problems. It is separate from human App Review. (Apple's notarization documentation)

One-time setup

You generally need:

• Apple Developer Program membership
• A Developer ID Application certificate stored in Keychain, the protected Mac app that holds passwords and signing identities
• App Store Connect API credentials or another supported notarization credential
• The .p8 key, Key ID, and Issuer ID stored outside the repository
• File permissions that prevent other users from reading the private key

For example:

chmod 600 /secure/path/AuthKey_XXXXXX.p8

Reference the values through protected environment variables or a secrets manager. Never paste the private key itself into a prompt.

Per-app configuration

The app needs:

• Hardened runtime: Extra restrictions that make it harder for malicious code to alter the running app
• An entitlements file: A list of specific security exceptions the app needs, such as access to a protected feature
• Notarization enabled
• Automatic certificate discovery: Let the tools find the correct certificate in Keychain instead of hard-coding one

Apple says notarization fails when hardened runtime is missing. Every entitlement weakens one default protection, so each should have a clear reason. (Apple's common notarization issues)

Electron builds desktop apps with web technologies. Its JavaScript engine may need runtime exceptions, while a native add-on is compiled code bundled into the larger app.

The direct-download build chain

• Code-sign the app. codesign applies your developer identity to the main app and every runnable program inside it.
• Find all nested code. That may include helper programs, native modules, a Node runtime that runs JavaScript, or a bundled Python environment.
• Submit the signed app to Apple. notarytool uploads it for the automated scan.
• Wait for Apple's decision. Apple checks for malware and signing problems.
• Staple the ticket. stapler attaches Apple's approval so a Mac can verify it without contacting Apple.
• Package the release. Put the app into a DMG, ZIP, or PKG installer. These are simply different containers for the final download.

Apple retired altool for notarization uploads in 2023. Current scripted workflows should use notarytool or the Notary API. (Apple's notarization documentation)

Verify the exact file people will download

A build log saying "success" proves that the script reached its final line. It does not prove Apple accepts the final artifact, meaning the exact file users will receive.

Run independent checks against that file:

spctl -a -vvv -t install /path/to/YourApp.app

You want Gatekeeper to report that the app was accepted and identify a notarized Developer ID source.

Then confirm the ticket:

xcrun stapler validate /path/to/YourApp.app

The supporting release notes captured the painful lesson: missing credentials, incorrect environment variables, swallowed code-signing failures, and broken entitlements all produced successful-looking builds. Four bugs returned exit code zero, while none of the artifacts were actually notarized.

Apple's final checks are the evidence. The build log is a progress report.

Prepare this Mac application for distribution from our website rather than through the Mac App Store.

Identify every executable component that must be signed, including helpers, runtimes, native modules, and packaged environments.

Enable hardened runtime. Request only the entitlements the app genuinely needs, and explain each one.

Sign all code, submit the app through Apple's current notarization workflow, staple the approval ticket, package the final release, and verify the exact file users will download.

Do not report success unless Gatekeeper and stapler both accept the final artifact.

Path B: Publish through the Mac App Store

The Mac App Store uses a separate release configuration.

Depending on the toolchain, you may need:

• An Apple Distribution or Mac App Distribution certificate
• A Mac Installer Distribution certificate for the installer package
• A provisioning profile
• A special Mac App Store build of the application
• App Store Connect metadata
• A signed package uploaded through Transporter, Apple's app for sending store packages
• Human App Review

For Electron, use the special MAS build, meaning the Mac App Store version, instead of the ordinary desktop file. (Electron's Mac App Store guide)

App Sandbox is the real engineering constraint

Mac App Store software must use Apple's App Sandbox.

A sandbox is a fenced area that limits what an app can reach outside itself. It restricts access to:

• Files outside approved locations
• Child processes, meaning separate helper programs launched by the app
• Local servers
• Hardware
• Network resources
• Other protected system capabilities

Each required ability needs an approved entitlement or a different architecture. Apple requires sandboxing for Mac App Store software and recommends it for direct downloads. (Apple's Mac distribution guide)

A desktop app that freely launches command-line tools or reads arbitrary folders may need meaningful redesign before it can pass review.

What the Mac App Store gives you

• Apple-hosted discovery
• Familiar installation and updates
• Built-in payment infrastructure
• Apple handling download and billing support

What it costs you

• Sandboxing work
• Human review for releases and updates
• Slower emergency fixes
• Store metadata and privacy work
• A commission on qualifying digital sales

Apple's standard commission is 30%, with 15% rates for qualifying subscriptions and approved programs such as the Small Business Program. (Apple Developer Program benefits)

For a product you plan to sell, those tradeoffs may be worthwhile. For a portfolio app, a notarized direct download or web version may accomplish the goal with less work.

The Chrome-extension route

The episode introduces Chrome extensions at 10:44 and returns to them at 1:02:21.

Test it privately

An unpacked extension is the raw project folder loaded directly into Chrome for testing.

• Open chrome://extensions.
• Enable Developer mode, which allows locally built extensions to run.
• Click Load unpacked.
• Choose the extension's folder.
• Test it across realistic websites, tabs, browser states, and signed-in conditions.

Google says unpacked extensions are appropriate for developing and testing trusted local code. Public consumer distribution generally goes through the Chrome Web Store. (Chrome's distribution guide)

Prepare the public listing

The extension's manifest is its configuration file. It tells Chrome the extension's name, scripts, features, and requested permissions.

You will need:

• Extension name
• Description
• Icons
• Screenshots
• Packaged files
• A clear single purpose
• Permission explanations
• Privacy disclosures
• A working support route

A permission is access to a browser feature or user information. An extension may request access to tabs, page content, browsing history, downloads, or the clipboard.

Google requires extensions to request the narrowest permissions needed for existing functionality. You cannot request broad access merely because a future version might use it. (Chrome Web Store permission policy)

If the extension handles user data, its privacy policy and store disclosures must accurately explain what is collected, used, and shared. (Chrome Web Store policies)

Prepare this Chrome extension for real users.

Test its main behavior across realistic websites, tabs, browser states, and error conditions.

Review every requested permission. Remove anything unnecessary and explain why each remaining permission is required.

Identify any private information the extension can access, store, or transmit.

Then prepare the package, listing description, icon and screenshot checklist, permission explanations, privacy disclosures, and reviewer notes.

Do not submit it until the local packaged version passes the complete test plan.

What about Android?

The hosts discuss Android architecture and distribution at 1:03:09.

Swift is Apple-specific, and iCloud is Apple's storage and syncing service, so an app built around both will need meaningful changes for Android.

A cross-platform framework is designed to share much of one project across different devices. React Native is one option; Flutter is Google's alternative.

You still need separate store records, signing, testing, privacy disclosures, and Google Play submission. Google Play Console is Google's equivalent of App Store Connect.

Google's testing rules change, so check the current Play Console requirements before planning around a fixed number of testers or days.

Key moments from the livestream

• 9:43: What happens after your AI-built prototype works
• 11:11: App Store Connect tour
• 14:58: Apple Developer Program enrollment
• 19:13: Membership cost and developer tools
• 20:30: Using Codex to set up the development environment
• 22:14: How Bean Counter began
• 25:22: Tell the agent every future platform
• 30:58: Create the engineering plan
• 31:53: Simulator, code review, and security review
• 32:51: Test on a real phone and submit numbered feedback
• 36:59: Ask the agent to handle the submission process
• 38:59: TestFlight explained
• 40:01: Automated screenshot capture and upload
• 43:03: Descriptions, keywords, support, and privacy pages
• 49:03: Choose the permanent Apple account
• 50:02: Bundle identifier and Apple records
• 53:22: Signing credentials
• 54:48: EAS production build and upload
• 59:20: The complete release flow
• 1:00:45: TestFlight, listing, App Review, and release
• 1:02:21: Web app versus extension versus mobile app
• 1:03:09: Android tradeoffs

Our take

AI has made the first 80% of building software radically more accessible.

The remaining 20% is where the product becomes real.

A stranger needs to be able to install it, understand it, trust it, recover when something breaks, and know what happens to their information. Apple and Google's bureaucracy can feel excessive, but those questions exist because released software has consequences that a local prototype does not.

Coding agents can now handle much of the mechanical labor:

• Inspecting the project
• Building the binary
• Managing signing
• Capturing screenshots
• Drafting metadata
• Uploading builds
• Reading rejection messages
• Preparing fixes

They cannot take responsibility for a false privacy answer, an exposed secret, a payment mistake, or a product that loses somebody's information.

The next question is how much of this release process becomes fully agent-run. Apple can automate certificates, uploads, checks, and metadata APIs. It still needs a human or legal entity to stand behind the app's behavior.

For now, move one project exactly one level forward:

• Local extension → load it into Chrome
• Web prototype → send it to one tester
• Simulator build → install it on a physical phone
• Physical-phone build → upload it to TestFlight
• TestFlight build → complete the store listing
• Mac app → sign, notarize, and verify the final download
• Public app → run a complete security and privacy review

Do not add five more features. Ship the smallest version you would feel comfortable handing to one real person.