Store-Compliance Release Rescue
When the deadline is closer than the migration.
This is the engagement people call about at the wrong end of a release window. An update was rejected, or the Play Console is refusing the upload, or a security review has flagged the framework and there is a board date attached to the answer.
A full migration is the right long-term answer and it is not going to happen this month. This rung exists so that the deadline and the migration stop competing for the same six weeks.
The two shapes this takes
One more compliant build from the existing app. Sometimes this is still possible, and when it is, it is by far the cheapest answer. It usually means raising the Android target API level and fixing what that breaks, rebuilding against a current iOS SDK on a toolchain that can still target it, replacing or pinning the dependencies that block either, and repairing a signing and provisioning setup that has drifted since the last release.
The minimum .NET MAUI shell. When the existing app genuinely cannot be built to current requirements any more, the shortest compliant path is a .NET MAUI project that hosts the existing screens through the compatibility layer rather than a rewritten UI. It satisfies the store on SDK and target-API grounds, it ships, and it doubles as the first slice of the real migration instead of throwaway work.
Which of the two applies is a question about your repository, not a preference. It is the first thing an assessment answers, and on a rescue we answer it in the first days.
What the work includes
- Target and SDK work. Android target API level and the behaviour changes that come with it: storage, background execution, permissions, exported components, and the foreground-service declarations that are now checked at upload.
- The iOS toolchain. Getting a build out on an Xcode and SDK combination the App Store currently accepts, from a machine or runner that can still be provisioned.
- Provisioning and signing. Certificates, profiles, keystores and their passwords, plus who holds them. On a rescue this is a surprisingly common critical path.
- The pipeline. A CI job that reliably produces an uploadable artifact, so the next submission is not another archaeology exercise.
- Crash and regression triage. The crashes the raised target level introduces, found before review does.
- A submission dry run. The upload, the store listing requirements, and the review questionnaire answered, before the deadline rather than during it.
What it does not include
It does not include new features, and it does not include a redesign. A rescue is scoped to getting a compliant build through review, and anything else is noted for the migration plan rather than quietly added.
Afterwards
A rescue buys a release cycle, usually a year. It does not change the fact that Xamarin support ended in May 2024. The rescue report ends with what the next store requirement is likely to demand and how much of the migration should be done before it lands.
Billed hourly, staffed by senior US engineers, scoped in an initial conversation.