What I deliver
- iOS and Android applications built on a shared codebase
- Tablet interfaces designed for the space available, not simply stretched
- Installable web apps, when going through the stores is not warranted
- The API and back office feeding the app, written by the same person as the app
- Taking over an existing app and repairing its release pipeline
- Release on the App Store and Play Store, and version management
One codebase, two platforms
For the vast majority of business applications, writing the same thing twice in Swift and Kotlin costs double and gives the user nothing. I work in React Native, which shares the logic and most of the interface between iOS and Android, and lets you drop into native code where it genuinely matters.
Fully native still has its place: games, heavy graphics, intensive sensor use, extreme performance requirements. If your need falls there, I will say so rather than forcing an approach that will not hold.
Tablets are not large phones
This is the most common blind spot. An app that works on an iPhone often looks absurd on an iPad: text columns stretched across the full width, buttons stranded in the middle of an empty screen, navigation designed for one thumb on a device held with two hands.
- Adaptive layouts, with a master-detail view where the width allows
- Rotation genuinely handled, including preserving in-progress state
- Touch targets placed where hands actually are on a tablet
- Multitasking and split view on iPadOS
- Screen densities and notches accounted for across the Android estate
What happens at release
The part people discover too late: store review. A rejection costs several days, and the reasons are often administrative rather than technical.
- Developer accounts, certificates and provisioning profiles set up properly
- Store listings, screenshots and privacy policy meeting the requirements
- Data collection declarations, mandatory on both stores
- Staged rollout and test builds before general release
- Updates shipped without breaking existing installations
Apps delivered
Among the eleven documented projects, two rest on intensive mobile use: the delivery platform, whose courier app is used on the move and on an unreliable network, and the dating platform, whose entire journey is designed for the phone.
See the eleven documented projects
Frequently asked questions
Do I need an app, or is a mobile site enough?
An app is warranted if you need notifications, offline operation, access to device sensors or a presence on the stores. Otherwise a properly built mobile site costs less, updates without review, and asks nobody to install anything.
iOS and Android at the same time?
Yes, that is the point of a shared codebase. You can still publish on one platform first to validate usage, then open the second with no rewrite.
Who publishes the app on the stores?
The developer accounts must be in your name; you remain the owner of the app. I handle the configuration, the listings and the release, and hand everything over at the end.