Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

30k lines of SwiftUI in production later

blog.timing.is

Post reply on HN
Print view View original

41–50 of 124 posts

Re: 30k lines of SwiftUI in production later

#41

Post by LudwigNagasena »

lapcat wrote: post #37
LudwigNagasena wrote: post #33

Earlier quoted context omitted.

Why is it overoptimistic? It’s the same company, they should be able to leverage their past knowledge.

> It’s the same company, they should be able to leverage their past knowledge. It's not the same company. Compare 2023 to 2003. Different CEO, mostly different leadership (only Eddy Cue and Phil Schiller remain), massive employee turnover and new hiring. Even the name is different: Apple Inc. vs. Apple Computer, Inc. https://en.wikipedia.org/wiki/Ship_of_Theseus

I guess that means we should expect AppKit and SwiftUI to never improve.

Re: 30k lines of SwiftUI in production later

#42

Post by GeekyBear »

LudwigNagasena wrote: post #33
GeekyBear wrote: post #18

> It could — and really should — have been easier, especially considering SwiftUI has had three major updates since it was announced in 2019. Apple (and Next) have been iterating on AppKit for three decades. The UIKit fork of AppKit for iOS is a decade and a half old. Expecting the same level of polish in SwiftUI after three years is a bit overoptimistic. Apple has said that SwiftUI is "where the puck is going" so yo…

Why is it overoptimistic? It’s the same company, they should be able to leverage their past knowledge.

So Microsoft's ARM based Windows RT should have been able to run any x86 software, because Microsoft had been coding Windows for a long time?

Sorry, but it takes time for new things to gain functionality and polish. Windows RT was from 2012, and running x86 software on ARM only became possible recently.

Re: 30k lines of SwiftUI in production later

#43

Post by cellularmitosis »

bsaul wrote: post #36
toyg wrote: post #34

Earlier quoted context omitted.

What missed opportunity, Apple saw the opportunity right there and took it: the opportunity to reinforce the lock-in they always, always consider imperative to achieve. People think Apple simply don't care about other platforms, but that's just not true. They do care - they care that developers should stay the hell away from them.

i know, it's just completely delusional. Thinking that a programming language can thrive in a walled garden is insane. They've been burned by this in the past with objc, i don't understand how they can try again.

This thread is either completely serious or completely sarcastic and I love the fact that I honestly can't tell which it is :)

Re: 30k lines of SwiftUI in production later

#44

Post by rickspencer3 »

SpaghettiX wrote: post #21

> It took a few hours to fall in love with SwiftUI. > It was in development for 12 months. It would have been less if SwiftUI just gave. > At the end, we didn’t drop it for a couple of reasons. We were too deep into the process. Being a bootstrapped operation that was already severely behind schedule, we couldn’t afford to restart. This may be useful to someone trying to create something: In terms of software enginee…

I am a heavy user of Flutter. Even for simple things if I need to throw together a UI for my own use and then throw it away, I default to Flutter simply because I have become proficient at boot strapping a Flutter project. This is especially true now that they support desktop applications.

For this application, it sounds like the underlying services are not very platform specific, so on that level it seems like Flutter is a good choice. My concern would be that the developers seem very focused on the quality of the experience of even micro-interactions. My experience in Flutter would say that this degree of attention to detail would be hard to get right with Flutter, especially without choosing a platform to focus on, in which case the cross-platform benefits of Flutter are minimized.

Whether delaying an MVP for months to achieve that quality in the user interactions is an interesting side debate, though.

Re: 30k lines of SwiftUI in production later

#45

Post by bsaul »

cellularmitosis wrote: post #43
bsaul wrote: post #36

Earlier quoted context omitted.

i know, it's just completely delusional. Thinking that a programming language can thrive in a walled garden is insane. They've been burned by this in the past with objc, i don't understand how they can try again.

This thread is either completely serious or completely sarcastic and I love the fact that I honestly can't tell which it is :)

I was quite serious :)) why do you think it's sarcastic ?

Re: 30k lines of SwiftUI in production later

#46

Post by kitsunesoba »

bsaul wrote: post #36
toyg wrote: post #34

Earlier quoted context omitted.

What missed opportunity, Apple saw the opportunity right there and took it: the opportunity to reinforce the lock-in they always, always consider imperative to achieve. People think Apple simply don't care about other platforms, but that's just not true. They do care - they care that developers should stay the hell away from them.

i know, it's just completely delusional. Thinking that a programming language can thrive in a walled garden is insane. They've been burned by this in the past with objc, i don't understand how they can try again.

Swift is in considerably better shape than Obj-C is when it comes to cross platform. It’s not perfect, but it’s at least usable (there are production back ends written in Swift for example), it’s been slowly getting better, and Apple recently committed to filling many of the holes/inconsistencies in cross-platform with their announcement to rewrite Foundation in Swift and make it open source.

By contrast, Obj-C couldn’t even allocate memory without the assistance of AppKit, UIKit, or GNUStep. On its own it was woefully incomplete.

As for UI frameworks, porting SwiftUI would be a tall order with how it’s partially built on top of AppKit/UIKit. The most we’d probably get if it were open sourced is the surface bits, not the underpinnings.

Re: 30k lines of SwiftUI in production later

#47

Post by Zanfa »

mrtksn wrote: post #9
jalino23 wrote: post #3

I also fell in love with swift when I had to learn it trying metal. it just succs how you have to use xcode with it.

What's wrong with Xcode? Is it the usual "iPhone is preparing for development" type of annoyances? Is it the bugs that sometimes prevent you from compiling? Or is it something more fundamental like even when everything works fine you don't like it?

1) It's sloooooooooow

2) It's extremely buggy, like on a daily basis where something just doesn't work for any apparent reason that is usually either fixed by killing Xcode or removing derived data & then killing Xcode

3) Lack of plugins for even the most primitive of features like autoformatters

4) XML for build configs inside .xcodeproj

5) Why does it take half a day to update through the App Store?

I mean it has some nice features functionality-wise, such as the metal debugging toolkit, but the experience of actually coding in it is abysmal. Like so bad that I've been doing as much of my Swift work in VSCode as possible, which Xcode actually prevented for a while due to a bug in how it handled local Swift packages.

Re: 30k lines of SwiftUI in production later

#48

Post by veidr »

dmitriid wrote: post #2

What amazes me is that scrolling has never really been an issue in any native app? And yet here we are in 2023, with a native framework built for modern devices (where scrolling is the main interaction) that... inherits the worst behaviors of web of all things?

That isn't true; scrolling (and resizing) was a performance sinkhole for all kinds of apps that used the native table views (NSTableView and NSOutlineView), for many generations of Mac OS X.

They eventually added enough optimizations and performance cutouts to make it pretty easy to not fall in the hole with your app, so it hasn't been a problem with AppKit (or its younger 85% clone, UIKit) for a long while.

But I'm not surprised to hear Apple's much newer and not-very-related UI toolkit still has lots of those problems. That's one of the problems when not many developers actually use a technology — it's not just a popularity contest, having lots of users who complain is how you find a lot of the bugs and performance issues in your UI toolkits and app frameworks.

So lack of popularity often does mean there are probably a lot of those.

Re: 30k lines of SwiftUI in production later

#49

Post by ohgodplsno »

GeekyBear wrote: post #18

> It could — and really should — have been easier, especially considering SwiftUI has had three major updates since it was announced in 2019. Apple (and Next) have been iterating on AppKit for three decades. The UIKit fork of AppKit for iOS is a decade and a half old. Expecting the same level of polish in SwiftUI after three years is a bit overoptimistic. Apple has said that SwiftUI is "where the puck is going" so yo…

Jetpack Compose (Google's alternative on Android, that also works pretty much anywhere you can run a JVM and others like the web [1], terminals[2], powerpoints[3], iOS[4] if you squint, as well as pretty much anywhere you have an imperative API that you want to transform into a functional model[5]) is three years old and is infinitely more polished and has better tools than anything Apple has put out in all of SwiftUI's existence. Apple is bringing this upon themselves with their "major updates" concept for SwiftUI coming every other year, where components aren't even available on old versions of iOS. A UI toolkit is a library like any other, version it like a library and match patch releases.

[1] https://compose-web.ui.pages.jetbrains.team/

[2] https://github.com/JakeWharton/mosaic

[3] https://github.com/fgiris/composePPT

[4] https://touchlab.co/compose-ui-for-ios/

[5] https://github.com/googlemaps/android-maps-compose

Re: 30k lines of SwiftUI in production later

#50

Post by kitsunesoba »

mrtksn wrote: post #9
jalino23 wrote: post #3

I also fell in love with swift when I had to learn it trying metal. it just succs how you have to use xcode with it.

What's wrong with Xcode? Is it the usual "iPhone is preparing for development" type of annoyances? Is it the bugs that sometimes prevent you from compiling? Or is it something more fundamental like even when everything works fine you don't like it?

I spend most of my day in Xcode and for a while the main frustration was SourceKit being slow/crashy. That’s improved a fair deal over years, but I’ve found that the best thing one can do to improve that, as strange as it sounds, is to avoid code smells.

SourceKit can get really grumpy with things like deeply chained optionals, deeply nested blocks, and lots of casting or otherwise fighting against the type system. Not doing those things makes it run significantly more smoothly. So if Xcode starts bogging down or SourceKit is crashing, it means there are probably cleaner ways to write whatever I’m currently working on.

Post reply on HN