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

Live Activities: API gaps for ProgressView, Text(timerInterval:), and compact/minimal icons Thanks for organizing a session on Live Activities — looking forward to it. We're shipping a Live Activity for train departures (a countdown to departure, plus a custom indicator for the platform the train leaves from), and we've run into a handful of limitations where the public API doesn't seem to expose behavior that first-party experiences appear to have. We'd love either guidance on how to achieve these today, or confirmation that they're on the roadmap. Grouping them by API below. ProgressView 1. Height isn't adjustable. (FB23091027) A linear ProgressView renders at a fixed height. The only lever we've found is scaleEffect, but scaling the whole view also scales the corner radius, so the rounded caps end up distorted (stretched ovals instead of clean pills). We'd like a supported way to set the bar's height — or at least a fixed-radius style that survives scaling. 2. Only the fill is stylable, not the track. (FB23091058) .tint(...) and progress view styles let us color the progress portion, but we can't find a way to style the background/remaining track (color, opacity, etc.). First-party progress bars clearly have a styled track, so we assume there's a path we're missing. 3. No separator/border between filled and remaining. (FB23091078) We'd like a visible border or divider at the boundary between the active (filled) and remaining segments. There's currently no hook for this without abandoning ProgressView entirely and hand-rolling the bar. 4. ProgressView(value:) carries extra vertical padding that ProgressView(timerInterval:) doesn't. (FB23091242) The value-based initializer renders with an additional ~3 pt of top/bottom padding that the timerInterval: initializer doesn't apply. When the two are placed together — or swapped for one another — their bars don't line up vertically, since one has extra vertical inset and the other doesn't. We'd like the vertical insets to be consistent across the two initializers (or a supported way to control them) so progress bars can be aligned reliably. Collectively, points 1–4 push us toward reimplementing the progress bar with Canvas/Shape, which feels like it shouldn't be necessary for something the system already draws. Text(timerInterval:) 5. No minute-granularity ("3 min.") countdown. (FB23091094) We want a self-updating timer that ticks down in whole minutes — "3 min." → "2 min." → "1 min." — rather than MM:SS. Apple already does this: in the Dynamic Island compact trailing region, the system Timer renders a coarse, minute-granularity countdown that updates itself (it shows e.g. "3 m"). We'd love exactly that, but with a localizable, slightly longer unit such as "3 min.". Today Text(timerInterval:countsDown:) only gives us the full digit-ticking format, and we can't find a supported way to drive a minute-granularity self-updating timer. 6. It always reserves full horizontal width. (FB23091111) A Text(timerInterval:) claims the maximum horizontal space its widest value would need (presumably to avoid layout jitter as digits change). Concretely: placing a Text(timerInterval:countsDown:) in compactTrailing stretches the Live Activity to fill that direction. Apple's own Timer doesn't do this — its countdown in the same compact trailing region hugs its content. We'd like a supported way to opt into that content-hugging layout, accepting the jitter trade-off ourselves. Compact Dynamic Island 7. Animating between two icons while the timer stays visible. (FB23091159) In the compact presentation we want to transition between two graphics on a state change — in our case, cross-fading between a vehicle/line glyph and our custom platform indicator (showing which platform the train departs from) in the compact leading slot, while the departure countdown stays visible in the trailing slot. Today the swap hard-cuts. First-party activities show smooth content transitions in these regions, so we assume there's a supported approach we're missing. Guidance on supported transitions for the compact slots would be very welcome. If any of these are already achievable, we'd genuinely appreciate pointers — we may simply be holding the API wrong. And if they aren't, consider this a consolidated feature request. We've filed each as an individual Feedback item (FB numbers inline above) and are happy to attach sample projects and screen recordings.

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?

For some reason since iOS 26.5, a ControlWidgetButton or a Button in a widget configured with an AppIntent conforming to OpenIntent fails to receive its AppEnum parameter correctly if the intent and enum are defined inside a shared Swift Package. Tapping the control widget button opens the main application, but it doesn't pass the AppEnum parameter value in, leaving the app on its default screen instead of navigating to the intended view. This was working perfectly in iOS 26.4, where the app would launch and receive the correct enum case from the intent. No code, configuration, or scheme changes were made between the two runs, only the simulator/OS version differs. Has anyone else run into what seems to be a regression on iOS 26.5? I filed feedback with a sample project: FB22848510

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!

Our application currently supports Live Activities. We’re working on adding a new Widget and are weighing some architectural decisions regarding whether we should add it to the same extension target that our Live Activity lives in or create a new extension that would expose it and other widgets we plan to create in the future. In the Add Support for Live Activities documentation, it suggests adding Live Activity code to the existing widget extension to facilitate code reuse. Beyond code sharing, we’re trying to determine if there are downsides to isolating new Widget(s) into their own extension. Specifically, we are concerned about process isolation and how a failure/crash in one might impact the other. Assuming they did live in the same extension, we’re hoping to better understand some of the finer details as presented by the following questions: If a Widget (e.g., via the TimelineProvider) causes the extension process to crash, what is the guaranteed behavior for a currently running Live Activity? Is the relaunch and restoration of a Live Activity after an extension crash guaranteed, or is it best-effort? Is there a distinction in crash isolation between a TimelineProvider failure and a View rendering crash? Are there any known scenarios where a Widget crash could cause a Live Activity to be permanently dropped? Does keeping them in the same extension affect the memory budget, or does each 'instance' receive its own allocation? In short: we're looking to ensure that an issue with a Widget doesn't inadvertently affect a Live Activity (or vice-versa) when they live in the same WidgetsBundle within the same extension and are seeking guidance on whether it makes sense to keep them together or continue down the path of separate extensions in the interest of process safety. Any pointers to other documentation or known behavior would be greatly appreciated!