I'm seeing a Live Activity that successfully starts via Activity.request() — activityState returns .active, a valid ActivityKit push token is issued and works correctly — but nothing ever appears on the Lock Screen, and the widget extension process never shows up in Xcode's Debug → Attach to Process list (the main app process does appear). This happens consistently across many clean rebuilds. Setup: Flutter app (using the live_activities Flutter plugin, which wraps ActivityKit) with a native iOS Widget Extension target for the Live Activity Xcode 26.5, iOS 18.7.9 on a physical iPhone XS Max Bundle ID: com.santitech.foodboda, extension: com.santitech.foodboda.FoodbodaLiveActivity NSSupportsLiveActivities = YES confirmed in both the main app's Info.plist and the extension's Info.plist (verified in the compiled .appex binary itself, not just source) App Group entitlement confirmed present in both compiled provisioning profiles via security cms -D on embedded.mobileprovision Deployment target 16.6 on both targets (Live Activities require 16.1+) Settings → [App] → Live Activities toggle confirmed ON; Low Power Mode OFF What I've already ruled out: Target membership of Swift source files — confirmed correct in File Inspector WidgetBundle only references the real Live Activity widget (removed unused Control/home-widget/AppIntent boilerplate) Info.plist NSExtensionPointIdentifier = com.apple.widgetkit-extension — correct Built a brand-new, separate, minimal test app+extension from Xcode's default template, using the exact same Attributes/ContentState/SwiftUI view code as the main app (copy-pasted verbatim) — this minimal test successfully renders on the Lock Screen on the same physical device. This proves the Swift code itself, the device, and the Apple ID/provisioning are all capable of supporting Live Activities correctly. Confirmed areActivitiesEnabled() returns true and getActivityState() returns .active on every test Tested with full app delete + device restart + DerivedData wipe between attempts — no change Question: Given that identical code works in an isolated minimal project but not in the main app's bundle ID, what could cause this specific symptom — ActivityKit registering an activity as active while WidgetKit never instantiates the extension to render it — tied to one specific app/bundle identifier rather than the device or account in general? Is there a known interaction with App Groups that have been reconfigured many times during development, or any way to fully reset WidgetKit's registration state for a specific bundle ID short of changing the bundle identifier 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

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!

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?

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?

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

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.

I asked this elsewhere in the forums and haven't gotten a response, but 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?

One of the WWDC word clouds included the phrase "Real-time updates for widgets with app is open". Can someone please explain what is going on there and how that is different from what was happening previously? I was under the impression that updates were always happening while the app was running and never counted against whatever app update quota was in place. I am not sure if this is related, but I would love to know in iOS 27 has any sort of increase to the memory or CPU limits on widget updates. For years we have had ideas for more widgets but can't implement them because even staying under the 30MB limit has been nearly impossible.