“SwiftData inheritance relationship”

I'm on a MacBook Air 2025 M4 (Apple Silicon) using Flutter 3.35.5 on channel stable, Xcode 26.0.1, and CocoaPods 1.16.2. Actual Setup: Component Version macOS 15.0 Sequoia CPU Apple M4 (ARM64) Flutter 3.35.5 on channel stable Dart 3.9.2 DevTools 2.48.0 CocoaPods 1.16.2 Xcode 26.0.1 Build 17A400 Since updating Flutter from 3.24 → 3.35, iOS builds consistently fail with the following errors (not matter if simulation or real device, also ios version no matter): fatal error: 'Flutter/Flutter.h' file not found Error logs: /Users/myuser/.pub-cache/hosted/pub.dev/app_links-6.4.1/ios/app_links/Sources/app_links/AppLinksIosPlugin.swift /Users/myuser/.pub-cache/hosted/pub.dev/app_links-6.4.1/ios/app_links/Sources/app_links/AppLinksIosPlugin.swift:1:8 Unable to find module dependency: 'Flutter' import Flutter ^ flutter_native_splash /Users/myuser/.pub-cache/hosted/pub.dev/flutter_native_splash-2.4.6/ios/flutter_native_splash/Sources/flutter_native_splash/include/flutter_native_splash/FlutterNativeSplashPlugin.h /Users/m

Hello Apple Team, We are looking at developing an iOS feature on our current development that stores user-generated images as CKAssets in the public CloudKit database, with access control enforced by our app’s own logic (not CloudKit Sharing as that has a limit of 100 shares per device). Each story or post is a public record, and users only see content based on buddy relationships handled within the app. We’d like to confirm that this pattern is consistent with Apple’s best practices for social features. Specifically: Is it acceptable to store user-uploaded CKAssets in the public CloudKit database, as long as access visibility is enforced by the app? Are there any performance or quota limitations (e.g., storage, bandwidth, or user sync limits) that apply to CKAssets in the public database when used at scale? Would CloudKit Sharing be recommended instead, even if we don’t require user-to-user sharing invitations? For App Review, is this model (public CKAssets + app-enforced access control) compliant w

I have an app that uses a Share Extension that allows the user to share videos, from Files and Photos etc., the video URL and some related data is then persisted with SwiftData and synchronized with CloudKit. This code has worked consistently for a long time although recently, with iOS 26 and recent builds of iOS 18, I have observed that the video is either not saved to SwiftData (iOS 26.0), or available locally when the app is opened on the same device where the share occurred, but not synchronized to other devices (iOS 18.7 and iOS 26.1 beta). Assuming the video is opened locally after being shared into the app, it is typically synchronized with CloudKit to other devices although it's not as reliable as it should be. Is there a reliable approach in the Share Extension to ensure that the data is saved to the local SwiftData database and then synchronized with CloudKit. I suspect it could be that the lifetime of the Share Extension has become even more constrained in recent OS updat

Hi, I did cloudkit synchronization using swiftdata. However, synchronization does not occur automatically, and synchronization occurs intermittently only when the device is closed and opened. For confirmation, after changing the data in Device 1 (saving), when the data is fetched from Device 2, there is no change. I've heard that there's still an issue with swiftdata sync and Apple is currently troubleshooting it, is the phenomenon I'm experiencing in the current version normal?

I'm trying to set up an application using SwiftData to have a number of models backed by a local datastore that's not synced to CloudKit, and another set of models that is. I was able to achieve this previously with Core Data using multiple NSPersistentStoreDescription instances. The set up code looks something like: do { let fullSchema = Schema([ UnsyncedModel.self, SyncedModel.self, ]) let localSchema = Schema([UnsyncedModel.self]) let localConfig = ModelConfiguration(schema: localSchema, cloudKitDatabase: .none) let remoteSchema = Schema([SyncedModel.self]) let remoteConfig = ModelConfiguration(schema: remoteSchema, cloudKitDatabase: .automatic) container = try ModelContainer(for: fullSchema, configurations: localConfig, remoteConfig) } catch { fatalError(Failed to configure SwiftData container.) } However, it doesn't seem to work as expected. If I remove the synced/remote schema and configuration then everything works fine, but the moment I add in the remote schema and configuration I ge

I'm experiencing a significant UI freeze in my SwiftUI app that uses SwiftData with CloudKit sync. When users tap a button to present a sheet for the first time after app launch, the entire UI becomes unresponsive for 5-10 seconds. Subsequent sheet presentations work fine. App Architecture Service layer: An @Observable class marked with @MainActor that orchestrates operations Persistence layer: A @ModelActor class that handles SwiftData operations SwiftUI views: Using @Environment to access the service layer The structure looks like this: @Observable @MainActor final class MyServices { let persistence: DataPersistence init(modelContainer: ModelContainer) { self.persistence = DataPersistence(modelContainer: modelContainer) } func addItem(title: String) async { // Creates and saves an item through persistence layer } } @ModelActor actor DataPersistence { func saveItem(_ item: Item) async { // Save to SwiftData } } The app initializes the ModelContainer at the Scene level and passes it

I'm developing an app that uses CloudKit synchronization with SwiftData and on visionOS I added an App Settings bundle. I have noticed that sometimes, when the app is open and the user changes a setting from the App Settings bundle, the following fatal error occurs: SwiftData/BackingData.swift:831: Fatal error: This model instance was destroyed by calling ModelContext.reset and is no longer usable. The setting is read within the App struct in the visionOS app target using @AppStorage and this value is in turn used to set the passthrough video dimming via the .preferredSurroundingsEffect modifier. The setting allows the user to specify the dimming level as dark, semi dark, or ultra dark. The fatal error appears to occur intermittently although the first time it was observed was after adding the settings bundle. As such, I suspect there is some connection between those code changes and this fatal error even though they do not directly relate to SwiftData.