Wenn optionale SDKs sich wie Kern-Infrastruktur verhalten

Ein häufiger Launch-Fehler in vibe-codierten Mobile-Apps ist, dass Analytics, Attribution oder Crash-Reporting zusammen mit wirklich kritischen Services initialisiert werden. Wenn eines dieser optionalen SDKs sich auf einem bestimmten Gerät oder unter einer bestimmten Netzwerkbedingung danebenbenimmt, kann die ganze App sterben, bevor überhaupt der erste Screen erscheint.

Das passiert, weil KI-generierter Setup-Code dazu neigt, jede Dependency als gleich wichtig zu behandeln. Ohne explizites Tier-System gibt es keinen architektonischen Unterschied zwischen Must-have-Infrastruktur und Nice-to-have-Beobachtern. Aus Versehen wird alles zu Must-have.

Drei Dependency-Tiers

Jede Dependency in deiner App fällt in einen von drei Buckets. Diese Grenzen explizit zu ziehen, ist der Unterschied zwischen einer App, die Wachstum überlebt, und einer, die an tausend kleinen Produktions-Crashes stirbt:

  • Hard Dependencies: Wenn diese fehlschlagen, kann deine App nicht rendern. Config-Parsing. Storage-Erzeugung. Konstruktion zentraler Services. Das ist dein Fundament.
  • Soft Dependencies: Diese können kontrolliert fehlschlagen. Auth. Netzwerkabhängige Features. Flows, die von Berechtigungen abhängen. Die App-Shell rendert weiter; der Nutzer sieht eine degradierte Experience statt eines Crashes.
  • Optional Dependencies: Diese dürfen still fehlschlagen. Analytics. Crash Reporting. A/B-Testing. Sie blockieren niemals die App. Sie beobachten nur, statt selbst Teil des Flows zu sein.

Die meisten vibe-codierten Apps machen denselben Fehler: Sie behandeln alles als hard. Jedes SDK wird beim Startup initialisiert. Jeder Fehler wird zu einem Startup-Crash. Aber dein Analytics-SDK verdient nicht denselben Status wie dein Storage-Layer.

Die Hard-Dependency-Boundary

Die harte Boundary validiert Config und konstruiert Services. Wenn sie fehlschlägt, zeigt die App einen Error Screen mit einem Retry-Button - und nicht diesen weißen leeren Nichts-Screen, für den Nutzer dich im App Store mit einem Stern abstrafen.

// src/context/hard-dependency-boundary.tsx
// This is the gatekeeper. If it fails, nothing else renders.

import * as SplashScreen from 'expo-splash-screen'

void SplashScreen.preventAutoHideAsync()

export function HardDependencyBoundary({
  children,
}: {
  children: (services: Services) => ReactNode
}) {
  const { services, ready, error, retry } =
    useHardDependencies()

  useEffect(() => {
    if (ready || error) void SplashScreen.hideAsync()
  }, [ready, error])

  if (error) {
    return (
      <ErrorScreen
        title='Startup failed'
        message={error.message}
        onRetry={retry}
      />
    )
  }

  if (!ready || !services) return null

  return <>{children(services)}</>
}

Beachte das Render-Prop-Pattern. Die Boundary gibt die initialisierten Services an ihre Kinder weiter. Die Kinder konstruieren keine Services; sie bekommen sie übergeben. Konstruktion passiert exakt einmal, und jeder Fehler wird an der Boundary abgefangen - nicht erst in einem Crash-Report aus der Produktion.

Die Optional Boundary

Vergleiche das mit optionalen Dependencies. Diese sollten niemals deine App crashen. Wenn Mixpanel ausfällt, darf deine App nicht einmal zucken:

// src/context/optional-dependency-boundary.tsx
// If analytics fails, we log a warning and keep going.

export function OptionalDependencyBoundary({
  children,
}: PropsWithChildren) {
  const { analytics, crashReporting } = useServices()

  useEffect(() => {
    try {
      analytics.track('app_started')
    } catch (error) {
      if (__DEV__) console.warn('Analytics failed:', error)
    }

    try {
      crashReporting.setContext('app', { started: true })
    } catch (error) {
      if (__DEV__) console.warn('Crash reporting failed:', error)
    }
  }, [analytics, crashReporting])

  return <>{children}</>
}

Der Unterschied in der Haltung ist deutlich. Hard Boundary: Wenn sie fehlschlägt, zeige einen Error Screen. Optional Boundary: Wenn sie fehlschlägt, logge eine Warnung und mach weiter. Beides ist explizit. Nichts davon tut so, als wäre es etwas anderes.

Die meisten Produktions-Crashes in vibe-codierten Apps kommen von genau einem Fehler: Soft oder optionale Dependencies wie harte zu behandeln. Das Autotomy Expo Starter Pack zieht diese Grenzen von Tag eins an, damit du diese Lektion nicht um 2 Uhr nachts lernen musst.