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

81–90 of 124 posts

Re: 30k lines of SwiftUI in production later

#81

Post by bsaul »

kitsunesoba wrote: post #46
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.

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 could…

Chris lattner had very clearly stated objectives for the language, and at some point cross-platform swift was a real possibility : at the time when a few server framework were created and when people at google were using it. Why this never lasted, i don’t know (my guess is the reason was purely political).

Unfortunately all those options got cancelled, and now apple remain on its own using it. I don’t believe in cross-platform swift anymore.

Re: 30k lines of SwiftUI in production later

#82

Post by Klonoar »

lapcat wrote: post #51
LudwigNagasena wrote: post #41

Earlier quoted context omitted.

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

AppKit has been going downhill for years.

Uhhh, not sure I agree. You could argue it’s stagnant, maybe - but it’s just as good as it’s always been.

Re: 30k lines of SwiftUI in production later

#83

Post by politician »

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?

Xcode sometimes takes 20-60 seconds to recover from errors in the syntax. It’s so odious that when I have to use it, I build everything in VSCode and then do the final mandatory testing pass in XCode.

It’s extremely slow on high-spec MBP.

It sometimes takes developers over 14 hours to update.

It interferes with other command line tools, forcing itself into the middle — if you’ve ever tried to run git on a fresh MBP and run into the xcode-select install step, you know this one. It’s a bad citizen.

Installing XCode will cause a perfectly functional machine heavily used for development in VSCode to experience several full crashes until it fully takes over the machine. MacOS with and without XCode appear to be two fundamentally different operating systems.

Having XCode running for any amount of time saps battery like nothing else. You can run VSCode for 24 hours on a MacBook Air with M1 for maybe 3 hours in XCode.

The git integration is so utterly crap and broken that it’s safer to turn it off rather than fighting the secret intermediate repo cache that it hides from you and sometimes forgets to update.

For some idiotic reason, creating a new file in XCode prepends the file with a comment block including the name of the file, the date, and the name of the user. Who asked for that? For a file that’s part of a repo that’s going to be touched by multiple people over a long period of time and likely renamed, this is just obnoxious noise.

Re: 30k lines of SwiftUI in production later

#84

Post by mrtksn »

politician wrote: post #83
mrtksn wrote: post #9

Earlier quoted context omitted.

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?

Xcode sometimes takes 20-60 seconds to recover from errors in the syntax. It’s so odious that when I have to use it, I build everything in VSCode and then do the final mandatory testing pass in XCode. It’s extremely slow on high-spec MBP. It sometimes takes developers over 14 hours to update. It interferes with other command line tools, forcing itself into the middle — if you’ve ever tried to run git on a fresh MBP a…

Some valid points, thanks.

However you might have some other issues with your system because I practically never close Xcode and I’m having like +10 hours of battery life on my M1 air. This includes actual work being done in Xcode.

Re: 30k lines of SwiftUI in production later

#85

Post by Pulcinella »

nodemaker wrote: post #72
herodotus wrote: post #54

Earlier quoted context omitted.

This is why: it's hard to get things right. When I started programming for Apple almost 20 years ago (mainly using Objective C), too many hours of my time were spent making sure that I was dealing with memory correctly. Easier in Objective C than C's primitive malloc/free, but still hard, even with the tools to help. During my time there, new things were tried: firstly garbage collection, and then automatic reference…

For an expert with some mathematical intuition layout constraints can do a custom layout that lays out perfectly on all screen sizes much better than declarative. However there is a learning curve I admit.

I love AutoLayout constraints…unfortunately Apple has never improved debugging tools. So when the system breaks and spews a bunch of autolayout constraint complaints to the debug console, it can be difficult to determine what went wrong (especially because the system will sometimes generate its own constraints, like if you are using stack views, and you have no insight into why they were generated or why the system is ignoring and discarding the constraints you made).

Apple’s documentation has also gotten way, way worse. Apple expects you to watch the WWDC videos, but it’s not like they make refresher videos on old topics all the frequently and they often remove or hide old videos.

Re: 30k lines of SwiftUI in production later

#86

Post by Pulcinella »

mrtksn wrote: post #55
Zanfa wrote: post #47

Earlier quoted context omitted.

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 s…

On Apple Silicon it's quite performant, I'm sure there are faster things but I don't have complaints on speed o M1 Air. I had complaints on my Intel based mac though. The bugs can be annoying but they usually go away after restart and cleaning the junk. > 5) Why does it take half a day to update through the App Store? But this one is really annoying. Also for some reason in downloads and installs TWICE.

It’s way, way faster and easier to just download new versions of Ccode from the developer website. I have no idea why doing it through the AppStore is so slow. If you pull up the console log you can see the AppStore app not actually doing anything for 20-30 minutes (even though it’s displaying the download spinner) before it finally decides it’s time to start downloading.

Re: 30k lines of SwiftUI in production later

#87

Post by politician »

mrtksn wrote: post #84
politician wrote: post #83

Earlier quoted context omitted.

Xcode sometimes takes 20-60 seconds to recover from errors in the syntax. It’s so odious that when I have to use it, I build everything in VSCode and then do the final mandatory testing pass in XCode. It’s extremely slow on high-spec MBP. It sometimes takes developers over 14 hours to update. It interferes with other command line tools, forcing itself into the middle — if you’ve ever tried to run git on a fresh MBP a…

Some valid points, thanks. However you might have some other issues with your system because I practically never close Xcode and I’m having like +10 hours of battery life on my M1 air. This includes actual work being done in Xcode.

That’s probably true, but also I’ve experienced these issues on two different machines (high spec Intel MBP, highest spec M1 MBA).

I do regularly find that mDNSresponder has been sending and receiving 100’s of GB over the network and must be force killed. When that process goes off the rails, it also saps battery.

I wish that I didn’t have to keep Activity Monitor open at all times on both machines just to keep ahead of the problems. It’s not like effectively running top is cheap.

Re: 30k lines of SwiftUI in production later

#88

Post by LudwigNagasena »

GeekyBear wrote: post #42
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.

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.

Different tasks require different timescales. It seems reasonable to expect the biggest company in the world with some of the best software developers and UI designers to be able to produce a polished UI library for their own device that runs on their own software and hardware given that they have been developing UI solutions for 30 years.

Re: 30k lines of SwiftUI in production later

#89

Post by Pulcinella »

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?

Scrolling on SwiftUI is extra bizarre because I often observe weird micro stutter. A scroll view with perfectly static text that never updates will sometimes scroll at what seems to be ~45fps. But really it’s more like it’s randomly dropping 1 out of every 4 or 5 frames or so. It also seems to be related to dragging the scroll view, because programmatic scrolling can be very smooth. (Also SwiftUI was weirdly capped at 60hz and couldn’t do 120hz until iOS16.2. Doesn’t make me confident that SwiftUI will ever get a lot of development love from Apple if it took over a year for SwiftUI to support a flagship feature from the iPhone).

Re: 30k lines of SwiftUI in production later

#90

Post by GeekyBear »

LudwigNagasena wrote: post #88
GeekyBear wrote: post #42

Earlier quoted context omitted.

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.

Different tasks require different timescales. It seems reasonable to expect the biggest company in the world with some of the best software developers and UI designers to be able to produce a polished UI library for their own device that runs on their own software and hardware given that they have been developing UI solutions for 30 years.

Microsoft is just as big as Apple. So they should be capable of immediately writing an ARM emulator for their own longstanding Windows API's running on their own hardware, right?
Post reply on HN