Cross-posting from <#C02B3PECK6E|> as I'm not sure...

# multiplatform

[sigmadelta]

Cross-posting from #C02B3PECK6E as I'm not sure where this question belongs:

I currently made a website using the WASM export and it works for all clients, except for iOS below 18.2. This is related to the fact that they only introduced support for WASM GC with their recent os update.

To bypass this there is the option of exporting the whole project in JS, but I would prefer to stay in WASM. Is there somehow an option to detect the browser of the user doesn't support WASM GC and redirect him to a different index.html with an explanation or something?

[hfhbd]

You can always show a html element containing the error and hide it using WASM.

[sigmadelta]

Ah that's quite clever, didn't even consider that scenario.

I'll give it a shot, thanks!

[sigmadelta]

Works like a charm, thanks!

FYI for anyone facing the same:
• Modify your index.html and add a div in the body like <div id="wasmgc_support_1">...
• In your app entry point add the following document.getElementById("wasmgc_support_1")?.remove()
It will show it for a few miliseconds at the start of the page, but it sure beats having clueless users staring at a white page until iOS 18.2 adoption is a bit further

[PHondogo]

Better solution: https://github.com/JetBrains/kotlinconf-app/blob/f7a148eb148376d6b4b7a8f2b10187074c559d46/shared/src/webMain/resources/index.html#L197

[hfhbd]

A user could also disable JS too

[hfhbd]

But checking for all required WASM features is quite clever.

[sigmadelta]

So for the above solution I would have to define the JS target as well so it could use it as a fallback if I understand right?

[hfhbd]

Well, you could but I would just copy the plain JavaScript code to check the WASM features and not use Kotlin JS at all.

[hfhbd]

And then load WASM like in the Kotlin conf sample app. You could still use the html error workaround to show a plain html error message if the user disabled JS and WASM.

[sigmadelta]

Not completely sure I understand how the mechanism works or what the expected result is though.

As I understood it, in this case I would need both the wasmJs build target and the js build target, run their gradle tasks to create the dist outputs and then merge these together I suppose?

But I assume more adaptations in the code are actually required to get this working no?

[hfhbd]

If you really want to support non WASM browsers, you need a Kotlin JS target too, yes. If you just want to show the user a error message, you don’t need Kotlin JS. But if you want to add a Kotlin/JS target, what’s the point having the WASM target?

[sigmadelta]

Right, fair point indeed. Honestly, given the low-prio of the project and the current timeframe of WASM releases I think I'll stick to WASM for now along with the warning. Expect to be able to remove it in a year tops.