Blazor Hybrid not working on MacOS 15.0 [Potential fix]

[veler]

Description

Hi,

I believe I found that Blazor Hybrid does not work at all on MacOS 15.0 Beta (Sequoia).

For context, I'm the author of DevToys, which is not a MAUI app, but a AppKit app made in C#, and it use a fork of .NET MAUI's BlazorWebView to work. The app has 300k users on Windows and about 40k on MacOS.

A customer reported that on MacOS 15.0, the app is blank. I do reproduce the issue, and out of curiosity, I tried a new MAUI Blazor Hybrid app to see if the issue reproduces too, and it does, hence my ticket here.

The issue is very easy to reproduce.

Steps to Reproduce

1. Make sure to run MacOS Sequoia (15.0 Beta)
2. From VS Code's .NET Maui extension > Create a new .NET MAUI Blazor Hybrid App.
3. Build and Run on MacOS (desktop).

Expectation:
A nice Blazor Hybrid app running

Actual:
A bank page

Early Investigation:
It seems like the web browser does not find Blazor. It also seems like the page is about:blank instead of wwwroot/index.html. It seems like somehow BlazorWebView fails to navigate to index.html from app://0.0.0.0.

Link to public reproduction project repository

https://github.com/DevToys-app/DevToys

Version with bug

8.0.61 SR6.1

Is this a regression from previous behavior?

No, this is something new

Last version that worked well

Unknown/Other

Affected platforms

macOS, I was not able test on other platforms

Affected platform versions

MacOS 15 Beta (Sequoia)

Did you find any workaround?

Not yet. Will post an update if I find one.

Relevant log output

No response

[github-actions]

Hi I'm an AI powered bot that finds similar issues based off the issue title.

Please view the issues below to see if they solve your problem, and if the issue describes your problem please consider closing this one and thumbs upping the other issue to help us prioritize it. Thank you!

Closed similar issues:

• Blazor Hybrid is not supported on Macs running MacOS 11. (#19613), similarity score: 0.81
• [macOS] [8.0] Hybrid app crashed after launch on macOS 12.4 (#19904), similarity score: 0.78
• MAUI Blazor app crashes during startup on MacBook M1 (#20426), similarity score: 0.77
• Maui BlazorWebView MacOS issues (#10843), similarity score: 0.77
• Maui-Blazor (Hybrid) MacCatalyst app will not run on older MacOS (#19808), similarity score: 0.76

Note: You can give me feedback by thumbs upping or thumbs downing this comment.

[veler]

Further Investigation

Continuing my investigation on DevToys side, I found that StartUrlSchemeTask is never invoked.

A Potential Solution for DevToys and .NET MAUI

After some time, I kind of dumbly decided to change the app host address from 0.0.0.0 to localhost, "just in case", and it worked!

I suspect a fix for MAUI is similar. Please try changing this line to app://localhost/ to see if it works.

https://github.com/dotnet/maui/blob/2a9f9fd1980d521d1a36f72febc5ad9f94dc706e/src/BlazorWebView/src/Maui/iOS/BlazorWebViewHandler.iOS.cs#L26C3-L26C83

Consideration

Now I'm concerned with the retro compatibility with older MacOS version. I will try getting out of MacOS 15 Beta and test on MacOS 14.

While my problem is fixed, .NET MAUI Blazor Hybrid still doesn't work at all on MacOS 15, so I will leave this issue open for now and will let you decide what to do with it :-)

[marcusbooyah]

I am seeing the same using MAUI blazor on iOS 18 beta 2 as well.

[Bl4d3s]

We experience the same issue with iOS 18 Beta 2 as well (was working on Beta 1).

A workaround is to set the base url using reflecting as first action in the MauiProgram.cs

var handlerType = typeof(BlazorWebViewHandler);
var field = handlerType.GetField("AppOriginUri", BindingFlags.Static | BindingFlags.NonPublic) ?? throw new Exception("AppOriginUri field not found");
field.SetValue(null, new Uri("app://localhost/"));

Then the app works like before, so I can confirm the above workaround works with Maui Blazor as well.

[jfversluis]

FYI @Eilon @mkArtakMSFT we probably want to fix this before Sept!

[nor0x]

can confirm that this is also an issue on iOS 18 Beta 2

I will test the workaround now

[MarkWalter94]

We experience the same issue with iOS 18 Beta 2 as well (was working on Beta 1).

A workaround is to set the base url using reflecting as first action in the MauiProgram.cs

var handlerType = typeof(BlazorWebViewHandler);
var field = handlerType.GetField("AppOriginUri", BindingFlags.Static | BindingFlags.NonPublic) ?? throw new Exception("AppOriginUri field not found");
field.SetValue(null, new Uri("app://localhost/"));

Then the app works like before, so I can confirm the above workaround works with Maui Blazor as well.

Workaround works on macos 15 sequoia maui blazor hybrid, saved my life, i was going to format the mac and revert to sonoma

[Bl4d3s]

While investigating further, we noticed some strange behavior when fetching data via JavaScript.
These requests do not seem to work.

One possible cause could be that the check in the following method now is never true, as we cannot change the const BlazorWebView.AppHostAddress which is used.

To my understanding this check, redirects the request back to the app basically.

WebView Check

Thus, the proposed workaround is not really working anymore :/
@jfversluis A fix is now strictly required imho.

We tested with localhost on both iOS 17 and 18 devices, and besides the above issue had no other problems.

[Nijnhoofd]

Hello there,

I'm experiencing the same of behaviour in my NET8.0-iOS app running on iOS 18.3 Beta. The app crashes on launch while showing the splashscreen. In the stacktrace of the crash no leads are to be found. Did someone experience the same thing? The solution described above isn't applicable for my app unfortunately.

[Eilon]

Alright I'm like this --> <-- close to getting macOS 15 Beta installed on my Mac. Thank you for all the investigations and feedback. Hopefully this is an easy fix!

[Eilon]

Alright all it took was getting a different Mac and downloading 40GB of updates 😁 But I can repro this on my Mac on iOS 18 Simulator - the BlazorWebView just doesn't show up at all.

I'll confirm that the suggested workaround works as a start.

But then we'll need to make sure we have a solution that works on both iOS 17 and older, but also iOS 18 and newer, and the respective MacCatalyst versions (for running on macOS desktop).

[Eilon]

[veler]

Thanks @Eilon ! For what it worth, on MacOs at least, I released an update of DevToys with my own fix and so far, customers are happy.

[Eilon]

I've got a PR here that I think should fix the issue: #23906

[Eilon]

Thank you again to everyone for the reports, investigations, and the tip on how to fix it! The PR was merged so this will be available in the next .NET MAUI 8 service release, and also will be ported to the .NET MAUI 9 branches.

As an aside, if anyone can find docs from Apple on this change of behavior I'd love to learn more. I couldn't find any release notes or info from Apple about changes to the iOS/MacCatalyst WebView that are relevant to this (I found other notes, but nothing about this). We'd love to catch these types of things by reading release notes as opposed to finding out after it's already not working.

[Yu-Core]

I saw this article, maybe it's helpful

https://www.oligo.security/blog/0-0-0-0-day-exploiting-localhost-apis-from-the-browser

WebKit/WebKit#29592

[Kebechet]

@Eilon even after updating to maui 8.0.80 my Blazor hybrid app still experiences this problem.
iPhone with iOS 18.0 beta 5 still shows empty screen

[Eilon]

I saw this article, maybe it's helpful

https://www.oligo.security/blog/0-0-0-0-day-exploiting-localhost-apis-from-the-browser

WebKit/WebKit#29592

Wow fascinating! Perhaps we should do an even broader fix for the next patch because it sounds like maybe this could affect all platforms in the future?

[Eilon]

@Eilon even after updating to maui 8.0.80 my Blazor hybrid app still experiences this problem. iPhone with iOS 18.0 beta 5 still shows empty screen

Hmm I checked that release and it seems to have the fix in it.

Some questions/ideas:

1. Did you accidentally also set the AppSwitch? It must not be set - it's only there to undo the patch in case it breaks someone.
2. Did you try on physical iOS device, or Simulator, or both? If not both, can you try on both?
3. Can your app run on macOS/MacCatalyst? If so, does the issue happen there?
4. Can you try uninstalling and re-installing the app on the device?
5. Did you do a git clean -xdf (delete all untracked files in your repo - or whatever equivalent command), and then do a clean build after upgrading the package?

Hopefully we can figure this out!

[Kebechet]

This was the only change I did. And the release was done through github actions, so no old artifacts should be in the new build.
But after running the pipeline 2nd time, uninstalling the old version and installing the new one it finally works.

Thanks you for your help!

[Eilon]

This was the only change I did. And the release was done through github actions, so no old artifacts should be in the new build. But after running the pipeline 2nd time, uninstalling the old version and installing the new one it finally works.

Thanks you for your help!

Thanks for confirming you got it working! That's definitely odd.

@Kebechet if you or anyone else sees this again please let me know!

If you do still have the 'broken' IPK (or whatever file it was), it could be interesting to look inside it to see which DLLs made it into the package and see what version they are stamped with.

[sdonoghue76]

I am also having this same error on my maui/blazor hybrid app. It sounds like the maui worklaod 8.0.80 may have the correct fix. However, my system is not updating past: maui 8.0.61/8.0.100 SDK 8.0.300
I am running macOS.
Is there troubleshooting around how to update to this 8.0.80 version?

[Eilon]

I am also having this same error on my maui/blazor hybrid app. It sounds like the maui worklaod 8.0.80 may have the correct fix. However, my system is not updating past: maui 8.0.61/8.0.100 SDK 8.0.300 I am running macOS. Is there troubleshooting around how to update to this 8.0.80 version?

@sdonoghue76 can you try manually updating the reference in your app's CSPROJ file from:

        <PackageReference Include="Microsoft.AspNetCore.Components.WebView.Maui" Version="$(MauiVersion)" />

To:

        <PackageReference Include="Microsoft.AspNetCore.Components.WebView.Maui" Version="8.0.80" />

And see if that updates the version in the app?

[sdonoghue76]

I am also having this same error on my maui/blazor hybrid app. It sounds like the maui worklaod 8.0.80 may have the correct fix. However, my system is not updating past: maui 8.0.61/8.0.100 SDK 8.0.300 I am running macOS. Is there troubleshooting around how to update to this 8.0.80 version?

@sdonoghue76 can you try manually updating the reference in your app's CSPROJ file from:

        <PackageReference Include="Microsoft.AspNetCore.Components.WebView.Maui" Version="$(MauiVersion)" />

To:

        <PackageReference Include="Microsoft.AspNetCore.Components.WebView.Maui" Version="8.0.80" />

And see if that updates the version in the app?

Thank you @Eilon .
That app is now running correctly on iOS 18 with this change.
I can just revert back to $(MauiVersion) parameters when 8.0.80 workload is associated.

Thanks again.

[nwestfall]

I saw this article, maybe it's helpful
https://www.oligo.security/blog/0-0-0-0-day-exploiting-localhost-apis-from-the-browser
WebKit/WebKit#29592

Wow fascinating! Perhaps we should do an even broader fix for the next patch because it sounds like maybe this could affect all platforms in the future?

I would agree that a patch to change the default to localhost, or at least opt in to only use localhost across all versions would be good. It sounds like Chrome is starting to roll out with the same change and I'd feel safer if there was a Maui version ready to go giving us the ability to switch away from 0.0.0.0. At the very least to give devs the option, can ther ebe a AppSwitch to go the other way? (Force localhost instead of always 0.0.0.0)

Edit: Further, it appears to already be in the dev channel for Chrome on Android - https://chromestatus.com/feature/5106143060033536

[Eilon]

I saw this article, maybe it's helpful
https://www.oligo.security/blog/0-0-0-0-day-exploiting-localhost-apis-from-the-browser
WebKit/WebKit#29592

Wow fascinating! Perhaps we should do an even broader fix for the next patch because it sounds like maybe this could affect all platforms in the future?

I would agree that a patch to change the default to localhost, or at least opt in to only use localhost across all versions would be good. It sounds like Chrome is starting to roll out with the same change and I'd feel safer if there was a Maui version ready to go giving us the ability to switch away from 0.0.0.0. At the very least to give devs the option, can ther ebe a AppSwitch to go the other way? (Force localhost instead of always 0.0.0.0)

Edit: Further, it appears to already be in the dev channel for Chrome on Android - https://chromestatus.com/feature/5106143060033536

@nwestfall very good point, I logged #24363 to track that work. Please comment on the other issue if you have thoughts on various proposals.

[sonali-vaghela]

This works for MAC. Do you know any similar work around for Windows as well?

[Eilon]

This works for MAC. Do you know any similar work around for Windows as well?

I'm not aware of any current issue like this for Windows. This bug was specific to iOS and Mac due to a change made by Apple for those operating systems. If you're experiencing an issue on Windows it is likely unrelated, so please file a new issue with detailed information so that we can investigate. Thanks!

[sonali-vaghela]

There is no such issue regarding this in the windows I am facing.
But as it is going to stop 0.0.0.0 later on windows as well, for the safer side of application point of view I want to change it for windows as well.
So looking for the same way to change app hostname for the windows. So my application will work same way for both windows and MAC.
Based on this hostname, we have also some license agreements. So wants to make it common for both MAC and Windows.

[Eilon]

For BlazorWebView we patched .NET 8 and have the fix in for .NET 9 to use the address 0.0.0.1, which we confirmed works on all supported platforms: #24884

So it's the same address on all platforms going forwards. (There's an optional switch you can use to use the legacy 0.0.0.0 address, but that of course doesn't work anymore on certain platforms, and might eventually stop working on all platforms.)

In the future we're considering enabling using a custom address.

[gerneio]

@Eilon do you know if we will get the latest fix (using 0.0.0.1 on all platforms) in a .net 8 release? I know we have the first fix attempt already in 8.0.82+ (just 0.0.0.0 when targeting ios 18), but would like to go ahead and set up our other platforms for success in a .net 8 release (w/o waiting .net 9 in a month).

[Eilon]

@gerneio yes the fix will be in a patch for all platforms in .NET 8 to make everything consistent, and the same code will be in .NET 9 as well.

[sonali-vaghela]

@Eilon Yes. It is available in .Net 8.
As my application is currently running in .Net 6. We do not have any plan currently to upgrade it to .Net8.
Do you think is there any way possible to do this in .Net 6 without upgradation?

[Eilon]

@Eilon Yes. It is available in .Net 8. As my application is currently running in .Net 6. We do not have any plan currently to upgrade it to .Net8. Do you think is there any way possible to do this in .Net 6 without upgradation?

.NET MAUI 6 is no longer supported so there are no more patches for it available. The only current supported version is .NET MAUI 8, and then soon .NET MAUI 9 when it comes out later this year.