Expo'da güncellemeleri OTA ile yönetmek

Mobil geliştirmenin en sinir bozucu kısıtlarından biri mağaza döngüsü. Bir hata gördünüz, düzelttiniz, derleme aldınız — ama kullanıcıya ulaşması App Store incelemesinin bitmesini bekliyor. Kritik bir hata için bu süre kabul edilebilir değil.

OTA (Over-the-Air) bu sorunu çözüyor, ama tam olarak anlamadan kullanmak da sorun yaratıyor. Expo Updates ile birkaç yıldır üretim ortamında çalışıyorum; öğrendiklerimi burada özetleyeceğim.

OTA nedir, ne değildir

OTA güncelleme, uygulamanın JavaScript paketini (bundle) ve varlıklarını (assets) mağaza incelemesi olmadan cihaza göndermek demek. Expo’nun OTA altyapısı bunu expo-updates paketi üzerinden yönetiyor.

Kritik sınır: native kod değiştirilemez. Yeni bir native modül eklediğinizde, bir Expo SDK sürümü atladığınızda ya da uygulama izinlerini değiştirdiğinizde mağaza sürümü şarttır. OTA yalnızca JavaScript katmanındaki değişiklikleri taşıyabiliyor.

Bu ayrımı aklınızda net tutmak gerekiyor. “OTA’ya gönderirim” diye başladığınız bir değişiklik sonunda native bağımlılık gerektiriyorsa, planınızı en baştan yeniden yapmak durumunda kalırsınız.

Expo Updates ile basit yapılandırma

eas.json dosyasında güncelleme kanalları (channels) tanımlıyorum:

{
  "build": {
    "production": {
      "channel": "production"
    },
    "staging": {
      "channel": "staging"
    }
  }
}

app.json veya app.config.js içinde güncelleme politikasını belirliyorum:

{
  "expo": {
    "updates": {
      "enabled": true,
      "fallbackToCacheTimeout": 0,
      "checkAutomatically": "ON_LOAD"
    }
  }
}

fallbackToCacheTimeout: 0 ile uygulama açılışında güncelleme varsa beklemeden indiriyor ve bir sonraki açılışta uygulayıyor. Bu “indirip bir sonraki oturumda uygula” yaklaşımı en az sürtünmeli deneyimi veriyor.

EAS Update ile güncelleme yayınlamak

# Staging kanalına güncelleme gönder
eas update --channel staging --message "Form doğrulama hatası düzeltildi"

# Production'a
eas update --channel production --message "v2.4.1 hotfix"

Bu komut JavaScript paketini ve değişen varlıkları EAS (Expo Application Services) sunucularına yükleyip ilgili kanala bağlıyor. O kanalı izleyen cihazlar bir sonraki uygulama açılışında güncellemeyi alıyor.

Güncelleme stratejisi

Üretim ortamında iki yaklaşım var: pasif güncelleme ve force update.

Pasif güncelleme, uygulamanın arka planda güncellemeyi indirip bir sonraki açılışta uygulaması. Kullanıcı hiçbir şey fark etmiyor. Kritik olmayan düzeltmeler için bu yeterli.

Kritik bir güvenlik açığı ya da ciddi bir işlev hatası için ise güncellemeyi zorlamak gerekebilir. expo-updates API’si üzerinden kontrol alınabilir:

import * as Updates from 'expo-updates';

async function checkForUpdate() {
  try {
    const update = await Updates.checkForUpdateAsync();
    if (update.isAvailable) {
      await Updates.fetchUpdateAsync();
      await Updates.reloadAsync();
    }
  } catch (e) {
    // Ağ yoksa sessizce geç
  }
}

Bu kodu uygulama açılışında ya da kullanıcı belirli bir ekrana girdiğinde çağırabilirsiniz. reloadAsync() uygulamayı güncel paket ile yeniden başlatıyor.

Kanal yönetimi ve test süreci

Üretim ortamına OTA göndermeden önce staging kanalında test etmek iş akışımın değişmez parçası. EAS update, aynı komutun farklı kanallarla çalışmasına izin verdiği için bu çok basit.

Bir güncellemeyi yayınlamadan önce şu soruyu soruyorum: bu değişiklik native bir bağımlılığa dokunuyor mu? Hayırsa OTA gönderebilirim. Evetse mağaza sürümü planına geçiyorum.

OTA’nın gerçek değeri

Mağazaya göndereceğim her sürüm Apple incelemesini beklemek zorunda. Bu süre değişken, ama genellikle 24-48 saat. Bir üretim hatasını bu süre bekletmek çoğu zaman kabul edilemez.

OTA güncellemelerle JavaScript katmanındaki hataları birkaç dakika içinde tüm kullanıcılara ulaştırabiliyorum. Bu hız, mobil geliştirmenin en büyük kısıtlarından birini önemli ölçüde hafiflettiriyor. Ama bu araç ne kadar güçlü olursa olsun, native sınırın bilincinde olmak gerekiyor — aksi halde yanlış araçla yanlış sorunu çözmeye çalışırsınız.