We are encountering an issue in an iOS application where functionality works correctly in Debug builds but fails in Release builds distributed via TestFlight.
Details
- Debug (No Optimization -Onone): Works correctly
- Release (Optimize for Speed -O): Fails
- Release with -Onone: Works, but app size nearly doubles
Context
The issue is related to integration with the Microsoft ONNX runtime library. It appears that the Swift/Clang compiler is aggressively optimizing certain parts of the code in Release builds, possibly removing or altering required logic.
Observations
- The issue started appearing with recent iOS/Xcode updates.
- No code changes affecting this logic were made recently.
- Behavior strongly suggests optimization-related side effects.
Questions
- Are there known issues with aggressive optimization (-O) affecting third-party libraries?
- Are there recommended flags to selectively disable optimization for specific modules or functions?
- Any tools or diagnostics to identify what is being optimized out?
Temporary Workaround
Using -Onone resolves the issue but is not viable for production due to significant increase in app size.
Any guidance would be greatly appreciated.
Are there known issues with aggressive optimization (-O) affecting … ?
Yes. If you’re using a C-based language it’s very easy to rely on undefined behavior, and the exact behaviour you get can change based on the optimisation level, the compiler version, the OS version, and so on.
This is true in safer languages as well, but it’s less common. For example, Swift is generally safer than C but there are still sources of undefined behaviour, including unsafe pointers [1] and concurrency [2].
Is sounds like you’re building this third-party library from source. Is that right? If so, you can dig into the library to see if you can isolate the cause of the problem. This is no different from tackling a hard-to-debug problems in your own code. You can use both build-time tools (like the Clang static analyser) and runtime tools (like the standard memory debugging tools).
It’s also possible for problems like this to be caused by bugs in the compiler. However, my experience is that these are relatively rare, and it’s much more common for the problem to be in the source code you’re building. And the only way to know for sure is to fully isolate the problem, so that’s your first step anyway.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
[1] These should start to fall away as more subsystems present Swift-friendly APIs, but it’ll be a long time before they go away completely.
[2] Turning those from undefined behaviour into compiler errors is the goal of the Swift 6 language mode.