Buyer's guide
What to look for in a cross-platform WPF runtime
Eight questions to put to anyone asking you to run a decade of production WPF on their runtime. Take them to every supplier you are considering, including us.
Running an existing WPF application on macOS or Linux without rewriting it is a genuinely hard problem, and the number of serious attempts at it is small. That makes this an unusual purchase: the shortlist is short, the technology is difficult to assess from the outside, and a demo that renders your login screen tells you almost nothing about whether your real application will ship.
What follows is written as criteria rather than as a comparison, on purpose. Comparisons go stale, and they tell you about the market on the day they were written. Criteria keep working, including against whatever appears next year. No supplier is named below.
The eight questions
Tested compatibility, not claimed compatibility
Ask
Which third-party control suites have you tested, at which versions, and where are the results published?
"Compatible with WPF" is not an answer, it is a category. Your risk does not live in the framework, it lives in the commercial control suites, the custom controls, and the rendering edge cases your application has accumulated. A runtime that cannot show you a per-vendor, per-version compatibility record is asking you to do that testing for them, on your schedule, at your cost.
A good answer looks like: A published list, broken down by vendor and version, that admits what does not work.
A support commitment that exists in the contract
Ask
What is the response time in working days, is it written into the agreement, and what is the remedy when it is missed?
Best-effort community support is a genuine good and it is not an SLA. Ask what is bounded, too. A stated ticket allowance is a sign of a supplier who has done the arithmetic on what supporting a hard migration actually costs; unlimited support offered by a small team is a promise that will not survive contact with a difficult codebase, and the person it fails is whoever bet a release date on it.
A good answer looks like: A named response time, in the contract, with the limits stated up front rather than discovered later.
Source code access and escrow
Ask
Can we get the source, on what terms, and will you put it in escrow?
This is the question that decides what happens to your product if the supplier stops existing. It matters more here than in most software purchases, because a UI runtime is not a component you can swap out in a sprint: it is underneath everything your application draws.
A good answer looks like: A clear yes with terms, or a clear no. Evasion on this question is itself the answer.
Indemnity and provenance
Ask
Who warrants that we can ship this, and what indemnity comes with it?
Any cross-platform WPF runtime is derived from a substantial existing codebase with its own licence history. Somebody has to stand behind your right to distribute the result inside a commercial product. If nobody does, that liability has quietly become yours, and it will be found during the next acquisition or security review rather than today.
A good answer looks like: A named legal entity accepting the warranty in writing.
A funded maintenance commitment
Ask
Who maintains this, is it their job, and what has the release cadence been for the last two years?
Volunteer effort is not a defect, and some of the best software in this ecosystem is built that way. It is not a commitment, though, and the two get conflated. Ask what happens to the release schedule when the maintainer changes employer, has a difficult year, or simply loses interest, because over a ten-year application lifetime at least one of those will happen.
A good answer looks like: Paid maintainers, a track record you can inspect, and a roadmap with dates that have been met before.
The organisation standing behind it
Ask
How many people are employed on this, how is the work funded, and how long has the entity existed?
You are making a ten-year bet on a dependency that sits under your entire user interface. The relevant question is not whether the code is good today. It is whether the thing that produces the code will still be producing it when you need a fix during a release freeze in 2031.
A good answer looks like: A funded organisation with a commercial reason to keep the lights on, not a single point of failure.
Production evidence at your scale
Ask
Which named production applications of comparable size and complexity run on this, and what did they hit?
A demo application proves the happy path. What you need to know is what happened to somebody with eight hundred XAML files, a print pipeline, a compliance sign-off, and a control suite threaded through all of it. Ask specifically what went wrong for them, because a supplier who cannot name a single problem has either not shipped anything hard or is not being straight with you.
A good answer looks like: Named customers at your scale, and a candid account of what was difficult.
Licence terms that survive a bad year
Ask
Is the licence perpetual or a subscription, and what happens to our right to ship if we stop paying?
There is a meaningful difference between losing access to updates and losing the right to distribute what you have already built. Understand which one you are buying before procurement gets involved, not after, and make sure the answer is written down rather than described on a call.
A good answer looks like: A perpetual right to ship the version you have, with updates and support as the thing that renews.
And then run the evaluation properly
The answers above tell you who is worth evaluating. Only your own codebase tells you whether it works.
Evaluate against the real codebase
Not a sample, not a prototype, not the clean module. Use the application with the parts nobody wants to touch, because that is where the entire risk is concentrated.
Start with the ugliest screen
The dashboard with the custom control, the third-party grid, and the printing. If that renders, the rest is scheduling. If it does not, you have learned it in week one instead of month five.
Give it long enough to be real
A two-week window on a fifteen-year codebase tells you nothing worth knowing. Serious evaluations of applications this size run for months, and any supplier who will not support that timescale is telling you something.
Declaring the interest
We publish this because we think we answer these questions well. You should still make us prove it.
We build Avalonia XPF, so we are not a neutral party and you should read the list above with that in mind. Our answers are on the record: a published third-party compatibility list broken down by vendor and version, response times written into the agreement with the ticket allowance stated up front, source code access available at the Enterprise tier, perpetual licences, and named production deployments at Autodesk, KLM, Stryker, Keysight and Okta.
We also maintain the free, MIT-licensed Avalonia framework, and if your application is small enough that porting it is the better answer, we would rather tell you that. Either way, the questions above are the ones to ask, and the only evaluation worth anything is the one run against your real codebase.