I am still seeing this with Xcode 12.3 on iOS 12.4.1 devices. Anybody find a workaround?

edit: using lipo is necessary, and is the accepted solution for this. Can you provide some links to where this is documented and how we are supposed to accomplish this? I am in the middle of getting some of our C++ dependencies to build with iOS arm64 simulator support and am failing when attempting to make an xcframework with all three slices.

I just got around to running the integration tests that were experiencing this issue with Xcode 12 beta 5 and am no longer seeing this issue. My Feedback (FB8192296) was marked as having more than 10 reports and the "Potential fix identified - For a future OS update" resolution but has not been marked whether this is the release that fixes it. Can we get some confirmation from  as to whether this is indeed fixed?

This is still an issue as of Xcode 12 Beta 4.

Submitted FB8192296

We are also experiencing this similar crash when running the simulator from Xcode 12 beta 3. We had a similar issue with Beta 1, but it was resolved with Beta 2 and now we are seeing this with beta 3. 	* frame #0: 0x000000010a07133a libsystem_kernel.dylib`__pthread_kill + 10 		frame #1: 0x000000010a0cee60 libsystem_pthread.dylib`pthread_kill + 430 		frame #2: 0x0000000109dc7c54 libsystem_c.dylib`abort + 120 		frame #3: 0x000000010e4ff8c9 AudioToolboxCore`_ReportRPCTimeout(char const*, int) + 90 		frame #4: 0x00000001311bbff5 libEmbeddedSystemAUs.dylib`_CheckRPCError(char const*, int, int) + 92 		frame #5: 0x00000001311b88fc libEmbeddedSystemAUs.dylib`AURemoteIO::Initialize() + 1878 		frame #6: 0x00000001311d234a libEmbeddedSystemAUs.dylib`AUBase::DoInitialize() + 36 		frame #7: 0x000000013115888b libEmbeddedSystemAUs.dylib`AUMethodInitialize(void*) + 59 		frame #8: 0x0000000123831d81 <redacted>`webrtc::VoiceProcessingAudioUnit::Initialize(double) + 789 This is happening on Catalina 10.15.6 with Xcode Beta 3. The simulator is as follows: CoreSimulator 732.7 - Device: iPhone 11 Pro (6EC8D05E-BCD2-424F-B321-4DFA2D4FE93B) - Runtime: iOS 14.0 (18A5332e) - DeviceType: iPhone 11 Pro

I have created Feedback FB7801261 which also includes the request for XCUIProtectedResource. As ceagleston and I explained during our lab session as well as in the ticket above, there are some issues with the approach of fire and check later for errors when combined with WebRTC and Interactive Connectivity Establishment (ICE) which will cause issues which could be circumvented if we know beforehand that a user has denied local network access. Please review Feedback FB7801261. If you have further questions regarding the use case, please don't hesitate to reach out. Thank you!

I am experiencing this exact issue. Not sure how to resolve this now, short of setting the CLANG_WARN_QUOTED_INCLUDE_IN_FRAMEWORK_HEADER build setting to NO.

Furthering the testing question, I just watched the "Handle interruptions and alerts in UI tests" session and they discussed the addition of the resetAuthorizationStatusForResource: method on XCUIApplication. This method takes an enum which allows a UI test to reset the authorization status for various system permissions that the OS requests of the user. Looking at the XCUIProtectedResource enum, there is no such enum for the Local Network privacy option.

I was also wondering the same thing. This would be something that is super helpful for our automated UI testing. In our current testing application we trigger camera and microphone permission prompts before we run our test suite so we can ensure that the tests that depend on camera and microphone capture will work. Now, we run into the issue where if our SDK (which builds upon WebRTC) decides that a local network Peer to Peer connection is most suitable, it will cause the Local Network permission alert to appear. Its all dependent on the environment at the given time, and being that we test in a device farm on fresh devices, this is something that could be tricky to manage. I was under the assumption that the permission would be similar to AVCaptureDevice authorizationStatusForMediaType: where it would return things like AVAuthorizationStatusNotDetermined, AVAuthorizationStatusAuthorized and AVAuthorizationStatusDenied. If the user chooses to not allow permissions, we have no way in code to do something different, as we... don't know... that they said no previously. If we were able to detect that they denied the permission, we could, for instance, force WebRTC to use TURN instead and still achieve functionality. I am looking at this from two angles, now that I type this. One is about allowing us the ability to manage permissions in automated tests. The second is for allowing a better experience to our customers' customers who decline local network permissions. If we are unable to know that they declined the permission, we can't talk alternative approaches to providing a useable experience.