Mobile app development
Android and iOS applications, from design through store submission.
We design, build and publish mobile applications for Android and iOS. Because we publish our own apps, we know the store review and release process from the inside rather than from documentation.
An app is not finished when it runs on your own phone. It has to pass review at Apple and Google, work on screen sizes and operating system versions you do not own, and keep working when the platform changes underneath it. Most of the surprises in a mobile project come from that second half, not from writing the screens.
What it solves
- Customers expect to do on a phone what they can already do on your website.
- The work happens away from a desk — on site, in a vehicle, in a store — where a phone is the only practical tool.
- You need to reach people with a notification rather than an email they will not open.
- The app exists but has not been updated, and now it fails review or crashes on current operating system versions.
- A process needs the phone’s camera, location or offline capability, which a website cannot reach in the same way.
What the work covers
- Screens and flows, designed around the task the person is trying to finish.
- Android and iOS builds from one codebase where that fits, or native where the app needs it.
- The store listing: description, screenshots, category, age rating and the privacy declarations.
- Submission, review and release — including the back and forth when a reviewer asks for changes.
- Updates after launch, and keeping the app compliant as store rules and OS versions move.
What store review actually checks
Both Apple and Google review apps before release, and a rejection is a normal part of the process rather than a sign that something is broken. In our experience the questions are far more often about metadata than about code: whether the privacy declaration matches what the app really collects, whether every requested permission is justified by a visible feature, whether the description promises something the app does not do, and whether account deletion is possible when accounts exist. Getting those right before submission is most of what shortens the wait.
How we work
- We agree what the app must do before we design screens.
- You get builds you can install and try during development.
- We handle store listing, review and release, and stay available for updates afterwards.
Our own product in this area
Veilig Besteden is our own mobile app for self-employed professionals in the Netherlands. It estimates income tax, BTW and toeslag risk from the income you enter, and it deliberately asks for no bank connection and no national identifiers. Read about Veilig Besteden.
Frequently asked questions
Native or cross-platform?
It depends on what the app has to do. An app built mostly of forms, lists and API calls is well served by one shared codebase; one that leans on the camera, sensors or heavy graphics is usually better native. We make the call per project and explain the trade-off rather than defaulting to one answer.
Whose developer account is the app published under?
It can be published under your own Apple and Google developer accounts, which means the listing, the reviews and the users stay yours even if you later work with someone else.
What happens after launch?
Operating systems and store rules change on their own schedule, so an app that is left alone eventually stops being accepted. Updates are part of owning an app, not an accident, and we can keep handling them.
Do we need an app at all, or is a website enough?
A mobile website is often the right answer, and it is cheaper to maintain. An app earns its place when you need notifications, offline use, or hardware the browser cannot reach in the same way. We will say so if a website would serve you better.