This is my architecture proposal extending an existing build-and-upload pipeline. Review, monitoring, and rollout orchestration remain unimplemented and unverified end to end. The models below are design deliverables, not production results.

Connect short executions through a Release Task

Technical flow; implementation and validation boundaries are explained below.

A GitHub-hosted job currently has a six-hour execution limit. It should not sleep through a multi-day review. Each proposed workflow performs one action, persists its result, and exits. GitHub Actions limits.

The record carries the release ID, application, source SHA, configuration revision, platform build IDs, runtime, store version or track, raw states, observation times, artifact-bound approvals, executions, and pause reasons. Persistent state must outlive short-lived artifacts; artifact retention must support recovery.

Reconcile uncertain outcomes before retrying

A timeout does not prove an upload or submission failed. Query the identified application and build before deciding to repeat an operation.

State updates also require version checks or locking. A stale scheduled run must not overwrite a newer pause decision. Workflow concurrency reduces conflicts but does not replace idempotency and conditional writes.

Update the earlier Google state model

edits.tracks alone does not represent every review stage. The current applications.tracks.releases resource additionally exposes releaseLifecycleState, including in-review, approved-but-unpublished, rejected, and published states. Google release lifecycle API.

The revised design combines lifecycle observations with track and rollout information. Its published state can include partial and resumable halted releases, so it does not alone prove full rollout. Access and behavior for the actual account still require MVP validation.

For Apple, an approved version awaiting developer release is distinct from one ready for distribution. Pending Developer Release still requires the release action. Apple application states.

An internal status model can simplify presentation while retaining the original platform state, build identity, and observation time. Unknown states require inspection, not an inferred success.

Separate reading status from controlling publication

Fastlane's App Store tooling supports formal submission parameters, subject to the application's metadata, review information, credentials, and integration validation. Fastlane App Store submission.

Google's lifecycle resource currently lists a read operation. The Managed publishing, supply, and publishing API documentation checked for this design does not establish a standard equivalent of the Console's final “Publish changes” action. The proposal therefore retains two explicit choices:

Observing approval does not implement publication. changesNotSentForReview is not a replacement for the final release action. Google publishing controls, edit commit, Fastlane supply.

The orchestration coordinates a launch window, not simultaneous propagation across stores and devices. First publication also has different eligibility from an update.

Treat a one-percent rollout as real exposure

An earlier option proposed releasing Android to one percent while waiting for iOS. That requires the backend, runtime, OTA bundle, and feature configuration to support those users already. It is not an unpublished state.

Apple's phased updates primarily govern eligible automatic updates; users can still download manually. Android uses its own eligibility and rollout mechanism. Matching percentages does not create matching cohorts or identical exposure. Apple phased updates, Google track rollout.

Pausing does not remove installed builds. Full availability also does not mean every user has upgraded. Runtime changes still need compatible services and bundles for older clients, or an independently designed forced-update and support-retirement policy.

Bind approval to artifacts and actions

Make readiness a checkable condition

This pure function is a preflight policy for manual publication after review. Both platforms must be approved but unpublished, QA and publication approvals must bind the same artifacts, and observations must be fresh. It deliberately refuses to treat Google's PUBLISHED state as permission to publish again or evidence of full rollout.

targetKey identifies an immutable persisted target. A real implementation must bind it uniquely to the app, source SHA, both build IDs, runtime, configuration revision, track and intended action. Query adapters must verify the actual version identities returned by the platforms rather than stamp the current task's key onto arbitrary results. Fifteen minutes is an example policy, not an API guarantee.

// Proposed policy model. No network, store mutation, lock or persistence.
export function evaluateReadiness(task, nowMs) {
  const reasons = [];
  const expected = task.targetKey;
  if (!expected) reasons.push('missing-target');
  if (task.paused !== false) reasons.push('paused-or-unknown');
  for (const kind of ['qa', 'publication']) {
    const approval = task.approvals?.[kind];
    if (approval?.decision !== 'approved' || approval.targetKey !== expected) {
      reasons.push(kind + '-approval-mismatch');
    }
  }

  const requiredStates = {
    ios: 'PENDING_DEVELOPER_RELEASE',
    android: 'RELEASE_LIFECYCLE_STATE_APPROVED_NOT_PUBLISHED',
  };
  for (const platform of ['ios', 'android']) {
    const observation = task.observations?.[platform];
    if (observation?.targetKey !== expected) {
      reasons.push(platform + '-target-mismatch');
    }
    const age = nowMs - observation?.observedAtMs;
    if (observation?.querySucceeded !== true || !Number.isFinite(age)
        || age < 0 || age > 15 * 60_000) {
      reasons.push(platform + '-observation-unusable');
    }
    if (observation?.state !== requiredStates[platform]) {
      reasons.push(platform + '-not-waiting-for-publication');
    }
  }
  return {
    stage: reasons.length ? 'blocked' : 'ready_for_execution_checks',
    reasons,
  };
}

The function above is a self-contained policy model. It evaluates local inputs and performs no store operations. ready_for_execution_checks only permits further execution checks. This function does not authorize an operator, acquire locks or call a store API. Execution still needs revision-conditional writes, renewed pause and approval checks, and reconciliation of uncertain outcomes. Google Managed publishing retains its authorized human action.

Nine local model tests passed during preparation, covering coordinate comparison and release-readiness counterexamples. These checks do not establish store integration or a completed release. The table above lists representative release cases that can be reproduced with synthetic task inputs.

The proposal separates QA confirmation from the production release decision. Approvals bind the source SHA, both builds, and intended action. A subsequent PR change cannot inherit an old build's approval, and an older completed release cannot approve a new PR head.

Runtime-changing releases and compatible patches can share executors with different completion policies. A version label does not itself prove compatibility between old binaries, JS, and backend behavior.

GitHub Environments can provide protected credentials and approval controls, but capabilities depend on repository visibility and plan. Private repositories must not assume required reviewers are available. An alternative approval system must still validate authority, bind artifacts, and record decisions. GitHub Environment availability.

Define evidence for the MVP

Slack notifications carry release identity, observed platform states, failure reasons, and next-action links. A click is not evidence that a store mutation succeeded.

The MVP should exercise asymmetric approvals, submission timeouts, duplicate actions, polling interruptions, pause races, expired artifacts, changed PR heads, and the manual Android publication path.

Only after those exercises should the proposal become an implementation case study with identified applications, builds, and results. Its present contribution is API research, state modeling, recovery, and permission design, without claims of completed automation or measured labor reduction.

ivan provides part-time remote support for mobile delivery workflows, including audits, orchestration design, and staged implementation through written, asynchronous collaboration.

Work with me

This article organizes my existing application-onboarding and store-submission notes into a reusable delivery method, checked against current official guidance. Those records do not establish a consolidated launch count, approval rate, or complete review-outcome history, so none is claimed.

Establish ownership and access before building

Determine whether the app belongs to an individual or organization and who completes verification, agreements, and payment. Organization enrollment involves legal-entity and authorization requirements, including applicable D-U-N-S information. Apple enrollment requirements.

Use member invitations and permissions appropriate to the task. Store administration, CI identities, and signing materials are separate concerns. Creating an app, uploading, submitting, and releasing can require different access. Secrets belong in controlled credential storage; handoff documents describe their purpose and location.

Historical templates also need correction. Google Play currently charges a US$25 one-time registration fee. Applicable new personal accounts must complete a closed test with at least 12 continuously opted-in testers for 14 days before applying for production access; meeting that condition still requires the access review. Registration, testing requirements.

Align application identity across services

Technical flow; implementation and validation boundaries are explained below.

My Android onboarding records connect package identity and certificate fingerprints to service configuration and a notification check after installation from Google Play.

The upload key and Play App Signing key are different roles. Services restricted by certificate fingerprint must recognize the certificate used for the distributed application. Push, maps, and sign-in need independent checks; one notification does not validate all integrations. Android app signing.

Tie store materials to the submitted build

An identity manifest and artifact inspection

I organize application identity and signing references into a reviewable handoff. The generic JSON below is a design example, not a store API payload or an existing platform schema. It contains references rather than private keys, reviewer passwords or service credentials. Capabilities must match the actual app.

{
  "app": "example-mobile",
  "environment": "production",
  "ios": {
    "bundleId": "com.example.mobile",
    "distribution": "app-store",
    "teamIdReference": "signing/ios/team",
    "capabilities": ["push-notifications", "associated-domains"]
  },
  "android": {
    "applicationId": "com.example.mobile",
    "track": "internal",
    "uploadCertificateReference": "signing/android/upload-certificate",
    "appSigningCertificateReference": "signing/android/play-app-signing-certificate"
  },
  "servicesToVerifyFromStore": ["maps", "login", "push"]
}

Next, inspect the binary instead of relying only on configuration. These read-only IPA checks require macOS developer tools and an exported Example.ipa. They were not run against an app during this writing task.

# macOS; an IPA already exported for inspection. No upload or signing occurs.
# Use a fresh temporary directory to avoid mixing builds.
inspection_dir="$(mktemp -d)"
unzip -q ./Example.ipa -d "$inspection_dir"
find "$inspection_dir/Payload" -maxdepth 1 -name '*.app' -print
# Replace Example.app below with the actual application bundle name.
plutil -extract CFBundleIdentifier raw "$inspection_dir/Payload/Example.app/Info.plist"
plutil -extract CFBundleVersion raw "$inspection_dir/Payload/Example.app/Info.plist"
codesign -d --entitlements :- "$inspection_dir/Payload/Example.app"

Compare CFBundleIdentifier, CFBundleVersion, and the signed entitlements' application identifier, Team, push environment and associated domains, then check that the store selects this build. On Android, confirm the app-signing certificate in Play's App integrity page and compare package names and fingerprints registered with maps or login services. Play App Signing can use a different key from the upload key, a useful starting point for a local-build success followed by a store-build failure. Android app signing.

The handoff includes the app name, icon, localization, description, classification or keywords, screenshots, support URL, privacy policy, review contact, and access notes. Screenshot requirements should be checked in the current Console, and images should represent actual submitted functionality.

iOS submission selects a specific build and requires completed metadata. Google Play setup covers applicable access, advertising, rating, audience, and Data safety declarations. Apple submission guidance.

Reuse a form's structure, not another application's answers. Statements about advertising, audience, and collected data must reflect the actual product and SDKs.

Make the core experience accessible to reviewers

My operational notes cover review accounts, access instructions, and handling test data afterward. A reusable review-access package includes a dedicated account, stable access, clear English instructions, suitable demonstration data, and accurate explanations of limitations.

Credentials belong in the designated store fields, not public documents. Arrange testing that avoids real charges or irreversible business actions. Reviewers should not depend on a developer being online to relay an OTP or reveal an unexplained hidden switch.

A demonstration video can provide context but does not replace functionality in the submitted build. Payment testing also depends on the purchase type: third-party payment integration is not evidence of StoreKit subscription experience.

Derive privacy declarations from actual behavior

Map features and SDKs to data types, purposes, recipients, and deletion behavior before completing disclosures. Both stores require consideration of third-party data practices. Apple privacy details, Google Data safety.

The policy URL, deletion entry point, and implemented behavior must agree. An ordinary privacy-policy page does not establish an account-deletion capability.

Separate first launch from an update

Initial publication includes account and application setup that an established app has already completed. Google explicitly states that Managed publishing cannot be used for an application's first publication, so an update-control plan cannot automatically promise the same launch timing. Google publishing controls.

Track actual milestones: buildable, uploaded, testable, submitted, rejected, approved, published, and available in the intended region. Each needs different evidence.

For a rejection, I would map each finding to code, configuration, metadata, or reviewer access, document corrections, and identify the resubmitted version. Engineering support can deliver diagnosis, changes, and a clear response; the store makes the review decision. Responding to Apple review messages.

Leave a repeatable handoff

Delivery includes ownership, the application identity map, store materials, build identifiers, installation checks, review correspondence, and instructions for the next update. Together with a build-and-upload pipeline, the initial setup becomes reusable operational knowledge.

This article uses three historical onboarding and submission documents plus current official guidance. No store publication or verification of historical review accounts was performed during writing.

ivan provides part-time remote support for iOS / Android onboarding, launch preparation, and release troubleshooting through written, asynchronous collaboration.

Work with me

I introduced Maestro into an existing React Native application and connected the app repository, shared GitHub Actions workflows, and a separate E2E repository. The work covered Android and iOS execution, version selection, change-based suite selection, case conventions, and artifact retention.

This article explains those decisions using generic names and examples. It is an implementation case study, not a complete CI template.

Give every run an explicit identity

For an RN application that can update its JavaScript bundle, “the current branch” is not a complete test identity. I separated four inputs:

The workflow definition has its own version as well. Changing its ref does not necessarily change the downloaded binary. Selecting a test branch does not mean the app contains the selectors added on that branch.

I recorded these values as explicit inputs or resolved outputs. When an existing binary was used as a fallback, each platform's artifact availability and actual source needed recording. Native code or dependency changes required a matching new binary; switching bundles could not replace that build.

The artifact also had to match the device. An iOS Simulator needs a simulator-compatible app, rather than a device IPA. Android checks included the application ID, build environment, and emulator ABI. Performing these checks before business tests made failures easier to classify.

Separate infrastructure from test policy

Technical flow; implementation and validation boundaries are explained below.

I avoided maintaining duplicate business-suite lists in the app repository and shared workflows, using the ownership boundaries shown above.

The E2E repository owned suite definitions, path mappings, ordering, and platform runners. Shared workflows handled invocation and environment preparation. Maintainers could find the test rules together when adding a case.

One important detail: local discovery of a YAML file does not prove CI executes it. An earlier CI implementation listed suites explicitly. Adding a case therefore required checking discovery, registration, and the actual remote execution plan.

Treat unavailable change information differently from an empty list

We mapped business paths to suites in E2E configuration and generated a plan from the changed files. Common preparation ran first; selected business suites followed their configured order.

“No relevant changes” and “change information unavailable” are different states. Converting an API failure to [] could silently reduce test scope while producing an apparently normal run.

We also handled empty cross-repository refs explicitly. A caller can pass an empty string, so an input default alone is insufficient. Normalizing it before checkout prevents the E2E code from drifting to an unintended default branch.

Make business state observable

Each case had a small contract: known preconditions, one primary business behavior, cleanup limited to its own records, and a known final screen on success. Failures preserved the scene for diagnosis.

Suites owned shared preparation. Cases did not depend on business results left by earlier cases. Cleanup used exact IDs from the current case, rather than deleting unrelated records from a shared account.

We preferred stable testID selectors and checked them against the actual UI hierarchy. A selector in source code does not prove the installed app or loaded bundle contains it. Additional test-state nodes also needed an explicit test-environment boundary.

After a tap, the flow should wait for an observable result. This simplified navigation fragment uses illustrative selectors; the timeout needs adjustment for the real application:

- tapOn:
    id: "example-open-detail"
- extendedWaitUntil:
    visible:
      id: "example-detail-ready"
    timeout: 10000

This verifies screen readiness. A test intended to create an order or complete a payment must assert that business outcome as well. extendedWaitUntil proceeds when its condition is met; the timeout is an upper bound. Maestro wait command

Optional dialogs need state-aware handling. A dialog that may not appear should not become a mandatory assertion. Dismissing a dialog also does not prove the flow succeeded. If several asynchronous branches can appear, the bounded waiting logic must recognize those states and still finish with the intended business assertion.

Retries should be narrow. Observation and navigation can support bounded retries, but operations that create, charge, or delete should not simply be wrapped in a retry of the entire flow. Test retries do not provide business idempotency. Maestro retry documentation

Preserve evidence from passing runs too

Separate test status from evidence delivery

This job fragment distills the implementation principle. The illustrative runner must export diagnostics to runner-output/ and leave them there before returning. An outer always() cannot recover files the runner has already deleted. The script name is an integration contract, not a runner shipped in this repository.

# Fragment inside an existing job after device / App preparation.
- name: Execute tests and preserve the result
  id: e2e
  shell: bash
  run: |
    mkdir -p evidence
    set +e
    bash scripts/run-selected-suites.sh > evidence/console.log 2>&1
    test_exit=$?
    set -e
    printf '%s\n' "$test_exit" > evidence/test-exit-code.txt
    copy_exit=0
    cp -R runner-output/. evidence/ || copy_exit=$?
    printf '%s\n' "$copy_exit" > evidence/evidence-copy-exit-code.txt
    if [ "$test_exit" -ne 0 ]; then
      exit "$test_exit"
    fi
    exit "$copy_exit"

- name: Upload evidence on success or failure
  if: ${{ always() }}
  uses: actions/upload-artifact@v7
  with:
    name: e2e-${{ runner.os }}-${{ github.run_id }}-${{ github.run_attempt }}
    path: evidence/
    if-no-files-found: error

A failed test keeps its original exit code. If tests pass but copying evidence fails, delivery also fails, with both statuses recorded. Uploading in a separate step avoids losing that operation when the shell exits. An advisory wrapper must still report the recorded test outcome. Inputs follow upload-artifact.

The earlier implementation uploaded diagnostic directories only on failure and cleaned up successful output. When we wanted engineers to inspect successful runs, changing the upload condition alone was insufficient.

Two changes were necessary: runners copied successful output before cleanup, and workflow upload steps included both outcomes. Otherwise, the upload step could run after its input files had disappeared.

The diagram preserves the critical order: save results and evidence before cleaning temporary output.

Workflow status conditions allowed collection after success or failure. They could not guarantee complete evidence when a runner never started or was forcibly terminated. We still checked upload outcomes and artifact contents. GitHub status conditions, workflow artifacts

The retained evidence included target versions, the execution plan, result files, JUnit, console and debug logs, recordings, and relevant failure screenshots or UI hierarchy. This gave teammates enough context to review a run without attending it.

Keep advisory execution separate from test truth

The rollout used E2E as an advisory regression signal rather than a required merge gate. That was a delivery-policy decision; it did not change whether the test passed.

I kept the runner's real result, the workflow's continuation policy, and the summary or notification distinct. Allowing the workflow to continue should not turn a failed business assertion into a reported pass. A skipped test is not completed validation either.

A green top-level workflow therefore still required inspection: was the run eligible, did both platform jobs execute, did the selected suites run, and did the final assertions pass?

Validate the app's caller chain

Running the E2E repository directly proves that entry point. To demonstrate integration into app delivery, we also had to exercise the app's caller and inspect version resolution, suite selection, and both platform jobs.

The recorded validation covered distinct scenarios:

• The full configured suite sequence passed on Android and iOS.
• An app-triggered integration run selected the expected scope from changed files and executed it on both platforms.
• Runs with business failures still uploaded diagnostic evidence.
• A passing preparation-only run produced downloadable results, reports, logs, and recordings on both platforms.

These scenarios answered different questions. They demonstrated the corresponding execution and artifact paths, not complete business coverage or a permanently flake-free test system.

Make the next case maintainable by the team

To help product engineers extend coverage, I documented the information needed for a new case: objective, preconditions, steps, optional branches, success assertions, and cleanup. Engineers could describe the behavior in writing, with tools helping inspect components, locate selectors, and draft YAML.

Tools reduce implementation effort; the business owner still needs to confirm that an assertion represents real success. Delivery should include the runnable case, suite registration, execution results, and enough documentation to investigate failures.

This work moved E2E from a script on one engineer's machine into a regression capability the team could invoke, inspect, and maintain. Further work could then focus on useful assertions, better failure attribution, and keeping the tested binary and code versions aligned.

ivan works on React Native, Expo, and iOS migrations, troubleshooting, and delivery workflows. Available for part-time remote technical support through written, asynchronous communication.

Work with me

The investigation connected touch coordinates, post-scroll measurement, and Pressability state transitions. The delivered page-level workaround wrapped the affected ScrollView in a View, supported by a record of the Native-to-JS investigation.

The code change was small. Explaining where the interaction lost its eligibility as a press was the harder part.

Distinguish a received touch from a completed press

Technical flow; implementation and validation boundaries are explained below.

I compared native callbacks, JS responder callbacks, and the final business callback. In the recorded failing interaction, the device emitted touchesMoved, reaching the region check in onResponderMove. The normal comparison taps recorded only the beginning and end callbacks.

This does not establish a hardware defect or behavior shared by every iPhone X. It identifies the branch that needs investigation.

The diagram shows the failure path for the already activated touch.

This diagram omits other paths such as delays, long presses, and cancellation. Receiving onPressIn establishes that the touch entered the response chain; it does not guarantee eligibility at release.

Connect the transition to coordinate evidence

Turn the coordinate mismatch into a checkable predicate

Synthetic numbers below reproduce a visible hit that fails the region test. These are not device logs. The model isolates coordinate space and omits hitSlop, pressRetentionOffset, delays and long-press branches.

function insideRegion(touch, region) {
  return touch.pageX > region.left && touch.pageX < region.right
    && touch.pageY > region.top && touch.pageY < region.bottom;
}

const touch = { pageX: 80, pageY: 120 };
const measured = { left: 20, right: 180, top: 820, bottom: 864 };
const visible = { left: 20, right: 180, top: 100, bottom: 144 };

console.log(insideRegion(touch, measured)); // false
console.log(insideRegion(touch, visible));  // true

Only the region's vertical position changes; the touch stays identical. In an investigation, capture touch.pageY, measured pageY/height, scroll offset and state transitions within the same gesture. Do not combine observations from different layout moments. A useful counterexample is a deliberate drag outside the visible region: it must still return false, preserving normal cancellation.

Pressability checks the touch against a responder region during movement and sends LEAVE_PRESS_RECT when it falls outside. Release handling also depends on the previous state and other conditions. I examined measurement, movement, and release together. RN 0.77.3 Pressability source reference.

The investigation compared touch and measurement values between architectures. In the failing case, the measured pageY used to build the region did not reflect the ScrollView's scroll offset. The touch was still near the button's visible position, so the two could not be compared correctly.

This explanatory model is not a device log or a general coordinate-conversion formula:

Button position within scrolling content: Y_content
Scroll offset: offset
Visible position: Y_visible ≈ Y_content - offset (parent offsets omitted)

The touch is near Y_visible
The incorrect measurement remains near Y_content
  → A visually valid tap is classified as leaving the press region

The measurement callback constructs the region from page coordinates and size. The region check then uses the touch's pageX / pageY. Logging only a local coordinate such as locationY, or only the missing business callback, would not explain that mismatch.

The evidence identifies inconsistent measurement and the resulting state transition. It does not identify the exact Fabric layout or measurement function responsible for omitting the offset. Those are different levels of diagnosis.

Apply a local page workaround

The adaptation record resolves the affected page by adding a container outside the ScrollView. This rewritten example uses generic names:

import type { PropsWithChildren } from 'react';
import { ScrollView, View } from 'react-native';

export function FormScreen({ children }: PropsWithChildren) {
  return (
    <View style={{ flex: 1 }}>
      <ScrollView style={{ flex: 1 }}>{children}</ScrollView>
    </View>
  );
}

This was the documented page-level workaround. It was not a framework fix with a proven lower-level cause that could be applied universally.

Increasing hitSlop changes the allowed region without correcting its coordinate source. Ignoring all movement events would alter the intended cancellation when a user drags off a button. Neither is an equivalent replacement for understanding the observed failure.

Resolving the page issue and fully explaining the underlying framework mechanism can have different completion scopes. The useful deliverable preserves the failure evidence and makes the intervention's scope explicit.

Make verification distinguish success from a lucky tap

The historical notes contain the device and OS, callback differences, coordinate comparisons, state transitions, and workaround. They do not contain a complete post-fix device matrix or execution count. This writing session did not rerun the scenario, so no pass rate or all-device success claim is made.

A follow-up verification should cover:

Evidence should include both touch state and the business result. For a submit button, verify the intended post-submit state; an animation or onPressIn alone does not complete the user task.

What the investigation demonstrates

The work narrowed a seemingly unresponsive button through native callbacks, RN event handling, Pressability state, and business callbacks. Coordinate evidence explained the failure path and supported a local intervention.

For remote support, that investigation is also a maintainable handoff: another engineer receives observation points, decision criteria, and a verification path without needing to rediscover the entire native event system.

ivan provides part-time remote React Native / iOS support, focusing on native interactions, difficult debugging cases, and delivery through written, asynchronous collaboration.

Work with me

I helped implement and maintain a shared GitHub Actions and Fastlane pipeline covering builds, artifact transfer, and uploads. Here, submission means uploading to TestFlight or a configured Google Play track. Formal review submission, review monitoring, and rollout control are a separate release orchestration design, not a completed end-to-end implementation.

Separate three configuration dimensions

A production-connected iOS build can be distributed through TestFlight before public release. A simulator app is not a device artifact for store upload.

The shared entry point validates the platform and profile combination before choosing the execution lane. Callers provide an explicit delivery target while platform implementations remain independently maintainable.

Keep application policy separate from shared execution

Technical flow; implementation and validation boundaries are explained below.

My work included organizing application onboarding around stable metadata, signing configuration, and limited application hooks. Shared execution handles preparation, native builds, and artifact transfer; hooks own application-specific version and runtime rules.

Frequently changing build numbers do not belong in stable application metadata. Resolved iOS build numbers, Android version codes, and runtime identifiers travel through build metadata to the upload stage.

The upload identity must describe the artifact actually being uploaded. Recomputing a next build number during recovery can make the reported version differ from the binary.

Make the build-to-upload handoff explicit

Express the handoff through a fixed artifact identity

This iOS fragment omits dependency setup, signing, compilation and the upload lane. It keeps the existing build/post split and additionally illustrates artifact-ID binding and checksums; those additions are examples, not a claim about deployed behavior. Android can apply the same contract in its own build job.

# Handoff fragment for an iOS build. Project setup/build steps are omitted.
jobs:
  build:
    runs-on: macos-latest
    outputs:
      artifact_id: ${{ steps.archive.outputs.artifact-id }}
    steps:
      # Existing build steps must produce both files below.
      - name: Verify and fingerprint delivery
        run: |
          test -s delivery/app.ipa
          test -s delivery/build-info.json
          cd delivery
          shasum -a 256 app.ipa build-info.json > SHA256SUMS
      - uses: actions/upload-artifact@v7
        id: archive
        with:
          name: ios-${{ github.run_id }}-${{ github.run_attempt }}
          path: delivery/
          if-no-files-found: error
          retention-days: 14

  post:
    needs: build
    runs-on: macos-latest
    steps:
      - uses: actions/download-artifact@v8
        with:
          artifact-ids: ${{ needs.build.outputs.artifact_id }}
          path: delivery/
      - name: Verify before upload
        run: |
          cd delivery
          shasum -a 256 -c SHA256SUMS
      # Restore pinned tooling/configuration, then run the existing upload lane.
      # Read version/build identity from build-info.json; do not allocate it again.

The build producing the binary must also produce build-info.json, recording the actual source SHA, Bundle ID, build number, runtime and configuration revision. The artifact ID fixes the handoff object for this run. Checksums check file consistency, not signing identity, review status or trusted provenance. Cross-run recovery also requires the run ID, artifact ID, authorization context and a check for prior store receipt.

The example's 14-day retention illustrates a configurable recovery window; the inspected implementation uses one day. Longer review cycles still need separate archival. Inputs and outputs are defined by upload-artifact and download-artifact.

The existing pipeline separates build and post jobs. The first preserves native output and diagnostic material; the second restores its environment, downloads artifacts from that run, and executes upload and distribution steps.

This supports recovering the upload stage, provided artifacts remain available, metadata matches, and the destination has not already accepted the build. Two jobs alone do not establish unconditional retry safety.

A useful handoff records the application, source commit, configuration revision, platform, build identifiers, artifact location, destination track, and failure stage. It does not include secret values.

After an upload timeout, I would inspect the destination before retrying. A compiler failure requires correcting the source or toolchain and rebuilding. Those failures need different recovery actions.

Preserve platform-specific behavior

On iOS, the Team, Bundle ID, signing material, and entitlements must agree. The implemented upload lane loads build metadata, checks the IPA, and uploads to TestFlight.

An accepted upload, completed build processing, tester availability, and App Review approval are distinct. A lane configured not to wait for processing can finish before testers can install. Formal review requires selecting a build and completing the submission information. Apple submission documentation.

On Android, the lane resolves the package and track and checks for an AAB or APK. It distinguishes a draft-app path from ordinary uploads. A completed internal-track release is not a public production launch. First-time application setup also extends beyond what an upload tool does. Fastlane Google Play upload documentation.

Deliver diagnostic material with the binary

The pipeline includes artifact paths and upload logic for debugging material. Whether sourcemaps, symbols, or obfuscation mappings are enabled and successfully delivered must be checked for each application and run.

These files must match the build they describe. A green workflow does not prove every optional upload executed, and a mapping from another build cannot establish reliable source attribution.

The inspected build artifacts have a one-day retention period. That supports short-term transfer but does not cover a multi-day review lifecycle. Durable release storage belongs to the next phase of the design.

Scope a remote delivery engagement

I start by identifying the repository, platform, environment, signing setup, destination, and failing stage. The deliverables are a repeatable entry point, configuration instructions, the identified artifact and actual upload status, any device verification performed, and stage-specific recovery notes.

This article was checked against the application caller, shared workflows, actions, and upload lanes. No new hosted build or store upload was triggered for the article. Source inspection does not prove every application or branch has passed, and no unmeasured speed or labor savings are claimed.

ivan provides part-time remote support for React Native / iOS / Android builds, signing, and upload workflows through written, asynchronous collaboration.

Work with me

I encountered this in an application that still needed the Legacy Architecture. An upstream fix covered the New Architecture. I adapted its approach to Paper's native input implementation, shared an RN 0.77.3 patch publicly, and later maintained the fix during an RN 0.81.5 upgrade.

This case study distinguishes the upstream contribution, my adaptation, and the available validation.

Identify the unnecessary update

Technical flow; implementation and validation boundaries are explained below.

Issue #44157 describes cursor drift in controlled inputs with autocorrection and predictive text involved. PR #46970 explicitly addresses the New Architecture. Original issue, upstream fix.

The upstream investigation identified a timing problem: UITextField can update text and selection in separate stages during autocorrection. Replacing its complete attributedText in between can preserve an intermediate caret position.

The useful question was why a controlled-value round trip rewrote the input when the returned content was already effectively equivalent.

Compare effective attributes in Paper

Plain character equality ignores meaningful styling. Strict NSAttributedString equality can also reject equivalent input because UIKit's default typing attributes differ from RN-generated attributes.

Following the upstream approach, I added effective attribute comparison to Paper's RCTBaseTextInputView.mm. The implementation checks string content, compares attributes across character ranges, uses captured initial typingAttributes as a baseline for missing values, and normalizes natural paragraph alignment and writing direction.

Actual content, range, or effective style differences still have an update path. The work required adapting the principle to Paper's objects and lifecycle; Fabric's input component and attribute types could not simply be copied into a different file.

Handle two distinct update boundaries

Single-line inputs

This is the core guard from the RN 0.81.5 adaptation, with surrounding object preparation omitted. Variables belong to the RCTBaseTextInputView update path; textOf:equals: already uses the effective comparison described above. It is an excerpt, not a standalone patch.

UITextRange *selection = self.backedTextInputView.selectedTextRange;
BOOL isSinglelineTextField =
    [self.backedTextInputView isKindOfClass:[UITextField class]];
BOOL stringsMatch =
    [attributedTextCopy.string isEqualToString:backedTextInputViewTextCopy.string];

if (eventLag == 0 &&
    isSinglelineTextField &&
    self.backedTextInputView.isFirstResponder &&
    (selection == nil || selection.empty) &&
    stringsMatch) {
  textNeedsUpdate = NO;
} else {
  textNeedsUpdate =
      ([self textOf:attributedTextCopy
            equals:backedTextInputViewTextCopy] == NO);
}

The review point is the final assignment decision: textNeedsUpdate = NO avoids the subsequent whole-attributedText reset. Other cases still pass through the comparator. It neither forces the caret to the end nor disables autocorrection. The public patch and upstream attribution are linked later in this article.

The legacy patch skips an identical-text rewrite only when all of these conditions hold:

This does not directly detect autocorrection. It protects an identical-text update that may occur while the caret is temporarily stale. Actual text changes retain the normal update path.

The guard is broader than effective attribute comparison: a style-only update during active editing may also skip that complete rewrite. Same-text style updates, selection changes, and composition therefore belong in regression testing. The patch should not be described as having no effect on every input scenario.

Multiline inputs

The patch also introduces a programmatic-update boundary between RCTUITextView and its delegate adapter. Relevant editing callbacks are suppressed during JS-driven writes, and string and selection snapshots are synchronized afterward.

This handles feedback from programmatic writes. It is a separate path from single-line autocorrection and needs separate review and validation.

Maintain the patch across versions

The public patch targets Expo 52 / RN 0.77.3. During the RN 0.81.5 migration, I inspected the legacy implementation again, identified the safeguards still needed, adapted the relevant changes, and regenerated the dependency patch.

Delivery included the native implementation, patch file, and corresponding lockfile identity. Keeping them aligned lets another developer or CI reproduce the modified dependency after installation.

The original patch and my report are available in the upstream discussion. The upstream authors implemented the Fabric fix; my contribution is the Paper adaptation and its subsequent maintenance. My legacy patch and report.

Report the observed result accurately

In that public report, I stated that we had not received further user reports after adopting the patch. The observation did not include a defined period, input count, or control group, so it does not establish a measured fix rate or permanent elimination.

Historical validation of the RN 0.81.5 adaptation included applying the patch against a clean dependency, installation with a frozen lockfile in offline mode, and an iOS Simulator build of the React-RCTText target.

Those checks establish patch reproducibility and native compilation. That validation record did not include real-device fast typing or predictive-keyboard regression. No device tests were rerun while writing this article.

For a similar engagement, I would test rapid typing, autocorrection, the double-space period shortcut, English and Chinese input methods, selection replacement, programmatic clearing, and dynamic styles across single-line and multiline inputs, recording both RN version and architecture.

What the work delivers

An application that cannot immediately switch architectures still needs usable input. This work connects upstream native analysis to a version-specific implementation, reproducible dependency changes, and an explicit validation scope that another maintainer can continue.

ivan provides part-time remote React Native / iOS support, focusing on native debugging, upgrades, and patch maintenance through written, asynchronous collaboration.

Work with me

I encountered these different layers while leading an Expo SDK 54 migration. The work covered React Native 0.81.5, React 19.1, native project changes, build tooling, and regression checks. This article focuses on the decisions that helped turn a version update into a migration with reviewable evidence.

The examples are simplified and use generic names. They explain this migration; they are not a universal upgrade script.

Establish the migration boundary first

Technical flow; implementation and validation boundaries are explained below.

The application already had native directories, custom initialization, third-party SDKs, and dependency patches. We retained the Legacy Architecture and Hermes for this migration, leaving the architecture transition as a separate task. SDK 54 still supports the Legacy Architecture, but it is the final SDK release to do so. That decision therefore carries future migration work. Expo SDK 54 release notes

Before editing, I established a baseline across five layers:

Declared configuration and actual build inputs can differ. Updating package versions while retaining an outdated native initialization path does not complete a migration.

Compare templates against the application you actually maintain

I compared the matching Expo template, the RN upgrade diff, and the application's implementation. A bare React Native diff needs interpretation when the project also uses Expo and maintains native code.

For example, we aligned Android's RN initialization with the corresponding loadReactNative entry point while preserving the ordering of application SDK initialization. Gradle, AGP, Kotlin, KSP, and NDK also needed review as a compatible toolchain, rather than as unrelated candidates for individual upgrades. Expo SDK 54 native template

Existing system-bar and inset handling required similar care. Keeping custom Activity behavior does not remove the need to handle platform edge-to-edge requirements. A framework configuration flag, application layout ownership, and OS-enforced behavior are separate concerns. We needed to document who owned the layout behavior and which screens and OS versions were checked.

I classified differences as confirmed compatibility gaps, intentional application choices, or risks needing further validation. That made both changes and deliberate omissions reviewable.

React 19: a type fix cannot restore runtime defaults

Compare the layer that changes before and after the fix

This example follows the clustering-dependency scenario and retains only parameter binding. Values and names are illustrative; Props, noop and rendering are omitted. The two same-named functions are a before/after comparison, not one executable module.

// Before: function-component defaults depended on React.
function ClusterLayer(props: Props) {
  const radius = props.radius;
  // ...the dependency's clustering and rendering logic...
}
ClusterLayer.defaultProps = { radius: 50, onClusterPress: noop };

// After: defaults are applied by JavaScript parameter binding.
function ClusterLayer({
  radius = 50,
  onClusterPress = noop,
  ...rest
}: Props) {
  // ...the same clustering and rendering logic...
}

// Call-site cases that must keep their meaning:
// omitted / undefined -> default
// radius={0}          -> 0, not 50
// explicit callback   -> caller's callback, not noop

The change supplies values when the function executes; changing an optional type to a required type would not do that. radius || 50 loses a valid zero, while radius ?? 50 also treats explicit null as missing, unlike parameter defaults. Check the dependency's accepted inputs and regress the actual exported component.

One issue involved function-component defaultProps. React 19 no longer applies this mechanism to function components; class components retain support. React 19 upgrade guide

A map-clustering dependency in our application used it for default configuration and callbacks. Omitting a prop could therefore leave a downstream operation with a value the library did not expect.

This generic button illustrates moving defaults into the function parameters. It is explanatory code, not copied application code:

import { Button } from 'react-native';

type RetryButtonProps = {
  label?: string;
  onRetry?: () => void;
};

const noop = () => {};

function RetryButton({
  label = 'Retry',
  onRetry = noop,
}: RetryButtonProps) {
  return <Button title={label} onPress={onRetry} />;
}

Each migrated default still needs a semantic review, including callbacks, numeric calculations, and layout options. Parameter defaults apply only when the input is undefined; explicit values must retain priority. A truthiness-based fallback can incorrectly replace valid values such as false or 0.

Our application also injected some application-wide component defaults during initialization, including font-scaling behavior. After the upgrade, omitted props could fall back to RN's own behavior, changing layouts at large system font sizes.

Changing a TypeScript declaration could not repair that behavior. We handled affected components according to their rendering paths: parameter defaults for functions we controlled, narrow patches for confirmed dependency issues, and render-time handling where dynamic application defaults were required. Explicit caller props retained priority. This compatibility work has maintenance costs and should not be treated as a default architecture for other applications.

A text search was only the start of the audit. A dependency containing defaultProps was not automatically a production defect: it might use a class, merge defaults itself, or receive explicit values from every relevant caller. We checked the actual call sites before deciding what to patch.

The regression checks also needed to exercise the modified runtime implementation. A test wrapper that supplies missing defaults only proves that the wrapper works.

Preserve existing API behavior while migrating

Existing file operations used string URIs, directory constants, and read, write, upload, and download APIs. SDK 54 provides the newer object API while retaining an official legacy entry point. Expo FileSystem legacy documentation

We used that entry point to preserve the established calling model:

import * as FileSystem from 'expo-file-system/legacy';

This separated the SDK upgrade from a future migration to File and Directory. It did not remove the need to inspect supported options, return values, and error handling. Separating the changes made potential regressions easier to attribute.

Localization calls moved to getLocales() and getCalendars(). The following shows the reading pattern only:

import { getCalendars, getLocales } from 'expo-localization';

const regionCode = getLocales()[0]?.regionCode;
const timeZone = getCalendars()[0]?.timeZone;

Application logic still needs to handle missing values without overwriting an existing user selection. A one-time read also does not solve every lifecycle-related refresh requirement; that depends on the consuming screen. Expo Localization documentation

We removed broad compatibility declarations that hid real API mismatches. Remaining type adaptations represented confirmed equivalent behavior. Declarations cannot create an API that no longer exists at runtime.

Review dependency patches and OTA compatibility separately

Existing patches often encode earlier production fixes. For each patch, I checked whether the newer dependency had already addressed the issue, whether the affected path remained reachable, whether lifecycle assumptions had changed, and which platform was affected.

Only the behavior still needed was carried forward. This preserved necessary fixes without importing obsolete implementation details wholesale.

A concrete example was the iOS controlled TextInput cursor issue. The upstream fix covered the New Architecture; I adapted its approach to Paper, including effective attribute comparison and input-update safeguards, then maintained the existing RN 0.77.3 patch for RN 0.81.5. The legacy TextInput case study explains the implementation, public patch, and validation scope.

A separate New Architecture adaptation involved taps failing after scrolling on an iPhone X running iOS 16.7.10. I traced native events into JS, identified inconsistent responder and touch coordinates, and applied a wrapper on the affected page. That case has its own version context and was not a newly introduced Expo 54 issue. See the iOS scrolling and touch investigation.

Native changes also affect OTA compatibility. Producing a JavaScript bundle does not prove that an older installed binary can run it. That binary must contain the native capabilities the bundle expects. Native dependency changes therefore require a review of runtime versions and update targeting. Expo runtime versions

We treated a successful run on a newly built app and compatibility with an older app as separate questions. Delivery notes needed to identify the binary, compatibility boundary, and bundle used for validation.

Report validation by what it actually proves

The recorded checks for this migration included lockfile-constrained installation, type checking, relevant lint checks, 113 Jest suites with 509 tests, Android Kotlin compilation, and an Android JavaScript export. The project documentation also records self-tests for sending and saving images and uploading video after the file API adaptation.

Each result has a specific scope:

The 113 suites and 509 tests describe the existing regression run, not newly added tests or complete business coverage. Release parameters, optimized artifacts, distribution, and device regression remain separate validation responsibilities.

Leave a migration another engineer can maintain

I organized the migration notes around symptoms, causes, changes, validation, and remaining boundaries. Type changes, runtime behavior, native compilation, and release risks had distinct evidence instead of sharing one broad “upgrade passed” label.

That record becomes useful again during the next upgrade. Another engineer can see why a template difference was retained, which patch still serves a purpose, and which checks should be repeated.

ivan works on React Native, Expo, and iOS migrations, troubleshooting, and delivery workflows. Available for part-time remote technical support through written, asynchronous communication.

Work with me