I have a macOS app with a WidgetKit widget extension, distributed two ways: a notarised Developer ID download, and a Mac App Store build (same bundle identifiers, same team, different signature). When a user replaces the Developer ID copy in /Applications with the store-signed copy, the desktop widget draws only the grey placeholder and never recovers. The app itself runs normally. What I saw (8 October 2026, macOS 27): An iMac had the Developer ID build 47 (version 1.6.3) in /Applications with the widget on the desktop. I installed build 48 (version 1.6.4), signed for the store, from TestFlight. It replaced the Developer ID copy in /Applications. The app worked. The large widget showed grey placeholder bars and no data, for at least five minutes. killall chronod in Terminal brought the widget back straight away. On a MacBook, updating from one TestFlight build to the next (builds 46, 47, 48) redrew the widget each time. So it is the change from a Developer ID signature to a store signature, not an ordinary update. What I think is happening, and would like confirmed or corrected: the widget process that was started from the Developer ID copy keeps running after the app is replaced, and the system refuses what it draws (or never asks it for a new timeline), while the widget gallery and desktop keep showing that process's placeholder. What I already do: The Developer ID build ships a small helper outside the sandbox that ends the old widget process after an update. The Mac App Store build cannot carry that helper. The widget extension compares the build number in its bundle's Info.plist on disk with the one it started with, and exits if they differ. This ran in the case above (the build numbers were 47 and 48) and did not clear the placeholder. I suspect the check only runs when the system asks the widget for a snapshot or timeline, and the system had stopped asking. I call WidgetCenter.shared.reloadAllTimelines() after the app writes new data. Questions: Is there a supported way for a sandboxed app (or its widget extension) to make the system replace or restart a widget process that belongs to an earlier, differently signed copy of the same app? Without a Terminal command, and without a helper outside the sandbox. Is it expected that chronod keeps the old extension process after the containing app is replaced by a copy with a different signing identity, and that the widget then stays on the placeholder? Is there a log subsystem or predicate that shows why the old extension process was kept, or what the system refused? Thank you.

Hi everyone, I’m developing an iOS app and would like to know if it’s possible to dynamically show or hide a widget in the iOS Widget Gallery based on the user’s login status in the app. For example: When a user logs in to the app, the widget should appear in the Widget Gallery. When the user logs out, the widget should be hidden or removed from the Widget Gallery. Is this behavior supported by iOS? Can an app dynamically control the visibility or availability of its widget in the Widget Gallery based on the user’s authentication status? If this is not directly supported, is there an alternative or recommended approach using WidgetKit? Since my app has multiple widgets, some of them specifically require users to log in before they can be used. That’s why I wanted to implement this kind of behavior. Any guidance or suggestions would be appreciated. Thank you!

After updating an internal test app through TestFlight, newly started Live Activities sometimes fail to render. Activity.request succeeds, but the Dynamic Island shows an empty tappable area and the Lock Screen shows no Live Activity. Rebooting the device restores rendering. Is there a supported way to recover from this state without asking the user to reboot? Configuration Device: iPhone18,1 OS for the captured reproduction: iOS 27.0.1 (24A446) Distribution: TestFlight, internal testers only. This app bundle is not published on the App Store. We have reproduced the issue with builds made using both Xcode 26 and Xcode 27. Deployment target: iOS 17.0 The widget extension contains an ActivityConfiguration for Live Activities only, with no Home Screen widgets. Our QA team also reported similar symptoms after app updates on iOS 17.4.1 (iPhone 15 Pro Max) and iOS 26.5 (iPhone 11). We do not have diagnostic logs from those devices, so we cannot confirm that they have the same underlying cause. Bundle identifiers below have been consistently replaced with com.example.internalapp and com.example.internalapp.widgets for this public post. Steps to reproduce Install a build of the app containing the Live Activity widget extension. Update to a newer build through TestFlight. After the update completes, launch the app and start a Live Activity using Activity.request(attributes:content:pushType: nil). Check the Dynamic Island and Lock Screen. This is intermittent: it has happened after several app updates, but not every update. In the captured reproduction, the activity was started about two minutes after installation completed. Expected and observed behavior We expect the Live Activity to render on the Dynamic Island and Lock Screen, with taps opening the app through its widgetURL. Instead: Activity.request succeeds and liveactivitiesd starts the activity. The Dynamic Island has an empty tappable area and the Lock Screen shows nothing. Tapping the empty area opens the app without the activity's widgetURL. Updating the activity's content does not restore rendering. After rebooting, newly started Live Activities render normally. QA has also seen rendering recover after an undetermined wait without rebooting. Relevant diagnostic observations The following is an abbreviated, redacted excerpt from a locally collected sysdiagnose. Times are JST (UTC+09:00), on 2026-10-18. Ellipses indicate omitted fields; the activity identifier has also been redacted. During installation, runningboardd records a RBSPreventLaunchLimitation covering the app and its extensions. While installation is still in progress, chronod ignores the widget extension: 22:38:45.295 runningboardd ... RBSPreventLaunchLimitation ... ... com.example.internalapp.widgets ... com.example.internalapp ... 22:38:45.549 chronod [com.apple.chrono:extensions] Ignoring restricted or unknown extension com.example.internalapp.widgets 22:38:47.178 installcoordinationd -[IXSCoordinatedAppInstall setComplete:] ... com.example.internalapp ... complete! 22:38:47.292 chronod [com.apple.appinstallation:TransactionLog] com.example.internalapp ... applicationsDidInstall When a Live Activity is started later, chronod repeatedly reports zero extensions for the app's container: 22:40:41.221 liveactivitiesd [com.apple.activitykit:activityManager] Starting activity: id: <activity-id>; ... state: active ... 22:40:41.254 chronod [com.apple.chrono:descriptor] Reloading descriptors for 0 extensions in container com.example.internalapp with reason: activityRendererInitiated 22:40:53.543 chronod [com.apple.chrono:descriptor] Reloading descriptors for 0 extensions in container com.example.internalapp with reason: activityRendererInitiated 22:40:55.707 chronod [com.apple.chrono:descriptor] Reloading descriptors for 0 extensions in container com.example.internalapp with reason: reload descriptors requested by client The installation logs also show the widget extension's provisioning profile being found and its data container being created. These observations suggest that extension discovery may not have recovered after the installation restriction was lifted, but we have not established the root cause. We noticed a potentially related watchOS WidgetKit report referencing FB24619522. Its author reported that their issue was resolved with watchOS 27.0 / iOS 27.0; we do not know whether our Live Activity issue is related. Questions Is there a supported API or recovery procedure that makes the system rediscover the Live Activity extension after an app update? Are there known TestFlight installation or extension configuration conditions that could explain this sequence? Which additional ActivityKit/WidgetKit diagnostics would help distinguish an app configuration issue from a system extension discovery issue? The full sysdiagnose is being kept out of this public post because it contains device and account diagnostics.

I am encountering an issue where the Lock Screen Quick Action fails to visibly open my app. My app is a camera application that utilizes a CameraCaptureIntent to launch a standalone, lightweight camera view (accessible while the device is locked), distinct from the main application. Steps to Reproduce: Open the lightweight camera view using the Lock Screen Quick Action. From this view, launch the Main App. Lock the iPhone (put it to sleep). Attempt to launch the lightweight camera view via the Quick Action again. A slight animation occurs, but the camera view does not appear on screen. After multiple tests, it seems the view is actually launching but remains in an "invisible state." I suspect that the system hides the lightweight camera view when transitioning to the Main App, but fails to reset this hidden state when the Quick Action is triggered subsequently. I would appreciate any guidance on a potential workaround or confirmation if this is a known issue awaiting a system update.

Environment: iOS Version: iOS 27.0 Framework: ActivityKit Xcode Version: Xcode 26.1 Issue Description: In iOS 27, Live Activities fail to adapt to the system colorScheme. Regardless of whether the system theme is set to Light or Dark mode, @Environment(.colorScheme) inside the Live Activity view always returns .dark. This behavior worked as expected on iOS 26, where the Live Activity correctly responded to light/dark mode changes and rendered the appropriate theme. Expected Behavior: The Live Activity view should respect the system's current colorScheme (returning .light when the system is in Light Mode) on iOS 27, consistent with the behavior on iOS 26. Actual Behavior: The Live Activity view strictly defaults to .dark mode on iOS 27, even when the device is explicitly set to Light Mode. struct LockScreenView<T: BaseLiveActivityAttributes>: View { let context: ActivityViewContext<T> @Environment(\.colorScheme) var colorScheme var isLight: Bool { colorScheme == .light } var body: some View { Color(isLight ? .white : .black) .overlay(alignment: .topTrailing) { VStack(alignment: .trailing, spacing: 2) { Text("colorScheme: \(String(describing: colorScheme))") } .font(.system(size: 9, weight: .bold, design: .monospaced)) .foregroundColor(.yellow) .padding(4) .background(Color.black.opacity(0.6)) .cornerRadius(4) .padding(.trailing, 8) .padding(.top, 4) } } } Any insights or workarounds would be greatly appreciated. Thanks!

Is there a supported way to schedule a Live Activity update on the device for a known future date, so the system applies it while the app is suspended? It should update on the Lock Screen when the phone is locked, and in the Dynamic Island when the user is in another app, ideally with an alert. Local notifications can be scheduled for an exact date, but I haven't found an equivalent for Live Activities. My use case is a rest timer in a workout app that keeps all data on the device, with no server. When a rest starts, the app knows when it ends, and at that moment the Live Activity should show the next set and the time since the rest ended. Today the app schedules a local notification for the alert and sets the Live Activity's stale date to the rest's end. That has some problems: The stale date is applied a minute or two late in my testing, so the Live Activity shows 0:00 after the notification has already arrived. Updating from the app only works while it's running, which in practice means during a workout mirrored from Apple Watch. Even then, an alert sent with the update while the phone was locked appeared about a minute late, so the Live Activity never alerts. Push updates need a server, which this app doesn't have by design. A scheduled Live Activity start (iOS 26) creates a second activity instead of updating the existing one. Am I missing an API or a pattern for this? I've filed FB25210471 asking for it in case there isn't one.

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