Hacker News Reader

> Don’t get me wrong, iOS is great, and I love it to death. However, the baggage signals to me that a massive opportunity to start anew has been missed.

Starting anew is over rated. It’s sometimes the right answer, sure, but it’s just one possible answer. iOS benefited enormously from being immediately familiar and approachable to existing OSX devs, and would have taken another 5+ years to develop from scratch without leveraging its OSX heritage.

Meanwhile Android was in a crash emergency race to relevance for the first 5 years of its existence. If they’d taken the time to do everything right the first time, they could have ceded Microsoft enough time to get their Windows Mobile act in gear.

So legacy is a thing for a reason, taking one opportunity very often means giving up another.

I think certain paradigms were completely shifted compared to the PC space.

  -Revamped permissions
  -App packaging/name spacing/consistent installation
  -IPC was redesigned as asynchronous Intent blobs on Android
  -Urls becoming first class citizens at the OS level
  -More consistent background app apis (and eventually better ways to track them)

I could come up with more but I think there's actually a very big difference. But yes, its all built on top of older Java and obj-c libs.

SwiftUI isn’t UIKit-specific. Display Postscript hasn’t existed since the OS was called NeXT, 20+ years ago, and was never on any iDevice. Cocoa is an alias for AppKit + CoreData, and iOS uses CocoaTouch instead.

You’re right, yet this doesn’t directly address what parent said, in fact it’s somewhat agreeing with the point, that there’s a ton of influence left behind by these things, even though they are not there anymore.

Display PostScript is in Apple Mac OS X Server 1.0 and then abandoned in favor of Quartz and PDF.

> Don’t get me wrong, iOS is great, and I love it to death. However, the baggage signals to me that a massive opportunity to start anew has been missed.

I guess that's what Flutter is doing (for both iOS and Android).

> I guess that's what Flutter is doing (for both iOS and Android).

How does it do this as opposed to adding yet one more layer? Does it somehow get beneath all the cruft mentioned?

It is another layer, but it has as small as possible dependence on the below layers (UIKit, OpenGLES, posix) and instead tries to reimplement everything. For instance, if you want a slider control, that’s not going to use UISlider underneath, it’s going to reimplement it from scratch.

The problem with this is that it is an enormous task and they have barely scratched the surface of it.

Flutter is hardly the first reimplement the world GUI programming environment that tries to match the existing first party environment in terms of look and feel. Java swing was pretty much the same idea 20 years ago, and probably had more investment and momentum behind it than Flutter does today. While I can think of a number of swing success stories, I don’t think java swing as a whole was successful in what it set out to do.

> The problem with this is that it is an enormous task

It's an enormous task that never ends, too. Flutter has to continually keep up with UI/UX changes that Apple makes. Without enough momentum there, the devs using their platform are going to have apps that appear/feel old, which tends to be a marketing negative for Apple users.

Flutter took the approach of treating the screen as a blank canvas. Everything is drawn using Skia primitives, exposed as Dart libraries.

It has some downsides – they had to expose a lot of accessibility features on top of that using platform APIs – but it's quite nice when you are a developer, as you can Cmd-click on anything to learn how it is drawn, and use the same tools to build your own widgets if you need.

Afaik Flutter is basically a Game Engine. Its not using the build in UI Toolkit instead rendering everything itself and just mimics the look of the native UI.

I'm not completely sure about it, i just now it from listening to some talks.

Yes. It's not using any native UI widgets or UI code, but drawing everything itself using the lowest level API it can get, which I guess on iOS is Metal (and something for input). This means that the look and feel and the behavior and accessibility features will not match those of other apps (which do use the native toolkits), or the Flutter team will have to do a lot of reverse engineering and re-implementation to match that on each platform.

Currently, Flutter targets OpenGL ES on iOS which is less than ideal.

https://github.com/flutter/flutter/issues/18208

"We were discussing this in today's Triage meeting. Our current plan is to turn Metal on soon. This will increase the size of our engine by ~200KB. We can eventually reduce this by removing the OpenGL code but (a) that would drop support for <iOS10, which we don't want to do anytime soon (Skia only does Metal from iOS10), and (b) would require some work from the Skia team (OpenGL can't currently be removed from the codebase)."

Seems like it will be solved 'soon'

I am really curious why you are concerned at all about supporting iOS 9 (and lower?) at this point. That's a tiny, tiny fraction of worldwide iOS users. Probably not more than 1%. How many people are creating apps in Flutter that need to target that far back, and that user base?

Besides being a cross platform platform for Android and iOS, it appears to be a native UI framework for Fuchsia, Google’s nearly ‘from scratch’ OS.

I consider this a feature: the older code has known behaviour, while a from-scratch implementation would have been a minefield of unknown bugs

I’m not buying your reasoning. Try putting a WKWebView into a SwiftUI view. This kind of thing is all sorts of messed up when multiple rendering systems - two of them declarative (SwiftUI and HTML) - collide in a single view. I’m sure someone’s going to call this a corner case, but useful and interesting apps that push the boundaries of the feasible are all composed of such “corner cases”. And hey, I’m not even doing anything outlandish: just trying to show some HTML.

I sympathize with your position and have had similar problems in the past. There’s no magic option. But typically the combination of a completely new API and implementation is very difficult for both implementors and users.