When a mobile app is built as two separate products, the cost doubles and the platforms start behaving differently. We build the iOS and Android sides from a single React Native codebase: a feature is written once and works in both stores. Our own venture, Otomiks, was built this way and is live in both stores.
What is mobile app development?
Mobile app development means designing, building, publishing and then keeping current the phone-based version of a service. What separates it from a website is not only screen size: an app reaches the device itself — it sends notifications, uses location, opens the camera, stores data offline — and it holds a permanent place on the user's home screen.
That permanence is also a responsibility. When you change a web page, everyone sees the new version; in a mobile app, a change goes through store review and then waits for the user to install the update. That is why architectural decisions on mobile projects are the most expensive ones to correct later.
We build applications with React Native: iOS and Android come from a single codebase and the business rules live in one place. Where a server side is needed we build that too, so the contract between the app and the backend stays inside one team and there is no grey area where each side waits on the other.
A mobile app is not necessary for every organisation. If people use your service a few times a year, a mobile website that works well is usually the better choice; nobody keeps an app on their phone to open it twice a year. An app earns its place where usage is repeated, where notifications are needed, or where device capabilities have to be reached. We make that assessment openly in the first conversation.
What we do
A mobile project is not just the app itself; the service behind it, the store process and post-launch maintenance are all part of the same job.
- iOS and Android development — One codebase, two platforms. The interface respects each platform's own conventions; navigation, the back button and keyboard behaviour feel native.
- Interface design — The screen flow is designed around the moment the app will actually be used. A screen designed for someone standing, using one hand and distracted is different from one designed for a desk.
- Server side and API — We build the API that feeds the app, or connect to your existing system. The same API can feed the web interface too, so mobile and web do not diverge in behaviour.
- Notifications — Push notification infrastructure is set up and which events produce a notification becomes manageable. Unnecessary notifications are among the leading reasons apps get deleted.
- Offline working — On the screens that need it, data is stored on the device, actions are queued and synchronised when the connection returns. Which screens work offline is decided up front.
- Store release and version management — Build, signing, store listings and the review process are handled. The same pipeline stays in place for later releases.
- Analytics and crash reporting — Which screens get used and where crashes happen are measured. A problem a user hits is discovered before it appears in a store review.
- Accessibility and language support — Font size settings, screen reader compatibility and a multilingual interface are planned from the start; these are among the hardest layers to add later.
The concrete example of this approach is our own venture, Otomiks: a single server core running live on three platforms — web, iOS and Android.
How we work
On mobile, the cost of going back is higher than on the web: a badly built flow can only be corrected once a new version passes store review and the user installs the update. That is why we move the validation steps to the front of the process.
- Scope and flow — We establish who the app is for, at what moment it is used and which problem it solves. What will not go into the first release is written down just as clearly; on a mobile project the most valuable decision is what not to build.
- Screen flow and design — The flow between screens comes first, then the visual design. Screens designed before the flow settles get redrawn during development.
- Development — The app and the API progress together. An installable build is produced at every stage; the team uses the product on its own phones before it reaches the store.
- Testing on real devices — Different screen sizes, low memory, weak connections and denied permissions are tested on real hardware. These conditions do not look right in an emulator.
- Store release — Developer accounts are opened in the organisation's name, store listings and privacy declarations are prepared, and the app is submitted for review. Review feedback is addressed.
- Post-launch maintenance — Crash reports are monitored, operating system releases are tracked and regular updates are made. An unmaintained app starts causing store problems within a year.
What you gain
- One build, two platforms — The same feature is not written twice; development and maintenance run on a single line.
- Consistency across platforms — What a user sees on iPhone behaves the same on Android; your support team does not have to learn two different products.
- Faster release cycle — A single codebase means fixes reach both stores at the same time.
- A direct channel — Notifications are one of the few channels that reach a user without an intermediary; used well, the response rate is high.
- Usable in the field — Offline screens mean the app also works in warehouses, on sites and in service vehicles where the connection is weak.
- Ownership — The store accounts and the source code belong to the organisation; the app's future is not tied to a single supplier.
An app is not judged by download numbers but by whether it is still being opened in the second week. That is why we prefer to ship a first release that does a few things well rather than many things half-way. Missing features can be added in later releases; a poor first impression is not easily undone.
Frequently Asked Questions
Why one codebase instead of two separate apps?
Writing the same app separately for iOS and Android doubles the development and maintenance load. More importantly, the two apps drift apart over time: a bug fixed on one platform stays on the other, a feature works only partly on one side. With a single codebase the business rules live in one place, which preserves both consistency and update speed. Where platform-specific behaviour is needed, that part is written separately — a single codebase does not stand in the way of it.
Do you publish the app to the stores?
We run the release process: the app is built, the store listings (description, screenshots, category, privacy declaration) are prepared, and it is submitted for review. Developer accounts are opened in the organisation's own name and the organisation owns them; ownership of the app is never tied to us at any stage. Addressing feedback during review is also part of the process.
Does the app work without an internet connection?
It can be designed to work partly offline. Data loaded earlier is stored on the device and can be viewed without a connection; actions the user takes are queued and sent when the connection returns. Which screens need to work offline is decided up front — making every screen work offline creates unnecessary complexity.
Can it connect to our existing systems or our website?
Yes. The app generally works over an API, and the same API can feed the web interface too. That keeps the business rules in one place and stops mobile and web behaving differently. If you already have a system we connect to it; if not, the server side is built as part of this project.
How are updates made after launch?
New versions are built and published after passing store review. Small content changes do not require a store update, to the extent they can be managed from the server side. Because operating system versions change every year, an app needs maintenance at least once a year; that is planned as part of the maintenance scope.
Where can we see your experience in this area?
Our own venture, Otomiks, was built with the same approach: a single server core, a web interface and iOS and Android applications built with React Native. The product is live on all three platforms, and the server, web and mobile sides were all built and are all operated by us. You can find the details on the Otomiks page in our projects section.