DEV Community

Sebastien Lato
Sebastien Lato

Posted on

SwiftUI App Health Dashboard Architecture (Internal Telemetry UI)

#swiftui #architecture #observability #diagnostics

Most teams debug production apps from the outside:

  • crash dashboards
  • log aggregators
  • analytics tools
  • guesswork

The best teams debug from inside the app.

This post shows how to design an internal App Health Dashboard in SwiftUI:

  • live diagnostics
  • feature status
  • config visibility
  • environment awareness
  • zero impact on production UX

This is how serious apps stay operable at scale.

🧠 The Core Principle

If your app can’t explain its own state, you don’t control it.

Observability should be visible, not buried in logs.

🧱 1. What an App Health Dashboard Is (and Isn’t)

It is:

  • a diagnostic surface
  • internal tooling
  • runtime visibility
  • environment-aware UI

It is not:

  • a user-facing feature
  • a debug dump
  • a random settings screen

Think of it as an operations console, embedded safely.

📦 2. Health Data Model

Define a typed snapshot of app health:

struct AppHealthSnapshot {
    let appVersion: String
    let environment: Environment
    let configVersion: String
    let featureFlags: [Feature: Bool]
    let experiments: [Experiment: Variant]
    let memoryUsage: MemoryStats
    let networkState: NetworkStatus
    let lastErrors: [AppError]
}
Enter fullscreen mode Exit fullscreen mode

One object. One truth.

🧭 3. Health Providers (Decoupled Sources)

Each subsystem contributes health data:

protocol HealthProvider {
    func snapshot() -> PartialHealth
}
Enter fullscreen mode Exit fullscreen mode

Examples:

  • NetworkHealthProvider
  • ConfigHealthProvider
  • PermissionHealthProvider
  • MemoryHealthProvider
  • FeatureFlagHealthProvider

The dashboard composes, never queries directly.

🧬 4. Aggregation Layer 

final class AppHealthService {
    let providers: [HealthProvider]

    func snapshot() -> AppHealthSnapshot {
        // merge partial snapshots
    }
}
Enter fullscreen mode Exit fullscreen mode

This ensures:

  • consistent timing
  • atomic views
  • predictable refresh

Never fetch health data ad-hoc from the UI.

🔐 5. Safe Access Control

The dashboard must be:

  • hidden by default
  • inaccessible to normal users
  • gated by environment or gesture

Examples:

  • debug builds only
  • QA flag
  • secret gesture
  • internal account check

Never expose internal state accidentally.

🧪 6. Real-Time vs Snapshot Data

Not all data should be live.

Good live data:

  • network reachability
  • memory pressure
  • active flags

Snapshot-only:

  • app version
  • config hash
  • build metadata

Avoid constant polling.

🧠 7. Diagnostic Actions (Carefully)

Optional actions:

  • refresh config
  • clear caches
  • toggle debug logging
  • simulate failures (non-prod)

Rules:

  • never mutate production data
  • never bypass auth
  • actions must be reversible
  • actions must be logged

This is a tool, not a playground.

⚠️ 8. Common App Health Anti-Patterns

Avoid:

  • dumping raw logs
  • exposing secrets
  • mixing debug UI with user settings
  • relying on print statements
  • building this too late

If you add it only after incidents, it’s already late.

🧠 Mental Model

Think:

Subsystems
 → Health Providers
   → Aggregation
     → Diagnostic UI
Enter fullscreen mode Exit fullscreen mode

Not:

“Let’s just show some info here”

🚀 Final Thoughts

An App Health Dashboard gives you:

  • faster incident diagnosis
  • safer debugging
  • clearer production visibility
  • confidence during releases
  • fewer blind spots

The best apps are not just functional —
they are self-aware.

Top comments (0)