BeSafe experience · App Review

App Store Guideline 1.5 rejection: what to check and fix

An App Store rejection gives you a concrete gap to investigate. Start with what the reviewer could not verify, reproduce that situation and fix its cause before changing unrelated parts of the app.

By Hugo Bertin8 September 20264 min read

1. Identify the requirement involved

Apple places Guideline 1.5, Developer Information, in the Safety section. It concerns people being able to contact the developer and find accurate, current support information in the app and through its support URL.

A blank page, a broken redirect or missing contact details can prevent that. A separate privacy requirement may also apply to a privacy page. Read the actual rejection instead of assuming that every broken link falls under the same rule.

2. What happened with BeSafe

The BeSafe experience documented in the guide includes a Guideline 1.5 rejection involving a support or privacy URL that did not work correctly in one or more App Store Connect localisations. The sequence was rejection, correction of the page, resubmission and approval.

The practical lesson is that public pages and store metadata form part of the submitted experience. A reviewer should not need your browser session or knowledge of the project to find the information. This case illustrates a failure to check those entry points; it is not a prediction of how every review will end.

3. Reproduce the reviewer’s starting point

Note the rule, language and URL mentioned in the message. Open the exact address in a private window and on a phone, without signing in as an administrator. Follow redirects and confirm that the destination contains usable contact details.

Go through each active App Store Connect localisation. Do not assume a correct URL in the primary language guarantees the other fields are correct. Compare the identity shown on the support page with the app and store listing.

Public HTTPS pages load successfully.
Contact information is visible and usable.
Essential support information does not require an administrator login.
Each configured language leads to the intended page.

4. Fix the reported cause and repeat the check

Correct the affected page or field, then repeat the same visit from outside your normal session. Check the actual content as well as whether the server responds: a page can load successfully while still missing the information a user needs.

A public-page correction is different from changing the binary. Establish what needs updating in your case instead of rebuilding automatically. Keep unrelated features out of the correction so you can clearly explain its effect.

5. Send a factual response

Use the review conversation to explain the cause, the correction and where it can be checked. For example, describe which localised support URL was corrected and where the contact information now appears. Use only details that match your actual fix.

If the decision seems mistaken, ask a precise question and provide relevant evidence. Apple also provides an appeal process. A successful response is not a formula: its value comes from making the specific issue easy to reassess.

6. Add the failure to your release checklist

Repeat the public-link and localisation check before future submissions. Include support contact details and reviewer access in the same record as the build tests. A small repeatable check is more useful than relying on remembering an earlier rejection.

Save the original message and the verified correction. You will have a concrete example for the next release and a faster starting point if a similar issue appears again.