Oh no, I’m pretty sure it’s you who doesn’t understand, seeing as how you don’t quite seem to understand how iOS is structured and in what manner they can fork it, easily.
... and furthermore how renaming it to iPadOS is less of a gimmick than was a necessity at this point... but pointless to continue this, as you’ll continue to not understand.
Cheers.
Not that I’ve already explained most of this or anything, but you argue while failing to rebut. Never mind moving the goalposts — at no point have I argued that they
cannot (or cannot easily) fork iOS. Someone with access to the system’s full source code could do so in a matter of seconds if they felt like it. I’ve said that from an engineering perspective, they
should not (and likely won’t) fork iOS because it just doesn’t make any sense compared to the current approach.
Project forking can work for open-source software, but iOS is not open-source. Fittingly, Apple, as a public corporation with a de facto duty to its shareholders to maximize profit, seeks to develop it as efficiently as reasonably possible. Forking is likely to harm efficiency in software development, especially where much will be shared between the two forks. Why? At least some work that would have needed to be done once must then be done twice, the same way, each time. Setting aside the likelihood for human error in duplicating work, this introduces a paradoxical choice: Hire more engineers, or have your existing engineers reallocate some of their time to repeating their work? Why can’t they just continue what they’re doing — wouldn’t forking it just be “fixing” an approach that’s not broken?
Seriously, good luck presenting
that through the lens of a cost–benefit analysis to the people who’d actually make the call. You’d need to have one hell of a reality distortion field handy to explain why you suddenly need to hire dozens and perhaps hundreds of new engineers to get the same result you’re getting now.
It’s just a shame that you’re not willing to provide any actual reasoning, as I’d love to hear about this secret sauce that makes defying best practices (i.e., implementing UIKit and now SwiftUI twice to mostly do the same things on iOS and a newly independent iPadOS) a good idea for iOS. Guess I’m just too stupid to understand or something.
Cheers.