No debug APIs or test endpoints in release build

A production build that points to staging APIs or includes debug tooling exposes real users to test data, unstable endpoints, and developer-only interfaces. More critically, staging endpoints typically have weaker auth, lower rate limits, and no data residency guarantees — a production release hitting a staging backend may log user PII into non-compliant systems. CWE-489 (active debug code) and CWE-200 (information exposure) both apply: redux-logger printing state trees to device logs, or a localhost URL falling back to a staging server, creates information exposure paths that violate user trust and may constitute a GDPR Art. 5 processing purpose violation. App store reviewers who discover staging URLs during dynamic analysis can reject the binary.

Gate all debug tooling behind __DEV__ and drive API URLs from environment variables, never from hardcoded strings in source.

// src/config.ts
export const API_URL = process.env.EXPO_PUBLIC_API_URL ?? 'https://api.yourapp.com';

// Conditionally load debug middleware
const middleware: Middleware[] = [thunk];
if (__DEV__) {
  const { createLogger } = await import('redux-logger');
  middleware.push(createLogger());
}

Set EXPO_PUBLIC_API_URL as an EAS secret for production builds (eas secret:create --scope project --name EXPO_PUBLIC_API_URL --value https://api.yourapp.com). Verify by running eas build --profile production --local and grepping the bundle for staging hostnames before submitting.