Skip to main content

Release and Patch Lifecycle

In TkushPatch, Over-The-Air code distribution clearly distinguishes between the lifecycle of store-published base binaries (Releases) and dynamic Over-The-Air updates (Patches).

Deployment Lifecycle Overview​

The delivery model connects two complementary tracks:

  • Store Release Track: Build Creation ➔ Internal Testing ➔ Store Submission (with automatic Store Review Shield) ➔ Live on Store ➔ Planned Deprecation.
  • OTA Patch Track: Patch Submission ➔ Review & Digital Signature ➔ Staging Verification ➔ Production Promotion ➔ Staged Rollout with Geo-Targeting. In case of an unexpected issue, the Instant Rollback (Kill-Switch) returns devices immediately to the healthy release.

1. Release Lifecycle (ReleaseStatus)​

A Release is the compiled binary package (.apk, .aab, .ipa) distributed via application stores. It progresses through four key statuses:

StatusDescriptionPlatform Behavior
INTERNAL_TESTINGVersion undergoing internal QA review on test distribution platforms.Patches targeted at internal or pre-production channels are delivered to registered test devices.
IN_STORE_REVIEWVersion submitted for review to Apple App Store or Google Play.Store Review Shield Active: Dynamic updates on public channels are temporarily paused so store reviewers inspect the original binary without divergence.
LIVE_ON_STOREVersion approved and publicly available on app stores.Validated production patches are eligible for progressive rollout across the active device fleet.
DEPRECATEDOlder version retired after its support grace period.No new patches can be attached to this release.

2. Patch Lifecycle (PatchStatus)​

A Patch is an incremental update targeted at a specific release version.

Step 1: Submission (STAGED)​

The developer or CI/CD pipeline compiles the patch using the tk-ota-push patch command:

  • The system computes the binary difference between the base release and the new version.
  • The diff file is compressed to minimize network transfer (typically a few hundred kilobytes).
  • The patch receives an incremental patch number and an initial STAGED status. It is not yet available to end users.
# Example patch submission via CLI
tk-ota-push patch \
  --app-id=com.company.mobile \
  --release-version=1.4.0+42 \
  --channel=staging

Step 2: Approval and Signing (APPROVED_AND_SIGNED)​

To meet enterprise and banking compliance standards, TkushPatch enforces Maker-Checker governance:

Separation of Duties Rule: The author who created the patch cannot approve it for production. Approval must be completed by a separate authorized user (Administrator or Release Manager).

Upon approval:

  1. A cryptographic integrity digest is calculated to seal patch contents.
  2. The patch is signed with a production digital signature verifying origin and authenticity.
  3. The status transitions to APPROVED_AND_SIGNED.

Step 3: Staging Verification​

Before public rollout, the patch is validated on a staging channel. To maintain strict test boundaries, TkushPatch supports a QA Device Whitelist: only designated test devices receive updates on internal tracks.

Step 4: Promotion to Production​

Once certified by QA:

  1. An authorized operator promotes the patch to the production track (stable) via the Web Console or CLI.
  2. The patch becomes immediately available for rollout according to configured distribution policies.

3. Staged Rollout and Geo-Targeting​

To minimize blast radius and monitor user metrics safely, patch distribution is strictly controlled.

Staged Rollout (Canary)​

Distribution percentage can be increased gradually (e.g., 5% ➔ 20% ➔ 50% ➔ 100%):

  • Device assignment uses a deterministic algorithm based on each device's unique identifier.
  • Rollout Stability: Any device included in an earlier cohort (e.g., 5%) remains eligible as rollout expands to higher percentages. No device experiences accidental downgrades.

Country Filtering​

TkushPatch can restrict patch distribution to specific countries (ISO 3166-1 alpha-2 codes, e.g., ["FR", "CI", "SN", "CM"]). If a device's resolved location is outside targeted countries, the update is masked.

4. Emergency Rollback (Kill-Switch)​

If a critical issue occurs in production (app crash, major regression), TkushPatch provides instantaneous remediation.

Rollback Process:​

  1. Triggering Rollback: An operator clicks Rollback in the Web Console or runs tk-ota-push rollback. The rollout percentage immediately drops to 0% and status changes to ROLLED_BACK.
  2. Device Enforcement: During its next check, each mobile client detects the revocation, purges the patch from local storage, and seamlessly resumes running the original base release.
  3. Fleet Monitoring: Support and engineering teams can review device fleet status in the Web Console, track rollback acknowledgments, and clear the incident once resolved.