Xamarin App Assessment
Every screen and dependency given a decision and a reason.
A Xamarin app is usually described to us in one sentence: "it is a Xamarin.Forms app from about 2019, and nobody here wrote it." The assessment replaces that sentence with a list you can plan against.
What we read
- The solution structure. Xamarin.Forms shared project plus iOS and Android head projects, target frameworks, the Xamarin.Forms version, and how far behind the last version it can still be built with.
- Every custom renderer and effect. What each one changes, whether .NET MAUI's compatibility layer will carry it unchanged, and which ones have to become handlers.
- Every third-party and custom NuGet. Current version, whether a maintained successor exists for .NET MAUI, and what the app loses if it does not. Commercial control suites are treated the same way: we check your licence terms and what the vendor's current package supports.
- Native bindings and platform code. Binding libraries against native SDKs are where migrations stall; we establish whether each SDK still ships a supported version and what the binding will cost to move.
- Platform services and dependency resolution. DependencyService registrations, MessagingCenter use, and anything relying on the Xamarin.Forms application lifecycle.
- Test coverage, honestly measured. Which shared logic is covered, which is not, and where characterization tests would have to be written before the UI layer is safe to touch.
- Build and signing state. Whether the project still builds on a supported toolchain, which certificates and provisioning profiles are current, who holds them, and whether CI can still produce an uploadable artifact.
What we work out from it
Whether you need a rescue before a migration. If a store deadline lands before any realistic migration date, the assessment says so on the first page and sequences a compliant release ahead of the port.
A decision per screen and per dependency. Keep, rewrite, or retire, with the reason recorded next to it. Retire is consistently larger than teams expect: flows built for a process that has since changed, and screens the analytics show nobody opens.
The blockers, costed. Bindings with no supported SDK, controls with no successor, platform behaviour that changed under the app while it sat still, and signing material nobody can produce any more.
A sequenced work order. Which slices come first, what each one leaves releasable, and which ones can run in parallel with your own team's roadmap.
What you get
A document with a row per screen and per dependency and a defensible answer in the last column, the sequenced plan, the risk list ranked by what happens if it fails, and a walkthrough with the engineers who did the work.
It is written to be executed by your own developers. If you would rather we executed it, the migration picks up exactly where it stops — but the assessment stands alone, and it is deliberately the kind of document you can take to a firm that is not us.
When the answer is not .NET MAUI
Occasionally it is not. An app that is two screens over a web service, or one whose real problem is a process nobody follows any more, does not need a migration; and some apps are better served by a native rewrite than by a port. If that is what the evidence says, that is what the document says. We charge for the assessment, not for a predetermined answer.
How long it takes
It depends on screen count, how much native binding there is, and whether the project still builds. Scope and timeline are agreed in an initial conversation, and the work is billed hourly.