Created a fresh Xcode project using the macOS App template. Set up a Xcode Cloud Workflow with a "Test - macOS" action. Using the latest environment available, currently Xcode 14.1 (14B47b) and macOS Ventura 13 RC 2 (22A380). App builds and tests run fine locally in Xcode 14.1 (14B47b). But on Xcode Cloud, this is resulting in a code signing error when the test-without-building step is reached. Foo (7828) encountered an error (Failed to load the test bundle. If you believe this error represents a bug, please attach the result bundle at /Volumes/workspace/resultbundle.xcresult. (Underlying Error: The bundle “FooTests” couldn’t be loaded. The bundle couldn’t be loaded. Try reinstalling the bundle. dlopen(/Volumes/workspace/TestProducts/Debug/Foo.app/Contents/PlugIns/FooTests.xctest/Contents/MacOS/FooTests, 0x0109): tried: '/Volumes/workspace/TestProducts/Debug/FooTests' (no such file), '/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/usr/lib/FooTests' (no such file), '/Volumes/workspace/TestProducts/Debug/Foo.app/Contents/PlugIns/FooTests.xctest/Contents/MacOS/FooTests' (code signature in <AEE218C5-FDB4-3327-B270-99D8A86530EB> '/Volumes/workspace/TestProducts/Debug/Foo.app/Contents/PlugIns/FooTests.xctest/Contents/MacOS/FooTests' not valid for use in process: mapped file has no Team ID and is not a platform binary (signed with custom identity or adhoc?)), '/System/Volumes/Preboot/Cryptexes/OS/Volumes/workspace/TestProducts/Debug/Foo.app/Contents/PlugIns/FooTests.xctest/Contents/MacOS/FooTests' (no such file), '/Volumes/workspace/TestProducts/Debug/Foo.app/Contents/PlugIns/FooTests.xctest/Contents/MacOS/FooTests' (code signature in <AEE218C5-FDB4-3327-B270-99D8A86530EB> '/Volumes/workspace/TestProducts/Debug/Foo.app/Contents/PlugIns/FooTests.xctest/Contents/MacOS/FooTests' not valid for use in process: mapped file has no Team ID and is not a platform binary (signed with custom identity or adhoc?)))) I was able to narrow the command line flags Xcode Cloud is using to reproduce it locally. Running xcodebuild test -scheme Foo CODE_SIGN_IDENTITY=- locally results in a similar error.

When you correctly implement EntityPropertyQuery on an AppEntity, Shortcuts will expose a "Find Entity" action that calls into entities(matching:mode:sortedBy:limit:). This is demoed in the "Dive into App Intents" session and works as expected. However, with this action, you can change the "All Entity" input to a list variable which changes the action text from "Find All Entity" to "Filter Entity where" still giving you the same filter, sort and limit options. This appears to work as expected too. But, what's unexpected is that this filter action does not appear to call any method on my AppEntity code. It doesn't call entities(matching:mode:sortedBy:limit:). One would think there would need to be a filter(entities:matching:mode:sortedBy:limit:) to implement this functionality. But Shortcut just seems to do it all on it's own. I'm mostly wondering, how is this even working? Here's some example code: import AppIntents let books = [ BookEntity(id: 0, title: "A Family Affair"), BookEntity(id: 1, title: "Atlas of the Heart"), BookEntity(id: 2, title: "Atomic Habits"), BookEntity(id: 3, title: "Memphis"), BookEntity(id: 4, title: "Run Rose Run"), BookEntity(id: 5, title: "The Maid"), BookEntity(id: 6, title: "The Match"), BookEntity(id: 7, title: "Where the Crawdads Sing"), ] struct BookEntity: AppEntity, Identifiable { static var typeDisplayRepresentation: TypeDisplayRepresentation = "Book" var displayRepresentation: DisplayRepresentation { DisplayRepresentation(title: "\(title)") } static var defaultQuery = BookQuery() var id: Int @Property(title: "Title") var title: String init(id: Int, title: String) { self.id = id self.title = title } } struct BookQuery: EntityQuery { func entities(for identifiers: [Int]) async throws -> [BookEntity] { return identifiers.map { id in books[id] } } } extension BookQuery: EntityPropertyQuery { static var properties = QueryProperties { Property(\BookEntity.$title) { EqualToComparator { str in { book in book.title == str } } ContainsComparator { str in { book in book.title.contains(str) } } } } static var sortingOptions = SortingOptions { SortableBy(\BookEntity.$title) } func entities( matching comparators: [(BookEntity) -> Bool], mode: ComparatorMode, sortedBy: [Sort<BookEntity>], limit: Int? ) async throws -> [BookEntity] { books.filter { book in comparators.allSatisfy { comparator in comparator(book) } } } } The example Shortcut first invokes entities(matching:mode:sortedBy:limit:) with comparators=[], sortedBy=[], limit=nil to fetch all Book entities. Next the filter step correctly applies the title contains filter but never calls entities(matching:mode:sortedBy:limit:) or even the body of the ContainsComparator. But the output is correctly filtered.

I can't seem to log into Feedback Assistant. I'm getting a pretty generic when trying to log in from any beta device. Different than password incorrect error. What's the proper channel for contacting Apple about this bug given that I can't use Feedback Assistant itself to report the issue? So I'm in a bit of a Catch-22 here.

When generating a MLWordEmbedding model, there seems to be some kind of compression happening with the original input vectors. Just take the example from the documentation: let vectors = [   "Hello"   : [0.0, 1.2, 5.0, 0.0],   "Goodbye" : [0.0, 1.3, -6.2, 0.1] ] let embedding = try! MLWordEmbedding(dictionary: vectors) embedding.vector(for: "Hello") == vectors["Hello"] // false embedding.vector(for: "Goodbye") == vectors["Goodbye"] // false // unexpectedly compressed to same vector embedding.vector(for: "Hello") == embedding.vector(for: "Goodbye") // true embedding.distance(between: "Hello", and: "Goodbye") // 0 Larger datasets, like word2vec, seem to work a bit better. But input vectors are still changed in unexpected ways and more vector collisions occur. I'm curious what spacial properties are expected to hold after compression? Is there some way to tune or disable this? Thanks!

I've set a Swift Package for some SwiftUI views. It looks like Xcode Previews do work for files directly under the target directory. But break once you add any nesting. // -- Sources/Foo/RootView.swift -- import SwiftUI struct RootView: View {     var body: some View { Text("Hello, World!") } } // Works! struct RootView_Previews: PreviewProvider {     static var previews: some View { RootView() } } // -- Sources/Foo/Subviews/SubView.swift -- import SwiftUI struct SubView: View {     var body: some View { Text("Hello, World!") } } // Error! // NoBuildableEntriesError: active scheme does not build this file // Select a scheme that builds a target which contains the current file, or add this file to a target that is built by the current scheme. struct SubView_Previews: PreviewProvider {     static var previews: some View { SubView() } } The "Generate Report" button also seems broken for this case. It just opens finder to the root temp directory and doesn't seem to dump any specific logs. Xcode 12.0 beta (12A6159)

Today, if you wanted to build or test a package on iOS, you could generate a xcodeproj via swift package generate-xcodeproj and test via xcodebuild. However, once you start using the new Resources feature, this breaks. It doesn't look like the generated xcodeproj is set up to copy resource bundles or generate the resource_bundle_accessor.swift source. Here's a reproducible case using the Fruta sample code. $ cd Packages/NutritionFacts $ swift package generate-xcodeproj $ xcodebuild build -sdk iphoneos error: type 'Bundle?' has no member 'module' &#9;Text("\(kilocalories) Calories", bundle: .module)

I'm trying to set up a Swift Package that target's macOS Big Sur. From the documentation, it looks like v11 should be the new property. https://developer.apple.com/documentation/swift_packages/supportedplatform/macosversion/3632902-v11 platforms: [.macOS(.v11)], But it crashes with the following error. error: manifest parse error(s): Package.swift:9:17: error: reference to member 'v11' cannot be resolved without a contextual type &#9;&#9;&#9;&#9;.macOS(.v11) Oddly, an undocumented v10_16 works! platforms: [.macOS(.v10_16)], Looking at the open source code, it appears both values should work. https://github.com/apple/swift-package-manager/blob/6cfe2de63e53dd9cb75e7bf910277e699d9383a2/Sources/PackageDescription/SupportedPlatforms.swift#L212-L223 Is there a bug in this release of Xcode's Swift tool chain? What platform property should I be using to target Big Sur? Xcode Version 12.0 beta (12A6159) $ swift --version Apple Swift version 5.3 (swiftlang-1200.0.16.9 clang-1200.0.22.5) Target: x86_64-apple-darwin19.5.0