iPhone and Android apps. One codebase, your name on both.
We build native apps for iPhone and Android from a single React Native codebase, so you pay for one app, not two. It is the front door to your service: customers see their plan, book, pay and talk to your team, and your staff see it all live. Listed under your own store accounts.
One app, the whole service.
A good app is not a brochure on a phone. It is your service in the customer’s pocket, wired to the system your staff work in. Here is one customer’s account: her plan, a chat with her named advisor and a moved appointment, landing in the staff record as they happen.
- Hello, AmiraYour planWeek 4 of 12 · on track
- Set your goal
- First review with Sam
- Weekly check-in · due Friday
- Sam EllisYour advisor
Great check-in on Monday. You’re a third of the way there.
Can I move Thursday? Work came up.
Of course. I’ve opened Friday at 14:00 for you.
Message Sam - ‹ AppointmentsReview with Sam
- When
Thu 15 Oct · 10:00- Moved to
- Fri 16 Oct · 14:00 · Confirmed
Activity
- Appointment moved · in the appThu 10:00 → Fri 16 Oct, 14:00 · diary updated
- Reply sent by Sam EllisDelivered to the app · push sent
- Message from Amira · in the app“Can I move Thursday? Work came up.”
- Check-in completedMonday · week 4
- Their plan, their progressEach customer sees where they are, what is next and what they have done, built around your service.
- A named person to talk toChat goes to their own advisor, not a shared inbox. Replies arrive on the phone as a push.
- Booking that changes the diaryMoving an appointment in the app moves it in the staff diary. No call, no retyping.
- Staff see it live, both waysMessages, bookings and check-ins appear on the customer’s record as they happen.
From build to both stores.
Getting an app approved is a job in itself. We run the whole release, under your own Apple and Google developer accounts, so the listing, the reviews and the customer relationship stay yours.
- BuildEAS Build
Both apps are built and signed in the cloud from the same code, the same way every time.
- TestTestFlightPlay internal testing
Your team installs each build on their own phones and signs it off before any customer sees it.
- ReviewApp ReviewPlay review
Each store checks the app against its rules. We prepare the listing, screenshots, App Store privacy details and the Google Play Data safety form.
- LiveApp StoreGoogle Play
Published under your name. Crash reports and store reviews come to you, and to us while we support it.
Small fixes skip the queue. Changes to the app’s screens and logic can go straight to installed apps through EAS Update, and are picked up the next time the app starts. Anything that changes the native code, or what the app does, goes back through store review, as the rules require.
What goes into every app we build
The parts most apps need, and what each one is built with. Your quote lists the ones your app will have, stage by stage.
| Part | What it does | Built with |
|---|---|---|
| One codebase, two native apps | React Native draws real iPhone and Android controls, not a web page in a wrapper. Both apps get every fix at the same time, and both are built for VoiceOver, TalkBack and larger text. | React Native · Expo · TypeScript |
| Sign-in people will use | Email and password, Sign in with Apple and Google, and Face ID or fingerprint unlock. Sign-in tokens live in the phone’s secure storage. | OIDC · Keychain / Keystore |
| Plans, progress and check-ins | Each customer gets their own plan, goals and history, built around how your service works, with check-ins your staff can act on. | Per-customer plans · history |
| Bookings and calendars | Customers book, move and cancel within the rules you set, and add appointments to their own phone calendar in one tap. | Live availability · calendar export |
| Payments | Card, Apple Pay and Google Pay through Stripe, so card details never touch your servers. We follow each store’s rules on in-app purchase. | Stripe · Apple Pay · Google Pay |
| Chat with a named person | Customers message the person looking after them, and staff reply from the record. Tapping a new message opens that conversation. | Real-time chat · deep links |
| One backend with your staff system | The app talks to the same API and database as your staff system, which checks who the person is and what they may see on every request. | REST API · role-based access · TLS 1.3 |
The app we built for clients of nine NHS Stop Smoking Services runs on iPhone and Android, in ten languages. Read the case study
Often paired with a web portal on the same accounts, the staff system the app books against, routine admin handled, with a person approving and our security pack.
App questions
Something else? hello@echticstudios.com
Do we need two separate apps for iPhone and Android?
No. We write one React Native codebase and build a native app for each store from it. That means one build, one set of tests and one lot of upkeep, not two.
Whose store accounts is it published under?
Yours. You open an Apple Developer Program account and a Google Play Console account in your organisation’s name, and invite us to manage releases. If we part ways, the app, its reviews and its users stay with you.
Can the app connect to the system we already have?
Usually, through its API. If we build your staff system too, the app shares its database, so everything is live on both sides. Where there is no API we agree a safe sync with you, and tell you honestly what will be reliable.
What if the stores reject the app?
It happens, usually over the listing, privacy details or sign-in. We prepare for review from the start, answer the reviewer and resubmit. It is part of the job, not an extra.
How long does an app take?
A first version usually takes three to four months, delivered in stages, so your team can test it on their phones long before launch. Your quote sets out each stage.
How do you price an app?
After a free consultation we send a fixed quote, split into stages. Each stage has its own fixed price, and you can stop after any stage. Apple and Google charge their developer account fees to you directly.
Who owns the code?
You do, once paid for. The code sits in your own repository, and the data sits in your database.
Tell us what your customers should be able to do from their phone.
A free consultation, then a fixed quote in stages, with your team testing the app on their own phones early.