.NET MAUI Release Candidate 2 – With 100% More Tizen

David Ortinau

We are excited to release .NET Multi-platform App UI (.NET MAUI) Release Candidate 2. This release is covered by a “go-live” support policy, meaning .NET MAUI is supported by Microsoft for your production apps. The team has been focused on stabilizing the toolkit, resolving the high impact issues you have been helping us to identify through your valuable feedback. Thank you!

Get Started Today

To acquire .NET MAUI RC2 on Windows, install or update Visual Studio 2022 Preview to version 17.2 Preview 5. In the installer, confirm .NET MAUI (preview) is checked under the “Mobile Development with .NET” workload.

To use .NET MAUI RC2 on Mac, follow the command-line instructions on the wiki. Support for .NET MAUI in Visual Studio 2022 for Mac will ship formally in a future preview.

Release Candidate 2 release notes are on GitHub. For additional information about getting started with .NET MAUI, refer to our documentation and the migration tip sheet for a list of changes to adopt when upgrading projects.

Reminder about Xamarin support The Xamarin Support Policy is still in effect, which covers those products for 2 years after initial release. The last release was in November of 2021, so support will continue through November 2023.

Adding Tizen Platform

Tizen.NET has long enabled .NET applications to run on millions of Samsung TVs, phones, and other devices running Tizen. Today, Tizen joins Android, iOS, macOS, and Windows as one of the target platforms you can reach with .NET MAUI. Congratulations to the Samsung Tizen.NET team on this great milestone!

Visit the Tizen .NET introduction to get started. While the platform support is part of .NET MAUI SDK and we’ve added the scaffolding for Tizen to the .NET MAUI template project, the required workload dependencies are distributed through a separate installation experience maintained by Tizen.

Looking for samples? The Tizen team keeps up to date with all our beautiful sample apps to make sure they run great on Tizen mobile and Tizen TV.

The official Tizen Emulator supporting .NET 6 will be released by the Tizen team soon.


Tizen emulator



Tizen TV emulator running WeatherTwentyOne


.NET Podcast

Tizen emulator and browser running dot net podcasts, .NET MAUI Release Candidate 2

Tizen TV emulator running dot net podcasts


Getting the most from platforms

.NET MAUI excels at giving you the same UI and styling for native controls across all supported platforms, while also giving you broad access to native platform features all from a single .NET language. .NET does this by taking full advantage of multi-targeting to organize code and resources that may span several platforms from a single project.

There may also be scenarios in your applications where you’ll want to customize how it looks and behaves on a specific platform in order to take full advantage of native features only present on that platform, or to unify an experience to be more consistent with other platforms. There are 3 main ways in which you can do this in .NET MAUI:

1. Platform folders

Within the single project structure, we’ve paved the way for you to put platform-specific code and files into folders by platform. The build tasks for .NET MAUI are pre-configured to know that anything you place there will apply only to that platform.

Solution shows platform folders, .NET MAUI Release Candidate 2

2. Filename convention

The .NET MAUI build tasks will also look at filename conventions to determine what code should run for each platform. The source code is actually setup this way as well. The Button handlers suffix the filenames by platform: Android, iOS, Tizen, and Windows.

Button handler files by platform

3. Conditional compilation

Multi-targeting also works via conditional compilation arguments. By using #if, you can segment code per platform from anywhere in your project. For example, in the WeatherTwentyOne app’s MauiProgram.cs, we configure services for local notifications and the system tray, which are very platform-specific APIs.

    var services = builder.Services;
    services.AddSingleton<ITrayService, WinUI.TrayService>();
    services.AddSingleton<INotificationService, WinUI.NotificationService>();
    services.AddSingleton<ITrayService, MacCatalyst.TrayService>();
    services.AddSingleton<INotificationService, MacCatalyst.NotificationService>();

By default, the following options are available to you:

  • IOS

You’ll notice IntelliSense will additionally offer you more specific options to target each platform such as “WINDOWS10_0_17763_0_OR_GREATER” in case you need it.

For additional information on writing platform-specific code, check out the .NET MAUI documentation:

.NET MAUI provides other helpful strategies for adapting your applications to different platforms, screen sizes, idioms, and more. For example, you can leverage these markup extensions and strategies:

  • OnPlatformWidthRequest="{OnPlatform 250, iOS=200, Android=300}"
  • OnIdiomWidthRequest="{OnIdiom 100, Phone=200, Tablet=300, Desktop=400}"
  • Triggers – Property, Data, Event, Multi-triggers, EnterActions, ExitActions, and State

We need your feedback

Install the latest preview of Visual Studio 2022 for Windows (17.2 Preview 5) following our simple guide and build your first multi-platform application today.

We’d love to hear from you! As you encounter any issues, file a report on GitHub at dotnet/maui.


Discussion is closed. Login to edit/delete existing comments.

  • Joren Thijs 0

    Hi David!

    I tried out the RC2 preview earlier tonight without realizing it😅
    Everything compiled and deployed to my Samsung Android phone without issue so that was nice. Also props on the Xaml hot reload it was super fun to play with👍
    Excited to see Tizen support brought in from the Tizen team, let’s hope we get Linux next!

    Some ‹Notes› from a Maui and Xamarin noob:
    Shell is the default template now but maybe add a code example to the documentation to show how to get such a nice result with a picture up top like is seen in the documentation.
    Also shell is supposed to make flyouts super simple but by default that behaviour is disabled in the templates and it took me 15 minutes to spot that FlyoutBehaviour property and get it working. Maybe update the docs or templates? Even after that my flyout items kept appearing as both flyout items in the menu and bottom tabs for some reason…

    About debugging:
    I then tried to make a label read out the Battery charge level. When navigating to that page my app crashed throwhing a runtime invocation exception. This error was not helpfull and VS didn’t even show me at what line in .NET the error occurd. Luckily i watched some of James M and Gerald V videos on MAUI and quickly figured out that I needed to add a missing Android permission to the manifest. Still this debugging experience is not great. And has clearly not improved from when I was forced to make a Xamarin Forms 4.8 app in college. Are there any concrete plans to improve this behaviour? In this aspect it still feels like in the Xamarin days where you pass a wrong property to some library function and everything crashes without telling you what you did wrong.

    To continue on the debugging topic. As a Web developer BlazorHybrid is the most appealing app type to me and my team, but the Blazor debugging experience is also not great? During one of the last previews if i wanted to know what my exceptions where I had to run the windows version of my app and then I had to open the edge dev tools to look at the browser console where errors from Blazor appeared? Is there any way to debug it like a normal Blazor wasm app where an exception is thrown and VS shows me the linebreak and the exception? (if this is already fixed my appologies I did not have time to test it yet with RC2)

    And like always a request for better tooling/debugging support in VS code en the dotnet cli. I liked MAUI-check, it’s a copy of flutter doctor but thats okay, maintaining a mobile dev toolchain is complicated and sometimes stuff breaks. i hope good tools like MAUI-check can continue so people don’t have to be dependent on VS. No hate against it i just want developers who use linux to feel welcome too.


    Not to take away from the impressive work accomplished by the team, I’m excited for the future of MAUI and .NET. Keep up the great work!

  • Juri Ryazanov 0

    I can’t even create new MAUI project because MAUI templates never show up in Visual Studio if I have both MAUI and any .NET 7 SDK preview installed…

  • John King 0

    Xaml is really old and use reflaction, and no real AOT (Baml is still a document), with todays frontend framework like Angular ,Vue they both provide a template engine that design for AOT(no document when app run, pure js code to manipulte DOM ) , and both of them provide for loop in template engine , and theire binding syntax is way simple than XAML, and formating use concept like Angular's Pipe Vue's Filter are way easier to understand and way easier to implement.

    Can the MS redesign a new template engine base on the concept of Angular's lvy template engine

    • David OrtinauMicrosoft employee 0

      .NET MAUI uses XAML compilation and supports publishing with AOT. https://docs.microsoft.com/en-us/dotnet/maui/xaml/xamlc That plus with compiled bindings I’m not sure you’ll be using any reflection.

      Have you tried Angular for UI in a WebView with .NET MAUI, or better yet Blazor?

      • Charles Roddie 0

        MAUI supports AOT publishing with Android and iOS definitely.

        For Windows I am not sure but I think it doesn’t. It depends on the WinUI version. I find the single project hard to read and understand so I can’t find a template in the MAUI repo indicating what version it uses. There are references to UWP in the codebase (“#if WINDOWS_UWP || WINDOWS”) but not sure if those are current or historic code.

        If MAUI uses WinUI 3 then it doesn’t have AOT compatibility and if it uses WinUI 2 then it should do (since that is UWP compatible).

        Trying to figure this out now as it affects whether we can update.

    • Yi Wang 0

      Compile template code to JS? You call this AOT? LoLLLLLL-)))))))

      • Ian Marteens 0

        Agree. Most funny thing read in this blog for a while.

      • John King 0

        lvy’s concept is not JS, it the Pipe TemplateOutlet OneWayBindingSystax TwoWayBindingSystax EventBindSystax DI RoutingSystem ReactiveServer(base on rxjs) and template control flow like For and If

        and what Xaml have ? Binding Systax + static extension property ? just think about how you’ll implement the follow lvy template in Xaml

        <div  *ngIf="list.length > 0;else empty">
            <div *ngFor="let item of list">
                <span>HI: {{item.name?.toUpperCase()}} </span>
                <span *ngIf="item.isRecommand">Recommand</span>
        <ng-template #empty>

        The Xaml’s Binding concept is cool in 10 years ago, but now is old because it’s not been improve since it’s born!

        and if you rethink that lvy template there are nothing you can not implement in C# , because lvy is strong type in mind!

        • Souleymane Ba 0

          Yes, XAML was cool 10 years ago and I thought it was still cool (despite being very verbose) until I discovered the razor syntax with Blazor.

          • John King 0

            razor is learnning from react, and it’s bad to “extend” , because you are using the C# for if , and unlike angular’s lvy template , the For is ForDirective + Template , that’s means you can do more in the `ForDirective` for example take advantage of ObserableType , but blazor use C# ‘s `For` and `if` , that’s means you can not take advantage of ObserableType, or you can but only with deep intergrated to the razor compiler.

            with all those templete I learned, Xaml can only be raplaced by the angular’s lvy Template syntax,

            • Xaml oneway bind => lvy property bind [prop]="value"
            • Xaml twoway bind => lvy two way bind property [(prop)]=value
            • Xaml event => lvy event (click)="event"
            • Xaml Template Concept => <ngTemplate />
            • Xaml extension property => angular derective <control [MyDerective] />
  • Virchar Bautista 0

    RC1 and RC2 crashes on release Signed apk but debugging mode working.

    • David OrtinauMicrosoft employee 0

      Check your error logs for a missing permission or anything else. If that doesn’t resolve it, please file an issue for us on GitHub.

  • Brown, Stephen 0


    This is great work but we are still having lots of issues with Hot Reload for both MAUI and MAUI Blazor:

    • MAUI hot reload refuses to work for any code changes to C#.
    • MAUI Blazor Hot Reload does not work at all and crashes with Roslyn compiler errors.

    MAUI itself is great but it is concerning that the VS tooling is lagging behind which makes using and recommending MAUI in the release candidate stage very difficult. We are hoping to adopt MAUI for a large project with Blazor and we are a bit worried that the tooling is not going to be in place or at a usable level from day 1. Can you confirm these issues will be ironed out and that the developer experience/inner loop is the highest priority now ahead of GA?

    Again, great work on MAUI and don’t want to detract what looks like a fantastic technology.


    • Carlos León 0


      The same happens to me.

      I really appreciate the work they have done. But trying other technologies I think they are one or two steps behind. The effort to keep Visual Studio as the best option (almost the only one) works against the adoption of MAUI. Hot Reload does not work. Sometimes it seems so, but it doesn’t work well. Even in Blazor Server projects, which are the simplest, just moving bits of Razor code forces you to rebuild some times.

      In any case, I still trust Microsoft and the team, and I hope that in the future all these problems will disappear.

      • David OrtinauMicrosoft employee 0

        Thanks for the feedback. There is a progression of things that’ll happen here as we go GA, and the tip of the spear is stabilizing the SDK so that we can enable libraries and other dependencies to also GA. Visual Studio features are coming along at their own pace and timeline that will at times necessarily differ from the SDK timeline. We appreciate your patience as we bring the entire developer experience forward through this process.

      • Daniel RothMicrosoft employee 0

        Hi Stephen, Carlos. I’ll just add that Hot Reload for .NET MAUI and .NET MAUI Blazor apps is being worked on and we expect to make it available shortly in an upcoming Visual Studio preview. We are also working on broadly improving the capabilities of Hot Reload for all types of apps in .NET 7. If there are specific types of edits that are not supported by Hot Reload today that you find particularly frustrating, please submit that feedback through the Visual Studio feedback tool so that we can make sure it is getting addressed. Thanks!

  • Jura B 0

    Hi David,
    I have asked several times and unfortunately have not received an answer.

    How can I launch iOS and Android simultaneously with .NET MAUI like it was possible with Xamarin Forms.

    When programming in XAML, it makes sense to see both platforms.

    Otherwise I think MAUI would be great if Visual Studio would play along

    thanks for the work

    • David OrtinauMicrosoft employee 0

      I agree, this is a scenario we want to see for .NET MAUI. It is not something the multi-targeted project supports yet, so it’s on the backlog.

      When using .NET MAUI with multiple app projects like in Xamarin.Forms, you should have the same multi-project startup options. If you find that it’s working please file a Visual Studio feedback ticket from the Help menu.

  • younky yang 0

    why do I still get preview14 when following the instruction for Mac?

    • Dean FaizalMicrosoft employee 0

      Did you install .net 6.0.300? dotnet installers

      • David OrtinauMicrosoft employee 0

        Yes, make sure to get the latest versions and check the install command for any versioning to reflect what you are asking it to install. As Dean says, it all begins with getting the right installer that provides the .NET MAUI workload.

        • younky yang 0

          It is intresting, only from the readme.md I can get the 6.0.300 version, no matter from dotnet.microsoft.com or github release page, I just saw 6.0.2xx.

          • Matt Johnson-Pint 0

            @David – This really needs to be the first thing in the prerequisites section of the macOS install wiki. MAUI RC1 and RC2 requires .NET SDK 6.0.300, which is not released yet – still only available from the daily builds, not the regular .NET 6.0 downloads page. Installing it breaks other things, so I can only play with MAUI superficially. I have to uninstall the daily SDK after every use to get back to normal work. This will be a non-issue once 6.0.300 SDK is released, but I see no roadmap for that.

  • Martin Rothschink 0

    Hi David,

    noticed that ScrollView is no longer working on Android with RC2. Has anybody else noticed this?

    • David OrtinauMicrosoft employee 0

      Yes, there are issues filed related to ScrollView on Android, and I too see it’s not scrolling in certain situations. Look for it to be resolved soon!

  • Enrique Morell 0

    The migration tip sheet link is broken. It redirects to the Github but not to the migration tip sheet. Thanks!

  • Steve 0

    It’s RC2 and I can’t get the iOS tooling to work 🙁
    Please prioritise iOS tooling on Mac above all else.
    None of the other stuff matters if you can’t build your app.

    • David OrtinauMicrosoft employee 0

      If you are having trouble with building via command line, please open an issue for us on GitHub.

      • Steve 0

        Given the number of issues people are experiencing the real problem seems to be lack of basic workflow testing prior to releases, that’s the single biggest change that would improve peoples MAUI experience.

Feedback usabilla icon