I get this a lot too. Filed FB9807088

Ah. There was a user setting VALID_ARCHS that I think an old Xcode upgrade created (I certainly didn't). It's a very old project.

This is still a problem, two years later, in Xcode 13.1. I've written feedback about it.

Hmm. We already have the export compliance plist key, but have two out of many users with "no builds available."

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!

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.

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?

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

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.

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.

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) } }) } } } } }

Oh never mind, I'm wrong about that.

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

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.

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.