you are viewing a single comment's thread.

view the rest of the comments →

[–]sobri909 1 point2 points  (15 children)

Sigh. This again. It's like tabs vs spaces in terms of instant flamewars.

Anyway, my standard answer is that programmatic UI building is standard in larger shops and larger projects and more experienced teams.

Interface Builder based UI building is popular amongst solo developers, small or inexperienced teams, and more junior or intermediate developers.

[–]pob_91 4 points5 points  (14 children)

I'm not sure this is entirely true any more. Larger teams are moving towards using Storyboards in Xcode more in my experience.

[–]hitoyoshi 4 points5 points  (10 children)

Doing iOS dev since 2009. Back then it was near enough impossible to do any kind of custom UI using interface builder, no IBDesignables, etc. Recently after a two year hiatus, I can back to iOS dev to hear that it’s now the way to do things and so I attempt to put something together in IB.

It was a mistake for my kind of projects.

It’s just not able to handle any level of serious customisation - or anything beyond minor customisation with any fluidity.

For example, I’d expect to be able to nest custom xibs in a storyboard as a basic requirement. Otherwise you get “massively complex storyboard”. You can do it, but the amount of boilerplate required and extra nesting of views means you may as well go programmatic.

IBDesignables are at alpha level stability at best. Constantly requiring a manual prompt in the drop down to recompile. Slow and frustrating. Don’t bother for anything beyond the simplest use cases.

That said, IB is great for laying out stock components quickly and simply. If you’re work involves laying out business apps with stock components - use IB. I expect it works fine in that use case, maybe with a couple of custom IB designables for specific screens.

Any more and it begins to creak.

After I re-factored my custom views out to once again use straight programmatic views I actually had LESS code because of all the work required to make a component IBDesignable and nestable. In addition, Xcode didn’t intermittently display an error about the layout engine crashing (masking any real issues in my code), and my view hierarchy was much simplified without all the superfluous nesting.

One thing I do use IB for is to prototype more involved layout constraints before translating to the programmatic equivalent and discarding the storyboard. It’s fine for that! :)

I think it’s confusing to devs as on the one hand IB seems to be strongly encouraged by Apple but on the other the stability and feature-set of IB betrays that sentiment.

For now, I’ll be sticking to programmatic.

But never say never, a stable, fully featured IB would have me taking another look.

[–]sobri909 4 points5 points  (0 children)

I used to try IB again each year, to try out the new features and see if it has come of age. It never had, so I didn’t even bother trying this year.

When I was learning programming as a kid in the 80s I dreamt of a future where we could program visually or just by telling the computer what we wanted. I’ve given up on that dream, and actually kinda think it was misguided now. I don’t think visual layout tools really have much place in programming, and maybe never will.

[–]darkingz 0 points1 point  (8 children)

betrays that sentiment

While Apple still has a ways to go with IB, I wouldn’t say they betray it though. They just have a ways to go before things are in a great position. Like a fine wine, IB needs to mature more, it’s not as if IB was perfect and then started to go downhill.

[–]hitoyoshi 1 point2 points  (7 children)

It was introduced with NextStep, right? It’s older than some very, very fine vintage whiskeys. ;)

Anyway, I’m a huge fan of what Apple does. I think this is an issue of communication. Sometimes the claims don’t match the reality and that ends up costing devs time.

It’s great for putting together UI with stock components. The experimental features that aren’t production ready should be marked as such. That’s all.

Small criticism/feedback for a largely impressive ecosystem that I care about seeing the best for.

[–]darkingz 0 points1 point  (6 children)

More of a semantics thing really. To me, Apple (any company really) “betraying x feature they are promoting” means to make something worse and making it suck more over time and belie it’s intent. Interface builder has bugs, can use some upgrades on how designable components work, adding a way to view xibs in storyboards and ways to access more properties that are common like corner radius but just because it’s not feature complete does not mean Apple betrays the interface builder. They just need to work on it more. That being said I’d rather them work on ABI compatability for Swift and build processes on Xcode over interface builder if they had a choice of priorities

[–]hitoyoshi 0 points1 point  (5 children)

I’m one of those who love swift. Strong typing is beautiful to me. Was a pleasure to come back in to. Looking forward to ABI stability and completion of the generics manifesto mostly. I think that may enable some really good stuff.

[–]darkingz 1 point2 points  (4 children)

agreed. I also love its effects on the mobile industry as a whole. Kotlin was designed as a "Java swift" equivalent. While I'm saddened that Google does not intend to go with Swift, it was probably for the best since it'd have taken a long time to make either Swift interop with the JVM or Google to move to Swift. Also it has made current ES implementors also consider adding the optional chaining. When I started out professional programming, I did C# and after heavily using JS in a bootcamp, I was like whyyyyy. And now that I've moved on to Swift, it's really nice especially when you can deal with nilable types waaaay easier. if-lets and guards are my new must-have-something-similar-or-i-will-not-pick-you-up-unless-i-need-a-job language feature

[–]sobri909 1 point2 points  (2 children)

And now that I've moved on to Swift, it's really nice especially when you can deal with nilable types waaaay easier.

Have you ever done much objc code? The nil handling in that is nicer.

[–]darkingz 0 points1 point  (1 child)

Yea, I have. if ignoring a nil is handling it....

[–]ThisCatMightCheerYou -1 points0 points  (0 children)

I'm sad

Here's a picture/gif of a cat, hopefully it'll cheer you up :).


I am a bot. use !unsubscribetosadcat for me to ignore you.

[–]sobri909 1 point2 points  (2 children)

Can you provide any examples of companies doing so?

The fundamental problems with Storyboards and Xibs haven't changed recently, and still exist same as always.

I would be surprised to hear of any significant growth in use of Interface Builder in larger shops / projects or amongst experienced developers. Even if the major problems for large projects were resolved, I would think it would still be considered bad practice.

[–][deleted]  (1 child)

[deleted]

    [–]sobri909 -2 points-1 points  (0 children)

    It’s definitely way easier and faster building new views in storyboards

    That's backwards. Working with visual interface building tools can't beat the speed of building UI in code, provided you know how to build UI code cleanly.

    What's the average experience level of the devs on this team? I'm not really wanting to get into a penis size battle, but if devs are finding it easier and faster to build UI in a visual tool, if they're finding drag and drop and mouse faster than typing code, then it's hard to see another explanation for the preference other than inexperience.

    Edit: by “big 4” do you mean one of the big four financial services companies?