Making an app for iPhone used to start with a shopping list: a Mac, Xcode, Swift, and a simulator to pretend a phone was there. That is no longer the shape of the work. You describe the app, it gets built, and the part that genuinely needs Apple hardware runs on somebody else’s Apple hardware in the cloud.
What has not changed is the paperwork. You need your own Apple developer account, a real iPhone to test on, and an app that does something a browser tab cannot. This guide walks the whole path, and it is specific about the two or three things nobody can do on your behalf.
QUICK ANSWER
How do you make an app for iPhone?
Describe the app in plain language and AI builds it as a real iPhone app inside your project, with its own backend and database. Preview it on your phone while you work. The build runs on Apple hardware in the cloud, so you do not need a Mac. You need your own Apple developer account, and you press submit to the App Store yourself.
What you need before anything gets built
None of these are technical, and two of them involve waiting on Apple. Sort them out on day one and the release is a short afternoon rather than a fortnight of surprises.
- Your own Apple developer account: There is no way around it and nobody can lend you theirs. Apple’s enrolment page said on 2026-08-16 that the Apple Developer Program is 99 USD per membership year, with prices varying by region. Treat that as a figure to re-check, not a fixed price. Individuals need an Apple Account with two-factor turned on and their legal name on it. Companies also need a D-U-N-S number and a binding-authority check, and that verification is the part that takes days.
- A real iPhone, or somebody who owns one: There is no simulator anywhere in this path, by design. You preview the app on an actual phone while you build, and you install a real test build before you submit. If you do not own an iPhone, line one up now, because the first thing you will find is a layout problem a laptop screen cannot show you.
- One thing the app does that a browser tab cannot: Apple’s App Review Guidelines set a minimum functionality bar in guideline 4.2. An app that only repackages a website is the classic rejection, and it is the most common reason a first submission comes back. Write down one complete task the app performs on the phone before you describe anything.
- A name and an identifier you will not want to change: Your app needs a display name for under the icon and a bundle identifier in reverse-domain form, such as com.yourcompany.yourapp. The identifier is effectively permanent once an app record exists in App Store Connect under it. Choose it using a domain you actually control, not a placeholder you meant to fix later.
- A public address the phone can reach: A phone is a different machine from your laptop. It cannot see localhost and it cannot see a port that only exists on a development server. The app has to talk to a public HTTPS address. On Playcode that is already true, because the project is published on its own link and the app is pointed at it for you.
Credentials and access
| Credential | Minimum access | Storage and rotation |
|---|---|---|
| Apple Developer Program membership Human identity and organisation membership | Give each person the narrowest App Store Connect role that lets them do their job. Keep the Account Holder with the legal owner of the business, not with a contractor or an agency. | Protect the Apple Account with two-factor authentication and an address you will still control in three years. Never paste an Apple password, recovery code or session token into a chat message. Remove people when they leave, review roles before each release, and keep more than one administrator so a holiday does not block an update. |
| App Store Connect API key Service credential used by the build service to upload | Create one key per automation with the narrowest role that can upload builds. Prefer it over an Apple ID password, because it can be revoked without locking anyone out. | Store it as a project secret. On Playcode the agent stores credentials as secrets in the project environment rather than in the conversation or a committed file. A key that has appeared in a message is leaked and should be replaced. Record who created each key and when it was last used. Revoke unused keys, and revoke immediately when the person who created one leaves. |
| Cloud build service account Token for the service that runs the iOS build and upload | One account per company, with the build token scoped to that account. It is what lets a build run without an interactive login. | Keep the token in project secrets alongside the Apple credentials. It grants the ability to build and submit under your identity, so treat it like a password. Rotate it on a schedule and after any suspected exposure. Confirm a build still runs after rotation, before you need one urgently. |
Three ways to put something on an iPhone
These are genuinely different trades, not three names for the same thing. Only two of them end with an App Store listing, and the cheapest one is the one most first products actually need.
| Approach | Best for | Tradeoff |
|---|---|---|
| A web app people open from a link | A form, a booking flow, a dashboard, a portal, or anything where the audience arrives from a link you send them. It opens on every phone, and it can be added to the Home Screen. | No App Store listing, no store search, and no icon that arrives with the credibility of a review. You trade reach and status for zero accounts, zero fees and zero review queue. |
| An iPhone app built in the cloud from one description | A product that needs to be in the App Store, and a team that does not want to own a Mac, a toolchain or a second codebase. This is the Playcode path: the phone app, the web app and the backend live in one project. | You depend on the build service supporting your libraries, and anything with unusual native code needs checking before you commit to it. You still own the Apple account, the review and the updates. |
| Native Swift written in Xcode on a Mac | A product whose core feature is a deep Apple capability, or a team already shipping iOS continuously with people who know the platform. | A Mac per developer, a separate codebase from your website, and the full release apparatus to run yourself. It is the right answer eventually for a native-heavy product and the wrong first purchase for a first release. |
Recommended:Start with the web app if the job is a form, a dashboard or a booking flow, because there is no account, no fee and no review. Move to a store app when you need an icon on the Home Screen, a listing people can find, or something that only makes sense on a phone. Build native Swift when you can name the specific Apple capability that forced it.
How to make an app for iPhone
Open the Apple account, describe the app, test it on a real iPhone, run the cloud build, and submit it to the App Store yourself.
STEP 01
Start the Apple enrolment on day one
It is the only step with somebody else’s queue in it, so begin it first and build while it is being verified.
Enrol at Apple’s developer enrolment page. Use your legal name exactly as it appears on your identity document. The name you enrol under becomes the seller name on your App Store listing, so a nickname is not a small mistake.
If you are enrolling a company rather than yourself, get the D-U-N-S number and a working company website in place before you begin. Both are checked, and both are the usual reason an enrolment sits waiting for a week.
Turn on two-factor authentication for the Apple Account and use an address you will still control in three years. Whoever holds this account controls your ability to update your own app.
Expected result: An approved Apple Developer Program membership, and the ability to sign in to App Store Connect and see an empty app list.
Verify it: Sign in to App Store Connect and create a new app record with your chosen bundle identifier. If the record saves, the account is genuinely ready rather than half-enrolled.
STEP 02
Write down the one job the first version does
A first release that does one thing completely gets through review. A shell around a website does not.
Name the person who opens the app, what they do in it, what gets saved, and what they see afterwards. Then write what they see when it is loading, when they are offline, when the input is wrong, and when the server says no. Those four unhappy states are most of the work and they are what a reviewer actually taps.
Keep the rest of the roadmap out of version one. Everything you add before the first release adds review risk without adding evidence that anybody wants the app.
This paragraph is also your prompt. You do not need to name a framework, a database or a screen layout; you need to describe the job.
One job: a technician opens today's visit, adds a note, and submits it once.
Who signs in: a technician who belongs to one company.
What gets saved: the note, on the server, against that visit.
What they see after: the visit marked done, with the note under it.
Loading: a skeleton, not a blank screen.
Offline: the note is kept on the phone and sent when the signal returns.
Wrong input: an empty note is refused next to the field, keeping what was typed.
Server says no: a plain message and a retry button that does not create two notes.
Not in version one: photos, scheduling, invoicing, notifications.Expected result: One paragraph describing a single complete task, with its four unhappy states written down beside it.
Verify it: Read it to somebody who has not seen the product. If they can repeat the task back and say what happens when it fails, it is specific enough to build.
STEP 03
Describe the app and get a working version
On Playcode you write the brief in ordinary words and get a project that already contains the phone app, the web app and the backend.
Paste the paragraph you wrote and let it get built. Playcode builds the mobile app with React Native and Expo, in the same project as the web app and the backend, so one description covers the phone, the browser and the database behind both.
The phone app and the website share the same accounts, because they call the same backend. Somebody who signs up on your site can sign in on the phone with no extra work. That is the part most app builders cannot do, and it is the reason to keep them in one project rather than two.
Ask for changes the same way you asked for the app. The point of this step is a running app, not a finished one.
Expected result: A project containing an iPhone app alongside the web app and the backend, running without errors.
Verify it: Complete the task once in the preview, reload, and check the record is still there. If it survives a reload it is really in the database rather than held in memory.
STEP 04
Set the identity: name, icon, and bundle identifier
These are what turn a preview into something App Store Connect will accept, and two of them are hard to change later.
Set the bundle identifier to the reverse-domain name you chose and the display name to what should appear under the icon. Do this before the first build, because the app record in App Store Connect is tied to the identifier permanently.
Add the app icon and the launch screen now. They are required for a store build, and leaving them until the end is how a build fails at the last minute on a Friday.
Check the app reads its API address from configuration rather than a value typed into the code. This is the single most common reason an app works in a browser preview and shows nothing on a phone.
Expected result: An app that starts with your icon and your name, and loads real data from your published backend address.
Verify it: Search the project for a hardcoded localhost or a raw IP address in the app code. Finding none, and seeing real data on the phone, is the proof.
STEP 05
Test it on a real iPhone, not a picture of one
Preview it on your phone by scanning a code. This catches most problems while fixing them is still cheap.
Start the mobile preview and open it on an iPhone. There is no simulator in this path, which is a feature rather than a gap: everything you see is what a real device does. Check the things a laptop cannot show you, such as whether the tap targets are reachable with a thumb, whether the keyboard covers the field you are typing in, and whether the app survives switching away and back.
Test on a slow connection and with the phone in airplane mode. An app that shows a permanent spinner when the network is gone gets rejected by a reviewer on hotel wifi.
If a screen breaks only on the phone, look first at anything with custom native code. Libraries that ship their own native code cannot load in a quick preview; they need a full build. Prefer a plain JavaScript alternative until you are past your first release.
Expected result: The complete task works on a physical iPhone, including the offline and wrong-input paths.
Verify it: Do the whole task on the phone with the laptop closed. Anything you have to explain away is a defect, not a quirk.
STEP 06
Break it on purpose before a reviewer does
Reviewers use apps badly, on bad networks, on devices you did not choose. Go there first.
Turn the text size up to the largest accessibility setting and open every screen. Fixed-height rows and text that cannot wrap are the most common way a good-looking app becomes unusable for a real customer.
Try the app on the smallest screen you can find. A layout only ever checked on a recent large phone is a layout that has never been checked.
Sign in as a second account and try to open the first account’s records. The server has to refuse that. A hidden button is not a permission, and a reviewer is not the person you want discovering the difference.
Expected result: The app is usable at the largest text size, on the smallest screen, and refuses to show one customer another customer’s data.
Verify it: Write down each device, text size and account you tried and what happened. A release blocked by one unexplained result is cheaper than a rejection.
STEP 07
Run the cloud build
This is the step that used to need a Mac, and the step a hosted build service does for you.
The build runs on Apple hardware you do not own. Expo documents that EAS Build is a hosted service that produces installable binaries and manages app signing credentials, which is why nothing on your desk has to be a Mac. Signing certificates can be generated for you after you sign in with your Apple account, or you can supply certificates you already have.
Apple moves the floor for what it will accept. Its developer news page states that from April 2026, iOS apps uploaded to App Store Connect must be built with the iOS 26 SDK or later. You do not set this by hand on Playcode, but it is the sort of rule that turns a working build into a rejected upload, so re-read the page before a big release.
On Playcode you do not run these commands yourself. Describe what you want, and the agent drives the build, asks for the credentials it needs, and stores them as project secrets rather than in the conversation. Never paste an Apple credential into a message.
Expected result: A finished iOS build in your build history, marked for App Store distribution rather than internal testing.
Verify it: Open the build log and confirm it produced a store binary. A build that succeeded but was made for internal testing cannot be uploaded to App Store Connect.
STEP 08
Fill in the listing and press submit yourself
The upload is automatic. The submission is yours, and Apple requires that it is yours.
The upload sends the binary to App Store Connect from any operating system. Expo documents that the build becomes available in TestFlight after processing, and that a TestFlight build is not automatically released: you sign in, complete the metadata and screenshots, select the build, and submit it for review.
Nobody can submit on your behalf. Guideline 4.2.6 says apps created with a commercialised app generation service are rejected unless they are submitted directly by the provider of the app content. That is you. Playcode drafts the listing text and captures screenshots for you, and the app is listed under your account with the submit button in your hands.
Answer the privacy questionnaire from what the app actually collects. Apple’s App Privacy guidance covers your own code and every third-party component in the app, and the listing needs a privacy-policy URL. Answering it wrong is a slower problem to fix than answering it slowly.
Expected result: A version in App Store Connect with your build attached, complete metadata, and a status of waiting for review after you submit.
Verify it: Watch the version status change to waiting for review. Until you have seen that with your own eyes, it is not submitted.
STEP 09
Ship the second version and watch what it breaks
A release you can repeat in an afternoon is worth more than a fast first release.
Bump the version, build, upload, submit. Apple documents that an update needs a new version and build, and that the App Store cannot be reverted to a previous version. There is no undo button, so the recovery plan is always a corrected version plus whatever you can fix on the server.
Keep the phone app and the website moving together. They share a backend, so a change to the data model touches both. Test the web version after any change you made for the phone.
Read the crash reports Apple shows in App Store Connect after every release. The first crash of a new version usually appears within a day of it reaching real devices.
Expected result: A second release that took hours rather than days, with a recorded build number you can match to a date.
Verify it: Compare the build number in App Store Connect with the number in your own release note. If they match, your record is trustworthy.
The four tests to run before you submit
A screen that looks right proves rendering and nothing else. These four cases are the ones that turn into rejections, support tickets and one-star reviews.
| Test | Scenario | Expected result |
|---|---|---|
| happy path | On a real iPhone, sign in, complete the one task the app exists for, close the app, and open it again. | The record is saved on the server. It is still there after reopening, and the same record appears when you sign in to the web version of the same project. |
| invalid input | Submit the main form with a required field empty, with a value far longer than the field expects, and while signed in as an account that does not own the record. | The app explains what is wrong next to the field and keeps what was already typed. The server refuses the unauthorised write regardless of what the app shows. Nothing is saved and nothing crashes. |
| retry | Turn on airplane mode, submit, force-close the app, reopen it, turn the network back on, and press the button again. | The first attempt fails with a plain message and an obvious way to retry. The retry succeeds and creates exactly one record, not two. |
| production smoke | Install the build you actually uploaded, on a phone that has never seen the app, over mobile data rather than wifi, with a brand new account. | A clean install signs up, completes the task, and shows the result. This is the run that catches an app still pointing at a development address instead of the published one. |
What breaks, and what to do about it
Every one of these has been somebody’s entire delay. They look mysterious and they are not. Read the first error rather than the last, and fix the mismatch it names.
| Symptom | Likely cause | Check | Fix |
|---|---|---|---|
| It works in the browser preview and shows nothing on the phone. | The app is calling an address only your development machine can see, usually localhost or an internal port. | Open the same API address in the phone’s browser. If it does not load there, the app was never going to reach it either. | Point the app at the project public HTTPS address through configuration rather than a value typed into the code, then reload it on the phone. |
| A library fails the moment its screen opens in the phone preview. | The library ships its own native code. A quick preview can only run the native code it was built with. | Remove the screen that imports it and see whether the app starts. If it does, that library is the cause. | Swap it for a JavaScript-only alternative, or accept that this feature can only be tested in a full build. Decide before your first release, not during it. |
| The iOS build fails during signing. | The Apple account is not fully enrolled, the membership has lapsed, or the bundle identifier in the app does not match the app record in App Store Connect. | Open the build log and find the first error rather than the last. Then compare the identifier on the App Store Connect record with the one in your app configuration, character for character. | Fix the mismatch or finish the enrolment, then build again. Do not create a second app record to work around it; that permanently splits your app in two. |
| The upload is rejected before a human ever looks at it. | The build does not meet the current minimum SDK, the version and build numbers were reused, or the export-compliance answer is missing. | Read the exact message from App Store Connect and compare the archive against the current upload requirements rather than retrying the same bytes. | Change the failing item, increment the build number, rebuild, and upload again. A build number can never be reused, even for a build nobody saw. |
| Apple rejects the app under guideline 4.2 for minimum functionality. | The app is largely a wrapper around a website, or it repeats what the mobile browser already does perfectly well. | Ask what the app does that a browser tab cannot. If the honest answer is nothing, the reviewer reached the same conclusion. | Add something that only makes sense on a phone, or ship the web version instead and stop paying the store tax. Both are legitimate outcomes. |
| App Review says it cannot get into the app. | The demo account is invalid, the backend was down during review, or a non-obvious path was never explained in the review notes. | Follow your own submitted notes on a clean device, on a network outside your office, using only the credentials you gave Apple. | Provide a working demo account, keep the backend up through the review window, and write review notes that describe the exact taps. Reply through App Store Connect rather than resubmitting blind. |
| The enrolment has been pending for more than a week. | The name on the Apple Account does not match the legal identity, or a company D-U-N-S record or website did not verify. | Re-read the enrolment requirements against what you actually entered, particularly the name fields and the company website. | Correct the mismatch and contact Apple Developer Support. This is a queue you cannot shorten by resubmitting, so keep building while you wait. |
Release, watch, recover
Deploy
Keep the version number and the build number in the project rather than in your head. Every upload needs a build number that has never been used before, and matching a crash to a build is impossible without the record.
Release one change at a time when you can. When something breaks after a release containing six changes, you have six suspects and a bad afternoon.
Send a test build to the people who will tell you the truth before the public version goes out. A processed build reaches your testers first, and that is the cheapest place to find out that the icon is wrong.
Monitor
Read the crash reports in App Store Connect after each release. A crash rate that rises the day after a release is the release.
Watch your backend errors at the same time. The phone app and the website share it, so a fault caused by the phone shows up in the same place as one caused by the browser.
Track how many people finish the one task the app exists for, not how many downloaded it. Downloads say the listing works. Completions say the app works.
Recover
There is no rollback on the App Store. Recovery is a corrected version with a higher build number, so keep the previous build and be able to rebuild it.
If the fault is on the server rather than in the app, fix it there. That reaches every installed copy immediately without going through review at all, which is a good reason to keep the rules on the backend.
Take a snapshot of the project before a risky change, so you can restore code, files and database together and try again rather than reconstructing from memory.
The parts a generated app must not get wrong
Most of the risk here is not in the code. It is in who owns the account, and in what the app is allowed to ask the server for.
- The Apple developer account must be in your name or your company’s name, never a contractor’s personal account. Whoever holds it controls your ability to update your own app.
- Keep Apple and build-service credentials in project secrets, never in chat messages, code or a committed file. A credential that has been pasted into a conversation should be treated as leaked and replaced.
- Never ship a private key inside the app. Anything in an app bundle can be read by anyone who downloads it, so keys belong on your backend. That is one more reason the app should talk only to your own server.
- Make the server decide what each account may read and write, for every single request. A hidden screen is not a permission. Test it with two accounts before a stranger tests it for you.
- Ask for a permission at the moment it becomes useful, explain why, and keep the main job working when it is denied. An app that refuses to start without notifications is an app people delete.
- Answer the App Privacy questionnaire from what the app actually collects today, not from what you intend to collect later. An inaccurate answer becomes a compliance problem once the app is live.
Questions people ask about making an app for iPhone
Do I need a Mac to make an app for iPhone?
No. The Mac requirement came from Xcode and Apple code signing, and a hosted build service runs both on Apple hardware for you. Expo documents that its submit step runs from any operating system. You can build and ship an iPhone app from Windows, Linux or a Chromebook.
Do I need to know Swift or Xcode?
No. You describe what the app should do in ordinary language and get a real project back. Playcode builds the phone app with React Native and Expo in the same project as your website and your backend, so there is one thing to maintain rather than two.
What does it cost to put an app on the App Store?
Apple listed the Apple Developer Program at 99 USD per membership year on its enrolment page when we checked on 2026-08-16, and said prices vary by region. Google Play charged a 25 USD one-time registration fee on the same date. Both are their charges, not ours, and both can change, so check before you budget.
Can I test the app on an iPhone without a simulator?
Yes, and there is no simulator in this path at all. You preview the app on your own phone while you build, then install a real test build before submitting. Everything you check is what an actual device does, which is the only test that has ever counted.
Does Playcode publish the app to the App Store for me?
No, and no honest tool can. Playcode drives the cloud build and the upload, drafts the listing and captures screenshots. You need your own Apple developer account and you press the final submit yourself. Guideline 4.2.6 requires apps made through a service like ours to be submitted by the owner of the content.
How long does App Review take, and will my app be approved?
Nobody can promise either. Review takes days rather than minutes and it can come back with a rejection, most often for minimum functionality under guideline 4.2. Plan for at least one round trip, and read the guidelines before submitting rather than after being rejected.
Do I get an Android app too?
Yes. The same project builds for both, because the app is written once. Google Play has its own account, its own one-time fee and its own rules, and its testing gate is stricter for new personal accounts, but you are not writing the app twice.
Should I build an iPhone app or just a website?
Build the website first when the job is a form, a booking flow, a dashboard or a portal, because there is no account, no fee and no review queue. Build the app when you need an icon on the Home Screen, a listing people can find, or something that only works on a phone.
Do I own the code, or am I locked in?
You own it. Playcode produces real, exportable code, and the project holds the phone app, the web app and the backend together. If you later decide you want a Mac and Xcode, you take the project with you.
Build it on Playcode
Describe your iPhone app and see it on your phone today
Write down the one job it does, and get a real app with its own backend, its own database and a link you can share. Preview it on your phone while you build, and take the cloud build to the App Store under your own Apple account.
Build My iPhone AppNo credit card required. An Apple developer account and the final submit are yours.