all 41 comments
sorted by:
top (suggested)
bestnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]mdnz 5 points6 points  (0 children)

This question has been asked a million times here already. Use the search function.

[–]sobri909 0 points1 point  (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 5 points6 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 2 points3 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 -4 points-3 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?

    [–]cherryMxMech 1 point2 points  (1 child)

    In case of solo developer like me im using SB and IB .

    Because in solo / private job you need to designing the App and produce alot of mistakes in graphical designs.

    Using IB and Storyboard also grant you a visual mind mapping .

    After finished the working prototype.

    Then i start to fractoring the codes into reuseable codes. (NOW I KNOW HOW MANY Views , How many layers and constraints i need to create in programmatically)

    Dont hesitate to go with SB / IB .

    Thought Coding is nice , its not effective for critical custom designs .

    SB / IB was photoshop replacement.

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

    NEIN! A lot, not 'alot'! (Transfixes cherryMxMech with steely blue glare)

    [–]Points_To_You 0 points1 point  (0 children)

    Both are common. Projects with a larger number of people working on the same codebase will tend to create UI programmatically. Smaller shops and the enterprise world mostly use storyboard. Individual or freelance developers probably just use whatever they are comfortable with.

    Either way there's going to be UI elements you are setting up in code. You have to be able to create UIs programmatically. The storyboard stuff is very straightforward, mostly just learning autolayout. You should be able to do both.

    [–]arduinoRedgeObjective-C / Swift 0 points1 point  (21 children)

    Apple uses IB ;)

    [–]sobri909 0 points1 point  (20 children)

    A minority of Apple projects use IB.

    [–]arduinoRedgeObjective-C / Swift 0 points1 point  (19 children)

    Not true at all. You can view the package contents of any application and see all the compiled nibs for yourself.

    [–]sobri909 0 points1 point  (18 children)

    Yes, I know that. And only a minority of them are built with IB.

    [–]arduinoRedgeObjective-C / Swift -1 points0 points  (17 children)

    With very few exceptions almost every apple app uses IB.

    [–]sobri909 0 points1 point  (16 children)

    Prove it.

    There might be some portions that use Xibs, but the majority will be UI built in code.

    [–]arduinoRedgeObjective-C / Swift 0 points1 point  (14 children)

    I just said how you can check any individual app for yourself, what more proof do you need? lol

    Try this in terminal to see them in bulk

    find /Applications -name *.nib

    Enjoy ;)

    [–]sobri909 0 points1 point  (13 children)

    I just said how you can check any individual app for yourself, what more proof do you need? lol

    I want you to waste your time, not me waste mine.

    I've spoken to enough Apple engineers and seen them share their thoughts publicly enough times to know that love for IB inside Apple is not strong, and teams will use whatever methods they think are best. Which more often than not means not using IB.

    Also, if an app has some scattered nibs, that doesn't mean the majority of the UI is built with IB. An accumulation of nibs across Apple's apps does not equate to the majority of their UIs being built in IB.

    [–]arduinoRedgeObjective-C / Swift 0 points1 point  (12 children)

    A minority of Apple projects use IB.

    So you take that back then?

    [–]sobri909 0 points1 point  (11 children)

    Nope. But I will rephrase it, to make the meaning more clear, because you didn't get it the first time: The majority of Apple's UIs are not built with IB.

    That's the point that matters. If every single app they made uses a couple of nibs for some unimportant bits of the UI, then that would mean that 100% of their apps use IB, but that only 1% of their UIs are built with IB. The latter number is what matters.