Read the rejection before changing the app
Open the submission in App Store Connect and read every issue, including attachments. Record the cited guideline, the reported behaviour, the device and operating system where supplied, and what Apple asks you to do. Treat each issue as a separate task with an owner and evidence of completion.
Distinguish a request for information from a defect in the submitted build. Apple's review-status guidance says you can reply directly when only information, credentials or server adjustments are needed. If the build itself needs fixing, upload and submit the corrected build. Clarify uncertainty before restarting review.
Keep a small rejection log. Include the original message, your diagnosis, the change, the test result and the reply sent to Apple. This gives the business owner and developer a shared account of what remains unresolved. A vague task called 'fix Apple rejection' gives neither person much to work with.
| What the message describes | First check | Evidence to prepare |
|---|---|---|
| Reviewer cannot sign in | Test the supplied account from a fresh session | Working access details and exact navigation steps |
| Crash or blank screen | Reproduce using the submitted build | Device details, logs and a repeatable test |
| Listing does not match the app | Compare each claim with the submitted version | Corrected copy or screenshots |
| Purchase cannot be completed | Run the purchase flow in Apple's sandbox | Product configuration and transaction test results |
| Feature appears absent | Check whether it exists and can be discovered | Navigation instructions or a tested implementation |
Make the app accessible to the reviewer
Apple's guidance on complete review information asks for usable demo credentials and explanations of the app's purpose, audience and business model. If your app has different account roles, provide access for each relevant role. Describe regional differences and any external services needed for the main experience.
Test the supplied credentials yourself without an existing session. Check whether an expired invitation, an empty workspace or a verification step blocks progress. Populate the account with fictional records that demonstrate the actual workflow. Write directions using the button labels visible in the submitted app.
For example, a booking app's review notes could explain how to open a sample appointment, change its details and view the result. Have someone unfamiliar with the product follow those directions. If they need a developer standing beside them, revise the instructions or interface before submitting.
Reproduce crashes and incomplete flows on real devices
Guideline 2.1 covers app completeness, including crashes and obvious technical problems. Apple's device-testing guidance calls for testing on physical devices and across the platforms where the app is available. A working simulator session is useful evidence, but it does not finish that job.
Ask the developer to test the submitted build with a fresh account and an existing account. Exercise the reported failure, then adjacent actions: returning to the previous screen, retrying a failed request, reopening the app and denying an optional permission. Record what happened and collect diagnostic logs where available.
For a blank dashboard, investigate whether the account lacks data, the server request failed or the interface failed to display the response. Those are different fixes. After the repair, repeat the original failing steps and the main customer journey. Include compatible iPad use if the app is available there.
Make screenshots and descriptions match the product
Apple's screenshot guidance requires images that show the app in use. Build the screenshot set around real tasks in the version being submitted. Avoid filling it with opening screens, decorative artwork or designs that have not been implemented.
Give marketing and development the same build to check. For each headline, identify the screen or behaviour that supports it. Remove roadmap promises from the description. If an image promotes a feature requiring an additional purchase, make that condition clear, as Apple's metadata guidelines require.
Check every submitted language and device presentation. A translated caption can promise something different from the original. An older screenshot can show a control that moved. Keep a simple inventory pairing each asset with its feature and build so the next update does not quietly reintroduce obsolete material.
Check both the purchase model and the purchase flow
Apple's payment guidelines generally require In-App Purchase for digital features consumed inside the app, with specific exceptions and storefront provisions. Physical goods and services consumed outside the app follow different rules. Map what you sell, where it is consumed and which storefronts you serve before choosing a payment approach.
Do not treat an external checkout link as a universal fix. Read the applicable payment provisions for your product and storefront. Explain the model in review notes, especially when customers arrive with an existing subscription or business account.
For StoreKit purchases, Apple reviews transactions in its sandbox testing environment. Test there before submission. Confirm that configured products load and that the purchased access appears after completion. Check cancellation, interrupted attempts and recovery of existing access. Keep the results with the submission record.
A product that works only in a local test configuration needs further checking. Compare the identifiers used by the app with App Store Connect and confirm the relevant purchase items are included for review. Apple's sandbox guidance also explains that purchases do not need prior approval to function during review.
Align privacy answers and permission prompts with behaviour
Apple's App Privacy Details documentation requires information about data practices, including relevant third-party code. Ask development to inventory analytics, advertising, diagnostics and other services in the app. Use Apple's definitions when deciding what must be disclosed. Do not answer the questionnaire from the marketing brief alone.
Make a working sheet with each data type, its purpose, destination and associated service. Compare that sheet with the app's behaviour and the submitted privacy answers. Investigate disagreements before editing the label. Changing an answer without understanding the underlying collection leaves the actual problem unresolved.
Permission prompts need concrete explanations. Apple's purpose-string guidance calls for describing how the requested resource is used. For a receipt-scanning feature, explain that the camera captures receipts for expense entries, if that is what the app actually does. Avoid a generic request for access to improve the experience.
Test the prompts in each supported language and try declining access. Confirm that the explanation and resulting behaviour agree. This is general information, not legal advice; the checks here concern Apple's submission requirements. hehe.software helps implement the technical side and does not certify legal compliance.
Make account deletion a complete workflow
Apple requires apps supporting account creation to let people initiate account deletion within the app. Its account-deletion guidance says temporary deactivation is insufficient. If completion happens on a website, the app must lead directly to the deletion page.
Test with a disposable account. Locate the control, complete any confirmation, submit the request and check the outcome. Inspect the backend result as well as the confirmation screen. A button labelled Delete account is only the start of the implementation.
Write review notes explaining where the control sits and whether processing takes additional time. Keep the user informed about that process. Ask the developer to verify associated authentication handling, including token revocation where Sign in with Apple is used, as described in Apple's deletion guidance.
Address minimum functionality and community features
Guideline 4.2 expects useful functionality beyond a repackaged website. If Apple questions the app's value, identify the repeat task it helps someone complete. Show that workflow clearly. If it does not exist yet, a more enthusiastic description will not create it.
Consider a service business app that currently displays opening hours and a contact button. A useful product direction might involve managing appointments or preparing information for a visit. Choose additions because they solve a customer problem. Adding unrelated device features makes the product harder to explain.
For user-generated content, guideline 1.2 requires filtering, reporting, blocking abusive users and published contact information. Test these controls with sample accounts and assign responsibility for incoming reports. Include the navigation steps in review notes. A report button needs an operational process behind it.
Reply with evidence, then choose whether to resubmit
Use Reply to App Review in App Store Connect to address the message. Apple allows supporting attachments. Structure the response around each reported issue: explain what changed, where it can be checked and what you tested. Keep credentials in the designated review information rather than public release notes.
For a repaired crash, identify the affected action, the corrected build and the device used to repeat the test. For a discovery problem, supply the exact route through the interface. Avoid claiming the whole app is fixed when you have verified only one flow.
If clarification does not resolve a rejection and you believe the app follows the guidelines, Apple's appeal guidance provides a route to the App Review Board. Explain the disputed requirement and supporting evidence. Use the appeal process for that disagreement; keep ordinary questions in the submission conversation.
Example response outline, to complete with your actual evidence: identify the issue and guideline from the review message; state whether the correction is in a new build, metadata or the server; give the exact build and retest device; list the navigation steps and test credentials; explain any remaining reviewer question. Describe what you verified. An appeal or clarification still needs evidence, and a response template is not an approval shortcut.
- Account for every issue in the rejection message before proceeding.
- Verify the selected build contains the changes you describe.
- Retest review credentials, sample data and required services.
- Repeat the failing steps and the main customer journey.
- Compare screenshots, descriptions and privacy answers with the build.
- Check applicable purchase, permission and account-deletion flows.
- Update review notes with precise access and navigation instructions.
- Record unresolved questions and send them before restarting review.
How hehe.software can help
hehe.software is a small, independent web and app studio based in Vancouver, working remotely across Canada and the United States. We help with iOS development, App Store launches and fixes to apps we did not build. Our own App Store products include Rain, Tifo and Broski; these are owned products, not client work. Email mwe@hehe.software with the rejection message and a short explanation of the app. We can scope the technical investigation and repair work, then provide a fixed quote or hourly estimate.