Then you have to have two copies of the program, on disk and, at least at times, in memory. And they behave differently, which might be confusing. And all kinds of handoff scenarios and edge cases get potentially-weird.

Meanwhile, how many users would sacrifice any amount of stability or even just disk space to get somewhat-quicker releases of browser features? I'm guessing the percentage may very reasonably be rounded to zero. It's not even close to being urgent enough to be worth any amount of risk or extra resource use, IMO, as someone who conceivably might care about it, and the vast majority of users are even less likely to give a damn than I am.

So: why? Maybe I'm unusual, but it's been a really long time since I saw a new browser feature and was like "holy shit, this is amazing and I don't know how I browsed the web without it!" I can wait a few months for a browser update, it's really not a big deal.

Not only that; Chrome, even when preloaded, is uninstallable like any other app. It's use is not mandatory.

>even when preloaded, is uninstallable like any other app

Most preloaded apps are installed on a read only partition. Since it is read only you can't uninstall it.

You can disable them. System then behaves as if it wasn't there, without having to write into read only partition.

That's what they originally did, and developers complained that in-app browser wasn't getting the same features as the main browser

Make it an option for developers. They should be able choose between an OS-provided "stable" webkit, or the Safari-provided "evergreen" webkit.

You could even make it so that the stable option is automatically used as a fallback if Safari isn't installed, if that ever becomes an option.

or just ship both at the same time so it's nice and simple