Hello, Users are reporting that widgets in my iOS app running on Mac OS are starting to crash after updating to MacOS 26.1. Everything works fine on iOS 26.1 and MacOS 15.6. The same bugs I found in iOS 26 beta 4, but then Apple fixed them in iOS 26RC and now they're back in macOS. Any suggestions? Crash report: Process: WidgetWebWidgetExt [23580] Path: /Volumes/VOLUME/*/WidgetWeb.app/PlugIns/WidgetWebWidgetExt.appex/WidgetWebWidgetExt Identifier: app.vitalek.widgetapp.web.WidgetWebExt Version: 7.5 (5796) AppVariant: 1:MacFamily20,1:18 Code Type: ARM-64 (Native) Role: unknown Parent Process: launchd [1] Coalition: app.vitalek.widgetapp.web.WidgetWebExt [28539] User ID: 501 Date/Time: 2025-11-04 11:47:19.0746 -0500 Launch Time: 2025-11-04 11:47:18.8035 -0500 Hardware Model: Mac14,6 OS Version: macOS 26.1 (25B78) Release Type: User Crash Reporter Key: 39D39455-7F69-746C-2A1D-7A6086F25541 Incident Identifier: 7AC31574-73A4-4320-B17A-C2819252EEDA Sleep/Wake UUID: 1535756C-44D8-497F-A288-07E53CD9B9E4 Time Awake Since Boot: 18000 seconds Time Since Wake: 7417 seconds System Integrity Protection: enabled Triggered by Thread: 0, Dispatch Queue: com.apple.main-thread Exception Type: EXC_CRASH (SIGABRT) Exception Codes: 0x0000000000000000, 0x0000000000000000 Termination Reason: Namespace SIGNAL, Code 6, Abort trap: 6 Terminating Process: WidgetWebWidgetExt [23580] Application Specific Information: abort() called Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 libsystem_kernel.dylib 0x1926e75b0 __pthread_kill + 8 1 libsystem_pthread.dylib 0x192721888 pthread_kill + 296 2 libsystem_c.dylib 0x192626850 abort + 124 3 libc++abi.dylib 0x1926d5858 __abort_message + 132 4 libc++abi.dylib 0x1926c44d4 demangling_terminate_handler() + 304 5 libobjc.A.dylib 0x1922f0414 _objc_terminate() + 156 6 libc++abi.dylib 0x1926d4c2c std::__terminate(void (*)()) + 16 7 libc++abi.dylib 0x1926d8394 __cxxabiv1::failed_throw(__cxxabiv1::__cxa_exception*) + 88 8 libc++abi.dylib 0x1926d833c __cxa_throw + 92 9 libobjc.A.dylib 0x1922e6580 objc_exception_throw + 448 10 Foundation 0x19495122c -[NSAssertionHandler handleFailureInMethod:object:file:lineNumber:description:] + 288 11 UIKitMacHelper 0x1b0240c80 -[UINSApplicationDelegate init] + 1348 12 UIKitMacHelper 0x1b02406d8 __41+[UINSApplicationDelegate sharedDelegate]_block_invoke + 48 13 libdispatch.dylib 0x19257eac4 _dispatch_client_callout + 16 14 libdispatch.dylib 0x192567a60 _dispatch_once_callout + 32 15 UIKitMacHelper 0x1b02405dc +[UINSApplicationDelegate sharedDelegate] + 324 16 UIKitCore 0x1ca488518 -[UIScene setTitle:] + 188 17 UIKitCore 0x1ca487e90 -[UIScene initWithSession:connectionOptions:] + 1084 18 UIKitCore 0x1cb2a6a54 -[UIWindowScene initWithSession:connectionOptions:] + 92 19 UIKitCore 0x1ca66b44c -[_UIScreenBasedWindowScene initWithScreen:session:lookupKey:] + 292 20 UIKitCore 0x1ca66aff4 +[_UIScreenBasedWindowScene _unassociatedWindowSceneForScreen:create:] + 408 21 UIKitCore 0x1cb09171c -[UIWindow _uiWindowSceneFromFBSScene:] + 704 22 UIKitCore 0x1cb0918cc -[UIWindow _initWithFrame:debugName:scene:attached:] + 92 23 UIKitCore 0x1cb091e68 -[UIWindow _initWithOrientation:] + 56 24 UIKitCore 0x1cb091ebc -[UIWindow init] + 72 25 WidgetWebWidgetExt 0x1027eb250 0x102718000 + 864848 26 WidgetWebWidgetExt 0x1027ea418 0x102718000 + 861208 27 WidgetWebWidgetExt 0x1027f5bc8 0x102718000 + 908232 28 WidgetWebWidgetExt 0x1027f4bfc 0x102718000 + 904188 29 WidgetWebWidgetExt 0x1027cf9f4 0x102718000 + 752116 30 WidgetWebWidgetExt 0x102807c20 0x102718000 + 982048 31 libdispatch.dylib 0x19257eac4 _dispatch_client_callout + 16 32 libdispatch.dylib 0x1925696e4 _dispatch_continuation_pop + 596 33 libdispatch.dylib 0x19257c800 _dispatch_source_latch_and_call + 396 34 libdispatch.dylib 0x19257b4d4 _dispatch_source_invoke + 844 35 libdispatch.dylib 0x19259c008 _dispatch_main_queue_drain.cold.5 + 592 36 libdispatch.dylib 0x192573f48 _dispatch_main_queue_drain + 180 37 libdispatch.dylib 0x192573e84 _dispatch_main_queue_callback_4CF + 44 38 CoreFoundation 0x1927ea980 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 16 39 CoreFoundation 0x1927bf7dc __CFRunLoopRun + 1944 40 CoreFoundation 0x19287935c _CFRunLoopRunSpecificWithOptions + 532 41 Foundation 0x194a06890 -[NSRunLoop(NSRunLoop) runMode:beforeDate:] + 212 42 Foundation 0x194005a50 -[NSRunLoop(NSRunLoop) run] + 64 43 libxpc.dylib 0x19240ce14 _xpc_objc_main + 668 44 libxpc.dylib 0x19241ecf8 _xpc_main + 40 45 libxpc.dylib 0x19241ecd0 xpc_bs_main + 16 46 BoardServices 0x1ac51179c +[BSServicesConfiguration activateXPCService] + 72 47 ExtensionFoundation 0x237a92710 _EXRunningExtension.resume() + 1592 48 ExtensionFoundation 0x237a911a8 _EXRunningExtension.start(withArguments:count:) + 124 49 ExtensionFoundation 0x237a88f24 EXExtensionMain(_:_:) + 668 50 Foundation 0x1940065ec NSExtensionMain + 200 51 dyld 0x192359d54 start + 7184

When we use AppIntents to configure WidgetKit complications, the description we provide in IntentRecommendation is ignored after applying a .watchface file that includes those intent configurations. In the Watch app, under Complications, the labels shown next to each slot do not match the actual complications on the face—they appear to be the first strings returned by recommendations() rather than the selected intent configuration. Steps to Reproduce Create an AppIntent used by a WidgetKit complication (e.g., .accessoryRectangular). Provide multiple intent recommendations with distinct descriptions: struct SampleIntent: AppIntent { static var title: LocalizedStringResource = "Sample" static var description = IntentDescription("Sample data") @Parameter(title: "Mode") var mode: String static func recommendations() -> [IntentRecommendation<Self>] { [ .init(intent: .init(mode: "A"), description: "Complication A"), .init(intent: .init(mode: "B"), description: "Complication B"), .init(intent: .init(mode: "C"), description: "Complication C") ] } func perform() async throws -> some IntentResult { .result() } } Add two of these complications to a Modular Duo face (or any face that supports multiple slots), each with different intent configurations (e.g., A in one slot, B in another). Export/share the face to a .watchface file and apply it on another device. Open the Watch app → the chosen face → Complications. Expected Each slot’s label in Complications reflects the specific intent configuration on the face (e.g., “Complication A”, “Complication B”), matching what the complication actually renders. Actual The labels under Complications do not match the visible complications. Instead, the strings shown look like the first N items from recommendations(), regardless of which configurations are used in each slot. Notes The complications themselves render correctly on-watch; the issue is the names/labels displayed in the Watch app UI after applying a .watchface. Filed Feedback: FB20915258

For our Live Activity Tokens, when we fire a payload, often apns is returning a response of 410 unregistered. Docs are saying: The device token is inactive for the specified topic. There is no need to send further pushes to the same device token, unless your application retrieves the same device token, refer to Registering your app with APNs Questions: Why does this happen? Does it only happen because the user changed their permission? Or there are other reasons? And when it does happen, what should we do about it? A. Should we keep the token on the server? Because perhaps the user will change their permission and the token becomes valid? That could leave us with lots of invalid tokens and us firing at them unnecessarily. Docs do say: Don’t retry notification responses with the error code BadDeviceToken, DeviceTokenNotForTopic, Forbidden, ExpiredToken, Unregistered, or PayloadTooLarge. B. Or should we remove the token from the server? That then requires app to re-register the token. But the problem with that is: When I went into App's settings from OS settings and toggled push notifications to on, the app was not launched into the background nor killed i.e. it requires explicit app launch by the user to re-register itself which isn't ideal... It means a user may turn on notifications from the OS settings and then assume that their push notifications should be back in business, but that won't happen if you toggle things from OS settings.

I submitted a Feedback FB19925261 with a demo project two months ago, but it’s still marked as Open. The issue still persists in Xcode 26.1 + watchOS 26.1. Could someone kindly take a look at the status of this Feedback?

iPhone 16.0 16.0.2 系统上运行小组件出现问题， 其他系统没有问题 SendProcessControlEvent:toPid: encountered an error: Error Domain=com.apple.dt.deviceprocesscontrolservice Code=8 "Failed to show Widget 'com.jiduauto.iphone.jdcomiphoneWidget' error: Error Domain=FBSOpenApplicationServiceErrorDomain Code=5 "The request to open "com.apple.springboard" failed." UserInfo={NSLocalizedDescription=The request to open "com.apple.springboard" failed., NSLocalizedFailureReason=Unexpected error type., NSUnderlyingError=0x600002bbd7a0 {Error Domain=BSServiceConnectionErrorDomain Code=3 "XPC error received on message reply handler" UserInfo={BSErrorCodeDescription=OperationFailed, NSLocalizedFailureReason=XPC error received on message reply handler}}, BSErrorCodeDescription=InvalidResponse}." UserInfo={NSLocalizedDescription=Failed to show Widget 'com.jiduauto.iphone.jdcomiphoneWidget' error: Error Domain=FBSOpenApplicationServiceErrorDomain Code=5 "The request to open "com.apple.springboard" failed." UserInfo={NSLocalizedDescription=The request to open "com.apple.springboard" failed., NSLocalizedFailureReason=Unexpected error type., NSUnderlyingError=0x600002bbd7a0 {Error Domain=BSServiceConnectionErrorDomain Code=3 "XPC error received on message reply handler" UserInfo={BSErrorCodeDescription=OperationFailed, NSLocalizedFailureReason=XPC error received on message reply handler}}, BSErrorCodeDescription=InvalidResponse}., NSUnderlyingError=0x600002bbd5f0 {Error Domain=FBSOpenApplicationServiceErrorDomain Code=5 "The request to open "com.apple.springboard" failed." UserInfo={NSLocalizedDescription=The request to open "com.apple.springboard" failed., NSLocalizedFailureReason=Unexpected error type., NSUnderlyingError=0x600002bbd7a0 {Error Domain=BSServiceConnectionErrorDomain Code=3 "XPC error received on message reply handler" UserInfo={BSErrorCodeDescription=OperationFailed, NSLocalizedFailureReason=XPC error received on message reply handler}}, BSErrorCodeDescription=InvalidResponse}}} Domain: DTXMessage Code: 1 User Info: { DVTErrorCreationDateKey = "2024-02-19 08:02:14 +0000"; } System Information macOS Version 13.5.2 (Build 22G91) Xcode 15.0 (22265) (Build 15A240d) Timestamp: 2024-02-19T16:02:14+08:00

I have developed a LiveActivity on my product that supports DynamicIsland. Recently, two users encountered this situation while updating the app: LiveActivity was created with a status of. active, but after 100ms, it immediately started displaying as. dimiss. This process was repeated many times until the user restarted their iPhone and the display became normal A user's LiveActivity was successfully created with a status of. active, and the data was updated using the. update method normally; But this user's interface keeps showing a gray component empty state I am unable to obtain useful information regarding the bug encountered in processing. I would like to know how to obtain the reason why the user's LiveActivity has been modified to. dimiss by the iOS system in the face of these situations; How can I obtain useful information to determine the cause of the error when the user interface cannot display data without debugging. Thank you~

I'm struggling to understand what the impact of this flag is. Docs only say: For devices running iOS 18 and iPadOS 18 or later, you can add input-push-token: 1 to your payload to start a Live Activity and receive a new push token. After you receive a new push token, you can use it to send updates to a Live Activity. But things were working fine for iOS 17. Right? Does it somehow make the OS emit update tokens faster/more successfully? Should I include in all start, update, end events?

Hello, We have observed a change in the presentation behavior of the AlarmKit Live Activity banner when our application is in the foreground, following the update from iOS 26.0 to iOS 26.1. We would like to clarify which behavior is intended. In iOS 26.0: When our application was in the foreground, the AlarmKit Live Activity banner did not present. In iOS 26.1: The AlarmKit Live Activity banner now presents even when our application is in the foreground. Could you please advise on what the correct or desired behavior is for this scenario? Thank you for your clarification.

Hello, I would like to inquire about a specific behavior I've observed with Live Activities to determine if it is a bug. When our application is closed but the device is in use, an alarm triggers a Live Activity to appear at the top of the screen. However, it seems that tapping the background area of this Live Activity does not trigger the .widgetURL and .onOpenURL Could you please confirm if this is the intended behavior? or should I config another setting for desired action like trigger .onOpenURL? Thank you for your time and assistance. Best regards,

I don't see any where how to make my payment

I want to add my app to Controls, just a button to open the app. The end goal is to put it on a lock screen. However, I can get it to work on the iPhone simulator, but I am unable to get it on my actual device. No warnings or failed build or signing issues. I feel like I have changed and tinkered everything. I feel like my code is correct, so maybe it's an issue of the signing? I am lost. Running the control center stuff through Widgetkit.

Im having trouble enabling Live Activities in a new app. The option is not available in Xcode or in the developer portal. Is there something I have to do to activate this option?

Just wanted to clarify some expected behaviors here. It seems that there are two distinct behaviors for Live Activity flows for freshly installed apps. When you start a Live Activity for the first time and the user hasn't yet clicked on Allow/Don't Allow in the activity interface, there are two different sequences: Starting a Live Activity locally Request a Live Activity locally via Swift Live Activity starts .pushTokenUpdates is immediately triggered, even if the Allow/Don't Allow buttons appear under the Activity UI Starting a Live Activity via push-to-start Send a push-to-start notification to launch a Live Activity Live Activity starts .pushTokenUpdates is not triggered, and .pushToken returns nil. If a user clicks on Allow in the Activity UI, only then is .pushTokenUpdates triggered.

Q1. Can you place a sound on an end event? That doesn't seem to work for us Additionally: Q2. Is there any way that after you send the end event, still have the Live Activity remain on the Dynamic Island until the dismissal-date? Currently when an end event is sent, it's abruptly ended from the Dynamic Island without any sound. Users are confused until minutes/hours later they see their Lock Screen.

Hi there, I'm adding a new widget using the new WidgetConfigurationIntent which takes a number of parameters, including one which conforms to AppEntity. It is defined as an optional. When the user is configuring the widget, after one of the suggested entities is chosen, there is no way to return to a state where this value is nil. Is this possible? I'd like the user to be able to select "None" for this parameter. For now, I'm using a bool to determine whether the AppEntity parameter is used. Thanks!

I have developed a Widget Extension with editable dynamic options. `struct ModelQuery: EntityStringQuery { public var allModels:[ModelEntity] { // from App Groups UserDefaults let models = SharedDataManager.getModelList() // 检查原始数据是否为空，避免转换后的数据异常 guard !models.isEmpty else { return [] } let entites = models.map{ModelEntity(from: $0)} return entites } func entities(for identifiers: [ModelEntity.ID]) async throws -> [ModelEntity] { let models = allModels if models.isEmpty { return [] } // 尝试匹配ID let matchedEntities = identifiers.compactMap { id in models.first { $0.id == id } } // 如果没有匹配到任何实体，返回默认的第一个站点 if matchedEntities.isEmpty && !models.isEmpty { return [models[0]] } return matchedEntities } func entities(matching string: String) async throws -> [ModelEntity] { let stations = allModels if stations.isEmpty { return [] } if string.isEmpty { return stations } let lowercasedString = string.lowercased() let filteredStations = stations.filter { station in station.name.lowercased().contains(lowercasedString) } if filteredStations.isEmpty { return [] } return filteredStations } func suggestedEntities() async throws -> [ModelEntity] { return allModels } }` Below is how it looks when functioning properly However, when I tested it on iOS 26, occasional "Failed to Load" errors or unknown errors occurred. The same issues did not appear on iOS 17 or iOS 18.

import AppIntents struct AddTodoIntent: AppIntent { static var title: LocalizedStringResource = "Add Todo" static var openAppWhenRun: Bool = true func perform() async throws -> some IntentResult & ProvidesDialog { .result(dialog: "New todo added successfully.") } } struct ViewTodosIntent:AppIntent { static var title: LocalizedStringResource = "View Todos" func perform() async throws -> some IntentResult & ProvidesDialog { .result(dialog: "Here are your todos...") } } struct TodoAppShortcuts: AppShortcutsProvider { static var appShortcuts: [AppShortcut] { AppShortcut( intent: AddTodoIntent(), phrases: ["\(.applicationName) Add a new todo"], shortTitle: "New Todo", systemImageName: "plus.circle" ) AppShortcut( intent: ViewTodosIntent(), phrases: ["\(.applicationName) Show my todoso"], shortTitle: "Show todos", systemImageName: "plus.app" ) } } when we used, it wrong How did i can do it success？

When I set Alarm with fixed schedule(Alarm.Schedule.fixed(date)) LiveActivityIntent just work inconsistently it sometimes call perfrom but cannot call other's such as NotificationCenter.default.post it just work fine with relativeSchedule but not for fixed schedule i want to know why it happen tested code is under below struct StopIntent: LiveActivityIntent { static var supportedModes: IntentModes = [.foreground(.immediate)] func perform() throws -> some IntentResult { guard let id = UUID(uuidString: alarmID) else { NotificationCenter.default.post(name: .Alarm.stoped, object: alarmDataString) throw TestAlarmManager._Error.badAlarmID } Task { @MainActor in try TestAlarmManager.shared.stopAlarm(id) NotificationCenter.default.post(name: .Alarm.stoped, object: alarmDataString) } return .result() } static var title: LocalizedStringResource = "Stop" static var description = IntentDescription("Stop an alert") @Parameter(title: "alarmID") var alarmID: String @Parameter(title: "alarmDataString") var alarmDataString: String init(alarmID: UUID, alarmDataString: String) { self.alarmID = alarmID.uuidString self.alarmDataString = alarmDataString } init() { self.alarmID = "" self.alarmDataString = "" } }

My widget has a background color set, but after the system sets custom transparency, my widget displays a blank space. I would like to solve this problem by obtaining the system's custom transparency settings and then setting the background color transparency, or do you have a better way to solve this problem

We currently have the need to develop Smart Island. We need to identify whether the current mobile phone supports Smart Island. At present, the solution we can think of is to maintain a model list if the current phone is in the white list, it supports Smart Island. But we think this method is not good enough. Is there a better solution to support identification? In addition, will the later models support smart Island?