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

Hi there, I’m having trouble with localization for App Intents used in a configurable widget when the intents are defined inside a Swift Package. The intents appear correctly in the widget configuration UI and function as expected, but the localized strings are not displayed. Instead, the widget shows the localization keys themselves. Setup Xcode: 26.1 iOS: 26 The App Intents are used for a configurable widget Intent is located in a Swift Package The Widget Extension depends on the package AppIntentsPackage setup: // In the package public struct MySharedIntentsPackage: AppIntentsPackage {} // In the widget extension import AppIntents import SharedAppIntents struct WidgetIntentsPackage: AppIntentsPackage { static var includedPackages: [any AppIntentsPackage.Type] { [MySharedIntentsPackage.self] } } What I’ve tried I tested several configurations separately to see which setup allows localization to work: Localizing inside the Swift Package Placed a Localizable.xcstrings file inside the Swift Package. Specified .module for the bundle parameter in LocalizedStringResource initializers. → The widget still displayed the localization keys. Localizing inside the Widget Extension Placed a Localizable.xcstrings file inside the Widget Extension target instead of the package. → The widget continued to show the localization keys. Allowing mixed localizations Added CFBundleAllowMixedLocalizations = YES to the Widget Extension’s Info.plist. → No change; the widget still showed the keys. Problem In the WWDC 2025 session “Get to Know App Intents”, it was announced that App Intents would officially support Swift Packages. However, despite following that guidance, here we have a situation where the localizations do not work and only the keys appear in a configurable widget’s configuration UI. When I move the same App Intent code directly into the Widget Extension target, localization works as expected, but not when the intent remains inside the Swift Package. Question Is localization for App Intents defined in Swift Packages officially supported for configurable widgets? If yes: Which bundle does App Intents use to resolve localized strings? Should the .xcstrings file be placed in the package or in the host extension’s bundle? Or is this a current limitation or known issue? Any clarification or workaround would be greatly appreciated. Thank you.

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

Hello everyone, I'm encountering a persistent issue with my newly created widget project, even though it’s a clean, minimal setup. Every time I try to run the widget on the simulator or a device, I get the following error message: [S:1] Error received: Connection invalidated. I get this error even in a new project (I just created a new one) when I add a widget extension to it. The app itself works fine—no errors—but when I try to install the widget extension, it always shows me this error. Initially, I thought the issue was caused by an incorrect URLSession, but even after creating a clean (default) widget extension, the issue persists. I don’t know what to think anymore. Has anyone encountered this before? It’s completely blocking my progress. Conditions - new project from iOS App template WidgetExtension from template with no changes Iphone 14 pro IOS - 18.3.2

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 am looking for a way to hide sensitive information on my Complication, basically whenever the user does not actively look at it. That includes Always-On state Locked State (e.g. Watch not on wrist) I could observe differences in behavior between Preview, Simulator and Real Device. In general it looks like the .privacySensitive() modifier does not do anything for my purpose (except if the user enables redaction in settings). For the always-on state I could use @Environment(\.isLuminanceReduced) to conditionally apply .redacted(reason: .placeholder). This works most of the time. @ViewBuilder func preservePrivacy(_ isLuminanceReduced: Bool) -> some View { if isLuminanceReduced { self .redacted(reason: .placeholder) } else { self } } However I still cannot hide the information when the Watch is locked completely (via PIN-Code). I still believe that .privacySensitive() should take care of it, but apparently it doesn't. So the question is: How can I hide sensitive information when the Watch is locked? This is my widget: Text("1234") .privacySensitive() .preservePrivacy(isLuminanceReduced) .widgetCurvesContent() .widgetLabel { Text("PIN") .widgetAccentable() .foregroundStyle(.secondary) } .containerBackground(.teal.gradient, for: .widget) (I included the whole story, because possibly my whole approach is wrong.)

When the home screen is in tinted mode in iOS 18, the widget gallery seems to display widgets with the background inset from the edge of the widget (i.e. negative padding). You can see this behavior in the Apple News widget too, where the full-bleed content outside of the inset is very light. This only happens in the sample gallery, not when the widgets are placed on the home screen. For my widgets, this outer edge contains important content and the clipping behavior makes the widgets look poorly designed when viewed in the gallery. Is there any way to turn this behavior off and just show the widget normally in the gallery with no weird inset — the way it will actually display when added to the home screen? If it matters, my widgets are currently configured with: .contentMarginsDisabled() .containerBackground(for: .widget) { // ... (background color) */ }

When I create new build for TestFlight, it could not install from Test Flight, and show any error/warning/tip, from device's console, I got this error: -[IXSDataPromise cancelForReason:client:error:]: <IXSPlaceholder(0xc1acd7480) Name:App Placeholder: XXXXXXX(com.YYYYYY) Creator:App Store UUID:8AB2A59C-C367-42E1-990A-ACAFD8F9F4B9 Location:[system-defined]> : canceled by client 17 for reason Error Domain=IXUserPresentableErrorDomain Code=1 "This app could not be installed at this time." UserInfo={NSUnderlyingError=0xc1b1751a0 {Error Domain=MIInstallerErrorDomain Code=99 "WatchKit 2.0 app has disallowed Info.plist key: ISIconPlatform" UserInfo={LegacyErrorString=WatchKitAppIllegalInfoPlistKey, FunctionName=-[MIExecutableBundle hasOnlyAllowedWatchKitAppInfoPlistKeysForWatchKitVersion:error:], SourceFileLine=2715, NSLocalizedDescription=WatchKit 2.0 app has disallowed Info.plist key: ISIconPlatform}}, NSLocalizedDescription=This app could not be installed at this time., NSLocalizedRecoverySuggestion=WatchKit 2.0 app has disallowed Info.plist key: ISIconPlatform, NSLocalizedFailureReason=Could not install at this time.} After I remove watch app in this app, It could install successful, but this watch app still needed. I count not find anything about [IconPlatform] in my code, and could not find it in the info.plist files in the .ipa file. I only do some tiny code change for my app, and it could install in yesterday, but could not install for today. So how to resolve this issue? I need submit my new build for a urgent company events.

Hello everyone, I am facing a critical and blocking issue regarding watchface sharing on iOS/watchOS 26 and would appreciate any immediate guidance or updates from the community or Apple. The Problem: We are unable to share watchfaces containing any complications from our app in TestFlight and App Store distribution environments. The operation fails with an error indicating the app and complications are unavailable. However, the exact same functionality works perfectly in all development builds (both Debug and Release schemes). This issue was not present on iOS/watchOS 18. We have testing, including: Successfully sharing the watchface in development environments. The failure occurs consistently across TestFlight and App Store builds. Exporting the watchface configuration from a TestFlight/AppStore build on iOS, transferring it to a paired watch, and finding it still shows as "Unavailable". We suspect this may be related to the dual-target architecture of Watch apps. Any guidance or updates would be greatly appreciated. Thank you for your time and support!

I've encountered a major issue with the iOS 18.1 RC and watchOS 11.1 RC. It appears that complications running on WidgetKit cannot be synced as .watchface to these new release candidates. The error message indicates that "the Watch Faces app and complication are not available," which is affecting all apps utilizing WidgetKit. This issue renders all WidgetKit-based complications unusable on watchOS 11.1 RC. It’s a serious problem for those of us who rely on these complications for our apps and for users expecting consistent functionality. APPLE, PLEASE FIX THIS ISSUE ASAP! This bug is a significant setback for developers and users alike, and any guidance or updates would be greatly appreciated.

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.

I'm updating some of the views for a Live Activity, now that CarPlay can display Live Activities in iOS 26. My Activity is updated only with local updates from the iPhone (no push notifications), displaying a user's blood glucose. The activity updates fine in both CarPlay and in the Apple Watch Smart Stack, but in CarPlay, the previous values are not cleared when the new values are displayed, resulting in superimposed text and making it essentially unreadable. This only happens when the iPhone screen is off. As soon as the phone screen is woken up, even if the phone is not unlocked, the old values disappear and the display looks fine. I can't find anything in the API about clearing a display, so I'm wondering if this is a bug (especially since it clears when waking the phone screen). I'm running iOS 26.0.1 on my test phone. Thanks for any thoughts!

Filed as FB20766506 I have a very simple use case for a rectangular widget on the iPhone lock screen: One Text element which should fill as much space as possible. However, it only ever does 2 per default and then eclipses the rest of the string. Three separate Text elements work fine, so does a fixedSize modifier hack (with that even four lines are possible!). Am I completely misunderstanding something or why is this not possible per default? Other apps' widgets like Health do it as well. My attempt (background added for emphasis) Health app widget var body: some View { VStack(alignment: .leading) { /// This should span three lines, but only spans 2 which eclipsed text. Text("This is a very long text which should span multiple lines.") // .fixedSize(horizontal: false, vertical: true) /// Using this fixes it as well, but that does not seem like a good default solution. /// Three separate `Text` elements work fine. // Text("This is a very long") // Text("text which should") // Text("span multiple lines.") } .frame(maxWidth: .infinity, maxHeight: .infinity, alignment: .leading) .background(Color.black) /// Added for emphasis of the widget frame }

Summary When a SwiftUI widget uses a Link containing an Image modified with .widgetAccentedRenderingMode (using any mode except .fullColor), tapping the image on the widget launches the app but does not pass the expected deep link URL to the SceneDelegate. Steps to Reproduce Create a SwiftUI Widget View with a Link: struct ImageView: View { var image: UIImage var body: some View { Link(URL(string: "myapp://image")!) { Image(uiImage: image) .resizable() .widgetAccentedRenderingMode(.accentedDesaturated) // or any mode other than .fullColor .scaledToFill() .clipped() } } } Add Custom URL Scheme in Info.plist: <dict> <key>CFBundleURLName</key> <string>com.company.myapp</string> <key>CFBundleURLSchemes</key> <array> <string>myapp</string> </array> </dict> Implement Deep Link Handling in SceneDelegate: func scene(_ scene: UIScene, willConnectTo session: UISceneSession, options connectionOptions: UIScene.ConnectionOptions) { if let url = connectionOptions.urlContexts.first?.url { handle(url) } } func scene(_ scene: UIScene, openURLContexts urlContexts: Set<UIOpenURLContext>) { if let url = urlContexts.first?.url { handle(url) } } private func handle(_ url: URL) { // Process URL here } Run the application on a device or simulator. Add the widget to the Home Screen. Tap the image inside the widget. Expected Result The application launches and receives the URL in SceneDelegate, as expected. Actual Result The application launches, but the URL is not passed to SceneDelegate. Both connectionOptions.urlContexts and openURLContexts are empty.

To reproduce this bug create a new Xcode Project for IOS choose UIKit. In the app delegate add the following lines. As you can see in the above image . Line 19 with the initialization of PHPickerViewController has no compilation failure. Now lets add import WidgetKit As soon as widgetKit is imported a compiler error is thrown which is PHPickerViewController is not in scope. This worked with Xcode 16.4 It was possible to have a swift file with both WidgetKit implementations and PhotosUI implementations. This behavior has changed in Xcode 26/26.0.1 . Does anybody know why this happens , could not find any clues within the different versions of documentations. P.S Found a work around which raises further questions Adding import SwiftUI fixes this problem , I am genuinely curious on how this is happening on a compiler level. LINKS To my previously published post :https://developer.apple.com/forums/thread/804059

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.

Hi everyone! My Apple Watch app has relied for years on the WKApplication.scheduleBackgroundRefresh(...) method to keep the app updated in the background. The system would reliably trigger WKApplicationDelegate.handle(_:), where I would then schedule the next refresh task (usually 15 minutes later). As stated in the documentation, as long as there is a complication on the watch face, these background tasks should run at a relatively stable frequency. However, this approach seems to have stopped working on watchOS 26. I no longer receive any WKApplicationRefreshBackgroundTask at all. Has anyone else experienced this issue?

My implementation of LockedCameraCapture does not launch my app when tapped from locked screen. But when the same widget is in the Control Center, it launches the app successfully. Standard Xcode target template: Lock_Screen_Capture.swift @main struct Lock_Screen_Capture: LockedCameraCaptureExtension { var body: some LockedCameraCaptureExtensionScene { LockedCameraCaptureUIScene { session in Lock_Screen_CaptureViewFinder(session: session) } } } Lock_Screen_CaptureViewFinder.swift: import SwiftUI import UIKit import UniformTypeIdentifiers import LockedCameraCapture struct Lock_Screen_CaptureViewFinder: UIViewControllerRepresentable { let session: LockedCameraCaptureSession var sourceType: UIImagePickerController.SourceType = .camera init(session: LockedCameraCaptureSession) { self.session = session } func makeUIViewController(context: Self.Context) -> UIImagePickerController { let imagePicker = UIImagePickerController() imagePicker.sourceType = sourceType imagePicker.mediaTypes = [UTType.image.identifier, UTType.movie.identifier] imagePicker.cameraDevice = .rear return imagePicker } func updateUIViewController(_ uiViewController: UIImagePickerController, context: Self.Context) { } } Then I have my widget: struct CameraWidgetControl: ControlWidget { var body: some ControlWidgetConfiguration { StaticControlConfiguration( kind: "com.myCompany.myAppName.lock-screen") { ControlWidgetButton(action: MyAppCaptureIntent()) { Label("Capture", systemImage: "camera.shutter.button.fill") } } } } My AppIntent: struct MyAppContext: Codable {} struct MyAppCaptureIntent: CameraCaptureIntent { typealias AppContext = MyAppContext static let title: LocalizedStringResource = "MyAppCaptureIntent" static let description = IntentDescription("Capture photos and videos with MyApp.") @MainActor func perform() async throws -> some IntentResult { .result() } } The Issue LockedCameraCapture Widget does not launch my app when tapped from locked screen. You get the Face ID prompt and takes you to just Home Screen. But when the same widget is in the Control Center, it launches the app successfully. Error Message When tapped on Lock Screen, I get the following error code: LaunchServices: store ‹private > or url ‹private > was nil: Error Domain=NSOSStatusErrorDomain Code=-54 "process may not map database" UserInfo=&NSDebugDescription=process may not map database, _LSLine=72, _LSFunction=_LSServer_GetServerStoreForConnectionWithCompletionHandler} Attempt to map database failed: permission was denied. This attempt will not be retried. Failed to initialize client context with error Error Domain=NSOSStatusErrorDomain Code=-54 "process may not map database" UserInfo=&NSDebugDescription=process may not map database, _LSLine=72, _LSFunction=_LSServer_GetServerStoreForConnectionWithCompletionHandler} Things I tried Widget image displays correctly App ID and the Provisioning Profile seem to be fine since they work fine when the same code injected in to AVCam sample app and when used the same App ID's. AppIntent file contains the target memberships of the Lock Screen capture and Widget Apple compiles without errors or warnings.

If you use UISceneDelegate's scene(_ scene: UIScene, openURLContexts URLContexts: Set<UIOpenURLContext>) to handle deep links (such as tapping a widget) you might run into an issue where this callback is called twice in the majority of cases. If you push a view controller in response to this, you might end up with two pushed view controllers, if you do not mitigate this. This is exclusively an issue in iOS 26.0 and works as expected on iOS 18. func scene(_ scene: UIScene, openURLContexts URLContexts: Set<UIOpenURLContext>) { /// Add any widget to the home screen that uses the widgetURL modifier and tap them. Most of the time, openURLContexts() will get called twice. /// If you run this project on iOS 18, it's *always* called once as expected. print("openURLContexts \(URLContexts)") } Filed as FB20301454

Create a static widget kit based widget for watchKit. Use swiftUI and an image. IE on 42mm you can import a 141x141 image at 2x. Import a 141x141 image in the widget and load it in swiftUI. In watchOS 11.x simulator the image will allow up to the size for X Large circles, and on os26, it will not load and complain the image is too large and report the area for the smaller circle, IE 89x89 @ 2x for 41mm Also submitted a "feedback" ticket FB20506200 This is a big issue b/c the size difference for X large circles v the smaller circles is really large. To get existing images to load I am having to resize them down 75-80% on OS26 in the X Large complication.