Saat SDK Opsional Bertindak seperti Infrastruktur Inti

Kegagalan launch yang umum di aplikasi mobile hasil vibe coding adalah analytics, attribution, atau crash reporting diinisialisasi bersamaan dengan service yang benar-benar kritis. Jika salah satu SDK opsional itu bermasalah di perangkat tertentu atau dalam kondisi jaringan tertentu, seluruh aplikasi bisa mati sebelum screen pertama muncul.

Ini terjadi karena kode setup hasil AI cenderung memperlakukan setiap dependency seolah sama pentingnya. Tanpa sistem tier yang eksplisit, tidak ada pembedaan arsitektural antara infrastruktur yang wajib ada dan observer yang sekadar nice-to-have. Semuanya berubah menjadi wajib ada secara tidak sengaja.

Tiga Tier Dependency

Setiap dependency di aplikasi Anda masuk ke salah satu dari tiga bucket. Menggambar batas ini secara eksplisit adalah perbedaan antara aplikasi yang bertahan saat tumbuh dan aplikasi yang mati karena seribu production crash:

  • Hard dependencies: Jika ini gagal, aplikasi Anda tidak bisa render. Parsing config. Pembuatan storage. Konstruksi core service. Ini fondasi Anda.
  • Soft dependencies: Ini bisa gagal dengan graceful. Auth. Feature yang bergantung pada network. Flow yang bergantung pada permission. App shell tetap render; pengguna melihat pengalaman yang menurun, bukan crash.
  • Optional dependencies: Ini bisa gagal secara senyap. Analytics. Crash reporting. A/B testing. Mereka tidak pernah memblokir aplikasi. Mereka pengamat, bukan peserta.

Kesalahan yang dibuat kebanyakan aplikasi hasil vibe coding adalah memperlakukan semuanya sebagai hard dependency. Setiap SDK diinisialisasi saat startup. Setiap kegagalan menjadi startup crash. Padahal analytics SDK Anda tidak pantas mendapat status yang sama dengan storage layer Anda.

Batas Hard Dependency

Batas hard dependency memvalidasi config dan membangun services. Jika gagal, aplikasi menampilkan error screen dengan tombol retry - bukan kekosongan putih yang akan diberi rating satu bintang oleh pengguna di App Store.

// 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)}</>
}

Perhatikan pattern render prop di sini. Boundary ini meneruskan services yang sudah diinisialisasi ke child components-nya. Child components tidak membangun service; mereka menerimanya. Konstruksi terjadi tepat satu kali, dan kegagalan apa pun ditangkap di boundary - bukan bocor ke production crash report.

Optional Boundary

Bandingkan itu dengan optional dependencies. Ini tidak boleh membuat aplikasi Anda crash. Jika Mixpanel down, aplikasi Anda bahkan tidak tersendat:

// 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}</>
}

Perbedaan pendekatannya mencolok. Hard boundary: jika gagal, tampilkan error screen. Optional boundary: jika gagal, log peringatan lalu lanjutkan. Keduanya eksplisit. Tidak ada yang pura-pura menjadi yang lain.

Kebanyakan production crash pada aplikasi hasil vibe coding berasal dari satu kesalahan: memperlakukan soft atau optional dependency sebagai hard dependency. Autotomy Expo Starter Pack menggambar batas-batas ini sejak hari pertama sehingga Anda tidak perlu belajar pelajaran ini pada jam 2 pagi.