Projects created with Xamarin Forms

[developersimsek]

Hi,

There are multiple projects I created with Xamarin.Forms and published in Google Play and App Store. Will these projects be automatically updated to Maui? Or is it necessary to create a new project for Maui from the beginning? I could not find any information on this subject in any source. So I wanted to ask. I would be glad if you can answer. (Hopefully there will be an automatic update.)

Thanks,
Good work...

[davidortinau]

There will be a migration path. For sure Xamarin.Forms apps will need to:

• update namespaces from Xamarin.Forms to System.Maui (find/replace)
• convert from existing csproj to SDK Style
• update NuGets to those supporting .NET 6
• adopt breaking changes - the proposed changes are things like changing MinWidthRequest to MinWidth and enforcing the behavior.

I'll update the FAQs with this.

Beyond that there are other possible changes such as #43 which proposes broader breaking changes to the XAML implementation and object model to conform to desktop variations. Please engage on those issues and let us know the value and impact to your applications and business. Changes such as these would likely require your manual conversion of code.

[Chiramisu]

I'll take a wild guess that this is the FAQ you updated? 😉

Will my Xamarin.Forms projects automatically update to .NET MAUI?

[developersimsek]

There will be a migration path. For sure Xamarin.Forms apps will need to:

• update namespaces from Xamarin.Forms to System.Maui (find/replace)
• convert from existing csproj to SDK Style
• update NuGets to those supporting .NET 6
• adopt breaking changes - the proposed changes are things like changing MinWidthRequest to MinWidth and enforcing the behavior.

I'll update the FAQs with this.

Beyond that there are other possible changes such as #43 which proposes broader breaking changes to the XAML implementation and object model to conform to desktop variations. Please engage on those issues and let us know the value and impact to your applications and business. Changes such as these would likely require your manual conversion of code.

Thanks for the answer. In the future, I think there will be a document on how to upgrade Xamarin.Forms projects to Maui. However, it should be noted that I think the transactions you give as examples should be done automatically. In other words, if an update obligation is required, this should include minimum manual changes by the user.

[davidortinau]

Thanks @developersimsek. Yes, we'll provide documentation.

Can you elaborate on what you would consider to be minimal?

Can you describe of a previous experience where an update exceeded your threshold, where the effort was greater than the value?

[developersimsek]

Thanks @developersimsek. Yes, we'll provide documentation.

Can you elaborate on what you would consider to be minimal?

Can you describe of a previous experience where an update exceeded your threshold, where the effort was greater than the value?

First of all, your examples;

• A manual workload such as update (find / replace) find and replace namespaces from Xamarin.Forms to System.Maui should not be left to the user.
• adopting breakage changes - proposed changes are things like changing the MinWidthRequest value to MinWidth and applying the behavior. Find / replace operation in the same way.
  Such workloading operations should be avoided.

As an example, even now I am having problems with Xamarin.Forms AndroidX upgrade. I think it is probably one of the nuget packages used. #4856 I can't imagine they'll be in a specific update like Maui, not AndroidX.

[J-Swift]

@davidortinau you didn't ask me but this seems like the best place to through a couple cents into the discussion : )

For me personally when evaluating the migration, I think about the process in a few ways:

1. How urgent is the upgrade requirement? Since Xamarin.Forms is effectively being EOL'ed and Maui being blessed as the Path Forward, the urgency is pretty high. In terms of risk management across multiple professional projects, I dont want to be caught in a situation where Maui has gone live, but I am on Xamarin.Forms and have a critical bug that needs addressed. This means I need to take action sooner rather than later.

2. How gradual can I perform the upgrade? Is it a big bang of all 4 of your bullet points all at once? Can I address each bullet over time while still technically being Xamarin.Forms before completing a final process to cutover? Again, for risk management, it will significantly cut down on friction if I can attack things over time as I have bandwidth.

3. Am I losing anything by migrating? e.g. will I lose access to 3rd party libraries because they "arent compatible"? This scenario is a good example of when cost to migrate can exceed the value. It also means that if the transition is not low friction, then 3rd parties will be less likely to be updated in a timely manner. I think the current nullable reference types effort could be a good proxy for how this might play out.

A couple thoughts on what can improve the developer experience when coming up to migration time:

• Linters/analyzers to aid in pre-migration code updates. e.g. for the MinWidthRequest situation you described. I would also include in this bullet some sort of namespace redirecting tool similar to jetifier.
• Provide clear documentation on the different aspects and process of the migration, as well as very clear, centralized places to get information. There are a couple great examples from the angular community for these.
  -- ngUpgrade (https://angular.io/guide/upgrade) is a really pragmatic tool to move from the old version of the framework to the modern version.
  -- This github issue was a great way to understand and follow along with efforts to significantly modify the underlying build tooling
• Dont attack everything at once. I love to see all the issues/enhancements in this repo, but if you can minimize the changes for Maui v1.0, then its much easier to have that release be the foothold people use to get into the new ecosystem before phasing out in a future major version of Maui any Xamarin.Forms crutches that were brought along for the ride.

EDIT: I forgot to highlight that AngularJs had a really good strategy of adding some of the new features into the old framework (rather than bringing over the legacy stuff into the new system), which meant you could adopt some of the new patterns early in the old system before migrating. Again, this makes the migration much more digestible, and also doesnt force you to dirty up the greenfield effort with legacy considerations.

[knocte]

How urgent is the upgrade requirement? Since Xamarin.Forms is effectively being EOL'ed and Maui being blessed as the Path Forward, the urgency is pretty high. In terms of risk management across multiple professional projects, I dont want to be caught in a situation where Maui has gone live, but I am on Xamarin.Forms and have a critical bug that needs addressed.

This reasoning seems backwards to me, given that Xamarin.Forms would still receive bugfixes. In fact, in a scenario in which Maui is the only one that gets new features and Xamarin.Forms is considered feature complete (and therefore only receives bugfixes), staying on Xamarin.Forms is less risky because there's less chances of regressions.

[bmacombe]

Right now there is only 1 year of planned bug fixes for XF post-MAUI release, so it will be necessary to port to MAUI after it's initial release.

At least to start considering porting in that 1 year window.

[J-Swift]

This reasoning seems backwards to me, given that Xamarin.Forms would still receive bugfixes. In fact, in a scenario in which Maui is the only one that gets new features and Xamarin.Forms is considered feature complete (and therefore only receives bugfixes), staying on Xamarin.Forms is less risky because there's less chances of regressions.

As @bmacombe said, the bugfix support is only temporary. Further, in no way will Xamarin.Forms ever be 'feature complete'. The best you can hope for is "feature complete as of this point in time". The underlying platforms will never stop changing, so there will always be maintenance required to keep up on the framework side. Thats not even considering the current 2.4k open issues and 144 open PRs in the Xamarin.Forms repo (not hating/judging the maintainers, just illustrating).

[davidortinau]

staying on Xamarin.Forms is less risky because there's less chances of regressions.

@knocte yep, I totally get that. You can ride that train as long as you like. As Xcode/iOS and Android versions evolve that require publishing with their latest versions, that'll perhaps be the first forcing function to migrate to .NET MAUI.

We'll do everything to make the transition smooth and painless whenever your project is ready.

[knocte]

the bugfix support is only temporary.

1 year, plus, considering the first (non-preview) release of MAUI is kinda far in the future, I think there's plenty of time to stay in a stable XF.

in no way will Xamarin.Forms ever be 'feature complete'

You know that no new features will land in XF right? (See xamarin/Xamarin.Forms@a603efd.) Therefore, feature-complete is the correct term.

Thats not even considering the current 2.4k open issues

That includes bugs. Bugs being fixed doesn't change "feature-completeness".

We'll do everything to make the transition smooth and painless whenever your project is ready.

Sounds great. Just voicing my opinion that comes from a very conservative point of view, given all the regressions I have faced in the past.