Guideline 1.5 Developer Information: how to fix a Support URL rejection

What Guideline 1.5 actually requires

Guideline 1.5 sits in the Safety section of Apple's App Store Review Guidelines. The core instruction: "Make sure your app and its Support URL include an easy way to contact you." Apple adds that this is particularly important for apps that may be used in the classroom, and that missing or outdated contact information "may violate the law in some countries or regions" (guidelines last updated June 8, 2026, checked October 2026).

In practice, App Review checks three things:

• The Support URL field in App Store Connect. It is required, can be localized and is displayed on the App Store. App Store Connect Help says it "must lead to actual contact information (legal address, email address, telephone number), as may be required by local law."
• Contact options inside the app. The guideline names "your app" too. A Contact button that does nothing can trigger 1.5 or a 2.1 App Completeness rejection.
• Wallet passes, if your app issues them: valid contact information from the issuer, and a dedicated signing certificate assigned to the brand or trademark owner of the pass.

A 1.5 rejection is usually not about your code. It's about whether a reviewer who opens your link, or taps "Contact us", can actually reach a person.

Common reasons apps get rejected under 1.5

The rejection message usually quotes the exact URL the reviewer opened. Start there. These are the typical triggers:

1. The URL doesn't load

A 404 after a website relaunch, a staging or preview link, an expired SSL certificate, a timeout or a redirect loop.

2. A generic homepage with no way to contact you

A marketing page that only links to the App Store, or an FAQ with no email address or form. Social media icons alone, or a blog comment box far down the page, can be flagged too: reviewers look for a direct contact method they can see without hunting for it.

3. Parked, expired or "coming soon" domains

A registrar parking page, a domain that lapsed between releases, or an "under construction" placeholder. This can happen when an agency registered the domain on its own account and stopped renewing it.

4. Support behind a login or permission wall

Help-desk portals that require an account, Notion or Google Docs pages that show "Request access", Discord or Slack invites. The reviewer is an anonymous visitor.

5. The wrong page in the field

• Your App Store product page (apps.apple.com/...) or a TestFlight link, which sends users in a circle.
• Your privacy policy or terms of service reused as the Support URL.
• A bare mailto: link or a PDF download instead of a web page.

6. Problems only the reviewer sees

A localization still pointing to an old domain, geo-blocking or bot protection that blocks Apple's network, a cookie wall hiding the content, or a contact form that errors on submit.

Rejected or stuck? Talk to an App Specialist – for free.

Book a free consultation call: we look at your rejection or setup, explain the fastest way forward and tell you honestly whether you need us. Prefer to hand it off? Book our AI-powered + human-powered service and we take care of it.

Free consultation call Book our service →

How to fix a 1.5 rejection step by step

1. Find the exact URL and localization. Compare the URL quoted in the rejection with the Support URL in each localization of the rejected version.
2. Open it the way a reviewer would. Private browser window, on a phone, on mobile data, no VPN, not logged in. Then check the redirect chain: curl -sIL https://example.com/support | grep -iE '^(HTTP|location)'. You want a final 200 on the page you expect, not a login or parking page.
3. Build a dedicated support page at a stable path like /support. Include:
   • the app name at the top,
   • a direct contact method visible without logging in: a support email address and/or a working contact form,
   • your developer or company name and, where local law requires it, postal address and phone number,
   • optionally a short FAQ and a link to your privacy policy.
4. Test the contact method end to end. Send a test email and submit the form on mobile Safari. Make sure the messages arrive.
5. Update App Store Connect. Go to Apps → your app → the iOS version in the sidebar → Version Information → Support URL and enter the full URL including https://. Switch through every localization with the language menu, fix each one, then click Save. The field can only be edited while the version has an editable status; Rejected and Metadata Rejected versions are editable, a live Ready for Distribution version is not.
6. Check that your identity is consistent. The name on the support page should match your seller name and copyright line. If you distribute in the EU as a trader, keep your Digital Services Act contact details (shown on EU product pages) current under Business → Agreements → Compliance → Digital Services Act.
7. Fix the in-app contact option if the message mentions the app itself. That part needs a new build.
8. Reply to App Review with what you changed and a screenshot, then resubmit.

In-app contact options that work on the review device

Add a "Help & Support" row to your Settings or profile screen, reachable without an account if possible. The classic mistake is a contact button that silently fails on the reviewer's device:

• UIKit: check MFMailComposeViewController.canSendMail() first. It returns false when no Mail account is set up. Fall back to your support web page or show the address with a copy button.
• SwiftUI: Link("Contact support", destination: supportURL) pointing to your web support page works whether or not a mail client is configured.
• Flutter and React Native: if you call canLaunchUrl or canOpenURL for mailto:, add mailto to LSApplicationQueriesSchemes in Info.plist, or the check returns false. Always handle the failure case.
• Test on a real device. iOS simulators don't include the Mail app, so mailto: links can't be tested there.

Load the support URL and email from one constant or remote config value, so a domain change doesn't leave a dead address in a live build.

Support URL vs. privacy policy URL and other contact fields

Mixing up App Store Connect's URL and contact fields causes rejections under different guidelines:

Support page and privacy policy can share a domain, but they should be separate pages. If App Review flagged the privacy link, follow our Guideline 5.1.1 guide instead. Apps with user-generated content also need published contact information under Guideline 1.2, which the same support page can cover.

Special cases: B2B, white-label apps and Wallet passes

Login-only B2B apps

Even if the app only works with a company account, the Support URL must be public. Publish a small page with your support email and a note on how existing customers reach their account manager.

White-label and agency-built apps

Users need the support channel of the company that publishes the app. Make sure the domain is registered to, and renewed by, the app owner, or the URL dies when the agency contract ends.

Classroom apps and legal notices

Apple calls out classroom apps specifically, so give teachers and school administrators a clear contact. Some countries also require a legal notice with name, address and contact details for commercial online services, such as Germany's Impressum. Put it on, or one tap away from, your support page.

Wallet passes

Set organizationName in pass.json to the real issuer and put customer service contact details on the back of the pass (backFields). Apple requires passes to be signed with a dedicated certificate assigned to the brand or trademark owner, so in practice the Pass Type ID certificate should come from the brand owner's own developer account rather than a reseller's or agency's.

How to respond to App Review

• Metadata Rejected: Apple's help says to edit the metadata and reply to the App Review message. You can resubmit the same build; no new binary is needed.
• Submission shows "Unresolved Issues": in Apps, click View App Review Issues & Messages, click Resolve next to the submission, edit the rejected item, then click Resubmit to App Review.
• In-app contact flagged: fix it in code, upload a build with a higher build number, select it on the version page and resubmit.

Keep the reply short: name the new URL, list the localizations you updated, describe the contact methods and attach a screenshot. If the page was temporarily down, say so and explain what prevents it now, such as domain auto-renewal.

Appeal to the App Review Board only if you believe the reviewer misread a page that worked and clearly showed contact information. Apple asks for only one appeal per submission that didn't pass review. For 1.5, moving the contact method to the top of the page and replying is usually faster than arguing that the reviewer should have scrolled.

How to prevent 1.5 rejections in future releases

Support URLs break between releases: domains lapse, websites get relaunched, help-desk tools change. Automate the check:

• Keep metadata in your repository. With fastlane deliver, the Support URL lives in fastlane/metadata/<locale>/support_url.txt. In the App Store Connect API it's the supportUrl attribute of each appStoreVersionLocalization.
• Add a CI/CD gate. Before each submission, request the support and privacy URLs for every locale. Fail on anything but a final 200 or when no email address or form is found, and flag redirects to an unexpected host.
• Monitor continuously. Uptime checks, domain auto-renewal and SSL certificate expiry alerts.
• Review content, not just status codes. AI-assisted checks can read the page like a reviewer: is the app named, is a contact method visible, does the company name match the seller? Add a quick human look before submitting.

If you'd rather not build this yourself, appsubmitter.io sets up the pipeline, metadata checks and submission, and handles App Review communication if something gets flagged. You can book a free consultation call to go through your rejection first.

Template: how to reply to App Review

Adapt this template to your situation. Keep it factual, short and specific – and only claim what you have actually changed.

Hello App Review Team,

Thank you for your feedback on Guideline 1.5 - Safety - Developer Information for [App Name], version [x.y] (build [build number]).

We have resolved the issue:

- The Support URL is now [https://www.example.com/app-name/support] for all localizations ([list of locales]). The page loads without a login and shows our support email address ([[email protected]]), a contact form and our company name and address.
- [The previous URL returned an error because our domain had expired. We have renewed it and enabled automatic renewal.]
- [The app now includes a "Contact support" option under Settings > Help & Support. If no Mail account is set up on the device, it opens our support web page instead.]

A screenshot of the support page [and the in-app contact screen] is attached. [The metadata has been updated. / New build [build number] has been submitted.]

Please let us know if you need anything else.

Best regards,
[Your Name]
[Company / Developer Name]

Checklist before you resubmit

• The Support URL returns a final HTTP 200 over HTTPS, tested in a private window on a phone without VPN or login.
• The support page names the app and shows an email address or working contact form near the top.
• Every localization of the version has the correct Support URL – none point to an old domain or placeholder.
• The Support URL is not your App Store page, a TestFlight link, your privacy policy, a social profile or a mailto: link.
• A test message sent through the form or to the support address actually arrived.
• The company name on the support page matches your seller name, and EU trader contact details are current if they apply.
• The in-app Help or Contact option works on a real device without a Mail account and falls back to the web page.
• The privacy policy URL is set separately under App Privacy and linked inside the app.
• Domain auto-renewal, SSL auto-renewal and uptime monitoring are enabled for the support domain.

Frequently asked questions

Official source: App Store Review Guidelines – 1.5 Developer Information. Store policies change regularly – always check the current version. This guide is independent advice and not affiliated with Apple or Google.