After the manual release-ios job, Apple reviews the app before it appears in the App Store. With Google, the review runs after release-android has promoted the build to the Production Track. Both reviews run against the live state, that is, against the production environment and the real store texts.
Demo access for the reviewers
If the app has a login, the reviewers need a working demo account. You store it in the app repository under ios/fastlane/metadata/review_information/ in three files: demo_user.txt contains the username, demo_password.txt the password, and notes.txt notes for the reviewers, for example about special aspects of the app. The account must work in the production environment because the reviewers test the live state.
Common reasons for rejection
Most rejections have a handful of causes. Description, screenshots, and privacy details must match the actual app; how to maintain them in the repository is described under Store metadata. Placeholders such as empty screens, “lorem ipsum”, or dead links reliably lead to rejection. Crashes on launch are the first thing reviewers notice; that is exactly why the platform stages every build in TestFlight and the Internal Track first, where you can try the release build before submitting it. The privacy policy at the privacy URL and, where required, a legal notice must be reachable. Every permission for camera, location, or tracking needs an understandable justification in the app.
After a rejection
- Read the reasoning in App Store Connect or the Play Console. It references the specific guideline the app violates.
- Fix the issue, merge the change to
main, and wait until the pipeline has published the new build. - Start
release-iosorrelease-androidagain.
If Apple’s reasoning remains unclear, you can reply and ask directly in the Resolution Center of App Store Connect.