And in fact, the code copied straight from the WWDC section no longer builds, either: import SwiftUI import RealityKit struct MoonOrbit: View { var body: some View { RealityView { content, attachments in guard let earth = try? await Entity(named: "Earth") else { return } content.add(earth) if let earthAttachment = attachments.entity(for: "earth_label") { earthAttachment.position = [0, -0.15, 0] earth.addChild(earthAttachment) } } attachments: { Text("Earth").tag("earth_label") } } } This produces "'init(make:update:attachments:)' is unavailable in visionOS" on the RealityView declaration line.

Neglected to add: there's a "[More]" button in ConversationLineView that does the actual incrementing of $shownSteps. These "conversations" are pre-generated, this code is effectively just doing a staged disclosure of each line of an existing list.

So for what it's worth, I was never able to make this work. My particular app wasn't very big, so I created a private repo on Github as a second origin to push to, and just sync it when I want to do a build. It's clumsy (and wouldn't work if you can't use Github for whatever reason), but it got me by. Hopefully Apple will eventually add "generic" Git support.

Feedback ID is FB14324883. The suggested code modification(ScrollView + VStack) does not work either in my case. I've also tried a LazyVStack instead of the list, as well as a ScrollView embedded inside the ScrollViewReader (I've seen examples of that on the web). All give similar results across the various platforms (works as expected on some platforms, doesn't work as expected on others, and it's not consistently "new ones work, old ones don't" or the reverse). I've also tried delaying the scroll by a few hundred milliseconds with asyncAfter(), and that doesn't work, either. ScrollView { ScrollViewReader { proxy in VStack { ForEach (gameModel.conversationPoints) {cp in let ind = gameModel.conversationPoints.firstIndex(of: cp)! if (ind <= shownSteps) { ConversationLineView(step: ind, shownSteps: $shownSteps).border(Color.blue) .id(cp.id) } } }.onChange(of: shownSteps) { _, _ in print("Scrolling to step \(shownSteps)") proxy.scrollTo(shownSteps, anchor: .bottom) } } } Note that one difference here is that your suggested onChange() is looking at the entire content array, and you're modifying that array by adding an element to it each time. My array is fixed in advance, and I'm simply changing an index to indicate how much of the array is drawn (and my onChange handler is looking for changes of the index, not the array). The effect should be identical, of course, but noting it in case it matters. The print statement shows the correct index to scroll to, indicating both that the step is correct and that the onChange is being called.

The reply immediately above this has one other change: I'm passing just an index (shownSteps) into the scrollTo method rather than gameModel.conversationPoints[shownSteps].id, but the behavior is the same either way. Interestingly, I've tried to reproduce this behavior in a smaller app, shown here, and the simpler app seems to work correctly everywhere. I have no what the difference is in the "real" app that makes it behave differently on some platforms. import SwiftUI import SwiftData @main struct SampleScrollApp: App { static var numbers = ["One", "Two", "Three", "Four", "Five", "Six", "Seven", "Eight", "Nine", "Ten", "Eleven", "Twelve"] var body: some Scene { WindowGroup { ContentView() } } } struct ContentView: View { @State var index = 0 var body: some View { VStack { HStack { Button { } label: { Text("Show Full Conversation") } Spacer() Button { } label: { Text("Skip Conversation") } }.padding(5).background(Color.black) ScrollView { ScrollViewReader { proxy in VStack { ForEach(0..<12) { item in if (item <= index) { TextyView(myIndex: item) .id(item) } } }.onChange(of: index) { _,_ in proxy.scrollTo(index, anchor: .bottom) } } } Button { index = index + 1 } label: {Text("More") } }.frame(width:400, height: 375) } } struct TextyView : View { var myIndex: Int var body: some View { VStack { Text("[\(myIndex)]").font(.title) HStack { Spacer() Text(SampleScrollApp.numbers[myIndex]) .font(.title) .multilineTextAlignment(.center) } }.padding(50) .border(Color.primary) .frame(maxWidth: .infinity, maxHeight: .infinity) } } #Preview { ContentView() }

So I got this working reliably; and of course the problem is in code I elided above. The increment for shownSteps was wrapped in an animation: withAnimation { shownSteps = shownSteps + 1 } That was apparently playing havoc (differently on different OSes) with the scrolling. Sometimes it wouldn't scroll at all, sometimes it would be one behind, sometimes it would work fine. My solution was just to remove the animation there, and stick it around the actual scroll: }.onChange(of: shownSteps) { _, _ in withAnimation { proxy.scrollTo(shownSteps) } } Is this a bug? Me just using it wrong? An oversight the compiler should have caught? I don't know. But it's now working as expected everywhere I've tested it so far.

Azure devops seems to be a bit of a hole in Apple's coverage everywhere -- Xcode cloud doesn't support it, and it's always a bit of a challenge to get working because of it's authentication system (similar to the change that Github is forcing on it's users now -- no passwords, custom, per-repository, frequently expiring and hard-to-configure tokens, etc.) That said, its very large size limits make it the obvious choice for certain types of projects (games with lots of assets, for example) that couldn't be hosted elsewhere in a cost-effective manner. For my part, I don't bother even trying to set it up from Xcode preferences any more. Just set it up with an external Git tool (I use Fork) and Xcode will see the existing repository automatically once you open the project there. As long as it's set up correctly to push/pull/fetch etc. from the command line, it'll work in Xcode. (Or just do all your source control from the external tool/command line, which also works fine). Alternatively, if there's no barrier to doing so, it might be easier just to jump on the bandwagon and move the repository to GitHub or one of the other more common providers. I do this for smaller projects just to avoid the hassle.

I filed the issue back in July, but apparently neglected to post it here. It's FB14505280.

I've got it even worse. There are 22 different .dmg files in System/LIbrary/AssetsV2/com_apple_MobileAssetXXX on my system, cumulatively taking up more than 200gb of my system space. Nearly all of them appear to be runtimes for simulators I don't even have installed any more; there are eight of them for VisionOS alone. This is crippling my system, since that's more than 20% of my drive! (In fact, I noticed the problem in the first place because installs were failing with "out of disk space" errors).