Great list of the complexity encompassing a proper "GUI" framework. I feel like text / rich text / unicode alone is a huge project (if you include editing, especially of large documents).
However, one thing not mentioned in this list (which I feel is only becoming more important) is that a modern GUI framework also might want to support iPad / iOS / Android.
This complexifies the undertaking by a huge amount as the differences between macOS/win/linux are much smaller than the distance between, say, iOS and macOS. Apple has been going into this direction with SwiftUI where the same code can be run on different systems and behaves differently depending on the platform. However, by doing so, this "common denominator" of all platforms automatically reduces the flexibility of the framework as every "component" needs to be cut wide enough to intelligently behave correctly per platform.
Getting rich text right is a huge undertaking. I spent a lot of time on getting text working really well on a few GUI projects I worked on.
This is the last big GUI/application framework I coauthored. It’s still getting maintained 10 years later. It’s primarily been used for creative applications, but could just as well build cross platform media rich application.
https://github.com/Downstream/ds_cinder
And then there is the question if your GUI framework is even allowed on iOS. For example, Firefox can't use its internal render engine on iOS, but is forced by Apple to use Safari's library.
They can use their internal render engine. What they can't use is their Javascript framework because a modern JIT requires taking compiled javascript code in memory and marking it as executable (e.g. taking any memory page of data and telling the system that this is code now, thus allowing to execute it). This goes against the iOS security mechanism / sandbox because a bug here would allow executing any remote code in the context of the current process.
You can even ship a custom Javascript engine on iOS if you disable JIT, it will just be slow. Or, you do it like iSH (https://ish.app) and implement custom execution via a hard-to-debug genius assembly.
As an exempla, Ejecta is a custom Javascript library for iOS - just without the JIT to make it fast. https://impactjs.com/ejecta
> You can even ship a custom Javascript engine on iOS
Yes but you can't run code downloaded from the internet or supplied by the user. So you are prohibited from building your own browser, even without JIT.
Unless you are Roblox for some reason, then you can run all the downloaded code you want! Sucks to be a Roblox competitor, sorry no running downloaded code for you.
Pro tip for Roblox competitors: Make a product that children really, really like, and make sure some of those children are those of executive leadership at the company you'd like to influence.
You'll get exceptions too, and you don't even have to be a unicorn (Roblox got an exception well before that, after initially getting banned from the App Store).
I am interested to hear more about the history of this exception. Roblox is now a public company worth 40 billion dollars and I believe a large part of that valuation can be attributed to their privileged and protected position in the iOS app store. Did they disclose that in their S-1?
Where do they draw the line for what is "code"? Does HTML/CSS not count? Browsers will take complicated actions based on that downloaded data. Even PDF is up there if you ask me...
> They can use their internal render engine. What they can't use is their Javascript framework because a modern JIT requires taking compiled javascript code in memory and marking it as executable
> You can even ship a custom Javascript engine on iOS if you disable JIT, it will just be slow.
Wouldn't this mean that Mozilla could theoretically ship "real" Firefox (Gecko/XUL/SpiderMonkey) on iOS after the SpiderMonkey wasm port[0][1] lands?
> Instead of working directly on the machine’s memory, the JS engine puts everything—from bytecode to the GCed objects that the bytecode is manipulating—in the Wasm module’s linear memory.[2]
Outside of sideloading, probably not. The rule Apple has isn't "only we use JIT", it's "only we load code".
The lack of third-party JIT entitlements (outside of a debugger entitlement in iOS 14.0 thru 14.2) is downstream of the prohibition on loading code. For the record, "loading code" implies that the code is coming from somewhere other than the current app bundle. Embedded JavaScript, Python, Mono, Flash, or any other interpreters running code that ships with the app are fine. (At one point, Apple actually threatened to ban these. It was concommitent with "Thoughts on Flash".) However, running code by any means from any other location - a third-party server, or even user-selected files - is very much considered malicious behavior by Apple.
The contours of this rule are particularly strange, though. It's not just a pure ban on all third-party apps that interact with third-party code. You're allowed to have third-party browsers. But they have to use Apple's WebView control to get access to a browsing engine. Yes, you can compile a no-JIT build of Gecko, but Apple will never approve it. In fact, Apple goes so far as to even prohibit projecting new web APIs through the WebView interface. (I have no idea how they're going to apply this rule to Safari extensions in iOS 15.)
Of course, Apple also wants to sell iPads as computers, which means that eventually someone is going to want to program on their iPad. This has resulted in quite possibly the strangest rule exception I've ever seen on the App Store. You're allowed to load code if it's code that the user can see and modify. The explanation being that these aren't "code loaders", now they're "learn to code apps". So, e.g. Swift Playgrounds and third-party JavaScript or Python REPLs are perfectly fine. But, of course, all of that has to run at interpreter speed.
Side note: Apple is hilariously inconsistent with this rule, when it comes to emulation. Riley Testut proposed a ROM whitelist on GBA4iOS which App Review said they were OK with, but then changed their mind on by the time it was submitted to the App Store. iSH - an app that emulates x86 Linux binaries - was approved, pulled, appealed, and then re-approved under the "learn to code" exception. iDOS 2 - an app that does the same thing but with DOS apps - was approved, and then pulled with a rejection letter that strongly implicates iSH.
However, one thing not mentioned in this list (which I feel is only becoming more important) is that a modern GUI framework also might want to support iPad / iOS / Android.
This complexifies the undertaking by a huge amount as the differences between macOS/win/linux are much smaller than the distance between, say, iOS and macOS. Apple has been going into this direction with SwiftUI where the same code can be run on different systems and behaves differently depending on the platform. However, by doing so, this "common denominator" of all platforms automatically reduces the flexibility of the framework as every "component" needs to be cut wide enough to intelligently behave correctly per platform.