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

91–100 of 124 posts

Re: 30k lines of SwiftUI in production later

#91

Post by nodemaker »

Pulcinella wrote: post #85
nodemaker wrote: post #72

Earlier quoted context omitted.

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

Yeah there is a learning curve I admit. Usually you try to change the size of your view and see how things resize.

And yes StackView is your biggest friend. Usually when the system ignores your constraint it says that on the log. It can be a bit tricky to find out which constraint its breaking but the View Debugger and also the constraint constant value can help find it.

Re: 30k lines of SwiftUI in production later

#92

Post by quesera »

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…

> 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?

This is standard corporate policy at most/all big software shops. Apple uses Xcode internally, so the format and contents probably reflect their policy.

The block can be customized for your policies -- or removed completely, if preferred.

Re: 30k lines of SwiftUI in production later

#93

Post by allenu »

drclau wrote: post #52
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?

> What's wrong with Xcode? I still have no idea how I can quickly switch back and forth between open files. Either the feature is entirely missing, or completely unintuitive to discover and/or use. For the record, I am writing this message in 2023.

There’s definitely a ton of features in it that aren’t obvious.

These days I typically use cmd-control-left/right to navigate the open file history and then cmd-shift-[/] to navigate open tabs.

Also worth noting that you can find these in the Navigate menu if you want to peruse all the options.

Re: 30k lines of SwiftUI in production later

#94

Post by lapcat »

Klonoar wrote: post #82
lapcat wrote: post #51

Earlier quoted context omitted.

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.

> You could argue it’s stagnant, maybe

Quite the opposite. I would argue that macOS (the artist formerly known as Mac OS X) is quickly being transformed into iOS. Big Sur was a massive change in this respect, and the transformation continues in Ventura.

Re: 30k lines of SwiftUI in production later

#95

Post by nodemaker »

How does everyone feel about hiring iOS devs in this environment? I feel like its too hard for SwiftUI devs to pick up UIKit when they get blocked and usually they just give up. Also in interviews junior devs have no clue about AutoLayout or UICollectionViews.

Re: 30k lines of SwiftUI in production later

#96

Post by allenu »

Pulcinella wrote: post #85
nodemaker wrote: post #72

Earlier quoted context omitted.

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

When they introduced auto-layout, I started using it all the time. The debug spew from the console was definitely frustrating to debug though.

Eventually I tried going back to manual layout because a coworker still used it all the time and I noticed that it was pretty easy to follow the layout rules in imperative code (so long as it's well-structured). Since then I just do manual layout for everything. It's just easier for my brain to describe the layout I want that way. I feel like it takes me longer to come up with constraints that match what I want, but I'll admit if I went back to auto-layout, I'd probably be better at it.

Re: 30k lines of SwiftUI in production later

#97

Post by alexashka »

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…

> Expecting the same level of polish in SwiftUI after three years is a bit overoptimistic

Is it?

Should I expect my M1 macbook to break in unexpected ways for a decade before it works too? M1 is new, like SwiftUI is new, how come it actually works?

Apple devs have stockholm syndrome.

Re: 30k lines of SwiftUI in production later

#99

Post by sicp-enjoyer »

avianlyric wrote: post #59
WA wrote: post #39

Earlier quoted context omitted.

Descriptions like these makes me wonder how we ever made a single computer game with millions of polygons that are in view or not and must be rendered accordingly.

Completely different problem. Rendering millions of polygons is almost trivial to parallelise, and there’s plenty of hardware around that’s capable of providing the needed parallel compute. You’ll note that games have loading screens, those exist so the games can get everything it needs into working memory, order it to enable extreme levels of parallelism. And only then do you get buttery smooth 60fps, and games, of…

Filling polygons has never been the hard part of realtime games. It's all the work that gets you to be able to fill just the polygons you need in the way you want them.

It is not a big ask to have a scrolling UI. Look at motif from 80s.

Re: 30k lines of SwiftUI in production later

#100

Post by sicp-enjoyer »

jb1991 wrote: post #38
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 is hardly a solved problem. On iOS, for example, using UIKit which is very mature and performant, to avoid performance issues with a scrollabe table of, for example, thousands or tens of thousands of items, you use an api that recycles UI components to support lazy loading and the lowest memory usage possible in such a scenario. If you jump in to do this naively, it will destroy the user experience and the…

Are you suggesting that the programmer should be able to pass a tree of 10,000+ heterogeneous nodes with transformation and styling and it just works without them thinking about how to break up that problem?

It is a solved problem, the solution is load things lazily as needed, and the UITableViewDataSource protocol is one template you can follow for doing that.

Post reply on HN