2nd/10_Wiki/Topics/Coding/RN_OTA_Updates_CodePush.md

id, title, category, status, source_trust_level, verification_status, created_at, updated_at, tags, tech_stack, applied_in, aliases

id	title	category	status	source_trust_level	verification_status	created_at	updated_at	tags	tech_stack	applied_in	aliases
rn-ota-updates-codepush	RN OTA — Expo Updates / CodePush 후속	Coding	draft	B	conceptual	2026-05-09	2026-05-09	react-native ota expo vibe-coding	language applicable_to TypeScript / Expo Updates React Native		over-the-air hot update CodePush EAS Update Expo Updates

RN OTA Updates

JS 번들만 변경하면 store review 없이 즉시 사용자에게 배포. Expo Updates (CodePush 종료 후 표준) + 채널 + rollback. 단 native code 변경은 OTA 불가.

📖 핵심 개념

• OTA: JS bundle + assets만 교체. native 코드, infoplist, AndroidManifest 변경은 store 빌드.
• 채널: production / staging / canary.
• Rollback: 새 버전 문제 시 이전 만료 / 강제.

💻 코드 패턴

Expo Updates 셋업

npm install expo-updates
npx expo install expo-updates

// app.json
{
  "expo": {
    "runtimeVersion": "1.0.0",
    "updates": {
      "url": "https://u.expo.dev/<project-id>",
      "fallbackToCacheTimeout": 0,
      "checkAutomatically": "ON_LOAD"
    }
  }
}

EAS Update publish

eas update --branch production --message "v1.0.1: bug fix"

클라이언트 — manual check

import * as Updates from 'expo-updates';

async function checkForUpdate() {
  try {
    const update = await Updates.checkForUpdateAsync();
    if (update.isAvailable) {
      await Updates.fetchUpdateAsync();
      // 사용자에게 안내 후 reload
      await Updates.reloadAsync();
    }
  } catch (e) { /* ignore */ }
}

Runtime version 호환성

• runtimeVersion 같으면 OTA OK.
• native 변경 시 runtimeVersion bump → 새 store 빌드 필수, 옛 OTA 받지 않음.

채널 / 환경 분리

eas update --branch staging
# staging 빌드만 staging 채널 받음

const channel = Updates.channel; // 'production' / 'staging'

🤔 의사결정 기준

변경	OTA
JS 비즈니스 로직 / UI	✅
새 npm package (JS only)	✅
Native module 추가	❌ store 필요
Asset (이미지)	✅
app icon / splash	❌
Push 인증서 / 권한	❌
큰 변경 (UX 전면 개편)	OTA 가능하지만 staged rollout 권장

❌ 안티패턴

• runtimeVersion bump 안 하고 native 변경: 옛 binary 가 새 JS 받음 → crash.
• production 채널 직접 publish: 검증 없음. staging → production 단계.
• rollback 절차 없음: 사고 시 모두 영향.
• 거대 update (수 MB): 사용자 모바일 데이터 부담. 변경 부분만.
• store 빌드와 OTA 버전 mismatch 모니터링 X: 어떤 사용자 어떤 버전 모름.
• OTA 로 보안 패치만 의존: 사용자가 OTA 받기 전 노출. 진짜 보안 = store 빌드.

🤖 LLM 활용 힌트

• "JS only 변경 = OTA, native 변경 = runtimeVersion bump + store" 명시.
• 채널 분리 (production / staging).

🔗 관련 문서

• DevOps_Deployment_Strategies
• Feature_Flags_in_Practice