Just wanted to clarify some expected behaviors here. It seems that there are two distinct behaviors for Live Activity flows for freshly installed apps.
When you start a Live Activity for the first time and the user hasn't yet clicked on Allow/Don't Allow in the activity interface, there are two different sequences:
Starting a Live Activity locally
Request a Live Activity locally via Swift
Live Activity starts
.pushTokenUpdates is immediately triggered, even if the Allow/Don't Allow buttons appear under the Activity UI
Starting a Live Activity via push-to-start
Send a push-to-start notification to launch a Live Activity
Live Activity starts
.pushTokenUpdates is not triggered, and .pushToken returns nil.
If a user clicks on Allow in the Activity UI, only then is .pushTokenUpdates triggered.
Widgets & Live Activities
RSS for tagDiscuss how to manage and implement Widgets & Live Activities.
Selecting any option will automatically load the page
Post
Replies
Boosts
Views
Activity
We are currently using Live Activities in our app and supporting both of the following use cases:
Starting a Live Activity directly from the app using ActivityKit APIs.
Starting a Live Activity from the backend using the start token.
In the first case (initiated from the app), the OS generates an update token, and we are able to continuously update the Live Activity via our backend—even if the user has not explicitly provided "Allow" or "Always Allow" consent from the lock screen. This works as expected.
In the second case (initiated from the backend), if the user does provide consent ("Allow" or "Always Allow") from the lock screen, we receive the update token and can continue updating the Live Activity.
However, if the user does not provide consent, the OS does not provide the update token, and we are unable to send further updates.
Question:
Is it possible to receive the update token from the OS when the Live Activity is started from the backend, without the user explicitly providing "Allow" or "Always Allow" consent from the lock screen?
We would appreciate any clarification or official documentation related to this behavior.
Thank you!
Topic:
App & System Services
SubTopic:
Widgets & Live Activities
Tags:
APNS
Entitlements
ActivityKit
When we use AppIntents to configure WidgetKit complications, the description we provide in IntentRecommendation is ignored after applying a .watchface file that includes those intent configurations. In the Watch app, under Complications, the labels shown next to each slot do not match the actual complications on the face—they appear to be the first strings returned by recommendations() rather than the selected intent configuration.
Steps to Reproduce
Create an AppIntent used by a WidgetKit complication (e.g., .accessoryRectangular).
Provide multiple intent recommendations with distinct descriptions:
struct SampleIntent: AppIntent {
static var title: LocalizedStringResource = "Sample"
static var description = IntentDescription("Sample data")
@Parameter(title: "Mode") var mode: String
static func recommendations() -> [IntentRecommendation<Self>] {
[
.init(intent: .init(mode: "A"), description: "Complication A"),
.init(intent: .init(mode: "B"), description: "Complication B"),
.init(intent: .init(mode: "C"), description: "Complication C")
]
}
func perform() async throws -> some IntentResult { .result() }
}
Add two of these complications to a Modular Duo face (or any face that supports multiple slots), each with different intent configurations (e.g., A in one slot, B in another).
Export/share the face to a .watchface file and apply it on another device.
Open the Watch app → the chosen face → Complications.
Expected
Each slot’s label in Complications reflects the specific intent configuration on the face (e.g., “Complication A”, “Complication B”), matching what the complication actually renders.
Actual
The labels under Complications do not match the visible complications. Instead, the strings shown look like the first N items from recommendations(), regardless of which configurations are used in each slot.
Notes
The complications themselves render correctly on-watch; the issue is the names/labels displayed in the Watch app UI after applying a .watchface.
Filed Feedback: FB20915258
Topic:
App & System Services
SubTopic:
Widgets & Live Activities
Tags:
watchOS
Watch Complications
WidgetKit
App Intents
Im having trouble enabling Live Activities in a new app. The option is not available in Xcode or in the developer portal. Is there something I have to do to activate this option?
Topic:
App & System Services
SubTopic:
Widgets & Live Activities