Our app uses a Distribution.xml-based installer. Within the postinstall script, we attempt to untar a signed and notarized .app to the /Applications directory. On macOS 27 (tested up to Developer Beta 4), the tar command randomly fails to write random unpacked files with an I/O error; in the console there is "spolicyd[721] revoked access to "/Applications/XXX.app/file/within". It can be reproduced approximately every 4th install. Is this happening for anyone else? Any known workaround?

Subject: Clarification Request – Private Relay and Silent Network Verification (SNV) Hello, Context: our app uses Silent Network Verification (SNV), the standard carrier method where the network recognizes a subscriber's connection to verify their identity without needing an SMS code. When a user has iCloud Private Relay enabled, the request path changes in a way that breaks this recognition, and the user falls back to OTP instead. We're evaluating an approach where the app would handle DNS resolution itself for this specific verification request, so the request stays on a path our network can recognize — without the user having to turn Private Relay off. Before we go further with this, we'd like clarity on two things: Would this kind of app-level DNS handling, used only for this verification step, be acceptable under the App Store Review Guidelines — or would it likely be treated as working around a user's privacy setting (for example under 2.5.1, 2.5.9, or 5.1.1)? If we added an explicit, transparent consent step in the app — telling the user we're bypassing Private Relay for this one request so they can be verified without an SMS code — would that change how this is viewed? We'd rather get this in writing from Apple than build against an assumption, and we'll need to share your response with our internal IT and compliance team, so a written reply would be genuinely helpful. Happy to provide more technical detail if useful. Thank you,

Hello, We are using the UPI device validation APIs on iOS 26+ in a production banking/UPI app, and we are seeing a recurring failure from CoreTelephony that we need guidance on. API / entitlement Framework: CoreTelephony API: CTCellularPlanStatus.checkValidity(ofToken:) Related: CTCellularPlanStatus.token() Entitlement: com.apple.developer.upi-device-validation Availability: iOS 26.0+ Minimal call site do { let isValid = try await CTCellularPlanStatus.checkValidity(ofToken: token) // isValid == true/false -> expected outcomes } catch { // Unexpected: API throws instead of returning Bool print(error.localizedDescription) } Error error.localizedDescription is: English: Couldn't communicate with a helper application. Same failure also appears with a localized Hindi message on Hindi-locale devices. This is distinct from checkValidity(ofToken:) returning false (token/SIM mismatch). Here the API throws, so we cannot tell whether the token is valid. In production we currently only have this localizedDescription from telemetry. Production observations (large fleet, last few days) Observed only on production user devices so far; we have not reproduced it reliably on lab hardware. Occurs across multiple iOS 26.x builds (notably 26.5.2, 26.5, 26.6; also seen on 26.0-27.0). Not limited to a single patch. Seen on many iPhone models (not one SKU). Latency is bimodal for the same error string: large share fails in under 100 ms (immediate) another large share fails after about 2-10+ seconds (timeout-like) Observed under Wi-Fi, cellular (4G/5G), and No Connection / radio-not-ready conditions. Same device can emit many identical failures within about 1 second when validity is checked from multiple call sites concurrently. Token generation (CTCellularPlanStatus.token()) and successful checkValidity work for the vast majority of users; this throw is a smaller but material failure class. Questions for Apple Is "Couldn't communicate with a helper application." an expected / documented failure mode of checkValidity(ofToken:) (for example CommCenter/XPC unavailable, radio not ready)? What conditions typically trigger this error from checkValidity(ofToken:)? Recommended client handling: retry (with backoff)? treat as transient and skip forcing re-binding? surface to user? Does validation require cellular registration / SIM ready state even when docs indicate internet is not required? Any known issues on specific iOS 26.x builds, dual-SIM, eSIM, or airplane-mode transitions? Is concurrent checkValidity from multiple tasks unsupported / unsafe? Because this is currently production-only and not reliably reproducible on lab devices, we cannot attach a sysdiagnose or Instruments trace at this time. We can share aggregated production telemetry and API details via Feedback Assistant if helpful. Thank you.

We're investigating an edge case around push/local notification handling on macOS when multiple instances of the same app are running simultaneously, launched via open -n /path/to/App.app. We're aware this isn't the standard/expected usage pattern for macOS apps, which are singleton by default, but we need to understand and correctly handle this case, so any clarity here would help. Setup: macOS app, AppKit, using NSApplicationDelegate and UNUserNotificationCenterDelegate. Two separate processes of the same app launched via open -n, each independently calling UNUserNotificationCenter.current().delegate = self and registerForRemoteNotifications() on launch. Questions: Device token : is the device token unique per device and app installation, or could two separately-running processes of the same installed app each be issued a different token? Our understanding from Apple's documentation is that the token identifies the app and device combination, not a specific process. Can you confirm this holds even in a multi-instance scenario? Notification tap routing : when a notification, local or remote, is tapped and both process instances have independently registered a UNUserNotificationCenterDelegate, which instance's delegate receives userNotificationCenter didReceive withCompletionHandler? Is this deterministic, for example the most recently registered instance, or the one most recently connected to usernoted? Is it arbitrary or undefined? Or does the system only allow one instance's delegate connection to be active at a time, silently disconnecting the other? Is there any documented or recommended way for an app to detect it's running as a secondary instance launched via open -n, and adjust its notification handling behavior accordingly, if relevant? We understand this falls outside the normal supported usage pattern for macOS apps, but since the behavior isn't documented for this scenario, any insight, even confirming this is undefined behavior, would be genuinely useful for us to plan around.

I’m using Apple’s Network framework to implement a UDP client using NWConnection, and I have a question regarding the lifecycle of the DispatchQueue associated with an NWConnection instance. Let's assume I have an NWConnection instance, and I associate it with a dispatch queue using the start(queue:) API, such that network OS events for the NWConnection instance can be delivered to this queue. My understanding is that this association would result in NWConnection holding a strong reference to the DispatchQueue object. Now, I perform some I/O (send/receive) on the NWConnection instance and immediately perform the following steps. Also, assume that the completion closures for those I/O operations do not capture or otherwise retain the NWConnection. Call connection.cancel() and then release my last strong reference to the NWConnection. Without waiting for the connection to transition to the .cancelled state, I also release my last strong reference to the associated DispatchQueue. My question is: Does NWConnection, during its teardown, retain the DispatchQueue until the cancellation completions for all pending I/O operations associated with the connection have been delivered/executed, given that the application no longer holds any strong references to either the NWConnection or the DispatchQueue? Or, once cancel() is called, does NWConnection immediately release its reference to the DispatchQueue, in which case whether the pending callbacks are ultimately executed depends on whether the application has kept the queue alive?

Hi there, Starting with iOS 26.2 RC, all my DeviceActivityMonitor.eventDidReachThreshold get activated immediately as I pick up my iPhone for the first time, two nights in a row. Feedback: FB21267341 There's always a chance something odd is happening to my device in particular (although I can't recall making any changes here and the debug logs point to the issue), but just getting this out there ASAP in case others are seeing this (or haven't tried!), and it's critical as this is the RC. DeviceActivityMonitor.eventDidReachThreshold issues also mentioned here: https://developer.apple.com/forums/thread/793747; but I believe they are different and were potentially fixed in iOS 26.1, but it points to this part of the technology having issues and maybe someone from Apple has been tweaking it.

We are implementing StoreKit External Purchase Link for an iOS app distributed in the European Union and are trying to determine whether we are missing a configuration step or encountering a StoreKit server-side eligibility issue. The failure is reproducible in a focused native Swift Xcode project that directly calls StoreKit: let eligible = await ExternalPurchaseCustomLink.isEligible The sample contains no Flutter code, PayPal SDK, networking, or application business logic. Configuration we have verified: The Account Holder accepted the StoreKit External Purchase Link Entitlement Addendum for EU Apps. StoreKit External Purchase Link is enabled and shown as Assigned for the App ID. The regenerated Development provisioning profile contains com.apple.developer.storekit.external-purchase-link = true. The installed app's signed entitlements contain the same value. The application-identifier and team-identifier match the intended App ID and team. The compiled Info.plist contains SKExternalPurchaseCustomLinkRegions with all 27 lowercase EU region codes, including "de". Germany is available for the app in App Store Connect. No local StoreKit Configuration file is enabled. Test environment: Physical iPhone running iOS 26.5.2 (23F84) Xcode 26.6 (17F113) Real German Media & Purchases Apple Account German Sandbox Apple Account StoreKit 2 storefront ID 143443, country code DEU StoreKit 1 also reports country code DEU AppStore.canMakePayments = true AppTransaction verifies in the Sandbox environment Clean build and reinstall using the regenerated Development profile Observed result: ExternalPurchaseCustomLink.isEligible = false For diagnostic purposes only, after observing false eligibility, we also requested both token types: ACQUISITION: StoreKitError.notAvailableInStorefront SERVICES: StoreKitError.notAvailableInStorefront A delayed recheck still reports storefront DEU and isEligible=false. Our production flow does not request tokens unless eligibility is true. We found the similar thread "Unable to enable eligibility for External Purchase Link APIs" (https://developer.apple.com/forums/thread/808349). In that case, the production Media & Purchases account had an unsupported storefront. In our case, both the real Media & Purchases account and the Sandbox account are German, and StoreKit itself reports DEU. We also found "External Purchase in Japan" (https://developer.apple.com/forums/thread/822618), where an Apple App Store Commerce Engineer requested a Feedback Assistant report with a sysdiagnose and screen recording for isEligible=false. Questions: Should ExternalPurchaseCustomLink.isEligible return true in a developer-signed Sandbox build when the entitlement, compiled Info.plist, German storefront, and account conditions are all satisfied, or is TestFlight/App Store approval required? Is there any additional App Store Connect storefront election, entitlement approval, or server-side activation step required beyond the EU addendum, Assigned capability, signed entitlement, and SKExternalPurchaseCustomLinkRegions? If this configuration is complete, could Apple verify whether eligibility has not propagated correctly for the German Development/StoreKit Sandbox environment, and which diagnostics should be included in a Feedback Assistant report? We have also opened a code-level support request and prepared a minimal native Swift reproduction project. Any guidance from StoreKit engineering would be appreciated.

Overview I would like to observe calendar changes using NotificationCenter.messages(of: for:) I want receive Sendable messages, not traditional Notification which is not Sendable Problem I can't seem to get the following code to compile import EventKit NotificationCenter.default.messages( of: EKEventStore.EventStoreChanged.Subject.self, for: .changed ) Reference https://developer.apple.com/documentation/foundation/notificationcenter/messageidentifier/changed-50yz5 Questions How can I use by using NotificationCenter.messages(of: for:) for Calendar changes?

Hello, I have a question about App Intents and the Action button on iPhone. I have an App Intent that opens the app and navigates to a specific entity, conforming to OpenIntent with a single AppEntity parameter. The entity conforms to EnumerableEntityQuery, and the intent is registered as an App Shortcut via the AppShortcutsProvider. When assigning this shortcut to the Action button in Settings, the system doesn’t prompt the user to select a default entity upfront. Instead, it prompts on every activation, creating friction. In contrast, shortcuts like “Open Note…” and other third-party ones prompt the user for a note to open when setting up the Action button, and its title also includes three dots, indicating a pre-configurable parameter. My shortcut’s title shows no dots. What’s required to make an App Shortcut prompt for a default parameter during Action button setup? Sincerely, Holger

Is macOS 27 Public Beta 2 able to activate new non‑MDM CMIO system extensions that fail on macOS 26.5.2? I'm building a virtual-camera app with a CMIO camera system extension (Developer ID signed + notarized), for personal use on my own Macs — no MDM. On macOS 26.5.2 (25F80) I can't get a new activation to succeed, and I'm trying to find out whether macOS 27 resolves it. Two failure modes I've seen: With SIP enabled, OSSystemExtensionRequest reaches the daemon, then sysextd logs: "no policy, cannot allow apps outside /Applications" — even though the app is in /Applications (verified real path, single copy, running from there). This matches other reports (e.g. LuLu / network extensions). With SIP disabled + systemextensionsctl developer on, it now fails earlier, client-side, with OSSystemExtensionErrorDomain code 4 — "Extension not found in App bundle / Unable to find any matched extension with identifier" — the request never even reaches sysextd. Things I've already verified/ruled out: Product type com.apple.product-type.system-extension; extension embedded at Contents/Library/SystemExtensions/; matching CFBundleIdentifier and Team ID; CMIOExtensionMachServiceName = $(TeamIdentifierPrefix)$(bundle id). App has com.apple.developer.system-extension.install (with authorizing profile); shared App Group + camera entitlement on both app and extension. Valid codesign --deep --strict; notarized + stapled; single LaunchServices registration; running the correct bundle. Reproduces with both Developer ID and Apple Development signing, and running straight from Xcode with a signed-in account. So the app/extension appear structurally correct; this looks like an OS-side regression in 26.5.x. My question: Has anyone successfully activated a new Developer ID (non-MDM) CMIO / system extension on macOS 27 Golden Gate Public Beta 2? Is this sysextd / code‑4 activation regression fixed there, or is it still present? Trying to decide whether upgrading is worth it. Thank you!

I'm building a freediving app for Apple Watch Ultra using the shallow depth entitlement (com.apple.developer.submerged-shallow-depth-and-pressure). My app uses WKExtendedRuntimeSession with the underwater-depth background mode, and it works correctly — the session starts, Water Lock activates automatically, and Crown hold water ejection ends the session as expected. However, the app does not appear in Settings > General > Auto-Launch > When Submerged on the watch. Other third-party apps (including one that hasn't been updated in ~2 years and presumably only has the shallow entitlement) do appear in this list. My configuration: WKBackgroundModes: ["underwater-depth", "workout-processing"] WKSupportsAutomaticDepthLaunch: true (Boolean, in watch app Info.plist) Entitlement verified in both the signed binary and provisioning profile watchOS 26.3, Apple Watch Ultra 2 Tested with: development build, TestFlight, and direct Xcode deploy. Watch restarted after each. The app does not appear in any case. The documentation at https://developer.apple.com/documentation/coremotion/accessing-submersion-data states: "Adding the underwater-depth Background Mode capability also adds your app to the list of apps that the system can autolaunch when the wearer submerges the watch." Does auto-depth-launch require the full depth entitlement (com.apple.developer.submerged-depth-and-pressure), or should the shallow entitlement be sufficient? Is there an additional step required for the app to appear in the When Submerged list? Any guidance appreciated.

Hello, I've been working on this side project to help me understand the uses of Swift and CloudKit. In the middle of this project my "MHLocation" Data Record always keeps facing an internal error and this has been happening on and off for the past 6 months. What can I do to stop this error? I am willing to work with anyone on this. Best, Jordan

It's been 2+ months now since I've submitted an entitlement request for the Notification Service Filtering Entitlement (NSE). I have a mobile app that I transferred from a previous developer account due to business reorganization and the previous account had this entitlement. However, after transferring the app, I am unable to push any updates to the app on iOS because the new developer account does not have the same entitlement. Everything outside of the developer account that the app is associated to remains the same - same workflow, same audience, same app use cases, etc.. However, we still have not had any progress on receiving the entitlement even after multiple escalations and follow-ups with the Apple Developer Support team. I am curious to know if any others within the Developer Community have requested this specific entitlement before and what your experience has been with it? Any advice on how I can expedite the approval for the entitlement? Otherwise our app continues to go stale on the iOS app store.

Hello, For tracking purpose, is there a way to know when a widget is installed/uninstalled? Also, would it be possible to check which size widget was installed?

Hi everyone, I'm facing an issue with WidgetCenter.shared.getCurrentConfigurations() and I'm trying to determine whether this is expected behavior or a WidgetKit bug. Environment WidgetKit with IntentConfiguration One widget kind: PhotoBoxWidgetGroup Supported families: .systemSmall .systemMedium .systemLarge Steps to reproduce Fresh install the app. Add the PhotoBoxWidgetGroup widget to the Home Screen. Resize the widget between Small, Medium, and Large (or create different sizes during testing). Delete all instances of the widget from the Home Screen. Call: WidgetCenter.shared.getCurrentConfigurations { result in ... } Expected Result Since there are no widgets on the Home Screen, I expect: Widget count: 0 Actual Result getCurrentConfigurations() still returns three configurations: Widget count: 3 Kind: PhotoBoxWidget Family: systemLarge configuration: nil widgetConfigurationIntent: nil Kind: PhotoBoxWidget Family: systemMedium configuration: nil widgetConfigurationIntent: nil Kind: PhotoBoxWidget Family: systemSmall configuration: nil widgetConfigurationIntent: nil Although there are no widgets on the Home Screen, WidgetKit continues to report one configuration for each supported family. Additional observations This does not happen immediately after a fresh install. The issue appears only after the widget has been resized. If I restart the device, getCurrentConfigurations() correctly returns 0. After adding the widget again, resizing it, and deleting it, the issue reappears. I have also tried: reinstalling the app adding confirmation delays before querying querying only when the app becomes active filtering by kind comparing snapshots The result is always the same. Question Has anyone experienced WidgetCenter.shared.getCurrentConfigurations() returning stale widget configurations after widgets have been resized and removed? Is this a known WidgetKit issue, or is there an additional step required to ensure deleted widget configurations are removed from getCurrentConfigurations()? Any guidance or confirmation would be greatly appreciated.

We are implementing In-App Provisioning functionality for our Bank but there is always 500 Internal Server Error respond by Apple server once we tried to add card to apple wallet. Our code let request = PKAddPaymentPassRequest() request.activationData = try decodeBase64(payload.activationDataText, field: "activationDataText") request.encryptedPassData = try decodeBase64(payload.encryptedDataText, field: "encryptedDataText") request.ephemeralPublicKey = try decodeBase64(payload.ephemeralPublicKeyText, field: "ephemeralPublicKeyText") return request Because of fPanId is not required so we are not pass it to Apple server and that field generated once the card already added to wallet. Please help us investigate the issue, thanks! FeedbackId 24065847 (In-App Provisioning 500 Internel Error)

We are implementing In-App Provisioning functionality for our Bank but there is always 500 Internal Server Error respond by Apple server once we tried to add card to apple wallet. Our code let request = PKAddPaymentPassRequest() request.activationData = try decodeBase64(payload.activationDataText, field: "activationDataText") request.encryptedPassData = try decodeBase64(payload.encryptedDataText, field: "encryptedDataText") request.ephemeralPublicKey = try decodeBase64(payload.ephemeralPublicKeyText, field: "ephemeralPublicKeyText") return request Because of fPanId is not required so we are not pass it to Apple server and that field generated once the card already added to wallet. Please help us investigate the issue, thanks! FeedbackId 24065847 (In-App Provisioning 500 Internel Error)

I have the typical StoreKit 2 manager class, where I check currentEntitlements for subscription. I have filed a feedback (FB22349195), I hope someone can take a look at it. func updateCustomerProductStatus() async { var activeSubscription: String? = nil // BUG: In some cases the currentEntitlements does not emit a transaction until the device is reboot for await result in Transaction.currentEntitlements { print("Found transaction: \(result)") // This print does not appear until a restart! do { let transaction = try checkVerified(result) // Skip revoked transactions if transaction.revocationDate != nil { print("Skipping revoked transaction for \(transaction.productID)") continue } // Skip expired subscriptions if let expirationDate = transaction.expirationDate, expirationDate < Date() { print("Skipping expired subscription for \(transaction.productID)") continue } // Check product type switch transaction.productType { case .autoRenewable: activeSubscription = transaction.productID default: break } } catch { print("Unable to verify transaction: \(error)") } } // Update state once after processing all entitlements self.activeSubscription = activeSubscription print("updateCustomerProductStatus() activeSubscription: \(activeSubscription ?? "nil")") } There is some unexpected behavior where the currentEntitlements does not emit a result until the iPhone device is reboot. This bug appeared in iOS 26.4 (and in the betas).

Hello Apple Developer Forum, We have implemented the Declared Age Range API exactly as described in Apple's documentation. Our implementation checks isEligibleForAgeFeatures before calling requestAgeRange, as recommended. We have been testing with different users located in Texas (US) and Brazil. However, for all users, isEligibleForAgeFeatures consistently returns false, so the Declared Age Range prompt is never displayed. We would appreciate some clarification on the following: Under what conditions does isEligibleForAgeFeatures return true? When is the Declared Age Range prompt expected to be shown? Besides the user's region, are there any additional eligibility requirements, such as whether the Apple ID has a verified payment method (credit/debit card), verified identity or address, account age or a phased rollout? Since all of our test users are in supported regions (Texas and Brazil), we expected at least some users to be eligible. However, all four test accounts consistently return false. Could you please clarify how Apple determines eligibility for the Declared Age Range feature and when developers should expect the prompt to appear? Thank you for your guidance.

I'm developing a watchOS meditation app in which the user starts one continuous meditation session. During that session, I'd like the app to obtain a 1-minute HRV measurement immediately after the session begins (to establish a baseline), and then automatically obtain another 1-minute HRV measurement approximately 6 minutes after the session started, without requiring the user to manually start a second measurement or leave the app. My understanding is that HealthKit allows apps to read HRV samples after they have been recorded, but I haven't found a way to request that the watch generate a new HRV measurement. Is there any public API that allows a third-party watchOS app to initiate an HRV measurement similar to the Mindfulness/Breathe app, or otherwise request the Apple Watch to collect a new HRV sample at predetermined times during an ongoing session? Thanks in advance, Hern