01
Greenfield consumer + B2B apps
Native iOS / Android, React Native, or Flutter: chosen against the actual workload, team, and operational profile. Not 'always React Native' or 'always native' on principle.
Custom Software · FORGE
Mobile Apps.
Native iOS and Android, React Native, and Flutter apps, engineered for App Store / Play Store review survival, offline-first resilience, push and notification operations, and the long-tail mobile reality (low-bandwidth, low-end Android, regulator review, app-store de-listing risk).
- Practice
- Custom Software
- Department
- FORGE
The problem
Most enterprise mobile programs underestimate everything that happens after the app is built.
The pattern across enterprise mobile engagements: a beautifully built app that fails App Store review three times because the privacy manifest doesn't match runtime behavior; a React Native app whose offline mode works on the engineer’s iPhone 15 and breaks on a Pixel 4a in Karachi; a push pipeline that depends on a single Firebase service account that nobody rotated; a regulated mobile app whose biometric flow doesn’t survive the legal review six weeks before launch. Mobile is the half that’s easy; ops, store review, and the long-tail device reality are the half that breaks.
Prosigns ships mobile apps with store-review hardening, offline-first patterns, push and notification operations, and observability calibrated to the device fleet you actually have, not the test devices on the engineer’s desk. Privacy manifests match runtime behavior. Push pipelines have rotation runbooks. Offline mode is tested on real low-end Android. The app survives the first regulator / store review and the first 90 days of crash-free-rate scrutiny.
Where it ships
5 use cases, in production.
Specific applications we’ve built and operated. Not speculative: every example below is grounded in a real shipped engagement.
- 02
Enterprise field apps
Inspector apps, field-service apps, sales-rep apps, healthcare-clinician apps: offline-first, sync-aware, identity-integrated with corporate IdP, MDM-ready.
- 03
Regulated mobile apps
Healthcare (HIPAA), banking (PCI-DSS), insurance: biometric auth, audit logging, secure storage, jailbreak/root detection where the regulatory frame requires it.
- 04
Web → mobile (or web + mobile)
Existing web apps extended with native or cross-platform mobile. Shared backend / API contracts, shared design language, distinct interaction patterns where mobile demands it.
- 05
Wear, TV, automotive
Apple Watch, Wear OS, Apple TV, Android TV, Android Auto, CarPlay extensions where the workload genuinely benefits from the form factor.
How we engage
4 phases, named in the SOW.
Each phase has a deliverable, an owner, and an acceptance criterion. Not slogans, operating rules.
- 01
Stack choice against the workload
Native (Swift / Kotlin) wins for performance-critical, hardware-deep, or platform-feature-heavy workloads. React Native and Flutter win for cross-platform reach with lower team count. We tell you which fits the workload and the team, not which the bench wants to learn next.
- 02
Store review + privacy hardening
Privacy manifests match runtime behavior. App Tracking Transparency and Google Play Data Safety match the actual data practices. Compliance review is week-1 scope, not pre-submission scramble.
- 03
Offline-first + sync
Offline-first data layer (Watermelon DB / Realm / Core Data / Room) with conflict resolution designed for the actual workload, last-write-wins is rarely the right answer. Sync tested on real low-end Android, not just simulators.
- 04
Push, notification, and ops
Push pipelines with rotation runbooks for service-account credentials. Notification opt-in flows that respect the OS-level conventions. Crash-free rate, ANR rate, and per-OS-version dashboards from day one, not after the first store-review crash spike.
Capabilities
What’s in scope.
- Native iOS (Swift, SwiftUI), native Android (Kotlin, Jetpack Compose)
- React Native (with TypeScript) and Flutter (with Dart)
- Offline-first data layers and sync (Watermelon, Realm, Core Data, Room)
- Push pipelines (APNs, FCM) with rotation and observability
- App Store / Play Store review hardening and resubmission support
- Privacy manifests, ATT, Data Safety, biometric auth, secure enclave
- MDM-ready builds (Intune, Workspace ONE, JAMF) for enterprise distribution
- Crash + ANR monitoring (Sentry, Firebase Crashlytics, Bugsnag)
Stack
Tools we use in production.
- Native
- Swift / SwiftUIKotlin / Jetpack ComposeCombineCoroutines
- Cross-platform
- React Native (TypeScript)Flutter (Dart)ExpoCapacitor
- Offline + sync
- Watermelon DBRealmCore DataRoomPowerSyncReplicache
- Push + comms
- APNsFirebase Cloud MessagingOneSignalIterableBraze
- Identity + secure storage
- Apple Sign-InGoogle Sign-InOIDC librariesKeychainAndroid Keystore
- Crash + ops
- SentryFirebase CrashlyticsBugsnagDatadog MobileApp Center
Selected work
Quantified outcomes, not adjectives.
Common questions
Asked before the first call.
- 01
Native, React Native, or Flutter?
Depends on the workload. Native wins for performance-critical apps, hardware-deep workloads (camera, AR, audio processing), platform-feature-heavy apps, or when the team has native specialists. React Native wins for shared logic with web, faster cross-platform iteration, and JS-heavy teams. Flutter wins for design-heavy apps where pixel-perfect cross-platform UI matters and team is willing to invest in Dart. We’ll tell you which fits. Sometimes the answer is native iOS + React Native Android, or vice versa.
- 02
How do you handle App Store / Play Store review?
Privacy manifests, App Tracking Transparency, and Data Safety reviewed against runtime behavior pre-submission. Common rejection categories (data minimization, in-app-purchase scope, kids-category compliance, sign-in-with-Apple parity) audited as part of release readiness. Resubmission support if the first attempt is rejected.
- 03
Do you handle MDM / enterprise distribution?
Yes: Intune, Workspace ONE, JAMF, and direct enterprise distribution via the Apple Enterprise Program or managed Google Play. Configuration profile design, MAM policies, and the operational runbook for credential rotation are scoped from day one.
- 04
What about offline mode?
Offline-first by default in field-service and clinician apps. Sync layer chosen for the workload: last-write-wins is rarely right; we model conflicts against the actual user workflow. Tested on real low-end Android (Pixel 4a / Samsung A-series) not just simulators or current iPhones.
- 05
How do you handle crash spikes after release?
Crash-free rate, ANR rate, and per-OS-version dashboards from day one. Sentry / Crashlytics / Bugsnag wired into release process: staged rollouts (1% → 10% → 50% → 100%) with crash-rate gates. If a release crosses the gate, automatic halt of the rollout while we investigate. Hotfix process pre-defined.
- 06
What does a mobile engagement cost?
Discovery + design + spike: 4–8 weeks, $50K–$150K. Single-platform native MVP: 3–5 months, $250K–$700K. Cross-platform (RN/Flutter): 4–6 months, $400K–$900K. Two-native (iOS + Android): 6–9 months, $700K–$1.6M. Enterprise field app with offline-first + MDM: $800K–$2M. Managed Services post-launch: $25K–$120K monthly retainer.
Within Custom Software
Other capabilities in this practice.
Talk to us
Bring a mobile apps problem. We’ll bring a senior engineer.
A senior engineer plus the FORGE department lead joins the first call. No discovery gauntlet, no junior reps.