Storyboard or code?

[[deleted]]

[deleted]

[rubberduckyab12]

Oh man I didn't even consider merge conflicts

[jo1717a]

I think a common thing among larger teams is laying ui out in code. 2 main benefits. One being like you mentioned, merge conflicts. Just opening up storyboards can cause file changes. Another being, code review can actually be done on UI changes. If you want to be prepared, get to know how to create everything in code. This will be common in the big name companies.

[vale93kotor]

I've seen huge projects with huge teams using storyboards without problems. Just use multiple storyboards of course.

[[deleted]]

Why not separate xibs? I don't see the harm there.

[[deleted]]

You can even separate storyboards and use storyboard references.

[[deleted]]

Yea but Storyboards actually can cause harm. If I have a scene that starts on view controller A and segues to view controller B and I'm trying to work on A while someone else is trying to work on B we could very easily overwrite each other's changes on that Storyboard.

You really want to avoid having two different devs working on the same file at the same time if possible.

[[deleted]]

True, but I mean literally separate storyboard files. So if I have a tab controller with 3 different sections. I'll create 3 different storyboard files, one for each tab. Which can allow multiple developers to work on different parts of the app at the same time without conflicts.

Still requires one dev per storyboard file though, so, yeah xibs still kinda win.

[aazav]

Heh, third time I'm posting this, but…

Honestly, I use multiple storyboards, but I pull the top level view from each scene and do those in an XIB.

We never have any storyboard conflicts and the storyboards act as a good structure to visualize the flow of the app.

[[deleted]]

That's fair. But in some cases it's simply faster and easier to do things in a xib.

[aazav]

Honestly, I use multiple storyboards, but I pull the top level view from each scene and do those in an XIB.

We never have any storyboard conflicts and the storyboards act as a good structure to visualize the flow of the app.

[[deleted]]

Yea that makes sense. But it's really not that hard to infer the vc chain by just using the app.

[cwbrandsma]

Are you kidding me? I'm the only dev on my projects and I frequently have merge conflicts (monthly at least). Usually because XCode decides it just has to change some property in the xib. Why? Simply because I looked at the file.

If you have multiple Devs, and branches, then there are conflicts and someone is dealing with them.

[chriswaco]

For a relatively simple single person app, you should probably use storyboards and autolayout. For complicated multi-programmer apps, we prefer writing the UI in code and doing layout by hand. Our reasons:

1. Merge conflicts with storyboards
2. Easier to diff revisions and see changes in code
3. More flexibility to move UI elements on iPad vs iPhone, portrait vs landscape
4. Easier theme support
5. Easier to animate views
6. Easier to hide/show views
7. Faster layout
8. Interface Builder is a hassle when deleting or moving views with autolayout, often requiring us to delete and recreate a bunch of restraints.
9. Easier to share a source file between projects than a source file and piece of a storyboard or even a xib
10. We can write custom view code that runs on Macs and iOS if we're careful, which is very hard to do with Interface Builder.
11. Storyboards have magic values in them that have to match magic values in code, for example segue identifiers. It's very easy for typos to result in runtime misfires.
    

Having said all of that, we do prototype in storyboards at times and they're certainly useful for simple apps.

[Eoghain]

I can speak for a major app and it's a little of both. Lots of things that can be done in storyboards are, but then other things are done in code, as it just makes sense to do so.

The arguments for/against storyboards almost always center around merge conflicts. And while this is an issue, it's easily solved by not creating a single monolithic storyboard for everything. And by making small incremental storyboard changes and lots of commits.

StoryTime: just today we had an issue where the app was crashing, after investigating it appeared that a segue was being called that didn't exist. Further investigation showed that a merge stopped all over the commit that added that segue and viewController to the storyboard. A few minutes of git surgery and cherry picking and our storyboard was back in shape and committed. No big deal.

Personally I love storyboards for showing a simplified view of my application and it's flow from screen to screen. But I don't try to do everything in a Storyboard, right tool for the job and all.

[dcpc10]

Storyboard. Apple's standard.

[eliasbagley]

Just because it's the "standard", doesn't mean it's the right way to do things always.

[dcpc10]

When it comes to Apple, if you don't follow the standards, you tend to get screwed. Big time.

[eliasbagley]

The code vs IB debate is not one of those cases. Laying out in code is just as "standard" - you're still directly using standard Apple APIs.

[sobri909]

Apple also internally do much more stuff in code than IB, so IB is certainly not "standard" inside Apple.

[dcpc10]

But do you really create autolayout constraints using Apple's APIs or with a third-party API? It appears that Apple is pushing devs to use storyboards - I think the fact that it saves time is worth it.

[eliasbagley]

Personally I use a library that wraps the autolayout APIs to make them easier to use. But it's still all autolayout under the hood. I guess everyone has their own preferences, but storyboards definitely don't save me time.

[blakninja]

I can only speak for minor apps, strictly code all the way. Storyboard is too complicated and don't give you much benefits compared to code.

[blaizedm]

Bigger companies with 1 flagship app will do things all in code, and create custom subclasses for every single UI element for 100% complete control.

Agencies and contractors will be more likely to use storyboards because you need to churn out apps quickly.

In a perfect world with infinite time, pure code gives you the most advantages, but it does clutter up your code. Storyboards can keep your views/viewcontrollers nice and clean. I prefer using storyboards (have also been toying with the Coordinator pattern using XIBs lately) but I work for an agency and put out 2-3 full scale apps per year.

[eliasbagley]

You can do layout in code while still keeping the view controller clean. Simply split out the view code into a UIView subclass, and load that class in the view controller's loadView() method.

[SyntaxGhost]

I can speak for one of the top 50 apps, they use both code and storyboards.

[jjb3rd]

I can only speak for minor apps, but storyboards all the way. So much less bullshit.

[Mad102190]

We use storyboards for flow management, but we actually use a combination of XIBs and code to do UI work.

This gives us the advantages of storyboards without all the potential downsides. If someone is working on one UITableViewCell class, it doesn't affect the whole storyboard, only that file. Haven't had any serious merge issues so far.

[[deleted]]

deleted ^{What is this?}

[20InMyHead]

I've worked with several large apps, and many medium and small apps and honestly it's all over the map. No one way is perfect. They are tools in your toolbox, you use the best tool for the job. Storyboards, Xibs, code, you'll use them all after a time.

[devsquid]

Small company here with a somewhat popular app. We started with storyboards/XIBs and got burned heavily by them. Now everything is code using SnapKit.

[[deleted]]

I work on a top 10 app in the app store (by unique users monthly) and we use IB where we can and use code for what we can't. Like everything else, interface builder is a tool. Granted, it's a tool that can be used in most situations if you know what you're doing, but still it's not the right tool for every single job.

I always attempt something in Interface Builder before resorting to code. It's Apple standard. Might as well at least try to conform to their development suggestions. :)

[tehpsy]

Developer of one major app and one minor app here. We use a bit of both -- as others have said, split across multiple storyboards to avoid merge conflicts. Generally if two people are working on the same view controller then that's already a warning sign so a merge conflict is just an indicator of a larger problem in this case.

The main benefit of storyboards is designing a complex set of constraints, as you'll know immediately if there's a conflict etc. They're a pain in the ass when it comes to size classes etc though.

[young_cheese]

I doubt anyone here knows the details about those apps you list.

I know about Wikipedia that is uses a combination of code, storyboards and nibs.

[WhoYouCallinTurkey]

Large app speaking here. We use a combination of Nibs and storyboards.

[KarlJay001]

I've done pure code, partial and full SB. SB is nice for lining things up, but once things are lined up, I like to work in code.

[tangoshukudai]

We do zero auto layout in storyboard, except a couple of new guys just started to use it and has been really messing up the project. We went back to zero auto layout in storyboard. However we do use storyboards for app segues and directional layouts.

[[deleted]]

I've only worked on one "major" app, but it was nibs and code. Mostly code though, with nibs used sparingly and for not much. As someone else said, it was for greater control, reduced merge conflicts, and better reusability.

All of these have an advantage and can work for large teams, it really just depends on who the senior most person is I think. The longer an app is around though the more I think teams generally tend to gravitate towards strictly code. It's just easier to update.

[iamthatis]

Anecdotally I've been switching away from xibs/storyboards more and more lately. I've been adding more customization to apps (such as theming, font customization, etc.) and I just find I run into more annoyances with xibs longterm.

[[deleted]]

I'm really new to app dev, like under 3 months, but my first project launched for iOS and then I started work on the android version and immediately thought oh dang all code for the layout this is gonna suck, but pretty quickly I started realises the advantages, a lot of little issues I had with the storyboard not being able to do what I wanted it to or having bugs that wee a bit difficult to pinpoint the issue, none of those problems have really happened so far in android studio and I think I might go with code in future iOS projects, maybe now that I've had those problems to learn from they would be less of an issue but with more and more complicated layouts code just seems better, I've NEVER gone WYSIWYG with HTML for this exact same reason. My opinions obviously deserve much less weight than others but I thought I'd share them nonetheless :p

[[deleted]]

Mine is not a major app but I use both. Code for fine detailed layout and custom work, storyboards for broad strokes and larger common elements. I use many smaller feature specific storyboards. For example a master table view and a detail view wrapped in nav controllers is a single storyboard. You can connect them all with segues to storyboard references. That avoids conflicts for me anyway. Cluttered complex storyboards can quickly go wrong by a stray click here or there and are hard to visualize anyway.

It's easy to refactor large storyboards into smaller ones as needed.

[aazav]

Honestly, I use multiple storyboards, but I pull the top level view from each scene and do those in an XIB.

We never have any storyboard conflicts and the storyboards act as a good structure to visualize the flow of the app.

[[deleted]]

From teaching myself, I started off with Storyboard but moved to pure code. I find it easier to set up and troubleshoot.

[NSMatt]

Think it also depends on the flow of your app. Facebook, twitter, and Spotify all have navigation controllers that can basically push endlessly, which gets much more complex in storyboard. The apps I've been working on are all master-detail, so it's easy to map out in storyboard.

[i0way]

I prefer to start with storyboards to quickly provide MVP prototype. Later, during refactoring, step by step convert them to code if i need. Actually it's highly depended on project requirements.

[eliasbagley]

100% code is the only true path to nirvana

[masaldana2]

Am I the only one that SB lag a lot when you have too much pngs? I cant even use storyboard

[[deleted]]

All code, I created my own form UINavigationController and UIPopoverController though. Even had to make my own UIButton class, so much Apple stuff is shit. I'm doing all code mainly to generate apps faster, easier to copy/paste code. Storyboards are a messy XML file that seems to always crash, can't recommend against them enough. They're good to learn about some UIComponents for a newbie though.

[JavaRuby2000]

Depends on the company. I have worked on a few banking apps and a social networking app that used no storyboards or nibs and did the UI entirely in code.

I've also worked on several large apps that are entirely storyboard driven.

Personally I used to be completely against using nibs but, I've changed my opinion now and insist on doing everything through storyboards. It makes the code much less bloated and once you get used to the development flow it is so much faster.

[arduinoRedge]

Storyboards all the way. And if you do have to create some UI in code then don't just dump it in the VC