I created a new report: FB23072437

I also got the same error: 'extension' macro cannot be attached to extension (extension of 'CJLogAppEntity')

For your case: Contacts probably maps to an existing schema What kind of schema would this map to? I haven't found a suitable candidate.

So if I understand this correctly, adopting IndexedEntity on its own (without schema-based entities) should be enough to get semantic understanding from Siri for the 'data'. For eg. "which contact has the next birthday in " should work? But to get actionable 'intents', the intents would have to conform to one of the fixed schemas? Also, is there a way to request an expansion of the set of schemas and domains? It seems a little limited at this point.

I joined the waitlist a couple of hours after the keynote, and I still haven't been approved.

The issue isn't just with CKSyncEngine. I have a custom CloudKit-based syncing setup, which uses CKRecordZoneSubscription to listen and respond to changes in a zone, and the remote notifications aren't working with that either. I filed FB22380044 ... hopefully this can be patched up with a quick update, as it would break so many apps

To add more context: the same callout view works fine in UIKit on iOS26. I filed FB20975128 with a reproducible project, if that helps. Please suggest some workaround that might work.

Hi. Sorry I didn't specify, but I'm using UIKit. I figured I can use UIMainMenuSystem.Configuration().documentPreference = .removed and that removes the unnecessary File menu items. It still shows a 'Close Window' command instead of a 'Quit' command though.

Same issue in Beta 3. Filed FB18411347

Nevermind ... I was checking the wrong CKRecord's fields.

Pause / continue still crashes. Just removing the breakpoint helps.

Hi, I have the same issue. It was there in Beta1 as well, and I spoke to someone in the WWDC labs and they acknowledged it was an issue they were working on, but doesn't look they have fixed it for Beta 2. Happens when building in Xcode Beta 2 on macOS26 Beta 2 as well. I filed FB18411347

Thanks for that. I tried it, and now I can save / fetch the NSData from Core Data after transforming it ... BUT it doesn't get rendered as an attributed string (i.e. the formatting gets lost). This is the code for the next TextEditor in iOS26 that takes an AttributedString for its binding. Is there something wrong that I'm doing? struct AttributedDetailView: View { @ObservedObject var item: Item @State private var notesText = AttributedString() var body: some View { VStack { TextEditor(text: $notesText) .padding() .onChange(of: notesText) { item.attributedString = NSAttributedString(notesText).toNSData() } } .onAppear { if let nsattributed = item.attributedString?.toAttributedString() { notesText = AttributedString(nsattributed) } else { notesText = "" } } .onDisappear { item.attributedString = NSAttributedString(notesText).toNSData() do { try item.managedObjectContext?.save() } catch { print("core data save error = \(error)") } } } }

I'm also having this problem! Just posting some SwiftUI code with some code sample.

Just to follow up on this (as it's still an issue in macOS 15.4), based on your feedback, the following should be equivalent in performance (but they're not): // 1. the 'fast' version struct ContentView: View { @Environment(\.managedObjectContext) private var viewContext @FetchRequest( fetchRequest: Item.myFetchRequest(), animation: .default) private var items: FetchedResults<Item> var body: some View { NavigationStack { List { ForEach(items) { item in Text("\(item.itemNumber ?? "None")") } } } } } // 2. The 'slow' version struct ContentView: View { @Environment(\.managedObjectContext) private var viewContext @FetchRequest( fetchRequest: Item.myFetchRequest(), animation: .default) private var items: FetchedResults<Item> var body: some View { NavigationStack { List { ForEach(items) { item in ContentItemView(item: item) //Text("\(item.itemNumber ?? "None")") } } } } } // extracted subview struct ContentItemView: View { let item: Item var body: some View { Text("\(item.itemNumber ?? "None")") } } If you add 5k rows here, and try to drag the window scrubber up and down to scroll through the list, you can see the performance problems in the 2nd version. The number of subviews in each row are equal in both implementations. Your explanation makes sense for iOS but not for macOS, where there's some performance problem under the hood.