Why apps need ongoing work even when nothing is broken, and what a realistic annual budget looks like.
A website left alone for two years mostly still works. An app left alone for two years frequently does not, and may be removed from the store. The difference surprises people.
Why apps decay
- Operating systems update annually and can break behaviour you relied on
- Both stores enforce minimum SDK versions, and apps below them get delisted
- Third party services change their APIs, and your integrations stop working
- Certificates and provisioning profiles expire on a schedule
- New devices appear with screen sizes your layout never anticipated
A realistic annual budget
| Activity | Frequency | Rough effort |
|---|---|---|
| OS compatibility updates | Twice a year | A few days each |
| Dependency and security updates | Quarterly | A day or two each |
| Bug fixes from real usage | Ongoing | Varies with app complexity |
| Server and service costs | Monthly | Scales with users |
As a planning figure, budget somewhere between fifteen and twenty five percent of the original build cost per year to keep an app healthy. Less than that and you are accruing debt that arrives as a large bill later.
What to agree before the build ends
- Who holds the developer accounts? They should be in your company's name, not the studio's.
- Who has the signing certificates and how are they stored?
- What is the response time if the app breaks?
- What does a compatibility update cost, roughly?
The account ownership question is the important one. If the app is published under a studio's developer account, moving away from that studio is considerably harder than it should be.