Best 15+ Mobile App Companies in Edinburgh

Edinburgh mobile app work leans towards regulated products

Mobile app demand here comes from an unusual mix of buyers. Alongside the ordinary run of retail, hospitality and visitor services sits a dense cluster of banking, insurance, asset management, health research and university spinouts, and a large public sector. That changes the nature of the purchase, because a product touching money, patients or personal records is assessed by people whose job is to say no before it is assessed by people who want it launched.

The practical consequence is that your supplier selection should weight evidence of regulated delivery heavily. A team that has taken a mobile app through an information security review, a data protection assessment and an external penetration test knows what those processes ask for and how long they take. A team that has not will discover it at your expense, usually in the week you hoped to submit.

Sign up, identity checks and the flow that carries them

For a financial or health product, the sign up sequence is the hardest part of the design rather than a preliminary to it. Identity verification, document capture, liveness checks and eligibility questions all have to happen on a small screen, often one handed, frequently on a poor connection, and every additional step loses people who genuinely qualify.

Ask mobile app candidates how they would handle a failed verification, because the recovery path is where most products are weakest. Ask who supplies the verification component, what it costs per check, and what happens to the images afterwards. These questions belong in the evaluation rather than in the build, since the answer changes both the design and the ongoing running cost of the mobile app.

Security testing belongs in the plan and in the budget

An independent test is not a formality here, and it is not the same as the supplier testing their own work. Agree who commissions it, at what point in the schedule, and who pays for the retest after fixes. Schedule it before the store submission rather than after, because a finding that forces an architectural change is cheaper to absorb while the release is still in your hands.

Scope it properly too. A mobile assessment covers what is stored on the device, how secrets are held, whether traffic can be intercepted, how the app behaves on a compromised handset and what the service interfaces expose to somebody who skips the app entirely. That last point catches more issues than the rest combined, because a well protected mobile app in front of an unprotected interface protects nothing.

What the stores expect from financial and health products

Both platforms apply extra conditions to products handling money, medical information or regulated advice. Expect to demonstrate who you are as an organisation, to show the relevant authorisation where one is required, to provide a working test account with data in it, and to explain in the listing exactly what the product does and does not do.

Plan the submission as a phase with a buffer rather than a final day task. Prepare the reviewer notes, the demo credentials and the privacy description as deliverables with named owners. Rejections at this stage are usually procedural rather than technical, which is encouraging in the sense that they are avoidable and frustrating in the sense that they still cost you a week each time.

Records, retention and where data comes to rest

Write down what the mobile app stores on the handset and for how long. Cached personal data on a lost phone is a reportable problem, and the fix is architectural: keep as little as possible locally, protect what must be kept, and make remote sign out actually remove it. Decide retention for server side records at the same time, because deletion rules invented after launch rarely get implemented.

For anything involving research participants, patients or public sector data, confirm at the proposal stage where processing happens and which organisations sit in the chain. Suppliers working across Scotland with institutional clients will generally have answered this before and can show you the documentation they produced. Treat a vague answer as a schedule risk rather than a paperwork detail.

Small senior teams and the key person problem

Most studios in this market are small, and the depth you are buying often lives in two or three people. That is a strength while they are on your work and a serious exposure if one of them leaves. Ask directly who would be assigned, what proportion of their time you get, and what the cover arrangement is.

Reduce the dependency structurally rather than contractually. Insist the repository sits under your organisation, that at least two people on the supplier side can release a build, that the publisher accounts and signing keys are yours, and that documentation is a deliverable rather than a promise. None of this slows a good team down, and it makes changing supplier a decision rather than a crisis.

Choosing between mobile app companies in Edinburgh

Brief three or four firms identically, in writing, including your regulatory constraints, the testing expectation and the submission timeline, then compare exclusions before totals. Ask each to name a product you can install and a review process they have been through, and follow up with the client on how the difficult month went rather than how the launch party felt.

Where the service layer behind the product is the larger part of the work, software development firms in the city may be the better prime supplier, with app specialists working alongside them. The full supplier pool sits in the mobile app development directory, and adjacent markets such as Manchester are reasonable to include when local capacity is committed. Once the brief is written, send it to several verified suppliers at once so the quotes answer the same set of questions.