Hi Apple team, I'm experiencing a persistent issue with writing to UserDefaults from a widget extension on iOS. Here's the situation: I've set up an App Group: group.test.blah The main app has the correct entitlement and can read/write from UserDefaults(suiteName:) using this group successfully. I can read the value written by the app from the widget (e.g., "testFromApp": "hiFromApp"). The widget extension has the same App Group enabled under Signing & Capabilities. The provisioning profile reflects the App Group and the build installs successfully on a real device. The suite name is correct and matches across both targets. I’ve confirmed via FileManager.default.containerURL(...) that the app group container resolves properly. When I try to write from the widget extension like this let sharedDefaults = UserDefaults(suiteName: "group.test.blah") sharedDefaults?.set("hiFromWidget", forKey: "testFromWidget") ...I get this error in the console: Couldn't write values for keys ( testFromWidget ) in CFPrefsPlistSource<0x1140d2880> (Domain: group.test.blah, User: kCFPreferencesCurrentUser, ByHost: No, Container: (null), Contents Need Refresh: No): setting preferences outside an application's container requires user-preference-write or file-write-data sandbox access Questions: What could still cause the widget extension to lack write access to the app group container, even though it reads just fine? Are there any internal sandboxing nuances or timing-related issues specific to Live Activity widgets that could explain this? Is this a known limitation or platform issue?

When I use the Activity.request method to start the Dynamic Island widget, there have been continuous crash reports online, Could you please provide some ideas on how to fix this crash? Thanks! Crash backtraces: 0ActivityKitblock_copy_helper.101 (in ActivityKit)+21416 1CombinePublishers.FlatMap.Outer.receive(B.Output) (in Combine)+296 2Combineprotocol witness for Subscriber.receive(A.Input) in conformance Publishers.FlatMap<A, B>.Outer<A1> (in Combine)+20 3CombinePublishers.HandleEvents.Inner.receive(A.Output) (in Combine)+204 4Combineprotocol witness for Subscriber.receive(A.Input) in conformance Publishers.HandleEvents<A>.Inner<A1> (in Combine)+20 5CombineFilterProducer.receive(B) (in Combine)+2508 6Combineprotocol witness for Subscriber.receive(A.Input) in conformance FilterProducer<A, B, C, D, E> (in Combine)+20 7Combinepartial apply for closure #4 (C) in Publishers._Merged.request(Subscribers.Demand) (in Combine)+52 8CombinePublishers._Merged.guardedApplyDownstream<A>((C)) (in Combine)+180 9CombinePublishers._Merged.receive(A, Int) (in Combine)+400 10CombinePublishers._Merged.Side.receive(A) (in Combine)+20 11CombineJust.Inner.request(Subscribers.Demand) (in Combine)+692 12Combineprotocol witness for Subscription.request(Subscribers.Demand) in conformance Just<A>.Inner<A1> (in Combine)+20 13CombinePublishers._Merged.receive(subscription: Subscription, _: Int) (in Combine)+496 14CombinePublishers._Merged.Side.receive(subscription: Subscription) (in Combine)+20 15CombineJust.receive<A>(subscriber: A1) (in Combine)+420 16CombinePublishers.Merge.receive<A>(subscriber: A1) (in Combine)+380 17CombinePublisherBox.receive<A>(subscriber: A1) (in Combine)+104 18CombineAnyPublisher.receive<A>(subscriber: A1) (in Combine)+60 19CombinePublishers.RemoveDuplicates.receive<A>(subscriber: A1) (in Combine)+220 20CombinePublishers.HandleEvents.receive<A>(subscriber: A1) (in Combine)+300 21CombinePublisherBox.receive<A>(subscriber: A1) (in Combine)+104 22CombineAnyPublisher.receive<A>(subscriber: A1) (in Combine)+60 23CombinePublishers.FlatMap.receive<A>(subscriber: A1) (in Combine)+416 24CombinePublishers.RemoveDuplicates.receive<A>(subscriber: A1) (in Combine)+220 25CombinePublisherBox.receive<A>(subscriber: A1) (in Combine)+104 26CombineAnyPublisher.receive<A>(subscriber: A1) (in Combine)+60 27CombinePublishers.CompactMap.receive<A>(subscriber: A1) (in Combine)+440 28CombinePublisherBox.receive<A>(subscriber: A1) (in Combine)+104 29CombineAnyPublisher.receive<A>(subscriber: A1) (in Combine)+60 30CombinePublishers.SetFailureType.receive<A>(subscriber: A1) (in Combine)+420 31CombinePublishers.FlatMap.receive<A>(subscriber: A1) (in Combine)+416 32CombinePublishers.RemoveDuplicates.receive<A>(subscriber: A1) (in Combine)+220 33CombinePublisherBox.receive<A>(subscriber: A1) (in Combine)+104 34CombineAnyPublisher.receive<A>(subscriber: A1) (in Combine)+60 35CombinePublishers.CompactMap.receive<A>(subscriber: A1) (in Combine)+440 36CombinePublisherBox.receive<A>(subscriber: A1) (in Combine)+104 37CombineAnyPublisher.receive<A>(subscriber: A1) (in Combine)+60 38CombinePublishers.ReceiveOn.receive<A>(subscriber: A1) (in Combine)+660 39CombinePublisher.sink(receiveCompletion: (Subscribers.Completion<A.Failure>), receiveValue: (A.Output)) (in Combine)+316 40ActivityKitblock_copy_helper.101 (in ActivityKit)+33364 41ActivityKitblock_copy_helper.101 (in ActivityKit)+26716 42ActivityKitblock_copy_helper.101 (in ActivityKit)+53192 43ActivityKitblock_copy_helper.101 (in ActivityKit)+52408 44ActivityKitblock_destroy_helper.25 (in ActivityKit)+1140 45ActivityKitblock_destroy_helper.62 (in ActivityKit)+8220 46ActivityKitblock_destroy_helper.62 (in ActivityKit)+9364 47libswiftDispatch.dylibpartial apply for thunk for @callee_guaranteed () -> (@out A, @error @owned Error) (in libswiftDispatch.dylib)+24 48libswiftDispatch.dylibthunk for @callee_guaranteed () -> (@out A, @error @owned Error)partial apply (in libswiftDispatch.dylib)+12 49libswiftDispatch.dylibclosure #1 () in closure #1 (()) in OS_dispatch_queue._syncHelper<A>(fn: (()), execute: (), rescue: (Error)) (in libswiftDispatch.dylib)+188 50libswiftDispatch.dylibpartial apply for thunk for @callee_guaranteed () -> () (in libswiftDispatch.dylib)+24 51libswiftDispatch.dylibthunk for @escaping @callee_guaranteed () -> () (in libswiftDispatch.dylib)+24 52libdispatch.dylib__dispatch_client_callout (in libdispatch.dylib)+16 53libdispatch.dylib__dispatch_lane_barrier_sync_invoke_and_complete (in libdispatch.dylib)+52 54libswiftDispatch.dylibimplicit closure #2 (()) in implicit closure #1 (OS_dispatch_queue) in OS_dispatch_queue.asyncAndWait<A>(execute: ()) (in libswiftDispatch.dylib)+188 55libswiftDispatch.dylibpartial apply for implicit closure #2 (()) in implicit closure #1 (OS_dispatch_queue) in OS_dispatch_queue.sync<A>(execute: ()) (in libswiftDispatch.dylib)+72 56libswiftDispatch.dylibOS_dispatch_queue._syncHelper<A>(fn: (()), execute: (), rescue: (Error)) (in libswiftDispatch.dylib)+400 57libswiftDispatch.dylibOS_dispatch_queue.asyncAndWait<A>(execute: ()) (in libswiftDispatch.dylib)+136 58libswiftDispatch.dylibOS_dispatch_queue.sync<A>(execute: ()) (in libswiftDispatch.dylib)+60 59ActivityKitblock_destroy_helper.62 (in ActivityKit)+3272 60ActivityKitblock_destroy_helper.62 (in ActivityKit)+724 61ActivityKit___swift_store_extra_inhabitant_indexTm (in ActivityKit)+24928 62ActivityKit___swift_store_extra_inhabitant_indexTm (in ActivityKit)+23900 63 XXXApp static LiveActivityService.request() ......

When using the ManagedSettings API to block apps everything is blocked as expected (the app itself, Notifications, Live Activities on the Lock Screen etc) except for Compact Live Activities of those apps (that are shown in the Dynamic Island). I feel the expected behavior would be to block also the Compact Live Activities. Our use case: In Spoilerblock we want to prevent users from being exposed to spoilers before they've had time to watch for example a sports game. Current workaround: Right now the best we can do is to ask the user to disable Live Activities for apps that could expose results, to not risk being exposed to a spoiler.

I'm developing an app which will show the driver ETA and rendering the progress bar of the current ETA. Intuitively the backend server sends the push notification every 3 seconds through firebase cloud message service to APNS so that the device can refresh the dynamic island smoothly. But the live activity doesn't refresh as frequently as the backend service does. It should refresh every 3 seconds but it turns out like refresh 30 ~ 60 seconds, sometimes it didn't refresh at all. any body facing the same?

I'm developing an app which will show the driver ETA and rendering the progress bar of the current ETA. Intuitively the backend server sends the push notification every 3 seconds through firebase cloud message service to APNS so that the device can refresh the dynamic island smoothly. But the live activity doesn't refresh as frequently as the backend service does. It should refresh every 3 seconds but it turns out like refresh 30 ~ 60 seconds, sometimes it didn't refresh at all. any body facing the same?

The docs are conflicting. https://developer.apple.com/documentation/activitykit/starting-and-updating-live-activities-with-activitykit-push-notifications#End-the-Live-Activity-with-a-custom-dismissal-date says: When you end a Live Activity, by default the Live Activity appears on the Lock Screen for up to four hours after it ends to allow people to glance at their phone to refer to the latest information. However here it says: https://developer.apple.com/documentation/activitykit/displaying-live-data-with-live-activities#Understand-constraints A Live Activity can be active for up to eight hours unless its app or a person ends it before this limit. After the eight-hour limit, the system automatically ends the Live Activity, and immediately removes it from the Dynamic Island. However, the Live Activity remains on the Lock Screen until a person removes it or for up to four additional hours before the system removes it — whichever comes first. As a result, a Live Activity remains on the Lock Screen for a maximum of 12 hours. So is it 4 hrs OR '8 for Dynamic Island vs 12 for Lock Screen'?

Hey there, i start a live activity with notification , and but sometime it can not update, it happens sometime and make me so confuse; like about 2025-08-19 +8.0 09:20:52 updatetoken : 40ead3fd4dd4a934548c5455c645fc6920edfaa0ddad98abd619dc1d2662389c15d3dc3b420bdec733d9438d25ae61cb55601ae64292b3064a71ffb8d0355633f3f0f2254e6f7438282ce83366d8430c app can not accept push update msg, and APNs has show success when server send update msg to APP; how can i check the APNS to APP? Thanks

LiveActivity using colorScheme to adapt to dark mode in iOS 26 system does not work The system keeps returning. mark, unable to switch

I'm struggling to understand what the impact of this flag is. Docs only say: For devices running iOS 18 and iPadOS 18 or later, you can add input-push-token: 1 to your payload to start a Live Activity and receive a new push token. After you receive a new push token, you can use it to send updates to a Live Activity. But things were working fine for iOS 17. Right? Does it somehow make the OS emit update tokens faster/more successfully? Should I include in all start, update, end events?

Hi, I'm having this issue that I have have not been able to figure out as I've gone through a checklist and it seems I have everything in place, but im sending my pushToStartTokenUpdates token to a server and im able to test starting a live activity via CURL where it shows my push token going through and even my test payload but after a while I get this issue in my logs where it fails to find a live activity Push notifications are set up, im sending my token to APN and im even able to start live activities locally.

Does the alert only serve the following purposes: required for start events require for any event that needs to alert the user (with sound or having the live activity show in expanded presentation) while its content DO NOT matter. Only the presence of the field and its attributes matter. The only time its content matter are when the receiving device is an Apple Watch. Is that correct?

When sending multiple push to start notifications to start a live activities in a short time frame, after around 10 pushes live activities are no longer being started. Device logs show the following entry: Push-to-start budget exceeded for com.att.tlv.myatt::pushToStart; not starting activity What can be done to be able to open more live activities via push-to-start in a short time frame (increase the push-to-start budget)? Can this be related to the development environment and it will not happen on production? NSSupportsLiveActivitiesFrequentUpdates is already set to YES

When running application after installation I get a value in pushTokenUpdates and also the call to pushToStartTokenUpdates returns with the token value. But, if I kill the app and restart it again, there is no value in pushTokenUpdates and the call to pushToStartTokenUpdates does not return. Am I suppose to use the push to start token from the previous application run? is there a different solution?

After opening 5 live activities using live activity push-to-start push notifications, I clear them from lock screen. From this point forward I am unable to open new live activities. Device log shows: Could not create a new activity from push notification: ActivityKit.ActivityAuthorizationError.targetMaximumExceeded How can I handle such use case? shouldn't the count of opened live activities be reduced once the user clears the live activities? is this a bug?

On earlier iOS versions Live Activity displays correctly according to mode set.  Can't find an opened issue for that version: iOS 26 device: iPhone 16

While the activityBackgroundTint modifier is intended to set the background color of a Live Activity, it often fails to dynamically update, leaving the activity with an incorrect background. Replacing it with ZStack { Color(.background) .... } solves the problem, but this is a workaround. The activityBackgroundTint modifier is still needed, at a minimum, so that the "Allow Live Activity for the app" extension does not have the default color.

My start live activity CURL is not starting my live activity and I keep getting a decoding failure even though my curl matches my content state so my live activity is not starting. heres my CURL --header "apns-topic: MuscleMemory.KimchiLabs.com.push-type.liveactivity" \ --header "apns-push-type: liveactivity" \ --header "apns-priority: 10" \ --header "authorization: bearer eyJhbGciOiJFUzI1NiIsImtpZCI6IjI4MjVTNjNEV0IifQ.eyJpc3MiOiJMOTZYUlBCSzQ2IiwiaWF0IjoxNzU3NDYwMzQ2fQ.5TGvDRk5ZYLsvncjKwXIZYN78X88v5lCwX4fRvfl1QXjwv8tOtO2uoId27LQahXA3zqjruu_2YoOfqEtrppKXQ" \ --data '{ "aps": { "timestamp": '"$(date +%s)"', "event": "start", "content-state": { "plain_text": "hello world", "userContentPage": ["hello world"] }, "alert": { "sound": "chime.aiff" } }, "attributes-type": "KimchiKit.DynamicRepAttributes", "attributes": {} }' \ --http2 https://api.sandbox.push.apple.com/3/device/802fe7b4066e26b51ede7188a7077a9603507a0fa6ee8ffda946a864e75aa139602861538d6fb12100afbe9a3338d6c7c799d947dfacb2ee835f0339ecdc3165c9ed7e54839f5a3b89b76a011f5826cc and here is my content state public struct ContentState: Codable, Hashable { public var plainText: String public var userContentPage: [String] public enum CodingKeys: String, CodingKey { case plainText = "plain_text" case userContentPage } public init(plainText: String, userContentPage: [String]) { self.plainText = plainText self.userContentPage = userContentPage } } public init() {} }

A Live Activity relies on its app being in the background , but contrary to a widget it does not have a timeline. Our app "in the making" is sandboxed and does not need to receive ActivityKit push notifications How is the app "maintained in life" and not entirely killed for the duration of the activity - Apple documentation says up to 8 hours ? Is it necessary for us to do something to maintain it, like to trick the system , play a white noise audio background ...?

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.

Regular apns will give you a willPresent callback and there you can decide to suppress showing the notification or suppress its sound etc. I know the iOS app will give you callbacks for when there's a contentUpdate, yet that doesn't give the option to change the sound. Is there a way to suppress sound of a received Live Activity when app is in foreground?