On iOS 27.2, triggering RunSystemShortcutIntent from a Home Screen widget leaves all buttons in that widget unresponsive when the action does not navigate away from the current screen. Toggling the flashlight is a simple example. Steps to reproduce Add an interactive Home Screen widget with a button that uses RunSystemShortcutIntent. Trigger an action that stays on the current screen, such as toggling the flashlight. Try tapping the same button and other buttons in the affected widget. None respond. Swipe to another Home Screen page, then swipe back. The buttons respond again. Expected behavior Once the action finishes, the widget should remain responsive to subsequent taps without requiring the user to navigate away and return. Impact Based on my observations, this issue affects all apps that provide interactive widgets when the reproduction conditions above are met. A single routine system shortcut action leaves every button in the affected widget unresponsive, making important features effectively unavailable. For products built around interactive widgets, this blocks core functionality until the user switches Home Screen pages and returns. I have submitted this through Feedback Assistant: FB25377135. Given the impact on all apps that provide interactive widgets under these conditions, please prioritize investigation and a fix. Has anyone else reproduced this behavior on iOS 27.2? A consistent distinguishing symptom is that simply swiping to another Home Screen page and back restores responsiveness to all buttons in the affected widget.

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?

Environment: iPhone 12 Pro Max, iOS 26.6.1 (23G83), App Store build. The Live Activity is started in-app with pushType: .token and updated over APNs (production). What happens: An update push arrives and is applied, but the Lock Screen keeps the previous content with a system spinner over it. The sysdiagnose shows the system launching our WidgetKit extension to render the new state, and the kernel killing it at its memory limit about 0.5 s later, three times in a row: liveactivitiesd [activitykit:outputParticipant] Activity updated: <activity id> runningboardd [<WidgetExtension>:24466] Memory Limits: active 30 inactive 30 kernel memorystatus: <WidgetExtension> [24466] exceeded mem limit: ActiveHard 30 MB (fatal) chronod [chrono:activity.store] Reload failed; next attempt due at … New state: failedThe retry about 10 minutes later failed the same way. The device had plenty of free memory; only the per-process limit was hit. A render of the previous state two hours earlier, in an extension process that was already running, succeeded. ReportCrash then discards the report, so we got no crash log and no MetricKit diagnostic: ReportCrash (OSAnalytics) report not saved because it is non-actionable (ie: extension hangs or internal-only) ReportCrash no MetricKit for process <WidgetExtension> type 385The extension links a crash-reporting SDK (12 dynamic frameworks) that is configured at launch. We suspect it but haven't confirmed it yet.

I'm building an App, that is drawing power values in the Dynamic Island area. So the primary indicator is a circle presenting the charge. I've noticed the first issue with this in the landscape orientation, that it then gets clipped by the camera. So I've moved it a few pixels up, which also makes it look really snug with equal distance to the upper outline of the layout. However this then causes issues, when my app gets pushed into the minimal detached position. This is the same view and I can't seem to differentiate, which is which. So either I offset the camera and clip in the detached island or i render perfectly there and clip the camera. iOS 27 added isDynamicIslandLimitedInWidth, which sounds like the right indicator, but what's there before? I've tried measuring the area to get any indication, but it's equal in all regards. Did anyone solve this?

Hi everyone, I’m developing an iOS app and would like to know if it’s possible to dynamically show or hide a widget in the iOS Widget Gallery based on the user’s login status in the app. For example: When a user logs in to the app, the widget should appear in the Widget Gallery. When the user logs out, the widget should be hidden or removed from the Widget Gallery. Is this behavior supported by iOS? Can an app dynamically control the visibility or availability of its widget in the Widget Gallery based on the user’s authentication status? If this is not directly supported, is there an alternative or recommended approach using WidgetKit? Since my app has multiple widgets, some of them specifically require users to log in before they can be used. That’s why I wanted to implement this kind of behavior. Any guidance or suggestions would be appreciated. Thank you!

After updating an internal test app through TestFlight, newly started Live Activities sometimes fail to render. Activity.request succeeds, but the Dynamic Island shows an empty tappable area and the Lock Screen shows no Live Activity. Rebooting the device restores rendering. Is there a supported way to recover from this state without asking the user to reboot? Configuration Device: iPhone18,1 OS for the captured reproduction: iOS 27.0.1 (24A446) Distribution: TestFlight, internal testers only. This app bundle is not published on the App Store. We have reproduced the issue with builds made using both Xcode 26 and Xcode 27. Deployment target: iOS 17.0 The widget extension contains an ActivityConfiguration for Live Activities only, with no Home Screen widgets. Our QA team also reported similar symptoms after app updates on iOS 17.4.1 (iPhone 15 Pro Max) and iOS 26.5 (iPhone 11). We do not have diagnostic logs from those devices, so we cannot confirm that they have the same underlying cause. Bundle identifiers below have been consistently replaced with com.example.internalapp and com.example.internalapp.widgets for this public post. Steps to reproduce Install a build of the app containing the Live Activity widget extension. Update to a newer build through TestFlight. After the update completes, launch the app and start a Live Activity using Activity.request(attributes:content:pushType: nil). Check the Dynamic Island and Lock Screen. This is intermittent: it has happened after several app updates, but not every update. In the captured reproduction, the activity was started about two minutes after installation completed. Expected and observed behavior We expect the Live Activity to render on the Dynamic Island and Lock Screen, with taps opening the app through its widgetURL. Instead: Activity.request succeeds and liveactivitiesd starts the activity. The Dynamic Island has an empty tappable area and the Lock Screen shows nothing. Tapping the empty area opens the app without the activity's widgetURL. Updating the activity's content does not restore rendering. After rebooting, newly started Live Activities render normally. QA has also seen rendering recover after an undetermined wait without rebooting. Relevant diagnostic observations The following is an abbreviated, redacted excerpt from a locally collected sysdiagnose. Times are JST (UTC+09:00), on 2026-10-18. Ellipses indicate omitted fields; the activity identifier has also been redacted. During installation, runningboardd records a RBSPreventLaunchLimitation covering the app and its extensions. While installation is still in progress, chronod ignores the widget extension: 22:38:45.295 runningboardd ... RBSPreventLaunchLimitation ... ... com.example.internalapp.widgets ... com.example.internalapp ... 22:38:45.549 chronod [com.apple.chrono:extensions] Ignoring restricted or unknown extension com.example.internalapp.widgets 22:38:47.178 installcoordinationd -[IXSCoordinatedAppInstall setComplete:] ... com.example.internalapp ... complete! 22:38:47.292 chronod [com.apple.appinstallation:TransactionLog] com.example.internalapp ... applicationsDidInstall When a Live Activity is started later, chronod repeatedly reports zero extensions for the app's container: 22:40:41.221 liveactivitiesd [com.apple.activitykit:activityManager] Starting activity: id: <activity-id>; ... state: active ... 22:40:41.254 chronod [com.apple.chrono:descriptor] Reloading descriptors for 0 extensions in container com.example.internalapp with reason: activityRendererInitiated 22:40:53.543 chronod [com.apple.chrono:descriptor] Reloading descriptors for 0 extensions in container com.example.internalapp with reason: activityRendererInitiated 22:40:55.707 chronod [com.apple.chrono:descriptor] Reloading descriptors for 0 extensions in container com.example.internalapp with reason: reload descriptors requested by client The installation logs also show the widget extension's provisioning profile being found and its data container being created. These observations suggest that extension discovery may not have recovered after the installation restriction was lifted, but we have not established the root cause. We noticed a potentially related watchOS WidgetKit report referencing FB24619522. Its author reported that their issue was resolved with watchOS 27.0 / iOS 27.0; we do not know whether our Live Activity issue is related. Questions Is there a supported API or recovery procedure that makes the system rediscover the Live Activity extension after an app update? Are there known TestFlight installation or extension configuration conditions that could explain this sequence? Which additional ActivityKit/WidgetKit diagnostics would help distinguish an app configuration issue from a system extension discovery issue? The full sysdiagnose is being kept out of this public post because it contains device and account diagnostics.

I am encountering an issue where the Lock Screen Quick Action fails to visibly open my app. My app is a camera application that utilizes a CameraCaptureIntent to launch a standalone, lightweight camera view (accessible while the device is locked), distinct from the main application. Steps to Reproduce: Open the lightweight camera view using the Lock Screen Quick Action. From this view, launch the Main App. Lock the iPhone (put it to sleep). Attempt to launch the lightweight camera view via the Quick Action again. A slight animation occurs, but the camera view does not appear on screen. After multiple tests, it seems the view is actually launching but remains in an "invisible state." I suspect that the system hides the lightweight camera view when transitioning to the Main App, but fails to reset this hidden state when the Quick Action is triggered subsequently. I would appreciate any guidance on a potential workaround or confirmation if this is a known issue awaiting a system update.

I am working on a live activity showing realtime NYC subway arrival countdowns at a station. As trains arrive I want to remove them from the live activity so that only inbound trains are displayed. As I understand it this will require a broadcast push notification every time a train arrives, but this is incredibly inefficient (and will likely be throttled) as trains can arrive many times per minute at a busy station. MTA data includes approximately 90 minutes of train arrivals. Is there no way to create a live activity timeline the way widgets can update at planned intervals? The only viable option I've found is keeping the entire app alive in the background to update the live activity when required by registering for background location updates, but this seems like an unfriendly solution.

Environment: iOS Version: iOS 27.0 Framework: ActivityKit Xcode Version: Xcode 26.1 Issue Description: In iOS 27, Live Activities fail to adapt to the system colorScheme. Regardless of whether the system theme is set to Light or Dark mode, @Environment(.colorScheme) inside the Live Activity view always returns .dark. This behavior worked as expected on iOS 26, where the Live Activity correctly responded to light/dark mode changes and rendered the appropriate theme. Expected Behavior: The Live Activity view should respect the system's current colorScheme (returning .light when the system is in Light Mode) on iOS 27, consistent with the behavior on iOS 26. Actual Behavior: The Live Activity view strictly defaults to .dark mode on iOS 27, even when the device is explicitly set to Light Mode. struct LockScreenView<T: BaseLiveActivityAttributes>: View { let context: ActivityViewContext<T> @Environment(\.colorScheme) var colorScheme var isLight: Bool { colorScheme == .light } var body: some View { Color(isLight ? .white : .black) .overlay(alignment: .topTrailing) { VStack(alignment: .trailing, spacing: 2) { Text("colorScheme: \(String(describing: colorScheme))") } .font(.system(size: 9, weight: .bold, design: .monospaced)) .foregroundColor(.yellow) .padding(4) .background(Color.black.opacity(0.6)) .cornerRadius(4) .padding(.trailing, 8) .padding(.top, 4) } } } Any insights or workarounds would be greatly appreciated. Thanks!

Is there a supported way to schedule a Live Activity update on the device for a known future date, so the system applies it while the app is suspended? It should update on the Lock Screen when the phone is locked, and in the Dynamic Island when the user is in another app, ideally with an alert. Local notifications can be scheduled for an exact date, but I haven't found an equivalent for Live Activities. My use case is a rest timer in a workout app that keeps all data on the device, with no server. When a rest starts, the app knows when it ends, and at that moment the Live Activity should show the next set and the time since the rest ended. Today the app schedules a local notification for the alert and sets the Live Activity's stale date to the rest's end. That has some problems: The stale date is applied a minute or two late in my testing, so the Live Activity shows 0:00 after the notification has already arrived. Updating from the app only works while it's running, which in practice means during a workout mirrored from Apple Watch. Even then, an alert sent with the update while the phone was locked appeared about a minute late, so the Live Activity never alerts. Push updates need a server, which this app doesn't have by design. A scheduled Live Activity start (iOS 26) creates a second activity instead of updating the existing one. Am I missing an API or a pattern for this? I've filed FB25210471 asking for it in case there isn't one.

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.

AccessoryLiveActivities: session.liveActivities is always empty and activityUpdated is never called Hi Apple, I'm implementing an accessory using AccessorySetupKit, AccessoryTransportExtension, AccessoryNotifications, and AccessoryLiveActivities. My notification forwarding implementation works correctly, but Live Activity forwarding does not deliver any Live Activity to the Data Provider extension. Environment iOS 26.6 Xcode 26.6 iPhone Bluetooth accessory AccessorySetupKit AccessoryTransportExtension AccessoryNotifications AccessoryLiveActivities The final signed Data Provider extension contains the required: <key>com.apple.developer.accessory-data-provider</key> <true/> The Data Provider extension's Info.plist contains: AccessoryNotifications.NotificationsForwarding and AccessoryLiveActivities.LiveActivityForwarding. My Data Provider is: @main struct DataProvider: AccessoryDataProvider { var extensionPoint: AppExtensionPoint { Identifier("com.apple.accessory-data-provider") Implementing { NotificationsForwarding { NotificationHandler() } LiveActivityForwarding { LiveActivitiesHandler() } } } } Notification Forwarding works correctly The Notification Forwarding side is working end-to-end. The notification lifecycle callbacks are actually delivered to the extension: func addNotification(_ notification: AccessoryNotification) func removeNotification(_ notification: AccessoryNotification) So the Data Provider extension itself is loading correctly, and the Notification Forwarding session is receiving notification lifecycle events normally. Live Activity Forwarding The Live Activity forwarding handler is also created and activated successfully. I see: LiveActivityForwarding factory ↓ LiveActivitiesHandler init ↓ activate(for:) However, session.liveActivities is always empty: liveActivities = [] Existing Live Activity test I tested with a Live Activity that was already active and visible on the iPhone before launching my companion app. The existing Live Activity is not present in session.liveActivities. New Live Activity test I also tested the opposite order. The forwarding session is already active: activate(for:) Then I start a new Live Activity from another app. The Live Activity appears normally on the iPhone, but: activityUpdated(_:) is never called. And: activityUpdatedForAlert(_:) is also never called. The observed behavior is consistently: LiveActivityForwarding factory ✅ LiveActivitiesHandler init ✅ activate(for:) ✅ session.liveActivities [] Start Live Activity ✅ Live Activity visible on iPhone ✅ activityUpdated(_:) ❌ activityUpdatedForAlert(_:) ❌ Question Why does session.liveActivities remain empty even when there is an active Live Activity on the iPhone? And when a new Live Activity is started while the LiveActivityForwarding session is already active, why are activityUpdated(_:) and activityUpdatedForAlert(_:) never called? Thanks!

Hi, Our iOS airline app already provides its own Live Activity for flight tracking. We are currently adopting Apple's semantic boarding pass for our Wallet boarding passes. According to Apple's documentation, to automatically suppress the Wallet-based Live Activity, we should add our App Store Identifier (Adam ID) to the associatedStoreIdentifiers array in pass.json. We have configured this as follows: "associatedStoreIdentifiers": [ "<OUR_APP_STORE_ID>" ] However, we are still seeing the Flight Tracker / Wallet-based Live Activity option for the flight after adding the semantic boarding pass to Wallet. Has anyone experienced this behavior? Specifically: Is associatedStoreIdentifiers expected to completely suppress the Wallet-generated Live Activity? Does it suppress only the automatically generated Live Activity, while the Flight Tracker functionality remains available in the semantic boarding pass? Are there any additional requirements or specific pass.json configurations needed? Does the pass need to be removed and re-added to Wallet after adding associatedStoreIdentifiers? Is this behavior different between iOS versions? Our objective is to prevent duplicate flight-tracking Live Activities because our application already provides its own Live Activity for the same flight. Any clarification or guidance would be appreciated. Thanks!

Hello, I'm developing an iPhone alarm app with AlarmKit. The alert's secondary "Snooze" button uses secondaryButtonBehavior: .custom. Its secondaryIntent is a LiveActivityIntent with supportedModes: .background and authenticationPolicy: .alwaysAllowed. In perform(), the app saves an in-progress record, schedules a new fixed alarm with AlarmManager.shared.schedule(id:configuration:), cancels the original alarm only after scheduling succeeds, and then saves completion. If something fails partway, the original alarm may remain, with or without the newly scheduled one. Simplified configuration (not a standalone sample): let presentation = AlarmPresentation( alert: AlarmPresentation.Alert( title: "Alarm", secondaryButton: AlarmButton( text: "Snooze", textColor: .white, systemImageName: "repeat"), secondaryButtonBehavior: .custom)) let attributes = AlarmAttributes<ExampleMetadata>( presentation: presentation, tintColor: .indigo) let configuration = AlarmManager.AlarmConfiguration( schedule: .fixed(fireDate), attributes: attributes, stopIntent: StopIntent(id: alarmID), secondaryIntent: SnoozeIntent(id: alarmID), sound: .named(soundName)) What we observed We deliberately injected an app-side error inside the intent, using two different test apps on a spare iPad: Observations 1 and 2: a small standalone AlarmKit probe app (iPadOS 26.2.1, default alarm sound). It does not use our app's core logic. Observation 3: a separate validation app that uses our app's core logic (iPadOS 26.7, bundled alarm sound). Each condition was observed only once, so these are not reproducible causal claims. Error before scheduling the new alarm (probe app, device locked): The original alarm kept sounding, and snooze could be tapped again. We recorded several intent entries after the first error, but we can't tell which were user taps and which were system redeliveries. The alarm read as .alerting until the system Stop control was used. Error after the new alarm was scheduled successfully (probe app): The original kept sounding for about 15 seconds until system Stop. The new alarm remained and fired at its scheduled time about three minutes later. Error before scheduling (validation app, device unlocked with the app in the foreground): The alert appeared as a compact banner. After the failed snooze, the app was terminated and relaunched as part of the test procedure, and a test-only control allowed one retry. After that, the banner controls were no longer available, and reads over the next few minutes still reported the original as .alerting. About two hours later, cancelling it with the app's OFF action succeeded. We can't separate the effects of the intent failure, foreground presentation, relaunch, and test-only retry. About hardware buttons: I understand from the AlarmKit FAQ that a physical button stops the currently alerting alarm and that stopIntent is called on dismissal. In observation 3, a volume button was pressed after the banner controls were gone, and audio was no longer heard. Our logs did not capture a stop-intent execution, though that doesn't prove it wasn't invoked. I'm not asking about the general hardware-button behavior. My question is only whether that guidance also applies to an alarm in the state left by a failed custom intent (question 3 below). Questions When a custom secondary LiveActivityIntent.perform() throws, what behavior should an app expect for the original alarm's state and alert presentation? Are there documented limitations or differences between the locked and foreground (banner) presentations? What's the recommended way to report an unsuccessful snooze? Should the intent propagate the error, or catch it and return .result() while tracking the failure in the app? If the original stays .alerting, is invoking the same secondary intent again for the same alarm ID supported, and what concurrency or redelivery assumptions should the app avoid? If an alarm reads as .alerting but has no visible controls or audio after such a failure, which public APIs or user actions are recommended for recovery? Does the FAQ's physical-button and stopIntent guidance still apply in that state? How should an app choose among stop(id:), cancel(id:), or a new schedule without cancelling a valid future alarm? I've read the AlarmKit documentation and the AlarmKit FAQ (https://developer.apple.com/forums/thread/797158), but couldn't find guidance on this failure case. Any advice is appreciated. Thank you!

New faces I added in the iPhone Watch app showed up in My Faces but didn't reach my Apple Watch. Restarting both devices didn't help. The iPhone's logs showed the watch-face library was stuck in an automatic "reset sync" (not the Reset Sync Data button). With 65 watch apps installed, the reset was too big, hit the limit of 1000 messages per 5 minutes and failed, so new faces queued up behind it. One face took almost three hours to reach the watch. What worked for a while was removing the 7 watch apps with the most complications (I also pressed Reset Sync Data, so I'm not sure which did it). The reset dropped from 1946 to 927 messages and went through, and the stuck faces showed up the next time I added a face. About 90 minutes later a 939-message reset failed again, just over the limit counting the ~65 color-sync messages. To see if you're affected, stream your iPhone in Console.app on a Mac, add a face, and search for "requesting reset sync". I also filed FB25000090 because two queued Photos faces lost their photos when the reset went through. If you see it too, please file with sysdiagnoses from both devices (developer.apple.com/bug-reporting/profiles-and-logs) and mention FB25000073. iPhone 18 Pro on iOS 27.2 beta (24B5089g), Apple Watch Ultra 3 on watchOS 27.2 beta (24S5091f). Same on the public 27.0 release.

Filed as FB24619522 — sysdiagnoses from both devices and the live logs are attached to the report. We ship WidgetKit complications, and on the watchOS 27 betas (24R5360a, paired with iOS 27 24A5430a) they die every time the app gets updated while they're on the active face. Within seconds they turn into empty placeholders and never come back on their own — opening the app, switching faces or reloading timelines from the app does nothing. The watch logs show the extension being killed during the install (normal), and after that watchOS simply can't launch the new copy any more: runningboardd: <OSLaunchdJob | handle=…>: start succeeded, info=spawn failed, error=111: Invalid or missing Program/ProgramArguments chronod(ChronoKit): Reload failed; 0 retries remaining: … "Unknown extension process" Only two things fix it, and both restart chronod: rebooting the watch, or switching the watch language and back (iPhone › Watch app › General › Language & Region, then give it a couple of minutes). Our second extension in the same bundle, which wasn't running during the install, came back fine — so this looks like an OS bug rather than something we can work around in code. iOS 27 widgets seem to have the same problem (this thread, and iPhone in Canada wrote it up on beta 4), and someone posted the identical log lines back in March. FB24619522 — the full story, both sysdiagnoses and the live logs are in the Feedback.

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!

Hi, Problem I have a widget which displays a bright red. When I display the same view inside the app, the red is bright. However when I use the same view on the widget, the color looks a bit dull. Note: Widget Style: Default (Always) It is the same dull red when in focus and when not in focus This happens on iOS (device and simulator) and macOS Questions How can I fix it on the widget? Does widget support Display P3 colors? Any help on this would be much appreciated.

我们基于 ActivityKit Push-to-Start 实现远程推送创建 iOS 实时活动，当前遇到异常问题： 预期逻辑 Push-to-Start 推送到来、主 App 不在进程时，系统收到创建推送会后台拉起主 App；我们在 App 被拉起的时机，获取本次实时活动对应的updateToken并上报服务端，服务端拿到 token 后，才能持续推送更新该实时活动。 2. 异常现象（部分iOS27设备偶现） 设备成功收到 Push-to-Start 推送，实时活动正常创建并在锁屏 / 灵动岛展示；但埋点统计证实：系统没有在活动创建的同时后台启动主 App。 3. 带来的后果 因为主 App 未被唤醒，获取updateToken并上报的代码逻辑不会执行；服务端拿不到本次活动实例的更新 token，该实时活动创建成功后，无法接收后续状态更新推送。 我们想知道，为什么部分iOS27设备会偶现系统收到实时活动的创建推送，但是没有启动主APP的情况，我们可以采取什么措施避免这个问题

I have several Live Activities running concurrently for different trips in a delivery app (same app, multiple active Live Activities, each with its own activity ID). I update relevance-score via ActivityKit push notifications at each status change: Trip picked up → 20 route to destination → 40 Arrived at destination → 60 Delivery delayed → 80 Confirmed → 100 (sent with "event": "end") Per Displaying live data with Live Activities, "the relevanceScore also determines the order of your Live Activities on the Lock Screen." However, when the Confirmed Live Activity is sent with "event": "end" and "relevance-score": 100, it does not move to the top of the Lock Screen stack, even though other still-active trips have lower relevance scores (20–80). Questions: Does relevanceScore only apply to ordering among currently active Live Activities, and get ignored (or treated differently) once a Live Activity has ended? Is there a separate/implicit ordering rule for ended Live Activities during their dismissal window (e.g., always sorted below active ones, or sorted by end time instead of relevanceScore)? Is there a recommended pattern for making a Live Activity appear prominently right as it ends — e.g., sending a high relevanceScore via update first, then a separate end shortly after? This isn't documented explicitly in either the "Configure the Live Activity" or "End the Live Activity" sections, so I wanted to confirm the intended behavior rather than rely on trial and error.