To add on a bit, what is the best way to get a log archive from a tester's device when they *don't* have access to Xcode? The specific instance that's been most troublesome for me has been when TestFlight users have a build, but aren't otherwise familiar - or after a beta when it's in the hands of a customer directly.

Thanks, requested this as a suggestion: FB7829588

Some of the data maps reasonably well to time series, but the core of most of the metric kit data are as aggregates, which will be difficult to decompose back into it's original order and values. While the aggregate formats are well defined, I don't (yet) have a good sense of what all is in them, but NSHipster's code (nshipster.com/metrickit/) does a good job of highlighting how to tackle this sort of thing. I'm leaning towards setting up a quick server so that I can capture CI/CD and long running integration test results, but haven't started anything towards that end as yet.

You need to have a data structure that has a property children on it - your current example has the properties id and values. Since the List with the children parameter is meant to show a hierarchy, the SwiftUI framework uses the property that you provide to that parameter (a keypath to the property .children in the example above) to look up that data relationship to display it. Since you've provided a keypath that doesn't exist on that object, the compiler is letting you know that \.children isn't going to work.

For what it's worth, I've also submitted this as feedback with a relevant screenshot showing the compiler output, as FB9013606

I found a hint to the answer on twitter - in case someone else comes looking here: You have to be targeting a device for even compilation to work correctly. Once I connected an iPad and targeted it directly, there wasn't an issue with the compilation. Would be awfully nice to have this as a note/warning in the sample code though

I was hunting for something akin to this path myself, and haven't found any public accessors for RealityKit's entities to be loaded other than the loadModel, which in the examples are specific to USD formats. - https://developer.apple.com/documentation/realitykit/entity/stored_entities/loading_entities_from_a_file I suspect that in order to load your model in RealityKit, you'll first need to explicitly transform your STL-sourced model into USDZ, write it to a file or buffer, and then load it from there with loadModel - https://developer.apple.com/documentation/realitykit/entity/3244091-loadmodel or it's neighboring methods.

First does send a completion when it's triggered, although I suspect for this use case what you want is actually firstWhere, which looks for a specific predicate to trigger on before sending values - where first just takes whatever it gets right off the bat (meaning you had to filter the content earlier in the pipeline). The difference is minimal - when used inline it just looks like a parameter to the first operator, but they're different structs under the covers. While I was working on a my own reference content for Combine, I wrote a bunch of tests that worked all the various operators, so if you're so inclined, you can see what I did there to test the first operator - it's open source.

I don't think that there's currently a way to explore and examine (programmatically) what is in the environment - so there's no obvious way to verify that the object you're expecting to be in the environment was injected. To deal with this little quirk, the pattern that I've seen used in some code is to have an top-level View that explicitly injects the relevant environment object, often as a an explicit parameter to that view, and then use that as a base point upon which you can assume (safely) that all subviews from here will have the relevant pieces you need.

The short answer is that changes to a property aren't coalesced. The change notification is only a notification that something changed, and it leaves the getting and determining what's changed to the underlying code. As you've seen, a change notification handler can be called repeatedly, with apparently the same information inside it. When you can do to sort of work around this is make your own publisher from the messages that reacts to the change notification and sends the message down it's own pipeline, and include .removeDuplicates() as an operator on that pipeline, then. subscribe to it in your view with .onReceive to process the updates. This (obviously?) doesn't stop the duplicate notifications, and still triggers a send of the message value each time, but your pipeline with removeDuplicates does the coalescing for you, and you have a publisher that's providing you the specific values you want to work with - the message content.

This session is what prompted this question - The canvas is a single element, and I want to have multiple accessibility elements that I'm displaying within it. That may not be (yet?) possible, but I wanted to see if there was any suggestions for a pattern of how to create multiple children and align them with specific in-view-coordinate spaces, which mimics a bit of what you can do within UIKit where you specify a frame location for a child accessibility object.

With the WWDC21 software updates, I noticed that RealityKit now has some additional methods on MeshResource: generate(from:), generate(from:) replace(with:) (and async oriented variations of these methods) The generate method is used in the example code BuildingAnImmersiveExperienceWithRealityKit which looks like it is now possible to provide the indices, normals, etc to build up a mesh procedurally. These methods don't have any documentation on them, so I'm not 100% certain about the details, but the Swift generated headers for it have some relevant notes that make it appear like these might the the "RealityKit" way to procedurally create meshes. Am I inferring correctly that these methods enable procedural generation with this year's release, or are these methods more focused elsewhere?

In case it helps anyone else, the diffs I had to apply (Xcode 13.1) to compile it: diff --git a/Underwater/Octopus.swift b/Underwater/Octopus.swift index e447a32..7a99708 100644 --- a/Underwater/Octopus.swift +++ b/Underwater/Octopus.swift @@ -82,7 +82,7 @@ struct OctopusSystem: RealityKit.System { let scene = context.scene for octopus in scene.performQuery(OctopusComponent.query) { guard octopus.isEnabled else { continue } - guard var component = octopus.components[OctopusComponent] as? OctopusComponent else { continue } + guard var component = octopus.components[OctopusComponent.self] as? OctopusComponent else { continue } guard component.settings?.octopus.fearsCamera ?? false else { return } switch component.state { case .hiding: diff --git a/Underwater/Scattering.swift b/Underwater/Scattering.swift index 0883bdb..db3aa47 100644 --- a/Underwater/Scattering.swift +++ b/Underwater/Scattering.swift @@ -127,8 +127,8 @@ extension Entity { if let animation = try? AnimationResource.generate(with: FromToByAnimation<Transform>( from: transformWithZeroScale, to: transform, - duration: 1.0, - targetPath: .transform + duration: 1.0 +// targetPath: .transform )) { playAnimation(animation) }

I just built this for Xcode 13.1 by applying the following diffs (make sure you're building for a device, not the simulator - the code doesn't compile for the simulator, which isn't mentioned in the README - FB9181536): diff --git a/Underwater/Octopus.swift b/Underwater/Octopus.swift index e447a32..7a99708 100644 --- a/Underwater/Octopus.swift +++ b/Underwater/Octopus.swift @@ -82,7 +82,7 @@ struct OctopusSystem: RealityKit.System { let scene = context.scene for octopus in scene.performQuery(OctopusComponent.query) { guard octopus.isEnabled else { continue } - guard var component = octopus.components[OctopusComponent] as? OctopusComponent else { continue } + guard var component = octopus.components[OctopusComponent.self] as? OctopusComponent else { continue } guard component.settings?.octopus.fearsCamera ?? false else { return } switch component.state { case .hiding: diff --git a/Underwater/Scattering.swift b/Underwater/Scattering.swift index 0883bdb..db3aa47 100644 --- a/Underwater/Scattering.swift +++ b/Underwater/Scattering.swift @@ -127,8 +127,8 @@ extension Entity { if let animation = try? AnimationResource.generate(with: FromToByAnimation<Transform>( from: transformWithZeroScale, to: transform, - duration: 1.0, - targetPath: .transform + duration: 1.0 +// targetPath: .transform )) { playAnimation(animation) }

For code snippets in particular, there was a pitch recently in on the Swift Evolution open source forums by Ashley Garland that related to this — the idea being the documentation catalog could contain a specific set of swift snippets, and the compiler (or SwiftPM in this case I think) could/would build those to verify that everything kept working, no warnings, etc.