I am planning to run the AccessoryNotifications framework on xcode26.4 and ios26.4, please refer to the documentation https://developer.apple.com/documentation/accessorynotifications I couldn't find a complete demo, but I found a demo based on AccessorySetup Kit, ASK Sample https://docs-assets.developer.apple.com/published/89f5eef578ef/SettingUpAndAuthorizingABluetoothAccessory.zip. So I plan to practice the entire process of AccessoryNotifications based on this demo. Find accessories based on ASK Sample and connect them, OK Call requestForwarding (for:), OK Add AccessoryData Provider extension to receive system notifications But this step failed. I added an extension according to the documentation, but the following method will not be executed func activate(for session: NotificationsForwarding.Session) func add(notification: AccessoryNotification alertingContext: AlertingContext, alertCoordinator: AlertCoordinating) {} I found the following error log in console.app Error 16:38:17.582340+0800 usernotificationsd ### XPC DAEventExtension decode failed: DAExtensionSession: CID 0x89B80004, DAExtensionSessionConfiguration 'AB83C506-9F35-40FB-9A68-919D43B4D098': BundleID 'com.sifli.ASKSample', DAErrorDomain:350001 'DAExtensionEvent init bad type: 42' I have tried many methods to send messages to the testing phone, local Notifications, We can't even trigger the AccessoryData Provider, activate:for,add:notification: 1.Do I have to add the following two extensions according to the document in order to debug successfully? AccessoryTransportSecurity Manages cryptographic key exchange with your accessory. AccessoryTransportAppExtension Relays encrypted data to your accessory over Bluetooth. 2.What should be selected in the extension template panel of xcode 26.4 when creating these extensions? Geniric Extension Accessory Data Transport I am currently using Geniric Extension

Hi, We are the developers of Morning Call (https://morningcall.info), and we believe we may have identified an AlarmKit / system UI bug on iPhone. We can reproduce the same behavior not only in our app, but also in Apple’s official AlarmKit sample app, which strongly suggests this is a framework or system-level issue rather than an app-specific bug. Demonstration Video of producing zombie Live Activity https://www.youtube.com/watch?v=cZdF3oc8dVI Related Thread https://developer.apple.com/forums/thread/812006 https://developer.apple.com/forums/thread/817305 https://developer.apple.com/forums/thread/807335 Environment iPhone with Dynamic Island Alarm created using AlarmKit Device is unlocked when the alarm begins alerting Steps to reproduce Schedule an AlarmKit alarm. Wait for the alarm to alert while the device is unlocked. The alarm appears in Dynamic Island. Instead of tapping the intended stop or dismiss button, swipe the Dynamic Island presentation away. Expected result The alarm should be fully dismissed. The Live Activity should be removed. No empty UI should remain in Dynamic Island. Actual result The assigned AppIntent runs successfully. Our app code executes as expected. AlarmKit appears to stop the alarm correctly. However, an empty “zombie” Live Activity remains in Dynamic Island indefinitely. The user cannot clear it through normal interaction. Why this is a serious user-facing issue This is not just a cosmetic issue for us. From the user’s perspective, it looks like a Live Activity is permanently stuck in Dynamic Island. More importantly: Force-quitting the app does not remove it Deleting the app does not remove it In practice, many users conclude that our app has left a broken Live Activity running forever We receive repeated user complaints saying that the Live Activity “won’t go away” Because the remaining UI appears to be system-owned, users often do not realize that the only reliable recovery is to restart the phone. Most users do not discover that workaround on their own, so they instead assume the app is severely broken. Cases where the zombie state disappears Rebooting the phone Waiting for the next AlarmKit alert, then pressing the proper stop button on that alert Additional observations Inside our LiveActivityIntent, calling AlarmManager.shared.stop(id:) reports that the alarm has already been stopped by the system. We also tried inspecting Activity<AlarmAttributes<...>>.activities and calling end(..., dismissalPolicy: .immediate), but in this state no matching activity is exposed to the app. This suggests that the alarm itself has already been stopped, but the system-owned Live Activity UI is not being cleaned up correctly after the swipe-dismiss path. Why this does not appear to be an app logic issue The intent is invoked successfully. The alarm stop path is reached. The alarm is already considered stopped by the system. The remaining UI appears to be system-owned. The stuck UI persists even after our own cleanup logic has run. The stuck UI also survives app force-quit and app deletion.

After building the sample and enabling the file system extension the mount command is freezing. Any tips how to diagnose that? The logs show the following: log stream --style compact --info --debug --predicate 'subsystem == "com.apple.FSKit" OR process CONTAINS[c] "samplecode"' Filtering the log data using "subsystem == "com.apple.FSKit" OR process CONTAINS[c] "samplecode"" Timestamp Ty Process[PID:TID] 2026-03-17 15:15:51.832 I mount[16111:d88caa] [com.apple.FSKit:default] FSClient setting up connection to fskitd 2026-03-17 15:15:51.833 Db fskitd[589:d88a5f] [com.apple.FSKit:default] -[liveFilesMountServiceDelegate listener:shouldAcceptNewConnection:]: start 2026-03-17 15:15:51.833 Df fskitd[589:d88a5f] [com.apple.FSKit:default] Incomming connection, entitled 0 2026-03-17 15:15:51.833 Db fskitd[589:d88a5f] [com.apple.FSKit:default] -[liveFilesMountServiceDelegate listener:shouldAcceptNewConnection:]: accepting connection 2026-03-17 15:15:51.833 Df fskitd[589:d88a5f] [com.apple.FSKit:default] Hello FSClient! entitlement no 2026-03-17 15:15:51.834 Df mount[16111:d88caa] [com.apple.FSKit:default] Setting remote protocol to all XPC 2026-03-17 15:15:51.834 Df fskitd[589:d88a5f] [com.apple.FSKit:default] About to get current agent for 501 2026-03-17 15:15:51.834 I fskitd[589:d88a5f] [com.apple.FSKit:default] About to call to fskit_agent 2026-03-17 15:15:51.835 I fskit_agent[10123:d877d9] [com.apple.FSKit:default] Getting extensions 2026-03-17 15:15:51.836 Db fskitd[589:d88a5f] [com.apple.FSKit:default] -[fskitdAgentManager currentExtensionForShortName:auditToken:replyHandler:]_block_invoke: Found extension for fsShortName () 2026-03-17 15:15:51.837 I fskitd[589:d88a5f] [com.apple.FSKit:default] Probe starting on 2026-03-17 15:15:51.837 Db fskitd[589:d87c31] [com.apple.FSKit:default] -[FSResourceManager getResourceState:]:found: 2026-03-17 15:15:51.837 Db fskitd[589:d87c31] [com.apple.FSKit:default] -[FSResourceManager addTaskUUID:resource:]:: Adding task () 2026-03-17 15:15:51.837 Df fskitd[589:d87c31] [com.apple.FSKit:default] About to get current agent for 501 2026-03-17 15:15:51.837 I fskitd[589:d87c31] [com.apple.FSKit:default] About to call to fskit_agent 2026-03-17 15:15:51.837 I fskit_agent[10123:d877d9] [com.apple.FSKit:default] Getting extensions 2026-03-17 15:15:51.838 Db fskitd[589:d87c31] [com.apple.FSKit:default] -[fskitdXPCServer getExtensionModuleFromID:forToken:]_block_invoke: Found extension , attrs 2026-03-17 15:15:51.838 Db fskitd[589:d87c31] [com.apple.FSKit:default] applyResource starting with resource kind 4

Hi everyone, I’m seeing a blank Live Activity in my app after the alarm fires. Has anyone encountered this before or knows how to fix it? Any guidance would be greatly appreciated. At the top of the screen, there’s a blank Live Activity:

Hi! My users have reported (and I have observed) a blank Live Activity where only a black capsule is shown in the dynamic island. When tapping that capsule, the app opens, but inside the capsule, nothing is shown. The Live Activity is created through the AlarmKit API like this: let identifier = UUID() Task { do { _ = try await AlarmManager.shared.schedule( id: identifier, configuration: .init( countdownDuration: countdownDuration, attributes: attributes, stopIntent: CancelTimerIntent(), secondaryIntent: RestartTimerIntent(), sound: Settings.shared.systemAlarmToneEnabled ? .default : .named(Settings.shared.alarmTone[.loop].filename) ) ) Log.debug("Alarm scheduled successfully: \(identifier.uuidString)") } catch { Log.error("Error scheduling alarm with id \(identifier.uuidString), error: \(error)") } } I've read some other forum posts where developers reported the same issue: https://developer.apple.com/forums/thread/807335 https://developer.apple.com/forums/thread/812006 I assume, it has something to do with state management. However, in my case, this only happens very rarely. I use the app on a daily basis and the issue with the blank live activity only occurs like once a month, so I cannot reproduce it. I also have some logic to resume an existing alarm or snooze: do { for alarm in try AlarmManager.shared.alarms { switch alarm.state { case .paused: try AlarmManager.shared.resume(id: alarm.id) case .alerting: try AlarmManager.shared.countdown(id: alarm.id) default: break } } } catch { Log.error("Error resuming alarm: \(error)") } Is there any way I can debug this issue properly? I have checked the Device Logs and the Console in Xcode and didn't find any hints. Only one log made me a little suspicious, but I read that this might happen occasionally and may be ignored: Couldn't read values in CFPrefsPlistSource<0x10ae0d080> (Domain: group.myappgroupidentifier User: kCFPreferencesAnyUser, ByHost: Yes, Container: (null), Contents Need Refresh: Yes): Using kCFPreferencesAnyUser with a container is only allowed for System Containers, detaching from cfprefsd Any ideas on how I could proceed to find the cause of this empty (apparently crashed) Live Activity?

iOS 26.4系统上，我们发现三个问题： 1.调用了finishTransaction接口，但是在App重新启动后，[SKPaymentQueue defaultQueue].transactions仍然会有这笔订单。 2.支付完成后，[[NSBundle mainBundle] appStoreReceiptURL]]，拿到的票据解析出来里面的商品是空的，需要延迟2秒钟左右在调用[[NSBundle mainBundle] appStoreReceiptURL]]才能获取有效票据。 3.支付完成后，如果用户没有点击最后弹出的确认弹框，等待5秒钟，系统会自己回调 - (void)paymentQueue:(SKPaymentQueue *)queue updatedTransactions:(NSArray<SKPaymentTransaction *> *)transactions; 代理方法。正常应该是用户点击了最后弹出的确认弹框，在回调- (void)paymentQueue:(SKPaymentQueue *)queue updatedTransactions:(NSArray<SKPaymentTransaction *> *)transactions;方法。 我们在苹果开发者论坛上面找到其他开发者反馈的类似问题，链接如下： https://developer.apple.com/forums/thread/817700 https://developer.apple.com/forums/thread/792437?answerId=849557022#849557022 https://developer.apple.com/forums/thread/817834 https://developer.apple.com/forums/thread/817706 https://developer.apple.com/forums/thread/818586 我们有大量用户升级到了26.4系统，这对于我们造成了巨大的困扰，我们需要你们的帮助，感谢！

I try to update remoteHandle using CXCallUpdate for outgoing call, but this works only on iOS 15 but not on 17 or 18 (16 didn't test). This problem actual only for outgoing calls, but for incoming calls update works fine. func startOutgoingCall(with callID: UUID, userID: String) { let handle = CXHandle(type: .generic, value: userID) let action = CXStartCallAction(call: callID, handle: handle) callController.requestTransaction(with: action) { [weak self] error in // ... } } func updateOutgoingCall(with callID: UUID, groupID: String) { let update = CXCallUpdate() update.remoteHandle = CXHandle(type: .generic, value: groupID) provider.reportCall(with: callID, updated: update) } I also tried phoneNumber type but it seems initial handle that I set to CXStartCallAction not possible to change (value or even type). I use this handle value to implement recall by tap on call in Recents tab of system address book. But since my calls can transform from p2p to group call, I need to update handle value or find some another way to pass call identification info.

We're seeing some strange behavior of the appAccountToken when passing it to a purchase in the sandbox environment. Normally we'd expect the same account token to be set on the resulting verfication, but that's not the case. Instead the token seems to be persisted on the API side and reused for some amount of time, meaning there's a mismatch and the connection between account and purchase is lost. This happens consistently even if we send new tokens on each purchase. Has there been any updates to purchase flow in the sandbox environment on Apple's side? .purchase( options: [.appAccountToken(token)] )

HealthKit is currently not supported on macOS nor tvOS, despite being supported by visionOS. Support for macOS was last asked about[1] here in 2018. My goal is to display interactive data visualisations over workouts collected in HealthKit on macOS. Will this be possible to do in the near future using HealthKit directly? If not, can I somehow read the information from an iPhone and display it on the mac? Cheers, Rodrigo [1] https://developer.apple.com/forums/thread/94937

Hello, I am investigating a case where two different transaction IDs appear to refer to the same purchase, and I would like clarification on whether this behavior is expected. Additional context StoreKit version: StoreKit 1 (SKPaymentTransaction) Environment: Production Product type: Auto-renewable subscription Transaction sources The values are obtained from the following APIs: transaction_id from SKPaymentTransaction https://developer.apple.com/documentation/storekit/skpaymentqueue receipt_data from the App Store receipt https://developer.apple.com/documentation/foundation/bundle/appstorereceipturl Observed behavior After an In-App Purchase completes, the app receives: a transaction_id from SKPaymentTransaction the corresponding receipt_data for the purchase When inspecting the receipt, the transaction_id inside latest_receipt_info differs from the transaction_id received directly from the purchase transaction. For clarity: A = transaction_id received from the purchase flow (SKPaymentTransaction) A' = transaction_id found in receipt_data.latest_receipt_info The two values are different, but they differ only by 1. Additional observation The original_transaction_id for A and A' is identical, which suggests that both transaction IDs belong to the same subscription purchase chain. Pattern observation on the ID difference We have observed that the difference between A and A' is consistently exactly 1 (i.e., A' = A + 1) across multiple transactions, not just a single case. This appears to be a reproducible pattern rather than a coincidence. This observation raises an additional question (Question 6 below). API verification When calling: GET /inApps/v1/transactions/{transactionId} Both A and A' return what appears to be the same purchase record. The response data is effectively identical except for the transactionId field. However, when calling: GET /inApps/v2/history/{transactionId} A does not appear in the transaction history only A' appears in the history response Questions If A does not appear in transaction history, where does this transaction ID originate from? Why does Get Transaction Info (/inApps/v1/transactions/{transactionId}) return a valid response for A even though it is not present in the transaction history? Why do A and A' both resolve to what appears to be the same purchase? In this situation, which transaction ID should be treated as the canonical transaction ID for server-side validation? Is this difference related to how StoreKit 1 (SKPaymentTransaction) and the App Store Server API represent transactions? Is the consistent off-by-one difference between the transaction_id from SKPaymentTransaction and the one recorded in latest_receipt_info an intentional behavior of StoreKit 1's internal transaction ID assignment? Specifically, we are wondering whether StoreKit 1 applies some form of internal offset when delivering the transaction ID to the client, while the App Store server records a different (adjacent) ID in the receipt. If so, is this documented anywhere? Note We are currently in the process of migrating to StoreKit 2, but this behavior was observed while investigating our existing StoreKit 1 implementation. Any clarification would help us better understand the correct transaction model during the migration.

I'm working on securing communication between an Authorization Plugin and an XPC daemon, and I’d appreciate some guidance on best practices and troubleshooting. The current design which, I’ve implemented a custom Authorization Plugin for step-up authentication, which is loaded by Authorization Services at the loginwindow (inside SecurityAgent). This plugin acts as an XPC client and connects to a custom XPC daemon. Setup Details 1. XPC Daemon Runs as root (LaunchDaemon) Not sandboxed (my understanding is that root daemons typically don’t run sandboxed—please correct me if this is wrong) Mach service: com.roboInc.AuthXpcDaemon Bundle identifier: com.roboInc.OfflineAuthXpcDaemon 2. Authorization Plugin Bundle identifier: com.roboInc.AuthPlugin Loaded by SecurityAgent during login 3. Code Signing Both plugin and daemon are signed using a development certificate What I’m Trying to Achieve I want to secure the XPC communication so that: The daemon only accepts connections from trusted clients The plugin only connects to the legitimate daemon Communication is protected against unauthorized access The Issue I'm facing I attempted to validate code signatures using: SecRequirementCreateWithString SecCodeCopyGuestWithAttributes SecCodeCheckValidity However, validation consistently fails with: -67050 (errSecCSReqFailed) Could you please help here What is the recommended way to securely authenticate an Authorization Plugin (running inside SecurityAgent) to a privileged XPC daemon? Since the plugin runs inside SecurityAgent, how can the daemon reliably distinguish my plugin from other plugins? What is the correct approach to building a SecRequirement in this scenario? Any guidance, examples, or pointers would be greatly appreciated. Thanks in advance!

I've read several topics on cancelling subscriptions in sandbox environment, but it seems to me that it could not be applied to TestFlight. I can cancel sandbox subscriptions through Settings > App Store > Sandbox account But since TestFlight does not use sandbox account I cannot cancel a sub from there. Also, TF purchase does not appear in the list of regular subscriptions (Settings > Profile > Media & Purchases). So my question is: is there any way to manually cancel auto-renewable subscription bought in TestFlight build of the app?

By analysis the log, seems the following 3 calls has been ended by system callkit (Not mainly trigger the end call): @apple Do you have similar report that the iOS CallKit End the call withtour user action? Device info: iPhone18,1（iPhone 16 Pro） iOS 26.2 RCAppMobile/25.4.30.995 CTRadioAccessTechnologyNR（5G NR）

A user of my app reported that when my app copies files from a QNAP NAS to a folder on their Mac, they get the error "Result too large". When copying the same files from the Desktop, it works. I asked them to reproduce the issue with the sample code below and they confirmed that it reproduces. They contacted QNAP for support who in turn contacted me saying that they are not sure they can do anything about it, and asking if Apple can help. Both the app user and QNAP are willing to help, but at this point I'm also unsure how to proceed. Can someone at Apple say anything about this? Is this something QNAP should solve, or is this a bug in macOS? P.S.: I've had users in the past who reported the same issue with other brands, mostly Synology. import Cocoa @main class AppDelegate: NSObject, NSApplicationDelegate { func applicationDidFinishLaunching(_ aNotification: Notification) { let openPanel = NSOpenPanel() openPanel.canChooseDirectories = true openPanel.runModal() let source = openPanel.urls[0] openPanel.canChooseFiles = false openPanel.runModal() let destination = openPanel.urls[0] do { try copyFile(from: source, to: destination.appendingPathComponent(source.lastPathComponent, isDirectory: false)) } catch { NSAlert(error: error).runModal() } NSApp.terminate(nil) } private func copyFile(from source: URL, to destination: URL) throws { if try source.resourceValues(forKeys: [.isDirectoryKey]).isDirectory == true { try FileManager.default.createDirectory(at: destination, withIntermediateDirectories: false) for source in try FileManager.default.contentsOfDirectory(at: source, includingPropertiesForKeys: nil) { try copyFile(from: source, to: destination.appendingPathComponent(source.lastPathComponent, isDirectory: false)) } } else { try copyRegularFile(from: source, to: destination) } } private func copyRegularFile(from source: URL, to destination: URL) throws { let state = copyfile_state_alloc() defer { copyfile_state_free(state) } var bsize = UInt32(16_777_216) if copyfile_state_set(state, UInt32(COPYFILE_STATE_BSIZE), &bsize) != 0 { throw NSError(domain: NSPOSIXErrorDomain, code: Int(errno)) } else if copyfile_state_set(state, UInt32(COPYFILE_STATE_STATUS_CB), unsafeBitCast(copyfileCallback, to: UnsafeRawPointer.self)) != 0 { throw NSError(domain: NSPOSIXErrorDomain, code: Int(errno)) } else if copyfile(source.path, destination.path, state, copyfile_flags_t(COPYFILE_DATA | COPYFILE_SECURITY | COPYFILE_NOFOLLOW | COPYFILE_EXCL | COPYFILE_XATTR)) != 0 { throw NSError(domain: NSPOSIXErrorDomain, code: Int(errno)) } } private let copyfileCallback: copyfile_callback_t = { what, stage, state, src, dst, ctx in if what == COPYFILE_COPY_DATA { if stage == COPYFILE_ERR { return COPYFILE_QUIT } } return COPYFILE_CONTINUE } }

We now know the IsEligibleForAgeFeatures API is NOT returning True in Brazil at least 2 days past compliance date, and we don't know if that's the right API, or how it behaves. Folks here: Is there anyone here from Brazil who has tested out this 26.4 API? Has anyone tested out the regulatory feature API? Does it return something like declaredAgeRangeRequired? I don't know how to test it in Brazil without sandbox/physically in Brazil. Much appreciated!!

Hello, I’m honestly trying to understand what’s going on with the Family Controls API review process. I submitted my entitlement request on March 5, and as of today (March 19), there has been zero response. I also opened a support ticket on March 16, and that hasn’t received any response either. What’s confusing is that updates to another app on the same developer account were approved within days so clearly the account is in good standing and active. At this point, it feels like there’s no visibility into what’s happening: Is the request under review? Is it waiting for additional information? Or is it just sitting in a queue indefinitely? I understand that Family Controls is a sensitive API, but a two-week silence with no status or communication makes it very difficult to plan or ship features. For those who’ve gone through this: How long did your approval actually take? Did you receive any communication during the process? Is there any reliable way to get visibility or speed this up? Right now, this is blocking a feature we’ve invested significant time building, and the lack of feedback is the most frustrating part. Would really appreciate any insights.

I have a custom hardware board that I want to communicate serially with from an iPad. Should I use the DriverKit route or the MFi route?

I have a custom hardware board that I want to communicate serially with from an iPad. Should I use the DriverKit route or the MFi route?

While I welcome the arrival of a userspace implementation of drivers, DriverKit as it stands has some notable flaws. My main concern is the ability of open-source projects like HoRNDIS being able to access paid developer accounts and the limited entitlement scope (plus the waiting period) for what is essentially a hobbyist free project. Even if the developer is a professional company, some legacy hardware will go unsupported because of a lack of support from the vendor. Providing a way for users who need access to older hardware would be needed. Three concrete requests: A class-level or wildcard VID/PID entitlement for open source projects with a verifiable public repository A free or reduced-cost entitlement path for non-commercial volunteer-maintained drivers Published approval criteria and timelines so projects can plan accordingly Depreciating kexts without providing an accessible successor for community projects isn't security, it is gatekeeping access to hardware that is critically needed. Is this use case on the roadmap at all? Developers deserve a clear answer.

I am attempting to configure appclips, but I am getting this error in App Store Connect. I created an app clips target in my project, I have checked the XCAsset files and it is included when archived and pushed to App Store Connect. In both my parent and my app clips target I've added the associated domains capabilities, with the following associated same domains for both targets: appclips:akin-server-side-staging.onrender.com appclips:akin-server-side.onrender.com applinks:akin-server-side-staging.onrender.com applinks:akin-server-side.onrender.com My server is configured to serve the following json at all permutations of the staging endpoints and prod endpoints for both well known and aasa without well known. Here is one of them: https://akin-server-side.onrender.com/.well-known/apple-app-site-association Here is the JSON it is returning: {"applinks":{"details":[{"appIDs":["8PJ28P9ZZ8.com.ElevatedUnderdogs.akin1"],"components":[{"\/":"\/appClips\/referral\/venueToUser\/*"}]}]},"appclips":{"apps":["8PJ28P9ZZ8.com.ElevatedUnderdogs.akin1.Clip"]}} And yet I'm still getting Invalid Entitlement: Unknown ID in the store.