Hello,We have noticed that too in our last two TestFlight uploads. ODR tags appear to be missing completely (everything works when simulating it with the app connected to the debugger) and we have not changed tooling, export plist settings, or our dev environment (nothing governing how ODR tags are created and managed in the project that I know of).I have created the following bug in Feedback Assistant: FB7611040. Please feel free to dupe it/quote it in your bug report if you raise one (please do as it helps their engineers to prioritise).Kind Regards,Goffredo

Yes, it would surely be rejected at that stage.Could you all please ensure you have raised a Feedback Assistant bug and raised an issue with either/or the Developer Support and TestFlight teams?Kind Regards,Goffredo

Raised a Technical Support Incident ticket for this. Will update this thread when we hear about further developments.

Could you please raise a Feedback Assistant ticket referencing this thread and one of the pre-existing ODR related Feedback Assistant bug to help raise its priority please: FB7611040? Thanks 🙂

Thank you for your help, server side issues on such a widely used system must not be that easy or fun :/.Bugs raised:* Feedback Assistant: FB7611040* DTS ticket: 731018346I have rebuilt and resubmitted the ODR powered app in question, it processed on TestFlight even faster than it used to be too 🙂, and I can confirm the issue seems solved for me. The ODR tags were found and worked as expected. Thanks 😀!

Hey Eskimo... kind of... I see a mysterious UEFI device that sometimes boots me back in Big Sur (sometimes I end up in recovery mode). The time I had to go back to Catalina (from Big Sur Beta 6, with the target disk swapping as if it was a card game of “where/find the Queen”... not joking :)) and back to Big Sur using the launch boot picker (had to do it twice, only disk the Safe Mode could see was the Big Sur - Data partition which I could not mount... did not accept my password either) ... I lost some user profile data (settings for iTerm and Firefox were gone, had to get them back/recreate them).

An update from the quoted thread above: Example: struct Test: View { 		let value: Int? 		var body: some View { 				if case let value? = value { 						Text("\(value)") 				} else { 						Text("Test") 				} 		} } I tried to drop your example in it and it does not compile in the existing project. It does compile in a brand new iOS only project, but it does not compile in a brand new macOS project (shared sample iOS and macOS projects): https://www.icloud.com/iclouddrive/01bKAFXVd82HpGZ-3R7RExKeA#ViewBuilder_iOS_macOS Not sure why it would not work for macOS, there could be the embarrassing thing I was missing and I should have explained it is an iOS + macOS app. So it works as a pure iOS project, but not as a pure macOS project. Will be creating a Feedback report and post the ID here.

FB8800652 (ViewBuilder is not inferred for a SwiftUI's body property for a macOS Target) Tapped the “Answered” icon by mistake and I cannot undo it :/...

Fixed in Xcode 12.2 Beta 3

Apparently, unchecking the TouchBar zoom option in the accessibility setting gets you back the Touch Bar working as normal (at least working :), Apple is being super nice in how they are chasing this in the Feedback Assistant, I really appreciate that!).

I think it is a SwiftPM change. Integrating the library through CocoaPods solves the problem here and passes it down to the next library integrated through SwiftPM.

Apparently this is by design: https://forums.swift.org/t/set-application-extension-api-only-on-a-spm-package/39333/11 This breaks also other libraries like Firebase App Diatribution used in an app without any app extension target. It would be nice as the app developer to be able to tell SwiftPM there is no App Extension target :/. Will try to raise this issue in all the projects I can see are affected :(… might take a while. Will add links here if it is allowed.

Bug seems to be fixed when updating the the latest betas of macOS 12 and iOS 15.

The change has been reverted in SwiftPM so now this problem should not affect apps and libraries anymore (although some libraries like Firebase had already adapted successfully to it).

The change has been reverted in SwiftPM (Xcode 13 beta 5 for sure) so now this problem should not affect apps and libraries anymore (although some libraries like Firebase had already adapted successfully to it)