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

I am using ActivityKit push-to-start Live Activities on iOS 17.2 and later. In a small number of user reports, the app is never able to obtain Activity<LiveActivityAttributes>.pushToStartToken. The flow is: Task { if let token = Activity<LiveActivityAttributes>.pushToStartToken { // cache and upload token } else { // logged: current push-to-start token is nil } for await token in Activity<LiveActivityAttributes>.pushToStartTokenUpdates { // cache and upload token } } This task is started when the app launches. For the affected users: Activity<LiveActivityAttributes>.pushToStartToken returns nil at app launch. Activity<LiveActivityAttributes>.pushToStartTokenUpdates never emits any value. After waiting for a while, reading Activity<LiveActivityAttributes>.pushToStartToken again still returns nil. When an existing Live Activity ends or expires, the app retries and reads Activity<LiveActivityAttributes>.pushToStartToken again, but it is still nil. Example log from the retry after the Live Activity ended: [Live Activity][retryDisplayCreationAfterLiveActivityEnded] Failed to read PushToStart token. local entity is nil: true In this case, the local entity is empty because no push-to-start token was ever received from ActivityKit. This is not about the per-activity activity.pushToken; the issue is specifically with the app-level Activity<Attributes>.pushToStartToken. Because the push-to-start token remains empty, our server cannot send a push-to-start request for that user. I have seen a previous forum response mentioning a timing issue before iOS 26, but this affected case is on iOS 26.5, so I am not sure whether this is the same issue or a different condition. Questions: Under what conditions can Activity<Attributes>.pushToStartToken remain nil indefinitely? Is pushToStartTokenUpdates expected to emit the current token after app launch, or only future token changes? If the initial pushToStartToken read returns nil, what is the recommended retry strategy on iOS 26.5? Does Live Activities authorization, notification permission, APNs registration state, app install source, or device state affect generation of the push-to-start token? What logs or sysdiagnose information would be useful to confirm whether this is an ActivityKit issue? Environment: iOS version: 26.5 Device model: iPhone 17 App install source: TestFlight Xcode version: 26.3 ActivityKit usage: push-to-start Live Activity Any guidance on whether this is expected behavior, a known issue, or something we should file through Feedback Assistant would be appreciated.

Not sure if this is an intented change in terms of UI on 27 beta 1, but I think the previous implementation of configuring array of App Entity is better with a list and options and reorder and remove items. My widget configuration code: struct BusWidgetConfiguration: WidgetConfigurationIntent { static var title: LocalizedStringResource { "Bus Stop Configuration" } static var description: IntentDescription { "Configure youe top 3 most commonly used bus stop to open in app." } @Parameter(title: "Bus Stop", default: [], size: IntentCollectionSize(min: 0, max: 3)) var busStops: [BusStopEntity] @Parameter(title: "Open in Maps", default: false) var openInMaps: Bool } iOS 27 Beta 1: iOS 26.5:

Hi team, I’m working on an ActivityKit use case where a Live Activity is useful on the Lock Screen, but not in the Dynamic Island. Today, Live Activities appear to be treated as a unified presentation across system surfaces: Lock Screen, Dynamic Island, StandBy, etc. For our app, the Lock Screen presentation is the right user experience, but showing the same activity in the Dynamic Island creates unnecessary persistent foreground UI while the user is actively using the device. Is there any supported way to create a Live Activity that appears on the Lock Screen but opts out of Dynamic Island presentation on supported iPhones? If not, I’d love to request an ActivityKit enhancement that lets developers specify supported presentation destinations for a Live Activity, for example something like: Lock Screen only or Lock Screen + StandBy, but not Dynamic Island This would be useful for apps where the Live Activity is meant to act as a passive lock-screen status/reminder, rather than an ongoing foreground indicator. Thanks!

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?

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?