Need assistance in implementing this device management feature. Our free plan lets each person use one special device. To make this work, we need to set up device control right after they log in. Because of this, we can’t let people use our app on more than one device or platform at the same time. If we don’t ask them to log in, we won’t know if they have already used their free device on Android or the Chrome extension. But Apple wants us to give people free access to things that don’t need an account. Can you help us find a way to do this?

I have submitted my app for review on 3rd of June 2025, and its status is stuck at 'Waiting for Review' since then until today (16th June 2025). I have requested expedited review and contacted support multiple times, but to no avail. I am posting it here hoping that it can get expedited as our stakeholders depend on this app update. Thank you. My support ticket are as follow : 102617392761

Hello Apple Developer Team, I am currently integrating In-App Purchases (IAP) in my iOS app and would like to get a clear understanding of the App Store Review Guidelines related to offering paid digital content. My app provides access to digital content/features after payment. I would like to know if it is permitted to: Navigate the user to an external browser (e.g., Safari) from the app to complete the payment via a web-based payment gateway (like Razorpay, Stripe, etc.), and then unlock content in the app after verifying payment on the server. In this case: No purchases are made directly within the app. The app does not use an embedded WebView for the payment. The payment page is loaded in Safari via a deep link or external redirect. Would this approach comply with Apple’s guidelines, or would it be considered circumventing IAP requirements? I want to make sure I comply fully with Apple's policies. Thank you in advance for any clarification. Best regards, Sayed Muhammed App Name: Dream Treasure

Hello everyone, I’m reaching out to seek advice and support regarding a confusing issue I’m experiencing with my app’s review process. App ID: 6744330283 Here’s the situation: Versions 1.0 and 1.1 of my app were approved and successfully published on the App Store. However, updates 1.2 and 2.0 have both been rejected for Guideline 4.3 – Spam. The rejection happens extremely fast – less than 10 seconds after the app goes “In Review”, it gets rejected. There is no indication that the reviewer even launched the app. This is very frustrating because: The app has real user reviews, In-App Purchases, and active paying users. My app is 100% original – it is not a copy or template-based app. Even worse, the review process for versions 1.2 and 2.0 took over 7 days before even starting, and then they were rejected instantly, again without being opened. I’m happy to cooperate and improve my app further, but I feel like this may be a misunderstanding or a mistaken flag by an automated process. Has anyone experienced something similar? Is there any way to get a more thorough manual review or speak directly with the review team? Thanks in advance for any guidance or shared experience.

Hello, I submitted my app (App ID: 6744330283) on May 21, 2025, and by May 28, it was still not reviewed. I contacted Apple via email and phone, and was advised to wait. Suspecting a possible issue with my account, I removed the app and resubmitted it on June 7, 2025. Today is June 13, and the app is still "Waiting for Review". Normally, app reviews are completed within 48 hours (or 5 days max). I’m concerned there may be an issue with my developer account or submission. Could someone from the Apple Review Team help escalate or check the status of this app? Thank you in advance!

We received a notice from App Review on June 8 requiring us to make some changes. We submitted an updated version on June 10, but the app has remained in the "In Review" status since then. As the review team mentioned that issues must be resolved within 14 days, we’re now getting a bit worried, since the deadline is approaching and there has been no further update. Does anyone know how we can help speed up the review process?

We received a notice from App Review on June 8 requiring us to make some changes. We submitted an updated version on June 10, but the app has remained in the "In Review" status since then. As the review team mentioned that issues must be resolved within 14 days, we’re now getting a bit worried, since the deadline is approaching and there has been no further update. Does anyone know how we can help speed up the review process?

Hey everyone, We recently submitted our new dating app, Rove Dating, and it’s been rejected under Guideline 4.3(b) — “Design: Spam.” I’d really appreciate your insights, especially from anyone who’s faced something similar or has experience getting nuanced apps approved in a saturated category. Before building Rove, we spoke to dozens of users of existing dating platforms. We consistently heard the same thing: people are deeply dissatisfied with current apps. They’re overwhelmed, burned out by swiping, and frustrated by endless choices and low-quality interactions. It became clear that the problem isn’t that there are “too many” dating apps — it’s that most aren’t adapting to how people actually want to date in 2025. We designed Rove to address those pain points head-on, with a totally different approach to matching, message limits, and emotional safety. We believe our app meaningfully improves the dating experience — but we’re having trouble getting that across in the review process. Below is the explanation we’ve been submitting, which we feel strongly communicates how Rove is different. If anyone has tips, feedback, or even just a second set of eyes on how we’re presenting this, I’d be grateful! –– Response to Guideline 4.3(b) – Design – Spam We respectfully disagree with the assessment that Rove Dating duplicates existing apps. Rove is not a clone of existing dating apps — it introduces original interaction mechanics and novel safety features designed to address the growing frustration users feel toward current dating platforms. ⸻ What Makes Rove Dating Unique Rove Dating is a highly curated experience that intentionally limits user engagement to foster more meaningful, emotionally safe interactions: Key Differentiators: • No Swiping or Infinite Browsing: Users see a small, rotating selection instead of endless feeds. • Limited Conversations: Each user can have only 3 active conversations at a time. • “Shoot Your Shot” Mechanism: • Men can initiate contact with a limited set of women. • If a woman declines, the man can try with someone else — if not, he must wait. • Women can only receive inbound messages, helping prevent message fatigue. This constraint-based system: • Reduces inbox overload (especially for women). • Encourages higher-quality, intentional messages. • Mimics real-life social dynamics — where opportunities are limited and meaningful. ⸻ Innovative Safety System: MPAA-Style Behavior Ratings Rove also introduces a first-of-its-kind safety feature inspired by the MPAA film rating system: • Male users are assigned a community-informed behavioral safety rating (e.g., G, PG, R) based on in-app messaging analysis. • Women can quickly assess a match’s tone, trustworthiness, and vibe before engaging. • This system encourages respectful behavior and promotes a safer, more transparent dating environment. This type of behavioral transparency does not exist in any other dating app currently on the App Store. ⸻ Conclusion Rove is not another swipe-based clone. It is a thoughtfully reimagined dating platform built around scarcity, respect, and intentionality. Its mechanics — from conversation caps to safety scores — are fundamentally different from other offerings in the App Store’s dating category. We hope you’ll reconsider Rove on the merits of its original features, purpose-driven design, and unique safety innovations.

Dear Apple Team, We would like to bring to your attention an issue regarding our app release schedule. To prepare for our scheduled pre-order launch on June 13, we uploaded our app on April 30. However, that version was closer to a test build than the final release. In anticipation of the official launch, we submitted the final version for review on June 5. Unfortunately, by June 11, the review was still not complete, so we resubmitted the latest final build for review on June 11. Then, quite unexpectedly, the version we uploaded on April 30 was released on June 12 at 11:00 PM. In response, we urgently removed all release countries to stop further downloads. However, due to pre-order notifications, many users downloaded a version that was not intended for public release. Moreover, deleting the countries also canceled the pre-order setup, resulting in the loss of approximately 17,000 users. We would like to emphasize that the build intended for pre-order was clearly set to manual release, with a release date of June 13. Furthermore, that particular build had not even entered the review process as of June 12. We have attempted to reach out through various channels, including email, but have yet to receive a response. We are deeply concerned and have suffered significant damage as a result of this situation. May we kindly ask if something has happened on Apple’s side that might have caused this issue? We would sincerely appreciate your urgent review and support on this matter. Thank you very much.

Hello, Our new app keeps getting rejected against Guideline 5.1.2(i) - Legal - Privacy - Data Use and Sharing. Submission ID: 65088313-ab97-4557-bef9-8c1cd631e04d The reviewer comment: "The primary purpose of the app still is to encourage users to perform digital tasks in exchange for compensation, watch ads and/or perform other marketing-oriented tasks, which is not appropriate." Next Steps: "Review the app concept and incorporate different content and features." After thorough review of the mentioned guideline (5.1.2(i)) we think our app is totally compliant and transparent, and we feel the rejection reason is not valid neither justified on guidelines. Regarding the reviewer comment: On our app, ads are totally optional. Users do not have to watch any ad on our app to enjoy it's core functionality. We don't require users to perform digital tasks in exchange for compensation, watch ads and/or perform other marketing-oriented tasks. Regarding Guidelines 5.1.2 Data Use and Sharing (i): We don't use, transmit, or share someone’s personal data without first obtaining their permission. We provide access to information about how and where the data will be used in our Privacy Policy and Terms & Conditions, and is only shared with third parties to improve the app or serve advertising (in compliance with the Apple Developer Program License Agreement). User or device data from our app is linked to third-party data solely on the user’s device and is not sent off the device in a way that can identify the user or device, hence we aren't required to use App Tracking Transparency APIs. Our app does not require users to enable system functionalities in order to access functionality, content, use the app, or receive monetary or other compensation. Given these facts, we believe our app rejection is not fair as we are in good standing compliance-wise with App Store Review guidelines. Has anyone else faced this rejection reason before? Any advice on how to approach this situation? Any help would be greatly appreciated, as we have been dealing with the review process for over 2 weeks now...

Build is currently rejected but the submission status is marked as "complete" (even though it isn't). I think this is what's preventing me from replying to the reviewer who is now waiting on info from me. How am I supposed to reply to them if the option is no longer available? I already submitted another build - will they eventually just review that or not? If I expire the build that is rejected, will that get them to stop reviewing it?

We submitted our app for Review on June 3. The submission was put in "In Review" status on the same day. Today is June 10 and we did not receive any status update. Our customers are waiting for the release of our app. This is delaying our promised release date. Can someone review our app?

in review for long time Apple ID: 6742814997

Hello all, One of my app submission got rejected saying deletion feature wasnt available. We allow de-activate our user accounts after our customer support representative speaks with customer to confirm and then delete the account. But while submitting our app for release we got this message?? The app only offers to deactivate the account. Temporarily deactivating accounts is not sufficient to meet the account deletion requirement. Any help how to overcome this issue pls? Thanks K

Hello we just submitted our app one week ago. First submission was rejected and we have resubmitted it after resolving issues with it. but it has been more than 5 days. And we still haven't got any feedback from apple team. We need to publish the app ASAP. Thanks in advance for your help. Looking forward to hearing back from you.

My app uses Apple IAP. With the recent US external payment changes (May 2025), I plan to use Stripe via Superwall. Superwall allows me to remotely toggle my paywall for US users between Apple IAP and Stripe checkout without a new app build. Is it permissible to activate Stripe for new US users on an already live app version (approved with only Apple IAP) without first submitting a new build for Apple to review the Stripe integration? Or does this dynamic switch create a risk of takedown/compliance problems? Concerned about new users hitting an unreviewed Stripe flow during any potential review period for a new build. Seeking clarity on Apple's stance or community experiences. Thanks!

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) even if they’re not actively using the app. SMS ensures immediate delivery—even if a user’s internet connection is unavailable. Support & Emergency Contact: If there’s an urgent issue mid-trip (e.g., a missed flight, sudden cancellation, or a medical concern), our support team can reach users directly via phone to resolve issues in real time. Flexible Login Options Fallback Mechanism: If a user cannot access their email (e.g., server delay or no internet), they can request an OTP via SMS to log in. Conversely, if SMS delivery fails (e.g., network outage), they can choose to receive a OTP by email. This redundancy guarantees that users aren’t locked out due to a single point of failure. We believe both email and phone number are directly tied to our app’s security model, communication requirements, and overall user experience. All collection and usage details are transparently disclosed in our Privacy Policy (https://b4t.com/legal/privacy-policy) and User Terms and Conditions (https://b4t.com/legal/user-terms-and-conditions).

Hello, our submission rejected by the apple team and now we can't remove cancel the current submission. This is api response when we attempt remove: { "errors" : [ { "id" : "e069078e-4c57-4aa6-ab3b-913ddf9e6314", "status" : "409", "code" : "STATE_ERROR.ENTITY_STATE_INVALID", "title" : "Resource state is invalid.", "detail" : "Resource cannot be canceled at the moment, please try again later" } ] } We need to publish app asap and can't do anything because of this bug.

My application has been in "In Review" status since May 30, 2025, and it is still in that status today. Please check the status of my app, LS Tools. Our customers are waiting for the latest version

I’m trying to submit my app for review, but I’m currently blocked due to a recurring issue with in-app subscriptions. Both of my auto-renewable subscriptions (premium_monthly and premium_yearly) are marked as “Waiting for Review”. However, I am still seeing the blue box stating that “your first subscription must be submitted with a new app version.” Despite creating a new version (1.0.1) and uploading/selecting a new build , I am not seeing the “In-App Purchases and Subscriptions” section on the version page, and I therefore cannot link the subscriptions before submitting. This issue is blocking my ability to submit the app for review. Any help to resolve this would be greatly appreciated.