KCEF is archived, now what?

[parrotcar00]

I see that KCEF developer has now marked that repo as archived: https://github.com/DatL4g/KCEF.
Curious what this means for the jcef choice going forward? Will compose-webview-multiplatform be switching back to jcef or is there any other suggestion or no changes suggested?

[rohan-paudel]

https://github.com/saral-apps/ComposeMultiplatformWebview

I am trying to build native webview .... Tested in mac ... will test tomorrow in windows... Need help for linux

[Sterta]

https://github.com/kdroidFilter/ComposeNativeWebview

ComposeNativeWebView is a Compose Multiplatform WebView whose API design and mobile implementations (Android & iOS) are intentionally derived almost verbatim from KevinnZou/compose-webview-multiplatform.

✅ Android: android.webkit.WebView ✅ iOS: WKWebView ✅ Desktop: Wry (Rust) via UniFFI

[parrotcar00]

@Sterta @rohan-paudel Using system provided webview is great but IMO a compose webview library should make this configurable.
The default can be using system provided webview but if the developer is willing to ship a runtime (like Jetbrains runtime with jcef) then the library should allow that.
This is especially more relevant for desktop targets.

Just my $0.02.

[kdroidFilter]

@parrotcar00 I would have agreed with you if this were a desktop-only library and the goal were to achieve at all costs a similar, bug-free result, even if that meant having a larger bundle. But once it relies on native webviews on Android and iOS, which inevitably have a completely different rendering, I don’t understand why we shouldn’t do the same on desktop as well.

[parrotcar00]

@kdroidFilter I think the behavior of auto downloading the runtime/browser for webview is a bad default.
I have a suspicion that this is a dangerous/risky behavior for apps intended for ios like stores as downloading an entire runtime is quite a big download. Even if not now, in the future the review process might flag that.

We can also look at how existing libraries which have encountered this same problem are handling this? Take Playwright[https://playwright.dev/] for example which need a browser binary to run. It has an explicit install step even before you run your playwright code.
AFAIR it looks something like:

npx install playwright --browser=firefox

IMO a good solution would be to have the following order of choices:

1. Default choice can be the system supplied webview
2. The user can also install a versioned browser just like how playwright handles it
3. The user can make it so that the webview dependency is installed at runtime

[kdroidFilter]

@parrotcar00 I agree with the idea of prioritization, but not with the underlying premise. If you manage your packaging properly, there is no reason why the user should have to download the browser at runtime.