Hey everyone, We're using Push to Start Live Activities in our app (District: Movies Events Dining) where all Live Activities are entirely server-driven. At District, we've taken a unique approach to Live Activities. Since our customers often plan ahead reserving restaurant tables early in the week or booking movies days in advance we needed a way to surface timely, relevant information without requiring the app to be open. We power our Live Activities entirely from the server using Push to Start and Push to Update. This means the Live Activity is initiated and kept up to date by our backend from reservation confirmation all the way to the day of the experience. Whether it's a dining slot or a movie showtime, the Live Activity automatically appears in the notification tray with all relevant details, right when you need it no app launch required. FB Number: FB22062904 Problem: When a Push to Start payload is sent from the server, the user sees an Allow / Don't Allow prompt on their lock screen. If the user ignores this prompt (neither taps Allow nor Don't Allow), the Live Activity card stays stuck in the notification tray permanently with zero way to dismiss it programmatically. This happens because: The activity never officially "starts" on device Activity.end() cannot be called — there's nothing to end Sending an update/end push has no effect dismissal-date is not honoured in the start payload Steps to Reproduce Send a push-to-start APNs payload to a device Do NOT tap Allow or Don't Allow on the prompt Observe — card stays in notification tray indefinitely Send an end push from server — no effect Current Payload { "aps": { "timestamp": 1234567890, "event": "start", "alert": { "title": "Your table is reserved", "body": "Tap to view your reservation" }, "content-state": { ... }, "attributes-type": "ReservationActivityAttributes", "attributes": { ... } // ❌ dismissal-date has no effect here } } Expected Behaviour dismissal-date should be honoured in the push-to-start payload, so that if the user ignores the prompt, the notification auto-dismisses after the specified time — consistent with how standard Live Activity expiry works. Suggested Fix { "aps": { "timestamp": 1234567890, "event": "start", "content-state": { ... }, "dismissal-date": 1234568490 // ✅ honour this } } Impact This affects any app using server-driven Live Activities — dining reservations, movie bookings, food delivery, ride hailing, ticketing etc. Without this, there is no way to prevent permanent notification tray pollution for users who ignore the Allow prompt. Has anyone found a workaround for this? Would love to know if others are hitting the same issue.

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:

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.

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!

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

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?