Skip to content

v10.62.0

Choose a tag to compare

@sunnylqm sunnylqm released this 18 Oct 13:19
c98c2d6

English

One stored layout on every platform

Android, iOS and HarmonyOS now persist the update state in the same layout: two stores named pushy_state and pushy_cache (an Android SharedPreferences file, an iOS NSUserDefaults suite, a HarmonyOS preferences file), with the same keys on every platform, string values and a schemaVersion. This is a native release: rebuild the app, and run pod install on iOS.

The first launch of the new binary migrates the old layout once:

  • Carried over: the uuid (so gray-rollout buckets stay the same), the native configuration, the round breadcrumb, the bundle hash cache and the binary identity.
  • Dropped: the hot-update state, version metadata, first-load marker and response cache. A release build always gets a new build time, so this launch counts as a binary upgrade and would have cleared them anyway; the app starts on its packaged bundle, as after any app upgrade. Debug builds (build time fixed at "0") also return to the packaged bundle once.
  • Safe to interrupt: the migration can be killed at any step and finishes on the next launch. If it cannot run, the app starts as a fresh install that keeps its uuid, and the migration is retried on the next launch.
  • Old keys are deleted after the new stores are written. Only keys this SDK has ever written are touched.

Behaviour changes

  • Downgrading to an older binary (sideloading, adb install -d, enterprise distribution; app stores do not allow it) now looks like a fresh install to the old binary: no hot update, no native configuration until JS runs, and a new uuid, so gray-rollout buckets change while the old binary is installed. Upgrading again restores the previous uuid.
  • iOS keeps the update state in its own pushy_state / pushy_cache suites instead of standardUserDefaults. Clearing the app's defaults domain (a common logout step) no longer wipes the uuid and the hot-update state. The SDK also no longer collides with host keys such as an unprefixed packageVersion. The existing privacy manifest entry (CA92.1) still covers it.

For integrators

  • Code that read the SDK's keys directly (the Android update SharedPreferences file, iOS standardUserDefaults, the HarmonyOS update preferences) will no longer find them: they are now removed, and they were never a public interface.
  • The layout and the migration rules are described in docs/STORED_STATE_LAYOUT.md.
  • The iOS examples (Example/e2etest, Example/testHotUpdate, Example/expoUsePushy) adopt the UIScene life cycle, which apps built with the iOS 27 SDK need in order to launch on iOS 27. The Expo example uses Expo's own EXExpoAppSceneDelegate (Expo 57.0.23 or later).

Full changelog

中文

三端统一的落盘格式

Android、iOS、鸿蒙现在用同一种格式保存更新状态:两个存储 pushy_state 和 pushy_cache(Android 是 SharedPreferences 文件,iOS 是 NSUserDefaults suite,鸿蒙是 preferences 文件),三端键名相同,值一律是字符串,并带有 schemaVersion。这是原生版本,需要重新构建应用,iOS 请执行 pod install。

新二进制第一次启动时会一次性迁移旧格式:

  • 保留:uuid(灰度分桶保持不变)、原生配置、流程中断标记、bundle 摘要缓存和二进制身份。
  • 丢弃:热更状态、版本元信息、首次加载标记和响应缓存。release 构建每次都会写入新的构建时间,这次启动本来就会被判为二进制升级并清掉这些内容;应用从内置包启动,与任何一次应用升级相同。debug 构建(构建时间固定为 "0")也会回到内置包一次。
  • 可以中断:迁移在任何一步被杀,下次启动都会继续完成。迁移无法执行时,应用按全新安装启动但保留 uuid,下次启动再重试迁移。
  • 旧键会删除:新存储写好后才删旧键,只删本 SDK 写过的键。

行为变化

  • 降级到旧二进制(侧载、adb install -d、企业分发;应用市场不允许降级)时,旧二进制会表现为全新安装:没有热更版本,JS 运行前没有原生配置,uuid 重新生成,所以降级期间灰度分桶会变。再升级回来时,uuid 恢复为降级前的值。
  • iOS 把更新状态放在独立的 pushy_state / pushy_cache suite 里,不再写 standardUserDefaults。清空应用的 defaults 域(常见于退出登录)不会再抹掉 uuid 和热更状态,SDK 也不再与宿主的键(比如无前缀的 packageVersion)冲突。现有的隐私清单条目(CA92.1)照样覆盖。

接入方须知

  • 如果代码直接读取过 SDK 的键(Android 的 update SharedPreferences 文件、iOS 的 standardUserDefaults、鸿蒙的 update preferences),升级后将读不到:这些键已被删除,它们也从来不是公开接口。
  • 存储格式与迁移规则见 docs/STORED_STATE_LAYOUT.md。
  • iOS 示例工程(Example/e2etest、Example/testHotUpdate、Example/expoUsePushy)改用 UIScene 生命周期,用 iOS 27 SDK 构建的应用需要它才能在 iOS 27 上启动。Expo 示例使用 Expo 自带的 EXExpoAppSceneDelegate(需 Expo 57.0.23 及以上)。

完整变更记录