Hello, I found that if you apply the new .sidebarAdaptable tab view style, the accessibility identifiers of tab bar buttons are missing. import SwiftUI struct ContentView: View { var body: some View { TabView { Tab("Received", systemImage: "tray.and.arrow.down.fill") { Text("Received") } .accessibilityIdentifier("tab.received") // 👀 Tab("Sent", systemImage: "tray.and.arrow.up.fill") { Text("Sent") } .accessibilityIdentifier("tab.sent") // 👀 Tab("Account", systemImage: "person.crop.circle.fill") { Text("Account") } .accessibilityIdentifier("tab.account") // 👀 } .tabViewStyle(.sidebarAdaptable) // 👈 if remove this, ax identifiers are ok } } #Preview { ContentView() } The identifiers automatically appear after a few seconds. But this behaviour breaks a lot of the UI test cases.

Hello everyone! I've encountered an issue related to SwiftUI and StoreKit. Please take a look at the SwiftUI code snippet below: import SwiftUI struct ContentView: View { var body: some View { NavigationStack { List { NavigationLink { Page1() } label: { Text("Go to Page 1") } } } } } struct Page1: View { @Environment(\.dismiss) private var dismiss @State private var string: String = "" var body: some View { List { NavigationLink { List { Page2(string: $string) .simpleValue(4) } } label: { Text("Tap this button will freeze the app") } } .navigationTitle("Page 1") } } struct Page2: View { @Binding var string: String? init(string: Binding<String>) { self._string = Binding(string) } var body: some View { Text("Page 2") } } extension EnvironmentValues { @Entry var simpleValue: Int = 3 } extension View { func simpleValue(_ value: Int) -> some View { self.environment(\.simpleValue, value) } } This view runs normally until the following symbol is referenced anywhere in the project: import StoreKit extension View { func notEvenUsed() -> some View { self.manageSubscriptionsSheet(isPresented: .constant(false)) } } It seems that once the project links the View.manageSubscriptionsSheet(isPresented:) method, regardless of whether it's actually used, it causes the above SwiftUI view to freeze. Steps to Reproduce: Clone the repository: https://github.com/gongzhang/StrangeFreeze Open it in Xcode 16 and run on iOS 17-18.1 Navigate to the second page and tap the button, causing the app to freeze. Remove manageSubscriptionsSheet(...), then everything will work fine

Hi everyone, I’ve encountered an issue where using a popover inside the toolbar of a Catalyst app causes a crash on macOS 26 beta 5 with Xcode 26 beta 5. Here’s a simplified code snippet: import SwiftUI struct ContentView: View { @State private var isPresentingPopover = false var body: some View { NavigationStack { VStack { } .padding() .toolbar { ToolbarItem { Button(action: { isPresentingPopover.toggle() }) { Image(systemName: "bubble") } .popover(isPresented: $isPresentingPopover) { Text("Hello") .font(.largeTitle) .padding() } } } } } } Steps to reproduce: Create a new iOS app using Xcode 26 beta 5. Enable Mac Catalyst (Match iPad). Add the above code to show a Popover from a toolbar button. Run the app on macOS 26, then click the toolbar button. The app crashes immediately upon clicking the toolbar button. Has anyone else run into this? Any workarounds or suggestions would be appreciated! Thanks!

Hi everyone! I've noticed a color rendering issue with Home Screen widgets on iOS 26: the colors displayed in widgets are inconsistent with those shown inside the app. At first, I suspected this might be caused by differences in color spaces, but even after explicitly specifying the color space for SwiftUI.Color or UIColor, the widget colors remain incorrect. Steps to reproduce: Create a new iOS project in Xcode 26 beta 6. Add a new Widget Extension target. Use the following Widget view code: struct MyWidgets: Widget { let kind: String = "MyWidgets" var body: some WidgetConfiguration { StaticConfiguration(kind: kind, provider: Provider()) { entry in let white = Color(.sRGB, red: 1, green: 1, blue: 1) let veryLightGray = Color(.sRGB, red: 0.96, green: 0.96, blue: 0.96) let lightGray = Color(.sRGB, red: 0.9, green: 0.9, blue: 0.9) VStack(spacing: 0) { Rectangle() .foregroundStyle(veryLightGray) // 👈 Rectangle() .foregroundStyle(lightGray) // 👈 } .containerBackground(white, for: .widget) // 👈 } .configurationDisplayName("My Widget") } } ⬆️ In-app, the colors are correct: the top block is a very light gray (white=0.96)✅, and the bottom block is a regular gray (white=0.90)✅. However, on the Home Screen widget, the result is as follows: ⬆️ The top light gray block blends completely into the white background and is indistinguishable; the bottom gray block also appears lighter than it does in-app ❌. This issue occurs both on the simulator and on real devices. (Interestingly, the colors are correct in the Xcode Preview.) Whether I declare colors in code (SwiftUI.Color or UIColor) or in the Asset Catalog, the widget's color rendering does not match expectations. What's even stranger is that if I add an extra pure white block (white=1.0) to the view, it immediately affects all the colors in the widget: This whole behavior makes it very difficult to set accurate colors for widgets on iOS 26. While it seems related to glass effect rendering and color space handling, I still feel there might be a bug in the implementation.

Hi everyone! I've encountered an issue on Mac Catalyst: using the latest inspector modifier causes abnormal Sidebar and Columns state in NavigationSplitView. Sample Code: struct ContentView: View { @State private var isPresented = false var body: some View { NavigationSplitView { List { ForEach(0..<20, id: \.self) { item in Text("Item \(item)") } } } content: { List { ForEach(0..<20, id: \.self) { item in Text("Item \(item)") } } } detail: { List { } } .inspector(isPresented: $isPresented) { Form { } } } } Steps to reproduce: Xcode 16 beta 7, create a new iOS project Paste the code above Enable Mac Catalyst Run on Mac (macOS 15 beta 9) Press Command+N three times to open 3 new windows Click the Sidebar Toggle button The issue occurs (see screenshot below) Through testing, I found that as long as the inspector modifier is attached, the issue occurs. Also, the problem only appears in the 3rd and subsequent newly opened windows—the first two windows work as expected. FB20061521

Hello! My app has been experiencing some strange crashes in the last few months. The crash log shows it as a Watchdog timeout error of 0x8BADF00D. I knew about this error code before, especially since here is the documentation about addressing-watchdog-terminations. But actually, the call stack shows that the crash appears in dydl and it seems that my app code has not been executed yet. Does anyone know the cause of this problem please? I have observed this crash on iOS 15.6, 15.5, 15.4, and earlier versions. Incident Identifier: 82D9B8D8-88B3-4016-9CB5-5AE280006628 Hardware Model: iPhone10,6 Process: *** [297] Path: /private/var/containers/Bundle/Application/FDF7C78A-E217-482E-A20C-D602C117EB68/***.app/*** Identifier: com.***.*** Version: 3.1 (7774) AppStoreTools: 13C90b AppVariant: 1:iPhone10,6:15 Code Type: ARM-64 (Native) Role: unknown Parent Process: launchd [1] Coalition: com.***.*** [466] Date/Time: 2022-03-18 07:20:38.2452 +0200 Launch Time: 2022-03-18 07:19:37.6871 +0200 OS Version: iPhone OS 15.4 (19E241) Release Type: User Baseband Version: 5.02.02 Report Version: 104 Exception Type: EXC_CRASH (SIGKILL) Exception Codes: 0x0000000000000000, 0x0000000000000000 Exception Note: EXC_CORPSE_NOTIFY Termination Reason: FRONTBOARD 2343432205 &lt;RBSTerminateContext| domain:10 code:0x8BADF00D explanation:process-launch watchdog transgression: application&lt;com.***.***&gt;:297 exhausted real (wall clock) time allowance of 60.00 seconds ProcessVisibility: Background ProcessState: Running WatchdogEvent: process-launch WatchdogVisibility: Background WatchdogCPUStatistics: ( "Elapsed total CPU time (seconds): 283.260 (user 283.260, system 0.000), 78% CPU", "Elapsed application CPU time (seconds): 0.021, 0% CPU" ) reportType:CrashLog maxTerminationResistance:Interactive&gt; Triggered by Thread: 0 Thread 0 Crashed: 0 dyld 0x0000000104f82b60 ___ZNK5dyld46Loader13resolveSymbolER11DiagnosticsRNS_12RuntimeStateEiPKcbbU13block_pointerFvjjRKNS0_14ResolvedSymbolEEb_block_invoke.94 + 428 (Loader.cpp:1539) 1 dyld 0x0000000104f71308 dyld4::Loader::resolveSymbol(Diagnostics&amp;, dyld4::RuntimeState&amp;, int, char const*, bool, bool, void (unsigned int, unsigned int, dyld4::Loader::ResolvedSymbol const&amp;) block_pointer, bool) const + 348 (Loader.cpp:1504) 2 dyld 0x0000000104f84cd8 ___ZNK5dyld416JustInTimeLoader17forEachBindTargetER11DiagnosticsRNS_12RuntimeStateEU13block_pointerFvjjRKNS_6Loader14ResolvedSymbolEEbU13block_pointerFvS8_RbESD__block_invoke.46 + 124 (JustInTimeLoader.cpp:621) 3 dyld 0x0000000104f9a9d4 ___ZNK5dyld313MachOAnalyzer25forEachBindTarget_OpcodesER11DiagnosticsbU13block_pointerFvRKNS0_14BindTargetInfoERbES8__block_invoke.408 + 64 (MachOAnalyzer.cpp:5782) 4 dyld 0x0000000104f9a794 dyld3::MachOAnalyzer::forEachBind_OpcodesWeak(Diagnostics&amp;, dyld3::MachOLoaded::LinkEditInfo const&amp;, dyld3::MachOFile::SegmentInfo const*, void (char const*, dyld3::MachOLoaded::LinkEditInfo const&amp;... + 728 (MachOAnalyzer.cpp:6161) 5 dyld 0x0000000104f99b60 dyld3::MachOAnalyzer::forEachBindUnified_Opcodes(Diagnostics&amp;, bool, void (unsigned long long, dyld3::MachOAnalyzer::BindTargetInfo const&amp;, bool&amp;) block_pointer, void (unsigned long long, dyld3::Ma... + 632 (MachOAnalyzer.cpp:5763) 6 dyld 0x0000000104f9975c dyld3::MachOAnalyzer::forEachBindTarget_Opcodes(Diagnostics&amp;, bool, void (dyld3::MachOAnalyzer::BindTargetInfo const&amp;, bool&amp;) block_pointer, void (dyld3::MachOAnalyzer::BindTargetInfo const&amp;, bool&amp;... + 148 (MachOAnalyzer.cpp:5773) 7 dyld 0x0000000104f84304 dyld4::JustInTimeLoader::forEachBindTarget(Diagnostics&amp;, dyld4::RuntimeState&amp;, void (unsigned int, unsigned int, dyld4::Loader::ResolvedSymbol const&amp;) block_pointer, bool, void (dyld4::Loader::Reso... + 176 (JustInTimeLoader.cpp:608) 8 dyld 0x0000000104f732d4 dyld4::JustInTimeLoader::applyFixups(Diagnostics&amp;, dyld4::RuntimeState&amp;, dyld4::DyldCacheDataConstLazyScopedWriter&amp;, bool) const + 388 (JustInTimeLoader.cpp:412) 9 dyld 0x0000000104f79758 dyld4::prepare(dyld4::APIs&amp;, dyld3::MachOAnalyzer const*) + 1592 (dyldMain.cpp:573) 10 dyld 0x0000000104f783b0 start + 412 (dyldMain.cpp:864) Thread 0 crashed with ARM Thread State (64-bit): x0: 0x00000001c076a000 x1: 0x00000000000002f1 x2: 0x000000016b4aa198 x3: 0x000000016b4aa190 x4: 0x0000000000000001 x5: 0x000000016b4ac638 x6: 0x0000000000000000 x7: 0x000000016b4ad160 x8: 0x0000000180000000 x9: 0x000000034076a000 x10: 0x0000000000000000 x11: 0x0000000000000001 x12: 0x0000000104bf278b x13: 0x0000000000000000 x14: 0x00000001ffd94d24 x15: 0x0000000000000001 x16: 0x0000000104fa5070 x17: 0x0000000000000a06 x18: 0x0000000000000000 x19: 0x000000016b4ac6c8 x20: 0x0000000104c50dc0 x21: 0x0000000000000001 x22: 0x000000020b59cad8 x23: 0x000000016b4ac630 x24: 0x000000016b4aa1b0 x25: 0x0000000000000002 x26: 0x0000000000000247 x27: 0x0000000104c55a90 x28: 0x0000000000000770 fp: 0x000000016b4ac6b0 lr: 0x0000000104f82b60 sp: 0x000000016b4aa1b0 pc: 0x0000000104f82b60 cpsr: 0x20000000 esr: 0x92000007 (Data Abort) byte read Translation fault Binary Images: 0x104f60000 - 0x104fb3fff dyld arm64 &lt;5c4972a8ef8132dca84842cc7f7874cf&gt; /usr/lib/dyld EOF

On iOS16, I can't open the audio chart details page via the Audio Graph defined by AXChartDescriptorRepresentable. When trying to open chart details through VoiceOver, the screen flashes for a moment (the content seems to be correct) and then disappears immediately. This behavior was normal on iOS 15, but it doesn't work from iOS 16 beta to RC. I have uploaded the sample project to https://github.com/gongzhang/audio-graph-example. It needs to be running on a physical iOS 16 device with VoiceOver enabled to operate. Run the sample project Open the Audio Graph detail page, by using VoiceOver, swiping down until you hear Chart details. The chart detail page disappears immediately. Reported FB11479931

I found that watchOS 9.2 seems to break the complicationForeground() modifier. In previous systems, a View modified by complicationForeground() was rendered white, while an unmodified View was rendered with the watch face tint color. This is the correct behavior. However, in watchOS 9.2, this behavior has been reversed. The View modified by complicationForeground() renders the tint color, and the opposite is white‽ This causes third-party complications to look very inconsistent on tinted watch faces. Of course, this issue belongs to ClockKit, and I'm not sure if there are similar issues in the new WidgetKit. Will this issue be fixed please?

Hello! I'm trying to donate an Intent to iOS using IntentDonationManager, following the methods described in the documentaion. try await IntentDonationManager.shared.donate(intent: MyIntent()) // succeeded However, I'm not seeing any effect of this action anywhere in the system (iOS 17 and 16). I have debugged it on both the simulator and a physical device, and I have also enabled the "Display Recent Shortcuts" toggle in the developer settings, but I still don't see any relevant suggestions appearing. Similarly, the issue also occurs with the old SiriKit framework, where INInteraction.donate(completion:) doesn't seem to have any observable effect. I recall that in iOS 15, the simulator would immediately present the donated Shortcut action on the lock screen and Spotlight page. However, starting from iOS 16 and continuing to the current iOS 17 beta 1/2, I haven't been able to achieve the same behavior using the same code. Another similar report: https://developer.apple.com/forums/thread/723109 So is there any way to test or verify the results of this donation action?

Hi, I'm trying to apply the Vibrancy text style to SwiftUI Text. However, I didn't find proper API to do this. As the session video wwdc2023-10076 said, vibrancy brightens foreground content that displays on top of a material and works by pulling light and color forward from what's behind it. However, when I set .secondary foreground style to a Text, it's just some graycolor with a constant alpha value. It there any other API to achieve the vibrancy style? Thanks!

In Xcode 15 beta 6, I found that when building visionOS apps, #if os(iOS) is no longer considered part of the project. This behavior is different from beta 1 to beta 5. Is this intentional? This change has caused third-party dependencies that use #if os(iOS) and have not yet explicitly supported visionOS to fail to compile. Is there a way to switch back to the old behavior? After all, requiring all third-party dependencies to explicitly support visionOS is quite difficult.

Hello, My iOS app will support running on visionOS in compatible mode and I want to do some optimizations for the UI. Is there a flag can help to determine this compatible mode on visionOS? (Just like ProcessInfo.isiOSAppOnMac) Thanks! FB12757613

Hello everyone! I recently released the native visionOS version of my app on TestFlight. I noticed that there are 8 crashes on Vision Pro on the App Store Connect website, but I can't get these crash logs in Xcode Organizer (the crash list of visionOS app is empty). Is there any way to get these crash logs now? I don't have a physical Vision Pro device so I can't reproduce the crash, I can only rely on the crash logs.

Hello everyone! I've noticed that Xcode 15.2 is still not selectable as a build environment on Xcode Cloud, even though the official version of 15.2 has been out for several days. Is this part of the plan? Or is it a system bug? 🤔 I need 15.2 as the release environment, including support for building visionOS apps. I have already submitted FB13531029.

⌚️Hello, I've noticed in watchOS 10 that when a complication is in the Smart Stack, the value of WCSession.isComplicationEnabled is false. I'm not sure if this is intentional or a bug. It seems trivial at first glance, but it actually affects the communication mechanism mentioned in Implementing Two-Way Communication Using Watch Connectivity. In the following two scenarios, if the user has only added the app's complication to the Smart Stack, then the watch app will not be able to communicate properly with the iOS app. Scenario 1 - WCSession.transferCurrentComplicationUserInfo() // update complications from the iOS app if WCSession.default.isComplicationEnabled { let userInfoTransfer = WCSession.default.transferCurrentComplicationUserInfo(userInfo) // ... } As described in Implementing Two-Way Communication Using Watch Connectivity, when the iOS app proactively updates the data of the watch app, since WCSession.isComplicationEnabled is false, WCSession will refuse to transfer any data. This causes the standalone complication in Smart Stack to not be updated. Scenario 2 - WKApplicationRefreshBackgroundTask When the watch app uses WKApplication.scheduleBackgroundRefresh() to periodically update data, as long as the user has added the app's complication to the watch face, the corresponding WKApplicationRefreshBackgroundTask can be executed periodically in the background to fetch data. However, if the user has only added complication to the Smart Stack, then the watch app will be completely purged, and the background task will not be executed at all. Although WCSession.isComplicationEnabled is not directly used in this scenario, its behavior appears to be the same, that is, the complication in the Smart Stack is not considered a complication by the system. Should I submit a bug report?