iOS and Android apps, built in Tbilisi from one codebase.

Not from the public stores yet, and we would rather tell you here than have you find out on your phone during our meeting. Relive is our own product: it runs in production on the web at relive.ge, and its iOS and Android builds are made and in testing. The store listings are the step still open, and the reason is account paperwork on our side rather than a technical wall. Ask us and we will open it on a phone in front of you.

Because it is one we operate rather than one we delivered and forgot, and operating is where the lessons are. Carrying a single product all the way through means we have already met the parts nobody demos: store paperwork, payments that behave differently outside the sandbox, video processing that stalls on one bad file and blocks everything queued behind it, and finding out something is down. A studio that has shipped ten apps and run none of them has not met any of that.

Often a website does, and the fit test near the top of this page is there to help you decide. If what you are offering is content, a catalogue, a booking form or a one-off purchase, a fast mobile web build does the same job with no install to ask for and no store to satisfy — and search engines can read it, which an app cannot. An app earns itself when people return without being reminded, or when you need the camera, offline state, background work or push notifications.

You do, from the first commit rather than at handover. The repository is created in your organisation, the Apple Developer and Google Play accounts are opened on your company's legal entity rather than an employee's personal email, and the database and file storage sit in your accounts with our access added rather than the reverse. Without a written assignment, the default legal position in most places is that the people who wrote the code own it — so we put it in the contract.

Assume at least one round. Rejection is routine rather than a disaster, and we absorb the first round in the fee rather than billing it back. Apple publishes that it reviews the large majority of submissions within a day and names plain incompleteness as the dominant cause of trouble — crashes, placeholder text, dead links, a privacy policy that does not match what the app actually collects. The way to avoid a second round is to have the paperwork honest the first time.

For personal developer accounts opened after November 2023, yes: Google requires twelve testers, opted in and staying opted in for fourteen continuous days, before you may even apply for production. Registering as an organisation rather than as a person avoids the requirement entirely, which is the first thing to settle — in week one, not in month four. We know this one from the inside: it is the step still open on our own app.

Not for most bugs. React Native apps can receive JavaScript and asset updates over the air, and Apple's developer terms permit this provided the update does not change what the app is for — so an interface or logic bug can reach everyone in hours. Anything touching native code still needs a build and a review. The rule that makes the two safe together is that native modules are fenced, and an update landing on an older build must degrade rather than crash.

For most business apps, yes, and it is the honest default. We build on React Native with Expo — one codebase, both phones, close enough to native that your users will not notice. Where cross-platform is said to fall down is exactly where it does not have to: when you need something genuinely native, you write it. Our own app has a real iOS Live Activity written in Swift and a real Android foreground service written in Kotlin, sitting inside the shared codebase.

Not the number of screens, which is the weakest predictor and the one buyers quote first. The cost sits in how many kinds of user the app has, whether it needs a backend of its own or can talk to something you already run, how much of the phone it touches — camera, media library, push, background upload, offline — and whether money changes hands inside it. Payments are the most reliable way to double a mobile budget. The eight layers above are the honest checklist.

You will hold a build long before you have a launch date. Plan roughly three to five months from kickoff to a first usable version, plus store submission on top: about a month of discovery and design, two to three months of build with a testable build in your hands every week or two, then the tail nobody budgets for — device testing, privacy declarations, age ratings and store paperwork. Anything quoted at six weeks is either much smaller than you think or leaving out the tail.

The industry convention is fifteen to twenty per cent of the build per year in steady state, and more in the first year while real usage finds what testing did not. That is separate from new features. It covers the annual iOS and Android releases, dependency upgrades that arrive whether you want them or not, expiring certificates and signing keys, store policy changes, crash triage, and the running bill for servers, media storage and messaging.

Yes, and not as a translation layer bolted on afterwards. Our own product ships Georgian and English throughout — the app, the web product and the admin copy — with a written Georgian review as part of the work rather than a machine pass. Georgian typography breaks in specific, predictable ways when a layout was drawn in English, so the screens are designed with the longer language in them from the start.