What build settings improve Time Profiler symbols in Release builds?

WHAT THIS TESTS: Whether you understand how Xcode separates debug symbols from executable code and how to preserve symbolication data for Instruments without altering compiler optimizations. The interviewer cares that you can profile a true Release build and still read the resulting call stacks accurately.

A GOOD ANSWER COVERS: Four things in order. First, identify DEBUG_INFORMATION_FORMAT and set it to DWARF with dSYM File instead of DWARF alone so debug info is written to a separate dSYM bundle rather than embedded in the binary. Second, note that stripping settings must not discard the dSYM after it is created, which means checking that the build pipeline preserves the dSYM output path for Instruments. Third, state that the dSYM must be available to the Mac running Time Profiler so it can symbolicate sampled addresses back to source lines. Fourth, list the trade-offs: larger overall archive size, longer link times because the linker must generate the dSYM, and the operational risk of accidentally shipping debug symbols inside the app bundle instead of keeping them on the build machine.

COMMON WRONG ANSWERS: Three patterns. First, suggesting you disable compiler optimizations such as setting SWIFT_OPTIMIZATION_LEVEL to Onone or GCC_OPTIMIZATION_LEVEL to zero; this makes stacks readable but invalidates the profile because the code path no longer matches what users execute. Second, saying you only need to set Generate Debug Symbols to YES, which is incomplete because Release builds often already enable that flag yet still produce unreadable stacks if the format is plain DWARF and the binary is stripped. Third, confusing debug symbols with enabling the debugger on a Release binary, which is unrelated to sampling profilers like Time Profiler.

LIKELY FOLLOW-UPS: The interviewer may ask how you deliver dSYMs to a crash reporting service without including them in the App Store upload, or how Bitcode affects dSYM generation and whether you need to download recompiled dSYMs from App Store Connect. They may also ask what to do if Instruments still shows missing symbols even though the dSYM exists, which usually leads to checking the UUID match between the binary and the dSYM.

ONE CONCRETE EXAMPLE: You archive a Release build and Time Profiler shows opaque hex addresses for heavily inlined Swift code. You verify that DEBUG_INFORMATION_FORMAT is set to DWARF with dSYM File, rebuild, and locate the resulting dSYM beside the binary. After pointing Instruments to the dSYM or ensuring it is in the same directory as the binary, the call stack resolves to human-readable function names. The cost is that the link phase takes roughly ten to twenty percent longer and the dSYM adds tens of megabytes to your build artifacts, but the executable performance remains identical to a standard Release build.