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.

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.

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 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.

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

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

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.

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.

Thanks, requested this as a suggestion: FB7829588

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.