I found that in Xcode 14.2 (Swift 5.7), the compiler is unable to check the API availability of PropertyWrappers. For example, SwiftUI.StateObject was introduced in iOS 14, but when compiling for iOS 13, the compiler doesn't give an error. This leads to runtime dylib errors. struct ContentView: View { class Data: ObservableObject {} @StateObject private var data = Data() // 🤔️ No compiler error when targeting iOS 13 var body: some View { Text("Hello") } } The app will crash on iOS 13. dyld: lazy symbol binding failed: Symbol not found: _$s7SwiftUI11StateObjectV12wrappedValueACyxGxyXA_tcfC However, when we use StateObject in a regular statement, the compiler gives an error as expected. This is the correct behavior. init() { _data = StateObject(wrappedValue: Data()) // 'StateObject' is only available in iOS 14.0 or newer } So, it seems that the availability check for PropertyWrappers is not working.

Hello, I found that ScrollViewProxy.scrollTo(_:anchor:) always crash on iOS 16 beta 1-7. As soon as the Section in the List changes, the ScrollViewProxy does not scroll properly to the specified cell. This issue only appeared on iOS 16. Sample Code (for Xcode 14) import SwiftUI struct ContentView: View {     @State private var hideSection1 = false     var body: some View {         ScrollViewReader { scrollView in             List {                 if !hideSection1 {                     Section(header: Text("Section 1")) {                         ForEach(1...10, id: \.self) { i in                             Text("\(i)")                         }                     }                 }                 Section(header: Text("Section 2")) {                     ForEach(11...20, id: \.self) { i in                         Text("\(i)")                     }                 }             }             .safeAreaInset(edge: .bottom, spacing: 0) {                 VStack {                     // Crash Steps:                     //   1. Tap "Go to 20", OK ✅                     //   2. Hide Section 1                     //   3. Tap "Go to 20" again <--- ☠️ crash                     Button("Go to 20") {                         withAnimation {                             scrollView.scrollTo(20, anchor: .center)                         }                     }                     Toggle("Hide Section 1", isOn: $hideSection1)                 }                 .padding()                 .background {                     Rectangle()                         .fill(.ultraThinMaterial)                         .ignoresSafeArea()                 }             }         }     } } struct ContentView_Previews: PreviewProvider {     static var previews: some View {         ContentView()     } } Crash Message *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'Attempted to scroll the collection view to an out-of-bounds section (1) when there are only 1 sections. Collection view: <SwiftUI.UpdateCoalescingCollectionView: 0x13c88cc00; baseClass = UICollectionView; frame = (0 0; 390 844); clipsToBounds = YES; autoresize = W+H; gestureRecognizers = <NSArray: 0x60000323fc60>; backgroundColor = <UIDynamicSystemColor: 0x600002922dc0; name = systemGroupedBackgroundColor>; layer = <CALayer: 0x600003c2f260>; contentOffset: {0, -47}; contentSize: {390, 498.66666666666669}; adjustedContentInset: {47, 0, 129.66666666666674, 0}; layout: <UICollectionViewCompositionalLayout: 0x13c510ed0>; dataSource: <_TtGC7SwiftUI31UICollectionViewListCoordinatorGOS_19SelectionManagerBoxOs5Never__: 0x13c513670>>.'

Hello! Two of my watch apps (HiCoffee and HiWater) occasionally have issues with complications not displaying properly on watchOS 9. I did NOT use the new WidgetKit to implement the complications, all the related code still uses the same previous ClockKit + SwiftUI. I have observed several different types of wrong behaviors. One specific complication cannot be displayed (rendered?), while others do work (from the same app). This indicates that my watch app is working properly. All complications on the face cannot be displayed. But the app logs indicates it's running properly. In addition, when you long press the face to edit complications, yet it can be displayed normally. Log shows CLKComplicationServer.sharedInstance().activeComplications always returns 0 no matter how many complications are added to the face. Also, the ComplicationController is NOT called by system. I'm not using WatchKit. This part of the code in my app has been working properly for a long time and has not been changed. But after the release of watchOS 9, I received a lot of feedback from users with this problem. So I think the problem is in watchOS 9. I haven't found a way to reproduce the problem yet. Any suggestions please?

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.

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!

The #warning complier directive seems broken in Xcode 15 beta 5. The warning messages are not shown in the Issue Navigator until you open the corresponding source file. #warning("some custom warning message")

In Xcode 15 beta 1 to 5, the watch face preview of accessoryRectangular and accessoryCircular are always rendered in tinted mode, even if you choose multicolor. (NOTE: Please don't ask me to provide diagnostic data for Preview. Because this issue is 100% reproducible.)

In Xcode 15 beta 5 + iOS 17 beta 4, the AppShortcuts (or maybe Shortcuts app) is broken. The AppShortcuts defined in AppShortcutsProvider are not shown up in the Shortcuts app any more. Reproduce Code import SwiftUI import AppIntents @main struct LearnShortcutsApp: App { var body: some Scene { WindowGroup { Text("Hello, world!") } } } 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") } }

When using NavigationStack and NavigationLink, even in very simple situations, the behavior is not normal. When tapping on a NavigationLink, the cell's selected state cannot be maintained. The selection effect is not visible when pushing and popping views. This makes it difficult for users to track their selected content and the current view. At the moment of tapping a NavigationLink, the scroll offset of the List jumps, which affects the experience very much. (Before tapping a cell, as long as the page is not at the top, it can be reproduced 100%)

Hello! In Xcode 15 beta 1-5, a large number of old Xcode Cloud entries are displayed in the Report Navigator. These old entries do not contain any content. This issue does not occur when viewing the same project in Xcode 14.

Xcode 15 and iOS 17 now adds extra padding to widget content, which is inconsistent with iOS 16. Run on iOS 16: Same code run on iOS 17, with extra paddings: struct WidgetView : View { var entry: Provider.Entry var body: some View { LicenseView(entry: entry) .background(Color("WidgetBackground")) .modifier { if #available(iOS 17.0, *) { $0.containerBackground(for: .widget) { Color.white // to highlight the padding on iOS 17 } } else { $0 } } } }

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.

This is new in Xcode 15 beta 5. Command SwiftCompile emitted errors but did not return a nonzero exit code to indicate failure. error: Invalid Swift parseable output message (malformed JSON): `0` (in target 'HiCoffee' from project 'HiCoffee') error: Invalid Swift parseable output message (malformed JSON): `1` (in target 'HiCoffee' from project 'HiCoffee') error: Invalid Swift parseable output message (malformed JSON): `{ "kind": "finished", ` (in target 'HiCoffee' from project 'HiCoffee') "name": "compile", "pid": -1139, "process": { "real_pid": 95136 }, "exit-status": 0 } Command SwiftCompile emitted errors but did not return a nonzero exit code to indicate failure

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 everyone! I noticed that the UISearchBar on visionOS automatically supports the Look-To-Dictate function. However, for a regular UITextView, I couldn't find the corresponding API. How can I make a UITextView support the Look-To-Dictate function? This is a great system feature. (I noticed there is a protocol called UILookToDictateCapable but no idea how to use it.)