Short answer. A delivered app costs four things every year: store accounts (99 dollars a year at Apple, 25 dollars once at Google), server and domain (from a few thousand to a few tens of thousands of dinars a month depending on the host), consumed services (login SMS, notifications, maps, payment) and, above all, engineer-days to follow Android in June, iOS in September, the stores’ requirements on fixed dates, the libraries and the fixes that real use reveals. The first three lines can be read on invoices; the fourth decides the budget. The order of magnitude we have given since 2026, fifteen to twenty-five percent of the build cost per year, still holds; this guide shows where it comes from.
It is written for the founder, in Algeria or in France, who has just had an app delivered, for the company whose app was built by a provider who no longer answers, and for anyone comparing maintenance contracts. It does not cover the build price, which we detail in knowing the total price of an app before starting, nor the takeover of a stuck project, described in my app is stuck with a vanished developer. It covers the year after launch.
What changes every year, with the dates
Both stores impose requirements on fixed dates, and they come back every year. On Google’s side, the Google Play policy page states that new apps and updates must target Android 16 (API 36) by 31 August 2026, and that existing apps must target at least Android 15 (API 35) on the same date; an app that does not target a recent version within two years of the latest major Android release stops being visible to new users on recent devices, and an update that misses the target is blocked. The date repeats from one year to the next with one more version. On Apple’s side, the upcoming requirements page states that since 28 April 2026, every app uploaded to App Store Connect must be built with Xcode 26 and the iOS 26 SDK; the previous year, the equivalent requirement (Xcode 16, iOS 18 SDK) dated from 24 April 2025. There too, the window returns every spring.
The systems themselves change on a fixed rhythm: Android 17 shipped as a stable release in mid-June 2026 on Pixel phones, after Android 16 on 10 June 2025; iOS 26 shipped on 15 September 2025 and its successor will follow in September 2027 if the rhythm holds. Each version brings changes to permissions, notifications, camera or storage that break untested apps. For a Flutter app, the official schedule plans four stable releases a year (3.41 in February, 3.44 in May, 3.47 in August, 3.50 in November 2026), and payment, maps or notification libraries follow their own pace.
In Algeria the priority is clear: according to StatCounter, Android accounts for about 88 to 89% of mobiles in mid-2026, iOS about 11%. Google’s 31 August deadline is therefore the one that touches almost all your users; Apple’s touches the best-equipped customers, often those who pay. Account fees are known: 99 dollars a year for the Apple Developer Program, 25 dollars once for Google Play, and, for a personal Google account created after 13 November 2023, a closed test with at least twelve testers for fourteen days before publication. These amounts are paid by international card; from Algeria, that is often the most complicated piece of the budget, and one more reason for the accounts to be in the company’s name and not the developer’s.
Year 1 in six moments
An app does not age smoothly. It ages in jolts, at six moments that can be put in a calendar.
The first week is spent on accounts and listings: screenshots, the description in Arabic and French, the first rating and the first reviews, which weigh for a long time. The first month brings the feedback the tests had not seen, because users’ phones are not the developer’s: a particular Android skin, a narrow screen, an old version. The third month, the libraries have moved: payment, maps, notifications, and updating one often drags the others.
June and September are the months of the new systems, Android then iOS, with their changed permissions and behaviours. 31 August is Google’s date: an update that does not target the required version is refused. The twelfth month brings the renewals, Apple, domain, certificates, and the review that decides the next year’s improvements. Moments 04, 05 and 06 come back every year; they are the reason an app needs a calendar and not only a number to call.
The five cost lines
A year’s budget breaks down into five lines. The first four can be read on invoices; the fifth is priced in days.
Accounts and stores are the smallest and most visible line. Server and foundation include the machine, the domain, certificates, backups and monitoring; a comparative guide from August 2026 lists public offers from Algerian hosts ranging from about 1,900 dinars a month for a small virtual server to several tens of thousands of dinars for a serious machine, before tax and sometimes before backups; a European server is paid in euros by international card. Where the data lives is decided with law 18-07 in mind. Consumed services are billed per use: every login code by SMS, every notification, every call to a maps API, every transaction through the licensed payment platform.
Code is the line that weighs. Two systems, one framework and changing libraries must be followed, tested on the betas before the releases, version bumps published before the stores’ dates, and what real use reveals must be fixed. Product, finally, groups the improvements users ask for once they use the app; this line is budgeted separately, because it depends on success, but it must not consume the days reserved for code, or the dates are missed. We detail the durations of this work in how long to build an app or a platform.
«Store and server invoices are read; engineer-days are decided. They are what makes the budget.»
A worked example
An example on assumptions, to redo with your figures: an app for a company, five thousand active users, Android and iOS, one server, login codes by SMS.
Stores: 99 dollars for Apple, about 13,000 dinars at the official rate of April 2026 (132.12 dinars to the dollar according to the Bank of Algeria, reported by ObservAlgérie); the Google account is already paid. Server and domain: between 5,000 and 15,000 dinars a month depending on the host and size, so 60,000 to 180,000 dinars over the year, backups included if you require them. SMS: we found no public price in dinars for business SMS in Algeria; on an assumption of 3 dinars per message and four codes per user per year, that is about 60,000 dinars, to be checked with the aggregator or the operator.
Engineer-days: two system cycles at five days each (tests on betas, permissions, publication), five days for store requirements and version bumps, ten days of dependencies and fixes spread over the year: about twenty-five days. That figure, multiplied by your provider’s daily rate, makes the budget; the invoices above weigh less than one month of this line. If your app cost X to build, twenty-five days generally represent between fifteen and twenty-five percent of X, which matches the order of magnitude given in the price of a mobile app in Algeria. An internal app without payment or SMS falls below; an app that takes payments, with weekend peaks, goes above.
Six silent failures
None of these failures gives warning. Two have a fixed date; four happen when nobody is looking.
The update refused by Play is the most frequent: the Android target was not raised before 31 August, and the September update, the very one that fixes a crash, is blocked until the code is adapted. The upload refused by Apple comes in spring, when a project built with last year’s Xcode is no longer accepted. The expired domain or certificate produces the most misleading message, “the app stopped working”, while the server is running; auto-renewal and an alert thirty days before are enough.
Exhausted SMS credit cuts logins and sign-ups at once, often on a month-end evening; an alert threshold and a second provider settle it. A dependency with a flaw is invisible until someone exploits it; a library review each cycle, with a tested update, is the only counter. A new OS permission, camera, location, notifications, breaks a feature for the users who updated their phone, and only them, which makes the failure hard to reproduce if nobody tested on the betas.
«An app does not age slowly: it ages on 31 August, and in late April.»
From France: keeping alive an app you cannot see
The diaspora founder has an advantage and a risk. The advantage: the international card that pays Apple, the European server and the APIs is in their hands. The risk: they see neither the crashes, nor the reviews, nor the SMS credit, and they learn about it from a cousin or a customer.
The answer has three pieces. Accounts in your name from the first week: Apple, Google, domain, server, SMS, payment, with the provider as delegated access and not as owner. A dashboard showing crashes by version, installs, reviews, SMS balance and server status, checked in five minutes a week from Paris or Lyon. A written monthly report, one page, saying what was published, what was fixed, what is coming on the stores’ dates. It is the same logic we describe for running a business in Algeria from France: see from a distance what is happening, and decide on figures rather than on calls.
Who looks after it
Six ways to keep an app alive, from doing nothing to taking over an abandoned project.
Doing nothing costs nothing in the first year; in the second, an update is refused, then the app becomes invisible to new users on recent phones, exactly what Google’s rule provides. The in-house developer is responsive and knows the code, but is the only one who does; when they leave, the calendar leaves with them. The freelancer on call fixes what is reported; nobody watches the dates or the dependencies. The hours contract with an agency gives a known budget, but the hours go to emergencies and the planned updates are pushed back.
The contract with monitoring and a calendar is the one we advise for any app that takes payments or serves customers: dates are kept, failures seen before users, and the cost is fixed, quiet months included. The takeover of an abandoned app starts with a written audit and the recovery of the accounts; sometimes the code updates and maintenance resumes, sometimes it must be rewritten, which we detail in taking over a stuck project. In every case, what sets a serious contract apart is simple: it contains a calendar with Google’s and Apple’s dates, monitoring, and a monthly report.
The 2027 calendar
Two planned updates a year, in July and October, cover almost everything; fixes slip in between.
January and February: the review and the dependencies, and above all the year’s written budget, with the days reserved for code. April: the Apple window, if the requirement returns in late April as in 2025 and 2026, with the year’s Xcode and SDK. June: the new Android, tests on the beta then on the stable release, permissions and notifications. July: the update that raises the Android target before 31 August, the most important date of the year for an Algerian app.
September: the new iOS, tests and fixes. October: the second planned update, which also carries the requested improvements. November and December: the renewals, Apple, domain, certificates, and the preparation of the next year. This calendar is built in November, before launch, as we recommend in building a mobile app in 2027: the maintenance budget is decided together with the build budget, in the same document.
What makes this kind of contract fail
- Accounts in the developer’s name. Apple, Google, domain, server, SMS: in the company’s name from the first week, otherwise every renewal depends on someone else.
- A contract without dates. “Response within 24 hours” says nothing about 31 August; a serious contract contains Google’s and Apple’s windows.
- Hours eaten by emergencies. If the days reserved for code go to improvements, the version bumps are missed.
- No tests on the betas. Discovering a new Android on its release day means discovering it at the same time as the users.
- One SMS provider, no threshold. The credit hits zero on a Friday evening, and nobody can log in any more.
- Code not versioned, or versioned at the provider’s. The repository is yours, with its history; that is what makes a takeover possible.
- No dashboard. Without crashes by version and SMS balance in view, the failure is reported by customers.
Frequently asked questions
- How much does maintaining a mobile app cost per year in Algeria?
- The fixed invoices are small: 99 dollars a year for Apple, the server from a few thousand to a few tens of thousands of dinars a month, SMS and APIs per use. The deciding line is code: about twenty-five engineer-days a year for a typical app with payment and SMS, multiplied by your provider’s daily rate. In general, that represents fifteen to twenty-five percent of the build cost.
- What happens if I never update my app?
- Under Google Play’s rule, an update that does not target the required Android version is refused, and an app that does not target a recent version within two years of the latest major release stops being visible to new users on recent devices. At Apple, an app uploaded with an SDK that is too old is refused from the late-April window. Existing users keep the app, but it eventually breaks on new phones.
- Which dates matter in 2027?
- Late April for Apple’s SDK requirement, if it returns as in 2025 and 2026; June for the new Android; 31 August for the Android target imposed by Google Play; September for the new iOS. Google and Apple can move these dates; the contract must allow a margin.
- Should I host in Algeria or in Europe?
- Both are done. Algerian hosts publish virtual server offers from about 1,900 dinars a month, payable in dinars; a European server is paid in euros by international card. The decision is made with law 18-07 on personal data and with where your users are.
- I am in France, how do I follow an app used in Algeria?
- Accounts in your name, a dashboard of crashes, installs, reviews and SMS balance, and a written monthly report from the provider. You see the state of the app in five minutes a week, without depending on a call.
- My provider no longer answers and the app is live, what should I do?
- Recover the accounts first, Apple, Google, domain, server, SMS, then have the code and dependencies audited. If the code updates, maintenance resumes with a calendar; otherwise it must be rewritten, carrying over data and users. We describe the process in the guide on taking over a stuck project.