- Why React Native instead of native iOS and Android?
- One codebase, one team, one set of behaviours. For a small team shipping a regulated mobile surface, running two parallel native codebases is rarely worth the residual native gains. We use native modules where the platform genuinely requires it (biometrics, keystores, deep payments). Otherwise: one engineering investment, two app stores.
- Can Hotreloads ship audit trails that match server-side records?
- Yes. Every client-side action emits a typed event into a local IndexedDB-style queue. Queued events flush to the server on reconnect, with deduplication on a per-event idempotency key. Reconciled lines match server-side records 1:1, which is the bar for a regulator review of a payments or KYC surface.
- How does Hotreloads handle offline-safe state?
- Optimistic UI for the surfaces that can tolerate it. Strict server-confirmation for the surfaces that cannot (anything financial). Local state survives crashes and force-quits. We use the same queue pattern on web and React Native so the audit trail is a single design, not a per-platform one.
- What about App Store and Play Store review delays?
- We scope release cycles to expect 5-7 business days of store review per major version, with hotfix paths through OTA updates (CodePush, Expo Updates) for non-native changes. The release calendar is part of the engagement timeline, not a surprise at week eight.
- What does a 120-day React Native engagement actually deliver?
- The 120 days split into three phases. Weeks 1 to 3 are UX audit and information architecture, ending with a clickable prototype on a real device. Weeks 4 to 14 are the build, with weekly device demos on both iOS and Android so feedback loops stay tight. Weeks 15 to 17 are hardening, store submission, and handoff. You leave with one TypeScript codebase, a working EAS build pipeline your team operates without us, and audit telemetry that survives a financial review.
- How does Hotreloads keep iOS and Android parity when product requests pull them apart?
- Parity is a build constraint, not a review checklist. Every screen ships against a shared component library and a single TypeScript interface. When a product request requires platform-specific behavior, we implement it as a named platform shim in the shared codebase, not a fork. We run Detox end-to-end tests on both platforms on every commit, so a divergence surfaces in CI before it reaches a device demo. If a native module creates a genuine gap, we document it in the handoff spec and close it before the release candidate.
- Does Hotreloads handle App Store and Play Store submission, including review pushback?
- We own the full submission pipeline from first TestFlight build through App Store Connect binary review and Google Play Console release tracks. Rejections happen, especially for FinTech apps under guideline 3.2.1 or data privacy rules. When a rejection arrives we read the review note the same day, identify whether the fix is a metadata change, a privacy manifest update, or a code change, and resubmit. The submission pipeline uses Fastlane for certificate and provisioning management, so your team can rerun it without us after handoff.
- Can Hotreloads take over a React Native app another team half-built?
- Yes. We start with a two-week audit: codebase read, dependency scan, Flipper trace on both platforms, and a written summary of what works, what is broken, and what is a liability. Metro bundler config, native module registration, and CI pipeline are the usual problem areas. From there we give you a fixed scope for stabilization before any new feature work starts. We do not begin building on a foundation we have not read. The audit cost offsets against the engagement if you proceed.
