Mobile Apps Development
Native and cross-platform apps — iOS, Android and React Native — built for real field use: offline-tolerant, camera and scanner friendly, fast to ship.
A working demo, not a mockup — swipe a card or tap the buttons. Same pattern (gesture-driven, stateful, offline-friendly) we build in React Native for a real app. Open full-screen ↗
How we build your app
We work in five stages with one senior team. Each stage ends with something you can see, test and keep.
Frontend: native, cross-platform or HTML5
There's no single right way to build a mobile app. We choose the approach from your users, the device features you need and how long the app has to last. We don't pick it from habit.
The approaches we build with
Native iOS
Swift · SwiftUI · Combine
Premium consumer apps, and anything that relies on HealthKit, ARKit, CarPlay, widgets or Apple Watch.
You'll need a separate Android codebase and team.
Native Android
Kotlin · Jetpack Compose · Coroutines
Rugged Zebra and Honeywell scanners, kiosk mode, and deep Android or hardware integrations.
You'll need a separate iOS codebase and team.
React Native
TypeScript · Expo · New Architecture
One team shipping to both stores with 85–95% shared code. It can also share logic with a React web app.
Some edge-case hardware needs a small native module.
Flutter
Dart · Impeller · Riverpod
Brand-heavy, pixel-identical UI and rich animation across iOS and Android.
Dart is a separate skill set, and less code is shared with the web.
HTML5 / PWA / Capacitor
React · Angular · SAPUI5 · Ionic
Internal tools, Fiori apps in SAP Mobile Start, and apps nobody should have to install. It's the fastest and cheapest route.
iOS limits background work, Bluetooth and some device APIs.
How it happens
- 1
Discovery and platform decision
We interview users, list the devices and OS versions in the field, and map every hardware feature the app needs. The output is a written decision record that says why we chose native, cross-platform or web.
- 2
UX and a clickable prototype
We build Figma flows that follow Apple's Human Interface Guidelines and Material 3. Real users test them before any code is written. Accessibility (Dynamic Type, VoiceOver, TalkBack) and English/French copy are designed in from the start.
- 3
Design system and app shell
Navigation, theming, dark mode, localisation, error states and analytics hooks come first. That way every later feature plugs into a consistent frame.
- 4
Feature sprints
We work in two-week sprints. Every sprint produces a TestFlight and Play Console internal build, so stakeholders tap through real software, not status reports.
- 5
Offline data and device features
We add a local database (SQLite, WatermelonDB or Realm), background sync, camera, barcode and NFC scanning, GPS, biometrics, push notifications and deep links.
- 6
Performance hardening
Our targets are cold start under 2 seconds, smooth 60/120 fps scrolling, a small bundle and a crash-free session rate above 99.5%. Each one is measured on low-end devices, not just flagships.
What you get from this stage
Backend: we work with the systems you already run
The app is only as good as the data behind it. We connect to the systems you already run, whether that's SAP, Salesforce or your own APIs, or we build a new backend when you need one.
Systems we connect to
SAP S/4HANA & ECC
OData · CAP on BTP · SAP Mobile Services · Event Mesh
Field service, inventory, approvals, maintenance orders and goods receipts, all posted straight into SAP.
It needs clean-core discipline, and we build with it from day one.
Salesforce
REST / GraphQL APIs · Mobile SDK · Platform Events
Sales reps, service agents and partner portals that need CRM data offline and in real time.
API limits need careful caching and batching.
Microsoft & other ERPs
Dynamics 365 · Dataverse · Graph · NetSuite · Oracle
Organisations standardised on Microsoft 365 or another ERP.
Auth and data models differ by vendor, and we abstract that away.
Custom Node.js backend
Node.js · NestJS / Express · PostgreSQL · Redis
New products, or apps that combine several systems into one clean API.
You own and run it, and we set up the ops so that's easy.
Backend-as-a-Service
Firebase · Supabase · AWS Amplify
MVPs and pilots that need auth, a database and push notifications in days.
Complex business rules eventually outgrow it, so we plan the exit early.
How it happens
- 1
Map the systems of record
We work out which system owns each piece of data (orders, customers, stock, assets) and who is allowed to change it. That tells us where the app reads from and writes to.
- 2
Contract-first API design
We define an OpenAPI or GraphQL schema and stand up a mock server in week one. The mobile team starts building immediately instead of waiting on the backend.
- 3
Backend-for-frontend (BFF) layer
A thin Node.js layer sits between the app and your ERP or CRM. It trims payloads for mobile networks, merges calls to several systems and hides SAP or Salesforce complexity from the app.
- 4
Sync and conflict resolution
We use delta sync, idempotency keys and an outbound queue, so a form submitted offline is posted exactly once. Conflicts are resolved by rules the business agrees on, not by whichever write arrived last.
- 5
Events and push notifications
SAP Event Mesh, Salesforce Platform Events or webhooks trigger APNs and FCM notifications, so users hear about new work orders or approvals in seconds.
- 6
Observability
Structured logs, traces and dashboards follow every request from phone to ERP and back, so support can answer "where did my order go?" in minutes.
What you get from this stage
Hosting and distribution
There are two sides to this: where the backend runs, and how the app reaches your users' phones. We automate both, so releasing becomes routine.
Where it can run
AWS / Azure / Google Cloud
ECS / AKS / Cloud Run · RDS · S3 · CloudFront
Most custom backends. Canadian regions (AWS Montréal, Azure Toronto) keep data in Canada.
It needs infrastructure-as-code discipline, and we provide that.
SAP BTP
Cloud Foundry · Kyma · SAP Mobile Services
Apps that extend SAP, with SAP identity, connectivity and app lifecycle built in.
BTP credits and entitlements need planning up front.
Heroku / Salesforce
Heroku · Hyperforce · Salesforce Functions
Salesforce-centric apps that should live next to the CRM.
It costs more per unit of compute at scale.
Your data centre
Docker · Kubernetes · on-prem VMs
Regulated or air-gapped environments where data can't leave your network.
Your team runs the hardware, and we hand over runbooks.
App distribution
App Store · Google Play · Intune / Workspace ONE · Apple Business Manager
Public store releases, private enterprise apps pushed through MDM, or install-free PWAs.
Store review adds 1–3 days per release, so we plan around it.
How it happens
- 1
Infrastructure as code
Terraform or Bicep defines every environment. Dev, staging and production are identical and reproducible, and changes go through code review.
- 2
CI/CD for the app
GitHub Actions with Fastlane or Expo EAS builds, signs and versions every commit. Certificates and provisioning profiles are managed centrally, not on someone's laptop.
- 3
Over-the-air updates
JavaScript and asset fixes go out through EAS Update in minutes, without waiting on store review. Native changes still ship as full releases.
- 4
Store submission
We handle listings, screenshots, privacy nutrition labels, the data safety form and review back-and-forth. For internal apps we set up MDM deployment instead.
- 5
Staged rollout
Releases go to 1%, then 10%, then 50%, then everyone, with automatic halts if the crash rate or error budget is breached.
- 6
Monitoring and scaling
Sentry or Crashlytics catch crashes and APM tracks performance. Autoscaling, backups and cost alerts are set up before launch day.
What you get from this stage
Security by design, mapped to OWASP MASVS
Phones get lost, networks get intercepted and apps get decompiled. We design for all three, and we map our controls to the OWASP Mobile Application Security Verification Standard (MASVS).
Security controls in every build
Identity and SSO
OAuth 2.0 + PKCE · OIDC · Entra ID · Okta · SAP IAS
Employees sign in with their existing work account. Face ID and fingerprint unlock the session.
The app never stores passwords.
Data at rest
iOS Keychain · Android Keystore · SQLCipher
Tokens live in hardware-backed storage, and the offline database is encrypted.
A lost phone doesn't leak data.
Data in transit
TLS 1.2+ · certificate pinning · signed requests
Stops man-in-the-middle attacks on hotel or airport Wi-Fi.
Pin rotation is automated so certificate changes don't break the app.
App hardening
App Attest · Play Integrity · obfuscation · root/jailbreak checks
Blocks tampered apps, emulators and scripted abuse from reaching your API.
The checks are tuned so real users aren't locked out.
Compliance
PIPEDA · PHIPA · SOC 2 · HIPAA-ready
Canadian privacy law, health data and enterprise security questionnaires.
The evidence is collected as we build, not scrambled for at audit time.
How it happens
- 1
Threat model
In the first sprint we map what an attacker would want, how they'd get it and what it would cost you. That drives which MASVS level (L1 or L2) we target.
- 2
Identity and least privilege
Short-lived tokens, refresh-token rotation and roles that match your SAP, Salesforce or Entra ID roles. Users only see the data their job requires.
- 3
Secure storage and transport
Keychain and Keystore for secrets, an encrypted local database, pinned TLS, and no sensitive data in logs, screenshots or the clipboard.
- 4
Secure SDLC
Dependency scanning, secret scanning, SAST and MobSF static analysis run on every pull request. A vulnerable library blocks the merge.
- 5
Penetration test
Before launch, an independent mobile and API penetration test is run against the production build. Findings are fixed and retested.
- 6
Remote kill switch and wipe
A forced-upgrade flag, remote session revocation and MDM selective wipe mean a compromised version or device can be shut off in minutes.
What you get from this stage
Testing on real devices, automated in CI
Mobile bugs hide in the gap between the simulator and a three-year-old Android phone on a weak connection. We automate the test pyramid and run it on real devices.
The test layers
Unit and component
Jest · React Native Testing Library · XCTest · JUnit
Business rules, sync logic and UI components, checked in seconds on every commit.
It's the fastest feedback, but it can't catch device issues on its own.
API contract
Pact · OpenAPI schema tests · Postman / Newman
Catches the backend or ERP changing shape before the app breaks in production.
Both teams have to keep the contract up to date.
End-to-end UI
Maestro · Detox · XCUITest · Espresso · Playwright (PWA)
Real user journeys: log in, scan, go offline, submit, sync, done.
These are slower, so we keep them focused on the critical paths.
Real-device farm
BrowserStack · Firebase Test Lab · AWS Device Farm
Dozens of real phones, tablets and OS versions, including your field hardware.
It has a cost, so it runs nightly and before releases.
Non-functional
Performance profiling · VoiceOver / TalkBack · MobSF · network throttling
Speed, accessibility (WCAG 2.2 AA), security and behaviour on 3G or no signal.
Most teams skip this layer. We don't.
How it happens
- 1
Test strategy in sprint 0
We agree on the critical journeys, the target device matrix and quality gates such as coverage, crash-free rate and performance budgets, before feature work starts.
- 2
Tests written with the feature
Every story ships with its unit and component tests, reviewed in the same pull request. "Done" means tested.
- 3
Automated E2E on every build
Maestro or Detox flows run in CI on emulators for every pull request, and on the real-device farm nightly.
- 4
Offline and bad-network drills
We script airplane mode, flaky 3G and mid-sync app kills to prove that no data is lost or duplicated.
- 5
Beta programme
TestFlight and Play testing tracks put the app in real users' hands, with in-app feedback and screenshot capture.
- 6
Release gates
A release only moves forward if tests are green, the crash-free rate holds and the performance budget is met, and we keep watching during staged rollout.
What you get from this stage
Find your stack in 60 seconds
Answer seven questions about your users, devices and data. The fit meter re-ranks native, cross-platform and HTML5 as you go, then you get a full frontend, backend, hosting, security and testing recommendation.
Question 1
Who will use the app?
Live fit meter
- React Native–
- Flutter–
- Native iOS–
- Native Android–
- HTML5 / PWA–
Answer each question and watch the options re-rank.
Apps built for where the work actually happens
Field crews, warehouse floors and delivery routes don't have great signal. We build mobile apps that keep working when the network doesn't.
What we deliver
- React Native / TypeScript apps sharing one codebase across iOS and Android, dropping to native modules where it matters
- Offline-first sync with conflict resolution, so a scan or a form submitted underground still lands correctly later
- Camera, barcode and NFC scanning wired directly into your backend workflows
- Push notifications, deep links and background sync configured once, not bolted on
- App Store / Play Store release pipeline — signing, versioning and CI builds handled end to end
Recent patterns
- Barcode-scanning apps for warehouse bin-to-bin transfers and goods receipt
- Field-service apps with photo capture, GPS check-in and offline work orders
- Companion apps for existing web products, sharing the same backend and auth
Tell us about the process that hurts.
A 30-minute call is enough to tell whether an agent, an extension or a plain good Fiori app is the answer. No deck, no discovery fee.