Yup, this is exactly what I'm seeing (although I didn't try to build it in an earlier Xcode). Annoying.

It is often simply not possible to get the library from a third-party vendor fixed. We don't call the library code on simulator, but prior to Xcode 11.4 we at least could build and run everything else. Now we can't do that. We need to be able to link libraries and frameworks on a per-destination basis.

Yes, that was the first thing I checked. As I mentioned, optimizations are off.

I, too, would like this source code. This was an extremely informative talk, and demonstrated some non-trivial SwiftUI. In so doing, it went beyond just showing how to use documents.

Unfortunately that only works while the mouse button is held down. I found an amazing solution, though, but the forum won't let me include a link to it. It's the SwiftUI-Lab (dot com) website, article The Power of the Hosting+Representable Combo.” It's unfortunate that Apple seems to have completely omitted mouse tracking in views.

Did you ever find a solution to this? BTW when I try that sample code on Big Sur 11.2.3, it barely works. I can't pinch-zoom without also clicking the trackpad, and even then it doesn't really change size nicely.

The range of position is the same for both interpolatedValueAtPosition and valueAtPosition. What happens if you don't divide x by 256?

Oh never mind, I'm wrong about that.

Well, I can't show all the code, but I can show a bit more: swift class ChatStream { @Published var messages = OrderedSetMessage() func add(messages inMsgs: [IncomingMessage]) { for msg in inMsgs { let msg = Message(fromIncoming: msg, user: user) self.messages.append(msg) } self.messages.sort() } } ... struct ChatView: View { @ObservedObject public var stream : ChatStream var body: some View { ScrollViewReader { scrollView in ScrollView { LazyVStack(alignment: .leading, spacing: 0.0) { ForEach(self.stream.messages) { inMsg in ChatMessageCell(message: inMsg) } .onChange(of: self.stream.messages, perform: { inMessages in --- called multiple times for each update below. if inMessages.count 1 { return } withAnimation(.linear(duration: 0.25)) { scrollView.scrollTo(inMessages.last!.id, anchor: .bottom) } }) } } } } }

FWIW, I just added a keychain sharing entitlement using Xcode 12.5, and it added the entitlements file with $(AppIdentifierPrefix)groupname (groupname is what I put in the entitlements UI). I don't know what value it's actually putting in there, as I can't find AppIdentifierPrefix anywhere else in the project. Update: It's really hard to know what the string in my code should be to match what Xcode is generating for the entitlement.

13b1 is definitely much faster for me. I'm going to try using it day-to-day, and then revert to 12.5 for builds to submit.

It seems to require an inordinate amount of free space to decompress, double or triple the size. Xcode 13b1 is 33 GB on my disk (although Finder seems to have lost its mind reporting the size). I needed over 100 GB free to decompress it the other day. BTW, I don't recommend b2, as it fails to compile some Swift code that depends on CF_RETURNS_NOT_RETAINED in Obj-C headers (like AVCapturePhoto).

I ran into this today. I can't explain it, but it's a real issue. Where did you read about the filed bug, @cyclic?

I've verified that it's fixed in iOS 15b1. Apple really needs to back-port this fix. I worked around it by posting a notification in .onAppear() higher up the hierarchy, where .onAppear was being called appropriately.

Ah I saw that headline but almost subconsciously dismissed it thinking it was just an announcement of the new thing. That'll learn me. Thanks!