iOS publishing
App Store Review Guide
A working IPA is a build result, not an approval. Use this guide to check the product you are submitting and the evidence that supports it. There is no guaranteed number of native features that makes an app pass.
Reviewed September 5, 2026 · No approval or device-test result is claimed by this checklist.
Start with the actual review requirement
Apple's Guideline 4.2 evaluates minimum functionality and the app experience beyond a repackaged website. Push, biometrics or a splash screen are not automatic approval criteria. Build useful workflows for your audience, not features added only to decorate a submission.
If you already have a rejection, read its exact guideline and reviewer message. A login failure, an incomplete purchase flow and a minimum-functionality objection need different responses. Do not assume every rejection is 4.2.
Confirm the deliverable before submission
Code2Native's iOS workflow builds our website-wrapper template. Uploaded iOS source projects are not accepted. The default IPA is unsigned; optional cloud signing requires active Pro and matching certificate/profile inputs. An App or Builder offer alone does not unlock cloud signing.
A development, ad-hoc or enterprise export is not a TestFlight upload. Check the signing and export requirements and your own Apple account and app record. We do not submit the listing or guarantee review approval.
Keep a small, reproducible evidence record
Build identity
Record the build ID, app version, Bundle ID, signing status and export method from the delivered artifact. Keep that record with the version you submit; a screenshot from another build is not evidence for this one.
Device behavior
Record the device and iOS version. Test cold launch, navigation, authentication, keyboard and safe areas. Exercise file uploads and payment paths that your actual website uses, including cancellation and error recovery.
Network behavior
Check what happens when the connection drops and returns. A useful recovery screen is not the same as an offline application. Do not advertise cached content, background activity or offline transactions unless those paths work.
Platform capabilities
Verify each claimed native integration on iOS. An Android OneSignal setting does not establish iOS push support, and an API name in a web page does not establish that the selected shell implements it.
Make the real product reviewable
Supply accurate screenshots and metadata, keep the backend reachable, and provide a working demo account or complete demo mode when needed. Explain non-obvious workflows in review notes. Check the relevant privacy, account and payment requirements for your app against Apple's current guidelines.
Describe only capabilities in the submitted build. Do not copy a generic note claiming Face ID, APNs, Keychain or offline support that you have not implemented and tested. Keep passwords and signing files out of public screenshots, logs and support messages.
Respond to a rejection with specific changes
- Preserve the reviewer's message and identify the affected workflow.
- Reproduce the issue on the submitted build, or ask for clarification when you cannot.
- Change the relevant product behavior and record how to verify it in the replacement build.
- Reply through App Store Connect with concise steps and evidence. Follow Apple's review and appeal guidance when appropriate.
A new version number or a longer app description is not evidence that the product problem was fixed. The final decision remains with Apple.