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:

I've been implemented App Shortcuts into my apps which are localized for a variety of languages. The WWDC23 "Spotlight your app with App Shortcuts" has been extremely helpful in resolving my localized trigger phrases issue, but before I continue filling out all of the trigger phrases for my application I am concerned about a limitation that was mention in the video and need some additional information about it. The limitations noted in the video at minute mark 21:26 states that: Maximum 10 App Shortcuts (OK) Maximum 1000 trigger phrases... If I have 1 app and 10 shortcuts, and each shortcut only uses (.applicationName), this means I get to have 100 trigger phrases for each shortcut (for the sake of the discussion). What I'm unsure about is when I begin providing localization do the localized triggered phrases count toward the trigger phrase limit? Essentially, for every language I support do I have to drop 1/2 of all of my trigger phrases to stay under the limit? At the moment, my app is supporting 40 languages and I would like to know how localization affects the trigger phrase limit. Thank you!

I've created a Snippet for my iOS app which I want to be able to run from the LockScreen via a Shortcuts widget. All works fine except when I run the shortcut and the App Snippet appears, it doesn't always render the SwiftUI view in the same way. Sometimes the width boundaries are respected and sometimes not. I've tested this on iOS 26.1 and iOS 26.2 beta 3 I think this is a bug but it would be great if anyone could see what I might be doing wrong if it's not. Incase it is a bug I've filed a feedback (FB21076429) and I've created a stripped down sample project showing the issue and added screenshots showing the issue. Basic code to reproduce issue: // Intent.swift // SnippetBug import AppIntents import Foundation import SwiftUI struct SnippetEntryIntent: AppIntent { static let title: LocalizedStringResource = "Open Snippet" static let description = IntentDescription("Shows a snippet.") // Don’t open the app – stay in the snippet surface. static let openAppWhenRun: Bool = false func perform() async throws -> some ShowsSnippetIntent { .result(snippetIntent: TestSnippetIntent()) } } struct TestSnippetIntent: SnippetIntent { static let title: LocalizedStringResource = "Snippet Intent" static let description = IntentDescription("Action from snippet.") @MainActor func perform() async throws -> some IntentResult & ShowsSnippetView { .result(view: SnippetView(model: SnippetModel.shared)) } } @MainActor final class SnippetModel { static let shared = SnippetModel() private init() { } } struct SnippetView: View { let model: SnippetModel var body: some View { HStack { Text("Test Snippet with information") Spacer() Image(systemName: "heart") }.font(.headline) } } struct Shortcuts: AppShortcutsProvider { static var appShortcuts: [AppShortcut] { AppShortcut( intent: SnippetEntryIntent(), phrases: [ "Snippet for \(.applicationName)", "Test Snippet \(.applicationName)" ], shortTitle: "Snippet", systemImageName: "barcode" ) } } You also need these lines in your main App entry point: import AppIntents @main struct SnippetBugApp: App { init() { let model = SnippetModel.shared AppDependencyManager.shared.add(dependency: model) } var body: some Scene { WindowGroup { ContentView() } } } This is correct This is incorrect

(I truly appreciate all the responses you all have written for me :bow: ) I was under the assumption that for Live Activity, in order for you to be able to update the Activity, you need an update token. And for the OS to issue you the update token, user must hit the "Allow" from the lock screen. However based on these screenshots it seems that you don't need to hit "Allow" to be able to update the Live Activity. Live Activity was updated — even without the user hitting "Allow" So now I'm wondering if: Is hitting Allow required for the update token to get issued? Or that assumption is incorrect? In our tests (when connected to Proxyman, the OS emits the update token after user hits "Allow" / "Always Allow") If you don't hit allow, are there alternate ways to update the Live Activity without having the update token? I'm guessing you could set a short stale time and then when the OS launches the app in the background you query the server and then update the Live Activity. Is that a worthy approach? I also noticed that the "The Philly Inquirer" App has 'Background App Refresh" enabled, but this happened in 2 minutes. In our architecture assessments, after reviewing Apple's docs on 'Background Processing", we didn't think of it as a viable option, because it can't guarantee if the OS is given time in the next 2 minutes or 10 hours later when the phone is getting charged again. Are any of these workarounds viable or are there alternate approaches? Our requirement is: be able to use Live Activity between 2-72hrs after app install. (I mention this because perhaps Apple may impost some restrictions for new installs) be able to update an active Live Activity within 1-2 minutes after it has began.

I am encountering an issue where the Lock Screen Quick Action fails to visibly open my app. My app is a camera application that utilizes a CameraCaptureIntent to launch a standalone, lightweight camera view (accessible while the device is locked), distinct from the main application. Steps to Reproduce: Open the lightweight camera view using the Lock Screen Quick Action. From this view, launch the Main App. Lock the iPhone (put it to sleep). Attempt to launch the lightweight camera view via the Quick Action again. A slight animation occurs, but the camera view does not appear on screen. After multiple tests, it seems the view is actually launching but remains in an "invisible state." I suspect that the system hides the lightweight camera view when transitioning to the Main App, but fails to reset this hidden state when the Quick Action is triggered subsequently. I would appreciate any guidance on a potential workaround or confirmation if this is a known issue awaiting a system update.

I have a Live Activity on iOS. Love it. However, that Live Activity via remote hosting (I'm not building for other targets) shows the Live Activity on watchOS, macOS and CarPlay. disfavoredLocations are for widgets, but I don't appear to have a method to limit or provide exclusive locations the live activity should appear.

Good afternoon all, I have a question about Live Activities, specifically ProgressView. Why are they so hard to customize? You can't even really, consistently make the bar a specific height in points. You can't provide any progress view style to make it richer and more dynamic. We want to build a progress bar that's built up of 3 components: a track with its value constant on 1.0 (the full progress) with a specific color, another track that's the actual progress from ProgressView(timerInterval:countsDown:), and some way to create a visual gap in between. The progress bar should also be bigger than the standard size from iOS, but that's also not possible. The corners become really ugly when you use the scaleEffect modifier. Please, if anyone has any ideas about customizing the ProgressView without me having to send push notifications to manually make sure the bar updates, comment down below.

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?

I have been experiencing many issues trying to integrate the Apple AlarmKit in my app. I essentially keeping getting authorization errors. I was wondering if anyone else was experiencing issues like this and if anyone had guidance or a fix for what I am experiencing. I was under the impression that any devices IOS26+ could use the AlarmKit but maybe I am mistaken. Getting (com.apple.AlarmKit.Alarm error 1.) every time I try and enable alarms.

https://developer.apple.com/documentation/widgetkit/keeping-a-widget-up-to-date lists a number of exception including "The widget’s containing app has an active audio or navigation session." https://developer.apple.com/videos/play/wwdc2021/10048/ mentions: "However, there are a few situational exceptions that will make these reloads occur both immediately and budget-free. These are when your container app is foreground to the user or when your app is participating in a user session, like Navigation or Now Playing audio." Does an active workout session in a watchOS app count as "your app is participating in a user session", so calls to WidgetCenter.shared.reloadTimelines(ofKind:) are budget-free?

After updating Xcode and SDK to 26.4, I'm now getting an concurrency error when trying to update or end live activities with the following code that built successfully before: // Get list of active activities let allActivities = Activity<ArbeitszeitWidgetAttributes>.activities // Cancel all active activities Task { for activity in allActivities { await activity.end(nil, dismissalPolicy: .immediate) } } Sending 'activity' risks causing data races. Sending main actor-isolated 'activity' to @concurrent instance method 'update' risks causing data races between @concurrent and main actor-isolated uses I'm currently using nonisolated(unsafe) let activity = activity await activity.end(nil, dismissalPolicy: .immediate) to get it to compile again. What's the best approach here?

Hello community, I am implementing a Live Activity for my existing App Store app. The Live Activity works perfectly on the iOS Simulator, but it completely fails to appear on the physical device's lock screen. When I call Activity.request, it succeeds and returns a valid Activity ID, but the physical device's console immediately outputs the following errors from liveactivitiesd: liveactivitiesd is not entitled to specify a scene target. Defaulting containingProcess target to liveactivitiesd No asset provider bundle ID provided I have spent days debugging this and have tried every known workaround. Here is the comprehensive list of what I have already verified and attempted: Environment: Xcode: 16.4 iOS Device: iPhone 13 mini, iOS 26.3.1 macOS: Sequoia 15.6 What I have verified/tried (to avoid duplicate suggestions): NSSupportsLiveActivities: It is set to YES in the main app's Info.plist. I also tried adding it to the Widget Extension's Info.plist just in case. App Icons: The main app has a valid AppIcon set in Assets.xcassets. The Primary App Icon Set Name in Build Settings is correctly set to AppIcon. Bundle IDs: They match perfectly (com.mycompany.app and com.mycompany.app.MyWidget). Version & Build Numbers: The main app and the Widget Extension have exactly the same Version and Build numbers. App Groups & Entitlements: Checked and perfectly synced between the main app and the extension. Dummy Widget: Since it's a Live-Activity-only extension, I added a standard static DummyWidget to the WidgetBundle to prevent the known iOS 17 bug where the system ignores extensions without home screen widgets. Memory/Sanitizers: Ensured Address Sanitizer and Zombie Objects are completely disabled in the Scheme to prevent the 30MB memory limit crash on the device. Nuclear Option: Completely deleted the Widget Extension target, wiped DerivedData, restarted the Mac and iPhone, and recreated the extension from scratch. Minimal UI Test: Replaced the widget's UI with a simple Text("Test") to rule out any SwiftUI rendering crashes. Device Settings: Verified that "Live Activities" is enabled under "Face ID & Passcode" settings on the physical iPhone. Despite all of this, the Simulator works flawlessy, while the device throws No asset provider bundle ID provided and shows nothing. Does anyone know what specific condition causes liveactivitiesd to fail to find the asset provider (the parent app) on a physical device for an existing app? Are there any undocumented provisioning profile quirks or obscure Build Settings I might be missing? Any insights would be deeply appreciated. Thank you!

Hi, I need your opinion about an issue we faced while trying to implement an iOS widget in our Flutter app. Here is what we did and the problems we encountered: We created a Widget Extension (SwiftUI + WidgetKit) inside the existing Flutter iOS project. The widget files were generated correctly (Widget.swift, WidgetBundle.swift, Info.plist, etc.). However, during the integration, we faced multiple issues: Build Cycle Error We repeatedly got: “Cycle inside Runner; building could produce unreliable results” This was related to embedding the widget extension into the Runner target. Embed Problems Sometimes Xcode did not automatically create the “Embed App Extensions” phase. When we added it manually → build cycle errors appeared. When we removed it → the widget was not embedded at all (no PlugIns folder in Runner.app). Duplicate / Conflicting Embed The extension appeared both in: “Embed Foundation Extensions” “Frameworks, Libraries, and Embedded Content” Removing one often broke the build or removed the other as well. Widget Not Appearing Even when build succeeded: Widget did not appear on device PlugIns/Widget.appex was missing from build output Flutter Linking Errors In another test project, we got: Undefined symbol: _FlutterMethodChannel Undefined symbol: _FlutterBasicMessageChannel etc. This happened because the widget extension tried to link Flutter dependencies, which should not happen. App Group Confusion We also tried adding App Group (group.com.xxx), but behavior didn’t change. Conclusion: We suspect the root issue is: The Flutter template we are using was not designed for WidgetKit integration Xcode embedding phases and Flutter build scripts conflict with extension targets Question: In your opinion: Is this a known limitation with Flutter-based iOS projects? Is there a clean way to integrate WidgetKit without breaking the Runner target? Or is it better to create a separate native iOS module for the widget? Any guidance would be really appreciated. Thanks!

Hi Apple Team, We are facing an issue with Live Activities where the UI intermittently fails to render and shows a loader or blank state. After extensive debugging, we’ve identified that the failure happens during the rendering phase inside the system process (WidgetKit / liveactivitiesd), but there are no actionable signals exposed to the app. Problem: Live Activity launches successfully After a few updates or under certain UI conditions, it: stops rendering shows a loader / blank UI sometimes disappears No crash logs are generated No MetricKit diagnostics available for the extension Console logs show: Invalid frame dimension (negative or non-finite) Archive was nil. LiveActivity will be empty Sometimes because of memory pressure too The extension process appears to terminate silently Challenge Currently, there is no way to detect from the app side that: the Live Activity has failed to render the extension process has crashed/terminated the UI is no longer being updated Questions Is there any callback, delegate, or lifecycle hook that notifies when: a Live Activity rendering fails the extension process crashes or is terminated by the system? Is there any recommended way to detect a “broken” Live Activity state (e.g., stuck loader / non-updating UI)? Are there any diagnostic APIs or logs we can rely on in production to identify such failures? Is this considered expected behavior under certain system constraints (e.g., memory/rendering limits), and if so, are there guidelines to proactively detect or mitigate it? Goal We want to: proactively detect Live Activity failure log it for monitoring optionally fallback or recover gracefully Additional context: We fixed all the issues and the live activity is pretty stable. But asking for methods to track & fix such cases.

Heyy, I'm building a music tracking app that logs a user's Apple Music plays to build a personal weekly chart. The core mechanic depends on accurately counting how many times a user plays each track. My current implementation uses MPMusicPlayerController.systemMusicPlayer with beginGeneratingPlaybackNotifications() and observes MPMusicPlayerControllerNowPlayingItemDidChange. This works well when the app is in the foreground or recently backgrounded, but notifications stop firing once iOS suspends the app. To get around this I've implemented: applicationDidBecomeActive - restarts the monitor and logs the currently playing track on every foreground Background fetch (performFetchWithCompletionHandler) - periodically wakes the app to log what's playing. This gives some coverage but misses plays that happen between background fetch intervals or when the user hasn't opened the app in a while. The result is an inaccurate play count which undermines the core feature. My questions: Is there a supported entitlement or capability that would allow an app to receive MPMusicPlayerController playback notifications while suspended? Is MusicKit or MediaPlayer the recommended framework for this use case, or is there a better API I'm not aware of? Are there any supported background modes that would keep playback notification delivery alive without requiring the app to be a full audio player? I've looked at MusicRecentlyPlayedRequest but it only returns the last 25 items with no play counts, so it can't tell me a track was played 10 times vs once. Any guidance on the right approach here would be really appreciated.

There seems to be a long running issue with WidgetKit where some users don't see the widget when trying to add to their Home Screen. (even after opening the app for the first time). I have been able to reproduce myself intermittently, and typically restarting the phone or re-installing the app fixes the problem. However, some of my users have encountered this and end up requesting refunds because they think the app is broken. Has anybody else experienced this issue? Would be great to get this bug resolved as it's frustrating for users.

Confusion Based on the fact that the subscription is requested on a Activity type, I assumed that the push-to-start tokens would be different. But the push-to-start token for WidgetExtensionAttributes and WidgetExtensionAttributesOther were identical. This is misleading. The code below prints identical tokens even though the name of the token and their underlying schema are different. Code Sample func getTokens() { Task { if let data = Activity<func getTokens() { Task { if let data = Activity<WidgetExtensionAttributes>.pushToStartToken { print("exists:", data.hexadecimalString) } else { print("requesting pushToStartToken") for await ptsToken in Activity<WidgetExtensionAttributes> .pushToStartTokenUpdates { let ptsTokenString = ptsToken.hexadecimalString print("new:", ptsTokenString) } } } Task { if let data = Activity<WidgetExtensionAttributesOther>.pushToStartToken { print("other exists:", data.hexadecimalString) } else { print("other requesting pushToStartToken") for await ptsToken in Activity<WidgetExtensionAttributesOther> .pushToStartTokenUpdates { let ptsTokenString = ptsToken.hexadecimalString print("other new:", ptsTokenString) } } } }>.pushToStartToken { print("exists:", data.hexadecimalString) } else { print("requesting pushToStartToken") for await ptsToken in Activity<WidgetExtensionAttributes> .pushToStartTokenUpdates { let ptsTokenString = ptsToken.hexadecimalString print("new:", ptsTokenString) } } } Task { if let data = Activity<WidgetExtensionAttributesOther>.pushToStartToken { print("other exists:", data.hexadecimalString) } else { print("other requesting pushToStartToken") for await ptsToken in Activity<WidgetExtensionAttributesOther> .pushToStartTokenUpdates { let ptsTokenString = ptsToken.hexadecimalString print("other new:", ptsTokenString) } } } } Activity Types struct WidgetExtensionAttributesOther: ActivityAttributes { public struct ContentState: Codable, Hashable { var age: Int } var addresses: [String] } struct WidgetExtensionAttributes: ActivityAttributes { public struct ContentState: Codable, Hashable { var emoji: String } var name: String } Docs After much investigation I noticed the wording of the docs kind of hint that the push-to-start token is per ActivityKit as it says: An asynchronous sequence you use to observe changes to the token for starting a Live Activity with an ActivityKit push notification. But docs and the API don't align well. Questions Is it correct that the push-to-start token is per app? If so then is there a reason that that API designers decided to still have to pass a specific type and not just make a request without passing a type? Should I maybe file a radar? Is it correct to say push-to-start is per app, while update tokens are per instance. i.e. if I have two soccer matches, then unless the push-to-start token was refreshed by the OS, then both would use the same push-to-start token, however each match would have a unique update token?

I am experiencing an issue with my watchOS app. My application updates a shared file, accessible by both the main app and the WidgetKit extension, during a WatchConnectivity background task. Following this update, I call reloadAllTimelines(). This functionality worked as expected on watchOS 10, even without Developer Mode enabled. However, after updating my device to watchOS 11.5, this API appears to be broken. My reasons for believing this API is broken are threefold: The functionality worked reliably on watchOS 10. On watchOS 11.5, enabling "WidgetKit Developer Mode" (found under Settings > Developer) resolves the issue, and my complications update correctly. When I enter watch face edit mode, the snapshot/preview displayed (which utilizes the same underlying logic as the timeline API) shows the correct data. This indicates that the data has been successfully received from the phone, and the widget is indeed reading the updated shared file. Despite this, the actual widget view during its resting phase never updates. It's worth noting that TimelineReloadPolicy functions as expected, but I cannot rely on this for my use case. My widget requires immediate updates upon receiving new data. Apple, please investigate this behavior.

New features in WatchOS 26 with configurable widgets make it more important than ever that apps adopt IntentConfiguration options where applicable. I develop an app with an Apple Watch complication/widget on many many user's Watch faces around the world. I've completed updating my code to support WidgetKit and remove ClockKit. However, I face huge issues adding support for users to configure their widget/complications. If I update a widget to go from StaticConfiguration to IntentConfiguration, even when keeping the "kind" string the same, the widget disappears from the Watch face. This is an unacceptable user experience meaning I can't proceed with the migration. The problem is users will expect me to offer configuration in the Watch face soon for their widget/complication. Currently this process is done in a sub-optimal way in the app itself. A similar issue exists on iOS where the widget will just "freeze" indefinitely is migrated. This issue still occurs on the iOS 26 and WatchOS 26 betas. So how to move this forward. This has been discussed previously here: https://developer.apple.com/forums/thread/661247 I've mentioned it at WidgetKit labs I've filed feedback last year: FB13880020 I've filed feedback this year: FB18180368 It seems really important this gets fixed for developers to adopt these new features, is there any other migration route I'm missing or a workaround that would mitigate this seemingly big problem.

We need a live activity to countdown our time in formats like 2h 30m -> 2h 29m -> 2h 28m etc 58m -> 57m I see this kind in pictures in official documentation. to make a functional timer is: Text(context.state.startTime, style: .timer) But it's very limited when it comes to formatting. This timer .relative includes seconds which we don't want Text(futureDate, style: .relative) Also format we need is h instead of hour, m instead of min