Overview

Hi, I’m experiencing a TestFlight issue affecting multiple apps in my account. Issue summary: • Several TestFlight builds across all of my apps expired at the same time. • After uploading new replacement builds, neither I nor my testers are able to install them. • Installation fails with the message: “Could not install {App Name}. The requested app is not available or doesn’t exist.” • The build shows as processed and available in App Store Connect. • Testers are already invited and active. • No redeem code is required. I am seeing the same issue on my own device as well. What I’ve tried: • Uploading new builds (incremented version + build number). • Confirmed builds are visible and available in App Store Connect. • Removing and re-adding testers. • Logging out of the app. • Deleting the app from the device. • Restarting the device. • Reinstalling directly from TestFlight. • Restarting TestFlight. Despite this, installation consistently fails with the “requested app is not available or doesn’t exist” error. Expected behavior: • New TestFlight builds should be installable once processed and available. • Testers (and the developer) should be able to install directly from TestFlight. • Expired builds should not block installation of newly uploaded builds. Additional context: • This started immediately after multiple TestFlight builds expired across my apps. • All affected apps were previously installing and testing without issue. • Apple Developer Support has been contacted, but I wanted to check whether others are seeing the same behavior or if there is a known workaround. Has anyone else encountered TestFlight builds becoming unavailable across multiple apps at once, or an install failure after replacing expired builds

Hello, could someone from App Review please check whether our submission is stuck? App: EDM Hype (Apple ID 6810062512) Version: iOS 1.0 (build 275), our first release Submission ID: 188cccea-fc38-49ed-9053-f6120c547eac Timeline: Oct 11-12: first submitted for review. Oct 27: reviewed and rejected under Guideline 2.5.4 (the reviewer did not find a persistent audio feature). Oct 27: replied in App Store Connect with a screen recording from a physical iPhone showing background playback, added the same steps to the App Review notes, attached build 275, and resubmitted at 11:01 AM. Oct 29: requested an expedited review. The form confirmed "We'll expedite review for EDM Hype." Today, Nov 5: still Waiting for Review, 9 days after resubmitting and 7 days after the expedite was accepted. No new messages from App Review. Reply to App Review is not available on this submission, so we have no way to ask there. We have not changed or cancelled the submission, so that it keeps its place in the queue. Is there something on our side we should do, or can the submission be looked at? Thank you.

It seems it's not possible anymore to view the output of the thinking process of an LLM. In Xcode 27 we were able to enlarge the output of each thinking phase, even though the UX wasn't actually great for doing this. Now, in Xcode 27.2 this is almost completely gone. There's only one line that seems to print the last line of the output. Do I miss something? Observing this content while the LLM is thinking is important, in order to be able to steer the LLM, or help it to find things, stop digressing into irrelevant topics, etc. While this was also not great, since enqueuing a message while the LLM is thinking has been queued – but the thinking phase has never been interrupted. So, enqueuing a message in order to steer the LLM was almost futile anyway. Nonetheless, I would expect newer Xcode versions to improve the user experience. I am unsure why this choice was made and included in a release. In my view, the AI chat and conversation behavior need improvement in several ways, though that is material for a few more posts.

Since iOS 27, showing a system permission alert no longer deactivates the app. On iOS 26, sceneWillResignActive / applicationWillResignActive arrive about 0.05–0.1 s after ATTrackingManager.requestTrackingAuthorization. On iOS 27.0, 27.0.1 and 27.2 they don't arrive at all while the prompt is up, and SwiftUI's scenePhase stays .active. Apps that pause on resign, like games (Unity's iOS player pauses only on applicationWillResignActive), keep running behind the prompt: tutorials start, and timers and audio keep going. Minimal repro (plain UIKit with UIScene, fresh install so the status is .notDetermined): private var askedForTracking = false func sceneDidBecomeActive(_ scene: UIScene) { print("sceneDidBecomeActive") guard !askedForTracking else { return } askedForTracking = true DispatchQueue.main.asyncAfter(deadline: .now() + 3) { print("requesting ATT") ATTrackingManager.requestTrackingAuthorization { status in print("ATT finished: \(status.rawValue)") } } } func sceneWillResignActive(_ scene: UIScene) { print("sceneWillResignActive") }iOS 26.6: 3.27s requesting ATT 3.35s willResignActive 16.81s ATT finished: authorized 17.24s didBecomeActiveiOS 27.2: 3.21s requesting ATT 16.88s ATT finished: authorized 17.32s willResignActive 17.33s didBecomeActiveSo on iOS 27 the only lifecycle events are a resign/active pair about 0.44 s after the answer. What we found: The camera and notification permission alerts behave the same. It doesn't depend on the SDK the app is linked against, or on the thread making the request. SpringBoard's log shows the systemModalAlert deactivation assertion being added, but on iOS 27 the updateAllScenesForBand - Assertion added update never reaches the app's scene. The pending reason is only applied on the next unrelated scene update, such as a notification banner arriving, the screen dimming, an unlock, or the alert being dismissed. Taps outside the alert, a Control Center swipe or a home-indicator drag don't trigger it. Filed as FB25446786, with a sample project, delay sweeps on iOS 26 vs 27 (simulator and device) and a sysdiagnose. Is anyone else seeing this? And is there a supported way to know a permission alert is on screen until it's fixed? If you're affected, please file a Feedback and mention FB25446786; duplicates help.

Following Quinn's advice in https://developer.apple.com/forums/thread/118465?answerId=379585022#379585022, I have opened a Developer Programs Support case and am posting here with the case number. Case number: 103005753388 Team ID: 6PG3USG4A9 Notarization worked for this team: three submissions were accepted on 21 and 22 October 2026. Since the evening of 22 October every submission is rejected with status code 7000, "Team is not yet configured for notarization". The rejection logs have "issues": null and no ticket. Nothing changed on our side between the accepted and the rejected submissions: same app, same Developer ID Application certificate, same Apple ID with an app-specific password, same xcrun notarytool. The team is otherwise active; our iOS app is live on the App Store. Accepted: 49e6f112-fd07-40ca-b908-6b8126d2d137 (2026-10-21) fcaae8e3-84e3-493b-a747-297f0ab60c79 (2026-10-21) ab12ace8-743b-47fa-955b-e030feabce11 (2026-10-22) Rejected with 7000: 1731bdca-bf9c-417c-a65a-4f38c619897d (2026-10-22) 245112d4-8422-4b1d-bd73-d7718f994378 (2026-10-22) 52c784f3-ca5f-4d42-964d-2308192c5515 (2026-10-23) 2863f755-7bc4-42ea-b117-1eedcc7fcade (2026-10-23) 33996a21-59af-455e-ad22-11ef01f39fa4 (2026-11-03) b498ee7c-a1bf-46b4-bbb2-e8b3d643fe85 (2026-11-03) We distribute a Mac app outside the Mac App Store, and a release is waiting on this. Could someone from Developer Programs please look at the team's notarization status, or tell us what is missing on the account? Thank you.

Hi, I have a question about the numbers that we get from using the App Store Connect API and what is visible through Metrics/Analytics in App Store Connect's UI. Specifically, there appears to be significant discrepencies between counts for downloads, installs, deletes when comparing both data sets. I would expect them to be the same. Our workflow: Run app_installs_deletes through the API and download the provided report from the URL received Run Analytics, Total Downloads, through App Store Connect website In my case, running this for a day well in the past (to cater for catch up processing time), for example 20th Sept 2026, I get 37622 total downloads from the ASC website, but 21190 from the report data. This is a significant difference. What specific API report should be run to get the same data as displasy in App Store Connect? Looking to ensure that I have exact number from the ASC analytics/metrics, through an API report, on Installs, Updates, Deletes, Downloads. Any help appreciated. Developer support pointed me to post in the forums...

Hello, I am currently working on an iOS app and studying the feasibility of a custom voice detection feature. The user might set up a secret voice keyword (a custom word or phrase). When this keyword is spoken, even when the iPhone is locked and stored in a pocket, the application would automatically trigger an action. My questions are: Can an iOS app continuously detect a custom voice keyword when running in the background and iPhone is locked? Is there an officially supported and App Store compatible method to perform this detection locally, without recording or transmitting audio? Can an application automatically trigger an action following this detection? Would using AVAudioSession and the audio mode in the background be an acceptable solution for this use case? Are there any Apple frameworks suitable for this type of feature? I would be particularly interested in feedback from Apple engineers or developers who have experimented with similar features. Thank you in advance for your help.

I own a U.S. single-member LLC that's a disregarded entity. In App Store Connect, Line 1 of the W-9 is locked to the LLC name, but the IRS instructions say the owner's name goes on Line 1 and the LLC on Line 2. This is blocking my Paid Apps Agreement. I contacted Finance Support around 9-23-26 with a screenshot and video of the issue, but haven't heard back. I followed up a week ago. Still no response. Has anyone with a single-member LLC gotten this fixed recently? Apple developer support says their financial team is the only team that can handle this issue. Nearly one month to fix some basic text is ridiculous. I could have handles this myself if the Line 1 box wasn't greyed out.

Hello Apple Developer Support and App Review Team, We are experiencing an unusually long App Store review delay for our application, B2Meet (Version 1.0.03). APPLICATION DETAILS App Name: B2Meet Developer: Sia Teknoloji Apple ID: 6823916394 Bundle ID: com.b2meet SKU: b2meet Version: 1.0.03 Platform: iOS Current Status: Waiting for Review SUBMISSION HISTORY October 20, 2026: Initial submission – Waiting for Review October 22, 2026: Developer withdrew and resubmitted the application October 27, 2026: Developer withdrew and resubmitted the application November 5, 2026: Still Waiting for Review The application has been in the submission process for 16 days, including 9 days since the latest submission, without entering the actual review stage. BUSINESS IMPACT AND URGENCY B2Meet is a B2B networking and event management platform developed by Sia Teknoloji for major international exhibitions scheduled for November 25–28, 2026. The application must be available at least 20 days before these events to allow exhibitors, international buyers, and organizers to register, schedule B2B meetings, and prepare their participation. Our planned launch date was November 5, 2026, and this delay is now directly affecting event preparations. REQUEST FOR URGENT ASSISTANCE We would greatly appreciate clarification on the following: Could Apple investigate why our application has not entered the review stage? Is there any technical, account-related, or submission-related issue preventing the review from starting? Could our submission be considered for expedited review due to the fixed international event dates? We have attached a screenshot of the App Store Connect submission history documenting the timeline. We would greatly appreciate assistance from an Apple engineer or App Review representative. Thank you for your support. Best regards

On macOS 27.x (Apple silicon) I've been measuring how launchd stops a job, and two behaviors don't match the documentation. Method: a throwaway job whose script traps SIGTERM and logs it, bootstrapped with different ExitTimeOut values, then stopped with launchctl bootout while timing when the process dies. Observed (LaunchAgent in the gui domain; the same results in the system domain with a LaunchDaemon): ExitTimeOut 45 -> `launchctl print` reports 45; SIGTERM, then SIGKILL at 45 s ExitTimeOut 61 -> reports 60; SIGTERM, then SIGKILL at 60 s ExitTimeOut 90 -> reports 60; SIGTERM, then SIGKILL at 60 s ExitTimeOut 120 -> reports 60; SIGTERM, then SIGKILL at 60 s ExitTimeOut 0 -> reports 0; SIGKILL after ~0.1 s, SIGTERM never deliveredman launchd.plist says of ExitTimeOut: "The amount of time launchd waits between sending the SIGTERM signal and before sending a SIGKILL signal when the job is to be stopped. The default value is system-defined. The value zero is interpreted as infinity and should not be used, as it can stall system shutdown forever." So: is there a 60-second ceiling on ExitTimeOut? It isn't documented that I can find, and it applies in both domains. And is zero meant to be "infinity" as documented, or an immediate SIGKILL as observed? Finally, is there a supported way for a service to be given more than 60 seconds to exit when launchd stops it — or is 60 seconds simply the maximum? Happy to file a Feedback with a minimal repro if that's useful.

I can't find a way to create an event trigger with a presence-based predicate ideally for a particular user at home; or at least, for all users at home. Just for the record, the rationale: I need to keep the heating on in the user's private room when he is at home, off when he is not. The idea is to have a trigger based on a low temperature event (I can do that and works all right), which would then check whether the user is at home through the predicate; if so, it would open the radiator valve (the action also tested and also working all right); if not, it would do nothing. How to? Since I could find no API to create an HMPresenceEvent for a particular user, I've set it up in the Home application, and tried to use it this way (I happen to have only one such at the moment in Home, so there's no need to check the attributes): HMPresenceEvent *pevent; for (HMEventTrigger *t in home.triggers) if ([t isKindOfClass:HMEventTrigger.class]) for (HMPresenceEvent *e in t.events) if ([e isKindOfClass:HMPresenceEvent.class]) { pevent=[e copy]; break; } NSPredicate *p=[HMEventTrigger predicateForEvaluatingTriggerWithPresence:pevent]; HMEventTrigger *et=[[HMEventTrigger alloc] initWithName:@"TEST PRESENCE" events:... endEvents:nil recurrences:nil predicate:p];alas, this raises the “NSInvalidArgumentException: Invalid parameter; (user info absent)” exception. Looks like copy loses this information somehow?!? Without appropriate public APIs one can't say :( (Since I can set up these events in the Home application freely with any kinds of action, it seems to be patently absurd not to open these APIs for privacy reasons, but that's another question, not for this ticket.) Anyway, I've tried to resort to checking for “all users at home” through pevent=[[HMPresenceEvent alloc] initWithPresenceEventType:HMPresenceEventTypeAtHome presenceUserType:HMPresenceEventUserTypeHomeUsers];where HMPresenceEventUserTypeHomeUsers is documented as “Presence of all home users”. Nevertheless, when I log out the result, I get just “any user“: [Presence-Event: type: HMPresenceTypeAnyUserAtHome, mode: HMPresenceEventActivationGranularityHome]That's unusable for me. I need to check for presence of all users (if checking for a particular one is really forbidden for some inexplicable reason). Please help. How to properly set up a trigger predicate for (ideally) a given specific HMUser, or at the very least, for a presence of all registered home users. Thanks!

Issue: Screen rotation becomes locked when updating the status bar on an iPhone Duo. This does not appear to be a device-specific hardware issue; however, it occurs specifically on the iPhone Duo. In my app, if I change the status bar visibility (using prefersStatusBarHidden) while on the iPhone Duo’s external screen, and then immediately unfold the device to reveal the internal screen, the app’s rotation state becomes locked. Although I use prefersInterfaceOrientationLocked to manage rotation, the app remains locked even when this property returns false. The issue persists even when prefersInterfaceOrientationLocked is commented out or removed entirely. Returning to the device’s home screen, rotating the device, and then re-entering the app resolves the lock. Has anyone encountered or resolved a similar issue?

On macOS 27 the File Provider extension of our app (Secure ShellFish, an SSH client) can't connect to any host on the local network, while the containing app connects to the same host on the same Mac without problems. Local Network is enabled for the app in System Settings, but every connection from the extension fails with "Local network prohibited". It did not happen on macOS 26 and still happens on macOS 27.2 (26B123). This is hitting end users of Secure ShellFish, not just my test setup, and it has been my number one support issue since macOS 27 was released. I filed this as FB24999927 with a sysdiagnose. I'm posting here to find out whether others with File Provider (or other) extensions see the same, and whether there is anything on our side that should make it work. Steps Install the app on a clean macOS 27 system and launch it. Choose Allow at the Local Network prompt. Add an SSH server on the local network (another Mac in my test) and open a terminal to it. This works. Open the same server in Finder (the File Provider domain under ~/Library/CloudStorage). The directory listing fails. What happens TN3179 says "In general, app extensions share the Local Network privilege state of their container app", so I expected the listing to load. Instead every connection from the extension to the LAN host is blocked, and the error depends on the networking API: CFStream: ENETDOWN (50) "Network is down" BSD socket connect(): EHOSTUNREACH (65) "No route to host" Network.framework (NWConnection, multipath TCP): waits with path unsatisfied (Local network prohibited) until our connect timeout, ETIMEDOUT (60) No Local Network prompt appears. Toggling the permission, rebooting, killing the extension process and reinstalling the app don't help. What I ruled out A stale extension process: freshly launched extension processes are blocked on their very first connection. A missing UUID cache: after installing a new build, nehelper populates the cache for the app with 14 UUIDs, including both slices of the extension's executable. The extension was blocked 23 seconds later. Shared executable UUIDs: the app and the extension have distinct Mach-O UUIDs. The sandbox: the extension has com.apple.security.network.client. A missing usage string: adding NSLocalNetworkUsageDescription to the extension's Info.plist changed nothing, with no prompt and no separate entry in System Settings. Networking in general: the extension reaches internet hosts and the Mac itself by its local name. Only other hosts on the local network are blocked. Log The blocked notification arrives with bundle_id: (null). UserEventAgent then maps the extension to the app by its UUID, nehelper answers that local network is allowed by preference, and the handler is called with the newly allowed state. Later connections from the same process are still blocked, so that state never takes effect for the extension. 09:19:37.575 UserEventAgent Got local network blocked notification: pid: 4297, uuid: 183484C2-8052-36AD-A81E-B02F15F875B3, bundle_id: (null) 09:19:37.575 UserEventAgent LocalNetwork: found bundle id com.appliedphasor.secure-shellfish.mac-provider by PID 09:19:37.575 ShellFish-Finder [C1.1.1 IPv6#dace0833.22 failed path (unsatisfied (Local network prohibited), interface: en0[802.11], ipv4, ipv6, uses wifi)] 09:19:37.576 UserEventAgent LocalNetwork: found bundle id com.appliedphasor.secure-shellfish by UUID 183484C2-8052-36AD-A81E-B02F15F875B3 09:19:37.597 nehelper UUID cache hit for com.appliedphasor.secure-shellfish 09:19:37.597 nehelper Local network allowed by preference for ShellFish (com.appliedphasor.secure-shellfish) 09:19:37.597 UserEventAgent App got response: 1 09:19:37.597 UserEventAgent Calling handler with newly allowed state: 1 09:19:44.795 fileproviderd populate-directory error: FP -1004 "Unable to list p5.local: Unable To Connect To P5.Local: Network Is Down."Questions Is this a known change in macOS 27? FB24035385 (helper and child processes no longer inherit Local Network access on macOS 27) sounds related, and other File Provider apps report the same, for example nextcloud/desktop#10885: https://github.com/nextcloud/desktop/issues/10885 Does an extension need anything on macOS 27 to share its container's Local Network privilege, such as an entitlement, an Info.plist key, or something the app must do first? If not, is there a supported workaround? The only one we see is to relay the extension's traffic through the main app over loopback, which only works while the app is running. For these users Finder integration is completely broken, because servers on the local network (Raspberry Pi, NAS, home servers) are the most common setup among them. Any pointers are much appreciated.

Anyone working with the 27.3 devices beta in Xcode 27.3 on macOS 27.3? Canvas and device hub/simulator are throwing this error while open, several on first load, then periodically (not sure of the periodicity). Any help is appreciated. Not sure if it's impacting at the code or app, but it is interfering with active work (it assumes modal position while working). Can reproduce from Device Hub only (all other apps, including XCode closed), screencast here - demos 27.2 for the time it is started no errors, 27.3 as soon as it is started "identityservicesd quit unexpectedly" errors. Looks like stages in the rendering also - noticed dock not displayed, error, then dock displayed, next - home icons not displayed, error, then home icons displayed, etc. https://app.screencast.com/iK0BaVIVpjt0O

Perhaps I am just stupid, but I can't quite grok that. What object is the predicate evaluated over, how, and at what moment? Originally I've thought when some event causes the trigger to fire, the predicate would just be evaluated over that event; but that can't be that simple, see please details below. I've set (in a 3rd party application; Home, far as I can say, does not allow that) a predicate “only when both of a pair of lights are off”. The predicate works perfectly, and the event really performs its action set only when both of the lights are off, so far so good. Nevertheless, I've dumped the predicate, and it looks like this (the first line is my own dump which is a bit more concise; the 2nd one is the standard description just to make sure that my own dump works properly): (((self.characteristic == 'Power State' of 'Lustr O') && (self.characteristicValue == 0)) && ((self.characteristic == 'Power State' of 'Knihovna') && (self.characteristicValue == 0))) (characteristic == <HMCharacteristic, Unique ID: 2E046807-9127-565F-B9CB-10BC0F2EE6D2, Type: 00000025, Instance ID: 9> AND characteristicValue == 0) AND (characteristic == <HMCharacteristic, Unique ID: 7444CCCE-1C1B-5234-8CAE-01DA4D811B8B, Type: 00000025, Instance ID: 9> AND characteristicValue == 0)I can't understand that at all :( I must be missing something of great importance, but it seems to me that a predicate which can be just as well[1] written as self.characteristic==A && self.characteristic==B && (some other conditions) can't ever evaluate to YES when A and B differ (which they self-evidently do in this case). The “to evaluate before executing the scene” of the documentation does not really help. What do I miss, can anybody explain that? Thanks! [1] Correct me please if I am wrong, but I do believe the logical AND is both an associative and an commutative operator, which makes this re-write fully equivalent to the original.

Hi everyone, We are currently preparing the release of our Flutter-based iOS application and are experiencing an unusual StoreKit 2 storefront issue that only occurs when the app is installed through TestFlight. The problem When our application is installed through TestFlight, StoreKit 2 consistently returns the United States storefront (USA), and all six auto-renewable subscription products are displayed with USD prices. However, both the regular Apple Account and the Sandbox Apple Account are configured for Germany. We have verified the following: All six subscription products are correctly configured in App Store Connect with EUR prices for Germany. The subscriptions are available in Germany, Austria, and Switzerland. We created a completely new Sandbox tester with Germany selected during account creation, using an email address that had never previously been used for sandbox testing. The issue occurs on two different physical devices (iPhone and iPad). No local StoreKit configuration file is used. Our application does not override the storefront, modify localized prices, or contain any hardcoded USD fallback. Controlled comparison We performed additional tests using the same application code on the same iPhone. The results were: Installation method Storefront Currency Local Debug build via Xcode/Flutter DEU EUR Local development-signed Release build via Flutter DEU EUR TestFlight Release build USA USD The locally installed Release build successfully retrieves all six subscription products with their correct German prices. For example, StoreKit returns the following values for one of our subscriptions: Local Release build: Storefront.current.countryCode = DEU Product currencyCode = EUR Product.displayPrice = 6,99 € TestFlight build: Storefront.current.countryCode = USA Product currencyCode = USD Both builds use the same StoreKit 2 integration and product identifiers. Technical environment Framework: Flutter StoreKit integration: StoreKit 2 Flutter plugin: in_app_purchase_storekit 0.4.11+2 Devices: Physical iPhone and iPad iOS/iPadOS: 26.6.2 Subscription products: Six auto-renewable subscriptions Expected storefront: Germany (DEU) Actual TestFlight storefront: United States (USA) We have traced the storefront country code directly to StoreKit 2’s Storefront.current.countryCode and the localized prices to the product information returned by Product.products(for:). There is no application-level storefront override or price conversion. Questions Why would StoreKit 2 return a different storefront in TestFlight compared with a locally installed development-signed Release build on the same physical device? Could TestFlight use a different sandbox storefront or Apple Account context than a locally installed build? Is there a recommended way to diagnose or reset the storefront association used by TestFlight? Has anyone experienced similar behavior where TestFlight consistently returns USA despite using a German Apple Account and newly created German sandbox testers? We have already contacted Apple Developer Support and followed their recommendation to create a completely new German sandbox tester, but the issue persists. Any guidance from Apple engineers or developers who have encountered similar behavior would be greatly appreciated. Thank you!

Hello Apple Developer community, I'm investigating an unexpected metadata representation returned by Apple's Security framework while inspecting an existing Secure Enclave-associated Keychain item on macOS. A read-only inspection using SecItemCopyMatching returns one matching key record with a successful status, a Secure Enclave token identifier (com.apple.setoken), and a 256-bit key size. However, direct Core Foundation type inspection reports: kSecAttrKeyType: CFNumber kSecAttrKeyClass: CFNumber kSecAttrSynchronizable: CFNumber The raw Core Foundation observations and bridged observations agree. Our current validator rejects these unexpected types and returns UNSUPPORTED_OR_INCOMPLETE_METADATA. We have deliberately stopped further key operations pending clarification. Questions: Can these CFNumber values legitimately appear in a dictionary returned by SecItemCopyMatching for Secure Enclave-associated key items on macOS? What returned value types should be expected for these three attributes, and are they dependent on the query or Keychain implementation? Is there an Apple-recommended way to normalize or validate these attributes without incorrectly accepting incompatible metadata? How should an application distinguish an existing Secure Enclave-backed key from an incomplete or unsupported Keychain record without performing a private-key operation? Are there relevant Security framework documentation references or known implementation differences we should consult? Our aim is to validate the existing record safely without regenerating, deleting, or using the private key. Thank you for your guidance.

Hi all, It seems like there are a ton of us stuck in a "Waiting for Review" traffic jam, with Apple providing essentially no information on their end. Immensely frustrating. Given that, would people be up for posting their time submitted and (once they receive a review) editing to include the time it took? It would be good to get a sense of how long everyone is waiting. I'll go first: Submitted: October 8 Status: Waiting for review I'll update this post when I hear back.

We are implementing a fail-closed security check for a directory opened through a file descriptor on macOS. We need to reliably distinguish between: No extended ACL is present. An extended ACL is present but contains zero entries. ACL retrieval failed or is unsupported. Observed behavior For an existing directory with mode 0700: acl_get_fd_np(fd, ACL_TYPE_EXTENDED) returns NULL with errno == ENOENT. acl_get_file(path, ACL_TYPE_EXTENDED) returns NULL with errno == ENOENT. fstat() and lstat() agree on the device and inode. The directory exists and can be opened successfully. ls -ldeO@ displays no extended ACL entries. We reviewed Apple's open-source implementations of acl_get_fd_np() and filesec_get_property(). We understand that ENOENT can result from an unavailable FILESEC_ACL property, rather than a missing filesystem object. We also understand that XNU distinguishes an empty ACL from KAUTH_FILESEC_NOACL. Question Is there a publicly supported, file-descriptor-based API with documented postconditions that can reliably prove the absence of an extended ACL, while distinguishing it from an empty ACL and an ACL retrieval failure? Specifically: Can fstatx_np() and filesec_get_property() provide this distinction? Can fgetattrlist() with ATTR_CMN_EXTENDED_SECURITY and ATTR_CMN_RETURNED_ATTRS reliably establish ACL absence? What additional filesystem capability checks or return-value checks are required? If no public API provides this guarantee, is that a documented limitation? For security reasons, our implementation rejects the object whenever ACL absence cannot be established reliably. We would appreciate clarification of the supported API contract and its limitations. Thank you.

Hi everyone, I’m currently experiencing unusually long review waiting times and wanted to ask if others see the same behavior this week. My situation: • App Store update has been in “Waiting for Review” significantly longer than usual • A newly submitted build also seems stuck • TestFlight processing is slower than I normally see • Expedited review request and contact attempts didn’t change the status so far What confuses me is that I still see other apps receiving updates, so I’m unsure whether this is a broader review delay or something submission-specific. I’m not trying to escalate anything — just looking to understand if this is currently affecting more developers. Would really appreciate hearing about your recent experiences. Thanks and good luck to everyone waiting 🙂