When I set an alarm using the AlarmKit Demo App provided by WWDC, wait for the alarm to go off while the device is unlocked, and the Dynamic Island pops up with a notification, instead of tapping the button to dismiss it, I collapsed the Dynamic Island. The Dynamic Island displayed a black blank screen; when I long-pressed to expand it, it still showed a black blank screen. When I tapped it while collapsed, it redirected me to the Demo App, and this state persisted indefinitely. The issue was only resolved by turning off the device or setting a new alarm and waiting for it to go off, then explicitly tapping to dismiss it. Additionally, I’m currently developing my own AlarmKit-based alarm app, which is how I discovered this bug. Now that I’ve found the official demo has the same issue, I look forward to a fix. Xcode version 26.5 (17F42) macOS version 26.5 (25F71) Simulator version 26.4.1 Device version 26.5.1 Demo App link： https://docs-assets.developer.apple.com/published/c2045ce0bff8/SchedulingAnAlarmWithAlarmKit.zip

We are building a media application that uses Live Activities and Dynamic Island extensively on iPhone. On macOS, we currently need to build separate UI surfaces such as menu bar extras, widgets, and custom overlays. Are there any recommended patterns for creating a persistent, glanceable activity experience on macOS that maintains parity with Live Activities on iPhone?

We ship WidgetKit complications (StaticConfiguration, TimelineProvider) in a companion iOS + watchOS app and want to send Adobe Analytics when users add, remove, or switch complication kinds/families on their watch face. From the widget extension we only see timeline refreshes via getTimeline, which seems too noisy and unrelated to user intent to use for lifecycle tracking. On iOS we diff WidgetCenter.shared.currentConfigurations() at app launch against persisted state—is that also Apple’s recommended pattern on watchOS, or is there a supported callback we’re missing? How should this work for a companion app (watch collects and relays via WatchConnectivity vs. tracking from the iPhone Watch app) versus a standalone watch app where third-party analytics may only run on-device? We’re especially unsure how reliably removal is detected if the watch app doesn’t launch again after a complication is removed.

I asked this elsewhere in the forums and haven't gotten a response, but in one of the WWDC word clouds I saw the label "Extra-small widget option in visionOS", but looking at the WidgetFamily it doesn't look like there is any new size that has been opened up for 27. Is this a new size to be supported or something else entirely?

One of the WWDC word clouds included the phrase "Real-time updates for widgets with app is open". Can someone please explain what is going on there and how that is different from what was happening previously? I was under the impression that updates were always happening while the app was running and never counted against whatever app update quota was in place. I am not sure if this is related, but I would love to know in iOS 27 has any sort of increase to the memory or CPU limits on widget updates. For years we have had ideas for more widgets but can't implement them because even staying under the 30MB limit has been nearly impossible.

We are building a media application that uses Live Activities and Dynamic Island extensively on iPhone. On macOS, we currently need to build separate UI surfaces such as menu bar extras, widgets, and custom overlays. Are there any recommended patterns for creating a persistent, glanceable activity experience on macOS that maintains parity with Live Activities on iPhone?

I have widgets on iPhone and Watch. It uses colors and color gradients to convey information to my users. I respect Differentiate Without Color, but what has been defeating me is colored screens on watch and phone when it desaturates the widget. The view is not legible any longer. What would you recommend for handling my views. I would be happy if I could show the textures I made for Differentiate Without Color, and I tried, but the screen color tint seems to fill the entire frame. How do I control this? Once it is controlled, what are my options for display? Any other suggestions?

Can WidgetKit and Live Activities directly leverage Foundation Models, or is the recommended approach to use App Intents and have the model run in the containing app

If the user has a lot of widgets the timeline generator can wind up getting killed. Is there any recommendations on how to deal with this? Is there for example any equivalent of applicationDidReceiveMemoryWarning() ?

From post https://developer.apple.com/forums/thread/778914 I am wondering if there is any news on https://feedbackassistant.apple.com/feedback/17148295

Hi everyone, I'm working on a Live Activity implementation for a ticketing app (written in Swift/SwiftUI with ActivityKit), and I've encountered an unexpected behavior on iOS 26.2.1 that contradicts my understanding of the documentation. What the docs say: The official ActivityKit documentation states: "The system uses the minimal presentation when more than one app has an active Live Activity." This implies the two minimal slots are intended for two different apps. There is no documented scenario where a single app occupies both minimal positions simultaneously. What I observed: On a device running iOS 26.2.1, with two active Live Activities from the same app running at the same time, both minimal views appeared on the Dynamic Island simultaneously — one attached to the island, one as a detached floating pill. Questions: Is this behavior intentional in iOS 26, or is it a regression / unintended side effect? Has the system policy changed in iOS 26 to allow a single app to occupy both minimal slots? If this is expected, is there any updated documentation or release notes that cover this change? Environment: Device: iPhone 14pro iOS: 26.2.1 Xcode: xcode26 Any insights from Apple engineers or developers who've seen this would be greatly appreciated. Thanks!

Moved to WWDC26 iCloud & CloudKit Q&A: https://developer.apple.com/forums/thread/830698

Platform: iOS 26.5 · PassKit (semantic boarding pass) Summary When a .pkpass boarding pass uses the iOS 26 upgraded semantic format (preferredStyleSchemes: ["semanticBoardingPass", "boardingPass"]) for a real, scheduled flight that Apple's live flight data feed recognizes, the Wallet Live Activity (Lock Screen, Dynamic Island, and Wallet card "Welcome to …" copy) renders the destination city name in English, regardless of the value supplied in semantics.destinationCityName or the device's locale. On a German-locale iPhone, a flight arriving at MUC produces the grammatically broken string "Willkommen bei Munich" — German system-supplied prefix concatenated with the English city noun from Apple's flight data, instead of the expected "Willkommen in München". Steps to reproduce Build a .pkpass for any real, currently-scheduled flight whose destination city has a German-language variant (e.g. SK2657 CPH→MUC, 4Y1261 HER→MUC). Populate semantics with full iOS 26 fields including: "destinationAirportCode": "MUC", "destinationAirportName": "München", "destinationCityName": "München", "destinationLocationDescription": "Flughafen München Franz Josef Strauß" Install on an iPhone running iOS 26.1+ with Language: Deutsch, Region: Deutschland. Open the pass within Wallet's live-activity window. Expected: "Willkommen in München" Actual: "Willkommen bei Munich" What I believe is happening Apple's live flight data feed overrides the destinationCityName semantic tag with an English-only value sourced from the feed (presumably IATA / OAG). The iOS 26.1 liveDataConfiguration.excludedSemantics allow-list does not include destinationCityName or destinationAirportName, so there is currently no developer-side mechanism to either: submit a localized destination city, or opt out of the override while keeping live updates active. The PassKit destinationCityName schema is typed as a plain localizable string (single value), with no translations variant comparable to what some third-party pass APIs expose. The "localizable" annotation in the docs is misleading for this field, because pass.strings lookups are not applied to semantic values once the live flight feed supplies them. What I'd like to know Is this the intended behavior, or is destinationCityName missing from the documented excludedSemantics allow-list by omission rather than design? Is there a supported way for an airline (or a developer issuing passes on an airline's behalf) to ship localized destination city names that survive the live-data merge? If neither (1) nor (2): is there an intent to either localize Apple's flight-data city tokens by device locale, or expand excludedSemantics to cover destination/departure city + airport names in a future iOS 26.x release?

Hi everyone, I have two questions about Live Activity push notifications that we send from our backend server to iPhones. First, I would like to understand the expected behavior when lowering the APNs priority of a Live Activity update from 10 to 6. How does this affect delivery timing, reliability, or system handling of the notification? Second, my team has been seeing significant delays with some messages sent to the device. In some cases, notifications take anywhere from 1 to 3 hours to arrive on the phone. We are trying to understand what might cause this kind of delay. Is this expected under certain conditions, such as device state, system throttling, network conditions, or APNs behavior? Also, is there any way to inspect logs or delivery details for messages sent to the app so we can better diagnose where the delay is happening? Any guidance would be appreciated. Thanks.

We are using Live Activities in our iOS app to show real-time flight information on the Lock Screen and Dynamic Island. Our implementation currently works as follows: The Live Activity is created using the push-to-start token. After the Live Activity is started, our backend receives and uses the Live Activity update token to send updates to the Live Activity through APNs. The Live Activity content is updated through push notifications from our backend. These updates include flight status changes such as check-in status, boarding status, gate changes, delay updates, arrival status, and other journey-related states. We are observing an issue where some Live Activity state updates are not reflected on the device. From our backend logs, the APNs request is successfully sent, but in some cases the update does not appear to be received by the device, and the Live Activity remains in an older state. We understand from Apple documentation and platform behavior that Live Activity push updates may be subject to system-level throttling or delivery limitations. We would like to confirm the expected behavior and understand the recommended approach. Could you please help clarify the following? Are Live Activity update pushes subject to throttling by iOS/APNs even when the backend sends the update successfully? If APNs accepts the request successfully, is there still a possibility that the update may not be delivered to the device or may not update the Live Activity because of system-level throttling, device state, power conditions, network conditions, or Live Activity limits?

Environment App: Web app (Sign in with Apple JS / redirect flow) Hosted over HTTPS (valid TLS cert via AWS ALB) Tested on latest Chrome, Safari, and Firefox Reproducible in normal + incognito/private windows Expected behavior When clicking "Sign in with Apple", the popup should render the Apple login form and then redirect to our configured callback endpoint Actual behavior Apple Sign-In popup opens successfully Page loads only the Apple header shell: • Apple logo • "Apple Account" • Collapsed "Sign in" section The actual login form (email/password entry) never renders No visible error shown to the user No requests ever reach our backend callback endpoint Configuration status Services ID created and enabled for Sign in with Apple Domain verified and added to Services ID: Return URL configured exactly: Primary App ID has Sign in with Apple capability enabled Key created and associated with the App ID CSP allows What we have already tried Re-saving Services ID configuration multiple times Regenerating Key and re-binding to App ID Verifying client_id matches Services ID identifier exactly Waiting >24 hours for propagation Testing across multiple browsers and devices Key observation The flow appears to stop before authentication UI renders fully, and no redirect/callback is ever triggered, suggesting the issue occurs within Apple’s authorization session before completion. Question Is there any known requirement or verification step for Services IDs using a domain-style identifier, or any additional Apple-side configuration/activation step that could prevent the login form from rendering even though the initial authorize page loads?

I am looking into the new CarPlay support for systemSmall widgets introduced in iOS 26 (Apple documentation). I am trying to figure out if there is a way to programmatically detect whether the widget is currently being displayed on the iPhone/iPad home/lock screen or in CarPlay. So far, I haven’t found any information in the documentation or APIs that indicate how to distinguish between these environments. Is there an API, environment value, or best practice for handling this scenario? Thanks in advance for any insights!

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.

The sleep app on my Apple Watch is constantly getting the bedtime wrong. It averages in every nap or if I nod off in my chair, so the resulting moving average is always way off. There should be an ability to edit the bad data entries.

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!