We have some AppIntents we are POCing and when we make a Release build, they no longer appear in the system. These AppIntents live in a Framework compiled and linked with the core app. We believe that this is related to Mergable Libraries. We have confirmed that the meta data for the framework still contains a list of all of the actions and their mangled symbols. The mangled symbols however now live in the app binary (confirmed by building Release with DEBUG_INFORMATION_FORMAT = dwarf) If we move the AppIntent code into the app target, things once again work as expected. Is there a flag we need to set, or is moving the code into the app target the only workaround? Thank you!

https://communities.apple.com/fr/thread/256121053

When does alarmkit's alarm displayed in Live activity? I think it is very random. is there any condition for this?

I currently test AlarmKit's API with my project. But I find that AlarmKit API presents its UI inconsistently. When i turn off my device and re-install my application, it presents its alarm in Live activity, but sometimes doesn't. Is there any rules to present Alarm UI?

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'?

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?

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?

I am currently developing an interactive widget, but an AppIntent issue blocked me for 2 days. I have an AppIntent named TimerActionIntent, which has two parameters: TimerType and TimerAction. Here is the code: import AppIntents enum TimerType: Int, CaseIterable, AppEnum, AppEntity { case sleep case feeding static let typeDisplayRepresentation: TypeDisplayRepresentation = "Timer Type" static let caseDisplayRepresentations: [TimerType : DisplayRepresentation] = [ .sleep: "Sleep", .feeding: "Feeding" ] } enum TimerAction: Int, CaseIterable, AppEnum, AppEntity { case start case pause case stop static let typeDisplayRepresentation: TypeDisplayRepresentation = "Timer Action" static let caseDisplayRepresentations: [TimerAction : DisplayRepresentation] = [ .start: "Start", .pause: "Pause", .stop: "Stop" ] } struct TimerActionIntent: AppIntent { static let title: LocalizedStringResource = "Operate a Log Timer" @Parameter(title: "Timer", default: .sleep) var timerType: TimerType @Parameter(title: "Action", default: .start) var action: TimerAction static var isDiscoverable: Bool = false static var openAppWhenRun: Bool = false init() {} init(timerType: TimerType, action: TimerAction) { self.timerType = timerType self.action = action } func perform() async throws -> some IntentResult { // perform the action Self.openAppWhenRun = state == .stopped } return .result() } } I can't execute the AppIntent if using the following code: Button(intent: TimerActionIntent(timerType: .sleep, action: .start)) { // button view } // or let intent = TimerActionIntent() intent.timerType = timerType intent.action = .start Button(intent: intent) { // button view } and only execute when initialize TimerActionIntent without any parameters and @Parameter has the default value. e.g. Button(intent: TimerActionIntent()) { // button view } I have some logs in the Console app: default 17:51:27.626382+0800 linkd Accepting XPC connection from PID 39255 for service "com.apple.linkd.registry" default 17:51:27.637511+0800 WidgetsExtension Beginning PerformAction <<SB:788D850BBBC5>> default 17:51:27.637540+0800 WidgetsExtension Beginning InitializeAction <<SB:ACBC7A27CCBF>> default 17:51:27.637556+0800 WidgetsExtension [InitializeAction <<N:ACBC7A27CCBF>>] Found TimerActionIntent matching TimerActionIntent registered with AppManager default 17:51:27.637725+0800 WidgetsExtension Prepared timerType to TimerType(TimerType/0)) default 17:51:27.637744+0800 WidgetsExtension Prepared action to TimerAction(TimerAction/0)) default 17:51:27.637772+0800 WidgetsExtension Ending InitializeAction <<SE:ACBC7A27CCBF>> default 17:51:27.637795+0800 WidgetsExtension Beginning ResolveParameters <<SB:6C7CA02308AD>> default 17:51:27.639807+0800 WidgetsExtension Building resolver for parameter timerType<TimerType> = TimerType/0 default 17:51:27.640160+0800 WidgetsExtension Building resolver: EntityIdentifier → TimerType:TimerActionIntent:timerType default 17:51:27.640202+0800 WidgetsExtension Ending ResolveParameters <<SE:6C7CA02308AD>> default 17:51:27.640221+0800 WidgetsExtension Beginning NeedsDisambiguation <<SB:8E482F9CCCB0>> default 17:51:27.641328+0800 WidgetsExtension Ending NeedsDisambiguation <<SE:8E482F9CCCB0>> default 17:51:27.641344+0800 WidgetsExtension Ending PerformAction <<SE:788D850BBBC5>> error 17:51:27.642316+0800 chronod Perform action connection operation completed with error: Error Domain=LNActionExecutorErrorDomain Code=2010 "(null)" error 17:51:27.642774+0800 chronod Operation `<LNPerformActionConnectionOperation: 0x600002c4a180, identifier: F8FB77C5-7F8A-4670-BB8C-465DE4EAB6B8>` error Error Domain=LNActionExecutorErrorDomain Code=2010 "(null)" default 17:51:27.643358+0800 linkd Invalidated XPC connection from PID 39255 for service "com.apple.linkd.registry" I can't find any details about the error " Error Domain=LNActionExecutorErrorDomain Code=2010 "(null)"" The environment: Xcode: 16.4/26 beta 5 iOS: iOS Simulator 18.5, iOS Simulator 26, iPhone 16 Pro Max 18.6 macOS 15.6 Can anyone help me, please!

I cannot install any widgets on my simulator, even the system provided ones. I just finished removing all dev software from my machine and reinstalling only Xcode 16.3. Springboard always crashes: Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Subtype: KERN_INVALID_ADDRESS at 0xfffffffffffffff8 Exception Codes: 0x0000000000000001, 0xfffffffffffffff8 VM Region Info: 0xfffffffffffffff8 is not in any region. REGION TYPE START - END [ VSIZE] PRT/MAX SHRMOD REGION DETAIL UNUSED SPACE AT START ---> UNUSED SPACE AT END Termination Reason: SIGNAL 11 Segmentation fault: 11 Terminating Process: exc handler [5015] Triggered by Thread: 0 Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 SpringBoardHome 0x10f0f8e50 -[SBHRippleSimulation clear] + 74 1 SpringBoardHome 0x10f0f8f0f -[SBHRippleSimulation createRippleAtGridCoordinate:strength:] + 73 2 libdispatch.dylib 0x12de8e5b6 _dispatch_client_callout + 6 3 libdispatch.dylib 0x12de78a33 _dispatch_continuation_pop + 859 4 libdispatch.dylib 0x12de8baae _dispatch_source_invoke + 2178 5 libdispatch.dylib 0x12de8388e _dispatch_main_queue_drain + 732 6 libdispatch.dylib 0x12de835a4 _dispatch_main_queue_callback_4CF + 31 7 CoreFoundation 0x12c25fd5c __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 9 8 CoreFoundation 0x12c25a7c8 __CFRunLoopRun + 2511 9 CoreFoundation 0x12c2599f1 CFRunLoopRunSpecific + 536 10 GraphicsServices 0x118d35c09 GSEventRunModal + 137 11 UIKitCore 0x15732a580 -[UIApplication _run] + 875 12 UIKitCore 0x15732f707 UIApplicationMain + 123 13 SpringBoard 0x10fe9c4e2 SBSystemAppMain + 7639 14 ??? 0x10ada43da ??? 15 dyld 0x10fd7d530 start + 3056 So it's crashing when it tries to make the little animation when a widget is dropped. I removed all the runtimes, every cache and preference I could find, emptied the trash, rebooted (to release any open file descriptors), and reinstalled Xcode. Nothing helped.

The execution of the shortcut command is abnormal. An App Intents was created through xcode, a test example was written, and an exception was executed. error: couldn`t communicate with a helper application. log: Shortcut <WFWorkflow: 0x600003008b40, name: Test, actions: 1> failed with error Error Domain=NSCocoaErrorDomain Code=4097 "connection to service created from an endpoint" UserInfo={NSDebugDescription=connection to service created from an endpoint, WFActionIndex=0}. -[WFBackgroundShortcutRunner callWorkflowRunningCompletionBlockWithResult:] Workflow Did Finish: Calling Completion Block -[WFBackgroundShortcutRunner listener:shouldAcceptNewConnection:]_block_invoke XPC connection invalidated -[WFBackgroundShortcutRunnerStateMachine invalidateWithReason:] connection invalidated/interrupted while finishing shortcut or exiting runner. Exiting should already be in process, not transitioning. -[WFBackgroundShortcutRunner unaliveProcess]_block_invoke_2 Exiting process

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.

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() ......

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 &amp; 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&lt;0x1140d2880&gt; (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?

I’m implementing a Control Widget for watchOS 26 Beta 5, using .promptsForUserConfiguration() so that users can select an option from an enum when adding the widget. The overall functionality works fine, but when users configure the option, the enum’s corresponding text is not properly localized. My enum is defined like this: static var caseDisplayRepresentations: [XXXType: DisplayRepresentation] { [ XX1: .init(title: .init("text1", table: "xxx")), XX2: .init(title: .init("text2", table: "xxx")), ] } After the configuration is completed and the Control Widget appears in the Control Center or Smart Stack, the text is displayed correctly. Same code on iOS work perfect.

I am building a widget that supports 2 different widget kinds, each supporting systemSmall, systemMedium, and systemLarge size families. My widget does download and display images so I expect memory usage to be on the higher end, but in debugging some memory issues, I notice that when I build my widget scheme to a physical device, things start off reasonable at ~12MB of memory usage. But as I change the widgets intent, add the other widget kind, or add different widget size families, this memory usage grows until it ultimately hits the 30MB cap. My question is, is the 30MB memory limit spread across all my supported widget kinds/sizes? Or does each individual widget get its own 30MB cap? i.e., if I have systemMedium Widget A and systemLarge Widget B, are they sharing that 30MB memory limit?

I was very excited to see the addition of push notifications for widgets. However upon further inspection, the way it is implemented seems too limiting for real life apps. I have an app for time tracking with my own backend. The app syncs with my backend in the main executable (main target). My widgets are more lightweight as they only access data in the shared app container, but they don't perform sync with the server directly to avoid race conditions with the main app. I was under the impression that the general direction of the platform is to be doing most things in the main app target (also App Intents work that way for the most part), so the fact that the WidgetPushHandler just calls the widget's method to reload the timeline is very unfortunate. In an ideal scenario I also need the main app to be 'woken up' to perform the sync with the server, and once that's done I'd update the widget's timeline and where I would just read data from the shared app container. So, my questions are: What is the recommended way of updating the widgets when this push notification arrives in the case that the main app target needs to perform the sync first? Is there any way how to detect that the method func timeline(for configuration: InteractiveTrackingWidgetConfigurationAppIntent, in context: Context) was called as a result of the push notification being received? Can I somehow schedule a background task from the widget's reloadTimeline() function? How can I get the push token later, in case that I don't save it right away the first time the WidgetPushHandler's pushTokenDidChange() is called? Thank you for your work on this and hopefully for your answers. FB19356256

Background I'm developing an iOS app with Live Activities that allows users to select custom background images. While these custom images display correctly in widgets, they fail to appear in Live Activities on both Lock Screen and Dynamic Island, despite successful image loading and data transfer. Technical Details iOS Version: Testing on iOS 17.2+ Image Storage: Using App Group shared container for image sharing between main app and widget extension Image Loading: Successfully confirmed via logs - images load correctly with proper dimensions UI Framework: SwiftUI with ActivityKit What Works ✅ Custom images display correctly in Home Screen widgets ✅ Built-in bundled images work in Live Activities ✅ Image data successfully transfers via App Group shared container ✅ Image loading logs show successful UIImage creation with correct dimensions What Doesn't Work ❌ Custom user images don't display in Live Activities (Lock Screen) ❌ Custom user images don't display in Dynamic Island ❌ Images appear as black/gray background despite successful loading Code Implementation I've tried multiple approaches: 1. SwiftUI Image approach: Image(uiImage: customImage) .resizable() .aspectRatio(contentMode: .fill) 2. containerBackground API approach: .containerBackground(for: .widget) { Image(uiImage: customImage) .resizable() .aspectRatio(contentMode: .fill) } 3. UIKit wrapper approach: struct UIImageViewWrapper: UIViewRepresentable { let image: UIImage func makeUIView(context: Context) -> UIImageView { let imageView = UIImageView(image: image) imageView.contentMode = .scaleAspectFill return imageView } func updateUIView(_ uiView: UIImageView, context: Context) { uiView.image = image } } Observations Images load successfully (confirmed via console logs) File paths are correct and accessible Same image loading code works perfectly in widgets When testing with UIKit approach, a red prohibition icon appears, suggesting system restrictions Questions Is there a technical limitation preventing user-provided images from displaying in Live Activities? Are there specific security restrictions for Live Activity backgrounds that don't apply to widgets? Is this behavior intentional based on Apple's design guidelines for Live Activities? What's the recommended approach for custom backgrounds in Live Activities? Apple Documentation Reference I found this guidance in "10 questions with the Live Activities team": "The Dynamic Island is most immersive when you don't provide background color or imagery — think of it purely as a canvas of foreground view elements." However, this seems to be design guidance rather than a technical restriction, and it doesn't specifically address Lock Screen Live Activities. Expected Behavior Custom user images should display as backgrounds in Live Activities, similar to how they work in widgets. Current Workaround I've implemented a color extraction system that generates gradients based on the dominant colors of user images, but users specifically want to see their actual images. Has anyone successfully implemented custom user images as Live Activity backgrounds, or can Apple clarify the intended behavior and limitations? Thank you for any insights!

During the WWDC Session called "Design widgets for visionOS" the presenter says: You can choose whether the background of your widget participates in tinting. If you opted out, for example to preserve a photo or illustration, make sure it still looks good alongside the selected color palette. Unfortunately, this session has no example code. Can someone point me to the correct way to do this? Is there a modifier we can use on views? (reposting this in the correct topic/subtopic)

I know for start events, sending the timestamp isn't required. So that's easy. However when I'm testing Live Activity using the Apple Push Notification Console. A lot of times I just need to copy/paste the payload and resend it again. But then the timestamp field needs to get updated each time, because if it's from a time in the past, then it won't trigger. This requires me to have to use an EPOCH converter to find the right time and then copy/paste it. Is there a better solution to this? I know I can use curl, but that is not in the scope of my question.