Am I misunderstanding the expected behavior here, or is there a bug in the behavior of @Attribute(.ephemeral) tagged SwiftData model properties? The documentation for .ephemeral says "Track changes to this property but do not persist". I started using .ephemeral because @Transient was inhibiting SwiftUI from reacting to changes to the property through @Observable. I am updating the value of my @Attribute(.ephemeral) property about once a second and I am seeing corresponding console log output showing the property as part of the generated CKRecord object. I then confirmed in the CloudKit dev portal that the .ephemeral property was added to the Record schema and contains real values. The behavior seems as though the .ephemeral property is being completely ignored. This is observed in a new Xcode project using SwiftData with CloudKit, Xcode 16.2, macOS 15.3.1 and during Build & Run testing on physical devices.

I am wanting to not only surface my content in the system-level Spotlight search results but also to utilize the same index for my in-app search screen. The very few examples or tutorials I could find all craft a CSSearchQuery string using just the "title" attribute. I can't figure out where to look to understand how to search across other attributes. My most pressing need is to be able to perform a CSSearchQuery looking for a search term in the .htmlContentData attribute. If I search for this term in the system search field it returns results, so I know it's being indexed. However when I use a search query (in my app) like htmlContentData == "someSearchTerm" I get zero results. This frustration has led to some more general questions like: How do you know what attribute names are available to use in the search query? Is it just a string literal that's exactly the same as the CSSearchableItemAttributeSet property in Swift? e.g. property .htmlContentData is referred to as "htmlContentData" in the query string? Also, is there any way to just search across all attributes with CSSearchQuery? Obviously using the system Spotlight search (from Home Screen) you don't have to specify if you're searching the title or htmlContentData, it just finds it in either. Yet for CSSearchQuery I have to know up-front which fields I want to look in?

I have run into the issue of trying to use a static library in an iOS app running in the simulator on an M1 (Apple Silicon) mac. However I'm having a difficult time adapting existing recommended solutions to my use-case. As I understand it, the root cause is that previously iOS simulator targets were always Intel but now on Apple Silicon the simulator targets can also be arm64. The recommended solution is to use XCFramework to better handle the combinations of platform and arch (e.g. iOS simulator + arm64). I have a cross-platform C library with a Makefile that I have in Xcode as an "External Build System" target. In the Xcode target it calls /usr/bin/make with the following arguments, where it passes relevant build settings from the iOS Framework to this external make task. On Intel-based Macs this has worked to automatically change the arch and SDK depending on the build target chosen in Xcode, e.g. building for simulator or making an archive. build CONF=$CONFIGURATION CND_PLATFORM=$PLATFORM_NAME IPHONEOS_DEPLOYMENT_TARGET=$IPHONEOS_DEPLOYMENT_TARGET CFLAGS="-arch $PLATFORM_PREFERRED_ARCH -isysroot $SDKROOT -fembed-bitcode" Where I believe I'm stuck is that, when building for iOS simulator on my M1 MacBook, the $PLATFORM_NAME is correctly set for the simulator but the $PLATFORM_PREFERRED_ARCH still shows x86_64. When the iOS Framework goes to link with the static library produced by this makefile it complains about missing symbols (presumably because it's looking for arm64 symbols). How can I pass the correct contextual build information to this External Build System (makefile) target for the iOS Simulator on Apple Silicon?