Will AI make all code eventually look like demo code?

In the future, more code will be written by AI.

That AI will be trained by looking at existing code and documentation on the web.

For new libraries, APIs, functionality, etc. AI will first learn from the documentation, because there are no other examples to learn from.

Documentation and demo code contains unnecessary details and comments. It's also usually verbose and does not include many important considerations, like security, performance, logging, error handling, etc.

If that's all there is, how will the AI learn what better will look like?

It's already happening. 
When I have AI generate test cases, it frequently includes comments that only make sense in the context of teaching someone how to write test code. Why else would you include the single word "Assert" in a comment above a line that asserts whether a condition is met? Is such a comment necessary when the next line starts "Assert.IsTrue("? The AI does this because that's what it "saw" in the training data. And that training data included these comments because it was an instructional example, or was included in code that copied directly from examples like that.

Maybe it doesn't matter.

Maybe AI will learn to overcome this.

Maybe it's an indication that while AI may be able to write code that appears to work, it will still require people who have a different (and broader) understanding to ensure it works well, efficiently, and does everything that's needed. Not just what you might see in a demo.

I went to Interesting 2025

I went to Interesting 2025 (in London, the other week). Fourteen talks, from fifteen speakers, on very different topics.

But, I didn't find it interesting. I found it:

• Inspiring
• Curious
• Terrifying
• Intriguing
• Surprising
• Sad
• Heart-warming
• Hunger-inducing
• Hopeful
• Misleading
• Unbelievable
• Educational
• Inspiring (again)
• Triggering
• Motivating
• Wondering

which was really the point!

Thank you to: Alice, Rosa (& dad), Julia, Cate, Zoe, Lisa, Daniel, Rachel, Jackie, Terry, Lauren, Luyanda, Clare, Daria, Anthony, Helen, Rebekah, and especially Russel.

As one of the hosts said, "That was really interesting. Actually!" 

I went to Interesting 2025, I committed a rudeness, and I suffered as a result. (IYKYK😉)

INotifyPodcastChanged: Working with XAML

I was on the INotifyPodcastChanged podcast talking about XAML.

You can find the episode at https://inotifypodcastchanged.com/4 or listen on your preferred podcast player.

Yes, talking about something that by definition is very visual was a challenge, but I hope I did a good job.

Your feedback will be greatly appreciated. :)

 

I'm making Visual Studio less secure because I won't pay a 3rd party for security theatre

Which is less secure:

• preventing the application of security patches?
• not having signed assemblies?

It depends on context. So, what if I reframe the questions: 

How much would you pay to update an assembly that was previously signed?

If you don't pay, you can't update that assembly.

You can release another version (with a different name), but existing users won't get a notification of an available update.

For "reasons", I previously signed the libraries I released through NuGet and the extensions I released through the Visual Studio Marketplace.

The cost to renew my code signing certificate this year was over $800. This is more than I want or have to spend on this. (Especially given the quality of the support they provide. or not.)

Microsoft offer an alternative at a reasonable price, but it's only available to companies registered in the USA or Canada. I'm not, so that's no help.

NuGet makes it possible to release unsigned updates to previously signed packages. So, that's good.

Sadly, Visual Studio does not. I even asked very nicely. However, I was told that for security reasons, they do not allow this.

I guess the consequences of extensions not getting updated to address security threats or security vulnerabilities in their dependencies aren't a problem.

If they didn't allow the uploading and distribution of unsigned extensions it wouldn't be such an issue. But, because I was previously trying to be good and sign things on the basis that it was better for security, I (and anyone wanting updates) suffer now.

Unless someone wants to sponsor me enough to cover the cost of a certificate, the 50 extensions I have in the marketplace will never be updated. If you're waiting on a fix (or a security update), I'm not sure what to tell you.

I'm still wondering what to do. Hopefully, I'll have an announcement in the coming weeks...

ENAMEL RFC Revision 1

I've just released the first update to the RFC for the ENAMEL language.

This is only the first of several expected revisions and adds a few new options and clarifications.

Changes in this revision:

• Trailing semicolon is optional with inline C# (clarification)
• Nested loops are supported (clarification)
• Nested AUTOGRIDs are not supported (clarification)
• Add the ExpandGridDefinitions setting
• Add the SET keyword

As before, I appreciate any feedback on these changes or anything related.

Additionally, as I continue to explore these ideas and gain feedback from others, it's looking more and more likely that I will eventually release some tooling to support this language. I'd love your thoughts on this (including if you want to be an early tester) at https://forms.gle/DXVP8fjfyics74Sj6

AI will solve all our problems....?

 Apparently, "AI will solve all our problems!"

Even the ones that we know are being created by using AI now?

I can see two responses:

1. We hope that will be the case. (By the time we encounter the severe negative consequences, "AI" will have been developed to deal with those problems.)
2. We plan and prepare for these known issues and limit or mitigate their consequences before they become a problem. (Hope isn't always the best strategy - when it comes to technology.)

Improve .NET MAUI's AppThemeBinding?

 The AppThemeBinding in .NET MAUI is great. But wouldn't it be better if it required a lot less text?

I'm a massive fan of code that is clear, expressive, and as short as possible without obscuring any important details.

The default syntax in the top AppThemeBinding example above is indicative of what you'd expect from regular XAML use. It does everything you need, the names are clear, and anyone familiar with XAML will not struggle to read it.

But, I look at it and think:

• That's a lot of text
• Why the repetition?
• Why are so many braces needed? (I know why but wish they weren't.)
• Can't there be a better, simpler way of telling both the compiler/framework and any developer looking at the code in the future what I want to happen?

As you can see from the picture above, I have a better way, and you can see an example of it there.

Of course, I don't have all possible color combinations pre-defined. I used a Source Generator to create what I wanted by including this attribute somewhere in my code.

[AppThemeColorResource(AppColors.Primary, AppColors.White)]

This example also uses my RapidXaml.CodeGen.Maui library to generate constants for the names of the color resources defined in the Resource Dictionary. I could use hard-coded strings for the names, but that risks other possible maintainability issues.

I also have other variants of the attribute, so I can also do things like this:

[AppThemeNamedColor(nameof(Colors.Aqua), nameof(Colors.HotPink))]

[AppThemeHexColor("#FF00FF", "#8B0057", "PinkOrPurple")]

[AppThemeNamedBrush(AppBrushes.SecondaryBrush, AppBrushes.Gray200Brush)]

Each generates a MarkupExtension that can be used in place of an AppThemeBinding and is named based on the names of the provided brushes or a specifically provided name. (As in the AppThemeHexColor example above.)

The above example uses 'lightDark' as the xmlns alias. I tried various naming styles and conventions for the alias and the generated MarkupExtension but currently prefer this best. I think it communicates the maximum amount of helpful information with the least amount of text.

Examples of other things I've experimented with include:
{ifLight:WhiteElseBlack}
{color:PrimayIfLight_PrimaryDarkIfDark}
{if:LightUseFF0000_DarkUseDD3333}
{appThemeBrush:Green_ifLightElse_DarkGreen}

What would you use?

If you see something like the above, you might be tempted to think, "Yes, it's shorter and easier to read, but what's the downside? I bet it's slower."

If you've never measured how long it actually takes to load different XAML content, that is a reasonable assumption.

Previously, I would have thought the same too. However, I recently built a test harness that makes it easy to measure how long it takes to load different XAML files, and the results shocked me.

I created two pages. Each contains 100 Labels (in a VerticalStackLayout). In one page, each label uses the AppThemeBinding as shown above. The other page uses my syntax. 

In a quick test, loading each page multiple times and in a variety of scenarios, the version of the page that used my syntax loaded 25% faster!

So, my version:

• is shorter
• is easier to read/understand
• has exactly the same functionality
• and is faster!!!

Now, tell me why you wouldn't want to do this?

NOTE: If you're looking to hire someone to help you build apps with .NET MAUI and you appreciate code that is easy to read, understand, and maintain. Get in touch as I'm looking for work.

creating and making words

I was recently confused by someone who was using creating and inventing (& creator and inventor) interchangeably. I found this confusing. There must be a difference, and it may be useful to understand it.

I came up with these definitions for various creativity-related terms. They're not perfect, and there are exceptions, but sharing here as others may find this useful.

Make - To produce something

Create - To make something that has existed before

Invent - To create something that has never been created before

Innovate - To create something by combining existing things or ideas in a new way

Design - To create something for a specific need or purpose

But what about "creativity'?

In my experience, I believe this is mostly used as a shorthand for idea creation. Being creative means coming up with lots of ideas, possibly using invention or innovation, and seeing how they can meet a need or requirement.

When I built six apps in under 4 weeks

While looking for a new job, I've been thinking about how I quantify the work I've done previously, and I remember the time I built six apps in less than four weeks!

We didn't start from scratch, but compared to everything I have as a reference, it was fast work. I miss working on projects where the goal was to ship high-quality products regularly, and they would be used by lots of people.

So, backing up, the project was a port of existing apps that existed for other mobile platforms. The apps were "city guides" for different cities and were based on published pocket guides for those cities. The apps contained interactive maps of each city to enable the exploration of places of interest. It was also possible to create a custom itinerary of places to visit. Not massively complicated, but for a recognised brand that expected the highest quality.

Six apps, one for each of six cities.

Before we started, all the existing data and assets from the existing apps were gathered, a full review of the existing apps was performed (by everyone involved), and the designer from the agency created visual mock-ups for each of the "pages" in the app.

The [book] publisher hired an agency to build the apps, and the agency sub-contracted out the development to me. As a highly recognised agency, who did work I admired, they were one of the few companies I had always wanted to work for/with.

Prior to starting development, we held a meeting with the designer, product manager, agency owner, and myself to go through everything, ensure all requirements and details were known, and that everything was understood.

The plan was to build a single "core app" that could be "white-labelled". By providing different data files and visual assets, each of the six apps could be produced from a single codebase. I'd used a similar technique before when needing to build localised versions of an app for different countries, each with its own unique content and language.

Here's how the work broke down week by week.

Week 1: Build the custom map control. Without this, there would have been no app. It was the centrepiece of the application: unique functionality that differentiated it from other available apps. Yes, the whole first week was spent entirely on building a single control. It was, obviously, a complex control that contained a lot of functionality. All the functionality had to be easily testable too. It wasn't practical to travel to each city (on 3 different continents) to manually test the functionality.

Week 2: Get all the data in a consistent format. The provided data was in multiple formats. Mostly a mix of CSV files and SQLite databases. So, before building the actual mobile apps, I built a console app that would take all the different data sources and produce standardised, consistently formatted data that could be used by each app the same way. The existing apps embedded and used the raw data files, but it meant that they had to handle all the variations in file formats, data formatting, and incomplete data. Having data in a known and consistent format meant the code in the mobile app didn't have to account for as many variations or possible error conditions. It meant less code and less error handling. When updated data files were available, they could be reprocessed by the console app, and the files it produced were tested for consistency and correctness.

Week 3: Build the app. With all the complexities handled in the previous week, this became a case of building pages for the app(s) that displayed and allowed interaction with the data (& map control). I recall there being fewer than twenty pages in the app. Many pages were reused for different scenarios where the same basic structure could show very different data. These were pretty simple pages to display and interact with a fixed set of data. The challenging work in determining how the pages should look and the possible variations in data had all been considered prior to actually building the UI. This was key to building fast and correctly.

Week 4: Test the app. While doing some final tweaks and checks, I checked and retested everything while the agency's dedicated tester also did the same. Some additional automated checks/tests were also added. Across the entire code base, there were over 32000 tests, but many of these were for checking the data's validity, formatting, & consistency for each place of interest.

One particular memory I have was with the person from the agency responsible for testing the apps before release. They couldn't find any problems with any of the apps. However, like many people responsible for testing software, they didn't want to find no problems. They looked into the data that was being used and raised a single bug that some of the latitude and longitude details (of some places of interest) were specified to an unnecessary number of decimal places. A quick update to the data formatting app, the addition of an extra test that no lat/long values had unnecessary precision, and then the regeneration of all the data and the app was ready to ship. Once released, no bugs were reported.

Small apps with little feedback and interaction from the people using them aren't always desirable, but it's good to know (remember) that I can build them with impressive speed.

When process improvements can be more valuable than code changes

While looking for a new job, I've been thinking about how I quantify the work I've done previously. It reminds me of a role I had where I introduced positive changes far beyond the assigned coding tasks.

I was working in a team (of 8) building desktop software that the business sold. It was high-value software for a specific task and industry. The product was more than a decade old (when I joined), and updates were released (approximately) every three months. Updates would add fixes and new features. Some customers also paid for their own custom functionality.

I collaborated with the sales team to provide technical planning support for custom work and, as part of the general development team, implemented planned changes for each release.
It wasn't the most mentally taxing work and didn't break new technical ground. But, it did allow me the time to think about the broader picture of what we were doing and how we were doing it.

Here are five things I did in that role that others on the team couldn't or wouldn't have done.

1. Streamlined work distribution. When I joined, the work to be done for each release would be decided in advance and then individual tasks would be given out to developers one at a time as each task was completed. This way of working had been done for years, but I quickly identified multiple issues. I persuaded the manager to group related tasks (typically by area of the code base) and give them all to a single developer. This change resulted in faster changes, (so more work could be done for each release), fewer bugs, and developers gaining a deeper understanding of the codebase. Because each developer was spending more time in an area of code they got to know it better, could make multiple changes at the same time and avoid conflicts or rework when multiple developers tried to change the same area of code at the same time.
2. Increased documentation accuracy and quantity. The company used to have a set of Word documents that detailed developer processes and important information. These were hosted in a read-only form on an intranet. The process for changing or adding a document was slow, and so it wasn't done as frequently as would have been beneficial. I migrated the existing system to a wiki-based solution, which led to more documentation being created and it being kept up to date.
3. Simplified and automated the release process.  Releases were an important time, but they used to be very slow. Originally, a release would require a "release week" where all the developer team were involved in preparing the release or working on projects away from the main codebase. Creating a release build was a slow, manual process that took three days to complete. This would then be manually tested while custom builds were created for customers with unique features. After going through this process once, I saw the issues and began automating it. I reduced it to a 25-minute process that also included all custom builds. This was run multiple times a day as work was committed to the main branch.
4. Introduced automated testing. I joined a company with a dedicated manual tester and a technical director who refused to accept that coded/automated tests were a good use of anyone's time. When I was tasked with work that involved multiple complex calculations, I knew I couldn't complete the task without creating coded tests. There were too many variables and scenarios for me to remember everything, and even following a manual script would be slow and prone to errors. I created the tests anyway and even identified many previously unknown existing bugs in the calculations. At our next weekly meeting, I admitted what I'd done and showed how having the tests had not only saved me time and improved the quality of the code, but it also made future changes to this part of the code easier and with less risk of introducing unintended side effects. There was initial scepticism from the manual tester who felt threatened, but once they saw how it freed them up to do other work and reduced the bottleneck of manual testing from the development process, everyone got on board and creating coded tests soon became the norm.
5. Restructured weekly progress meetings. Every Thursday afternoon, the whole team would gather for a meeting. Initially, this was primarily dominated by each developer individually reporting what they had been working on and giving progress feedback to the manager. Most of the progress feedback to the manager was irrelevant to the rest of the team and so it wasn't a good use of time to gather everyone in a room for a series of 1-on-1 conversations. I suggested moving the progress reporting to email which, happened before the meeting. This freed up the meeting to collectively address any concerns and discuss wider issues or areas for improvement. I particularly remember the final meeting I attended on my penultimate day with the company. When I suggested a new process improvement and explained the benefits, another member of the team asked why I cared when I was about to leave. I replied that I wanted the best for the company and the team, even when I wouldn't be there. And, while I was there, I wanted to do everything I could to make it as good a place to work as possible.

The code changes I made could, arguably, have been made by any of the other developers on the team. That's part of the nature of coding. I expect that the increased use of AI/LLMs as part of software development will further reduce the distinction between the code produced by different developers. The distinguishing factor between developers may come down to their ability to do more than produce acceptable code. Being able to understand how the required task fits into the broader picture and identifying areas for improvement is a crucial skill. A knowledge of the wider business and its processes can also be valuable. Not that individual developers should always question every decision and attempt to change business processes, but they should be able to see and understand the broader environment and offer suggestions when appropriate.
I'm looking forward to competing in this developer marketplace.

When a one second saving was worth £10K each day

While looking for a new job, I've been thinking about how I quantify the work I've done previously. It reminds me of the time we worked out how a small performance improvement was worth approximately ten thousand pounds (Sterling/GBP) to the company on each day of operation. Six days a week times 52 weeks a year, that's over £3 million per year!

I was working for a courier/delivery company and was responsible (among other things) for the software used to scan parcels in the depots and by drivers when making deliveries. First thing in the morning was a very busy time, and lots of parcels needed to be scanned and loaded onto many vehicles, which often required delivery far-away or on tight deadlines. Time was definitely an essential factor. Saving time taken during this process would:

• Allow more time for time-sensitive deliveries
• Reduce the number of late deliveries
• Allow for increased capacity
• Reduce stress among people loading vehicles and drivers with tight deadlines

We (obviously) wanted to save any time we could.
Through a combination of changes to multiple pieces of software involved in the process (preparing the list of deliveries for each route, the scanning software, and the software used by controllers to organise and dispatch routes/drivers), it resulted in time savings equivalent to one second per parcel. 

One second per parcel might not sound like a lot, but there were a lot of deliveries being made each day. In addition to potentially saving time, that one second per parcel was, on average, enough to enable the addition of one extra delivery to each route each day.
Based on the number of routes and the average price of a delivery, that amounted to approximately ten thousand pounds. Per day. Definitely a successful project.

The monetary value is a notable figure, but no, I didn't see any of that or even get a bonus. My reward was knowing I'd done my job well and improved things for the people using the software I was responsible for.
I enjoyed the satisfaction of solving a complex technical problem (how to make the process take less time) that also contributed to a positive benefit for the people using the software.
More than simply being able to put a financial figure on the result of a change, I was able to use my broader knowledge of the company and its processes and also learn more about it during the project.

ENAMEL: More than a DSL for writing XAML

A few weeks ago, I first shared my idea for an alternative to writing XAML. However, I just realised I haven't posted about it here. So, I've included the TLDR below. 

It might be tempting to think about it as simply a way to write XAML, but I think of it as more.
I think it's a way of documenting what you want from the UI in a way that encourages you to think about the markup as any other code file.

The idea came from ideas about how to address some of the common criticisms of XAML. There are ways to write XAML that address many of those issues, but the restrictions of the language mean that it's only possible to go so far. ENAMEL is an idea about what could be done without the historical baggage of XAML and without needing to change any of the tooling or existing code bases for languages that use XAML.

I'm still exploring ideas about what ENAMEL could be.

I'm also working on formalising my ideas and guidance for writing better XAML. Stay tuned for more details.

In the meantime:

ENAMEL - An RFC for possible future XAML-based development

A new, simplified markup language to define application UI. The new files automatically generate comparable XAML files for your WPF, .NET MAUI, or WinUI app, which are then compiled as normal. Fully configurable, totally optional (use it for some or all XAML files) and low risk as the XAML (and C#) files are still available.

It addresses the common complaints about having to work with XAML and adds new functionality without the need to change any of the existing tooling.

How much less verbose is it?

Well, this is the XAML for an Empty page in a .NET MAUI app.

<?xml version="1.0" encoding="utf-8" ?>

<ContentPage

    x:Class="NewMauiApp.MainPage"

    xmlns="http://schemas.microsoft.com/dotnet/2021/maui"

    xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml">

</ContentPage>

And this is the exact same thing in ENAMEL.

ContentPage

Yes, just a single word is needed!

There are more examples comparing XAML and ENAMEL.

ENAMEL: Simple, human-readable, and easily maintainable UI markup.

Learn more at https://github.com/mrlacey/enamel 

I also have a few amendments and extensions to the original process that are coming soon.

Sales, Marketing, and Advertising

I'm writing this for my own benefit and to think it through.

I'm trying to get some ideas clearer in my head by reducing them to something specific and simple. Obviously, the real world is more complicated and nuanced. I can't reduce whole industries down to a few paragraphs.

Let's start with some definitions:

Sales: Exchanging money for a good or service. Or activities relating to this.

Marketing: Saying 'here is a thing.'

Advertising: Saying 'buy this thing.'

Of course, people rarely buy something before being aware of it. Advertising and/or marketing create awareness that leads to sales.

When advertising creates enough sales to keep going, a business can be successful.
Put money into advertising. Create sales to more than cover the advertising. Make more money. Repeat.

Marketing is intended to eventually lead to someone buying a thing, but it may do so indirectly. By simply showing a thing, it may lead to people wanting to buy it. But it might "just" be increasing awareness so that someone will consider them (the company or a product) favourably (or at all) when looking to make a purchase in future.

Marketing may also be able to produce something that can "spread" / be shared / "go viral", so that it reaches more people than paying for direct advertising.

A "thing" can also be a concept. People still need to "buy" into an idea!

The marketing of ideas can be a powerful thing.

The boundary between advertising and marketing can be blurry. At least one is needed. A thing won't sell (or spread) if people don't hear about it.

Sorry, no conclusions or summaries here, just a desire to learn and grow.

Developers using "AI" is like learning JavaScript or jQuery

Excuse the data reference, but it's one I occasionally come back to. Back when jQuery was in its prime, there were two schools of thought about what front-end web developers should do.

1. Do you learn JavaScript so you can do "anything"? or

2. Do you "just" learn JQuery?

If you take the second option, and need to do something jQuery can't, you can probably find a blog post somewhere where someone else has figured out a solution. Or if you find a bug in jQuery itself, you can wait for someone else to fix it.

However, if you take the first option, you gain deeper and broader knowledge that can help see things in different ways and to know when jQuery may not be suitable, or will help when the next tool of choice comes along. Hey, you may even be someone who helps build the next great framework or write the blog posts that the other jQuery developers find when they get stuck.

At a high level, it's the same as asking:

• Do you learn a language or an API?
• Do you learn all about how to do a task, or how to use a single tool that can do most of the things related to the task?

Short term, the "smart" answer is to do the simple thing.
Long term, the broader knowledge is, theoretically at least, more useful.

However, when it comes to recruitment, suitability is often measured in terms of the length of time spent using a specific tool.

"Do you have X years of experience using Y product? - If not, you're not suitable."

But then I might have 5X years of experience with multiple products, including Y and competitors/alternatives, plus I'm considered by some to be an expert in the field.
However, recruiters (and their automated CV parsing tools) don't see me as suitably experienced. 

Maybe it's better to only work with quantifiable tools in measurable ways.

But what about AI, as I promised in the title?

I think there's a comparison with the use of AI/LLMs/Copilots/Agents/etc. when helping with coding.

I wanted to do something with a technology I wasn't very familiar with. 
I started by working through the documentation and was learning some things. But, it quickly became apparent that I'd need to spend many hours to get a full understanding of the technology and gain the knowledge to create the best version of the solution I needed.

So, I wondered if GitHub Copilot could do it for me.
I opened the relevant file, selected some relevant lines and asked it how to do it the different/better/shorter/generic way that I wanted. 

It quickly produced an example, and I was able to adjust this to get exactly what I needed. At least to the point where it appears to work.

But here's the catch. I don't know enough to know if this is the "best" way to do what I want. 

• Is "appears to work" good enough?
• Are there alternate solutions?
• What's the difference between the different approaches?
• And the pros and cons of each?
• Are there any edge cases I need to account for that the current code doesn't cover?
• How can I create automated tests for this?
• Can Copilot answer these questions?

Is it acceptable to go with what Copilot gave me? And, if there are issues in the future, to ask Copilot (or future replacement/alternative) how to fix them?

Maybe.

Maybe I'll have to learn more to address any future issues. That's okay, as I know how to learn and have enough wider knowledge and experience to do that.
If all I could do was ask a Copilot how to solve a problem, I might get stuck when the problems get harder.
But, at least I can say I have 2+ years using Copilot to assist my coding...

19 Questions to ask before migrating a Xamarin app to .NET MAUI

I got asked about helping rewrite a "legacy Xamarin-based mobile app to .NET MAUI". They'd already determined how long it would take, but had very few details about the app or the rewrite/migration.

To help anyone else in a similar situation, here are a few questions to ask (and get answered) to determine how much time/effort will be required in such a project.

1. What's driving the rewrite?
2. What's driving the time scale for the rewrite?
3. When was the code written initially?
4. Who has been maintaining and updating the app since it was originally written?
5. What does the existing app do?
6. How is the existing app built?
7. How is the existing app distributed?
8. How is the existing app tested?
9. Does the initial code base use Xamarin.Forms or Xamarin Native?
10. Which platforms (operating systems) does the existing app run on?
11. Does the application have any specific customisation or variation in functionality when running on different devices or operating systems?
12. What programming languages does the existing app use?
13. How large is the existing app?
14. What 3rd party controls or tools does the existing app use?
15. How are 3rd party tools licensed?
16. Do the 3rd party tools have equivalent support for .NET MAUI?
17. What external systems (including back-ends, analytics, etc.) does the existing app connect to?
18. Beyond getting the app to build and run with .NET MAUI, what other changes are planned and/or needed?
19. What are the long-term plans for the app? (Who's going to maintain and update it after this rewrite?)

Obviously, the answers to many of these questions will prompt follow-ups to identify relevant specifics.

What did I miss?

My second rule of testing

For a long time, I've told people that I recommend adding tests for any code that is "non-trivial".

I define non-trivial to mean any code that you can't look at and immediately see all the possible paths through it and potential outputs, such that you can see that all possible negative and edge-case consequences are correctly handled. Yes, the reality is that very little code meets this threshold.

I also make exceptions for plumbing code.

I now have a second rule. Well, guideline:

Include tests for anything that may be affected by a change in a dependency.

This matters because dependencies change and get updated. Without tests to verify that nothing has broken or been altered in unwanted ways, switching to using a new version of a dependency is a bigger risk than it should be or that you probably want to have to deal with.

Oh, that package you use now has a new version that reportedly fixes a security vulnerability. How quickly can you switch to using the new version? Do you trust that there are no other changes or consequences of updating? Can you be sure? Do you have the time to verify manually?

Also note that this applies to both internally and externally sourced dependencies.