Hello

I’m sorry but I don’t understand your confusing and self-contradictory post. Please rephrase and separate the problems clearly. Provide logs where necessary.

1. Your app crashes when you tap a microphone button. What do the remote debug console logs say ? The reason of the crash will be indicated.

2. If this didn’t happen before, have you tried using the same iOS SDK as before ? This is more likely to be the cause than the other way around.

3. How can you say you get a compiled app if the linker fails even when you use the automatic symbol finding option ? This is contradictory.

4. I don’t support using older versions of the builder. That would be unmanageable. If a newer version causes a regression, it has to, and will be, fixed.

From this build log I see that your project uses the Objective-C msgSend stub prototypes, and to build this currently you _must_ use the LLVM linker, not the Apple one ; because Apple hasn't published their implementation yet.

Now about this crash problem. What do the remote debug logs say when the app crashes ?

Hint: if you changed the minimum iOS version, your app may need an Info.plist change, for example you might need to provide a mandatory key that will explain the user why your app requires microphone access. If that key is absent, any behaviour can happen, including an app crash.

*How to read a stack frame*

From this crash log we can see (in the stack frame) that :

- At the top level of the stack (level #0) is the crash handler, i.e. the very function that produces the crash log: __sig_handler. The actual crash always happens at the level just below.
- This function is called by level #1, i.e. the function that raised the crash signal (a SIGBUS signal): 939B1878-C4CB-34D0-B126-55AE30D21EFC (it's a GUID, Apple redacted the internal function name). The crash happens in an iOS system library (libsystem_platform.dylib).So either your app did something wrong in this iOS system library or Apple did something wrong in this version of iOS - you might have hit an iOS bug.
- At stack level #2 is the parent function that called the internal iOS system library function where the crash took place, and this function is opus_packet_parse() in UnityFramework. A Google search tells us that this function is from the Opus audio codec API: https://www.opus-codec.org. So it looks like Unity uses the open source Opus audio codec for encoding microphone input, and does something wrong.
- Levels #3 to #10 are functions that deal with the initialization of that Opus audio codec. Level #11 is an interface callback. Level #12-#13 explicitly deal with the microphone data. The next frames deal with WebRTC. The intent of the code seems to create a bridge between the microphone and a remote web server. The rest of the frames are thread initialization routines and we reach the bottom of the stack.

It does look like an implementation problem in either the Opus audio codec itself, or the way Unity initializes it. Perhaps something worked with the previous version on iOS that is now illegal on newer versions. I am relatively confident that the problem was triggered by your phone's iOS version update, although it was certainly latent with the previous version.

One thing important to note, is that your app causes a SIGBUS error. SIGBUS errors happen when your app tries to access memory that is beyond the addressable limit. This is different from the (by far most common) SIGSEGV errors which are caused when your app tries to access memory at an invalid address (such as dereferencing a NULL pointer). SIGBUS errors, as in your case, are typical from a memory exhaustion problem. This is consistent with an early warning that I see your app receives:

%
Nov 25 23:25:09.168 RemoteConsole <stdout>: WARNING -> applicationDidReceiveMemoryWarning()
%

This is a message from iOS to inform your app that it's abusing the system resources and should take action. Then later on we see the Unity engine attempting to do something on its own:

%
Nov 25 23:25:18.882 RemoteConsole <stdout>: Unloading 62 unused Assets to reduce memory usage. Loaded Objects now: 22737.
%

It looks like the Unity engine is having a hard time to keep your app within the imposed system memory constraints. This might be the sign of a design problem.

I hope you find this explanation useful.