On iOS 27, a Live Activity's activityBackgroundTint and activitySystemActionForegroundColor are sometimes resolved with their light-appearance variants while the Lock Screen is dark. The activity's own content correctly uses dark at the same time. This is corrected the next time the activity is updated. If the tint's light variant is near-white, the system replaces it with its default blue. The Live Activity background and the "Allow Live Activities" prompt turn bright blue. The "Allow"/"Don't Allow" labels also use the action colour's light variant (black instead of white). Observed on the following: iPhone Duo, iOS 27.1: start an activity on a dark wallpaper when the extension's first render is slow. Adding Thread.sleep(forTimeInterval: 1) to the body reproduces it reliably. In a real app, a heavier first render (custom font registration, larger layouts) triggers it some of the time. iPhone 18 Pro, iOS 27.0: start an activity on a light wallpaper, then switch to a dark wallpaper. I have tried an asset catalogue colour, a dynamic UIColor, switching on colorScheme, and an identical update straight after requesting the activity, but all still show blue. Only a fixed dark tint with a fixed white action colour avoids it. I've filed FB25019357 with a sample project attached. Are there any known workarounds?

New faces I added in the iPhone Watch app showed up in My Faces but didn't reach my Apple Watch. Restarting both devices didn't help. The iPhone's logs showed the watch-face library was stuck in an automatic "reset sync" (not the Reset Sync Data button). With 65 watch apps installed, the reset was too big, hit the limit of 1000 messages per 5 minutes and failed, so new faces queued up behind it. One face took almost three hours to reach the watch. What worked for a while was removing the 7 watch apps with the most complications (I also pressed Reset Sync Data, so I'm not sure which did it). The reset dropped from 1946 to 927 messages and went through, and the stuck faces showed up the next time I added a face. About 90 minutes later a 939-message reset failed again, just over the limit counting the ~65 color-sync messages. To see if you're affected, stream your iPhone in Console.app on a Mac, add a face, and search for "requesting reset sync". I also filed FB25000090 because two queued Photos faces lost their photos when the reset went through. If you see it too, please file with sysdiagnoses from both devices (developer.apple.com/bug-reporting/profiles-and-logs) and mention FB25000073. iPhone 18 Pro on iOS 27.2 beta (24B5089g), Apple Watch Ultra 3 on watchOS 27.2 beta (24S5091f). Same on the public 27.0 release.

Filed as FB24619522 — sysdiagnoses from both devices and the live logs are attached to the report. We ship WidgetKit complications, and on the watchOS 27 betas (24R5360a, paired with iOS 27 24A5430a) they die every time the app gets updated while they're on the active face. Within seconds they turn into empty placeholders and never come back on their own — opening the app, switching faces or reloading timelines from the app does nothing. The watch logs show the extension being killed during the install (normal), and after that watchOS simply can't launch the new copy any more: runningboardd: <OSLaunchdJob | handle=…>: start succeeded, info=spawn failed, error=111: Invalid or missing Program/ProgramArguments chronod(ChronoKit): Reload failed; 0 retries remaining: … "Unknown extension process" Only two things fix it, and both restart chronod: rebooting the watch, or switching the watch language and back (iPhone › Watch app › General › Language & Region, then give it a couple of minutes). Our second extension in the same bundle, which wasn't running during the install, came back fine — so this looks like an OS bug rather than something we can work around in code. iOS 27 widgets seem to have the same problem (this thread, and iPhone in Canada wrote it up on beta 4), and someone posted the identical log lines back in March. FB24619522 — the full story, both sysdiagnoses and the live logs are in the Feedback.

Hi team, I’m working on an ActivityKit use case where a Live Activity is useful on the Lock Screen, but not in the Dynamic Island. Today, Live Activities appear to be treated as a unified presentation across system surfaces: Lock Screen, Dynamic Island, StandBy, etc. For our app, the Lock Screen presentation is the right user experience, but showing the same activity in the Dynamic Island creates unnecessary persistent foreground UI while the user is actively using the device. Is there any supported way to create a Live Activity that appears on the Lock Screen but opts out of Dynamic Island presentation on supported iPhones? If not, I’d love to request an ActivityKit enhancement that lets developers specify supported presentation destinations for a Live Activity, for example something like: Lock Screen only or Lock Screen + StandBy, but not Dynamic Island This would be useful for apps where the Live Activity is meant to act as a passive lock-screen status/reminder, rather than an ongoing foreground indicator. Thanks!

Hi, Problem I have a widget which displays a bright red. When I display the same view inside the app, the red is bright. However when I use the same view on the widget, the color looks a bit dull. Note: Widget Style: Default (Always) It is the same dull red when in focus and when not in focus This happens on iOS (device and simulator) and macOS Questions How can I fix it on the widget? Does widget support Display P3 colors? Any help on this would be much appreciated.

On watchOS 27 my app's round complication on the Infograph face disappears for about a second every time I raise or lower my wrist, then comes back. It only happens in the small round dials of that face, only when the face is set to a single color instead of Multicolor, and only when Always On Display is turned on. Everything else on the same watch is fine. my complication placed in a corner of the same face, the same face set to Multicolor, and an Apple complication sitting right next to mine. Other faces set to a single color are fine too, including in their round slots - I tested Modular and Meridian among others. With Always On Display off there is no problem either. What I already checked is: It still happens when my complication is the only one on the face. It still happens when the complication shows just a single line of plain text. The data is not being reloaded. I displayed the timestamp of the entry inside the complication and it does not change across the gap, so the same content is simply being redrawn. Removing the complication and adding it back does not help. Rebuilding with the newest Xcode changes nothing, and an older build behaves exactly the same. The same app, unchanged, worked correctly on watchOS 26. This started right after updating the watch to watchOS 27. Has anyone else run into this on watchOS 27? And has anyone found anything on the app side that makes a difference? I have not found a single thing.

Project structure is: App target + widget extension + widget intent extension All share a common appgroup group.com.x.y and all file handling is done using FileManager.default.containerURL(forSecurityApplicationGroupIdentifier: "group.com.x.y") so that only the shared container is used. Using the Main app target, a font "Chewy-Regular.ttf" is downloaded and saved to the shared AppGroup container. Font can now be loaded via CTFontManagerRegisterFontsForURL and displayed in a Main App Text view Text("Testing...").font(Font.custom("Chewy-Regular", size: 20)) Now add a Widgetkit widget instance that uses this font. In 'getTimeLine() and getSnapShot() of IntentTimelineProvider we load the font again via CTFontManagerRegisterFontsForURL (this needs to happen again probably because widget runs in a separate process from the main app?). On simulator, the widget will show the correct font. BUT On iPhone7 real device, the widget will show the 'redacted placeholder view'. It seems that something is crashing. I see in the device console : error 14:39:07.567120-0800 chronod No configuration found for configured widget identifier: D9BF75EE-4A04-441A-8C85-1507F7ECE379 fault 14:39:07.625600-0800 widgetxExtension -[EXSwiftUI_Subsystem beginUsing:withBundle:] unexpectedly called multiple times. error 14:39:07.672733-0800 chronod Encountered an error reading the view archive for &amp;lt;private&amp;gt;; error: &amp;lt;private&amp;gt; error 14:39:07.672799-0800 chronod [co.appevolve.onewidget.widgetx:widgetx:small:1536744920620481560@148.0/148.0/20.2] reload: could not decode view error 14:39:07.674984-0800 kernel Sandbox: chronod(2128) deny(1) file-read-metadata /private/var/mobile/Containers/Shared/AppGroup/9B524570-1765-4C24-9E0C-15BC3982F0DC/downloadedFonts/Chewy/Chewy-Regular.ttf error 14:39:07.675762-0800 kernel Sandbox: chronod(2128) deny(1) file-read-data /private/var/mobile/Containers/Shared/AppGroup/9B524570-1765-4C24-9E0C-15BC3982F0DC/downloadedFonts/Chewy/Chewy-Regular.ttf error 14:39:07.708914-0800 chronod [u 8D2C83B3-A6CB-432E-A9D4-9BC8F7056B10:m (null)] [&amp;lt;private&amp;gt;(&amp;lt;private&amp;gt;)] Connection to plugin invalidated while in use. fault 14:39:07.710284-0800 widgetxExtension -[EXSwiftUI_Subsystem beginUsing:withBundle:] unexpectedly called multiple times. error 14:39:07.803468-0800 chronod Encountered an error reading the view archive for &amp;lt;private&amp;gt;; error: &amp;lt;private&amp;gt; It seems that it's a permission issue, and the textview can't access the font file it needs when the widget is rendering. Notes: 1) Font is definitely registered because I can see them in for fontFamily in UIFont.familyNames {             for fontName in UIFont.fontNames(forFamilyName: fontFamily) {                 print(fontName) &amp;amp;#9;&amp;amp;#9;&amp;amp;#9;&amp;amp;#9;&amp;amp;#9;&amp;amp;#9;&amp;amp;#9;&amp;amp;#9;... in both the Main App target and the Widget Extension target 2) If I make make the font part of the app bundle and add to 'Fonts provided by application' , the are loaded absolutely fine in the Main App and the Widget on simulator and iPhone 7 real device. 3) I do see this error sometimes in the Widget extension target log, don't know if it's related. widgetxExtension[1385:254599] [User Defaults] Couldn't read values in CFPrefsPlistSource&amp;lt;0x28375b880&amp;gt; (Domain: group.co.appevolve.onewidget, User: kCFPreferencesAnyUser, ByHost: Yes, Container: (null), Contents Need Refresh: Yes): Using kCFPreferencesAnyUser with a container is only allowed for System Containers, detaching from cfprefsd 4) I suspected something to do with app groups, so I tried to copy the font into the Widget Extension container and load from there, but had the same result. Please help! Thank you.

We are qualifying a production WidgetKit extension on an iPhone 17 running iOS 26.6.1. both use App Group group.com....app.widgets. The extension reads small snapshots from the App Group. Precise personal Home data uses NSFileProtectionComplete; a separate book-only Lock projection uses NSFileProtectionCompleteUntilFirstUserAuthentication. Public Daily and non-personal control state are stored separately. Does Apple provide a supported deterministic mechanism to cause or observe the actual system-hosted WidgetKit provider performing a fresh App Group read during each phase below? Locked after first unlock. Rebooted, before the first passcode unlock. Relocked after first unlock. We need to attribute the read to the exact extension executable/process, establish the lock phase without unlocking or opening the protected data through the observation mechanism, and distinguish “the provider did not run” from “it ran but observation was unavailable.” Cached widget pixels, file attributes and later recovery cannot establish whether a fresh provider read was allowed or denied. WidgetCenter reload requests and timeline dates are opportunistic and have not produced deterministic invocations in these phases. Direct provider invocation, XCTest helper processes, debugger-controlled lifecycle substitution and manually reading files from the host do not establish the required system WidgetKit lifecycle. We cannot weaken file protection or add artificial production AppIntent/background capabilities solely to force this test. Please clarify which applies: A. A supported deterministic XCTest, CoreDevice, Xcode or WidgetKit test mechanism exists. If so, what setup, trigger and logging method should we use? B. WidgetKit scheduling in these states is intentionally opportunistic and no deterministic public test mechanism is provided. If so, what supported evidence does Apple recommend for verifying this protected-file contract? This request concerns test methodology; we are not claiming locked/BFU protection has passed.

Following up on a related discussion here: https://developer.apple.com/forums/thread/797298 "Using the new Liquid Glass effect in iOS 26 for widget backgrounds" I’ve also been looking at the widgetRenderingMode documentation and the “Optimizing your widget for accented rendering mode and Liquid Glass” documentation you mentioned. I understand that the widget should adapt its content based on the rendering mode, and that Liquid Glass is provided by the system when the widget is rendered in the appropriate context. What I’m still trying to understand is the behavior of the widget’s background/container itself. I tested a minimal widget on an iPhone running iOS 27, including: .containerBackground(for: .widget) { Color.clear } I also tried EmptyView(), .clear, containerBackgroundRemovable(true), and several material/glass combinations. What I found is: In Clear/Tinted Home Screen appearance, the widget becomes .accented and the system provides the expected transparent/Liquid Glass presentation. In the normal Home Screen appearance, the widget remains .fullColor (confirmed by logging @Environment(.widgetRenderingMode) directly in the widget view), but the actual Home Screen wallpaper does not show through the widget container. So I’m wondering whether this is simply expected behavior for .fullColor. Is it possible for a Home Screen widget to remain in .fullColor while its system widget container is genuinely transparent, allowing the actual Home Screen wallpaper to remain visible behind the widget? Or is transparency of the system widget container intentionally limited to the system’s Clear/Tinted (.accented) presentation? I’m asking because I’ve seen some third-party widgets that appear to provide a transparent or Liquid Glass-style widget even when the Home Screen is using its normal appearance, so I’m trying to understand whether there is a public WidgetKit/SwiftUI API or configuration that I’m missing. Thanks for any clarification.

Hi, for anyone who is working with LiveActivities and is running a beta of iOS 27, has apple made the ability for LiveActivities to be vertically larger and display more content as they appear in some of the demo images, or are these LiveActivities like the ones in the pictures above just system specific that is only available to apple.

My widget uses the @Environment(.isActivityFullscreen) variable. When running on ios 17, it will crash and report an error: dyld[55031]: Symbol not found: _$s7SwiftUI17EnvironmentValuesV9WidgetKitE20isActivityFullscreenSbvg Expected in: /Library/Developer/CoreSimulator/Volumes/iOS_21E213/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS 17.4.simruntime/Contents/Resources/RuntimeRoot/System/Library/Frameworks/WidgetKit.framework/WidgetKit

I've created a basic Multiplatform Project in Xcode, by going to File > New > Project. I've also included the default widget extension target. When I run the widget on Mac, and I control-click and choose "Edit Widget" the widget just kinda turns gray and floats over other windows, but does not let me configure anything. We leave the option to use configure with app intents turned on when adding the widget extension target. When I run the same project on an iPhone simulator, I can configure the widget without any issue. If someone else has a few minutes, can they see if this repeats for them? We are running this test because we are seeing the same experience in a real widget we are trying to develop but we can't get it to go into configuration mode on Mac.

Environment: Xcode 15/16, iOS 17/18, WidgetKit (IntentTimelineProvider) Issue: I have a photo widget that lets users pick an album and rotate through its photos on a timer (configurable refresh interval). When the selected album is large, the widget extension is Jetsam-killed with: Thread X: EXC_RESOURCE (RESOURCE_TYPE_MEMORY: high watermark memory limit exceeded) (limit=30 MB) After this happens, the widget stops refreshing entirely and stays on a stale/placeholder image until the app is relaunched. What I've tried: Downsampling with CGImageSourceCreateThumbnailAtIndex + kCGImageSourceThumbnailMaxPixelSize before building entries Reducing entry count and using policy .after(nextDate) instead of pre-building a full day of entries Still seeing intermittent Jetsams on albums with several hundred photos Questions: Is there a recommended max total archived timeline size WidgetKit expects developers to stay under, beyond "keep it small"? For a "large photo album" use case specifically, is the recommended pattern to pre-generate and cache small thumbnails in the App Group container ahead of time, rather than downsampling on demand inside getTimeline()? Is there guidance on how many timeline entries is "too many" before WidgetKit itself starts struggling to archive/deliver them, independent of image size? useful than a forum thread — let me know what info would help most.

I have created widget which supports medium and large family similar to news feed app like title and image by configuring the medium widget with 2 articles and large with 4 articles where each article has title and it's image with size 46x46 and 61x61. When am adding the small and large widgets to my Home Screen getting memory limit (Thread 1: EXC_RESOURCE RESOURCE_TYPE_MEMORY (limit=30 MB, unused=0x0)(crash and the widget is not refreshing and some times widgets is showing the skeletons instead of data. This is my timeline provider     func getTimeline(in context: Context, completion: @escaping (Timeline) -> Void) {             widgetVM.getRecommendedDataForWidget{ (result) in                 switch result {                 case .success(let items):                     let entries =  getRecommendedWidgetTimeLineEntries(recFeedModel: items)                     let timeline = Timeline(entries: entries, policy: .atEnd)                     completion(timeline)                 case .failure(_):                         let entry = RecommendedWidgetEntry(date: Date(), recommedationData: WidgetFeedModel.getPlaceholderData())                         let timeline = Timeline(entries: [entry], policy: .never)                         completion(timeline)                 }             }         }         else {             if accessTokenValue == nil { // if token is nil then considering it as member is not logged in.                 let entry = RecommendedWidgetEntry(date: Date(), recommedationData: [])                 let timeline = Timeline(entries: [entry], policy: .never)                 completion(timeline)                 return             }     } Could you please help me out on this as this is priority for me as part of app release. I couldn't find out the reason for this. Thanks

I have an app with a Widget Extension. Both the main app and the widget extension link against the same Swift Package, which contains a localization bundle (String Catalog) used by SwiftUI views inside the package. To make the package's views follow the app's configured language (rather than the system language), I set CFBundleAllowMixedLocalizations to NO in the Info.plist of each target (main app and widget extension). Behavior in the main app: This works as expected. If the app only supports Korean, the package's views display Korean text even when the system language is set to English. Behavior in the widget: The same views (from the same package) display English instead of Korean, even though the widget extension has the identical CFBundleAllowMixedLocalizations = NO setting and the widget's view code lives entirely in the package — not in the widget extension target itself. Question: As far as I understand, widgets are supposed to follow the host app's language setting. Given that both targets have the same Info.plist configuration, why would the widget extension resolve localized strings differently from the main app for code in the same package? Is this expected behavior for widget extensions specifically, or a bug? Is there a recommended workaround to force a widget extension (and by extension, the Swift Package code it runs) to use the app's language instead of the system language?

Hi, On visionOS 27 simulator accessoryRectangular widget shows completely blank with no text. The same widget shows up correctly on iOS 27 simulator. What I have tried: I have checked the timeline provider and they all seem to be generating timeline entries. supportedFamilies include accessoryRectangular I have even hard coded the content in the view for the widget yet only accessoryRectangular for visionOS 27 shows up blank. Isolated problem The same widget shows up correctly on iOS 27 simulator. The problem is only with visionOS 27. Environment: macOS: 26.6.1 (25G76) Xcode: 27.0 beta 5 (27A5237l) Simulator: visionOS 27.0 Questions What am I missing? How can I resolve it? Is this a known issue? Has anyone gotten accessoryRectangular widget showing up on visionOS 27 simulator? Any help on this would be much appreciated.

It's fairly well know and stated that the Apple Health / HealthKit data store is unavailable when iPhone is locked. Since Lock Screen Widgets were introduced there's been a feature parity mismatch with Apple's own Fitness app which is able to display updating Activity Rings on the Lock Screen. Third party apps cannot do this and have to rely unlocking their device to then trigger an update. This means they often display stale and wrong Health data. With the release of iOS 18 beta, I see no changes to this... Is there anything I've missed? Currently for requesting the Timeline Updates on my Widget I have to just keep requesting updates as often as possible and hope that each time the iPhone might be unlocked.... This is inefficient and a waste of device resources. Even a Widget timeline reload API that let the developer say "Only call update if iPhone unlocked" would be useful.

I'm exploring the possibility of using Apple's SystemLanguageModel from the Foundation Models framework within a WidgetKit extension to generate a summary of today's activities from my app. The API works as expected when invoked from the widget extension. However, I'm looking for guidance on whether this is a recommended approach in production. Given the execution time and memory constraints of WidgetKit extensions, is it advisable to perform on-device inference directly in the widget? Or is the recommended pattern to generate the summary in the main app (or another process), store the result in an App Group/shared container, and have the widget simply read and display the precomputed output?

Hello, For tracking purpose, is there a way to know when a widget is installed/uninstalled? Also, would it be possible to check which size widget was installed?

I would like to suggest adding a third Home Screen app icon size option that separates icon size from the option to remove app names. After using the current Home Screen customization options, I noticed that removing app names creates a much cleaner and more minimal look, but it also automatically increases the size of the app icons. While some users may prefer the larger icons, I personally prefer the regular icon size because it feels more balanced and organized. I discussed this idea with my friends and family, and we all agreed that we like the clean look of having no app names while still wanting to keep the original regular app icon size and compensating for the space of the name's of these apps being gone. My suggestion is to add a third option: Regular icons with app names (current default) Regular icons without app names (new option) Large icons without app names (current option) This would allow users to create a cleaner, more customizable Home Screen without forcing the app icons to become larger when removing app names. To help visualize this idea, I have also created some design mockups of what this option could look like. I hope these concepts help demonstrate how this feature could fit naturally into the existing Home Screen customization options. Adding this option would give users more control over their Home Screen design while maintaining the simplicity and attention to detail that Apple is known for. A small change like this could make the experience feel more personalized for many users.