Rilis aplikasi mobile memiliki risiko asimetris dibandingkan aplikasi web. Ketika bug fatal lolos ke tahap produksi pada React Native, Anda tidak dapat melakukan rollback server-side secara instan. Proses rilis hotfix biner memerlukan peninjauan reguler dari Apple App Store dan Google Play Store yang dapat memakan waktu 12 hingga 48 jam. Jika fitur kritis menyebabkan crash beruntun (crash-loop) saat startup atau merusak alur transaksi, tim pengembang memerlukan kontrol langsung untuk menonaktifkan fitur tersebut dari jarak jauh tanpa menunggu persetujuan store.

Arsitektur Remote Kill-Switch dengan Fallback Cache

Arsitektur kill-switch yang tangguh harus memenuhi dua kriteria utama: non-blocking startup dan offline resiliency. Mengambil konfigurasi langsung lewat jaringan sebelum me-render aplikasi (blocking cold start) memperkenalkan single point of failure jika penyedia remote config mengalami degradasi performa atau koneksi pengguna bermasalah.

Solusi yang teruji adalah menerapkan strategi Stale-While-Revalidate menggunakan penyimpanan lokal cepat seperti react-native-mmkv, dikombinasikan dengan Firebase Remote Config atau Unleash. Nilai dari cache lokal dibaca secara sinkron saat inisialisasi aplikasi, sementara sinkronisasi jaringan dilakukan di latar belakang.

import { MMKV } from 'react-native-mmkv';
import remoteConfig from '@react-native-firebase/remote-config';

const storage = new MMKV({ id: 'app-killswitch-cache' });

interface FeatureFlags {
  isNewCheckoutEnabled: boolean;
  isBiometricAuthEnabled: boolean;
}

const DEFAULT_FLAGS: FeatureFlags = {
  isNewCheckoutEnabled: false,
  isBiometricAuthEnabled: false,
};

class ConfigService {
  public getFlag(key: keyof FeatureFlags): boolean {
    const cached = storage.getBoolean(key);
    if (cached !== undefined) {
      return cached;
    }
    return DEFAULT_FLAGS[key];
  }

  public async syncRemoteFlags(): Promise<void> {
    try {
      await remoteConfig().setConfigSettings({
        minimumFetchIntervalMillis: 300000, // 5 menit untuk produksi
      });
      await remoteConfig().setDefaults(DEFAULT_FLAGS as any);
      
      const fetched = await remoteConfig().fetchAndActivate();
      if (fetched) {
        const allValues = remoteConfig().getAll();
        Object.keys(DEFAULT_FLAGS).forEach((key) => {
          const val = allValues[key]?.asBoolean();
          if (val !== undefined) {
            storage.set(key, val);
          }
        });
      }
    } catch (error) {
      // Network fail: aplikasi tetap berjalan menggunakan cache MMKV
    }
  }
}

export const configService = new ConfigService();

Integrasi React Error Boundary: Dynamic Feature Short-Circuit

Remote kill-switch membutuhkan intervensi manual dari engineer untuk mematikan flag di dashboard. Namun, pada insiden runtime tak terduga, aplikasi harus mampu mematikan fitur secara otomatis pada sisi klien sebelum pengguna mengalami forced close berulang.

Kombinasi React Error Boundary dengan cache lokal memungkinkan aplikasi mendeteksi crash pada subtree komponen fitur tertentu, menulis status pembatalan darurat ke local storage, dan menampilkan fallback UI secara elegan.

import React, { Component, ErrorInfo, ReactNode } from 'react';
import { View, Text, StyleSheet, TouchableOpacity } from 'react-native';
import { storage } from './ConfigService';

interface Props {
  featureKey: string;
  fallback: ReactNode;
  children: ReactNode;
  onIncidentReport?: (error: Error, featureKey: string) => void;
}

interface State {
  hasError: boolean;
}

export class FeatureErrorBoundary extends Component<Props, State> {
  constructor(props: Props) {
    super(props);
    this.state = { hasError: false };
  }

  static getDerivedStateFromError(): State {
    return { hasError: true };
  }

  componentDidCatch(error: Error, errorInfo: ErrorInfo) {
    const { featureKey, onIncidentReport } = this.props;

    // Aktifkan local kill-switch otomatis untuk sesi berikutnya
    storage.set(featureKey, false);

    if (onIncidentReport) {
      onIncidentReport(error, featureKey);
    }
  }

  render() {
    if (this.state.hasError) {
      return this.props.fallback;
    }
    return this.props.children;
  }
}

Komponen tersebut digunakan untuk membungkus fitur berisiko tinggi tanpa mempengaruhi container root aplikasi:

export const CheckoutModule = () => {
  const isEnabled = configService.getFlag('isNewCheckoutEnabled');

  if (!isEnabled) {
    return <LegacyCheckoutScreen />;
  }

  return (
    <FeatureErrorBoundary
      featureKey="isNewCheckoutEnabled"
      fallback={<LegacyCheckoutScreen />}
      onIncidentReport={(err) => reportErrorToMonitoring(err, 'isNewCheckoutEnabled')}
    >
      <NewCheckoutScreen />
    </FeatureErrorBoundary>
  );
};

Skema Observabilitas dan Telemetry

Saat remote kill-switch diubah atau komponen me-render fallback akibat error boundary, status transisi wajib terdokumentasi dalam analitik dan monitoring logging (misalnya Datadog atau Sentry). Format payload terstruktur memastikan sistem alerting dapat memicu audit instan.

interface KillSwitchTelemetryPayload {
  event_name: 'feature_killswitch_executed';
  flag_key: string;
  trigger_source: 'remote_config' | 'error_boundary_auto_disable';
  action: 'rendered_fallback' | 'feature_disabled';
  app_version: string;
  build_number: string;
  platform: 'ios' | 'android';
  timestamp: number;
  error_message?: string;
  stack_trace?: string;
}

// Contoh pengiriman log ke Sentry / Datadog
export function trackKillSwitchEvent(payload: KillSwitchTelemetryPayload): void {
  fetch('https://telemetry-gateway.internal.corp/events', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify(payload),
  }).catch(() => {
    // Non-blocking telemetry capture
  });
}

Checklist Postmortem dan Pencegahan Pipeline Rilis

Setelah sebuah fitur berhasil di-kill dan ancaman operasional mereda, tim harus menuntaskan mitigasi teknis lanjutan untuk mencegah regresi di masa depan:

  1. Isolasi Kode Mati: Fitur yang dimatikan melalui remote flag tidak boleh dibiarkan terkatung-katung lebih dari 2 siklus sprint rilis. Lakukan hard rollback pada Git mainline untuk biner berikutnya.
  2. Audit Kontrak Konfigurasi: Verifikasi apakah tipe data pada dashboard remote config sinkron dengan schema parsing di aplikasi. Gunakan schema validator (seperti Zod) saat mem-parsing JSON payload dari remote config untuk menghindari crash akibat null reference.
  3. Staged Rollout pada Toko Aplikasi: Terapkan Phased Release di App Store (distribusi bertahap selama 7 hari) dan Staged Rollout di Play Store (mulai dari 5%, 10%, hingga 100%) bersamaan dengan pemantauan metrik crash-free session.
  4. Health-Check Pre-Rollout: Pastikan flag kill-switch untuk fitur baru selalu berstatus inactive atau disabled secara default pada binary release hingga verifikasi production smoke test tuntas.