Blank Page in ios when in release mode

[dMiracleMan]

I don't know if this is something related to mobile binding but here it goes just in case somebody has seen it.

We currently have an app build with blazor, we ported it using the mobile bindings to phone. The app is working great, but in debug mode. Once we switch to release mode, we get blank pages (some) in an iphone, not in the emulator. Android everything is working.

Anyone seen this?

[Eilon]

Hi @dMiracleMan I haven't seen an issue like that in quite a while. Can you show what your app's startup code looks like in App.cs? Does it look sort of like what's here: https://docs.microsoft.com/en-us/mobile-blazor-bindings/migrate/preview1-to-preview2#update-appcs-to-use-new-host-and-set-mainpage

[arivera12]

@Eilon

There are few issues on iOS platform which I am not sure why this happens but we still were able to fix them.

Me and @dMiracleMan got this fixed and working by doing some refactors to the code.

We spend like a month from time to time trying to get everything running back and compatible with iOS on release mode.

We still don't know if this is a bug from MBB or iOS itself since our original code was working properly in debug and release on iOS emulator, in debug on real device but in release displaying blank on some pages.

Android have been working perfectly with the original code and even with the refactors we did to get iOS up and running.

In conclusion as part of our research for iOS to work properly in a real device in release mode:

• Avoid using type params on classes that will be used as component base class.
• Avoid the virtual keyword.
• Classes and Types must be explicitly typed.
• Use ComponentBase as your base component always and avoid doing custom component base which you may inherit.

Hope this helps anyone if they hit this error and get stuck on this in iOS platform.

[Eilon]

@arivera12 very interesting. I wouldn't have thought that the changes you mention would make much difference. If there's any other info you can share that might help us narrow down the root cause of this. I think that the original problem we had like this had to do with the main page taking too long to start up and because it's async, it wouldn't load in time for iOS to accept it. So that's why the default template sets a temporary main page, and then uses Blazor to load the "real" main page in async, so it's ready whenever it's ready.

[arivera12]

@Eilon I would like to have any info to share but iOS just displays blank with no error message and no crash also.

It's seems like maybe BlazorWebView is crashing but not the main app at all.

The problem it's not when the app starts but it could even throw this error on application start up on the index.razor page.

Try this simple test on iOS in release mode on a real device

[Inject] public virtual IJSRuntime JSRuntime { get; set; }

The page containing this should display blank.

Why this happens? I don't know and I don't get any error message.

We just did what I mentioned above to workaround it and fix it.

[Eilon]

Yes this is quite odd. I can't think of many differences between debug vs. release and also simulator vs. physical device. I don't think there's any code in Mobile Blazor Bindings that cares about these settings/configurations. But it could be some interaction of pre-existing components that is made worse in MBB.

[Eilon]

I'm keeping this issue open because there is presumably some issue here, but I don't have any immediate action planned for this.

[arivera12]

At least I have the fixes there if anyone crash there.

[Eilon]

Yes, thank you @arivera12 , I hope your notes help anyone else who runs into this!

[kngsly]

I ran into this problem and tried the suggestions about 24hrs ago, and still have no idea what caused.

My solution:

1. Create a separate MBB project with the same name as the existing MBB project (when the seperate app is working, you can merge back into your solution without compatibility issues)
2. Test blank/template app
3. If the default works, slowly implement each aspect of your existing (broken) project
4. Test after doing any change, make a good effort to identify what breaks and what works

• I implemented like this wwwroot -> index.html -> mainlayout/globals -> classes/extensions -> helpers -> pages -> app properties/manifest
• By the time I got to implementing pages, I knew the issue isn't page specific or has been solved.

Remember to test as much as possible and across debug/release, it's a lot easier to debug on a blank slate rather than back tracking code changes.