Hi all, We're seeing an issue where Live Activity content-state push updates sent via PushType.channel(_:) are not consistently delivered to all devices subscribed to the same channel — even though Activity.request() succeeds on every device, and the affected/unaffected devices are both on recent iOS versions well above the 18.1 minimum for channel-based push. Setup: Our backend broadcasts content-state updates to all devices subscribed to a given channel. Activity creation succeeds normally on the affected device, but it never receives a single subsequent update — the activity eventually goes .stale after its staleDate elapses, despite our backend confirming it sent an update to that channel. What we've verified so far: Activity.request() succeeds locally on the affected device, no error thrown. We instrument ContentState's Decodable init(from decoder:) to log every time ActivityKit attempts to decode an incoming push. On the affected device, this log never fires — so no push payload is ever being handed to ActivityKit at all on that device. It's not a decode/payload-format issue. A second device on the identical app build and channel setup receives updates normally in the same window — rules out a backend-wide outage. Both devices are on recent iOS (affected: iPhone 13 Pro Max, iOS 26.5.2 / unaffected: iPhone 15 Pro Max, iOS 26.6) — rules out OS version threshold. No logs, crash reports, or console output of any kind on the affected device around when the update should have arrived — completely silent failure. Question: Has anyone run into a device silently failing to receive PushType.channel broadcast updates like this? Are there known conditions (notification permissions, Low Power Mode, Background App Refresh, channel subscription expiry/limits, etc.) that could cause this? Is there any client-side API to check the health/status of a device's channel subscription, to distinguish "not subscribed," "subscription expired," and "subscribed but delivery failed"? Any pointers appreciated — happy to share more details if useful.

Hi, We are the developers of Morning Call (https://morningcall.info), and we believe we may have identified an AlarmKit / system UI bug on iPhone. We can reproduce the same behavior not only in our app, but also in Apple’s official AlarmKit sample app, which strongly suggests this is a framework or system-level issue rather than an app-specific bug. Demonstration Video of producing zombie Live Activity https://www.youtube.com/watch?v=cZdF3oc8dVI Related Thread https://developer.apple.com/forums/thread/812006 https://developer.apple.com/forums/thread/817305 https://developer.apple.com/forums/thread/807335 Environment iPhone with Dynamic Island Alarm created using AlarmKit Device is unlocked when the alarm begins alerting Steps to reproduce Schedule an AlarmKit alarm. Wait for the alarm to alert while the device is unlocked. The alarm appears in Dynamic Island. Instead of tapping the intended stop or dismiss button, swipe the Dynamic Island presentation away. Expected result The alarm should be fully dismissed. The Live Activity should be removed. No empty UI should remain in Dynamic Island. Actual result The assigned AppIntent runs successfully. Our app code executes as expected. AlarmKit appears to stop the alarm correctly. However, an empty “zombie” Live Activity remains in Dynamic Island indefinitely. The user cannot clear it through normal interaction. Why this is a serious user-facing issue This is not just a cosmetic issue for us. From the user’s perspective, it looks like a Live Activity is permanently stuck in Dynamic Island. More importantly: Force-quitting the app does not remove it Deleting the app does not remove it In practice, many users conclude that our app has left a broken Live Activity running forever We receive repeated user complaints saying that the Live Activity “won’t go away” Because the remaining UI appears to be system-owned, users often do not realize that the only reliable recovery is to restart the phone. Most users do not discover that workaround on their own, so they instead assume the app is severely broken. Cases where the zombie state disappears Rebooting the phone Waiting for the next AlarmKit alert, then pressing the proper stop button on that alert Additional observations Inside our LiveActivityIntent, calling AlarmManager.shared.stop(id:) reports that the alarm has already been stopped by the system. We also tried inspecting Activity<AlarmAttributes<...>>.activities and calling end(..., dismissalPolicy: .immediate), but in this state no matching activity is exposed to the app. This suggests that the alarm itself has already been stopped, but the system-owned Live Activity UI is not being cleaned up correctly after the swipe-dismiss path. Why this does not appear to be an app logic issue The intent is invoked successfully. The alarm stop path is reached. The alarm is already considered stopped by the system. The remaining UI appears to be system-owned. The stuck UI persists even after our own cleanup logic has run. The stuck UI also survives app force-quit and app deletion.

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

This is about AlarmKit, and this problem is also happening with the native phone alarm. I’m working on some alarm apps, and some users have been complaining that when they get their phone, the alarm is being dismissed. We were never able to simulate this until today. We noticed that when touching the bottom notch of the phone, below the stop swipe area, sometimes the alarm is simply dismissed. In some cases, you can see the same UI repeated behind the screen; other times, you can’t drag, but it also dismisses the alarm. This seems to have been happening for quite a while with our users. They grab their phones, unintentionally touch that area, and dismiss the alarm. It’s very critical for us because we present other buttons on AlarmKit for the user to click on (guess which bird is singing, for example). Feedback Ticket Created: FB24407814

Hi — I’m trying to understand what customization is currently supported for App Shortcuts as they appear inside the Shortcuts app. From the public App Intents APIs, it looks like an AppShortcut can specify a systemImageName, and an AppShortcutsProvider can specify a shortcutTileColor. I haven’t been able to find documentation for either of the following: Using a custom app-provided icon/image asset instead of an SF Symbol Using custom imagery or a background image for the App Shortcut tile itself However, some Apple apps such as Music and Podcasts appear to use richer/custom artwork in their Shortcuts tiles, which made me wonder whether there is a supported API or approach that I’m missing. Are custom icons or background images currently supported for App Shortcut tiles through public APIs? If not, are the richer treatments used by Apple Music/Podcasts based on system-only capabilities that aren’t currently available to third-party apps? Thanks!

在iOS27测试版回退到iOS26正式版后iCloud无法备份、恢复照片，求解决方案

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.

So how can I still login

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?

Hi everyone, I'm facing an issue with WidgetCenter.shared.getCurrentConfigurations() and I'm trying to determine whether this is expected behavior or a WidgetKit bug. Environment WidgetKit with IntentConfiguration One widget kind: PhotoBoxWidgetGroup Supported families: .systemSmall .systemMedium .systemLarge Steps to reproduce Fresh install the app. Add the PhotoBoxWidgetGroup widget to the Home Screen. Resize the widget between Small, Medium, and Large (or create different sizes during testing). Delete all instances of the widget from the Home Screen. Call: WidgetCenter.shared.getCurrentConfigurations { result in ... } Expected Result Since there are no widgets on the Home Screen, I expect: Widget count: 0 Actual Result getCurrentConfigurations() still returns three configurations: Widget count: 3 Kind: PhotoBoxWidget Family: systemLarge configuration: nil widgetConfigurationIntent: nil Kind: PhotoBoxWidget Family: systemMedium configuration: nil widgetConfigurationIntent: nil Kind: PhotoBoxWidget Family: systemSmall configuration: nil widgetConfigurationIntent: nil Although there are no widgets on the Home Screen, WidgetKit continues to report one configuration for each supported family. Additional observations This does not happen immediately after a fresh install. The issue appears only after the widget has been resized. If I restart the device, getCurrentConfigurations() correctly returns 0. After adding the widget again, resizing it, and deleting it, the issue reappears. I have also tried: reinstalling the app adding confirmation delays before querying querying only when the app becomes active filtering by kind comparing snapshots The result is always the same. Question Has anyone experienced WidgetCenter.shared.getCurrentConfigurations() returning stale widget configurations after widgets have been resized and removed? Is this a known WidgetKit issue, or is there an additional step required to ensure deleted widget configurations are removed from getCurrentConfigurations()? Any guidance or confirmation would be greatly appreciated.

I saw Apple Clips on one of my relatives phone but it’s discontinued now so how do I download it without the family thing and the Apple ID?

Hello Apple DTS Team, We are optimizing a real-time iOS 26 WidgetKit architecture that utilizes both direct WidgetKit APNs pushes and Notification Service Extension (NSE) background asset downloading. We would appreciate technical clarification regarding budget allocation, execution latency, and view hierarchy invalidation on iOS 26. Architecture Overview Our system handles real-time visual updates across multiple distinct Widget kinds (KindA, KindB) using a dual-path pipeline: Direct WidgetKit APNs Push (iOS 26): Registers tokens via WidgetPushHandler (pushTokenDidChange(_:widgets:)). Remote server sends APNs requests targeting <bundleID>.push-type.widgets with apns-push-type: widgets and payload {"aps": {"content-changed": true}}. NSE Asset Pre-Fetch (Notification Service Extension): Server sends a remote notification containing mutable-content: 1 and asset metadata. The NSE intercepts the payload, streams the binary image asset into a shared App Group container (FileManager.default.containerURL(forSecurityApplicationGroupIdentifier:)), writes JSON state to shared UserDefaults, and executes targeted timeline reloads via WidgetCenter.shared.reloadTimelines(ofKind: "KindA"). Timeline Provider: TimelineProvider.getTimeline() reads data synchronously from the shared App Group UserDefaults, resolves the local file path via UIImage(contentsOfFile:), and returns a single SimpleEntry with TimelineReloadPolicy.after(25 minutes) alongside TimelineEntryRelevance(score: 100.0). Technical Questions & Observed Behaviors Per-Kind Budget Isolation vs. Bundle-Wide Budget: Does dasd / chronod maintain an independent 70-reload daily budget for each individual Widget kind (or widget instance), or is the daily background reload budget shared globally across all widget kinds within the extension bundle? Does calling WidgetCenter.shared.reloadTimelines(ofKind: "KindA") from an NSE deduct budget tokens only from KindA's budget bucket, or does it deduct from a global shared bundle pool? NSE Reload Budget Deductions vs. Direct WidgetKit Pushes: Does a direct WidgetKit APNs push (apns-push-type: widgets) draw from a completely separate APNs push budget pool than a WidgetCenter.shared.reloadTimelines(ofKind:) call issued inside an NSE? When an NSE issues reloadTimelines(ofKind:) in response to a user-visible notification (alert + mutable-content: 1), does iOS grant notification grace tokens that bypass standard _DASWidgetBudget deductions? WidgetKit Push Notification Delivery & Rendering Inconsistencies on iOS 26: When sending direct WidgetKit APNs pushes (apns-push-type: widgets), we observe 3 distinct, inconsistent behaviors in production on iOS 26: a) Successful Instant Update: APNs push arrives → WidgetKit wakes up immediately → getTimeline() executes (<0.1s) → Home Screen widget displays the new image instantly. b) Complete Execution Drop: APNs push is sent by our server (HTTP 200 response from APNs api.push.apple.com) → WidgetKit never wakes up, and getTimeline() is completely ignored/not invoked by iOS. c) Execution Success but Screen Bitmap Stale: APNs push arrives → getTimeline() wakes up, executes, and loads the image successfully from disk (UIImage(contentsOfFile:) returns a valid image) → completion(Timeline(entries: [entry])) returns → BUT the displayed image on the Home Screen does NOT change or repaint until the user opens the main app. Questions for DTS Engineers: Why does iOS 26 occasionally drop getTimeline invocation for direct apns-push-type: widgets pushes even when APNs returns HTTP 200? Is Image(uiImage:) rendering inside WidgetKit subject to view hierarchy caching if the SimpleEntry struct date is updated but SwiftUI considers the view tree structurally identical? Does binding an explicit .id(assetPath) modifier to the Image view force SpringBoard's compositor layer to invalidate and repaint immediately upon getTimeline completion? Thank you for your guidance!

After the installation and upgrade of the iOS App coverage, the desktop widget became unavailable. When deleting and re-adding them, they could not be found in the widget gallery . The problem was solved after the phone system was restarted

I’m seeing a regression in the App Intents framework starting with iOS 27 Beta 3. An AppIntent returns another AppIntent using result(opensIntent:). On earlier iOS versions, the second intent’s perform() method is invoked as expected. Starting with iOS 27 Beta 3, the first intent completes, but the second intent’s perform() method is never called. Minimal example: import AppIntents import OSLog private let logger = Logger( subsystem: "com.example.AppIntentTest", category: "AppIntents" ) struct AAAIntent: AppIntent { static let title: LocalizedStringResource = "Run AAA" static let description = IntentDescription( "Runs AAA and returns BBB as the intent to open." ) func perform() async throws -> some IntentResult & OpensIntent { logger.notice("AAAIntent.perform() called") return .result(opensIntent: BBBIntent()) } } struct BBBIntent: AppIntent { static let title: LocalizedStringResource = "Run BBB" func perform() async throws -> some IntentResult { logger.notice("BBBIntent.perform() called") // The actual action would be performed here. return .result() } } Observed behavior on iOS 27 Beta 3: AAAIntent.perform() is called. AAAIntent.perform() returns .result(opensIntent: BBBIntent()). BBBIntent.perform() is never called. No error is presented to the user. Expected behavior: After AAAIntent returns BBBIntent through result(opensIntent:), the system should invoke BBBIntent.perform(), as it did on previous iOS versions. The same implementation works correctly on: before iOS 27 beta3 The issue reproduces on: Device: All iOS Device iOS: 27 Beta 3 I have also tested the following without resolving the problem: Reinstalling the app Recreating the shortcut Restarting the device Confirming through unified logging that BBBIntent.perform() is not entered This appears to be a system regression because the API remains available and the same application code works on earlier iOS versions. For required business logic, I can work around the problem by moving the shared operation out of BBBIntent.perform() and invoking it directly from AAAIntent. However, that changes the intended OpensIntent flow and does not restore the documented behavior of result(opensIntent:). I submitted this issue through Feedback Assistant two weeks ago: Feedback ID: FB23616137 Current Feedback Assistant status: Open Has anyone else encountered this behavior on iOS 27 Beta 3 or later? Is this a known App Intents regression, or has the expected behavior of result(opensIntent:) changed in iOS 27? If this behavior has intentionally changed, what is the recommended replacement for chaining or handing off to a second AppIntent?

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!

Hello everyone, I am encountering an inconsistent typography behavior when developing for WidgetKit. Specifically, there is no native serif font fallback for Chinese characters (CJK) in the Widget environment, whereas Latin characters are fully supported. When using the .serif design modifier in SwiftUI: Text("Hello 世界").font(.system(size: 16, design: .serif)) English/Latin characters ("Hello"): System correctly renders using the pre-installed serif font (New York). Chinese characters ("世界"): System ignores the .serif design and falls back to the default sans-serif font (PingFang SC). Can I find any pre-installed native serif font for CJK in iOS that I can reliably invoke within my Widget Extension without bundling .ttf files? If not, do you have plans to map Font.design(.serif) to a pre-installed CJK serif font in future iOS releases so I can maintain design consistency across my localized widgets? Thank you for any insights or recommended workarounds.

Some users are reporting that they don't see Live Activities, but our logs show that the trigger was sent successfully. Is there a way to investigate on the client side why the Live Activity didn't appear? Logs on client side? anything?