5.1.1

Hi, I recently submitted an app to the App Store, but it was rejected for the following reason: Guideline 5.1.1 - Legal - Privacy - Data Collection and Storage Issue Description The app requires users to register or log in to access features that are not account based. Specifically, the app requires users to register before browsing products. Registration can only be required for account-based features like adding to cart or checking out. Next Steps Revise the app to let users freely access the app's features that are not account based. The app may still require registration for other features that are account based. Resources Learn more about requirements for apps with account-based content and features in guideline 5.1.1(v) - Account Sign-In. After receiving this, I updated the app to allow guest users. Now guest users can use the app freely and choose to login if they want to access their account and account features. However, I'm still receiving the same rejection for the same reason. Wh

Hi everyone, I’m working on the JOOD Mobile App, which is an employee/partner-privileged app (not public) for Qatar Foundation (QF) and its partner entities. The app uses corporate domain login / Microsoft login, no public sign up. Apple Review rejected the app, pointing out violations under: Guideline 3.2 – Business — App intended for use by a specific organization(s), but distribution selected as public. Guideline 4.0 / 4.8 – Design / Login Services — The user is forced to leave the app to log in via default browser; no in-app flow or “Safari View Controller” type embedded browsing. Also, uses third-party login, but doesn’t offer an equivalent login option that limits data collection to just name + email, allows email privacy, etc. Guideline 5.1.1(v) – Data Collection and Storage — App allows account creation but there is no user-initiated delete account option. I want to fix these rejections and resubmit. Below are the questions / ideas I have, and I would really appreciate feedback / suggestions

Hi, I developed an app and submitted it to the App Store, but it was rejected for the following reason: Guideline 5.1.1 - Legal - Privacy - Data Collection and Storage Issue Description: The app requires users to register or log in to access features that are not account-based. Specifically, the app requires users to sign up before accessing the app. Apps may not require users to enter personal information to function, except when directly relevant to the core functionality of the app or required by law. Next Steps: Revise the app to allow users to freely access features that are not account-based. The app may still require registration for features that are account-based. Resources: You can learn more about the requirements for apps with account-based content and features in guideline 5.1.1(v) - Account Sign-In. After receiving this, I updated my app and added a Continue as Guest button on the login screen. With this button, users can navigate the app without signing up. Only commenting, up

Hello everyone, Our app, NumberBox, was rejected due to Guideline 5.1.1, with the review team saying it “collects information from public sources to build individual profiles.” We want to clarify: All data is 100% user-reported. Users voluntarily submit phone numbers (spam, scam, or telemarketing) and assign tags through the “Add Tag” feature. No data is collected from public sources or user contacts. No profiles are built automatically. All user submissions are reviewed by our support team before being displayed. The sole purpose of NumberBox is to help users avoid unwanted or scam calls, not to collect personal data. Our updated Privacy Policy is here: https://numberbox.app/privacypolicy Has anyone encountered a similar issue with Guideline 5.1.1? Any guidance on how to clearly communicate this to App Review would be greatly appreciated. Thanks in advance!

Guideline 5.1.1 - Legal - Privacy - Data Collection and Storage The app does not meet all requirements for apps that offer highly regulated services or handle sensitive user data. Specifically: The account that submits the app must be enrolled in the Apple Developer Program as an organization, and not as an individual. The guideline 5.1.1(ix) requirements give users confidence that apps operating in highly regulated fields or that require sensitive user information are qualified to provide these services and will responsibly manage their data. Next Steps To resolve this issue, it would be appropriate to take the following steps: The app must be submitted through an Apple Developer Program account enrolled as an organization. You may either enroll in a new Apple Developer Program account as an organization, or request that your individual account be converted to an organization account by contacting Apple Developer Support. Please note that you cannot resolve this issue with documentation sho

Private relay emails are not being delivered, even though we've followed the guidance here, https://developer.apple.com/help/account/capabilities/configure-private-email-relay-service/ iCloud, gmail etc. get delivered fine but as soon as its a private relay email address they get bounced as unauthorized sender. We've tried a couple of domains but here I'll document test.x.domain.com We have registered domains (test.x.domain.com), also the sender communication emails just to be safe (noreply at test.x.domain.com). Passed SPF Authentication, DKIM Authentication. ESP account shows as all green checks in mailgun. Is there any way to track down what the actual rejection reason is? { @timestamp: 2025-08-20T14:30:59.801Z, account: { id: 6425b45fb2fd1e28f4e0110a }, delivery-status: { attempt-no: 1, bounce-type: soft, certificate-verified: true, code: 550, enhanced-code: 5.1.1, first-delivery-attempt-seconds: 0.014, message: 5.1.1 : unauthorized sender, mx-host: smtp3.privaterelay.appleid.com, sessio

Hi, I want to consult about this: This is regarding [Guideline 5.1.1 - Legal - Privacy - Data Collection and Storage] My client is asking if we can remove the new account registration through the iOS App, so we won't need to ask for mobile and birthdate. For iOS App users, new users will register through the website (or through a non-Apple related app). After registering through the website, they can access the iOS App using the credentials created through another method. Will that be a problem with Apple policies? My client said they need the Mobile number and birthdate for verification. Thanks in advance for the help and guidance. Best regards, Sophia

Hello Apple Developer Community, We’re running into a challenge with App Review related to Guideline 5.1.1 (Data Collection and Storage), and are hoping to get insights from others who may have encountered something similar. Our app is built entirely around account-specific functionality. Each user is issued a unique QR code tied to their account, which enables and disables core functionality. This QR code is not generic - it’s unique to the user and is securely stored in our Firebase backend to support cross-device use and persistent access. App Review has flagged that requiring login violates Guideline 5.1.1, despite the fact that we have already moved the login step to occur after the user completes an in-app purchase, as per their previous guidance. Login is not used to gate purchasing, but it is critical for generating and linking the unique QR code to the user’s account. Beyond the QR code, our product roadmap includes multiple account-dependent features like usage tracking, goal setti

Hi there. I’m building a digital-well-being app for iOS 17.x that relies on the Screen Time API (FamilyControls / DeviceActivity.framework). Before we implement the server side, we’d like to confirm that the architecture below complies with current App Store Review Guidelines. Planned flow FamilyActivityPicker User selects an app set. we receive only opaque ApplicationTokens, no bundle IDs. DeviceActivityMonitorExtension Whenever usage of any selected app crosses a threshold, we increment a running daily total (integer minutes) stored in UserDefaults for our App Group. Server sync If the user completes a two-step opt-in (Settings toggle + confirmation dialog), we would POST only the aggregated daily total—never bundle IDs or app names—over HTTPS to our server, enabling cross-device dashboards and weekly reports. MonitorExtension currently allows URLSession / HTTPS; DeviceActivityReportExtension does not, per Apple’s sandbox docs. Users can disable sync or request deletion of their server data at any time. Que

We are trying to post a local news app. We want it to be a customized version of our news website, displaying news, agenda, local shop offers etc filtered by the towns and interests the user selects. The user needs to register first so that we can create a profile with their interests and filter the content accordingly. We've tried to explain this in several different ways, but the answer is always the same: We understand that you provide customized news to your customers. However, they should still be able to access the news articles prior to registration and only prompted to register once they decide to customize their news feed. The app's specific purpose is offering customized content, and we need the users to register for that customization. If we can't offer the customized filtering, the app has no sense for us. Anyone in a similar situation or any tip on h ow to explain this to App Review? Thanks in advance!

Issue Description One or more purpose strings in the app do not sufficiently explain the use of protected resources. Purpose strings must clearly and completely describe the app's use of data and, in most cases, provide an example of how the data will be used. Next Steps Update the camera and photo library purpose string to explain how the app will use the requested information and provide a specific example of how the data will be used. See the attached screenshot. Resources Purpose strings must clearly describe how an app uses the ability, data, or resource. The following are hypothetical examples of unclear purpose strings that would not pass review: App would like to access your Contacts App needs microphone access See examples of helpful, informative purpose strings. I submitted my app to review, and got this review message. When you clcik on you profile picture, you can view it, or change it. When you decide to change it, the app need permission for camera or galler (depending on which one you select) F

Hello Experts, I am in need of your help with this feedback from the App Reviewer. Issue Description: One or more purpose strings in the app do not sufficiently explain the use of protected resources. Purpose strings must clearly and completely describe the app's use of data and, in most cases, provide an example of how the data will be used. Next Steps: Update the location purpose string to explain how the app will use the requested information and provide a specific example of how the data will be used. See the attached screenshot. Resources: Purpose strings must clearly describe how an app uses the ability, data, or resource. The following are hypothetical examples of unclear purpose strings that would not pass review: App would like to access your Contacts App needs microphone access Feedback #2 Regarding 5.1.1, we understand why your app needs access to location. However, the permission request alert does not sufficiently explain this to your users before accessing the location. To resolve this

I want to clarify why both email and phone number are mandatory at registration, while still allowing users to log in with either method if one fails. Email Address (Collected at Registration) Account Creation & Verification: We use email to establish a unique, verifiable account for each user. This prevents duplicate or fraudulent profiles. Primary Communications: All booking confirmations, trip updates, support requests, and in-app chat messages between care seekers and carers are sent via email. This ensures users have a reliable record of every transaction and message. Phone Number (Collected at Registration) OTP-Based Security: We send a one-time password (OTP) via SMS during registration and login. This SMS-OTP step is critical to confirm that the user owns the provided phone number and to safeguard against unauthorized account access. Critical Trip Notifications: During a booked trip, carers and care seekers must receive time-sensitive alerts (e.g., gate changes, flight delays, check-in reminders)

我们提交的APP，始终无法通过审核； Guideline 5.1.1 - Legal - Privacy - Data Collection and Storage Issue Description The app requires users to provide personal information that is not directly relevant to the app's core functionality. Apps should only require users to provide information that is necessary for the app to function. If information is useful for a non-essential feature, apps may request the information but make it optional. Examples of app concepts and inappropriate required information: A general shopping app that requires the user's marital status A rideshare app that requires the user's gender Next Steps Update the app to not require users to provide the following personal information: National ID number Age Gender Resources 是不允许在注册阶段收集身份证号吗？

I have an iPad 1 running iOS 5.1.1, I want to downgrade it to iPhone OS 3.2 Does anybody have a way to downgrade unsigned .ipsw's or do I have to sign it myself?