Hello Everyone, For the second time in 3 months, I am seeing my app getting stuck in 'Waiting for review' state for weeks. I wrote to apple support and got an email 11 days ago saying they have initiated expedited review of the version review. But still I see no progress with the review and status is still waiting for review. I sent emails 2-3 times after that but no response. Did anyone else face this and what else can I do now? Thanks

I've been stuck on Guideline 2.3 for two weeks now and I'm running out of ideas. My app is iPhone-only (UIDeviceFamily = [1]) and has been on the App Store since January. Version 2.1.9 passed review fine. The only change in 2.1.10 is adding two DeviceActivity extensions — a DeviceActivityMonitor and a DeviceActivityReport — for screen time-based stress detection. Every build since then gets rejected with the same message: "The UIRequiredDeviceCapabilities key in the Info.plist is set up in such a way that the app will not install on the device used in review." Review devices: iPhone 14 Pro, iPhone 17 Pro Max, iPad Air M3. Here's what I've tried across 13+ submissions: UIRequiredDeviceCapabilities as ["arm64"] (array) — rejected Empty array [] — rejected Removed the key entirely — upload validation fails, Xcode re-injects arm64 anyway Post-build script to force ["arm64"] — rejected Dictionary format {"arm64": true} — rejected Added com.apple.developer.family-controls to extension entitlements — rejected Enabled Family Controls (Distribution) on extension bundle IDs — rejected Fixed CFBundleVersion mismatch between host app and extensions — rejected Set TARGETED_DEVICE_FAMILY=1 on all targets including extensions — rejected Tried GENERATE_INFOPLIST_FILE=YES with minimal plists — rejected Tried ExtensionKit type for the report extension — rejected In the exported IPA, every target has UIRequiredDeviceCapabilities = ["arm64"] and UIDeviceFamily = [1]. The entitlements, provisioning profiles, and code signing all look correct. arm64 is supported on every review device they listed. The previous version (2.1.9) without DeviceActivity extensions passes review with the exact same UIRequiredDeviceCapabilities and signing configuration. Has anyone shipped an app with DeviceActivityMonitor + DeviceActivityReport extensions successfully? Is there something specific about these extension types that affects device capability validation? Or is there a known issue with the review system and FamilyControls extensions? I've replied to the review team multiple times asking which specific capability is causing the failure, but the response is always the same generic template. Any guidance would be really appreciated — I'm completely blocked on shipping this update.

I’m running into an App Store Connect issue and I’m trying to figure out whether this is a build configuration problem on my side or a backend issue in App Store Connect. When I try to save my app version after selecting a build, App Store Connect fails and DevTools shows this request failing: PATCH /iris/v1/appStoreVersions/ with a 409 Conflict. The response body is: Json { "errors": [ { "id": "af484f56-8f7d-4338-a04a-2aeda858ace1", "status": "409", "code": "ENTITY_ERROR.RELATIONSHIP.INVALID", "title": "The provided entity includes a relationship with an invalid value", "detail": "The specified pre-release build could not be added.", "source": { "pointer": "/data/relationships/build" } } ] } A few details: The issue seems to happen with all uploaded builds, not just one The builds finish uploading and appear in App Store Connect I’ve already checked and corrected my version/build number setup I created a fresh Release archive I uploaded a new build I removed the previously attached build and tried attaching the new one App Store Connect still refuses to save the version once a build is selected I’ve already verified that the app version and build number in the project appear to be set correctly. At this point I’m trying to understand: Any suggestions on specific things to check would be appreciated. Thanks.

Hello App review Team, Our app has been submitted for up to a week now. Submission id - 8b32ad4d-9912-4f25-837c-13b15323a258. Kindly review. Thank you

Hi, My iOS app, "GNYS" (Apple ID 6761986315) was submitted on 14 April 2026 and has had the status, "Waiting for Review" since then - now for 24 days. This is a first submission. I previously contacted Apple Support but haven’t received a clear explanation or timeline. I’d really appreciate it if the App Review team could look into this or advise on whether any additional information is needed from my side. Thank you.

can someone please help with the review ? Hi everyone, I submitted my app ZEROCAUGE PRO on April 21st. It has been 16 days and the status is still "Waiting for Review." This is impacting real users and a live business. Paying coaches and athletes are waiting daily to use this platform. Is anyone else experiencing this? And has anyone found a way to actually get Apple to respond? — James | CreateTitan (ZEROCAUGE PRO)

I have a new desktop software submission for macOS. It has to do with designs. The application serves two different roles of users. If they select the design leader role, they will get to create design projects. If they select the design follower role, they will not be able to create design projects. But they will get to view ones from the design leader. When the application starts up, it will prompt the user to select a role. If they click on the role acceptance button, they will be prompted for confirmation. The application also comes with a built-in tutorial that explains that design followers will not be able to create design projects. I knew the reviewer will play dumb and reject this software submission after selecting the follower role by claiming that he or she cannot create a design project. So I've given repeated warnings under Apple Review Information, telling them to select the design admin role if they want to test-create design projects. But they still fail and play dumb by starting that he or she cannot create one. The screenshot the reviewer provided me with indicates that he or she has indeed selected the user role. What's the point of this playing-dumb cycle of stupidity? No matter how many filters I place so that they won't select a wrong role, reviewers still manage to play dumb and fail. I already waited for 5 1/2 days for this new submission to be reviewed. Why do they reject every single new submission I make? Reviewers are wrong 6 or 7 out of 10 times. What a waste of time and resources... I think I'm infected with the mad cow disease.

Our app is stuck with "Waiting for review" for 4 days so far after rejection. We have to resubmit it yesterday, but more than 24 hours have passed and still nothing. Submission ID: 05e2667a-5641-4fbf-af44-aff94b03ae11

Hi to you all, I have a problem with setting up a subscription for an app for the first time. I keep getting a rejection with the message under Guideline 2.1(b) that “one or more of the In-App Purchase products have not been submitted for review.” I don’t know what to add anymore. I only have two monthly subscriptions. I set them up and selected them in the version description and submitted the package. There‘a not more information what exactly is missing. The only other information is the following: “Note you must provide an App Review screenshot in App Store Connect in order to submit In-App Purchases for review.” I’d be glad to get some advice.. Thank you in advance for your help!!

I launched my app on the App Store and Google Play about two months ago and despite improving the icon and screenshots I have only reached around 40 downloads which makes me believe ASO is my main challenge. I started using ASO tools like TryAstro and AppTweak but the keyword metrics such as volume 39 and difficulty 0 are confusing so I would appreciate guidance on interpreting this data and on effective ASO strategies for a new app with minimal downloads or ratings.

I’m building a macOS app with a MailKit extension. The containing app needs to show whether the Mail extension is enabled and actually being invoked. Currently the extension writes a “last seen” timestamp to app group defaults when Mail invokes it. The containing app reads that timestamp and shows a waiting/active state. During App Review, this behaviour was challenged: enabling the MailKit extension in Mail Settings does not immediately change the state reported in the containing app. The extension is only invoked when Mail receives or reloads messages, so the main app cannot confirm it is active at the moment the user enables it. The review challenge is that App Review may enable the extension, open Mail, select existing messages, and still see the containing app stuck in a waiting state. From what I can tell, selecting old messages does not reliably cause Mail to invoke the extension. I looked for a direct API like: let isEnabled = try await MEExtensionManager.shared().isEnabled But I do not see any public MailKit API that reports whether the extension is enabled in Mail Settings. MEExtensionManager seems limited to reload-style APIs such as reloadVisibleMessages. Questions: Is there a supported way to check whether a MailKit extension is enabled? Is “first extension invocation” the expected confirmation signal? Can reloadVisibleMessages be relied on during review, or can Mail skip/throttle old messages? Is the right App Review instruction: enable the extension, quit/reopen Mail if needed, then send a new test email? If possible, I want the app to report that the extension has been enabled as soon as the user turns it on in Mail Settings, even if Mail has not invoked the extension yet, but I do not see a public API that exposes that enabled state.

I'd appreciate input from anyone who has shipped a multiplatform productivity service (web + iOS + Android) where the iOS app is free and the website handles subscriptions. We just went through several review cycles on this and want to make sure we end up on the right pattern long-term. The setup Cross-platform productivity SaaS. Users sign up and subscribe on the web. The iOS app is fully free. No IAP, no upgrade UI, no pricing screens, no paywalls, no plan-tier badging. iOS exists primarily for capabilities a browser/PWA cannot deliver on iOS: native geofencing and native phone-call detection, plus on-the-go time capture. The same account a user has on the web is the account they sign into on iOS. The question For a multiplatform service like this — what's the safest, App-Review-defensible pattern for the iOS app's relationship to the user's web subscription tier? There appear to be two patterns in the wild: Tier-identical iOS — every iOS user, regardless of their web plan, sees an identical feature set on iOS. The iOS app surfaces nothing tier-specific. Web subscribers don't gain anything on iOS for being subscribers. Tier-aware iOS under 3.1.3(b) — Free users see a base feature set; users who already paid on the web see additional features mirroring their web account, framed under Multiplatform Services. What we learned Pattern 2 reads naturally from 3.1.3(b)'s text about apps "operating across multiple platforms" letting users "access content … acquired … on … your web site." We initially built and submitted with pattern 2. The piece we underweighted is the "also" in 3.1.3(b): "provided those items are also available as in-app purchases within the app." App Review's reading is that 3.1.3(b) only attaches if IAP is also offered in the iOS app for those items. If IAP is not offered, "Pro features visible to paid web users on iOS" is read as 3.1.1 (paid digital content accessed in-app without IAP), regardless of how the entitlement was granted. We resolved it by switching to pattern 1 — tier-identical iOS — which made the question moot. The product cost of pattern 1 Worth flagging for anyone weighing this themselves: pattern 1 (tier-identical iOS) creates a real and visible feature divergence between iOS on one side, and Android + web on the other. On Android we surface the user's paid-tier features just like the web does — there's no equivalent guideline forcing tier-uniformity on the Play Store side. So a Pro user on the same account sees a meaningfully different app on iOS than on their other devices. That's the trade we accepted to be unambiguously compliant with 3.1.1, but it is a trade — not a free move. Users notice. Support tickets will reflect it. For an internal stakeholder asking "why is iOS missing X," the honest answer is "App Store rules around paid digital content, with no IAP path that fits our pricing model." Specific things I'd love input on For other multiplatform services without IAP — has anyone defensibly shipped pattern 2 in the last ~12 months? If so, what was the framing? Is there a documented carve-out under 3.1.3(b) for genuinely free iOS apps, or has the "also available as IAP" language been read strictly across the board? For apps that took pattern 1 (tier-identical iOS): did you find any side-effects (e.g. App Store reviewers questioning the value of an iOS app that doesn't differentiate by plan)? For teams who took pattern 1: how did you communicate the iOS / Android feature gap to users? In-app message, FAQ, just leave it implicit? Are there cases where a phone call from App Review (offered in the rejection email) clarified this faster than the written back-and-forth? What I think the takeaway is, for posterity For a free iOS app fronting a cross-platform paid service, tier-identical iOS is the unambiguous safe harbour today. 3.1.3(b) appears to require IAP to be offered before it can be cited as cover for tier-aware behaviour, even if the user paid elsewhere. If anyone has a recent counter-example I'd genuinely like to see it — it would be useful for the next thread someone Googles. Thanks in advance.

Issue Description We noticed the app shares a similar binary, metadata, and/or concept as apps submitted to the App Store by other developers, with only minor differences. Next Steps Since we do not accept spam apps on the App Store, we encourage you to review the app concept and submit a unique app with distinct content and functionality. Resources Some factors that contribute to a spam rejection may include: Submitting an app with the same source code or assets as other apps already submitted to the App Store Creating and submitting multiple similar apps using a repackaged app template Purchasing an app template with problematic code from a third party Submitting several similar apps across multiple accounts Learn more about our requirements to prevent spam in guideline 4.3.

My app has been rejected twice, noted that the app is a financial app (banking app). The latest reply from Apple is provided below. "Issue Description The app provides loan services but the domains listed on the app's Product Pages are not clearly under your control or ownership. Since users may use these domains to contact you to request support, the domains used on the Product Page for loan apps must be under your control or ownership. Next Steps Update the Product Page metadata in App Store Connect to only include domains that you both own and are used as email domains for Apple Accounts registered to your developer account. You can review the email domains and Apple Accounts registered to your developer account in the Users and Access section of App Store Connect. Account Holder and Admin users should use emails with domains that identify the company providing loan services. Please note that apps used for financial trading, investing, or money management should be submitted by the financial institution performing such services, as required by App Review Guideline 3.2.1(viii)." Any suggestion?

We've a game that the first version has published 45 days again with a quick review and direct approve. After that initial version, we've made some big updates and additions as well as some bug fixes to get ready to officially publish our game, and market it. However, with my first update, it waited in the review queue for 2 weeks, which I then cancelled, make some bug fixes, and sent to review again since I heard that this can fix the process sometimes. Even after that, we've been waiting for 3 weeks and still no updates. I've also applied for Expedited Review since this is getting urgent after waiting more than a month. I hope someone from Apple Support team will see this and help me with the issue.

I submitted an app update for review yesterday and got rejected on the same second the app went to "In Review": In Review: Date: Mon, 4 May 2026 23:19:24 +0000 (GMT) From: App Store Connect App Crash Rejection email: Date: Mon, 4 May 2026 23:19:24 +0000 (GMT) From: App Store Connect No crash log, no device information. 20 TestFlight testers with no crashes and we tested on a range of devices and iOS versions as well. I replied to the review asking for the crash log and device information. But was it a custom to have the crash log and device information attached to the crash rejections? The first one for us, so we are not sure. We are re-testing and fixing speculatively the risk points. But same second In Review > Rejection with crash reason with no crash log and no device information, looks very strange to us.

Hi Apple Team, I would like to ask if it is normal for the “Waiting for Review” status to take 70 hours. I have already opened a ticket today, but it seems I may need to wait another 48 hours or possibly longer. Apple ID: 6764268650

Hi everyone, I am developing an app for a sport event in my area, which would provide live updates and notifications to participants and viewers, the event is coming up in 3 days and I thought I'd be able to have the app ready in the App Store by now, given the "on average, 50% of apps are reviewed within 24 hours and over 90% of apps within 48 hours" in the initial email message. Unfortunately, since a week ago where I uploaded my first version, it has been stuck in "Waiting for Review". I sent an expedited review request, but that did not seem to change anything. Looking through the forum I have been able to see others having the same issue, I'd appreciate it if someone from Apple could look into this and tell me why the review is stuck, if there's anything I need to do from my end. App ID: 6764243507 Thank you!

Hello! I submitted a new version of my app for review yesterday, and the status has been stuck on In Review for over 26 hours. In our previous updates, the review process was much faster. It is very important for us that this review does not get delayed further as it contains critical compliance updates for Guideline 5.3.4. My App Apple ID: 6761430958 Thank you in advance for any advice or investigation!

Hi everyone, I am looking for some insight from anyone who has dealt with a long "In Review" session recently, especially for apps in complex categories like prediction markets or finance. The Situation: Our app was previously rejected under Guideline 5.3.4 (Gambling/Prediction Markets). We submitted a formal appeal with a very detailed compliance brief and a comprehensive demo video to show our non-custodial architecture. The build went "In Review" exactly 24 hours ago. This is a standard (non-expedited) submission, but since the status hasn't moved in a full day, I wanted to see if this is common for apps that are under "compliance audit." App Details Name: Clover: Predict with Friends App ID: 6761430958 Bundle ID: fun.clover.app Version: 1.2.0 (Build 19) Status: In Review (24+ hours) What we have already tried Confirmed there are no unread messages in the Resolution Center. Verified that all testing credentials and demo videos are functional. Filed a formal App Status Inquiry via Developer Support. Questions for the community For those in "gray area" categories (prediction, crypto, etc.), how long does your "In Review" phase typically last for a standard submission? Given the 5.3.4 context, does a 24-hour session usually mean it's being escalated to a more senior reviewer or a legal lead? Is it common for standard reviews to stay "In Review" across a weekend or multiple business days? I would love to hear from anyone who has navigated a similar deep dive review. Thank you for any advice or shared experiences!