Hi everyone, We just received another App Store rejection under Guideline 3.1.3 - Business - Payments - Other Purchase Methods, stating that we are using in-app purchases to sell physical goods — specifically, a physical QR code sent to the user. However, in our latest build, this issue was already addressed: All physical QR code purchases are now handled entirely through Stripe Checkout, outside of the app. No consumable IAPs are used for physical goods. The purchase flow is completely optional - users can tap “Continue” to skip it and still use the app without ever engaging with Stripe or purchasing anything physical. We’re a small team trying to launch and are stuck in a loop where it seems like the rejection feedback might not reflect the latest build with not clear feedback from Apple. Has anyone experienced something similar? Would really appreciate any guidance or insight — or if anyone from Apple is here, we’re happy to jump on a call to clarify. Thanks in advance!

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 setting, emergency unlocks, and cross-device sync. None of this is technically possible without a persistent user account. We’re struggling to understand how to reconcile this rejection with the way our app is fundamentally architected. Account-bound functionality seems essential for delivering a secure and reliable user experience. Is anyone else facing similar confusion with this guideline? Thank you for your time and assistance.