Skip to content

ADR-0013: Adopt CodePushNext as the Upstream for Appcircle's React Native CodePush SDK

  • Status: 📝 Proposed
  • Date: 2026-03-22
  • Owners: @cagkan, @osmank, @enver
  • Related: ac-code-push-react-native-sdk, ac-codepush-mobile

Context

Microsoft retired its App Center CodePush service. Appcircle took over both the server infrastructure and the React Native SDK (a fork of microsoft/react-native-code-push). CodePush is sold as a commercial product to customers.

React Native ships a new major version approximately every two months, each carrying native bridge changes (TurboModules/JSI, Swift AppDelegate, Gradle/AGP) that break SDK compatibility. Keeping pace requires sustained native mobile expertise on both iOS and Android.

Current state:

  • Our production SDK is ac-code-push-react-native-sdk (@appcircle/react-native-code-push), currently supporting up to RN 0.80 (branch CSM-144). ac-codepush-mobile is the upstream reference fork and demo app host, not the shipped artifact.
  • Latest React Native is 0.84 — we are four major versions behind.
  • The engineers maintaining the SDK have flagged that the work exceeds current capacity and requires dedicated native mobile expertise.
  • The gap compounds with every RN release cycle.

A community project, CodePushNext (@code-push-next/react-native-code-push), has emerged to fill this gap. It is an MIT-licensed fork of the same Microsoft codebase, at v10.4.0 with support up to RN 0.82, maintained by 3-5 active contributors. Our own repository contains an incomplete branch (feature/pull-code-push-nexts-changes2) that attempted to incorporate their work.

Decision

Fork CodePushNext and publish as @appcircle/react-native-code-push with only the minimal Appcircle-specific customization needed for server integration (default endpoint URL, deployment key handling). Track and sync with each CodePushNext release.

Minimal customization is a first-class constraint. Every custom change beyond server integration creates merge conflict risk on every future sync. The goal is a diff small enough that syncing a new CodePushNext release takes hours, not days, and does not require RN native expertise.

Ownership: The Product Engineering team (lead: Enver Gökmen) owns the ongoing sync cadence — watching CodePushNext releases, merging upstream changes, verifying compatibility, and publishing the Appcircle-branded package. This is a recurring, low-effort task (estimated hours per RN release cycle, not days) given the minimal-diff constraint above, but it requires a clear single owner to avoid drift.

Options Considered

Option A: Self-maintain Option B: Recommend third-party (no Appcircle brand) Option C: Fork CodePushNext (Chosen)
Description Continue maintaining our fork independently Point customers directly to CodePushNext (no Appcircle SDK) Fork CodePushNext, apply minimal customization, track upstream
Pros Full control, no external dependency Zero maintenance cost Native bridge work handled upstream; bounded maintenance; brand preserved; MIT license
Cons Requires dedicated RN native specialist; compounding debt with each RN release; already 4 versions behind No branded SDK; weakened trust/support; no server-integration enforcement at SDK layer Dependency on small community (3-5 maintainers); release lag between CodePushNext and our publish

Option A — Continue self-maintaining

Keep the current fork and maintain native bridge compatibility independently.

  • Pros: Full control over the codebase; no external dependency.
  • Cons: Requires at least one full-time RN native specialist. With ~2-month RN release cadence, this is a permanent, compounding commitment. We are already four versions behind with no clear path to catch up.

Option B — Recommend a third-party SDK directly (no Appcircle brand)

Point customers to CodePushNext without maintaining our own SDK. This is what Bitrise does.

  • Pros: Zero maintenance cost.
  • Cons: Customers purchasing Appcircle's CodePush product receive no Appcircle-branded SDK. Trust and support surface is weakened. We lose the ability to enforce our server integration at the SDK layer.

Option C — Fork CodePushNext, minimal customization, track upstream (Chosen)

  • Pros: Native bridge work is handled by CodePushNext. We maintain only the Appcircle integration layer. Brand is preserved. SDK stays current with RN releases without requiring deep native expertise. MIT license explicitly permits this use.
  • Cons: Dependency on a small community project. If CodePushNext becomes unmaintained, we fall back to self-maintenance — but with a more current codebase as the starting point. Release lag between a CodePushNext release and our own publish must be managed.

Consequences

Positive

  • SDK can realistically track RN releases without a dedicated native specialist.
  • Customers receive a branded @appcircle/react-native-code-push SDK with guaranteed server compatibility.
  • Maintenance workload is bounded to sync + verify + publish per CodePushNext release.
  • Existing server-side architecture is unaffected — SDK changes are limited to what URL it points to.

Negative / Tradeoffs

  • Dependency on a small community project (3-5 maintainers, early-stage).
  • Release lag: CodePushNext release → Appcircle verification → publish.
  • If CodePushNext introduces a breaking change in its server API assumptions, we absorb the cost.
  • Our RN version support ceiling is bound by CodePushNext's pace. For example, CodePushNext currently supports up to RN 0.82; when a new RN version ships, we must wait for CodePushNext to add support before we can follow. This is an accepted tradeoff — the alternative (Option A) is strictly worse.

Follow-ups

  1. Customization mechanism: Define the exact fork strategy (minimal diff, configuration overlay, or wrapper). Determines how much of the sync process can be automated. → Separate work item.
  2. Sync process: Define the trigger (CodePushNext release), verification steps, and publish workflow. → Separate work item.
  3. Repository cleanup: Decide the fate of ac-codepush-mobile (archive vs keep as reference). → Separate work item.
  4. CodePushNext relationship: Evaluate sponsorship or contributor engagement with the CodePushNext project.
  • CodePushNext: https://github.com/CodePushNext/react-native-code-push
  • Upstream (archived): https://github.com/microsoft/react-native-code-push
  • Production SDK: ac-code-push-react-native-sdk (@appcircle/react-native-code-push)
  • Upstream reference / demo apps: ac-codepush-mobile