Post

Replies

Boosts

Views

Activity

Reply to iOS 18.4 - HomeKit actions from AppIntent fail when triggered from Widget
I’ve finally resolved this issue after many hours of debugging — posting the full solution here in case it helps others. ✅ Problem Since iOS 18.4, calling HomeKit APIs (like toggling accessories) from an AppIntent triggered by a Widget fails with the following error: Error Domain=HMErrorDomain Code=80 "Missing entitlement for API." UserInfo={ NSLocalizedFailureReason=Handler does not support background access, NSLocalizedDescription=Missing entitlement for API. } This happens only when the intent runs inside the widget process, not when it runs in the main app (even in background). ✅ Solution Part 1: Force AppIntent to run in main app process To bypass the limitations of the widget process, I made my AppIntent run in the main app instead, using the ForegroundContinuableIntent protocol. You can do this by adding the following extension: @available(iOSApplicationExtension, unavailable) extension MyActionIntent: ForegroundContinuableIntent {} Then declare your AppIntent as usual: struct MyActionIntent: AppIntent { init() {} static var openAppWhenRun: Bool { return false // Keep this false to avoid full app UI presentation } func perform() async throws -> some IntentResult { // Call HomeKit APIs here return .result() } } With this, even when triggered from a widget, the intent runs in the app's process — which has proper entitlements and access to HomeKit. 🧨 BUT... another hidden problem was causing crashes After applying the above fix, the intent still didn't seem to work — or worse, the app was crashing silently when launched in background. After deeper investigation, I found the real cause: I had a SwiftUI .backgroundTask(.appRefresh("MyBGTaskID")) { ... } modifier declared on the WindowGroup. Apparently, when the app is launched in background by an AppIntent, this SwiftUI modifier behaves incorrectly — the background task is not properly registered, and causes a crash when triggered. But this crash is invisible if you test by launching the app manually — because in that case, everything works fine, and the .backgroundTask behaves normally. ✅ Solution Part 2: Register background task manually I fixed this issue by removing the SwiftUI .backgroundTask modifier and manually registering the background task the "classic" way, in the init() of the @main app struct: import BackgroundTasks @main struct MyApp: App { init() { BGTaskScheduler.shared.register(forTaskWithIdentifier: "MyBGTaskID", using: nil) { task in // Handle your task here } } var body: some Scene { WindowGroup { ContentView() } } } ✅ Summary iOS 18.4 introduced stricter sandboxing for AppIntents running inside Widgets. Use ForegroundContinuableIntent to force your AppIntent to run in the main app context (where HomeKit works). Beware of SwiftUI .backgroundTask modifiers — they may cause background crashes when the app is launched by an AppIntent. Use manual registration via BGTaskScheduler.shared.register(...) instead. Let me know if anyone else experienced the same issue, or if you found a better way to debug background crashes in SwiftUI contexts. Hope this helps! 🙌
Apr ’25
Reply to Widgets: Detect StandBy night mode iOS 17
OK! I have found solution by myself using the showsWidgetContainerBackground Environment Value. I don't detect directly the StandBy mode but I detect that the WidgetContainerBackground has been removed. In widgetRenderingMode fullColor that means its the StandBy mode. At least it's true currently in iOS 17.0 @Environment(\.showsWidgetContainerBackground) var showsWidgetContainerBackground @Environment(\.widgetRenderingMode) var widgetRenderingMode ... ZStack { // If ContainerBackground will be removed, show the light background if (!showsWidgetContainerBackground && widgetRenderingMode == .fullColor) { Color.white.opacity(0.1).cornerRadius(cornerRadius) } WidgetContentView() .containerBackground(for: .widget) { backgroundView(viewSize: panelSize) } }
Topic: App & System Services SubTopic: Core OS Tags:
Aug ’23
Reply to How in interactive widgets in ios 17 to prevent the opening of the application by clicking on the widget?
I have still exactly the same behavior on iOS 17 beta 4. It is absolutely unpredictable when the tap on an interactive item (button or toggle) will pass through and will open the app. I did put a full size interactive background button (with an intent) doing nothing to try to catch missed click. It improve behavior but some tap still open the app with no reason. It looks like a bug but I am afraid it will persist for a while... :(
Topic: App & System Services SubTopic: Core OS Tags:
Aug ’23
Reply to How to prevent ios17 interactive widgets to open the app after an interaction?
Hi! I have still exactly the same behavior on iOS 17 beta 4. It is absolutely unpredictable when the tap on an interactive item (button or toggle) will pass through and will open the app. I did put a background interactive button (with an intent) doing nothing to try to catch miss click. It improve behavior but some tap still open the app with no reason. It looks like a bug but I am afraid it will persist for a while... :(
Topic: App & System Services SubTopic: Core OS Tags:
Aug ’23
Reply to What does WIDGET_BACKGROUND_API_ADOPTION_PROMPT mean?
So same issue here. I missed a log message in the console: The widget background view is missing. Please ensure that you have called the `containerBackground(for: .widget) {…}` modifier in your widget view. Just add the new .containerBackground(for:) in your widget view and it will resolve the issue. https://developer.apple.com/videos/play/wwdc2023/10027?time=180
Jun ’23
Reply to iPhone 14 Pro (and 14 Pro Max) Native Screen Size
Thanks to geoffhackworth (https://twitter.com/geoffhackworth) it seems that Xcode-14 TestFlight builds are treated as Xcode 13 builds and are scaled to the 12/13 Pro layout. So the issue will only occurs for TestFlight build. Thank you geoffhackworth (https://twitter.com/geoffhackworth) More about this here: https://twitter.com/geoffhackworth/status/1573652281848905728
Topic: UI Frameworks SubTopic: UIKit Tags:
Sep ’22