Eiglou — The Tech Hut, agentic AI and software development studio
Home/Services/Mobile Applications
MMobile

Mobile app development: apps people actually use

One app, built once for iOS and Android. We take it through store review, and can keep it working as phones and operating systems change.

Send us a message
  • You own itaccounts, signing keys and the source code
  • 40+projects delivered since 2014
  • HIPAArecorded on a phone, built to meet it
What we build

Apps for your customers, your team, or your hardware.

Mobile app development for any one of these: the people who buy from you, your team working away from a desk, or the machines you need to keep an eye on. Booking, payments, site checks, orders, records — whatever the app has to do.

  • Customer apps

    Accounts, booking, payments, tracking and self-service — the app your customers install.

    Account and sign-inSelf-service flowsOnboarding journeys

  • Apps for the hardware you run

    See what your own machines are doing, get an alert when something goes wrong, and control them from a phone.

    Live statusAlertingRemote control

  • Apps your team uses on the job

    Job sheets, checks, readings and approvals for your own staff, working away from a desk.

    Role-based accessTask and approval flowsField use
we do these too

Design, and getting through review

Screens that feel native, and a submission built to pass first time.

Interaction designPlatform conventionsStore compliance

The back end the app talks to

Sign-in, data, notifications, and the admin screens your team runs it from.

Mobile APIsPush infrastructureAdmin tooling

Releases and the years after

New versions, OS upgrades and the fixes that keep an app working.

Release managementOS version upgradesOngoing support

Your project might need one of these, all three, or other things like testing, analytics or work inside the systems you already run.

How we work

From first idea to an app in the stores.

01

Discover

We learn who will use the app, which phones they have, and what they need to do on the go.

02

Design

We design the screens and the flow for both iOS and Android, and plan the back end behind the app.

03

Build

We build with one shared codebase and test on real phones as we go.

04

Run

We prepare the app-store submissions and release the app — then keep it updated, if that is what you want.

Architecture

What we get right before the app leaves our hands.

Some of what we settle early, taken from apps we built. Each one gets expensive once the app is on real phones.

  • Live screens that do not flatten the battery

    The server pushes while somebody is watching, and stops when nobody is.

    Live updatesWebSocketsConnection lifecycle

  • Notifications people do not turn off

    Delivery is the easy part. Knowing what is worth interrupting someone for is not.

    Push deliveryDevice tokensNotification policy

  • Data on a phone you do not own

    What stays on the phone is a compliance decision before it is a technical one.

    On-device dataEncrypted transportCompliance scope

  • Old versions keep working after you ship a new one

    Not everyone updates on release day, so the back end keeps answering the older versions.

    API contractShared back endRelease compatibility
What we build with

What we build with, and what runs behind it.

We have shipped production apps in both Flutter and React Native. Everything else here is the service behind the app.

Flutter React Native Native modules
Push notifications Camera and microphone GPS and location
PHP / Laravel Node.js Python / FastAPI REST APIs WebSockets
MySQL MongoDB Redis
AWS Docker GitHub Actions

The choice follows what the app has to do and what your team can maintain after we hand it over. Where a feature needs native code we write the Swift or Kotlin for it, and if your own team already runs one of these we work in it.

What it costs

What the build costs. Keeping it alive is separate.

Mobile app development is one cost: the build. Keeping the app current after that is separate work, which your team can take on or ask us for.

paid once

The build

Everything up to the day somebody can install it, store review included.

What moves it
  • Platforms, and anything that has to be native
  • What the phone does — camera, location, offline, payments, biometrics
  • How much of the back end already exists
  • Roles, sign-ins, and the screens they add up to
only if you want it

Keeping it alive

Separate work, and only if you ask for it. What it takes to still be installable next year, which your own team can do instead.

What it covers
  • Two major OS versions a year, each able to break something
  • Libraries out of support, certificates expiring
  • Store policy changes you did not ask for
  • What you want next, once real people are using it
Three ways to work with us
most common A fixed-scope first release

You know what version one does, and the budget has to be certain.

long-running An ongoing product team

The roadmap does not stop at launch.

already live Take over an app that exists

It is live and whoever built it has gone, often with the keys.

Every build includes
  • Store accounts in your name
  • The signing keys and certificates
  • Source code you own

Tell us if you also want a build your team can release without us, or a runbook a new developer can follow, and it goes into the work.

FAQ

Common questions.

Native or cross-platform?

We have shipped production apps in both Flutter and React Native, so we are not defending a favourite. Cross-platform for most products; native where the app needs widgets, a watch, CarPlay or something only one platform offers.

What happens between "it is finished" and "it is on the stores"?

Both stores read the build against their own rules before it appears. Most of the work is passing first time: permissions explained, a privacy policy in the app, a way to delete an account.

Who owns the app and the store listings?

You do. The developer accounts are in your name, the signing keys are yours and so is the code. A supplier holding those holds your product, and it is the most common way a client gets stuck.

Our app was built by someone else. Can you take it on?

Usually. We review the code and what you still hold — the accounts and signing keys are the parts that bite — then say what is worth keeping before quoting.

Can the app work with the systems we already run?

Yes. The app talks to a back end, so the work is the API between them: we use yours where there is one and build one where there is not.

Will it work offline?

Worth deciding early. Showing what was already loaded is straightforward. Letting someone change things with no signal, then merging it afterwards, is a much larger piece of work and we price it separately.

Do we need an app at all, or would a mobile site do?

An app earns its place when it has to keep working while closed, send notifications that must arrive, reach Bluetooth, NFC or biometrics, or run long sessions with no signal. If people mainly read pages, find you by searching, or use it once rather than weekly, a mobile site is cheaper and faster to change — and Apple will not accept a repackaged website in an app icon. Tell us what the app would do that a site cannot and we will say which it is, including when it is the cheaper one.

Do we need both platforms on day one?

Usually yes: one codebase makes the second platform a small addition rather than a second project. Where one is genuinely enough, we will say so.

Still deciding? Tell us what you are building and we will tell you what the first release should be, and what it would take.

Other services
Agentic AI Bespoke Solution Development Full-Stack Development IoT Solutions Web Applications

Let’s talk about your project.

Tell us about your mobile app project. We will reply with what we would build first and what it would involve.

Send us a message