I have implemented the logic to display live activity with push notification. As of now, only in the foreground only, the live activity is getting triggered. For background, it is displaying some times and for killed state, it is not even trying to trigger.

I'm building a set of widgets that feature various emoji flags. However, when displayed in tinted mode, the emojis appear as solid white. Is there a way to control or override the rendering mode of emojis in this context? Any guidance would be very much appreciated. Thank you!

i will go and play games on certian apps like geometry dash and flappy dunk and they are very sluggish at times. is this because of the beta software and has anyone had problems with this?

When updating from beta 1 to beta 2, CarPlay now only shows 1 column instead of the two or three that were in beta 1.

https://developer.apple.com/watchos/whats-new/ Is there an example demo available

我们在使用clip轻应用功能，在App Store Connect中配置了高级轻应用体验，并配置了相关的https链接（在构建版本页面此域名是已验证状态），但是我们在使用此链接进行NFC触碰时，不会拉起来clip轻应用，只会显示“XXXX NFC标签”，使用Apple的官方链接：https://appclip.apple.com/id?p=xxxx，是可以拉起来轻应用的，请问各位大佬，我们的问题出现在哪？该如何解决？

I am developing Live Activities using Swift. The same code can display the lock screen view and Dynamic Island on most devices, but on one specific iPhone 16 Pro Max, the Dynamic Island is not shown. The system version is iOS 18.0. However, other apps on this phone can display the Dynamic Island normally. How should I troubleshoot the issue? Can anyone help me? Thank you.

WatchOS26 ControlWidget cannot display image copy or click import Foundation import SwiftUI import WidgetKit import AppIntents internal import Combine struct WidgetToggle: ControlWidget { var body: some ControlWidgetConfiguration { StaticControlConfiguration(kind: "com.example.myApp.performActionButton", provider: TimerValueProvider()) { isRunning in ControlWidgetToggle("WidgetToggle", isOn: isRunning, action: ToggleTimerIntent()) { isOn in Label(isOn ? "Running" : "Stopped", systemImage: isOn ? "hourglass.bottomhalf.filled" : "hourglass") } } .displayName("WidgetToggle") .description("WidgetToggle description") } } struct TimerValueProvider: ControlValueProvider { var previewValue: Bool { return false } func currentValue() async throws -> Bool { return TimerManager.shared.isRunning } } struct ToggleTimerIntent: SetValueIntent { static var title: LocalizedStringResource = "WidgetToggle" @Parameter(title: "Toggle") var value: Bool func perform() async throws -> some IntentResult { TimerManager.shared.isRunning = value return .result() } } class TimerManager: ObservableObject { static let shared = TimerManager() @Published var isRunning = false }

I'm looking to maximise my Watch app's widget to be as up to date as possible. If we imagined the app was a simple step counter, and we wanted to display the users count as up to date as possible. We can conclude: We don't care about widget timelines beyond the current entry as we can't predict the future! We need to refresh the count as often as possible The refresh should be very quick with a straightforward HealthKit query, no networking or heavy work needed. We will assume the user has the complication/widget on their active Watch face. With the standard WidgetKit APIs we can expire the timeline after 15 minutes and in my experimentation a Watch app can usually update its widget timeline at that frequency if it's on the Watch face. I'm experimenting with two methods to try and improve refreshes further A user's step count might not have recently changed when the timeline update is called. I was therefore looking into the HealthKit enableBackgroundDelivery API (which requires the HealthKit Background Delivery entitlement to be enabled) to get updates limited to once an hour from a HKObserverQuery, I can then call the WidgetCenter.shared.reloadAllTimelines() from there. WatchOS also support the BGAppRefreshTaskRequest(identifier:"") and .backgroundTask(.appRefresh) APIs. I can request updates once every 15 minutes here too and then call the WidgetCenter.shared.reloadAllTimelines(). With option 1, this update opportunity is great as it will specifically update when there's new steps so even once an hour this would be helpful (A real shame to be limited to once an hour even if this used up WidgetKit standard reload budgets: FB13879817, FB11677132, FB10016177). But I can't determine if this update takes away one of the standard timeline expiration updates that already run 4 times an hour? Could I observe additional Health types to get additional updates? Do I need the Background Modes Capability as well as the HealthKit Background Delivery for this in Xcode or just the HealthKit one? With option 2, I can't find a suitable option in the (short) list of supported background modes in Xcode. Does not selecting any mean my app will get 0 refreshes from this route and so should not be implemented in my use case?

I'm currently seeing that OS gets a new push-to-start token immediately after receiving the first notification. Should my server immediately invalidate the push-to-start token upon usage? Or invalidating the push-to-start token should only be done if my iOS device gets a new one and then I have to send it back to my server.

I've turned on Swift 6 language mode and noticed that during runtime Xcode gives this warning for a new widget (iOS 17.2): warning: data race detected: @MainActor function at TestWidgetExtension/TestWidget.swift:240 was not called on the main thread struct TestWidget: Widget { let kind: String = "TestWidget" var body: some WidgetConfiguration { AppIntentConfiguration( kind: kind, intent: ConfigurationAppIntent.self, provider: Provider() ) { entry in // LINE 240 TestWidgetEntryView(entry: entry) .containerBackground(Color.white, for: .widget) } } } Is there any way to solve this on my side? Thank you!

body: error when I run the app,and the frame just became freezed.

I'm trying to update data displayed in my Watch Complications (WidgetKit). I have an iOS app that sends data to the Apple Watch using WCSession.default.transferUserInfo. However, the data only updates on the complications or widgets after I open the watchOS app manually. Ideally, I'd like the Watch widget/complication to reflect the updated data as soon as it's sent from the iPhone, without requiring the user to open the Watch app.

In WatchOS 26 you can now configure Apple Watch Widgets that use AppIntents instead of having a preconfigured option via AppIntentRecommendation. This is demonstrated in the Weather Details Widget. In that, the Intent has been set up such that the options have icons for each parameter. How can I update my Intent code to offer this? struct DataPointsWidgetIntent: AppIntent, WidgetConfigurationIntent { static var title: LocalizedStringResource = "Data Points Widget Configuration" static var description = IntentDescription("Configure the individual data point display for Widgets.") static var isDiscoverable: Bool { return false} init() {} func perform() async throws -> some IntentResult { print("DataPointsWidgetIntent perform") return .result() } @Parameter(title: "Show Individual Data Points", default: true) var showDataPoints: Bool? @Parameter(title: "Trend Timescale", default: .week) var timescale: TimescaleTypeAppEnum? static var parameterSummary: some ParameterSummary { Summary("Test Info") { \.$showDataPoints \.$timescale } } } enum TimescaleTypeAppEnum: String, AppEnum { case week case fortnight static var typeDisplayRepresentation = TypeDisplayRepresentation(name: "Trend Timescale") static var caseDisplayRepresentations: [Self: DisplayRepresentation] = [ .week: "Past Week", .fortnight: "Past Fortnight" ] }

Hello, I'm currently developing for visionOS using Xcode's latest beta version. I have a question regarding Widget Previews for visionOS 26: When I create a new Widget Extension target directly from a visionOS project, the generated code does not include the #Preview macro. Following the documentation, I manually added the #Preview macro to a Widget created within a visionOS project, but Xcode then displays an error stating that "This platform does not support previewing widgets." My interpretation is that Widget Previews are currently not supported for Widgets created specifically for visionOS in this beta version. Is this understanding correct? Or am I missing a specific way to implement previews for visionOS Widgets, or is there a particular project setting I might have overlooked? Any clarification or guidance on this matter would be greatly appreciated. Thank you.

I am experiencing an issue with my watchOS app. My application updates a shared file, accessible by both the main app and the WidgetKit extension, during a WatchConnectivity background task. Following this update, I call reloadAllTimelines(). This functionality worked as expected on watchOS 10, even without Developer Mode enabled. However, after updating my device to watchOS 11.5, this API appears to be broken. My reasons for believing this API is broken are threefold: The functionality worked reliably on watchOS 10. On watchOS 11.5, enabling "WidgetKit Developer Mode" (found under Settings > Developer) resolves the issue, and my complications update correctly. When I enter watch face edit mode, the snapshot/preview displayed (which utilizes the same underlying logic as the timeline API) shows the correct data. This indicates that the data has been successfully received from the phone, and the widget is indeed reading the updated shared file. Despite this, the actual widget view during its resting phase never updates. It's worth noting that TimelineReloadPolicy functions as expected, but I cannot rely on this for my use case. My widget requires immediate updates upon receiving new data. Apple, please investigate this behavior.

I have a Health & Fitness widget that runs on iPhone and Apple Watch. As Health data access requires the device to be unlocked, the iPhone widget is already slightly limited in capability because of updates. With widgets further expanding to places like CarPlay, I know I can use the .disfavouredLocations{} API to try and prevent it being offered there. This is crucial as the widget functionality would be basically non-existent as your device is locked during CarPlay use. My problem is, on the Mac despite using the .disfavouredLocations{.iPhoneWidgetsOnMac} etc...., the widget can still be added in the "other unsupported section". And yet, in that section the Apple Fitness app widget is no where to be seen. Is there an API I am missing to completely remove a widget from the Mac widget gallery and hopefully CarPlay, Standby etc.... (all places where the device running the widget is usually locked -> No Health data)? Or does the Apple Fitness app have a private API to block it from these places where its function is not wanted and this isn't available to other apps?

See the image there the clock is stopped but on right on the top time is different

Hello, I'm working with Live Activities and noticed that sometimes an activity transitions to .dismissed, even though the user hasn't manually swiped it away and system conditions appear to be completely normal — such as: The activity is still within its intended 8-hour lifetime The battery level is high The app is active or recently active The activity is lightweight (not using frequent updates) According to the ActivityKit documentation: /// The Live Activity ended and is no longer visible because a person or the system removed it. case dismissed This doesn’t clarify why the system would dismiss an activity when all conditions seem fine. Additional context: When reviewing system logs via Console.app, we’re seeing messages such as: liveactivitiesd Removing activity from replicator: 381F3DDC-585B-4021-B075-548606F543DA for relationship IDs: [C7AB9C2A-49DD-43FC-BB58-D768ECF9D354] This suggests that the system is actively removing the activity, but there’s no API or reason provided that helps us understand why this is happening. Questions: What are the system-level triggers that could cause a Live Activity to be dismissed under normal conditions? Is there a known set of heuristics (e.g., memory pressure, resource constraints) that might apply? Is there a way to distinguish between system-triggered dismissal and user-initiated swipe-to-dismiss? Any best practices to reduce the likelihood of unexpected system removal? This is especially important for our use case, where users rely on Live Activities to view real-time flight and boarding information — and losing the activity unexpectedly negatively affects user experience. Thanks in advance for any insight!

Hello forum, I want to keep my app running in the background after user swaps up, for the purpose of workout tracking. start up the task and continuously receipt GPS updates process the location data show the data on a live activity Two examples Strava paddlelogger Question: Does this mean, these two apps would just pause when the .backgroundTimeRemaining becomes 0? How does a workout app "work" in background mode, do I need to handle budget running out?