Development Build Settings — What to Turn On and Off for a QA Build

Once you've settled what needs to travel with a build you hand to QA, the next question is how the build itself gets made. Development Build in Build Profiles (Build Settings in older Unity versions) enables a diagnostic build and makes additional options available. Pick the wrong combination for a QA build and reports start rolling in without the information you actually need to diagnose them.

What Development Build enables or makes available

Separate its default behavior from the options you must select yourself.

How logs and stack traces actually change in builds is already covered in the IL2CPP / release build post. This one doesn't repeat that ground — it focuses on how to combine these settings for a QA build.

What to turn on for a QA build

Development Build stays on by default. It is useful when you need a Profiler connection or QA-only diagnostic code behind the DEVELOPMENT_BUILD symbol. The watermark can help identify a dev build in screenshots where the target platform displays it. Log and stack-trace detail also depends on separate settings and the build environment.

// A diagnostics overlay that only exists in QA builds — compiled out entirely in release
#if DEVELOPMENT_BUILD
using UnityEngine;
using UnityEngine.SceneManagement;

public class QaDiagnosticsOverlay : MonoBehaviour
{
    void OnGUI()
    {
        float fps = Time.unscaledDeltaTime > 0f ? 1f / Time.unscaledDeltaTime : 0f;
        GUI.Label(new Rect(8, 8, 300, 20), $"FPS: {fps:F0}");
        GUI.Label(new Rect(8, 28, 300, 20), $"Scene: {SceneManager.GetActiveScene().name}");
    }
}
#endif

Autoconnect Profiler is situational. If you plan to connect a QA machine to the Profiler automatically and watch it live, leave it on for convenience. If there's no such plan, there's no reason to enable it.

What to turn off for a QA build

Deep Profiling Support stays off by default. It allows function-call-level instrumentation, but the overhead can be substantial. A stutter measured with it enabled needs to be interpreted in light of that overhead. Use it deliberately in a separate build when investigating a particular scenario.

Script Debugging stays off too. Enable it when someone needs to attach a debugger. Debugging information and runtime behavior can differ, so there's no need to enable it for a general QA build with no debugger planned.

The trap — dev build performance isn't shipping performance

A Development Build and a release build are not equivalent performance conditions. Extra code paths behind DEVELOPMENT_BUILD branches and any diagnostic options you enable can affect measurements. If QA reports an FPS number measured on a dev build as "shipping performance," that can lead to the wrong conclusion. Root-causing frame drops themselves is covered in part one of the stutter-diagnosis series and the instrumentation walkthrough — if that instrumentation ran on a dev build, the result needs a "measured on dev build" caveat attached, every time.

When QA has to run against a release build

For moments that need exactly the shipping behavior — performance validation, a final check before store submission — QA has to run against a release build. Check which diagnostic conditions change at that point.

• Development-build diagnostics — file and line information in stack traces depends on build and symbol settings, so verify it in the release candidate itself
• The Profiler workflow used for development builds — do not assume you can instrument the release candidate in the same way without checking
• The on-screen watermark — if you used it to identify dev builds, keep a separate build identifier in the release candidate
• Every branch behind DEVELOPMENT_BUILD — QA-only overlays and diagnostic logs vanish along with it

Even when diagnostic options differ, QA still needs to exercise release builds. Effects of stripping or conditional compilation can surface problems a development build misses.

Wrapping up

Development Build isn't one switch — it's a bundle of them. Start QA builds from a default of Development Build on, Deep Profiling and Script Debugging off, and make sure the same scenarios run against a release build at least once before shipping. Planning QA around the assumption that the two builds show you different things is the surest way to avoid the trap.

We built our own Rekon with runtime capture that does not depend on Development Build-only code. Video capture does require FFmpeg on desktop and is not supported in mobile builds. When adding it to a release candidate, verify the hotkey and saved capture on the target platform.