Introduction

A clinic's deposit bug fixed on Tuesday lunchtime that reached users on Friday afternoon, behind two rejection rounds caused by a privacy declaration nobody had re-examined after a dependency update; and a trade association's app published under an unreachable developer's account, with the source code available and completely irrelevant, that could never be updated again.

The fix that was finished on Tuesday and shipped on Friday

A small clinic had an appointment app. Nothing elaborate — book, reschedule, cancel, a reminder, a card on file for the deposit.

On a Monday a user reported that cancelling a booking sometimes charged the deposit anyway. Noor reproduced it in forty minutes, found the cause in an hour, and had a fix written and tested by Tuesday lunchtime.

Then it went into review.

The first submission was rejected — not for the bug, not for the fix, but because a privacy declaration on the listing did not match what an analytics component had started collecting after a routine dependency update three releases earlier. Nobody had noticed, because nothing had broken. The rejection was correct.

Noor corrected the declaration and resubmitted. That one was rejected too, for a related reason on a different question.

The fix went live on Friday afternoon. Between Tuesday lunchtime and Friday afternoon, the clinic kept taking deposits it then had to refund by hand, and the client asked four times — reasonably, and with increasing difficulty — why a bug that had been fixed on Tuesday was still affecting their customers on Thursday.

There is no good answer to that question. There is only a true one, and it should have been said before the engagement started rather than during it: you cannot deploy. You submit. The gap between finishing a fix and shipping a fix is not yours, it is not predictable, and it is not something skill removes.

The app that could not be updated

The second story is worse, and it is the one that ends businesses.

A trade association had an app built four years earlier by a developer who had since become unreachable. It still worked. Members used it. Nobody had touched it in two years and nothing appeared to be wrong.

Then a platform requirement changed, as they do, and the app needed a new build to stay available.

The app was published under the previous developer's account, not the association's. The signing credentials were on a machine nobody had access to. The association had the source code — they had been sensible about that — and it made no difference at all.

There was no way to update that app. Not with more money, not with more skill, not with a better developer. The only route available was to publish a new app: new listing, new identity, every existing installation stranded, every review and every ranking signal gone, and a message to several thousand members explaining that the app on their phone would stop working and they needed to install a different one.

Nobody had ever discussed the developer account. It had not appeared in the contract, in the handover, or in any conversation, because at the start of a build it seems like a detail and the app is the thing everybody is looking at.

The keys to a product are not the code. They are the account, the signing key and the certificates — and whoever holds them decides whether the app can ever be updated again.

What this book is about

This is a manual for building, shipping and supporting mobile apps for small businesses and organisations, alongside a job.

It covers product discovery, user stories, UX, prototypes, iOS and Android work, APIs and backends, testing, submission, analytics and support. But the reason those two stories open it is that the technical craft is not what decides whether this works as a business. Four structural facts do, and most app development advice mentions none of them.

The four rules

Rule one — you cannot deploy. You submit.

Every release passes through a reviewer you cannot call, on a timetable you do not control, against rules that are interpreted rather than executed. A rejection is frequently not a bug: it is a metadata problem, a declaration mismatch, a guideline reading you did not anticipate. Your critical fix goes out when it is approved. That single fact reshapes estimating, launch dates, emergency response, support agreements and every promise you are tempted to make.

Rule two — the device is not your environment.

There is a matrix of devices, operating system versions, screen sizes, locales, permission states, memory conditions and networks, and nobody owns it. Most of the failures you are told about cannot be reproduced on anything you have. You debug from crash reports, logs and analytics rather than from the thing itself, which is a different skill from the one that built the app.

Rule three — the keys to the product are not always yours, and they expire.

Developer accounts, signing keys, certificates and provisioning. Whoever holds them controls whether the app can be updated. They are frequently in the wrong name, on a machine nobody can reach, or thirty days from expiry with nobody watching. This is the one that turns a working app into an unfixable one, and it is discovered at the worst possible moment.

Rule four — shipping is the start of an obligation with no natural end.

The platforms release annually. Minimum requirements rise. Interfaces deprecate. Dependencies stop being maintained. An app nobody touches does not merely become dated — it eventually cannot be updated, or is removed from sale. The client thinks they are buying a finished thing, and what they are actually buying is the first release of something that requires attention for as long as it exists.

And the interaction is the whole risk. Rules two and four make failure likely. Rule three decides whether you can do anything about it. Rule one decides how long it takes, and it is never as long as anybody wants. That is why procedure rather than talent is what makes this business work, and why the developer with a verified release path and a pre-submission checklist beats the better developer without them, reliably.

The numbers this book is built on

The economic unit is revenue per app under support — what an app actually returns across a year of releases, rejections, platform changes, crash triage and support requests. Not the project fee, which describes one moment.

The leading indicator is hours per release, tracked as a curve and including every resubmission. It should fall as the app and the toolchain settle, and an app whose curve never falls has a specific, findable cause.

The master variable is first-submission approval rate — the share of your submissions approved without a rejection round. It predicts hours per release directly. It predicts whether you can honour a launch date. It predicts how fast you can ship an emergency fix, which is the only thing that matters on the worst day of the year. And it is almost entirely within your control, through a pre-submission checklist and a declaration register, which is what makes it worth measuring.

And the risk indicator is the count of apps without verified release access — apps where the developer account, the signing credentials and the certificates have not been checked, in the last quarter, by actually producing a build. Target zero. It is the mobile equivalent of an untested backup: nothing happens the month you skip it, and when it matters it is already too late.

How to use this book

Read Part One in order. Chapters 5 to 8 are the four rules in full, and everything afterwards depends on them.

Everything else can be read as needed. Part Two sets the business up — screening, discovery, the plan, the budget, the questions for somebody qualified, the toolchain and pricing. Part Three is the work itself. Part Four is the money and the records. Part Five is the year, the procedures, the numbers and the plans.

There are sixty-eight resources at the back and one hundred and forty-eight AI prompts, four per chapter. The ⚠ symbol marks a risk, a load-bearing constraint, or a clause in a prompt you should not delete when you adapt it.

Two things to do before anything else. Read your own employment contract, including the intellectual property clause, because code written in the evening is not automatically yours. And take Chapter 15 and Resource 18 to somebody qualified where you are — liability, IP, personal data, privacy declarations, accessibility, payments and insurance — before you accept a client rather than during your first year.

And one thing to establish on every engagement, before you write a line: whose account will this app be published under, who will hold the signing key, and what happens to both if we stop working together. It takes one conversation. The alternative is the second story.

©2026 James Henderson / https://localhandyman.work

Chapter 1 — What Mobile App Development Actually Is

Finishing and shipping are two moments separated by a queue owned by somebody else, and everything difficult about the business lives in that gap.

1.1 The job is not writing an app

Writing the app is perhaps a third of it, and it is the third people picture.

The rest is finding out what the product actually is before anybody has said it clearly, deciding what it depends on and who owns those dependencies, testing it on hardware you do not own, getting it through a review process on somebody else's timetable, and then keeping it alive through platform changes that arrive whether or not the client has budget.

The distinguishing feature of this trade is that finishing is not shipping. In almost every other kind of software work, those are the same moment. Here they are separated by a queue owned by somebody else, and everything difficult about the business lives in that gap.

⚠ If you find the coding part hard, you will find this business impossible. If you find the coding part easy, you will find this business surprising. The failures are almost never technical. Chapter 5.1.

1.2 What you are actually selling

Not screens. Not features. Not a codebase.

You are selling a working product in somebody else's hands, kept working. That is one sentence and it contains four separate obligations: that it does the thing, that it does it on the user's device rather than yours, that it can be updated, and that somebody is watching when the ground moves.

Clients buy the first. They do not know about the second. They assume the third. And they discover the fourth about eleven months in, when something stops working and nobody has touched it. Chapter 8.7.

⚠ Sell the four, priced separately, from the first conversation. A build sold as a finished object is a support conversation you will have anyway, later, from a weaker position. Chapter 27.1.

1.3 Why "an app" is the wrong unit

The word does an enormous amount of hiding.

"An app" can mean a form that posts to an existing system, which is a fortnight. It can mean the same form with an offline mode, a login, a push notification and a backend that does not exist yet, which is four months. Both are described identically in a first email, by the same kind of client, with the same air of it being straightforward.

The unit that predicts effort is not the app. It is the number of platforms, the number of dependencies you do not own, and the number of decisions nobody has made yet. Chapter 11.3.

⚠ When somebody says "just an app", the word doing the work is "just", and it means they have pictured the screens rather than the product. Chapter 4.1.

1.4 The four rules, in brief

Rule one — you cannot deploy, you submit. Releases go through a reviewer you cannot call, on a timetable you do not control, against rules that are interpreted. Chapter 5.

Rule two — the device is not your environment. A matrix nobody owns, and most reported failures cannot be reproduced on anything you have. Chapter 6.

Rule three — the keys to the product are not always yours, and they expire. The account, the signing key and the certificates decide whether the app can ever be updated. Chapter 7.

Rule four — shipping is the start of an obligation with no natural end. Platforms release annually, requirements rise, dependencies deprecate, and an untouched app eventually cannot be updated at all. Chapter 8.

And the interaction is the risk. Two and four make failure likely. Three decides whether you can fix it. One decides how long that takes.

1.5 What makes this different from web work

Worth stating plainly, because a lot of people arrive here from the web and the assumptions do not transfer.

On the web you deploy. Here you submit, and the difference is days rather than seconds on the worst day of the year.

On the web the browser matrix is small and the failures are visual. Here the matrix includes memory pressure, permission states, background termination and network transitions, and the failures are crashes on hardware you have never held.

On the web you can roll back. Here you cannot un-ship a release to the people who already have it; you can only ship another one, through the same queue.

And on the web, hosting is transferable. Here the store identity is not — an app's install base lives with an account, and moving it is a process rather than a copy. Chapter 7.8.

⚠ Every one of those differences makes the checklist matter more and the improvisation matter less. Chapter 24.2.

1.6 Who is realistically good at this

Not the fastest builder.

Somebody who reads the actual guidelines rather than remembering what they were, because they change and a remembered rule is a rejection. Chapter 23.9.

Somebody who can work from evidence — a crash report, a log, a user's badly-written description — rather than needing to see the failure themselves. Chapter 25.7.

Somebody who writes things down at the time, because the state you tested on, the declaration you made and the key you used are all unrecoverable afterwards.

And somebody who can tell a client an uncomfortable thing about a timetable early, when it is a scheduling adjustment, rather than late, when it is a failure. Chapter 33.4.

⚠ Temperamentally, the trait that matters most is tolerance for a queue you cannot influence. If waiting on somebody else's decision makes you frantic, rule one will be the thing that ends this rather than the technology.

1.7 What it costs you in a normal week

Build blocks. Evenings and weekend mornings. Schedulable, protectable, and where the visible progress happens.

Release windows. Preparing, submitting, monitoring review, responding to a rejection, watching a phased rollout. Short, unpredictable in timing, and not compressible.

And obligation load — the background awareness of every app you support: a certificate expiring, a platform release approaching, a dependency that has gone quiet. It consumes nothing on a calendar and a great deal of attention. Chapter 33.1.

⚠ The third one is why this is harder alongside employment than it looks, and it is the reason emergency exposure is counted separately from hours in the plan. Chapter 13.5.

1.8 The skill that actually decides your margin

Not language fluency. Not framework knowledge.

It is standardisation — how much of your work runs on one toolchain, one release procedure, one testing matrix, one dependency baseline. Chapter 16.1.

A developer with three apps on three toolchains has three of everything: three build setups to keep working, three sets of platform changes to absorb, three release procedures to remember. A developer with eight apps on one toolchain has one, applied eight times.

And it compounds into first-submission approval rate, which is the master variable of this book. A standardised release with a checklist gets approved. An improvised one gets a rejection round nobody priced. Chapter 35.4.

⚠ The economics of this trade are decided by sameness, and sameness is a screening decision made before the work starts. Chapter 10.6.

1.9 What this book assumes

That you have a job and a few evenings. That you can write code, or are close enough that documentation gets you there. That you have very little to spend beyond a developer account and one or two test devices.

That you have not yet shipped something for somebody whose business depends on it, which is the part that changes everything.

And that nothing here names a platform rule, a version, a timetable or an SDK — because those change, and a specific quoted from memory is exactly the failure rule one punishes. Everything in this book tells you what to verify rather than what the answer is.

1.10 Chapter summary

Writing the app is a third of it. The distinguishing feature of the trade is that finishing and shipping are different moments, separated by a queue owned by somebody else, and everything difficult lives in that gap. You are selling four things — that it works, that it works on the user's device, that it can be updated, and that somebody is watching — and clients buy only the first. "An app" hides a range from a fortnight to four months, and the predictors are platform count, dependencies you do not own, and decisions nobody has made. The differences from web work are all in the same direction: checklists matter more, improvisation matters less. The people who do well read the current guidelines rather than remember them, work from evidence, and tolerate a queue. And margin is decided by standardisation, which compounds into first-submission approval rate.

AI prompts for this chapter

Prompt 1 — Separating the four obligations in an enquiry

Here is a client enquiry about an app: [PASTE]. Separate what they are asking for into four obligations — that it works, that it works on devices I do not control, that it can be updated in future, and that somebody maintains it as platforms change. ⚠ Do not estimate hours or cost. ⚠ Do not name any platform, operating system version, store rule or SDK. ⚠ Identify which of the four the enquiry does not mention at all, as questions for me to ask.

Prompt 2 — Unpacking the word "just"

Here is how a client described what they want: [PASTE]. List every ambiguity that could change the effort by more than double — platform count, backend existence and ownership, offline behaviour, authentication, payments, notifications, and data handling. ⚠ Do not resolve any ambiguity by assuming the common case. ⚠ Do not produce a specification. ⚠ Output questions only, ordered by how much the answer changes the work.

Prompt 3 — Self-assessment against the four rules

Here is my background and my available time: [PASTE]. Ask me the questions that would establish whether I am suited to a trade where I cannot deploy, cannot reproduce most reported failures, may not control the release credentials, and carry an obligation that does not end at launch. ⚠ Do not reassure me. ⚠ Do not treat coding ability as the main variable. ⚠ Include tolerance for waiting on a decision I cannot influence as an explicit question.

Prompt 4 — Counting my three kinds of time

Here is my week: [PASTE]. Separate it into build blocks, release windows, and background obligation load for apps I would be supporting. ⚠ Treat obligation load as consumed capacity even in weeks when nothing happens. ⚠ Do not suggest working more hours. ⚠ State how many supported apps this week could realistically carry, and say what the number depends on.

⚠ AI checkpoint for this chapter

One — did it name a platform rule, version or timetable? All of those change, and a specific quoted from memory is the exact failure rule one punishes. Chapter 23.9.

Two — did it estimate effort from a description? The predictors are platform count, unowned dependencies and undecided questions, none of which appear in a first email.

Three — did it treat coding ability as the main variable? It is not. Standardisation and tolerance for a queue you cannot influence decide more.

Four — did it treat obligation load as free? It consumes nothing on a calendar and a great deal of attention, and ignoring it is how capacity plans fail. Chapter 33.1.

Do This Now

1. Write down, in one sentence, what you are selling — and check it includes being updatable and being maintained.

2. Count your three kinds of time separately: build blocks, release windows, obligation load.

3. Read your employment contract, including the intellectual property clause, this week.

4. Decide now that you will verify every platform specific against current documentation rather than memory.

5. Complete Resource 1, the ten-question self-assessment, and Resource 3, the four-rules reference.

©2026 James Henderson / https://localhandyman.work