Problem: unable to retrieve push-to-start token upon app start Environment: simulator, iPhone 15 Pro, iOS 18.1 (also reproduced on physical devices) First image is a start from XCode with "Run" option (Cmd+R) where debugger is linked Second image is a "cold" start - starting app by tapping the icon Difference is: Start observing (line 2), push token changed (last line). Everything is okay Push token changed (7 line), start observing (9 line). liveactivitysd generates token before we reach pushToStartTokenUpdates loop - we losing token The question is: how is this possible (case 2)?

For some reason since iOS 26.5, a ControlWidgetButton or a Button in a widget configured with an AppIntent conforming to OpenIntent fails to receive its AppEnum parameter correctly if the intent and enum are defined inside a shared Swift Package. Tapping the control widget button opens the main application, but it doesn't pass the AppEnum parameter value in, leaving the app on its default screen instead of navigating to the intended view. This was working perfectly in iOS 26.4, where the app would launch and receive the correct enum case from the intent. No code, configuration, or scheme changes were made between the two runs, only the simulator/OS version differs. Has anyone else run into what seems to be a regression on iOS 26.5? I filed feedback with a sample project: FB22848510

Pls apple i daily drive this and is a core part of the apple ecosystem i even bought my cousin a watch to solely talk to him whenever

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

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?