LiveActivity using colorScheme to adapt to dark mode in iOS 26 system does not work The system keeps returning. mark, unable to switch

I have a widget that uses a WidgetConfigurationIntent where a user can pick what to display in the widget. This configurable widget works fine in iOS 26, but if the app is built with the iOS 27 SDK / Xcode 27, it no longer will respond to any changes from the parameter, and the default is always shown. Is this behavior a bug, or have there been underlying changes in this area that need new accommodations? Thanks!

I create a Live Activity remotely via push-to-start, then use its per-activity token (Activity.pushTokenUpdates) so my server can send update/end pushes. To make sure I'm not missing tokens, I observe Activity.activityUpdates and prime from the Activity.activities snapshot at launch and on sceneWillEnterForeground, then subscribe each activity's pushTokenUpdates and POST the token to my server. This works reliably while the app is running or backgrounded/suspended — the system wakes it and I capture the token. The problem is the user force-quit case (swiped from the App Switcher, never reopened): Push-to-start still creates the Live Activity and it renders correctly on the Lock Screen. But pushTokenUpdates never fires, so my server never receives the per-activity token and can't update or end that activity. A backgrounded (not force-quit) app, as a control, captures the token every time. So it seems specific to user-termination rather than all "not running" states. I understand force-quit apps generally aren't granted background runtime — I'm trying to confirm whether that applies here and what the right pattern is. What's the recommended approach? Specifically: Is there any supported way to get the per-activity token to my server while the app stays force-quit — e.g. from the widget extension (does it have any access to Activity.pushToken, or only ActivityViewContext?) or a Notification Service Extension? 2. If not, is setting stale-date on the start push the intended way to let the card expire gracefully when it can never be ended via push? 3. Is there a better pattern for keeping a push-started Live Activity correct when the app is never relaunched?

Problem Description We are encountering a pushToken retrieval failure when creating Live Activities using the ActivityKit framework in our iOS application. Problem Symptoms Failure Rate: Approximately 40% of Live Activities created in production fail to obtain a pushToken Behavior: The Activity is created successfully, but activity.pushToken and the activity.pushTokenUpdates stream remain empty / return nothing Impact: Unable to update Live Activities via APNS Offline Issue Environment iOS Version: iOS 26.5 Device: Physical iPhone device Deployment Environment: Production environment, release build Code Sample Task { // Executed after Live Activity creation for await activity in Activity<T>.activityUpdates { ... if let activityTokenData = activity.pushToken { // Report token to APNS service reportTokenToAPNS(tokenString) } // Start async monitoring self.registerPushTokenUpdates(...) Log("actObserver: Live Activity registered successfully") } } // Async monitoring private func registerPushTokenUpdates<T: SAKActivityAttributes>(...) { Task { self.pushTokenObserveRecords.safe{ $0.append(activity.id) } Log("Monitoring pushToken updates for Live Activity <\(activity.id)>") for await data in activity.pushTokenUpdates { let pushToken = pushTokenString(with: data) // Report token to APNS service reportTokenToAPNS(pushToken) } } } System Log Evidence System logs, log and log

In one of the WWDC word clouds I saw the label "Extra-small widget option in visionOS", but looking at the WidgetFamily it doesn't look like there is any new size that has been opened up for 27. Is this a new size to be supported or something else entirely?

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

Anyone unable to configure their widgets on iOS 27? I can edit a widget’s configuration but that doesn’t have any effect on the widget. I’m seeing this in the simulator and I have some users seeing it on-device. Is this a known issue or are there workarounds?

Hi. It is not as much as widgets itself but it goes along with live activities for sure I believe. Question 1: Hybrid Intelligence & Proactive Context How can developers leverage the Intelligence Platform (specifically intelligenceplatformd) to ensure 3rd-party apps provide the same deep proactive context as first-party services like Spotlight, but strictly through on-device processing to maintain total user privacy? Question 2: Autonomous Diagnostics & Private Reporting Is there a roadmap for Feedback Assistant to autonomously aggregate complex system-level interactions—using spindump or system_profiler—to generate "ready-to-implement" solutions for users, while ensuring these diagnostic insights remain local and are never transmitted to Apple or Google without explicit, granular consent? Question 3: Deep Indexing for Hybrid Data Sources With the shift toward ecosystem-wide intelligence, are there upcoming APIs that will allow Siri or App Intents to more deeply index "hybrid" private data sources—such as external databases or complex Markdown structures in Obsidian—without compromising the local-first security model?

is there a documented way to schedule when a live activity changes? I have observed other apps that can update their live activities, (countdown timer that changes at 0:00 to 'Timer Complete') I've observed apps that can do this without using a server (my device was in airplane mode) and while the app was backgrounded. but I cant figure out how to do it in my own app

I have an iOS app, Timely, that provides App Intents / Shortcuts actions for starting countdown Live Activities. The same action works correctly when run directly from the Shortcuts app or from Shortcuts automations. It also works through Siri when there are no existing Timely Live Activities. However, when one Timely countdown Live Activity is already active, asking Siri to start a second countdown fails. Siri responds with: Something went wrong, please try again. I added focused logging around the exact ActivityKit start path. The intent does start, ActivityAuthorizationInfo().areActivitiesEnabled is true, and the code reaches Activity.request(...). The failure is thrown directly by ActivityKit: [StartCountdownLiveActivityIntent] perform started countdownId=ef6eace3-1186-4263-8215-ddcc80fd34ae activitiesEnabled=true activeActivityCount=1 [StartCountdownLiveActivityIntent] existing activity activityId=D469D281-45BC-42F1-9DC9-83A8F346EC9C eventId=0d1365ee-dc30-4bc9-a6b3-6c9151098b8b state=active eventTime=2026-06-12T17:00:00Z [StartCountdownLiveActivityIntent] before Activity.request eventId=ef6eace3-1186-4263-8215-ddcc80fd34ae enablePushToken=true activitiesEnabled=true activeActivityCount=1 activities=[activityId=D469D281-45BC-42F1-9DC9-83A8F346EC9C,eventId=0d1365ee-dc30-4bc9-a6b3-6c9151098b8b,state=active,eventTime=2026-06-12T17:00:00Z] [StartCountdownLiveActivityIntent] Activity.request threw eventId=ef6eace3-1186-4263-8215-ddcc80fd34ae originalError=visibility localizedDescription=The operation couldn’t be completed. Target is not foreground nsErrorDomain=com.apple.ActivityKit.ActivityAuthorization nsErrorCode=7 nsErrorUserInfo=[:] So the error appears to be: ActivityAuthorizationError.visibility NSError domain: com.apple.ActivityKit.ActivityAuthorization NSError code: 7 Localized description: The operation couldn’t be completed. Target is not foreground The important part is that this only seems to happen when invoked through Siri and only when another Live Activity from the same app is already active. Running the same App Intent through Shortcuts succeeds. Is this an expected limitation of Siri-hosted App Intents / LiveActivityIntent execution, or is this an ActivityKit/Siri bug? FB23079760

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.

I hope I'm just missing something is there a way to schedule when a Live Activity should be dismissed, or schedule when its content will change? (local, without a server) I have observed other apps have the ability to swap out their countdown view for a 'timer complete' all while the app is backgrounded and airplane mode is on (ie its not being updated via server) however when trying to build any kind of similar functionality into my own app I come up short, I see no way to schedule when a live activities view will change, and similarly no way to schedule when it should be dismissed, and the system doesn’t treat the stale date as a flag for clearing an out of date live activity

I noticed visionOS 27 introduces an extra-small widget size. Compared to other widget sizes, is this form factor mainly intended for quick actions/triggers rather than displaying app info or status? As a developer, how much interactivity can we build into it — can we attach App Intents to make these extra-small widgets directly actionable, similar to interactive widgets on iOS?

We ship WidgetKit complications (StaticConfiguration, TimelineProvider) in a companion iOS + watchOS app and want to send Adobe Analytics when users add, remove, or switch complication kinds/families on their watch face. From the widget extension we only see timeline refreshes via getTimeline, which seems too noisy and unrelated to user intent to use for lifecycle tracking. On iOS we diff WidgetCenter.shared.currentConfigurations() at app launch against persisted state—is that also Apple’s recommended pattern on watchOS, or is there a supported callback we’re missing? How should this work for a companion app (watch collects and relays via WatchConnectivity vs. tracking from the iPhone Watch app) versus a standalone watch app where third-party analytics may only run on-device? We’re especially unsure how reliably removal is detected if the watch app doesn’t launch again after a complication is removed.

Hi, do you have suggestions for implementing widgets that get populated with data from external sources at different times? Example: a few numbers are displayed that usually update once or twice a day but some days multiple times per hour for part of the day. We can't get this to work reliably on all of the devices we are testing with and because the throttling/budgeting behavior is opaque it is more of a challenge to pinpoint why. Here are some things we are starting to experiment with, it would be helpful to know if some or all of these approaches would be too demanding of resources to be useful when populating widgets with content: creating dynamic timelines that have different frequencies on different days in the main app downloading new schedules from a server for the timelines for future dates using a combination of silent push notifications and background tasks to download the data when notifications are missed And we're already aware of the basic guidelines (relaxed budget constraints when debugging from xcode, avoid force quitting apps, etc.), would be great to get additional insight beyond the documentation like how to tell when an app has already depleted its budgets. (The questions are primarily geared towards iPhone/iPad). Thanks again!

I have an iOS app, Timely, that provides App Intents / Shortcuts actions for starting countdown Live Activities. The same action works correctly when run directly from the Shortcuts app or from Shortcuts automations. It also works through Siri when there are no existing Timely Live Activities. However, when one Timely countdown Live Activity is already active, asking Siri to start a second countdown fails. Siri responds with: Something went wrong, please try again. I added focused logging around the exact ActivityKit start path. The intent does start, ActivityAuthorizationInfo().areActivitiesEnabled is true, and the code reaches Activity.request(...). The failure is thrown directly by ActivityKit: [StartCountdownLiveActivityIntent] perform started countdownId=ef6eace3-1186-4263-8215-ddcc80fd34ae activitiesEnabled=true activeActivityCount=1 [StartCountdownLiveActivityIntent] existing activity activityId=D469D281-45BC-42F1-9DC9-83A8F346EC9C eventId=0d1365ee-dc30-4bc9-a6b3-6c9151098b8b state=active eventTime=2026-06-12T17:00:00Z [StartCountdownLiveActivityIntent] before Activity.request eventId=ef6eace3-1186-4263-8215-ddcc80fd34ae enablePushToken=true activitiesEnabled=true activeActivityCount=1 activities=[activityId=D469D281-45BC-42F1-9DC9-83A8F346EC9C,eventId=0d1365ee-dc30-4bc9-a6b3-6c9151098b8b,state=active,eventTime=2026-06-12T17:00:00Z] [StartCountdownLiveActivityIntent] Activity.request threw eventId=ef6eace3-1186-4263-8215-ddcc80fd34ae originalError=visibility localizedDescription=The operation couldn’t be completed. Target is not foreground nsErrorDomain=com.apple.ActivityKit.ActivityAuthorization nsErrorCode=7 nsErrorUserInfo=[:] So the error appears to be: ActivityAuthorizationError.visibility NSError domain: com.apple.ActivityKit.ActivityAuthorization NSError code: 7 Localized description: The operation couldn’t be completed. Target is not foreground The important part is that this only seems to happen when invoked through Siri and only when another Live Activity from the same app is already active. Running the same App Intent through Shortcuts succeeds. Is this an expected limitation of Siri-hosted App Intents / LiveActivityIntent execution, or is this an ActivityKit/Siri bug?

I’m running into an issue with Live Activities and was wondering if anyone else has seen something similar. Some users occasionally see a spinning/loading indicator instead of the normal Live Activity UI. The push payloads look valid and consistent across users, nothing appears to be missing or malformed. Has anyone encountered this before or knows what could cause the Live Activity to fall back into a loading state?

When I set an alarm using the AlarmKit Demo App provided by WWDC, wait for the alarm to go off while the device is unlocked, and the Dynamic Island pops up with a notification, instead of tapping the button to dismiss it, I collapsed the Dynamic Island. The Dynamic Island displayed a black blank screen; when I long-pressed to expand it, it still showed a black blank screen. When I tapped it while collapsed, it redirected me to the Demo App, and this state persisted indefinitely. The issue was only resolved by turning off the device or setting a new alarm and waiting for it to go off, then explicitly tapping to dismiss it. Additionally, I’m currently developing my own AlarmKit-based alarm app, which is how I discovered this bug. Now that I’ve found the official demo has the same issue, I look forward to a fix. Xcode version 26.5 (17F42) macOS version 26.5 (25F71) Simulator version 26.4.1 Device version 26.5.1 Demo App link： https://docs-assets.developer.apple.com/published/c2045ce0bff8/SchedulingAnAlarmWithAlarmKit.zip

We are building a media application that uses Live Activities and Dynamic Island extensively on iPhone. On macOS, we currently need to build separate UI surfaces such as menu bar extras, widgets, and custom overlays. Are there any recommended patterns for creating a persistent, glanceable activity experience on macOS that maintains parity with Live Activities on iPhone?

We ship WidgetKit complications (StaticConfiguration, TimelineProvider) in a companion iOS + watchOS app and want to send Adobe Analytics when users add, remove, or switch complication kinds/families on their watch face. From the widget extension we only see timeline refreshes via getTimeline, which seems too noisy and unrelated to user intent to use for lifecycle tracking. On iOS we diff WidgetCenter.shared.currentConfigurations() at app launch against persisted state—is that also Apple’s recommended pattern on watchOS, or is there a supported callback we’re missing? How should this work for a companion app (watch collects and relays via WatchConnectivity vs. tracking from the iPhone Watch app) versus a standalone watch app where third-party analytics may only run on-device? We’re especially unsure how reliably removal is detected if the watch app doesn’t launch again after a complication is removed.