Hacker News Reader

Comment by aquabeagle | Hacker News Reader

I wish I would have not fought the tools so much.

I started Android programming from the command line using make/ant and testing on a device because I didn't like Android Studio. This ended up wasting a lot of time and energy over the years as I had to integrate more 3rd party libraries (including Google's own crap).

Same thing for iOS. I didn't like building GUIs in Interface Builder so I did everything in code. Over time as iOS devices came in different sizes, this became harder to do properly. I should have given in early and learned to use Interface Builder, auto layout, etc.

View on HN

I've been doing iOS for a while and I also fought AutoLayout for too long. I found doing it in code better than trying to get IB right, especially when working on a team.

What do you think about SwiftUI? I never liked coding layouts by hand but it seems a great compromise for SwiftUI, so I'm pretty happy to use it later on when more devices have moved on (which should be soon)

Code-only purists are still prominent in the iOS community. Yeah, there’s definitely baggage one must take on when using IB but the ease of being able to instantly preview your layout in different sizes is the big seller for me.

I actually went the other way. With autolayout is just easier (for me), to do UIs in code. Especially because IB does not offer 100% of what UIKit has. I don't hate IB, it just become less relevant to me. Storyboards on the other hand… Never thought well about them.

I’m not against IB but the lack of stuff like constants is really difficult when a customer demands “same app, different skin”. SwiftUI seems to fix this.

IB files are essentially impossible to code review.

If you read the storyboard diffs the layout code is human readable, just need to get used to it. Although there is no docs

Not in the case where a bunch of views are moved inside a new view. Then the XML diff is really janky, and elements are assigned new IDs.

The constraints are impossible to code review in XML since they refer to elements by IB ID which is essentially obfuscated. I don't understand why IB doesn't let you give the elements their own human-readable IDs.

most large apps, build by large teams, (from large companies) don't use IB at all.... for many reasons, but the main one it just doesn't play well in a 'many people working at the same codebase' type of environment.

For smaller apps, with a team of 2-3 people, IB is fine....

Reply on news.ycombinator.com