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.

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.

Hi! I've noticed that the IP_RECVIF socket option, i.e.: int y = 1; setsockopt(fd, IPPROTO_IP, IP_RECVIF, &y, sizeof(y)); does not seem to work if the socket is proxied by a NETransparentProxyProvider type network extension: there's no ancillary data in messages received with recvmsg. As soon as I disable the network extension, recvmsg starts returning ancillary data containing the interface name. This seems to break some applications which rely on IP_RECVIF in the presence of a transparent proxy, making it, in fact, not transparent. One such example is Apple's own libresolv, which relies on IP_RECVIF and breaks if there's no ancillary data in the recvmsg result. I don't think that this is the intended behaviour, since IPV6_PKTINFO seems to work fine. I've filed a bug report (FB17586550) about this, however, I would greatly appreciate if someone could point me in the direction of a workaround.

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!

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.

The functionality of authorizationStatus and requestAuthorization is completely broken. I'm using Xcode 15.3 and iOS 17.4. Does anyone have a solution? authorizationStatus doesn't behave as promised Revoking authorization in the system-wide settings does not change the authorizationStatus while the app is not closed. Calls to center.authorizationStatus will still return .approved instead of .denied. Even closing and relaunching the app after revoking authorization does not work: authorizationStatus is then .notDetermined when it should be .denied. Tapping "Don't Allow" in the alert shown after an initial call to requestAuthorization leaves the authorizationStatus unchanged, i.e. at .notDetermined. This is contrary to the promised outcome .denied (defined as: "The user, parent, or guardian denied the request for authorization") and contrary to the definition of .notDetermined (defined as: "The app hasn’t requested authorization", when it just did). Same issue when first tapping "Continue" followed by "Don't Allow" on the next screen. As a consequence of authorizationStatus being broken, its publisher $authorizationStatus is worthless too. requestAuthorization doesn't behave as promised This is most likely a consequence of the corrupted authorizationStatus: when revoking authorization in the system-wide settings, a call to requestAuthorization opens the authorization dialogue instead of doing nothing. It is thus possible to repeatedly ask a user to authorize Family Controls. Code sample To reproduce, create a new SwiftUI app, add the "Family Controls" capability and a button executing the following task when tapped: let center = AuthorizationCenter.shared var status = center.authorizationStatus print(status) do { try await center.requestAuthorization(for: .individual) print("approved") } catch { print("denied") } status = center.authorizationStatus print(status)

The error below started today 10/17/2024 (on iOS 18.1 beta 5/6/7 at least) in StoreKit sandbox testing. Outside code/app, I can't even login to the test account in settings->AppStore->Sandbox Account (goes through email/phone confirmation and then silently fails). Tried a different password for a new sandbox test account with no success...Anyone experiencing this? P.S. Status page (https://developer.apple.com/system-status/) shows some related outage from two days ago, but no current problem. Error: Purchase did not return a transaction: Error Domain=ASDErrorDomain Code=530 "(null)" UserInfo={NSUnderlyingError=0x3009ca040 {Error Domain=AMSErrorDomain Code=100 "Authentication Failed The authentication failed." UserInfo={NSMultipleUnderlyingErrorsKey=( "Error Domain=AMSErrorDomain Code=2 "Password reuse not available for account The account state does not support password reuse." UserInfo={NSDebugDescription=Password reuse not available for account The account state does not support password reuse., AMSDescription=Password reuse not available for account, AMSFailureReason=The account state does not support password reuse.}", "Error Domain=AMSErrorDomain Code=306 "Reached max retry count Task reached max retry count (3 / 3);" UserInfo={AMSDescription=Reached max retry count, AMSURL=..., NSDebugDescription=Reached max retry count Task reached max retry count (3 / 3);, AMSFailureReason=Task reached max retry count (3 / 3);, AMSStatusCode=200}" ), AMSDescription=Authentication Failed, NSDebugDescription=Authentication Failed The authentication failed., AMSFailureReason=The authentication failed.}}, storefront-country-code=USA, client-environment-type=Sandbox}

Hello! In our App we found out the сrash at QuickLook after users updated their iPhones up to iOS 18. Crash report: SIGABRT 0x0000000000000000 Crashed: Thread 0 libsystem_kernel.dylib __abort_with_payload + 8 1 libsystem_kernel.dylib abort_with_payload_wrapper_internal + 104 2 libsystem_kernel.dylib abort_with_payload_wrapper_internal + 0 3 libobjc.A.dylib _objc_fatalv(unsigned long long, unsigned long long, char const*, char*) + 116 4 libobjc.A.dylib _objc_fatalv(unsigned long long, unsigned long long, char const*, char*) + 0 5 libobjc.A.dylib weak_register_no_lock + 396 6 libobjc.A.dylib objc_initWeak + 440 7 UIKitCore -[UIViewController viewDidMoveToWindow:shouldAppearOrDisappear:] + 1412 8 UIKitCore -[_UIRemoteViewController viewDidMoveToWindow:shouldAppearOrDisappear:] + 396 9 UIKitCore -[UIView(Internal) _didMoveFromWindow:toWindow:] + 1180 10 UIKitCore -[_UISizeTrackingView _didMoveFromWindow:toWindow:] + 112 11 UIKitCore -[UIView(Internal) _didMoveFromWindow:toWindow:] + 712 12 UIKitCore __45-[UIView(Hierarchy) _postMovedFromSuperview:]_block_invoke + 128 13 CoreAutoLayout -[NSISEngine withBehaviors:performModifications:] + 84 14 UIKitCore -[UIView _postMovedFromSuperview:] + 512 15 UIKitCore __UIViewWasRemovedFromSuperview + 136 16 UIKitCore -[UIView(Hierarchy) removeFromSuperview] + 248 17 QuickLook -[QLToolbarController setAccessoryView:animated:] + 576 18 QuickLook __55-[QLPreviewController _presentLoadedPreviewCollection:]_block_invoke + 120 19 QuickLookUICore QLRunInMainThread + 60 20 QuickLook -[QLPreviewController _presentLoadedPreviewCollection:] + 116 21 QuickLook __48-[QLPreviewController _presentPreviewCollection]_block_invoke_2 + 68 22 QuickLook (Missing) 23 libswift_Concurrency.dylib swift::runJobInEstablishedExecutorContext(swift::Job*) + 252 After research, we found out that a crash occurs in QuickLook when a user tries to open a file with unknown mimeType - application/octet-stream. QuickLook convert that files to known type (for an example - application/pdf), but crashes for the first opening the file. Any help would be greatly appreciated!

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

Since iOS 18.4 and macOS 15.4 updating the calendar of an (ek)event (to another accounts calendar) or detaching an repeating event throws an error while saving: "Access denied" EKEventStore.save(event, span: .thisEvent, commit: true) catch { "Access denied" }

Excited for AlarmKit! I have found two concerns that I cannot find answers for though. The volume of my alarms seems to be very quite relative to the full volume capability of the device. For example, if I turn the volume all the way up and play the audio file, the sound is very loud. However then, if I set the alarm using alarm kit with the same audio, the track played during the alerting phase is not that loud. I am afraid that it will not be loud enough in real life. Will there be future support to set the volume level of the alarm to maximum settings? When I press the volume buttons (with the app open) during an active alarm, the audio stops, but the alarm manager does not clear these events. The alarm manager does clear the alarm event if the alarm is stopped through a live activity.

I'm unable to view Changes or Diff View in the Deploy Schema Changes Dialog due to an Internal Error.

I have start new live activity with push notifications,but sometimes this code"activity.pushTokenUpdates" can not callback to me,so I can't update the activity with push notifications. And I already click “Allow” button in my live activity widget.How can I solve this problem. Here are my code： fileprivate func observeLiveActivityForRemoteCreate() { // obverser pushToStartToken Task { if #available(iOS 17.2, *) { var beforeToken = "" for await pushToken in Activity<HLPlatformActivityAttributes>.pushToStartTokenUpdates { let pushTokenStr = pushToken.map{String(format: "%02.2hhx", arguments: [$0])}.joined() // avoid send duplication if beforeToken == pushTokenStr { return } beforeToken = pushTokenStr // send pushToStartToken to service await HLPlatformLiveActivityBridge.registerLiveActivity(withAttributesName: self.activityAttributesName, pushToStartToken: pushToken, seq: seqCreate(), pushType: .jPush) } }else { // Fallback on eralier versions } // obverser live activity update Task { for await activity in Activity<HLPlatformActivityAttributes>.activityUpdates { if let businessLiveActivityId = activity.attributes.businessLiveActivityId, let liveActivityId = activity.attributes.liveActivityId { Task { var beforeToken = "" for await pushToken in activity.pushTokenUpdates { // here the problem：sometimes pushToken not update to me let pushTokenStr = pushToken.map{String(format: "%02.2hhx", arguments: [$0])}.joined() // avoid send duplication if beforeToken == pushTokenStr { return } beforeToken = pushTokenStr // send pushToken to service } } Task { for await stateUpdate in activity.activityStateUpdates { if stateUpdate == .active { // live activity create } } } } } } }

Hi there, We’re developing a companion app for a smart home product that communicates over the user’s local network. To provision the device, it initially creates its own Wi-Fi network. The user joins this temporary network and enters their home Wi-Fi credentials via our app. The app then sends those credentials directly to the device, which stores them and connects to the local network for normal operation. We’re using AccessorySetupKit to discover nearby devices (via SSID prefix) and NEHotspotManager to join the accessory’s Wi-Fi network once the user selects it. This workflow works well in general. However, we’ve encountered a problem: if the user factory-resets the accessory, or needs to restart setup (for example, after entering the wrong Wi-Fi password), the device no longer appears in the accessory picker. In iOS 18, we were able to work around this by calling removeAccessory() after the device is selected. This forces the picker to always display the accessory again. But in iOS 26, a new confirmation dialog now appears when calling removeAccessory(), which confuses users during setup. We’re looking for a cleaner way to handle this scenario — ideally a way to make the accessory rediscoverable without prompting the user to confirm removal. Thanks for your time and guidance.

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!

Hi there, My app uses all the Screen Time API's with individual FamilyControls authorization. I've been using the API's for over 2 years (since they came out). In iOS 18 Beta (maybe started in Beta 3?), I've been experiencing random issues. I tracked it down to where it seems like DeviceActivityMonitor extension is more likely to deadlock in iOS 18. To reproduce: when DeviceActivityMonitorExtension.intervalDidEnd gets called, IF you call DeviceActivityCenter.startMonitoring for that SAME DeviceActivityName from the DeviceActivityMonitorExtension , the startMonitoring call deadlocks (if I pause debugger, it does not advance past DeviceActivityCenter.startMonitoring). The bug is reported in FB14664238. It also contains a sample project where you can reproduce this. I also note in the comment section that this is not the only way to encounter this problem. My application code (which is a lot more complicated) seems to deadlock on calling DeviceActivityCenter.activities. As a result, there seems to be an "overall trend" where, due to some changes, DeviceActivityMonitor extension is more likely to deadlock. The steps are not reproducible on iOS 17.6. This is built using Xcode 17.4. Thank you! 🙏

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.

This error occurs in Apple Pay Wallet In-App Provisioning Flow for Credit / Debit Cards When the data received from the PNO (Visa) is passed to PKAddPaymentPassRequest this error is seen in addPaymentPassViewController, in the finalize stage. Docs provide no clue as to what could be wrong. iOS 18.2.1 XCode 15.2 Error description mentions "unsupportedVersionError" Is the pass version not supported? Is the wallet version not supported? Is it an app implementation error or error in the data received from the PNO?