Overview

Hello, our app Whishope (Apple ID 6813004940, version 1.0, build 7) was resubmitted on September 29 with the Guideline 1.2 user-generated content changes App Review asked for (submission ID 77f9de35-b2ce-45c7-9784-c2ee7f95aabf). It moved to In Review on October 1 and has stayed there since. Our server logs show no requests from the app between October 2 and today, so the review does not seem to have started on a device. We contacted App Review on October 3 (case 102984908361) and have not heard back. Is there anything we need to provide? We can share another demo account or a screen recording right away. Thank you.

Why are we doing this nonsense? We want to be able to run builds in a sandbox such that they can only see the paths they are intended to depend on, to improve reproducibility. With builds with a very large number of dependencies, there's a very large number of paths added to the sandbox, and it breaks things inside libsandbox. Either it hits some sandbox length limit (sandbox-exec: pattern serialization length 66460 exceeds maximum (65535), Nix issue #4119, worked around: Nix PR 12570), or it hits an assert (this report; also Nix issue #2311). The other options for sandboxing on macOS are not viable; we acknowledge sandbox-exec and sandbox_init_with_parameters are deprecated; App Sandbox is inapplicable because we aren't an app. Our use case is closer to a browser, and all the browsers use libsandbox internally. We could possibly use SystemExtension or a particularly diabolical use of Virtualization.framework, but the former API requires notarization which is close to a no-go for our use case as open source software: it is nearly impossible to develop the software on one's own computer, and it would require us to ship a binary blob (and have the build processes to produce one in infrastructure completely dissimilar to what we use today); it also requires a bunch of engineering time. Today, we can pretend that code signing/notarization doesn't exist and that we are writing an old-school Unix daemon, because we are one. The latter is absolutely diabolical and hard to implement. See this saga about the bug we are facing: Nix issue #4119, Nix issue #2311, etc. What is going wrong I can't attach the file fail.sb as it is too large (you can view the failing test case at Lix's gerrit, CL 2870) and run this: $ sandbox-exec -D _GLOBAL_TMP_DIR=/tmp -f fail.sb /bin/sh Assertion failed: (diff <= INSTR_JUMP_NE_MAX_LENGTH), function push_jne_instr, file serialize.c, line 240. zsh: abort sandbox-exec -D _GLOBAL_TMP_DIR=/tmp -f fail.sb /bin/sh Or a stacktrace: stacktrace.txt Credits Full credits to Jade Lovelace (Lix) for writing the above text and filing a bug. This is submitted under FB16964888

Hello, Summary: Navigation apps that support the CarPlay Dashboard and Instrument Cluster set UIApplicationSupportsMultipleScenes = true, which allows users to open a second app window on iPhone Duo. However, the app cannot close that window, because requestSceneSessionDestruction returns "This functionality is not supported for this device idiom." We would greatly appreciate your advice on the recommended approach. Our navigation app supports CarPlay, including the Dashboard and Instrument Cluster scenes. Following the example in the CarPlay Developer Guide, our scene manifest sets UIApplicationSupportsMultipleScenes to true. On the inner display of iPhone Duo, this setting also allows users to open a second window of our app (for example, via "Open in Split View"). Since our app is designed around a single main window, we would like to allow only one UIWindowSceneSessionRoleApplication scene while keeping all CarPlay scenes working. Here is what we have found so far (tested on the iPhone Duo simulator running iOS 27.1; we have not yet tested on a physical device): In a test app with UIApplicationSupportsMultipleScenes = false, a second window cannot be opened, as expected. With true, we detect the additional window scene in scene(_:willConnectTo:options:) and display a notice instead of the app UI. However, requestSceneSessionDestruction(_:options:errorHandler:) fails with the error "This functionality is not supported for this device idiom." As a result, we are unable to close the additional window programmatically. We would be grateful if you could help us with the following questions: Is UIApplicationSupportsMultipleScenes = true required for the CarPlay Dashboard and Instrument Cluster scenes, or can these scenes connect when it is set to false? If it is required, is there a supported way to keep the CarPlay scenes while limiting the app to a single phone window? If there is no such way, could you please advise on the recommended way to handle an unwanted second window scene on iPhone Duo, given that apps cannot destroy scene sessions there? Thank you very much for your time and help.

Hello, My Individual Apple Developer Program enrollment is still showing “Pending”. Initially, I submitted the membership purchase through the Apple Developer website, but the payment was not charged to my card. I contacted Apple Developer Support and was told that something was preventing the payment from fully processing. Because I do not have access to an iPhone, iPad, or Mac, I could not resubmit the enrollment through the Apple Developer app. Apple Developer Support then asked me to verify my identity. I uploaded both the front and back sides of my valid National ID Card and received confirmation that my documents were received and are being reviewed. My account is still showing: “Pending” and “Purchase your membership — To continue your enrollment, complete your purchase now.” I have followed up with Developer Support, but I have not yet received an update. Phone support is currently unavailable due to high call volumes. Enrollment ID: QXPD74J83M Support Case: 102978432103 Could an Apple Developer Support representative please check whether my identity verification has been completed and whether my enrollment or payment state needs to be manually reviewed or reset? I do not want to submit another membership purchase until Apple confirms that it is safe to do so. Thank you.

Coparenta (Apple ID 6780444442), iOS 1.0 build 32, was submitted for review on 29 Sep 2026 and has been in Waiting for Review for 8 days. Expedited review was requested on 2 Oct and acknowledged, and a Developer Support case was opened on 5 Oct (App Review status, case 102986219748). There has been no change of state, no message and no reply since. Apple states that 90% of submissions are reviewed in less than 48 hours. This app has already completed App Review successfully three times (29 Jul, 8 Aug, 25 Aug) and App Store Connect shows no issue with this build, so we have no way to tell whether the submission is progressing, stuck, or waiting on something from our side. Could someone from App Review confirm the status and, if anything is needed from us, tell us what? Even a short status message would help us plan. Thank you.

Hello, We are reaching out to ask for help in reaching someone who can look into our submission, which has not entered review, and our unanswered support requests. We are Ntroy, a small game studio based in Türkiye. Basketball Mates is our first game on the App Store. It has already been approved on Google Play, and we announced a launch date to our players before submitting to Apple. App details App: Basketball Mates Apple ID: 6797563341 Version: 1.0 (105) Timeline September 30, 2026: version 1.0 (105) submitted for review, together with its in-app purchases. Since then, the submission has remained in "Waiting for Review" and has never moved to "In Review." We submitted two expedited review requests and contacted App Review support twice. We have not received any response. This delay has forced us to postpone our launch and is significantly affecting our small studio. Could an Apple representative please help us confirm: Whether our submission is still in the review queue and being processed normally. Whether there is any issue with the submission, our account, or our in-app purchases that is preventing it from entering review. Whether any action is required from us — documentation, reviewer access, or metadata changes. Whether we should keep the current submission as-is or take any other step. We can act immediately if anything needs to change, and we can provide reviewer access or a walkthrough of the game if needed. Thank you very much for your help. Ntroy Team

Hi, I’m having an issue enrolling in the Apple Developer Program, and I’m hoping someone here has experienced something similar. I’ve already contacted Apple Developer Support three times. My first enrollment attempt was through the Apple Developer website because I couldn’t use the Apple Developer app at that time. My Mac was still running macOS Sequoia, and I couldn’t download/use the required app because of the macOS version requirement. On my first web enrollment attempt, I reached the payment stage, but Apple was unable to charge my card. I contacted support, and the representative told me there was an issue with the card and advised me to try again. I then made another enrollment attempt using a different card. This time, the payment appeared to go through successfully and I did not receive any payment error. However, the enrollment order was later cancelled. After upgrading macOS, I downloaded the Apple Developer app. At first, the “Enroll Now” button was disabled. Because my enrollment order had been cancelled again, I contacted Apple Developer Support for the second time. The representative said there was still a payment-related issue and advised me to try enrolling through the Developer app instead. After that call, the “Enroll Now” button became available. I then tried enrolling through the app and was able to go through the enrollment process, but at the final step I was unable to continue. I contacted support for the third time, and this time I was told that I’m no longer able to enroll in the Apple Developer Program. However, I was not given a clear explanation as to why. My concern is that the previous failed or cancelled enrollment attempts may have caused some kind of restriction or incorrect enrollment state on my Apple Account. I’m not trying to create multiple memberships or accounts. I only retried because the previous attempts failed, were cancelled, or because I was following the instructions given to me by Apple Support. Has anyone experienced a similar situation where multiple payment/enrollment attempts caused the account to become unable to enroll? If so, were you eventually able to get the enrollment reviewed, reset, or approved? Any advice would be appreciated.

I scan a room with RoomPlan API, then keep the same ARSession running (stop(pauseARSession: false)) and place RealityKit entities using the CapturedRoom wall transforms (wall.transform, wall.dimensions), parented to an anchor at the world origin. The camera position stays continuous, so tracking was not reset. But the entities do not sit on the real walls. The whole room appears shifted. What is the correct way to place content in the live AR session so it aligns with the scanned room?

Hi everyone, I'm looking for some advice or assistance regarding a recent app submission. My app has been stuck in the "Waiting for Review" status for over 7 days (submitted on Sep 30]). I already reached out to Developer Support via the Contact Us form 3 days ago (Case number: 102983210348), but I haven't received any reply or update yet. I also double-checked TestFlight and there are no crash issues on IPv6 networks. App Name: Make it Fit - Packing Puzzle App ID: 6796574369 Has anyone experienced this kind of delay recently? Or is there an Apple representative on the forum who can help look into this case? We just want to make sure there are no unexpected issues and are ready to provide any further information if needed. Any help or guidance would be greatly appreciated. Thank you!

I am working on In-App-Verification. I am able to add my cards manually in the Apple Wallet Sandbox. I am getting the option to Verify using App. When I click on the Verify Button, I am able to redirect to my Testflight App. But when I use the API PKPassLibrary().pass(withPassTypeIdentifier: passTypeIdentifier, serialNumber: serialNumber) its not returning me the expected Pass. It is infact giving an empty result The entitlements which I already have added are: com.apple.developer.pass-type-identifiers com.apple.developer.payment-pass-provisioning So I have below questions: Do I need to do something else for PassKit API's to work? Is it even possible to test In-App-Verification in the TestFlight App using sandbox Wallet? Is it possible to redirect user to debug and enterprise builds also as currently the redirection from Apple Wallet is not working for debug and enterprise builds? The PassKit API which I indicated earlier is working in debug build when I sideload from Xcode. But since deeplink from Wallet does not work for debug builds, I am not able to proceed with testing. What will be behavior in App-Store build production environment without using sandbox, by using real cards? Will it work there?

I am working on In-App-Verification. I am able to add my cards manually in the Apple Wallet Sandbox. I am getting the option to Verify using App. When I click on the Verify Button, I am able to redirect to my Testflight App. But when I use the API PKPassLibrary().pass(withPassTypeIdentifier: passTypeIdentifier, serialNumber: serialNumber) its not returning me the expected Pass. It is in-fact giving an empty result So I have below questions: Do I need to do something else for PassKit API's to work? Is it even possible to test In-App-Verification in the TestFlight App using sandbox Wallet?

We are way past our marketed release that because our app has been stuck on waiting for review for more than 72 hours even after requesting for expedite review, my app ID is 6817660417 kindly assist

Issue: Our first app, Cool Girl Wears (Apple ID 6812481375, iOS 1.0.0), has been in "Waiting for Review" for 8 days with no movement. Request: Please check whether anything is holding the review, or tell us if you need anything else from us. Background: The first review happened within a day. On 27 September App Review asked for more information (Guideline 2.1, new account). We answered the same day with a screen recording, demo account and full answers, and resubmitted on 29 September. Since then we've requested an expedited review twice (both confirmed) and sent a status request on 5 October (case 102986649532), with no change. Thank you, Sienna Espie, Cool Girl Wears

Hello everyone, I am designing an in-app subscription and pass extension/upgrade system for an iOS app and want to ensure full compliance with App Store Review Guideline 3.1.1. Because pricing in our system depends on the user's historical purchase price rather than static store catalog prices, direct fixed-SKU purchases aren't sufficient on their own. Business Logic Overview Extensions: An extension costs 50% of the price the user originally paid for their plan. Example: If a user bought Plan A at $200, their extension cost is $100 (even if Plan A currently retails at $150). Upgrades: An upgrade charges the delta between the target plan's current price and the user's original purchase price. Example: A user bought Plan A for $200, and Plan B currently costs $250. The upgrade cost is $\max(0, 250 - 200) = 50$. Proposed Technical Solution User requests an extension or upgrade from the iOS client. The backend server calculates the exact delta amount based on user purchase history. The backend maps this calculated amount to a pre-defined Tiered StoreKit Product ID (e.g., com.app.tier_50). The iOS app receives the Product ID and executes the transaction via StoreKit 2 (Product.purchase()). The backend validates the transaction JWS signature with Apple and updates the user's access duration. Questions for the Community & Apple Engineers Has anyone implemented backend-resolved dynamic Tiered SKUs for top-ups or price deltas? Did this pass App Review without issues under Guideline 3.1.1? Are there recommended patterns when configuring price-point tier SKUs (Consumable vs Non-Renewing Subscription) in App Store Connect for variable delta payments? For auto-renewing subscriptions, is it preferred to handle extensions strictly via StoreKit 2 Promotional Offers rather than delta SKUs? Any feedback or real-world experience with similar pricing structures would be greatly appreciated!

Hi everyone, I'm hoping someone can shed some light on an App Review issue we're currently experiencing. We have submitted our Caffè Sabrina iOS app (version 1.0, build 5) for review. The app was previously reviewed by Apple and we were told that the demo account credentials we had provided were no longer valid. We immediately fixed this by creating a completely new demo account, testing it successfully, and updating the App Review information in App Store Connect. We then resubmitted the app. The submission has been sitting at “Waiting for Review” since Wednesday at 7:57 AM. The unusual part is that we have now requested expedited review twice, and Apple confirmed that the review would be expedited. However, the submission still hasn't moved to “In Review.” We've checked everything we can think of: Current build is correctly submitted. New App Review credentials have been tested successfully. App Review information has been updated. The latest build has been tested through TestFlight. The latest build has had installs and multiple sessions. There are no known crashes on the latest build. The current submission has not been cancelled or resubmitted again. We're now several days beyond the expedited request and are concerned that something may be preventing the submission from entering the review queue. Has anyone else experienced an expedited review being granted but the app remaining stuck on “Waiting for Review” for several days? If so, did Apple eventually move it into review automatically, or did you have to contact App Review again? Any advice would be greatly appreciated. Thanks, Michael Darling Tech Ltd

Hello App Review Team, I’m following up regarding our app Neat Everyday, which has been in Waiting for Review for approximately one week. We submitted an Expedited Review request yesterday because the app is part of our planned India launch, but we have not received any update and the submission remains in Waiting for Review. Could you please check whether the submission is correctly queued for review or if any action is required from our side? The app has been reviewed and approved by Apple previously, and there are no outstanding issues or requests for information in App Store Connect. We would greatly appreciate it if you could check the status of this submission. Thank you.

For some reason, Carplay 18.x works fine, however in under certain situations in our app, Carplay 26.x breaks. The expected grid layout should be : However, this is what we see in some cases when we update our templates. I have not been able to isolate the cause of this issue. Has anyone ever seen this happen on their CarPlay apps and discovered the cause? The data sets fed into the templates are identical, the difference is in some of the timing and update order...

For macOS 26.7.1 (25G241), Xcode 27.0 (27A266a), and macOS SDK 27.0, we request the supported, exact Info.plist schema for NSDataAccessSecurityPolicy: its value type, literal key names and nesting, item types, and identity-selector grammar. Can the policy allow only the owning process signed with a specific Team ID and signing identifier, without allowing all applications signed by that Team? Are cdhash or designated-requirement selectors supported, and how do process and installer/package identities differ? Please clarify the relationship to user consent and Full Disk Access exceptions, and confirm whether this configuration is supported for the macOS build listed above. Please provide primary documentation or an authoritative schema, rather than a schema inferred from NSUpdateSecurityPolicy.

Hi everyone, We resubmitted a new banking app on September 30 after a 2.1(a) rejection (the reviewer didn't complete the OTP step; we clarified the steps in our reply and review notes). It has been in "Waiting for Review" since then. Apple ID: 6779648622 Expedited review requested Oct 1 Support case opened Oct 2 (Case ID 102983863768) Updated Program License Agreement accepted Oct 6 The client's launch has already been postponed once, to October 14, because of the delay. Is anyone else seeing similar wait times right now, or is there anything else we should check on our side? Thanks!

App Review, App stuck in "Waiting for Review" since Sep 30 after expedite approval Hello, Our app HospiSavvy (Apple ID: 6766224866), iOS version 2.5, has been in "Waiting for Review" since September 30. Timeline: Sep 25: Resubmitted after addressing metadata feedback Sep 30: Expedited review approved. A reviewer asked about VPN functionality the same day. We replied (the app has no VPN functionality) and resubmitted at 11:06 AM. Since then, the status has not changed, and we can't reply further in the App Review thread. Oct 5: Opened a support case (Case ID: 102986178435), no response yet. Could someone from App Review please check whether this submission is stuck? Any help would be appreciated. Thank you.