iOS4 Built in SwiftUI(github.com) |
iOS4 Built in SwiftUI(github.com) |
I hate to say it but SwiftUI is tricky to write for very complex user interface...the one in that file is a nightmare imo.
It could also use actual comments, and perhaps breaking more things putout into subviews.
It is the fully working safari UI in only 1000 lines of code. Additionally the declarative approach of SwiftUI together with the type system makes it certainly correct in many ways: no rendering bugs, no invalid states, probably no memory leaks, no cyclic dependencies creeping in.
Try to build this in Java Swing, UIKit, Html/Css/Js or any other UI library. Flutter might come close, react/vue/svelte as well, if you assume sensible predefined components. But they work similar to SwiftUI and the resulting one-file might look pretty similar.
I have an old editor written in Java/Swing that takes more and more willpower to work on every time because handling state update bugs is what i spend half my time on.
A lot of this would be broken out into it’s own file (e.g. extensions on basic types like Arrays would go in Array+Extensions.swift). Each view would go in its own file. You would break out code into separate functions instead of inlining it inside closures in the view body.
SwiftUI (though not usually Swift in general) does have a problem with over-indentation IMO. You barely have to go more than 3 levels deep in the view hierarchy you are producing before your code feels like more white space than code.
I find that an insane project for a teenager. I certainly couldn't have pulled it of.
Reminds me of the PHP4-5 days where we'd have complex logic right within HTML components.
You don't have to (and almost certainly shouldn't) write it like that.
Of course, this is just a project for fun so if this person can figure it out, more power to them. It's a neat project.
Generally it’s better to compose views, by that I mean you often have to because of the compiler. I’m surprised this file even compiles! The Swift compiler usually chokes on much smaller views.
Just a personal opinion here, but those shared state objects and SwiftUI + glorified singletons really hurts every time I see it. It's so prevalent in online tutorials like Ray Wenderlich and the such.
Honestly, it's hard to avoid and can be done but requires a significant effort. I was hoping for Apple to come up with a more elegant solution during WWDC 21 but so far I haven't seen anything to improve this situation.
While this case I'm in 100% agreement with you, in my experience I don't think I've ever seen any people I know like changes to icons!
I haven't used an Apple mobile product in years (just Mac's for work), but damn did this hit me with some nostalgia.
That’s exactly what the author did. It’s like a “learn to build X clone” but for many different X’s.
With that said, he really needs to delete those .DS_Store files scattered everywhere in his repo. Ouch.
I’m not a Swift or SwiftUI expert, but have written declarative UI quite a bit. Don’t imagine some base best practices would differ too much.
Ditto other UI changes, like changes in menu or button layouts. People rely on things staying in the same place for speed and confidence using a UI. When they change, you slow them down and make them less confident. Of course people don't like that! Can you imagine the rage if every release of Ubuntu made the kinds of drastic, wide-ranging changes to various command line interfaces that operating systems and major GUI programs do routinely? I think it'd only take about two releases like that to kill the OS, market-wise, even if they managed to do it without breaking scripts and automation (to remove that difference) and even if there were some small benefits to the changes. But when GUI users complain about that stuff people get dismissive and roll their eyes.
For me, it's not just that. It's not just the "change" which I disliked. It's how ugly they are. The icons simply look very ugly with the shadows and other strange changes.
Appearance can certainly change, but the needs of the user, including for predictability, should be very important to the process of deciding to change and making the change. At the moment the reputation of the company and the artist are considered to the dominate over most other matters. It is simply reckless to do this at a time when public trust is so limited. It is the constant responsibility of everyone who acts in public to try and rebuild.