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
Selecting any option will automatically load the page
Post
Replies
Boosts
Views
Activity
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.
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 when using Sheet + ScrollView on Mac Catalyst: the buttons in the toolbar appear with an abnormal gray color.
import SwiftUI
struct ContentView: View {
var body: some View {
VStack {
}
.sheet(isPresented: .constant(true)) {
Sheet()
}
}
}
struct Sheet: View {
var body: some View {
NavigationStack {
ScrollView { // <-- no issue if use List
}
.toolbar {
Button(action: {}) { // <-- 👀 weird gray color
Image(systemName: "checkmark")
}
}
}
}
}
Steps to Reproduce:
On macOS 26.0 beta 9, use Xcode 26.0 beta 7 to create an iOS project and enable Mac Catalyst.
Paste the code above.
Select the Mac Catalyst scheme and run the project.
The buttons in the toolbar show a strange gray appearance.
If you change the ScrollView to a List in the code, the issue does not occur.
FB20120285
Hi everyone,
Starting today, my Xcode Cloud CI workflow can no longer successfully build iOS/macOS/visionOS targets. The Archive step does not report any errors, but the xcodebuild command hangs indefinitely and eventually fails with the following message:
The step invocation hit a user timeout. The xcodebuild archive invocation timed out. No activity has been detected on stdout, stderr or the result bundle in 30 minutes.
My iOS and macOS targets can still be built, but the build time has increased by 2-3x compared to before. That's interesting. After I removed the visionOS target, the iOS target also failed to build.
Additionally, since today, I’ve noticed a significant increase in network-related errors in Xcode Cloud. There have been multiple failures to download dependencies from Homebrew or GitHub.
I have confirmed that CI versions which previously built successfully are now failing, while running the same build commands locally works fine. Based on these observations, I suspect there may be an issue with the Xcode Cloud environment itself.
Has anyone else encountered similar problems? Any suggestions or updates would be appreciated!
Thanks!
I have a new Xcode project, and the git repository for this project contains a submodule. When I try to grant access to this submodule, App Store Connect refreshes the page directly due to an error encountered. The grant is not successful.
When I open the browser's Inspector, I can see that there are some requests in Network with 503 errors. I suspect that it is these errors that are causing the page to refresh.
This git submodule is working fine in my other Xcode Cloud projects, which I used to be able to configure properly. But not anymore, this new project's Xcode Cloud is not working at all because of this issue.
Reported: FB11548470
In Xcode 15 beta 3 and beta 4, if you add a AppShortcuts.xcstrings catalog or legacy AppShortcuts.strings files to the project, the project will always fail to build due to the following error.
error: Unable to call validation: The data couldn’t be read because it isn’t in the correct format. (in target 'LearnAppShortcuts' from project 'LearnAppShortcuts')
Command ValidateAppShortcutStringsMetadata emitted errors but did not return a nonzero exit code to indicate failure
The error seems related to a cli called ValidateAppShortcutStringsMetadata.
Reproducing Steps
(1) In Xcode 15 beta 3/4, create a new iOS app project.
(2) Add an arbitrary AppIntent and AppShortcutsProvider.
import AppIntents
struct MyAction: AppIntent {
static let title: LocalizedStringResource = "My Action"
func perform() async throws -> some IntentResult {
return .result()
}
}
struct MyAppShortcts: AppShortcutsProvider {
static var appShortcuts: [AppShortcut] {
AppShortcut(intent: MyAction(),
phrases: [
"Perform action with \(.applicationName)"
],
shortTitle: "Perform My Action",
systemImageName: "heart")
}
}
(3) Create a new AppShortcuts.xcstrings catalog file and add it to the iOS target
(4) Build the project. The string catalog will be updated as expected. However, the build will fail.
Topic:
App & System Services
SubTopic:
General
Tags:
App Intents
wwdc2023-10102
wwdc2023-10103
wwdc2023-10115
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.