Mobile app development in Edinburgh
For many visitors, a trip to Scotland starts in Edinburgh, and where it goes next often has no signal. Tour operators, walking and cycling companies, distilleries and heritage sites run apps for visitors who will spend the day in glens, on islands and on single-track roads where coverage comes and goes. An app that needs a connection to open a booking or a map is an app that fails at the moment it matters.
We build React Native apps for iOS and Android that work offline first: bookings, tickets, maps and guides stored on the device, updates that sync when a signal returns, and payments that queue safely rather than failing silently. We design for visitors from many countries and for the guide with a spare phone, and test on the kind of patchy connection your customers will actually meet.
Edinburgh is a money town with a major research university in the middle of it, and its software work reflects both. On one side sit the fund managers, life and pensions firms and banks: Baillie Gifford, NatWest Group's headquarters at Gogarburn, and a long tail of platforms, administrators and wealth managers. On the other side sit the University of Edinburgh's informatics and data science groups, and EPCC, which hosts the national supercomputer ARCHER2 and was chosen in 2025 as home for the next one, with up to £750 million of government funding.
The financial side needs systems that are careful rather than fast. Pension and investment products carry decades of rules, and much of the administration runs on platforms that predate the people maintaining them. Customers expect to see their pot, their charges and their options clearly on a screen, and advisers expect the platform to answer as fast as the one they used yesterday. So the work is usually integration, data, reporting and customer screens around an old core, with every change tested before it ships. Fintechs sit in between, often selling back into those same banks and fund managers.
The university side needs something different: research code that works on a GPU in a lab and has to become a product that works for a paying customer. That gap, between a model that is right and a service that is reliable, is where many spin-outs stall. Hiring is competitive. ITJobsWatch puts the median advertised software engineer salary in Edinburgh at £70,000 over the six months to September 2026, on a smaller sample than London, and the banks and fund managers take many of the experienced engineers.
Working with us from Edinburgh fits the day you already have. Four hours of every working day overlap with yours, set across your morning, so stand-up, review and the decisions that follow happen live with the engineer who writes the code. The rest of the day runs on written updates and pull requests in your own Slack, GitHub and Linear, waiting for you after lunch, with runbooks and architecture notes written as the work goes.
We are the right fit for a defined piece of work, a spin-out's first production system, or a project that needs senior engineers this quarter while your own hiring catches up. Start with a fixed-price two-week piece and judge us on what ships. For agencies, we work white-label under your name, in your repositories and tools.
Four ways this arrives.
And crashes on the ones your users own. We add crash reporting with readable stack traces, find the handful of devices and OS versions causing most of the crashes, and fix those before anyone touches a feature.
Signing keys on a laptop, a manual build, store notes written at midnight. We move builds and signing into CI, add over-the-air updates for JavaScript-only fixes, and write down exactly how a release goes out.
A Bluetooth device, a vendor SDK, a camera pipeline, a background task the OS keeps killing. We write the native module in Swift and Kotlin, expose a small typed interface to React Native, and keep it isolated so upgrades stay possible.
Forms that vanish, actions that send twice. We decide what must work offline, keep it on the device, queue writes with idempotency keys the backend understands, and show the user plainly what is still waiting to sync.
Our own React Native app on Android, with retraction built into the client because moderation can pull a message after it has been sent.
Read the write-up →Asked by Edinburgh teams.
How do you work with teams in Edinburgh?+
Four hours of every working day overlap with yours, set across your Edinburgh morning, so stand-up and code review happen live. We join your calls and work in your tools: Slack, GitHub and Linear. You talk directly to the engineer who writes the code. The rest of the day carries on in pull requests and written updates that are waiting for you after lunch, with runbooks and architecture notes written as we go.
Do you build for Edinburgh fund managers and pensions firms?+
Yes. For pensions and investment platforms we build services around the administration core: APIs that expose what it knows, transfers and switches processed exactly once, and tools for the exception cases that live in spreadsheets today. For fund managers we build investment data pipelines that trace every figure back to its feed, research search that cites its sources, and customer screens that make pots and charges clear.
How does your rate compare to hiring in Edinburgh?+
ITJobsWatch puts the median advertised salary for a software engineer in Edinburgh at around £70,000. Our published rate is $35/hour with a $5,000 minimum, or $5,400 a month for one engineer embedded in your team. There is no recruiting time and no employment overhead, and we can start within days of the first call. A fixed-price two-week piece at $2,800 lets you judge us on output first.
Can you work with a university spin-out?+
Yes, and it is a good fit. Spin-outs usually have strong research code and nobody whose job is running it in production. The research team stays in charge of the science, and we build what surrounds it: the API, the data handling, the deployment and the monitoring. A fixed-price two-week piece fits a grant or accelerator budget, and the code belongs to the company from the first commit.
React Native or fully native?+
React Native for most products: one codebase, one team, both stores. Fully native makes sense when the app is mostly the hard native part, such as heavy camera or audio processing, complex background work, or a platform feature React Native does not support yet. We will tell you which side of that line you are on, and write the native parts by hand either way.
Expo or bare React Native?+
Expo, in almost every case now. Development builds and config plugins removed most of the old reasons to eject, and EAS handles builds and signing. We go bare only when a native dependency genuinely cannot live inside a config plugin, and we will explain why before doing it, because it makes every future upgrade more work.
Can you take over an app someone else built?+
Yes. We start by getting it to build on a clean machine, which is often the hardest step, then bring React Native and its dependencies up to a supported version before adding features. We tell you what state the app is in, including where the store listings, signing keys and accounts actually live, before quoting anything larger.
Who handles App Store and Play Store submission?+
We do, from your developer accounts, not ours. We prepare the builds, the privacy disclosures and the notes for the reviewer, and deal with rejections when they come. The accounts, signing keys and listings stay in your name, so you can change developers later without asking anyone's permission.
Does our backend need to change for a mobile app?+
Often, a little. A mobile client stays on old versions for months, retries on bad networks, and cannot be fixed by a server deploy. That means versioned endpoints, idempotent writes, and a way to tell an old client it must update. We check the backend for those before the first screen is built, because retrofitting them after launch is slower.