The issue has been resolved with iOS 27 beta 3. Thanks!

I haven’t tested it myself, but as mentioned in this Forums post, the new Predicate(all:) initializer should be ideal for that!

Thanks a lot for your comment and things to consider! 🙏 I use that for different cases already – from small large text tweaks to custom grid layouts that change depending on window size – so I’ll check out the alternatives and see if it makes sense to switch.

@Frameworks Engineer Alright, I’ve created a feedback for this with a sample project: FB23045879

Checking back on that it seems to be working as expected in iOS 26. At least I get the sections now. 👍

Liquid glass should mainly be used on UI control elements that sit above the content. Also, currently, there's no dedicated support for liquid glass effects in Charts. It's a good idea to file enhancement requests with design justification and mock-ups. I understand that currently there’s no support for Liquid Glass in Swift Charts. Especially for actual chart elements I can see the reasoning behind it. Nevertheless, it’s quite a bummer that it isn’t supported for .annotation. I have a selection lollipop that bubbles up above the chart when the user interacts with the chart. As this is literally floating in front of the chart it would be great to add some glass effect to the container view (a HStack) of my annotation. I’ve already filed a feedback for specifically that (FB19110760). Feel free to join me with a dupe or for Apple check it out.

Thanks for the tip to avoid this. Just tested it with iPadOS 26.6 beta 1 and it still is an issue. 😕

This issue has been solved with the Xcode 26 RC and also the App Store version.

As posted in the other thread Steve4442 linked to: The way to go is the following (as John Siracusa) noted on Mastodon: Name your Tahoe .icon file the same as the name of your existing .appiconset in the Assets catalog. Set the ASSETCATALOG_OTHER_FLAGS build setting to: --enable-icon-stack-fallback-generation=disabled I can confirm that the Asset Catalog Other Flags still works with Xcode 26 RC! I’ve submitted two apps with that flag and both got approved by Apple. The App Store even displays the old icon in the iOS/macOS 18 App Store and the new icon in the iOS/macOS 26 App Store. You can see an example here in one of my apps.

Just want to confirm that the Asset Catalog Other Flags still works with Xcode 26 RC! I’ve submitted two apps with that flag and both got approved by Apple. The App Store even displays the old icon in the iOS/macOS 18 App Store and the new icon in the iOS/macOS 26 App Store. You can see an example here in one of my apps. So, to summarize in John Siracusa’s words again: Name your Tahoe .icon file the same as the name of your existing .appiconset in the Assets catalog. Set the ASSETCATALOG_OTHER_FLAGS build setting to: --enable-icon-stack-fallback-generation=disabled

Check out this other thread and the suggestion to disable blur effects. That helped for me. More information here: https://developer.apple.com/forums/thread/795411?answerId=855239022#855239022

I’ve just tested it with Xcode 26 beta 7 and I get the same issue!

I had the same issue recently. The problem was that my project readme.md had an example URL that started with itms-services:// (used from the Testing promoted In-App Purchases guide). I never used or initialized any of this in the actual code, though! It must have been an automatic check by Apple that triggered that. So, to solve that issue I just had to make sure that the readme was not included in the actual build files (by removing all target memberships) – which is probably a good idea anyway. 😅 Not it’s working for me. Tl;dr: Search for itms in all project files and see if you can hunt down the place where it’s mentioned.

For those wondering why not to wrap the whole TabView in a NavigationStack, this leads to weird results. This places the whole toolbar below the title. Also the button to toggle the sidebar is placed below the title instead of above:

I’ve finally managed to get the migration working. What I did was basically: Using FileManager to check whether the .sqlite file exists at the old application directory. If that’s the case I can assume in my case that the migration wasn’t done, because after the migration this file will be deleted. The migration itself loads the old NSPersistentContainer and migrates it to the app group with the coordinators replacePersistentStore(at: appGroupURL, withPersistentStoreFrom: legacyDataURL, type: .sqlite) function. Remove all the old .sqlite files with the FileManagers .removeItem(at: legacyDataURL) function. That whole migration check and actual location-migration is run before initializing the SwiftData ModelContainer, which then points to the app group url via ModelConfiguration(url: appGroupURL). SwiftData will then automatically perform the SchemaMigrationPlan. IMPORTANT: Please note that you need to keep the old .xcdatamodel file in your project, otherwise it will fail to create the Core Data container! My Code Following the Adopting SwiftData for a Core Data app example code from Apple, I’ve now moved my ModelContainer to an actor that shares the container via a singleton with the app and widget. @main struct MyAppName: App { // App SwiftData Model Container let sharedModelContainer = DataModel.shared.modelContainer var body: some Scene { WindowGroup { ContentView() } .modelContainer(sharedModelContainer) } } actor DataModel { /// Singleton for entire app to use. static let shared = DataModel() /// Legacy location of the Core Data file. private let legacyDataURL = URL.applicationSupportDirectory.appending(path: "MyApp.sqlite") /// Location of the SwiftData file, saved in SQLite format. private let appGroupURL = FileManager.default.containerURL(forSecurityApplicationGroupIdentifier: "group.com.domain.myapp")!.appendingPathComponent("MyApp.sqlite") private init() { // Checks for old Core Data migration before loading SwiftData. checkCoreDataMigration() } nonisolated lazy var modelContainer: ModelContainer = { let configuration = ModelConfiguration(url: appGroupURL) do { return try ModelContainer( for: Foo.self, Bar.self, migrationPlan: MigrationPlan.self, configurations: configuration) } catch { fatalError("Could not create SwiftData ModelContainer: \(error)") } }() nonisolated private func checkCoreDataMigration() { // If old store does exist perform the migration to App Group! // We can expect that the old store only exists if not yet migrated, because the migration deletes all old files. if FileManager.default.fileExists(atPath: legacyDataURL.path(percentEncoded: false)) { migrateCoreDataToAppGroup() } } nonisolated private func migrateCoreDataToAppGroup() { let container = NSPersistentContainer(name: "MyApp") let coordinator = container.persistentStoreCoordinator // 1. Migrate old Store do { // Replaces Application Support store with the one in the App Group. try coordinator.replacePersistentStore(at: appGroupURL, withPersistentStoreFrom: legacyDataURL, type: .sqlite) } catch { print("Error replacing persistent store in App Group: \(error)") } // 2. Delete old Store files NSFileCoordinator(filePresenter: nil).coordinate(writingItemAt: legacyDataURL, options: .forDeleting, error: nil) { url in do { try FileManager.default.removeItem(at: legacyDataURL) try FileManager.default.removeItem(at: legacyDataURL.deletingLastPathComponent().appendingPathComponent("MyApp.sqlite-shm")) try FileManager.default.removeItem(at: legacyDataURL.deletingLastPathComponent().appendingPathComponent("MyApp.sqlite-wal")) } catch { print("Error deleting persistent store at Application Support directory: \(error)") } } } } NOTE: Widget extensions may create an App Group store before the migration could happen by opening the app. Therefore I'm replacing the persistent store at the App Group location. Please note that this code doesn’t migrate to CloudKit yet!