Most clients ask us about the build. Few ask about the week after the build, when the app sits in App Store review and nobody can do anything about it. That week is where first launches slip, so we plan for it from the first sprint instead of the last.
This is how we run an iOS release for a client, and the rejections we try to prevent before Apple ever sees the app. It applies whether the app is native Swift, React Native or Flutter. Review does not care how you built it.
Start the Apple side early
Before we write much code, we need three things from you:
- An Apple Developer Program account enrolled under your company, not under a developer's personal name. If the account belongs to a freelancer or to us, moving the app later means a transfer, and transfers are slow and sometimes blocked.
- A company D-U-N-S number if you enrol as an organisation. This is the step that surprises people, because it can take days or weeks and we cannot speed it up.
- Someone on your side who can accept the agreements and receive the verification codes.
We would rather lose a day asking for these in week one than lose two weeks hunting for them at launch.
Use TestFlight from the first working build
TestFlight is not a final-week step. We push the first installable build as soon as login and one real screen work, usually in the second or third week.
It gives you three things. You hold the app on your own phone and react to real screens instead of screenshots. We find signing, entitlement and push notification problems while there is still time to fix them. And builds that go to external testers get a lightweight review, so the first external build also tells us early whether the app trips anything obvious.
We split testers into two groups. Internal testers are your team and ours, and they see every build. External testers are a few real customers or staff, and they get a build only when we say it is ready to be judged. Mixing them up wastes the goodwill of the people whose opinion matters most.
One practical limit: TestFlight builds expire after 90 days. If a project pauses, the last build quietly stops working. We note the expiry date on the project board.
The rejections we plan around
We cannot promise any app passes on the first try. But most rejections we see come from a short list, and almost all of them are decided before the build is uploaded.
The reviewer cannot get in. If the app needs a login, the reviewer needs a working demo account with realistic data, entered in the App Review notes. If sign-in uses a one-time code sent to a phone number, give them a fixed test number or a bypass for the review account. An app the reviewer cannot open is rejected as incomplete, and it costs a full round trip.
Account deletion is missing. If people can create an account in the app, they must be able to start deleting it from inside the app. This is a Laravel or backend task as much as a mobile one: the delete button has to remove or anonymise data on the server, and the order history you must keep for tax reasons needs a documented exception. We design that rule with you before building the button.
Sign in with Apple is skipped. Apps that offer Google or Facebook login generally have to offer an equivalent privacy-respecting option as well, which in practice means Sign in with Apple. Adding it late means touching the backend login flow, so we decide on it at the start.
The privacy answers do not match the app. The App Store privacy labels, the privacy policy URL and the actual network traffic must agree. If the app uses an analytics SDK, a crash reporter or an ad SDK, each one collects something, and Apple also asks SDK vendors for privacy manifests. We list every SDK in the app and what it collects before filling in the form, rather than guessing.
The app is a website in a frame. If the app is a thin wrapper around your WordPress or Joomla site, expect a design rejection. The fix is to give it something native-feeling that the website does not do: offline lists, push notifications, camera or file upload, saved state. If you cannot name that thing, a good mobile web site may serve you better, and we will say so.
AI features without disclosure. If the app sends user text or documents to an outside AI model, the review notes and the privacy policy should say who receives the data, and the user should know before the first message goes. Apple has been tightening its rules around sharing personal data with third-party AI, so read the current App Review Guidelines for your build date instead of trusting an article, including this one. We keep the data-flow description in the project docs so the answer is one paragraph, not a scramble.
What we put in the submission
Our checklist before pressing submit:
- Demo credentials tested on a clean install, on a phone that has never had the app.
- Screenshots for each required device size, taken from the real build, not mock-ups.
- A support URL and a privacy policy URL that load, on the live domain.
- Review notes that explain anything non-obvious, such as a feature that only works in a specific region or with hardware.
- Any backend the app calls is on the production URL and stays up for the whole review. A staging server that sleeps at night is a common cause of "we could not test the feature".
- Release set to manual, so you decide the day the app goes live instead of Apple's approval deciding it.
When it is rejected anyway
It happens. The rejection message cites a guideline number. We read it, fix what is actually being asked, and reply in the Resolution Center with a short, specific note. If we think the reviewer misread something, we explain politely with screenshots rather than resubmitting the same binary. A fix that takes one afternoon should not cost a week of arguing.
Because we budgeted for this, the rejection is a scheduled bump, not an emergency. We usually tell clients to plan one to two weeks between "build finished" and "live in the store", and to treat anything faster as a bonus.
What this means for your project
If you are planning a first iOS app, the useful questions to ask any agency, including us, are who owns the developer account, when the first TestFlight build will arrive, and who prepares the review notes. If the answers are vague, the surprises will land on your launch date.
We build iOS and Android apps from our Lalitpur studio, together with the Laravel, WordPress or Python backend behind them. If you have an app in mind and want a realistic release plan before you commit, send us a short brief and we will reply with our assumptions.
Reference: Apple's App Review Guidelines and the TestFlight overview.