Post-Migration Maintenance

The reason an app ends up five years behind is rarely a decision. It is that mobile maintenance is an annual obligation on a team whose other systems are not, and the obligation quietly stops being anyone's job.

This engagement is the standing capacity that keeps the obligation met.

What it covers

• The annual OS and SDK cycle. New iOS and Android releases, the behaviour changes that come with them, and the target-level requirements the stores enforce on a schedule you can read a year ahead.
• Store policy changes. Privacy manifests and data-safety declarations, permission justifications, account-deletion requirements, and the listing work that comes with each one.
• Crash and performance work. Triage from your crash reporter, with the fixes prioritised by affected sessions rather than by stack-trace novelty.
• Dependency hygiene. .NET and package upgrades taken in small regular steps, which is the difference between an afternoon and the engagement you just finished.
• CI and release engineering. Keeping the pipeline producing uploadable artifacts, and keeping certificates, profiles and keystores current and owned by more than one person.
• Pairing with your .NET developers. The explicit goal is that routine releases stop needing us.

How it is staffed

Hourly, as staff augmentation or as scheduled project work, by the same senior US engineers who did the migration. There is no retainer to buy and no minimum to commit to, because a maintenance relationship that has to be justified every quarter is one we would rather earn than lock in.

If you have not migrated yet

We also take on maintenance of apps still on Xamarin, where the honest job is keeping a revenue-carrying app shippable while a move is planned or funded. That is legitimate work and we do it properly — but we will not describe it as a long-term position. Xamarin support ended in May 2024, and the store requirements do not pause for budget cycles.