丢失旧代码后，能否用全新Expo EAS项目更新应用商店现有应用？

一、核心可行性结论 #

完全可以提交现有应用的更新，但必须满足以下关键前提：

• 严格保持Android包名/iOS Bundle ID与原应用完全一致
• 使用与原应用匹配的签名凭证：Android需保留原上传密钥（或通过Google Play应用签名重置流程获取对应密钥）；iOS需使用同一开发者账号下的分发证书、推送证书（若有），或重新生成对应证书但确保Bundle ID匹配
• 新版本的version（对外版本号）和buildNumber/versionCode（内部版本号）必须高于商店中当前应用的版本

二、存储模块的潜在影响 #

• 本地存储：
  • 若原应用使用SharedPreferences（Android）、NSUserDefaults（iOS）或RN AsyncStorage，重构后改用expo-secure-store/expo-file-system时，需保证存储键名完全一致才能读取旧数据，否则用户本地数据会直接丢失
  • Expo存储API与原生RN存储的底层实现存在差异，直接替换API会导致旧数据无法读取，必须编写数据迁移逻辑
• 云端存储：
  • 若使用Firebase Storage、AWS S3等第三方服务，只要保持相同的项目配置、权限规则，新应用可无缝对接，用户云端数据不受影响

三、令牌类模块的潜在影响 #

• 推送令牌（APNs/FCM）：
  • 包名/Bundle ID和签名凭证匹配的情况下，新应用注册的推送令牌会被原推送服务识别，用户不会丢失推送订阅
  • 若更换推送服务提供商，需做令牌迁移，否则用户将无法接收推送
• 身份令牌（如JWT）：
  • 只要后端验证逻辑不变，新应用生成的令牌格式、签名算法与原应用一致，就能正常通过验证
  • 若重构时修改了令牌生成逻辑，必须同步更新后端验证规则，否则会出现登录失效、权限异常问题
• 支付令牌（Apple Pay/Google Pay）：
  • 保持相同的商户ID、包名/Bundle ID，新应用可正常使用原支付配置，支付流程不受影响

四、其他注意事项 #

• App Store和Google Play会通过签名凭证、包名/Bundle ID验证应用身份，匹配即视为同一应用的更新，不会被当作新应用审核
• 重构时尽量保持原应用核心功能、用户体验一致，避免因功能差异过大导致审核被拒
• 建议先在测试环境用原应用签名凭证打包，安装到测试设备验证数据迁移、令牌功能正常后，再提交正式更新

内容的提问来源于stack exchange，提问作者hijack