iOS4 Built in SwiftUI | Hacker News Reader

iOS4 Built in SwiftUI

github.com

124 pointsmattei44 comments

Screenshots: https://imgur.com/a/JNVaFBI

Those screenshots invoke a lot of good memories from when I was in college and hanging out with friends. It's really weird how the design choices stuck with me as a trigger for that.

The dialpad for the Phone app was absolute perfection.

Huh. I like almost all the UI in this better than current iOS. Good placement, clear at a glance what everything is. This strengthens my sense that iOS has been going downhill, UI-wise, since v7 came out.

The square buttons made a target that was large enough to dial quickly. There was also some secret sauce they did to make the dial pad seem more responsive that other UI elements.

This file is insane: https://github.com/zzanehip/The-OldOS-Project/blob/master/Ol...

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.

Compared to the equivalent standard code to implement that UI?

Did you look at the file? Yes, comparatively using a non-declarative approach would render much simpler code. Perhaps the author is not writing SwiftUI proficiently? Having used SwiftUI myself I would argue that this is not the case.

It reminds me of why I am not a big fan of Flutter either. Not a fan of the deep nesting which both SwiftUI and Flutter needs to do for even moderately complex UIs.

This is a fun project so whatever code goes, but this could easily be broken into many small chunks. There’s even a context my button to pull subsections out into smaller strict automatically.

For those who have used both Flutter and SwiftUI, did you ever find that deep nesting to be very ugly and strange?

Deep nesting suggests that you need to break parts out into their own views (or pull logic out into their own functions). Like the close box in that file, it’s a great candidate for turning into its own view, or at least moving it’s action into a separate function.

This! It’s generally a good idea to have a lot of smaller “dumb” views that are stateless and depend on their parameters, and a few “intelligent” views that bring the children together and provide state logic. That puts reasonable boundaries between the view and business logic, even in declarative code like SwiftUI.

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.

I have zero experience with SwiftUI but dang, that looks really hard to read.

Reminds me of the PHP4-5 days where we'd have complex logic right within HTML components.

I've been writing SwiftUI full time for the last year and it's still hard for me to read.

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.

Probably could have made most of the event handlers separate methods rather than lambdas. That would have made the UI structure easier to read. I don’t know Swift or SwiftUI though.

Yeah you would never want to write Swift code professionally like this (at least where I work we don’t). I believe the developer of this said this was intentional (each file encapsulates an entire “app”).

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.

Really the problem is so much logic is being done inline with the view hierarchy. Like the close button action, it’s a big chunk of code and means I couldn’t even tell it was the close button until I scrolled further down. Actions like that probably should have been pulled off into their own functions.

It could also use actual comments, and perhaps breaking more things putout into subviews.

Very cool project but definitely not best practice. You could reduce the number of State variables using one or more shared state objects and access via environment at certain points in the view hierarchy.

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.

> You could reduce the number of State variables using one or more shared state objects and access via environment at certain points in the view hierarchy.

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.

The flutter people call this Nesting of layout and logic their secret sauce ! Opinions may vary

It’s fairly poorly abstracted, I guess OP is writing this more for fun. You could hide a lot of this implementation stuff in extensions, view modifiers and by composing views and splitting out event handlers. It isn’t representative of SwiftUI really.

OP is also 18 years old!

I find that an insane project for a teenager. I certainly couldn't have pulled it of.

That's awesome! I definitely couldn't have either.

I agree that ideally the code could be organized a lot better, but think about it like this:

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.

Agreed, i hacked together something resembling a midi-sequencer UI in about 1000loc with JS+Vue.

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.

I really think SwiftUI is hamstrung by trying to create a DSL that can describe a UI spanning everything from your watch to a desktop. The Apple world is starting to feel more like Google and MS with multiple UI frameworks coming out of different groups and no clear communication on what the long term plan is or expectation from developers. From what I can see though it looks like Catalyst is still very much a thing and I don't think that UIKit is going away anytime soon.

This is great! While I really do like the flat UI design trend, I sure do miss skeuomorphism in UI design. I underestimated the nostalgia that seeing this original design would stir up in me.

I like flat UI design and skeuomorphism too. However I am not a fan of what Apple's doing with half skeuomorphism in the latest MacOS. The new app icons look absolutely hideous. And based on anecdotal comments from others, I am not alone. Also them trying to make the MacOS app icons similar to iPadOS's rounded corner ones made it even worse.

> And based on anecdotal comments from others, I am not alone

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!

Or to further extend that, I've not seen any people like visual changes. Even though the science is there that the new design is better, people don't like change.

Which is one reason why (UI) engineers should be designing interfaces and prioritising usability, rather than artists who prioritise conformity with contemporary fashion and branding.

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.

The point of icons is to be able to quickly identify something—a button, an application, whatever. That's why people tend not to like changes to them—they're used to the current one, so changes make the icon less useful, at least for a while, and the more drastic the change the worse it is. Changes to a bunch of icons all at once are even worse, obviously.

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.

> That's why people tend not to like changes to them—they're used to the current one, so changes make the icon less useful, at least for a while, and the more drastic the change the worse it is.

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.

Would be nice if it share some screenshots

Adding screenshots would probably get the repo DCMA'ed by Apple for infringing their Copyright

Link wouldn't hurt.

Wow, this is a throwback to middle school with an iPod touch 2nd gen. I remember when the update allowing custom backgrounds came out, and I don't even know if my device could get it.

I haven't used an Apple mobile product in years (just Mac's for work), but damn did this hit me with some nostalgia.

You could... if you got it jailbroken :)

What I like most about this is how great and intuitive it is as a learning exercise. You have to re-construct the Camera, Maps, Safari, iPod, etc etc etc apps, and to make them functional, you need to call the system APIs for accessing web views / camera readings / etc.

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.

The name should be oldOS, not OldOS.

I may have missed it on the page, but is there a way to run old era apps if you have them in a backup?

iOS was and always will be a social construct. The ideas of NexTStep pre-date the 90s but certainly weren't new in 2010.

iOS does not have anything to do with NeXTStep beyond sharing a programming language.

Reply on news.ycombinator.com