Was it entirely necessary to (in my opinion) unceremoniously break the library/framework solution that has been employed by 3rd party, iOS SDK developers for over a decade? I realize that XCFramework has been a topic of discussion since mid-2019 and a feature in Xcode 11 since fall-2019, but to effectively decommission a solution that has functioned well for many years (given the lack of integrated support for external SDK distribution in the Apple dev tools) in a "minor" Xcode release (i.e. functional in 11.3, broken in 11.4) seems rash.I recognize that the scripts and instructions provided to customers can be updated back into a functional state. I understand that when developer tools are updated a certain amount of risk is inherently accepted (which is why I do so infrequently and judiciously). Furthermore, I must admit excitement over an Apple-blessed solution to the SDK/framework distribution problem. However, my excitement is (which, technically, has now become "was") in regards to a potential, likely future when XCFramework adoption felt prudent and solid. For now, the present has been unceremoniously disrupted by perplexed customers that are using Xcode 11.4.

I just added arm64e support to the framework that I work on, and I have run into the exact same question. My build script expects to find a BCSymbolMap for every UUID in the universal/fat framework executable file. This expectation is no longer true since I added arm64e to the build process. Obviously, this missing BCSymbolMap is appropriate given that the arm64e slice does not include bitcode, so the underlying question is why no bitcode?I am left to wonder if this missing bitcode is a result of arm64e continuing to be considered a "preview" of the technology. The original announcement of arm64e in the Xcode 10.1 Release Notes calls it a preview and further states that, "The App Store and TestFlight don't accept submissions containing arm64e. Xcode will remove arm64e content from your app when you distribute from the Organizer window." I had presumed that, by now, this caveat would no longer apply. However, I cannot find any mention of there being a final/non-preview version of arm64e support in any of the subsequent Xcode Release Notes. Furthermore, the Preparing Your App to Work with Pointer Authentication continues to exist, and it makes a similar claim.