I’m implementing a Live Activity that shows some text and a button.
When the user taps the button, I want to open the host app.
What I’ve done so far:
Implemented a LiveActivityIntent to handle the button tap.
The intent is triggered successfully. However, the app does not open by using deep link/universal app link.
From what I can tell, LiveActivityIntent seems limited to system/background execution and doesn’t bring the app to the foreground.
Questions:
Is it possible for a LiveActivityIntent to open the app?
Is this behavior a documented/intentional limitation?
If not supported, is using a Universal Link or deep link the recommended solution for opening the app from a Live Activity button?
Any official clarification or recommended best practice would be helpful.
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
I have start new live activity with push notifications,but sometimes this code"activity.pushTokenUpdates" can not callback to me,so I can't update the activity with push notifications. And I already click “Allow” button in my live activity widget.How can I solve this problem.
Here are my code:
fileprivate func observeLiveActivityForRemoteCreate() {
// obverser pushToStartToken
Task {
if #available(iOS 17.2, *) {
var beforeToken = ""
for await pushToken in Activity<HLPlatformActivityAttributes>.pushToStartTokenUpdates {
let pushTokenStr = pushToken.map{String(format: "%02.2hhx", arguments: [$0])}.joined()
// avoid send duplication
if beforeToken == pushTokenStr {
return
}
beforeToken = pushTokenStr
// send pushToStartToken to service
await HLPlatformLiveActivityBridge.registerLiveActivity(withAttributesName: self.activityAttributesName, pushToStartToken: pushToken, seq: seqCreate(), pushType: .jPush)
}
}else {
// Fallback on eralier versions
}
// obverser live activity update
Task {
for await activity in Activity<HLPlatformActivityAttributes>.activityUpdates {
if let businessLiveActivityId = activity.attributes.businessLiveActivityId, let liveActivityId = activity.attributes.liveActivityId {
Task {
var beforeToken = ""
for await pushToken in activity.pushTokenUpdates {
// here the problem:sometimes pushToken not update to me
let pushTokenStr = pushToken.map{String(format: "%02.2hhx", arguments: [$0])}.joined()
// avoid send duplication
if beforeToken == pushTokenStr {
return
}
beforeToken = pushTokenStr
// send pushToken to service
}
}
Task {
for await stateUpdate in activity.activityStateUpdates {
if stateUpdate == .active {
// live activity create
}
}
}
}
}
}
}
Hi,
My iOS app's home screen widget content was implemented to base on the preferred language of my main app (e.g. my app has the following preferred language options with this order English, Japanese, Traditional Chinese, Korean, Simplify Chinese).
Say the main app is currently using English as their preferred language, I can change the preferred language in the iOS Settings -> Apps -> My App -> Preferred Language.
My widget's content will respect to the preferred language option that I selected with only exception if I switch back to English language and my Widget's content won't get updated. The Main app content is always update with respect to the selected preferred language.
My app and widget is working without any issue in iOS 18.
Other things that I had discovered during my testing under iOS 26, the "first" language appeared in my preferred language always being the issue (e.g. if the first language is Japanese , once I change to other languages and than switch back to Japanese, my widget content won't respect to this but the main app content are ok).
Any one has a similar issues regarding the preferred language?
Topic:
App & System Services
SubTopic:
Widgets & Live Activities
Tags:
Internationalization
Localization
Hello,
I'm trying to create a widget using the WidgetKit framework. In this part, I'm using Intents along with a DynamicOptionsProvider. As shown in the Medium article below, I want to present multiple options when "Edit Widget" is tapped:
https://levelup.gitconnected.com/swiftui-configurable-widget-to-let-our-user-choose-4a54e398f42f
However, in this example, the options are provided statically. What I want to achieve is to display a list of devices based on the selected HomeId after the user selects a Home. I’ve set up the interface accordingly, but when I select a Home, the device list does not update.
How can I make this work? The two options should be dependent on each other.
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.
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