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

In the WWDC 2019 session "Extended Runtime for WatchOS apps" the video talks about an entitlement being required to use the HR sensor judiciously in the background. It provides a link to request the entitlement which no longer works: http://developer.apple.com/contect/request/health-monitoring The session video is also quite hard to find these days. Does anyone know why this is the case? Is the API and entitlement still available? Is there a supported way to run, even periodically, in the background on the Watch app (ignoring the background observer route which is known to be unreliable) and access existing HR sensor data

I want to prompt users when their iCloud storage quota is full. My test device's iCloud space is full, and when subscribing to the NSPersistentCloudKitContainer-eventChangedNotification event, events exceeding the quota will not be passed to the application at runtime. When I tried to add data to Core data using NSPersistentCloudKitContainer, I got an error: <CKError 0x600000c15890: "Quota Exceeded" (25/2035); server message = "Quota exceeded"; op = 1ECF73B9554DF79F; uuid = 34D12DF0-A307-49EB-AD3A-BB646FF66F54; Retry after 316.0 seconds>}> My iCloud storage space is full, but I am unable to retrieve the 'Quota exceeded' error.I have written a demo, please help me fix the issue. github: CloudKit Sync Demo

Updated with FB24122131. Here's the ready-to-paste forum post: Title: registerForRemoteNotifications() never completes (no success, no error callback) since July 3 — App Store Connect metrics confirm same cutoff Body: Posting in case anyone else has hit this — happy to compare notes, and I've also filed FB24122131 with Apple directly. Since ~July 3, 2026, our app (MyRoost, iOS) has been completely unable to register for remote notifications. registerForRemoteNotifications() is called at launch, but neither didRegisterForRemoteNotificationsWithDeviceToken: nor didFailToRegisterForRemoteNotificationsWithError: ever fires. No token, no error — just silence, indefinitely. This isn't a new-integration bug — the same code worked fine through July 2. What's interesting is that App Store Connect's own "Push Notifications → Overview" dashboard for our app independently shows notifications received by APNs dropping from ~20/day to flat zero starting exactly July 3, matching our own logs precisely. We've ruled out essentially everything on our side: Push Notifications capability + entitlements (independently verified present in the actual signed binary, not just source, via a CI step that dumps the compiled .ipa's Info.plist and codesign entitlements) Firebase/APNs Authentication Key configuration OS-level notification permission (confirmed granted) MDM/configuration profiles (none), Screen Time restrictions (none) Wi-Fi vs. cellular (identical failure on both) Full device reboot, clean reinstall, account logout/login Reproduced identically on two separate physical devices (iPhone 17 Pro, iOS 26.5.2; iPad A16, iPadOS 26.5.2) Added native diagnostic logging to capture the raw error from didFailToRegisterForRemoteNotificationsWithError: directly — confirms the native callback itself never fires, not just that we're failing to observe it Filed an Apple Developer Support case (102936910825) on July 8 — after investigation, closed 2026-07-30 as "outside scope" and redirected here / to Feedback Assistant. Has anyone else seen a total, silent APNs registration failure like this, starting around the same early-July timeframe? Any workaround, or confirmation this is a known platform-side issue, would be hugely appreciated.

Hi Team, Our universal links were working fine but since last week we are facing issues and when tapping the links outside app it takes to browser and not the app. Apple CDN is returning 404 for our domain and not the contents of AASA file. https://app-site-association.cdn-apple.com/a/v1/app.ooredoo.om sudo swcutil dl -d app.ooredoo.om returns The operation couldn’t be completed. (SWCErrorDomain error 7.) Can we get the exact issue apple is facing to cache the AASA file in CDN. Any server config which we need to do for AASA bot to access the file. Thanks in advance.

The new Apple Maps 3D experience in iOS 27 beta has very cool 3D Gaussian Splat maps of a number of cities now. I would like to be able to include these views inside my native app using MKMapItem. Is there a way to enable this 3D view inside of these map views at the moment? Thanks!

Summary: In Sandbox, Product.products(for:) returns all 3 of my IAPs with correct JPY prices and Japanese localizations, but product.purchase() fails immediately — the payment sheet is never presented — with ASDServerErrorDomain Code=3504 (Product.PurchaseError.productUnavailable). All 3 products fail identically. Reproduction captured in the sysdiagnose attached to FB24067333: 2026-07-30 18:43:58 JST — in-app purchase() on app.negaiboshi.placement; 18:44:40 JST — OS-level test (Settings > Developer > Sandbox Apple Account > Manage > Start Transaction), same product ID. Server correlation keys from the device log: inAppBuy → AMSServerCorrelationKey HNB5UGLE72AXSMY5KY7G4NAXQY (failureType 3504); Start Transaction → FQN4Y4JOEHYBW2GIR7KPTYTB2A (AMSServerErrorCode 3766, "provided product ID or bundle ID is invalid"). Environment App: Negaiboshi — Apple ID 6794682125, Bundle ID app.negaiboshi, Team 778QPP83C4 App status: first submission in preparation (never reviewed); build 1.0 (1) on TestFlight IAPs (all "Ready to Submit" since 2026-07-27 JST, attached to the 1.0 submission): app.negaiboshi.pro.monthly (auto-renewable, ¥480, group 22264517), app.negaiboshi.placement (non-consumable, ¥720), app.negaiboshi.nightsky (non-consumable, ¥1,200) IAP base country: Japan (JPY); availability 145/175 countries Device: iPhone, iOS 26.5.2; development build from Xcode; StoreKit Configuration = None Sandbox Apple Account: (address in FB24067333), region Japan, no purchase history; signed in under Settings > Developer Storefront.current = JPN. No Screen Time restrictions. Actual error (verbatim): Error Domain=ASDServerErrorDomain Code=3504 "このアイテムは見つかりませんでした。" UserInfo={AMSServerErrorCode=3504, client-environment-type=Sandbox, storefront-country-code=JPN} TN3186 checklist fully verified, none apply (Paid Apps Agreement, banking, tax all active; bundle ID + IAP capability; signing; membership). Also tried: Sandbox sign-out/sign-in, device restart — no change. Consistent across all 3 products and relaunches. Reproduced with zero app code involved (decisive): Settings > Developer > Start Transaction with product ID app.negaiboshi.placement and bundle ID app.negaiboshi fails: "The provided product ID or bundle ID is invalid. [Environment: Sandbox]" — Apple's own OS-level tool, no third-party code. Calibration: a deliberately nonexistent ID (app.negaiboshi.zzz) yields the identical error — the backend treats my real product like a nonexistent one. A price change (¥720→¥700, "now", 2026-07-29) propagated to the sandbox metadata catalog within minutes (products(for:) returned "¥700") — purchase() still 3504. Reverted. A full base-country change (2026-07-30): Japan (¥720) → United States ($4.99) at 15:52 JST — this deletes and recreates the price schedule and is the exact operation that resolved the identical symptom in thread 839557. It propagated to the metadata catalog (auto-converted ¥800 shown in ~20 min), yet purchase() and Start Transaction still failed at 16:10 and 16:55 JST. Reverted to ¥720 at 16:59 JST. Every lever that rewrites the price schedule reaches the metadata catalog but never the commerce/purchase catalog. Timeline: the products reached Ready to Submit hours after the 2026-07-26 15:22–17:58 PDT In-App Purchases outage (Message ID 1000005803), and the failure still reproduces after the 2026-07-29 16:20–19:30 PDT emergency maintenance on In-App Purchases + Advanced Commerce API (messageId 1000005805). Peer reports with the same metadata-vs-commerce-catalog split in the same window: threads 839220, 839441, 839437, 839645, 839557. Questions: Why does purchase() fail server-side with 3504 ("item not found") while products(for:) succeeds for the same IDs in the same JPN storefront? Can someone check the sandbox commerce-catalog state of the 3 product IDs above (Apple ID 6794682125)? This looks like a server-side provisioning failure that no developer-side action can repair. Is any additional App Store Connect state required before sandbox purchases can complete for a never-yet-reviewed app?