Algeria AgencyMobile application
A published application: what it costs to keep alive
Development ends. The application does not: it ages on its own, on handsets you can no longer reach.
A website left untouched for two years still displays. A mobile application left untouched for two years stops working, and sometimes stops being downloadable. That is not a difference of quality but of nature: one is served from your side, the other is installed on somebody else, on a system neither you nor your client controls.
It is the budget line almost nobody presents at quotation time, because it produces nothing visible. It builds no new feature, it cannot be demonstrated, and its only observable result is that nothing breaks.
This article describes that line: what ages, who owns the calendar, what a year costs, and when stopping is the reasonable decision. The companion article covers adoption — weight, permissions, the first launch — and none of it is repeated here.
It carries no chart, and the first section explains why the number you arrive looking for cannot exist in the form of an average.
A published application is no longer quite yours
On the day you publish, your software splits in two. There is the version you hold, in your repository, which you can fix this afternoon. And there are the installed copies, sitting with people, in the state they were in at download, over which you have no direct power at all.
That second half is what produces incidents. A defect fixed on your side stays live for everyone who has not updated, which at first is nearly everybody. A website does not have this problem: the fix is seen by the next visitor, and no older version remains in circulation.
The practical consequence is a reversal of priority. On a website you fix and then tell people. On an application you tell people first, because the delay between the fix and its arrival is measured in days and depends on the handset, the connection and the settings.
Keep this sentence for everything that follows: you never fix an application, you publish a new one and wait. Every decision on this page follows from that delay and from how uncertain it is.
Why there is no average annual cost
The question that brings people here is a fair one: what does an application cost per year? There is no honest number, and the reason differs from other subjects on this blog. It is not a figure somebody is keeping, nor a badly defined one: it is a figure that is not a property of the market.
The cost depends on three things you choose and none that we observe. The number of platforms, because two systems want two calendars and two pieces of work. The reach of the features, because anything touching payment, location or the camera ages faster than anything displaying text. And how fast your trade changes, because that decides whether you publish four times a year or once every two years.
A supplier answering with a percentage of the build cost is answering a different question. That percentage circulates, it is convenient, and it assumes upkeep is proportional to construction — which is wrong in both directions: a simple application on two platforms costs more to hold than a rich one on a single platform.
What we can do, and what section eight sets out, is break the line into items you can estimate yourself. A total you assembled beats an average you cannot check, and it has the advantage of staying right when your scope changes.
The versions in the wild, and why they stay there
At any moment your application exists in several simultaneous versions across your users, and the distribution is not up to you. Some hold the latest, many hold one from three months ago, and a handful hold the first, installed on release day and never updated since.
The reasons are ordinary and none is fixable in code. Automatic updating is sometimes off, often because it consumes data the person pays for. The handset has no free space left. The system is too old for the recent build. Or the application has not been opened in a long time, so nothing triggers the update.
What this imposes is a discipline rather than a tool: every change on your side has to keep working with older versions for a while. The case that hurts is the server: changing the shape of a response instantly breaks every installed copy expecting the old shape, and they will not fix themselves.
The simple rule, cheap if taken early, is never to remove a field and never to change its meaning — you add. An application is the only software in your estate whose old clients cannot be force-updated, which makes backward compatibility a real constraint rather than an elegance.
The calendar that is not yours
Both application stores publish technical requirements that evolve, and they set dates. Past a deadline, an application that does not meet them can no longer be updated, and then can no longer be downloaded by new users. None of that depends on what you did: your application has not moved, the requirement moved.
It is the most misunderstood difference between an application and a website. Nobody takes a website away from you because it is old. An application, yes, and the notice is real but it lands in a mailbox somebody has to read — usually the publishing account, rather than the owner.
From this follows a minimum obligation independent of any new feature: open the project at least once a year, rebuild it with current tooling, test it and republish. An application receiving nothing for two years is not thrifty, it is on borrowed time.
That obligation is also why an application project never really ends. A quotation showing a build price without saying what happens the following year describes half the product, and it is the cheaper half.
The signing key: the most dangerous object in the project
Every published application is signed with a key, and that key is the identity of the application as far as the system is concerned. An update signed with a different key is not an update: it is another application, which your users would have to install alongside the first, losing their data and their history.
The consequence fits in a sentence: losing the key means losing the continuity of the application, not just a file. The typical case does not look dramatic — a supplier change, a replaced computer, a former employee — and it is discovered only at the next update, sometimes two years after the loss.
The key must therefore live somewhere belonging to the business rather than to the supplier, and be backed up separately from the code repository. It is a secret rather than a project file: it does not get stored beside the sources, where it ends up in the first copy of the folder anybody makes.
Check this now if you already have an application, by asking whoever maintains it a precise question: where is the signing key, who can reach it, and where is its backup. A hesitant answer is a problem for this week, because its severity does not grow but the cost of repairing it becomes infinite on the day the key no longer exists.
The publishing account, and who really owns it
An application is published under a publishing account, and that account carries a name, an address and bank details. It owns your application presence in the same way a domain name owns a website.
The common mistake is leaving that account in the supplier name, because it is quicker at the start and they already have one. It works perfectly while the relationship lasts, and becomes a complete blockage the day it ends: moving an application between accounts is possible but heavy, and it needs the cooperation of the party you are parting from.
The rule is the same as for the domain name, the hosting and the advertising account, and it is equally dull to apply: whatever carries your name in public is opened by you, paid by you, and you invite the supplier onto it. The reverse is a starting convenience whose price you pay at the end.
The same reasoning covers the other accesses a project accumulates: the notification service, the tool receiving crash reports, the file storage. Make the list once, with the owning account for each — an hour of work that earns its price on the day a supplier changes.
What breaks without anybody touching it
The useful classification of application faults is not technical but causal, because it says who has to act. Three categories are enough, and two of them do not come from you.
The first is the system changing. A new handset release alters a rule — access to a folder, behaviour in the background, display under a notch — and an application written earlier stops behaving as intended. It did not move; the ground moved.
The second is a third-party service changing. A payment gateway, a map, a messaging provider alters its interface or withdraws an old version. It is the most brutal kind because it is instant, total, and usually announced in documentation nobody on your side follows.
Only the third is your own change, and it is the least frequent once the application has settled. That proportion is what makes upkeep counter-intuitive: most of the annual work responds to outside events, which explains why an application nobody is touching still consumes budget.
Triaging crashes: three questions, in order
A crash reporting tool produces a long and demoralising list, and reading it from the top is the best way to spend a week on a defect affecting two people. Three questions, asked in this order, put the list the right way up.
How many distinct users, rather than how many occurrences? A crash repeating a hundred times for one person is a special case; the same one hitting a hundred people once is a priority. Both show the same total in most tools.
Where in the journey? A crash at startup or at payment is worth twenty on a secondary screen, because it has no way around it: the person can do nothing else, and they uninstall. A crash on a screen you can leave costs irritation rather than a customer.
And on which versions? A defect existing only on old copies is already fixed — the question becomes update reach, which is section nine, rather than a new fix. Triaging it otherwise means repairing the same thing twice.
Supporting a version you can no longer fix
You will get messages from users describing a problem you settled two months ago. They are not wrong, and telling them it is fixed is a false answer from where they stand, because on their handset it is not.
The useful reply has two parts: say the fix exists, then explain precisely how to get it, in the actual movements on the handset rather than the word update. Half the people told to update do not know where the button is, and the other half believe they already did.
You also need to know which version the person is running, which means showing it somewhere in the application, on a screen support can have them open in one sentence. Without that, every conversation opens with a ten-minute investigation, repeated on every call.
Finally, that flow of messages is a free measure of how far your versions have spread, and the only one you will get without instrumentation. If complaints about an old defect continue three months after the fix, your problem is not that defect, it is that your updates are not arriving.
What a year costs, honestly broken down
Lacking a usable average, here is the breakdown that lets you estimate for yourself. It has four items and each is priced separately, which makes the total arguable line by line rather than in a block.
The compulsory item is the annual bring-up: rebuild with current tooling, correct whatever the new requirements impose, test on recent devices, republish. It exists even if you ask for nothing, and it is the only one that is not negotiable.
The second is reacting to the outside failures described in section six, unpredictable in date and fairly predictable in volume: a third-party service your application counts on will change eventually. The third is support, which depends on user numbers rather than on complexity. The fourth, the only optional one, is evolution: the features you choose to add.
Presenting those four separately changes the conversation, and that is why this section exists. A client can choose to evolve nothing for a year; they cannot choose not to do the first line, and a quotation that blends them suggests otherwise.
Forcing the update: the only lever, and its price
There is a way to take back control of installed copies: have the application check at startup that it is not too old, and block use until the update is done. It is the only real lever, and it is brutal.
Its cost is direct and immediate. You stop somebody who wanted to use your application, at a moment you did not choose, and ask them for a download consuming data they pay for, over a connection that may not be good. Some will not finish, and some of those will not come back.
It is justified in two cases only, and they are worth writing down in advance rather than deciding under pressure: when the old version has become dangerous — a flaw, a leak — and when it has become false, for instance showing prices or terms that no longer exist.
Everywhere else, inviting beats blocking: a banner offering the update, repeated, that lets people carry on. The difference between the two is the difference between an application that protects you and one that punishes you, and your users feel it in exactly those terms.
What we do, and what we refuse
Our share is the upkeep itself: the annual bring-up before the deadline rather than after it, backward compatibility on the server side, crash triage by the three questions in section seven, the screen showing the version for support, and the inventory of accounts and the signing key. These are recurring obligations rather than a project, and we present them that way in a quotation.
We refuse to quote an annual cost as a percentage of the build. That is not commercial caution: the figure exists in the trade, it is easy to say, and it assumes a proportionality that does not hold. We price the four lines of section eight separately, and you can decline one of them.
We also refuse to hold your signing key and publishing accounts in our name, including when you offer it to move faster. It is the convenience that costs most when a supplier changes, and a supplier who accepts it makes themselves hard to leave — which is not a quality we want to have.
Finally, part of this page needs no development and is worth doing this week, without us: ask where your signing key and its backup are, check whose name the publishing account is in, and show the version number inside the application. The three take a day and remove the three most expensive blockages on this page.
Frequently asked questions
Does an application really need republishing if nothing changed?
Yes, at least once a year. The stores evolve their technical requirements and set dates: past the deadline, a non-compliant application can no longer be updated, and then can no longer be downloaded by new users. Your application did not move, the requirement moved. It is the one upkeep item that is not negotiable.
What happens if the signing key is lost?
You lose the continuity of the application, not just a file. An update signed with a different key is treated as a different application: your users would install it alongside the old one and lose their data. The key must live with you, backed up separately from the code repository, and its loss is usually discovered only at the next update.
Why do users report a bug that is already fixed?
Because the fix is with you and not with them. Your installed copies exist in several simultaneous versions and many stay old: automatic updating off to save data, storage full, system too old, or the application not opened in a long time. Answer by explaining the concrete movements to update, never with the words already fixed.
Can the publishing account stay in the supplier name?
It can, and it is the starting convenience that costs most at the end. The account carries the public presence of your application the way a domain name carries a website. Moving to another account is possible but heavy and needs the cooperation of the party you are parting from. Open it yourself and invite the supplier onto it.
Should updates be forced?
In two cases only: when the old version has become dangerous — a flaw or a leak — or false, for instance showing prices that no longer exist. Blocking stops somebody who wanted to use your application and imposes a download they pay for in data; some will not finish. Everywhere else a repeated banner that lets them carry on is better.
What does maintaining an application cost per year?
There is no honest average, because it is not a property of the market but a function of your own choices: the number of platforms, the reach of the sensitive features, and how fast your trade changes. A percentage of the build cost assumes a proportionality that does not hold. Price four separate lines instead: annual bring-up, reacting to outside failures, support, and evolutions.
Where we come in
Three questions to whoever maintains your app — where the signing key is, where the publisher accounts are, who receives deprecation notices — decide whether it survives.
- We do the upgrade before the announced deadline, not after the removal.
- We leave the signing key and the publisher accounts in your name.
- We show the version number on a screen your support can have opened.
We will not reduce upkeep to a percentage of the original budget: that number circulates, it reassures, and it corresponds to nothing measurable.
Read next
Mobile apps: the weight and the asks decide more than the features
What makes people abandon an app is settled before the first feature: the download, the sign-up, the permissions.Custom software: the specification you write is not the one you need
Nobody knows what they want before using it. A complete specification written beforehand is a guess set down in the present tense.The pilot that will never ship: the signs, from week two
A pilot that fails rarely fails at the end. It fails in the second week, quietly, and everybody carries on for three months.
Let us talk about your project
A free audit, no commitment: we look at your online presence and tell you what is holding it back.