It looks like ExtensionKit (and ExtensionFoundation) is fully available on iOS 26 but there is no mention about this in WWDC. From my testing, it seems as of beta 1, ExtensionKit allows the app from one dev team to launch extension provided by another dev team. Before we start building on this, can someone from Apple help confirm this is the intentional behavior and not just beta 1 thing?

Hello! I am experiencing some strange bugs around DeviceActivityEvents: When creating a DeviceActivityEvent we can assign a threshold and applicationTokens. The idea is, that after the user has spent said threshold on said apps, eventDidReachThreshold is called. includesPastActivity is set to false. On iOS 26 however, it happens (quite reliably after updating to a new beta seed) quite often that eventDidReachThreshold is called immediately (after a couple of seconds) instead of waiting for the threshold to be met. Is anyone else seeing similar issues on iOS 26? Only workaround I have found is to ask users to re-grant Screen Time permissions. This only holds for about two weeks though or at most until the next iOS 26 beta update is installed. Feedback filed under: FB18061981 FB18927456

I'm trying to digest and understand the new set of APIs relating age verification that were released last week. I have say that without some cohesive overview, example app, just a simple diagram showing the relationship of everything, its not at all clear to me what's going on nor what an app developer is expected to do to use these apis (I'm a senior engineer with 15 year's iOS experience, but hey maybe I'm just a bit slow in the head). I have a few questions, but the topic of this post is what is the relationship between age verification i.e. between the declared age range/significant change and Permission Kit? The documentation for the former mentions the Significant Change API/Topic (https://developer.apple.com/news/?id=2ezb6jhj / https://developer.apple.com/documentation/PermissionKit/SignificantAppUpdateTopic). Now the Significant Change Topic is documented as being part of PermissionKit, however the documentation for that (https://developer.apple.com/documentation/permissionkit) States emphatically at the top: "Communication experiences using the PermissionKit framework are only available using iMessage." Meaning you can't use PermissionKit for anything other than iMessage? If it doesn't mean that, then why does it state so? If it does mean that, then how does an app which has nothing to do with iMessage make use of Significant Change - because this documentation:https://developer.apple.com/news/?id=2ezb6jhj Is talking about using significant change for all apps, not iMessage. So there is a contradiction here.

I am trying to implement a third party passkey credential provider and I have been able to successfully setup the project for that. Below is a sample code which I am using - let passkeyRegistrationCredential = ASPasskeyRegistrationCredential(relyingParty: self.request?.credentialIdentity.serviceIdentifier.identifier ?? "", clientDataHash: self.request?.clientDataHash ?? Data(), credentialID: Data(credentialId), attestationObject: Data(attestationBytes) self.extensionContext.completeRegistrationRequest(using: passkeyRegistrationCredential) The attestationBytes object that I am generating and sending back to RP seems to work only if I set the "fmt" to "none", which basically requires "attStmt" to be sent as an empty value as per WebAuthn spec - https://www.w3.org/TR/webauthn-2/#sctn-none-attestation When trying to set the "fmt" to "packed" in attestation object and creating a self signed "attStmt" consisting of "alg" and "sig" key-values referring - https://www.w3.org/TR/webauthn-2/#sctn-packed-attestation, it does not seem to work. The RP throws an error. I do not have "x5c" object as that supposedly is not mandatory in case of self attestation. I have "authData" also as part of the response properly setup. Is it not possible to use packed attestation or am I missing something in creating the attestation object? Also, does Apple modify the response being sent in the background before sending to RP if packed fmt is used?

I’ve filed this as FB20943098 (macOS 26.1 – FileProvider v3 synchronous enumeration bug), but posting here in case others can reproduce and add duplicates. Systems: macOS 26.1 (26B82) M4 Mac mini Pro and M4 MacBook Air Symptoms: In any app (TextEdit, Pages, Browsers, etc.), the Open/Save dialog lags for ~1s per folder navigation click. CPU spikes from fileproviderd, cloudd, bird, and siriactionsd. Key discovery: If my iCloud Drive root is empty (only “Documents” and “Downloads”), performance is perfect. As soon as any folder or file exists at the root of iCloud Drive, the lag returns immediately. Moving those items into “Documents” or “Downloads” makes everything smooth again. Analysis: Based on process traces and container paths, this appears to originate in the FileProvider.framework subsystem (via fileproviderd), which mediates iCloud Drive. Early evidence suggests that folder enumeration of the iCloud Drive container root may be blocking UI threads in macOS 26.1. I believe this may be related to the recent internal migration of the file-provider backend (often referred to as “v3”), but I do not have direct confirmation from Apple of that exact change. MacOS 26.1’s new FileProvider v3 backend seems to be blocking the Open/Save panel while enumerating the iCloud Drive root container (~/Library/Application Support/FileProvider/723EBBFF-…). Folder enumeration seems to wait synchronously for metadata from fileproviderd, and if the local SQLite DB is busy (WAL writes or sync state checks), UI freezes briefly. Workarounds: Disabling iCloud Drive entirely fixes the issue. Simply disabling Desktop/Documents sync does not help. Keeping the iCloud Drive root empty avoids the lag without turning iCloud off. I am able to store whatever I please in the Desktop or Documents folder which is currently syncing. Would appreciate if others on 26.1 could confirm. Engineers: I’ve attached fs_usage, log stream, and process samples to my Feedback ticket via the FB20943098. Expected behavior: Folder enumeration in NSOpenPanel should remain asynchronous regardless of FileProvider background activity. Open/save modal should be responsive and smooth.

Hi, On iOS 26 beta, calls can no longer be reported by swiping left on a call. This is unfortunately a breaking change. I have submitted a report on this on June with Feedback Assistant: FB17893517 I hope it will get some more exposure by posting here.

Hello, I hope to find out more about how AppTransaction works on macOS, specifically about its internet connection requirements: if I use this to validate that the app is a legit purchase from the Mac App Store, I would not want it to have an always-on requirement just to validate. Does AppTransaction require the user to always be online for AppTransaction.shared ? When an app is downloaded from the Mac App Store, is the data needed for AppTransaction automatically embedded during that download, or is that data downloaded upon first launch of the app, therefore requiring an internet connection at launch time? Once the data/receipt has been downloaded by AppTransaction, is it cached until the app's next update, or is it cleared at some time during the version's life and needs to be re-downloaded, therefore requiring an internet connection at launch? Where is that receipt/data stored? Also, if you don't mind me sneaking in this non-related but sort of related question, in terms of receipt validation: Does macOS Sequoia's MAC address rotation feature affect receipt validation in any way when using IOKit? Thank you kindly, – Matthias

Hi gurus, Recently I tried to use dtrace on macOS to do some performance analysis, and found that dtrace reliably freezes the whole system. I have disabled SIP (recovery mode, csrutil disable), when I run sudo filebyproc.d (or any other dtrace command), the whole system just freezes, only hard restart (press power button) can restore the system. I saw someone answered in https://developer.apple.com/forums/thread/735939 mentioning restart the system without sleep can work around this issue, but in my case, it doesn't work, even after fresh restart, it's the same. Is this a known issue? Any way around this issue? My system: macOS Sequoia 15.3.1 on M2. Regards, jz

Hi, In macOS26 beta, our app icon is not showing anymore in the MenuBar. It is also not displayed in the new section "Menu Bar > Allow in the Menu Bar", which seems to be the way to show/hide Menu Bar icons in macOS 26. The icon is correctly displayed and working in macOS 15. Our app is signed and notarized. It also has the "LSUIElement" value set to "true" in the Info.plist file. Is there some new mandatory entitlements to add in order to have our app showing in the "Allow in the Menu Bar" section? Thanks in advance for your help. Regards

Hi! Sms reporting is no longer available in iOS beta 26 builds. I can set my app as the SMS/Call Reporting Extensions but the report button is missing for sms messages in the messages app. Xcode 26 beta 7 build the app without errors. This is a breaking change. Same extension was previously broken for calls but has been fixed in beta 7 build, as reported here. It is however still missing for sms messages in the messages app (beta 9 build).

Dear Apple Support Team, Hello! I am currently developing the in-app subscription functionality using Apple IAP API and have encountered a serious technical issue while processing subscription data. I would like to report this issue to you. Issue Description: When calling the subscription API endpoint, the same OriginalTransactionId returns inconsistent results. Specifically, a particular transaction ID (let's call it TransactionId_A) should belong to the subscription order with OriginalTransactionId_A, but it is currently incorrectly associated with OriginalTransactionId_B. This issue severely affects our ability to accurately manage and process subscription data. Here are the relevant log details for your reference: API Endpoint Requested: https://api.storekit.itunes.apple.com/inApps/v1/subscriptions/{TransactionId_A} (Note: The link is a placeholder for the actual API endpoint.) Log Information on February 21, 2025, at 09:40:09: { "AppAccountToken": "{AppAccountToken}", "BundleId": "{BundleId}", "Currency": "CNY", "Environment": "Production", "ExpiresDate": {ExpiresDate}, "InAppOwnershipType": "PURCHASED", "IsUpgraded": false, "OfferDiscountType": "", "OfferIdentifier": "", "OfferType": 0, "OriginalPurchaseDate": {OriginalPurchaseDate}, "OriginalTransactionId": "{OriginalTransactionId_A}", "Price": {Price}, "ProductId": "{ProductId}", "PurchaseDate": {PurchaseDate}, "Quantity": 1, "RevocationDate": 0, "RevocationReason": 0, "SignedDate": {SignedDate}, "Storefront": "CHN", "StorefrontId": {StorefrontId}, "SubscriptionGroupIdentifier": "{SubscriptionGroupIdentifier}", "TransactionId": "{TransactionId_A}", "TransactionReason": "PURCHASE", "Type": "Auto-Renewable Subscription", "WebOrderLineItemId": "{WebOrderLineItemId}" } Log Information on March 21, 2025, at 09:38:49: { "AppAccountToken": "{AppAccountToken}", "BundleId": "{BundleId}", "Currency": "CNY", "Environment": "Production", "ExpiresDate": {ExpiresDate}, "InAppOwnershipType": "PURCHASED", "IsUpgraded": false, "OfferDiscountType": "", "OfferIdentifier": "", "OfferType": 0, "OriginalPurchaseDate": {OriginalPurchaseDate}, "OriginalTransactionId": "{OriginalTransactionId_B}", "Price": {Price}, "ProductId": "{ProductId}", "PurchaseDate": {PurchaseDate}, "Quantity": 1, "RevocationDate": 0, "RevocationReason": 0, "SignedDate": {SignedDate}, "Storefront": "CHN", "StorefrontId": {StorefrontId}, "SubscriptionGroupIdentifier": "{SubscriptionGroupIdentifier}", "TransactionId": "{TransactionId_A}", "TransactionReason": "PURCHASE", "Type": "Auto-Renewable Subscription", "WebOrderLineItemId": "{WebOrderLineItemId}" } From the above logs, it is evident that the same transaction (TransactionId_A) returns different OriginalTransactionId values at different times, which is clearly not expected and severely impacts our ability to correctly process and manage subscription data. I hope you can address and investigate this issue as soon as possible. If you need any further information or assistance, please feel free to contact me. Thank you for your support! Best regards!

Hello, Since updating to iOS 26 Beta 3, I’ve been experiencing an issue where transactions purchased through the normal in-app purchase flow continue to be reported as updated and unfinished—even after calling the finish() function. Please resolve this promptly.

I have a device. After pairing, it is shown as connected in the Bluetooth list of the mobile phone. Before iOS 18, I could retrieve the device through the retrieveConnectedPeripherals method, but after iOS 18, I cannot retrieve it. What is the reason? Because when the device is connected, it no longer sends broadcast packets. How can I retrieve the device?

We're seeing a consistent issue where iPads with the A16 chip fail to connect to our BLE device, which uses a Silicon Labs chip running Gecko SDK 3.x. All other Apple devices — including older iPads and iPhones — connect without any problems. According to Silicon Labs, the issue stems from the iPad A16 sending an LL_CHANNEL_REPORTING_IND message (opcode 0x28) during connection establishment: Per Silicon Labs: "Currently the iPad 16 will send a message for LL_CHANNEL_REPORTING_IND (opcode 0x28). This is a feature that is not supported in Gecko SDK 3.x. Shortly after, the BLE module responds with an 'Unknown Response' (opcode 0x07), indicating that it does not support opcode 0x28 After this exchange the iPad stops sending meaningful transactions to the BLE module and eventually closes the connection. The BLE Module is responding to this unknown request as specified in the BT Core Spec Volume 6 Part B." Unfortunately, the firmware on these BLE modules cannot be updated remotely, and we've already shipped several thousand units to customers. Given how widely Silicon Labs' BLE modules are deployed, we suspect this issue could be affecting many other developers and products as well. We’re hoping Apple might offer a workaround or allow us access — even internally or unofficially — to suppress or bypass this feature in CoreBluetooth for this specific scenario. For example, is there a way to disable LL_CHANNEL_REPORTING_IND or instruct the stack to ignore the unknown response from the peripheral? We’re open to any workaround via CoreBluetooth (even private APIs or entitlements, if necessary) that would allow us to preserve compatibility without a mass recall. If there's an Apple engineer monitoring this, we'd be extremely grateful for guidance or escalation. Thank you!

I'm encountering an issue with the App Store Server API where the appAccountToken is not preserved when users migrate their Apple ID email addresses. I've submitted Feedback Assistant ticket FB18709241 but wanted to check if anyone else has experienced this and get community input on best practices. The Issue When a user migrates their Apple ID from one email to another (e.g., from olduser@example.com to newuser@icloud.com), the App Store creates a new subscription transaction with a different originalTransactionId, but the appAccountToken is not carried forward from the original transaction. What I'm Seeing note: these values are fake When querying /inApps/v1/subscriptions/{originalTransactionId} with the either post-migration transaction ID or the pre-migration transaction ID, the API returns both transactions: Pre-migration transaction (status: 2 - inactive): originalTransactionId: "12345678910111" Contains: "appAccountToken": "abc123-def456-ghi789" Post-migration transaction (status: 1 - active): originalTransactionId: "67891011121314" Missing: appAccountToken entirely The Problem The appAccountToken is our only way to link App Store subscriptions to user accounts. Without it on the new transaction: Users lose access to premium features despite having valid subscriptions Server-side renewal notifications can't be matched to user accounts Manual support intervention is required for each affected user Questions for the Community Has anyone else encountered this issue with Apple ID migrations? What's the recommended approach for handling this scenario? Is there an alternative mechanism to maintain the subscription-to-user linkage across migrations? Questions for Apple Engineers Is this the expected behavior, or should the appAccountToken be preserved? Are there any planned improvements to handle this migration scenario? What's the best practice for developers to handle this case? Interestingly, both the old and new transaction IDs return the same JSON response from the App Store Server API, suggesting Apple maintains internal linkage between these transactions, but the appAccountToken isn't carried forward to the active transaction. Any insights or similar experiences would be greatly appreciated! Thank you!! Feedback Assistant: FB18709241

Invalid entitlement for core nfc framework. The sdk version '18.2' and min OS version '14.0' are not compatible for the entitlement 'com.apple.developer.nfc.readersession.formats' because 'NDEF is disallowed'. Anyone knows what is the correct configuration SDK version and minimum iOS deployment target for NFC that has NDEF format?

I'm working on an XPC server and need to determine the owner of the client process that connects to it. Specifically, I'd like to retrieve details such as the fully qualified user name or other identifying information from the XPC client connection.I'm considering using xpc_connection_get_pid() to get the client’s process ID, but I’m unsure of the best way to map this to the user who owns the process. Is there a recommended API or approach to capture this information securely?

I have an odd issue I'm trying to troubleshoot. I have an app that is deployed to our enterprise and works on almost all of our devices. Lately, I have devices (very small number) where the app installs from our MDM and it crashes upon launch, it does not get past the launch screen. If I remove and reinstall the app from the MDM it still crashes. I decided to put the devices in developer mode and if I run the App from Xcode on the device it works fine. If I stop it and run it right from the device it also works. If I do a final build of the app and install it using "Devices and Simulators", the app crashes upon launch. Using "Devices and Simulators" I check for crash log for the app and no file. I am stumped as to whats going on.

Apple Feedback Ticket: FB16804936 Background We develop a parental control application called Adora Kids (https://apps.apple.com/us/app/adora-kids/id6443787669) that requires "Location Always" permission to function properly. Our app has Screen Time authorization and provides monitoring services for parents. Issue We are experiencing a recurring problem where child users receive the system notification "Adora accessed your location in the background" every few days. This frequently results in children disabling location permissions, which prevents our app from functioning as intended. Current Approach and Limitations We have explored using Content & Privacy Restrictions for Location Services as a potential solution, but have encountered two significant limitations: These restrictions cannot be accessed programmatically via the ManagedSettings framework (unlike AppStoreSettings and other restrictions). The current implementation is "all-or-nothing" - enabling location restrictions blocks permission changes for ALL apps on the device, preventing children from granting legitimate location access to other applications. Questions Is there a way to programmatically access and manage Content & Privacy Restrictions for Location Services through the ManagedSettings framework that we might have overlooked? Are there any recommended approaches for apps with Screen Time authorization to prevent users from changing specific permissions (particularly location) while still allowing them to manage permissions for other apps? Does Apple have plans to implement app-specific permission locking for apps with Screen Time authorization in future iOS releases? Are there any alternative approaches or workarounds that other developers have successfully implemented for this use case? Any guidance from the developer community or Apple engineers would be greatly appreciated. This is a critical functionality issue affecting the reliability of our parental control service. Thank you in advance for your assistance.

I'm reaching out to see if anyone else is experiencing issues with the Live Caller ID feature on iOS. We recently encountered a problem where the feature stopped working entirely. Here's a brief overview of the situation: We were monitoring test traffic on our backend and noticed everything came to a halt around 1:00 AM UTC on November 15th. After this time, any attempts to reach our backend through calls failed completely. I tested this across multiple devices running iOS 18.2 and iOS 18.0. I used both TestFlight builds and development builds via Xcode, which should communicate directly with our backend. I experienced the problem on our main application as well as a dedicated test app. To troubleshoot further, I even set up a local server on localhost and tried directing requests there, but the requests did not reach the local server when a call was received. Further debugging in Console.app revealed the following error: identity request returned error: Error Domain=com.apple.CipherML Code=400 "Error Domain=com.apple.CipherML Code=401 "Unable to request data by keywords batch: failed to fetch token issuer directory" However, when I manually tried to hit our server endpoint using curl, the request successfully reached the server: curl https://our_server/something hb_method=GET hb_uri=/something [Hummingbird] Request -- log on backend This suggests that while our backend is responsive, the requests from the iOS client side are simply not being initiated.