In Angular, what does isDevMode() return, and what actually differs between development mode and production mode at runtime?

## One flag underneath Angular's framework code is sprinkled with checks like `if (ngDevMode) { ... }` and `ngDevMode && 'message'`. `ngDevMode` is a global. `isDevMode()` is the public way to read it: ```ts export function isDevMode(): boolean { return typeof ngDevMode === 'undefined' || !!ngDevMode; } ``` So development mode is the **default**: it holds unless something sets `ngDevMode` to `false`. ## Who decides the mode | How the app is built or started | `ngDevMode` | `isDevMode()` | | :-- | :-- | :-- | | `ng serve` (development configuration) | left defined for debugging | `true` | | `ng build` with the default production configuration (scripts optimized) | defined as `false` at build time | `false` | | Any build with `"optimization": false` | not forced off | `true` | | Code that calls `enableProdMode()` before bootstrap | set to `false` at runtime | `false` | The CLI's application builder injects `ngDevMode: false` as a compile-time constant whenever script optimization is on, which lets the minifier delete every dev-only branch. `enableProdMode()` still exists, but its own documentation discourages it because the CLI already handles the switch. ## What development mode adds - **Assertions and consistency checks** inside the framework that catch misuse early, including extra verification passes in change detection (covered in depth by the change-detection topic). - **Descriptive error messages**: a missing provider reports the token and its dependency path instead of a bare `NG0201`, plus a link to the error reference page. - **The `window.ng` debug utilities**: `ng.getComponent`, `ng.applyChanges`, `ng.getInjector` and friends. - **Angular DevTools support**: the extension refuses optimized builds because the hooks it needs are compiled out. - **Dev-only warnings**, such as console hints about misconfigurations. ## What production mode gains 1. **Smaller bundles**: messages, assertions and debug utilities are removed by tree-shaking. 2. **Less work per change detection pass**: no extra verification. 3. **No debugging surface** in the page: nothing publishes internals on `window`. ## Using `isDevMode()` in application code Reasonable uses: - verbose logging or extra `console` diagnostics during development; - registering development-only providers, such as a mock interceptor, behind a check at bootstrap; - showing a small "development build" banner. Things it is **not** for: - **Feature flags or environment configuration**: a staging build with optimization on reports `false` just like production. Use your own configuration for API URLs and toggles. - **Security**: anything gated only by `isDevMode()` is still in the shipped source unless the bundler removes it, and a non-optimized build flips it on. - **Replacing `environment.ts`**: the `environment.production` field in a project's environment files is just your data; Angular itself never reads it. It is common for teams to confuse the two. ## A common trap: behaviour that differs between modes Because development mode runs extra checks, some problems only show up there, and the absence of those checks can hide problems in production. Two practical consequences: - A bug report from production with a bare error code is best reproduced in a **non-optimized** build, where the same failure produces a full message. - Code must never *depend* on a dev-only side effect: anything that works only because a debug utility or dev-only branch exists will break when optimization removes it. ## Interview framing A crisp answer: `isDevMode()` reflects the `ngDevMode` flag; optimized CLI builds turn it off at compile time; development mode buys checks, readable errors and debugging tools at the cost of size and speed; and it is a diagnostics switch, not a configuration system.