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, When I turn on tinted mode on iOS 18, I noticed that the emojis in the widgets are not rendered properly. The widget in the following screenshot is the template project created by Xcode 16.

Hello, I noticed a small mistake in the Human Interface Guidelines (HIG). On the page HIG > Components > System Experiences > Widget > watchOS Widget Dimensions, scroll down to the bottom. In the "watchOS widget dimensions" section, the sizes in the table are in pixels (px), not points (pt) actually. However, the table header indicates the sizes should be in points (pt). Page link: https://developer.apple.com/design/human-interface-guidelines/widgets#watchOS-widget-dimensions For example, the widget size in the Smart Stack on a 49mm watch should be 192x81.5 pt (or 382x163 px), not 382x163 pt. This size can be verified with the information provided here: https://developer.apple.com/documentation/watchos-apps/supporting-multiple-watch-sizes/. https://developer.apple.com/documentation/watchkit/wkinterfacedevice/1620974-screenscale

Hello, I'm so glad that now you can scroll the list to top by tapping the tab bar ion on iOS 18. However, the current implementation on iOS 18 beta 8 has a little layout issue. import SwiftUI struct ContentView: View { var body: some View { TabView { Tab("Home", systemImage: "house") { NavigationStack { List { ForEach(0..<100) { i in Text("\(i)") } } .navigationTitle("Root") } } } } } #Preview { ContentView() } Tap the tab icon: Result:

Recently, I’ve noticed that the Archive workflow on Xcode Cloud frequently fails randomly with the following error: ❌ Exporting for App Store Distribution failed. Please download the logs artifact for more information I’m not sure if this issue is on my side or if it’s related to Xcode Cloud itself. Has anyone encountered a similar problem?

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!

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

Hello everyone! Recently my watch app has been receiving a lot of crash reports, all of them from watchOS 9.0 and 9.1. The crash reports suggest SIGNAL 11 Segmentation fault: 11 crash, and the call stack is located in the WatchConnectivity framework -[WCSession onqueue_ sendMessageData:replyHandler:errorHandler:dictionaryMessage:] + 340 (WCSession.m:674). Now it has become the most common crash of my app. As I understand it, Segmentation fault: 11 suggests some binary or compiler-level problem. Maybe the way I'm calling the API is triggering a problem within the system? Sample Crash Log: Incident Identifier: xxx Hardware Model: Watch6,9 Process: WatchApp [2338] Path: xxx Identifier: io.qifeng.HiCoffee.watchkitapp Version: 4.1.1 (7992) AppStoreTools: 14A305 AppVariant: 1:Watch6,9:8 Code Type: 0200000C (Native) Role: unknown Parent Process: launchd [1] Coalition: io.qifeng.HiCoffee.watchkitapp [450] Date/Time: 2022-10-11 07:14:55.0777 +0200 OS Version: Watch OS 9.0 (20R361) Release Type: User Baseband Version: 5.00.00 Report Version: 104 Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Subtype: KERN_INVALID_ADDRESS at 0x0000000000000004 Exception Codes: 0x0000000000000001, 0x0000000000000004 VM Region Info: 0x4 is not in any region. Bytes before following region: 68141052 REGION TYPE START - END [ VSIZE] PRT/MAX SHRMOD REGION DETAIL UNUSED SPACE AT START ---> __TEXT 40fc000-4100000 [ 16K] r-x/r-x SM=COW ....app/WatchApp Termination Reason: SIGNAL 11 Segmentation fault: 11 Terminating Process: exc handler [2338] Triggered by Thread: 7 Thread 0 name: Thread 0: 0 WatchApp 0x000000000418f1dc @objc ComplicationController2.getComplicationDescriptors(handler:) + 0 (<compiler-generated>:0) 1 libdispatch.dylib 0x000000002ba6b590 _dispatch_call_block_and_release + 24 (init.c:1518) 2 libdispatch.dylib 0x000000002ba6cd7c _dispatch_client_callout + 16 (object.m:560) 3 libdispatch.dylib 0x000000002ba7a114 _dispatch_main_queue_drain + 800 (inline_internal.h:2631) 4 libdispatch.dylib 0x000000002ba79de4 _dispatch_main_queue_callback_4CF + 40 (queue.c:7804) ... Thread 1 name: Thread 1: 0 libsystem_kernel.dylib 0x000000002c81c18c __ulock_wake + 8 ... Thread 2 name: Thread 2: 0 libsystem_kernel.dylib 0x000000002c81b0f8 kevent_qos + 8 ... Thread 6 name: Thread 6: 0 WatchConnectivity 0x000000005350996c __31-[WCXPCManager setupConnection]_block_invoke_2 + 0 (WCXPCManager.m:92) 1 libdispatch.dylib 0x000000002ba6b590 _dispatch_call_block_and_release + 24 (init.c:1518) 2 libdispatch.dylib 0x000000002ba6cd7c _dispatch_client_callout + 16 (object.m:560) 3 libdispatch.dylib 0x000000002ba73968 _dispatch_lane_serial_drain + 548 (inline_internal.h:2631) 4 libdispatch.dylib 0x000000002ba74454 _dispatch_lane_invoke + 388 (queue.c:3939) 5 libdispatch.dylib 0x000000002ba7e2a4 _dispatch_workloop_worker_thread + 628 (queue.c:6766) 6 libsystem_pthread.dylib 0x000000006580947c _pthread_wqthread + 280 (pthread.c:2618) 7 libsystem_pthread.dylib 0x000000006580951c start_wqthread + 8 Thread 7 name: Thread 7 Crashed: ☠️☠️☠️ 0 libdispatch.dylib 0x000000002ba81fd4 dispatch_source_cancel + 8 (inline_internal.h:231) 1 WatchConnectivity 0x00000000534f84b4 __81-[WCSession onqueue_sendMessageData:replyHandler:errorHandler:dictionaryMessage:]_block_invoke + 48 (WCSession.m:675) 2 libdispatch.dylib 0x000000002ba6cd7c _dispatch_client_callout + 16 (object.m:560) 3 libdispatch.dylib 0x000000002ba6fe7c _dispatch_continuation_pop + 388 (inline_internal.h:2631) 4 libdispatch.dylib 0x000000002ba81a90 _dispatch_source_invoke + 1760 (source.c:596) 5 libdispatch.dylib 0x000000002ba7cfe8 _dispatch_root_queue_drain + 332 (inline_internal.h:0) 6 libdispatch.dylib 0x000000002ba7d7a4 _dispatch_worker_thread2 + 168 (queue.c:6969) 7 libsystem_pthread.dylib 0x0000000065809440 _pthread_wqthread + 220 (pthread.c:2631) 8 libsystem_pthread.dylib 0x000000006580951c start_wqthread + 8 Thread 8 name: Thread 8: 0 libsystem_kernel.dylib 0x000000002c81e210 kevent + 8 ... Thread 9: 0 WatchApp 0x000000000458cd70 monitorCachedData + 756 (KSCrashCachedData.c:0) ... Thread 10: 0 libsystem_pthread.dylib 0x0000000065809514 start_wqthread + 0 I am currently unable to reproduce this problem on my own. Do you have any good suggestions for me?

Just found the rounded corners of Smart Stack previews are incorrect. They rendered as circular rounded corners, which are not consistent with other Apple Watch previews and also the physical Apple Watch. They should be changed to continuous rounded corners.

Hello, In WidgetKit, I have to write multiple #Preview macros for each family the widget supports. So is there any better way to write the #Preview? (Although I can use the legacy PreviewProvider but it does not support timeline to test transition animation.) #import WidgetKit #import SwiftUI struct DailyCaffeineWidget: Widget { ... } @available(iOS 17.0, *) #Preview("Inline", as: .accessoryInline) { DailyCaffeineWidget() } timelineProvider: { previewTimelineProvider() } @available(iOS 17.0, *) #Preview("Circular", as: .accessoryCircular) { DailyCaffeineWidget() } timelineProvider: { previewTimelineProvider() } @available(iOS 17.0, *) #Preview("Rectangular", as: .accessoryRectangular) { DailyCaffeineWidget() } timelineProvider: { previewTimelineProvider() } @available(iOS 17.0, *) #Preview("Small", as: .systemSmall) { DailyCaffeineWidget() } timelineProvider: { previewTimelineProvider() } @available(iOS 17.0, *) #Preview("Medium", as: .systemMedium) { DailyCaffeineWidget() } timelineProvider: { previewTimelineProvider() } ...

⌚️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?

Hello, I noticed that the CADisplayLink seems to emit incorrect targetTimestamp and timestamp in the iOS 18 simulator. If you compute the actual duration of a frame, the duration is always a negative number. This only occurs in the iOS 18 simulator.

Hello! I wanted to bring up an issue I've encountered with .popover(isPresented:). It does not show up above a TabView on iOS 18. This issue occurs on an iPad or on an iPhone when using the .popover compact adaptation modifier. (Xcode 16 beta 6 + iOS 18 beta 7)

Hello, Just noticed an issue with the .safeAreaInset() and .safeAreaPadding() modifiers. On iOS 18 beta 8, I'm unable to scroll the list or any other scrollable views within the safe area. This behavior is different compared to iOS 17/16. For example, adding a floating button using the .safeAreaInset() modifier: On iOS 18, the list cannot be scrolled or interacted within the bottom circled area.

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.