Service 02
An app on both stores, maintained past launch day
We design, build and publish iOS and Android apps. One codebase drives both platforms, which cuts the work without taking anything away from what the user sees. And because an app does not stop the day it ships, we take on what comes after: fixes, updates and OS version upgrades.
Our approach
Why we work this way.
We build in React Native with Expo: one codebase, two native apps at the end, and interfaces that respect each platform’s conventions rather than pasting the same screens everywhere. Cross-platform is not a dogma, though. Some uses — video processing, sensors, Bluetooth, system extensions and widgets — are written natively, and we say so during scoping rather than halfway through the build.
An app is not one more website. It gets installed, it takes up space, it asks to be updated, it passes a review board before every release, and it has to survive the next version of iOS and of Android. That is a long-term commitment, and it is the first thing we examine with you — sometimes to conclude that a well-built mobile site would do the same job.
What it covers
The detail, item by item.
iOS and Android from one codebase
A React Native and Expo foundation, screens that follow each platform’s habits, and native code where the use genuinely demands it.
- A single codebase for both platforms, tested on real devices
- Navigation, gestures and components following iOS and Android conventions
- Native modules where a feature requires them, decided and stated during scoping
- Accessibility: text sizes respected, labels read out by screen readers
- Light and dark modes following the phone’s own setting
Publishing to the App Store and Google Play
The part nobody enjoys and that blocks the most projects: the accounts, the listings, the declarations and the review.
- Apple and Google developer accounts opened in your company’s name
- Certificates, signing and app identifiers set up cleanly
- Store listings written: title, description, keywords, screenshots in the right formats
- Privacy declarations and age ratings filled in honestly
- Submission, review, and reworking the feedback if it is rejected
The everyday features
What most apps need, built once and built well: we start from how you will use it, not from a feature catalogue.
- Accounts and authentication, including Sign in with Apple and email
- Notifications, with fine-grained control over what the user agrees to receive
- Offline mode and syncing once the network returns
- In-app payment, according to the stores’ rules
- Deep links: a URL opens the right screen, including from an email
- Sharing, favourites, search and the other pieces a modern app is expected to have
The dedicated back end
An app on its own does not go far. We deliver the API and the data that keep it alive, with the means to administer them without us.
- A dedicated API, documented and versioned
- A database sized for your real usage
- An admin dashboard: content, accounts, notifications, exports
- A test environment separate from production
- Backups and a restore procedure that has been rehearsed, not merely written
After the launch
The first day on the stores is a beginning. Operating systems change once a year, store rules more often than that.
- Fixes and updates released as user feedback comes in
- Crash tracking, with the trace needed to reproduce the problem
- iOS and Android version upgrades, tested before your users have to live with them
- Adapting to changes in the stores’ rules
- Handover to another team made possible: readable code, a clean repository, documented setup
What you receive
Checkable, at the end of the engagement.
- An app published on the App Store and on Google Play, under your own developer accounts
- The complete source code, with its history, in your repository
- A dedicated API and database, with a test environment separate from production
- An admin dashboard to manage content, accounts and notifications without asking us
- The store listings written: descriptions, screenshots, privacy declarations
- A documented release procedure: how a new version goes to review and then live
Process
How we proceed
Scoping
What the app has to do in its first version, and above all what it will not do yet. A short first version ships, gets tried by real users and gets corrected; an exhaustive first version never comes out.
Flows and technical foundation
Screen by screen, the flow is drawn before it is coded. In parallel, the foundation is laid: navigation, accounts, API, environments. This is the moment we settle what stays cross-platform and what goes native.
Development through installable builds
You receive installable builds as we go, through TestFlight on Apple’s side and Google Play’s testing tracks on Android. Feedback arrives during development, while acting on it is still cheap.
Release and follow-up
Submission to both stores, review, addressing the comments, then release. After that, the follow-up: crashes, user feedback, fixes and version upgrades.
Frequently asked questions
The questions that come back, and our answers.
- Do you need an app, or a mobile site?
- Often a well-built mobile site is enough — it is findable in search engines, opens from a link, requires no installation and passes no review board. An app earns its place when the use is repeated, when you need notifications that actually arrive, offline operation, access to the phone’s hardware, or a spot on your customers’ home screen. We ask the question before selling the app, and “a site is enough” is a valid answer.
- How long before it is published?
- That depends entirely on the scope, and we do not give a duration before scoping it with you — a blind estimate commits nobody and always turns against the project. Once the scope is written, we announce a schedule and we hold to it. What remains is the stores’ review, which adds its own delay and which nobody controls, neither you nor us.
- Who owns the store accounts?
- You do. The Apple and Google developer accounts are opened in your company’s name, with your payment details and your access. We are invited in for the duration of the engagement, with the rights we need and nothing more. If we open the accounts for you, they are transferred to you — an app published under the supplier’s account is a problem that always surfaces at the worst possible moment.
- Can the app reuse our existing site or systems?
- Yes, and it is often the right choice. If you already have an API, a database or a back office, we plug into it rather than rebuild it. During scoping we check what the existing system can carry and what has to be added — typically authentication and notifications, which are almost always missing from a system designed for the web alone.
The other services
The same contact from end to end.
Tell us about your project
One email is enough.
Write to us in a few lines: your business, what you are trying to achieve, and the deadline that matters to you. We answer in English or in French, with a straight opinion — including when the honest answer is that another service, or none at all, would serve you better.