Services / Mobile
Apoliums builds iOS and Android apps, cross-platform or fully native, that behave correctly when the phone loses signal in a basement.
Most business apps do not need to be written twice. They need offline writes that survive a dead connection, notifications that open the right screen on a cold start, credentials in the Keychain rather than plain storage, and a release pipeline that makes submission routine. That is the work we do.
What we build
Screens are the easy part. These are the areas where mobile apps actually fail, so they are scoped and tested explicitly.
One TypeScript codebase compiled to both stores, on the New Architecture. Platform differences are handled where they matter instead of averaged into an interface that looks wrong on both.
The network is treated as unavailable by default. Writes are queued locally, replayed when the connection returns, and conflicts resolve by a rule agreed during scoping rather than by whichever request lands last.
A notification that opens the exact screen it refers to, on a cold start, on both platforms, including the permission flow that asks at a moment the user understands.
Camera, biometrics, Bluetooth, background location, secure storage. We write the native module when the ecosystem has no maintained package, and say so before the estimate is signed.
Signing, provisioning, screenshots, review notes and staged rollout are part of the build. A release is a pipeline run, not an afternoon of manual uploads.
Apps built by a previous team get an audit first: crash rate, dependency health, native module debt and OS-version support. The report ranks what to fix by user impact.
How we work
A simulator hides the two things that break mobile apps: a slow phone and a bad connection. The test set includes both.
Step 01 / 05
Screens, offline behaviour, device permissions and the store accounts each get settled up front. Store review rules shape the build, so they are read before the first sprint rather than after a rejection.
Written scope and store plan
Step 02 / 05
Flows are drawn once and specified twice where the platforms differ — navigation, back behaviour, share sheets, date pickers. Tap targets and contrast are checked at design time.
Platform-annotated designs
Step 03 / 05
The main path runs on real iOS and Android hardware in the first weeks, not only in a simulator. Low-end Android is part of the test set from the start.
Installable test build
Step 04 / 05
Offline queues, token refresh, background behaviour, crash reporting and deep links each get a dedicated pass, because these are what break outside the office wifi.
Crash reporting and offline tests
Step 05 / 05
We prepare listings, screenshots and review notes, submit under your developer accounts, and monitor the staged rollout for crashes before it reaches everyone.
Live on both stores
Technologies
Native code is written where a maintained package does not exist, and that decision is named in the estimate rather than discovered mid-build.
Stack manifest — 04 groups
27 components listed
01
Cross-platform or native, chosen at scoping with the reason written down.
08 components
02
One store per app. A second pattern for the same state is a bug waiting to happen.
08 components
03
Platform code wherever the app needs the hardware directly.
05 components
04
Signing and submission automated from the first internal build.
06 components
Questions
Apoliums quotes mobile app development per project after scoping. Cost is driven by the number of screens, whether the app works offline, how many device capabilities it uses — camera, Bluetooth, background location — and whether a backend has to be built alongside it or already exists.
The quote separates the app, the backend and the store release work, so you can see which part carries the cost and decide what waits for version two.
Apoliums recommends cross-platform, React Native or Flutter, when the app is business software — records, forms, lists, messaging, payments — because one codebase covers both stores and the team stays small. Fully native in Swift and Kotlin is the right answer for apps built around continuous device access: heavy graphics, real-time audio or video processing, or deep platform integration.
The choice is made at scoping, in writing, with the reason stated. A cross-platform app can still drop into Swift or Kotlin for one screen that needs it, which is usually cheaper than writing the whole app twice.
Apoliums sets the date after scoping and writes it into the signed scope, plus store review, which Apple and Google run on their own timetable. Internal test builds are installable on your devices early, so the app is in your hands long before submission.
Offline sync, payments and native modules that have to be written rather than installed are what move the date, and the estimate names each one.
Yes. Apoliums submits to the App Store and Play Store under your own developer accounts, so you hold the listings, the signing keys and the analytics. We prepare the listing copy, screenshots, privacy declarations and review notes, and handle the back-and-forth if a reviewer asks a question.
If you do not have developer accounts yet, we walk your team through creating them. We never register store accounts in our name for a client's app.
Yes, when offline behaviour is in scope. Apoliums builds mobile apps offline-first: reads come from a local database so the app opens to content, writes are queued and replayed when the connection returns, and the interface shows sync state rather than pretending everything saved.
Conflict rules are agreed during scoping — last write wins, server wins, or a manual review queue — because that decision belongs to the business, not to the network.
Apoliums maintains apps after launch on a monthly retainer covering iOS and Android version updates, dependency upgrades, crash triage from store data, and an agreed number of changes. Store policies and OS releases force work on a schedule you do not control, so maintenance is planned rather than reactive.
Teams who prefer to take it in-house get the repository, signing configuration, release pipeline and a handover session covering the release process end to end.
Next step
A warehouse, a delivery route, a clinic, a customer's sofa — the place decides the offline model, the permissions and half the interface. Send us that, and what the app has to do, and we will scope it.
