We are implementing starting an activity via Push-To-Start. For the most part it works great, however we have run into a few edge cases. Currently, we send the "start activity" push notification and it creates the Activity as expected. If the app doesn't send an update token w/in a configured time, we assume the activity didn't start and try to start the activity again. Occasionally we get into a situation where there have been multiple activities started, but it should really only be one. Here is my theory: We store an auth token in the keychain for all REST endpoints if the phone has been restarted and not unlocked, the app doesn't have access to the auth token and fails to send the update token to our backend. Are there any best practices on how to manage PTS and UPDATE tokens? (updating these w/o authentication seems problematic)

I have a live activity and even after a couple of times that it has shown on my lock screen it keeps prompting the user to tap on Don't Allow or Allow. Can someone help me understand why this is happening? I would like my users to only hit Allow once and not be prompted again, otherwise they would not be registered for updates, since update token only generates after selecting Allow.

I'm adding live activities to my app and I'm trying to use push notifications to fully remotely start them and end them. The pushToStartTokenUpdates sequence gives start tokens exactly as expected, and triggers even when the app is fully terminated when a new live activity starts. However, the pushTokenUpdates sequence is far less predictable and seems to never trigger when the app is fully terminated. Even when the app is just backgrounded, it's still finicky. I send the "input-push-token": 1 as part of the aps payload too to begin the live activity, but that seems to have little to no effect. Is there any way to ensure that we can receive a push token specifically to update the live activity after it starts? It seems to me that if a live activity can be started via push even when the app is fully terminated, and live activities are meant to reflect active information, then the mechanism to update it via a new token should also be able to work when the app is terminated. Both sequences are subscribed to within the AppDelegate upon initial app launch. This is what my code looks like at the moment: func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?) -> Bool { Task { for await newToken in Activity<WidgetAttributes>.pushToStartTokenUpdates { let tokenString = newToken.map{ String(format: "%02x", $0) }.joined() // send to server } } Task { for await activity in Activity<WidgetAttributes>.activityUpdates { Task { for await token in activity.pushTokenUpdates { let tokenString = token.map { String(format: "%02x", $0) }.joined() // send to server } } } } } } Thanks in advance for any insights!

I am developing an iOS app using ActivityKit Live Activities with interactive buttons based on LiveActivityIntent. The implementation works correctly: LiveActivityIntent.perform() executes correctly. The Live Activity updates visually. MediaPlayer actions are triggered successfully. The app does not open when tapping the buttons. Repeated taps correctly update the Live Activity state. However, I observed a behavior difference on the Lock Screen: Now Playing controls keep the Lock Screen awake while interacting repeatedly. Apple Stopwatch/Timer controls also keep the Lock Screen awake while interacting. My app’s Live Activity fades to black after around 5–7 seconds even while the user continues tapping the Live Activity buttons. I also tested a third-party timer app with Live Activity buttons and observed the same fade-to-black behavior. I additionally tested: repeated Activity.update(...) calls after each tap; visual state updates after every interaction; multiple consecutive interaction updates. None of these prevented the Lock Screen from dimming/fading to black. So my question is: Is this expected behavior for third-party Live Activities using LiveActivityIntent? Or is there any recommended way to keep the Lock Screen interaction session active while the user is continuously interacting with Live Activity buttons? I am especially interested from an accessibility perspective, because short interaction windows can make repeated Lock Screen interactions more difficult for users with motor impairments or slower interaction patterns.

Our application currently supports Live Activities. We’re working on adding a new Widget and are weighing some architectural decisions regarding whether we should add it to the same extension target that our Live Activity lives in or create a new extension that would expose it and other widgets we plan to create in the future. In the Add Support for Live Activities documentation, it suggests adding Live Activity code to the existing widget extension to facilitate code reuse. Beyond code sharing, we’re trying to determine if there are downsides to isolating new Widget(s) into their own extension. Specifically, we are concerned about process isolation and how a failure/crash in one might impact the other. Assuming they did live in the same extension, we’re hoping to better understand some of the finer details as presented by the following questions: If a Widget (e.g., via the TimelineProvider) causes the extension process to crash, what is the guaranteed behavior for a currently running Live Activity? Is the relaunch and restoration of a Live Activity after an extension crash guaranteed, or is it best-effort? Is there a distinction in crash isolation between a TimelineProvider failure and a View rendering crash? Are there any known scenarios where a Widget crash could cause a Live Activity to be permanently dropped? Does keeping them in the same extension affect the memory budget, or does each 'instance' receive its own allocation? In short: we're looking to ensure that an issue with a Widget doesn't inadvertently affect a Live Activity (or vice-versa) when they live in the same WidgetsBundle within the same extension and are seeking guidance on whether it makes sense to keep them together or continue down the path of separate extensions in the interest of process safety. Any pointers to other documentation or known behavior would be greatly appreciated!

Hi everyone, I have a question about Live Activity start tokens and update tokens. After reading the documentation, it is still not very clear to me how often these tokens are invalidated, and whether their expiration is time-based or event-based. My current understanding is that the update token is generated when the Live Activity starts, and that it becomes invalid when the activity ends or is dismissed by the user. What I am not clear on is whether the update token can also become invalid at any point while the Live Activity is still active. I have a similar question about the start token. I have noticed that it is generated on the initial app launch, but I have also seen it get regenerated at what seems like random times. I would like to better understand what events or conditions cause a new start token to be issued. Is there any official guidance on the lifecycle of these tokens, specifically: whether they expire based on time, whether they are only invalidated by specific events, and what conditions trigger regeneration of the start token or update token? Any clarification would be appreciated. Thanks.

On iOS 26, when using .activityBackgroundTint modifiers to change the background color in the Activity Kit, the changes do not appear to apply correctly in Smart Stack. While the color changes as expected, the background is rendered as simply transparent without a glass effect which reduces readability. The glass effect is applied only when activityBackgroundTint is not used.

Our app runs offline-first focus sessions using FamilyControls / ManagedSettings shielding and DeviceActivity monitoring. The in-app session timer is protected against wall-clock manipulation by using monotonic elapsed time, and the shield remains active correctly when the user manually changes the iPhone clock. However, the Live Activity and Dynamic Island countdown appear to use the device's wall clock for their timer rendering. If the user changes the device time from Settings during an active session, the Live Activity / Dynamic Island countdown immediately jumps forward or backwards, even though the underlying session has not changed. Is there a recommended ActivityKit approach for rendering a Live Activity / Dynamic Island countdown that is resistant to manual device clock changes? If not, is this an expected limitation of Live Activity timer rendering? And is there any supported way for the host app or widget extension to detect wall-clock manipulation so the Live Activity can be corrected, dismissed, or replaced with a safer non-countdown state?

Context I'm building a study-timer feature for an iOS app (Flutter + native ActivityKit) that displays a Live Activity on the Lock Screen / Dynamic Island while a session is running. When the user force-quits the app by swiping it up from the App Switcher, I want the Live Activity to disappear as quickly as possible. I have already confirmed (from on-device testing and Apple Developer Forums thread 732418) that: applicationWillTerminate is not called on swipe-up force-kill, only on OS-initiated termination or crash. So synchronous Activity.end(...) from the app itself is not a solution for the force-kill path. Shortening staleDate does not visually dismiss the Live Activity once the app process is gone — the Widget Extension keeps rendering the last fresh snapshot and there is no body-reevaluation trigger on the stale transition post-app-death. (I implemented and verified this, then rolled it back.) The only Apple-official reliable mechanism is APNs push-to-end (Activity.request(pushType: .token) + server sends event: end via APNs). Current architecture I have APNs push-to-end working end-to-end. Structure: Client: Activity.request(pushType: .token), subscribe to Activity.pushTokenUpdates, forward each new token to the backend. Backend: On every client heartbeat, upsert (user_id, la_apns_token, la_activity_id, last_heartbeat) into Postgres. A separate scheduler polls for rows whose last_heartbeat < now() - grace_ttl and sends APNs event: end to the stored token. Parameters I am currently running with: Parameter Value Client heartbeat interval 60 s Orphan grace TTL (server) 135 s (heartbeat × 2.25, to absorb network jitter) Scheduler poll interval 30 s The observation End-to-end latency from "user force-kills the app" to "Live Activity disappears from Lock Screen" is: Worst case: 60 + 135 + 30 = ~225 s (~3.75 min) Typical: ~3 min (as consistently measured on iOS 26.4.1, iPhone 17 Pro Max) Theoretical minimum (if the kill happens exactly at a heartbeat boundary): ~135 s Users perceive 3 minutes as broken — the timer clearly stopped (no ticking), but the Live Activity "ghost" is still visible on the Lock Screen. My question Is there any Apple-supported mechanism to reliably tear down a Live Activity faster than ~2 minutes after the owning app's process is gone, given that applicationWillTerminate does not fire on swipe-kill? Specifically: Is there any practical lower bound below ~60 s for this scenario using the current ActivityKit + APNs model, assuming we are not willing to spam heartbeats every few seconds? I can push heartbeat to 20–30 s, but the server cost grows linearly with active sessions. Does BGAppRefreshTask / BGProcessingTask have any documented lifecycle hook that fires on user-initiated swipe-kill specifically, so that I could do a "last-heartbeat flush" just before the process dies? My understanding is that background tasks are scheduled for later and do not fire synchronously at termination. Is there any signal from APNs/ActivityKit to my server (e.g. a feedback-service-like mechanism) that indicates "this Live Activity's owning app was force-killed", which would let the server short-circuit the heartbeat-based orphan detection? Are there any new APIs in iOS 18.x or the upcoming release that address this specific force-kill → LA-dismissal latency? I could not find anything in the 18.x release notes, but I may have missed it. What I am NOT asking I am not asking how to implement APNs push-to-end (that works). I am not asking about applicationWillTerminate (I already confirmed it does not fire on swipe-kill). I am not asking about shortening staleDate as a visual workaround (I already verified it does not trigger body reevaluation post-kill). Environment iOS 26.4.1 (also reproducible on 18.x devices I have on hand) iPhone 17 Pro Max, iPhone 15 Pro, iPad Air 11-inch (M3) Xcode 26.x Activity.request(pushType: .token) with ActivityContent + custom stalenessInterval = 120s APNs HTTP/2 via token auth (.p8), targeting api.push.apple.com in production apns-push-type: liveactivity, apns-priority: 10, payload includes event: end What I have tried (for the record, to avoid "did you try" responses) applicationWillTerminate with DispatchSemaphore 3.5 s sync wait + dismissalPolicy: .immediate — works only for OS-terminate, not swipe-kill. stalenessInterval = 30s + 15 s refresh cadence + override to 5 s on AppLifecycleState.paused — verified not to dismiss the LA after app death. Cold-start reconciliation via Activity<...>.activities on next app launch — works, but that only helps if the user relaunches. Current APNs push-to-end with 60 s / 135 s / 30 s configuration — works, but latency is the complaint. Any guidance, even "no, ~2 minutes is the floor by design" with a pointer to the relevant doc, would be very helpful. Thank you.

Description When starting Live Activities via ActivityKit push notifications, the “start” notification is received correctly on iPhone 16 Pro Max, but subsequent update or end push notifications are not. The same implementation on iPhone 16 Pro behaves as expected (both start and update/end notifications are delivered and processed). Environment Property Value Device (failing) iPhone 16 Pro Max Device (working) iPhone 16 Pro iOS Version 18.5 Xcode / SDK 16.2/ActivityKit / Push Notifications Network Wi-Fi / Cellular (both tested) Data Collection Method Devices connected via USB. Logs captured using Console.app. Log filtering applied for the liveactivitiesd daemon to isolate Live Activity behavior. Initial Triage/Observations Payload format confirmed compatible; no incompatible fields. APNs token remains the same across messages (no refresh). Identical ActivityKit subscriptions/participants on both devices. Server-side delivery is confirmed: iPhone 16 Pro receives all messages (start, update, end). Only iPhone 16 Pro Max fails to receive update or end push notifications. Log Analysis iPhone 16 Pro (Working) Push-to-Start successfully received: 13:45:20 - APSXPCDeliverMessageEvent: Created APSIncomingMessage 13:45:20 - Received message: eventType: start(SessionPushNotifications.IncomingMessage.EventType.StartParameters(attributesType: "AchToLSUpgradeAttributes", attributesData: 125 bytes, inputs: [])) 13:45:20 - Created activity: 1C081AC5-01AE-4EC0-8B67-5F2A9FAE2D60 13:45:45 - APSXPCDeliverMessageEvent: Created APSIncomingMessage 13:45:45 - Received message: eventType: end(dismissDate: Optional(2025-07-21 21:00:44 +0000)) 13:45:20 - Activity updated: 1C081AC5-01AE-4EC0-8B67-5F2A9FAE2D60 13:45:20 - Local activity did update: 1C081AC5-01AE-4EC0-8B67-5F2A9FAE2D60 iPhone 16 Pro Max (Failing) 13:56:39 - APSXPCDeliverMessageEvent: Created APSIncomingMessage 13:56:39 - Received message: eventType: start(SessionPushNotifications.IncomingMessage.EventType.StartParameters(attributesType: "AchToLSUpgradeAttributes", attributesData: 125 bytes, inputs: [])) 13:56:39 - Created activity: E6BBF691-0C7A-4791-98D2-6F1440D9932E **No subsequent APNs push-to-update or push-to-end messages received.** 13:56:39 - No destinations for event E6BBF691... of type start 13:56:40 - No destinations for event E6BBF691... of type update Questions for Apple Engineering Are there known issues with ActivityKit push notifications specifically on iPhone 16 Pro Max devices? What additional diagnostic logs (system, APNs, liveactivitiesd) would be most helpful to collect? Could device-specific power management, notification settings, or OS-level changes on Pro Max models affect Live Activity updates? Are there differences in how Live Activity push subscriptions or routing are handled on iPhone 16 Pro Max vs Pro that could lead to this issue?

Hi Apple Team, We are facing an issue with Live Activities where the UI intermittently fails to render and shows a loader or blank state. After extensive debugging, we’ve identified that the failure happens during the rendering phase inside the system process (WidgetKit / liveactivitiesd), but there are no actionable signals exposed to the app. Problem: Live Activity launches successfully After a few updates or under certain UI conditions, it: stops rendering shows a loader / blank UI sometimes disappears No crash logs are generated No MetricKit diagnostics available for the extension Console logs show: Invalid frame dimension (negative or non-finite) Archive was nil. LiveActivity will be empty Sometimes because of memory pressure too The extension process appears to terminate silently Challenge Currently, there is no way to detect from the app side that: the Live Activity has failed to render the extension process has crashed/terminated the UI is no longer being updated Questions Is there any callback, delegate, or lifecycle hook that notifies when: a Live Activity rendering fails the extension process crashes or is terminated by the system? Is there any recommended way to detect a “broken” Live Activity state (e.g., stuck loader / non-updating UI)? Are there any diagnostic APIs or logs we can rely on in production to identify such failures? Is this considered expected behavior under certain system constraints (e.g., memory/rendering limits), and if so, are there guidelines to proactively detect or mitigate it? Goal We want to: proactively detect Live Activity failure log it for monitoring optionally fallback or recover gracefully Additional context: We fixed all the issues and the live activity is pretty stable. But asking for methods to track & fix such cases.

Hi everyone, I’m currently implementing Live Activities in my music app to display real-time lyrics on the Lock Screen. The app works fully offline, so I’m not using push updates or push tokens. Instead, I’m updating the Live Activity locally as each new line of lyrics is played (essentially near real-time updates synced with the song). However, I’m running into an issue where the Live Activity UI is not updating reliably or frequently enough. Even though I’m calling the update method for each lyric line, the changes are either delayed or not reflected at all. Here’s some additional context: • The app runs fine in the background (verified via battery usage and playback behavior) • Live Activity is successfully created and initially displayed • Updates are triggered locally (no push notifications involved) • Updates are happening quite frequently (per lyric line) • No crashes or errors are observed My questions: 1. Is there a system-imposed throttling limit on how frequently Live Activities can be updated locally? 2. Are there recommended update intervals for smooth UI updates (e.g., for use cases like lyrics or timers)? 3. Does Live Activity deprioritize updates for offline apps or background execution? 4. Are there any additional configurations or capabilities required to ensure consistent updates? 5. Is using something like AsyncStream or other concurrency patterns helpful in this case? 6. Are there any undocumented limitations or best practices for high-frequency updates? 7. Is there any private or internal API used by Apple apps (like Music) that allows smoother real-time updates? My goal is to achieve smooth, near real-time lyric updates similar to Apple Music’s Now Playing experience. Any guidance, best practices, or clarification would be greatly appreciated. Thanks in advance!

Hello community, I am implementing a Live Activity for my existing App Store app. The Live Activity works perfectly on the iOS Simulator, but it completely fails to appear on the physical device's lock screen. When I call Activity.request, it succeeds and returns a valid Activity ID, but the physical device's console immediately outputs the following errors from liveactivitiesd: liveactivitiesd is not entitled to specify a scene target. Defaulting containingProcess target to liveactivitiesd No asset provider bundle ID provided I have spent days debugging this and have tried every known workaround. Here is the comprehensive list of what I have already verified and attempted: Environment: Xcode: 16.4 iOS Device: iPhone 13 mini, iOS 26.3.1 macOS: Sequoia 15.6 What I have verified/tried (to avoid duplicate suggestions): NSSupportsLiveActivities: It is set to YES in the main app's Info.plist. I also tried adding it to the Widget Extension's Info.plist just in case. App Icons: The main app has a valid AppIcon set in Assets.xcassets. The Primary App Icon Set Name in Build Settings is correctly set to AppIcon. Bundle IDs: They match perfectly (com.mycompany.app and com.mycompany.app.MyWidget). Version & Build Numbers: The main app and the Widget Extension have exactly the same Version and Build numbers. App Groups & Entitlements: Checked and perfectly synced between the main app and the extension. Dummy Widget: Since it's a Live-Activity-only extension, I added a standard static DummyWidget to the WidgetBundle to prevent the known iOS 17 bug where the system ignores extensions without home screen widgets. Memory/Sanitizers: Ensured Address Sanitizer and Zombie Objects are completely disabled in the Scheme to prevent the 30MB memory limit crash on the device. Nuclear Option: Completely deleted the Widget Extension target, wiped DerivedData, restarted the Mac and iPhone, and recreated the extension from scratch. Minimal UI Test: Replaced the widget's UI with a simple Text("Test") to rule out any SwiftUI rendering crashes. Device Settings: Verified that "Live Activities" is enabled under "Face ID & Passcode" settings on the physical iPhone. Despite all of this, the Simulator works flawlessy, while the device throws No asset provider bundle ID provided and shows nothing. Does anyone know what specific condition causes liveactivitiesd to fail to find the asset provider (the parent app) on a physical device for an existing app? Are there any undocumented provisioning profile quirks or obscure Build Settings I might be missing? Any insights would be deeply appreciated. Thank you!

默认 chronod [com.jd.jinrong.JDJRWidget] Creating session... 默认 chronod [DFB1D11C]: activityHandler ended 默认 iconservicesagent [0x5e2812320] activating connection: mach=false listener=false peer=true name=com.apple.iconservices.peer.0x5e2812320 默认 runningboardd <OSLaunchdJob | handle=DCD4DC2C-32B3-4340-94F7-72C8C150F82C>: start succeeded, info=spawn failed, error=111: Invalid or missing Program/ProgramArguments 错误 runningboardd Process start failed with Error Domain=NSPOSIXErrorDomain Code=111 "Unknown error: 111" UserInfo={NSLocalizedDescription=Launchd job spawn failed} 默认 runningboardd <OSLaunchdJob | handle=DCD4DC2C-32B3-4340-94F7-72C8C150F82C>: remove failed with error 144 Requestor lacks required entitlement 错误 runningboardd Job remove after failed start failed with Error Domain=OSLaunchdErrorDomain Code=144 "Requestor lacks required entitlement" UserInfo={NSLocalizedFailureReason=Requestor lacks required entitlement} 错误 runningboardd Launch failed with Error Domain=NSPOSIXErrorDomain Code=111 "Unknown error: 111" UserInfo={NSLocalizedDescription=Launchd job spawn failed} 默认 runningboardd Executing launch request for xpcservice<com.jd.jinrong.JDJRWidget([osservice<com.apple.chronod>:2892])> (Launching extension com.jd.jinrong.JDJRWidget(BFEC114A-32BF-4A62-97F3-8B0C3FE6AB70) for host 2892) 默认 runningboardd Checking PreventLaunch: global:0 exPath:(null) predicates:(null) allow:(null) 默认 runningboardd Skipping preflight as <RBSLaunchRequest| xpcservice<com.jd.jinrong.JDJRWidget([osservice<com.apple.chronod>:2892])>; "Launching extension com.jd.jinrong.JDJRWidget(BFEC114A-32BF-4A62-97F3-8B0C3FE6AB70) for host 2892"> is not an app 默认 runningboardd Creating and launching job for: xpcservice<com.jd.jinrong.JDJRWidget([osservice<com.apple.chronod>:2892])> 默认 runningboardd <OSLaunchdJob | handle=3BD97E17-E46A-41F7-B794-520044BCD36D>: submitExtension created a job 默认 runningboardd <OSLaunchdJob | handle=3BD97E17-E46A-41F7-B794-520044BCD36D>: createInstance created a job <OSLaunchdJob | handle=3B5CA561-A268-4A5C-BAFF-819801EB4465> 默认 runningboardd <OSLaunchdJob | handle=3B5CA561-A268-4A5C-BAFF-819801EB4465>: start succeeded, info=spawn failed, error=111: Invalid or missing Program/ProgramArguments 错误 extensionkitservice RBSLaunchRequest error launching extension com.jd.jinrong.JDJRWidget error: Error Domain=RBSRequestErrorDomain Code=5 "Launch failed." UserInfo={NSLocalizedFailureReason=Launch failed., NSUnderlyingError=0xca4d04aa0 {Error Domain=NSPOSIXErrorDomain Code=111 "Unknown error: 111" UserInfo={NSLocalizedDescription=Launchd job spawn failed}}} 错误 runningboardd Process start failed with Error Domain=NSPOSIXErrorDomain Code=111 "Unknown error: 111" UserInfo={NSLocalizedDescription=Launchd job spawn failed} 默认 runningboardd <OSLaunchdJob | handle=3B5CA561-A268-4A5C-BAFF-819801EB4465>: remove failed with error 144 Requestor lacks required entitlement 错误 runningboardd Job remove after failed start failed with Error Domain=OSLaunchdErrorDomain Code=144 "Requestor lacks required entitlement" UserInfo={NSLocalizedFailureReason=Requestor lacks required entitlement} 错误 runningboardd Launch failed with Error Domain=NSPOSIXErrorDomain Code=111 "Unknown error: 111" UserInfo={NSLocalizedDescription=Launchd job spawn failed} 错误 chronod -[_EXServiceClient launchWithConfiguration:error:]_block_invoke failed with error: Error Domain=com.apple.extensionKit.errorDomain Code=2 "(null)" UserInfo={NSUnderlyingError=0xde6b31c10 {Error Domain=RBSRequestErrorDomain Code=5 "Launch failed." UserInfo={NSLocalizedFailureReason=Launch failed., NSUnderlyingError=0xde6b328e0 {Error Domain=NSPOSIXErrorDomain Code=111 "Unknown error: 111" UserInfo={NSLocalizedDescription=Launchd job spawn failed}}}}} 错误 chronod New process is nil. 错误 chronod Failed to create extensionProcess for extension 'com.jd.jinrong.JDJRWidget' error: Error Domain=com.apple.extensionKit.errorDomain Code=2 "(null)" UserInfo={NSUnderlyingError=0xde6b31c10 {Error Domain=RBSRequestErrorDomain Code=5 "Launch failed." UserInfo={NSLocalizedFailureReason=Launch failed., NSUnderlyingError=0xde6b328e0 {Error Domain=NSPOSIXErrorDomain Code=111 "Unknown error: 111" UserInfo={NSLocalizedDescription=Launchd job spawn failed}}}}}. 默认 chronod [com.jd.jinrong.JDJRWidget] Failed to launch extension with error: Error Domain=com.apple.extensionKit.errorDomain Code=2 UserInfo={NSUnderlyingError=0xde6b31c10 {Error Domain=RBSRequestErrorDomain Code=5 UserInfo={NSLocalizedFailureReason=, NSUnderlyingError=0xde6b328e0 {Error Domain=NSPOSIXErrorDomain Code=111 UserInfo={NSLocalizedDescription=}}}}}.

I am developing a productivity app called "FocusPact" using the Screen Time API (Family Controls). Current Status: The parent app bundle ID (com.hayashikento.FocusPact) has already been approved for the Family Controls (Distribution) entitlement. I have recently submitted a new request for the DeviceActivityMonitorExtension bundle ID: com.hayashikento.FocusPact.FocusPActMonitor. The Issue: Currently, the extension only works while debugging with Xcode (Development entitlement). When the device is disconnected, the intervalWillEndWarning and intervalDidEnd triggers are ignored by the system because the Extension ID lacks the Distribution entitlement. This is a critical blocker for my MVP testing phase on TestFlight, as I cannot verify the core "automatic re-blocking" logic in a real-world environment. Request: Could any Apple staff or engineers help expedite the linking of this extension ID to my existing approved entitlement? Parent App ID: com.hayashikento.FocusPact Extension ID: com.hayashikento.FocusPact.FocusPActMonitor I would greatly appreciate any guidance or assistance to resolve this so I can proceed with user testing. Thank you.

I configured my app to show a Live Activity when an alarm rings using AlarmKit. However, if I dismiss the Live Activity by tapping somewhere other than the X button, and then long-press the Dynamic Island, a new Live Activity appears that is long but contains no information. Currently, the only way I can remove this empty Live Activity is to press the X button while the alarm is in the snooze state. Pressing the X button on the initial alarm does not remove it. Is there any way to prevent this behavior or properly handle / clean up this empty Live Activity?

Our watchOS App isn't opened when tapping on a Live Activity. Added the following to our Info.plist and still get the Open on iPhone option. <key>WKSupportsLiveActivityLaunchAttributeTypes</key> <array/> Is there something else we need to configure?

Our app is using the CLLocationManager to wake up the app near an iBeacon and then tries to connect to the accessory via bluetooth and UWB. For this to work in the background we need to create a Live Activity and show the user that the app is doing something. When the app is in the foreground or just recently got into the inactivity mode this works fine and we can use CoreBluetooth/NearbyInteraction even when the app then enters the background mode. But when the app is longer in the background creating a Live Activity via Activity.request() throws an ActivityAuthorizationError.visibility. According to the documentation the LiveActivityIntent is able to workaround this background restriction but I get the same exception when I create the LiveActivity from the perform() method. Is there another API to create Live Activities? Do I need to prepare the LiveActivityIntent somehow?

Hello, I’m working on an iOS app where we have integrated ActivityKit to support Live Activities. Our app currently supports iOS 16.x and above, and we do not have an Apple Watch app or watchOS support. However, we noticed that when a Live Activity starts on the iPhone, it automatically appears on the Apple Watch as well. Since our app is not designed for Apple Watch, we would like to prevent the Live Activity UI from appearing on the watch. My questions: Is there any way to disable or prevent Live Activities from showing on Apple Watch via code? Are there any configuration options in ActivityKit or Widget configuration that can restrict Live Activities to iPhone only? Our current setup: Minimum iOS version: 16.x Using ActivityKit for Live Activities No watchOS target in the app Any guidance or recommended approach would be greatly appreciated. Thanks

I'm building out a live activity that has a button which is meant to update the content state of the Live Activity. It calls a LiveActivityIntent that runs in the app process. The push server starts my live activity and the buttons work just fine. I pass the push token back to the server for further updates and when the next update is pushed by the server the buttons no longer work. With the debugger I'm able to verify the app intent code runs and passes the updated state to the activity. However the activity never updates or re-renders. There are no logs in Xcode or Console.app that indicates what the issue could be or that the update is ignored. I have also tried adding the frequent updates key to my plist with no change. I'm updating the live activity in the LiveActivityIntent like this: public func perform() async throws -> some IntentResult { let activities = Activity<WidgetExtensionAttributes>.activities for activity in activities { let currentState = activity.content.state let currentIndex = currentState.pageIndex ?? 0 let maxIndex = max(0, currentState.items.count - 1) let newIndex: Int if forward { newIndex = min(currentIndex + 1, maxIndex) } else { newIndex = max(currentIndex - 1, 0) } var newState = currentState newState.pageIndex = newIndex await activity.update( ActivityContent( state: newState, staleDate: nil ), alertConfiguration: nil, timestamp: Date() ) } return .result() } To sum up: Push to start -> tap button on activity -> All good! Push to start -> push update -> tap button -> No good...