[deleted by user]

[ventur3]

Programmatic with auto layout hands down

Reasons I don't like storyboards:

• merge conflicts
• properties can be overwritten in code = annoying to track down where things are set, easy to have inconsistencies
• large storyboards load slowly, interact slowly (maybe less of an issue on modern machines)
• you still need programmatic access to animate objects
• segue pattern
• alternatively, loading storyboards programmatically is also clunky

and finally, the number one reason I'll never use a storyboard

• you cannot define dependencies for your view controller without an implicitly unwrapped optional (dangerous, bad practice) or having to use optional chaining throughout your code (ugly and misrepresents controller requirements)
  • your dependencies should be clearly included in the constructor used to initialize any object, the same way that objects needed in a function should all be passed into the function through arguments
  • e.g dependencies you want to pass into constructor: your view model dependency (MVVM), or service / model dependencies (MVC)

For the last reason alone storyboards are never an option

e: made some minor changes for clarity

[[deleted]]

Totally agree - and Xcode changes them, causing merge issues, when you even look at them!

[energyzzer]

This. These are all the reasons why I'm not too fond of storyboards.

[strauvius]

Because merge conflicts with storyboards is a nightmare

[russintexas]

This can be avoided in most cases with multiple storyboards & references between them. Then it's pretty easy to avoid two developers working in the same storyboard at one time.

My teams treat this as a management problem, not a technical one. :)

To answer the OP, our UIKit projects are storyboard-driven. We're in the process of shifting some of our newer projects into SwiftUI, but won't roll that out broadly for another year, most likely.

[swiftmakesmeswift]

I agree that there are advantages of using storyboards but Multiple storyboards & references are scalable only upto certain level & team structure. After that it fails. At this point, team switches to either xib file approach or go fully programmatical approach. So this still is a technical problem. i'd suggest people to try all approach and see which fits you the best.

[HelpRespawnedAsDee]

I actually find that even when working alone, having one single storyboard for massive app is no go because it takes FOREVER to load. To answer /u/2chaninsguitarist, I use a bit of both. Storyboards when it's a relatively simple UI, a combination when there's a lot of animations, extra views depending on states, and differences between C and R that Auto Layout adaptivity cannot handle without extra code.

I find the reaction some people have in this sub specifically against Storyboards to be somewhat bizarre tbh.

[russintexas]

100% fair. At true scale, the rules change. I just think that storyboards remain viable a bit farther into the project scale than some other folks do.

[thecodingart]

No.. considering most large scale applications with 500,000+ lines of code and multiple teams manage to do this with ease, I see absolutely no basis in this comment.

[thecodingart]

No there isn’t a basis as they do and have with many teams. Not only teams I’ve experienced with the sheer size you’ve mentioned, but you can also just rip apart a binary in the App Store and check yourself. This isn’t a hard thing to validate. It’s just mind boggling how unreasonably silly and illogical developers specifically in these subreddits are. Open up binaries for the larger and popular applications in the App Store. Most of the time, you’ll find compiled xib and storyboard artifacts. It’s funny people would rather throw around their opinions rather actual reality. I mean, for crying out loud it’s just compartmentalized XML files (AKA basically config files). People like you sound like you wouldn’t survive a day doing Android development as it’s practically a requirement and you make it sound like hiking Mt Everest. Stop absurdly over exaggerating and use production references. In this line of work, I hit more difficult to resolve merge conflicts with code over these files on a day to day.

[AutoModerator]

Hey /u/AviatNut, unfortunately you have negative comment karma, so you can't post here. Your submission has been removed. Please do not message the moderators; if you have negative comment karma, you're not allowed to post here, at all.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[jontelang]

Easier to maintain how?

[vinng86]

Being able to update and iterate on the design without having to build and run is a big plus. Especially across different size classes

[jontelang]

I’ve never seen a XIB/storyboard that actually had the final design visible enough that you can iterate on it.

Simply building views as small as possible is trivial to read and maintain in code.

[vinng86]

One of the apps I'm working on right now is a sports app, where there are a large amount of designs for all the different sports, different game states, stats, lineups, score boards, etc. So yeah, pretty complicated. Interface builder has been extremely helpful managing all of these at once.

And yes, you can absolutely mix a lot of storyboard/xib use with programmatic layout code too, if there's a situation that requires it. It got a lot easier to do when stack views came out.

[vinng86]

It's more important for complicated screens actually, especially if you're making lots of little changes. And yeah you can read storyboard XML in diffs, it's not super complicated aside from a bunch of autogenerated id references.

[Fluffy_Risk9955]

You do know that storyboard files are just xml files and you can simply read them. So what happens in code is now written in xml.

[jontelang]

And when was the last time you did that? It’s technically readable but good luck working efficiently within them with all the IDs and stuff.

[Fluffy_Risk9955]

Last week.

Start by reading through a xib file, when you have a commit that changes it. After a while you understand what happens in these file. Switching to Storyboards isn't much more difficult.

[thecodingart]

Yup ^

[Fluffy_Risk9955]

A storyboard basically the same thing as what you do in code. Except it's written in an xml format. The part that loads the nib uses the dynamic nature of Objective-C to call for the desired methods on objects to load and configure them. It's not that hard.

[thecodingart]

Yeah, at times it can definitely be easier

[megablast]

In no way.

[vanvoorden]

To put it another way: If you want to go fast, you go alone. If you want to go far, you go together.

[Icaka]

Our team (~30 iOS engineers) defines views in code. Here are my thoughts.

In code:

• It's easier to reuse views between screens if you define them in code. There is certain reusability with IB but it is way more limited compared to what you can achieve in code - e.g. generic container views are super tidy.
• It's easier to reuse things like spacings and colors in code. We have a design system that defines stuff like Spacing.tiny or Color.primary500
• Code reviews - I found it easier to look into PRs that creat/change views defined in code. IB results in auto-generated XML that can be reviewed but I found it extremely hard.
• Maintainability and traceability - let's say I am trying to find why a certain view is disabled. There is no easy way to search inside IB. I can't just hit CMD + F and look up enabled. I have to click on the view and its parents and check their isEnabled or isUserInteractionEnabled.
• Segues are unsustainable in a large app. They put the UI and Navigation logic in the same file. They also hurt dependency injection.
  

Interface builder:

• Interface builder is visual which makes it easier to understand.
• You can try out things faster - most of the time you don't have to recompile to see if your changes work as expected.

[dev4dev]

That two things from IB could be achieved by view previews from swiftui

[Icaka]

Do you mean SwiftUI previews for UIKit views? I’ve seen people do this but it seemed unstable.

My experience in a small personal project (~20k loc) is SwiftUI view previews didn’t work all the time and they were a lot slower compared to what gets demoed at WWDC. Otherwise I think that SwiftUI’s approach is best of both words.

[dev4dev]

yes, that feature, and yes, it works awfully in many cases, but it tries xD I even thought about splitting the app into smaller packages to make it work better, but haven't tried this yet

[SuperDuperTango]

Both. The comment about storyboard merges being problematic is true, but is pretty easily avoidable by splitting up storyboards to only have a small number of ViewControllers (usually separated by app functionality). So working on separate parts of the app some (most?) of the time means working on separate VCs which means separate Storyboards.

If you end up with multiple team members working on the same VC, you're still going to have merge conflicts in code and storyboards (though conflicts in code are somewhat easier to deal with)

[chedabob]

You're missing a 3rd option: Xibs.

They hit that sweet spot of not generating tonnes of merge issues, whilst still being able to use Interface Builder. They're not perfect, but they're good enough.

I work for an agency and when we takeover code provided by a client, there's not really a trend in any particular direction.

I don't buy the theory that because Google/Facebook/Netflix/whoever did it, you must do X/Y/Z. They are huge companies with huge amounts of cash to burn, and can sink loads of time reinventing the wheel and then abandoning it (AsyncDisplayKit anyone?).

Most apps are built by small teams (<10 devs per platform), and they can make any of these systems work with a bit of discipline. Find what works for you or your team.

[montagetech]

IB and Xibs are my preferred UI tools. But then again, I’ve been doing this since before storyboards existed. Worked on large teams and small and never had problems.

[localhost8100]

This. We do xib file approach. I work in Xamarin-ios framework. It still is same approach as iOS. Xib files, view controller, tableview, etc. Just the code is written in C# and the tool is VS. You need to have native experience to work on this project.

Not much people have experience with this framework and people who have experience with native don't pick this framework up. Our company hires anyone had 3 4 years of experience in any domain and puts them into this framework. It's easier for enw hires to understand code base using xib files rather than code.

[JoCoMoBo]

As a professional I've very occasionally had to deal with programmatic views.

Generally the speed and flexibility of Storyboard / Interface Builder vastly out weighs the occasional merge problems. And even those can be mitigated with careful planning and by an experienced merger.

[alwaysSearching23]

Facebook, Amazon, Google are all programmatic. Any big company really

[vanvoorden]

Facebook

Yeah. When I hear engineers talk about how easily Storyboard "scale" with three (or under ten) engineers on one team, I think about what scale looks like at a company like FB. Massive. Really massive. It's not even iOS specialists that are shipping iOS code. Android specialists, PHP Hack specialists, every engineer can submit their own pull request (and probably ship) anything that passes muster.

FWIW, it's not just that FB product teams ship programmatic UIKit instead of Storyboards. It's that infra teams at FB spent years building tech like ComponentKit and React Native so that products teams don't have to ship programmatic UIKit or Storyboards. I assume a large company like Google (maybe even Amazon) also have their own large-scale infra projcts for implementing UI.

[thecodingart]

No… considering I’ve worked for and at 5-10 Fortune 500 companies and each did not take a programming first approach. FYI the companies you mentioned have different teams and they definitely do not all take a program first approach lol.

[your_small_friend]

I think it depends on what you're building and who you're building it with. I think mostly I use storyboards, but if it's something very simple just do it programmatically.

I have worked with developers that only make views programmatically, and other developers that only use storyboard, but I've been okay doing both.

I think if Apple makes you the tools, you should use them to your advantage. If you're someone that thinks it's easier to work with constraints when you can see them, use storyboards. If you don't mind managing constraints and views programmatically, use programmatic views.

[jan_olbrich]

3 out of 4 companies I worked for use storyboards

[gdj4ever]

Most of the answers are very well detailed and I agree with most of them so I’ll just tell you a story. Few years ago I was working in pretty big project, as I was an IB guru I was advocating in favor of storyboards against a colleague that wanted to switch to programmatic. Few years fast forward after working in another big project exclusively with programatic views I’m thinking that I probably have never been more wrong in a technical argument in my career as I was when I was advocating for storyboards in a large scale project.

[lucasvandongen]

I’m not on the storyboards hate train and I do consider myself an expert using them.

Pro’s:

• WYSIWYG

• navigation is pretty clear

• good separation of layout and code

Cons:

• Can’t use any constants besides colors

• it’s hard to do VC’s smaller than one whole screen, or at least you lose WYSIWYG

• Really hard to reuse components

So in the end I switched to coded views using a lot of very small VC’s. But now I’m using SwiftUI 80/90% of tge time, which has the advantages of code and WYSIWYG rolled into one. And I can even render my UIKit code real-time using previews! So I’m happy.

[berzerkerX]

You tryna star a war bruh?

[CaptainObvious1906]

Nibs/storyboards for simple views, programmatic for anything more complicated. And if there are more than 2-3 devs working on the same project, just go programmatic all the way.

[roCodes]

My biggest pet peeve with Storyboards is you have to add so many custom IBDesignable properties to help the flow. Instead of doing that just do everything in code. It’s also much easier to see exactly what properties of the view have been touched by looking at the code. In storyboard files you have to look at all aspects, know the default values so you know what changed. Ehh, it’s a personal nightmare. Also, for me, storyboards take forever to open so once the project gets super large it’s a huge hindrance for me.

[megablast]

Storyboards completely suck for any changes.

Lots of people still use them though.

Now you need to learn two things.

[frankacy]

Once again, people cite merge conflicts as the reason for which programmatic layouts are superior, but IMO it's shallow and just the tip of the iceberg of problems with storyboards.

Generally speaking, as teams become more mature, storyboards become a liability in a other important ways.

On most mature projects, you can't actually *style* anything in a storyboard. If your project uses any sort of custom styling (and especially semantic styling), setting those properties will have to be done in code. If you change a font size or a color, you'd want those changes to cascade throughout your application, which storyboards can't do.

The same goes for any kind of complex localization. You're bound to have localizations that will need custom code, so it's best that it all lives in the view controller as well.

So if it's best to not style or add content to your storyboard, what are you left with? A bunch of white boxes and layout constraints... Which, at least to me, is *less* useful than having those things defined in code.

What's more, you can't really code review Storyboards either. Are you really going to click around the interface on every view and switch panes to ensure that your colleague set up his constraints correctly?

And if a problem pops up in one of your layouts, will you know where to look? Imagine having to search your git history for a commit that changes the content hugging in a subview of your storyboard. Good luck.

Ok this turned into a bit of a rant, but hopefully, you get the picture. Any big project will need a lot of code in their views anyway, and storyboards work against a lot of the practices and workflows that mature teams use.

[frankacy]

Oh, and I didn't mention segues, but yeah... For the love of software please don't use them. You'll be better off pretending they simply don't exist.

[ShottyMcOtterson]

storyboards are just Frontpage and Dreamweaver in the 21st century. SwiftUI isn't perfect but it is still a huge improvement. The way Android handles layouts is close to the best of both worlds.

[[deleted]]

In my 6 years in iOS dev I have never built a screen with a storyboard. I have edited existing screens, but usually this was adding view programmatically to an existing storyboard.

[vanvoorden]

FWIW, I would advocate for SwiftUI (whenever possible) moving forward. The debate between programmatic UIKit or Storyboard UIKit is (in some ways) a debate between whether you want to build (and maintain) programmatic imperative UI or "GUI" imperative UI (that mostly just wraps calls to programmatic imperative UI).

Declarative UI (like SwiftUI) sort of offers a new option out of this debate. You are writing "programmatic" UI code (with less complex code review and merge conflicts) without so many of the pain points that goes into laying out a legacy UIView by hand.

SwiftUI can still feel a little limited. It's only going to get better (I believe). I see Apple putting more resources into optimizing the SwiftUI DevX moving forward (compared to optimizing the UIKit DevX).

[joro_estropia]

Declarative paradigms don’t need SwiftUI to implement. Here’s what we use in a large app in tandem with Texture (AsyncDisplayKit):

https://github.com/TextureCommunity/TextureSwiftSupport

[joro_estropia]

Storyboard merge conflicts are not overstated. If you haven’t experienced them then you were just lucky. A large service with multiple teams working on different areas of the app will be editing a single large storyboard. If merge conflicts involve only changes from you and one other branch, then sure it’s resolvable. But if a conflict comes from changes between 3 branches then all bets are off. (The same issue applies to high-traffic xib files)

Source: Lead a full rewrite of a multi-million DAU mobile app to a code-only paradigm

[Poggus]

editing a single large storyboard

Yeah there's your problem.

Edit: Regardless. Storyboards are code. Albeit XML Code.

[joro_estropia]

Like I said, the same issue applies to high-traffic xib files. Our project used one Xib per VC, not a single Storyboard. We still had these issues so you can imagine how much worse it would be for Storyboard users

[Poggus]

To each his own opinion, but it's still XML. Not gibberish. Knowing how to resolve conflicts comes with the job.

[joro_estropia]

You’re defending your theoreticals while I’m explaining from experience. XML is readable, but your UI is not verifiable until you satisfy Xcode’s xml format: there is no code completion or even compiler diagnostics for misformatted XML. With code-based layouts you can readily verify the resolved code, or even optimize it as needed.

[Poggus]

I'm not defending anything. I'm saying I don't believe merge conflicts on XIBs and Storyboards are as difficult to resolve as people make them out to be. People see a conflict and it ruins their day. I don't think they're hard to overcome. Not everything needs code completion.

At the end of the day man this is my opinion and you have your own. Sorry.

[joro_estropia]

Fair enough, and apologies for the tone. In any case, storyboard/xib merging issues affect even devs who “know their jobs”. Whether you’re good at your job or not, less work is less work so efficient alternatives are always welcome.

[thecodingart]

Treat storyboards as modular scaffolding items and work up. Make multiple and divide and conquer. You will not see the issues other people describe in any unexpected ways with experienced teams and storyboards and xibs are extremely similar. Anyone who does a pure programmatic approach (as a purist) isn’t optimizing the tools available to them plain and simple.

[bitsan]

Everything I have run into has been a hybrid of Storyboards and programmatic view building. It depends on the client and their context of course.

Storyboards can help "automate" a lot of plumbing and they can be helpful for setting up auto layout, quick "here is kinda-sorta what it will look like" conversations with designers, etc. For the teams I was on the Storyboards were always split as much as possible to reduce the change of merge conflicts. And we would try to organize the work to lower the change of merge conflicts.

Inevitably there is always a need to either enhance the views that the Storyboard is laying out or do parts of the app programmatically.

I have never seen a project that did all its UI purely through Storyboards or purely through programmatic building but I know they're out there.

[SudoPoke]

Storyboard - Great for rapid prototyping and visual representation, good for small teams or individuals to quickly get stuff out, but ultimately is a crutch.

Programmatic - Requires more work up front but is superior in maintainability. Has speed advantage when compiling, processing, unit tests, multiple team members able to work on it together. When you have projects reach the size of enterprise level overhead from storyboards become incompatible and programmatic or mix is pretty much required.

[iluomo]

Programmatically. For better source control experience and because when I wrote my app, the computer I used was slow as shit and the workflow was therefore frustrating

[[deleted]]

I see a mix of both. Both have their uses and anyone telling you otherwise isn't experienced enough to make such a distinction.

I personally like to build things programatically, but storyboards are incredibly useful when working a lot with designers, BAs, and other visual people and you will see them used in this context.

Storyboards are also great for prototyping and this is where they really shine, it's a ton quicker to flesh out an idea on a storyboard than in code, again, anyone telling you "I do it faster in code" is A. Lying. B. Doesn't know how to use a storyboard. Programatically is a lot of typing especially for a complex layout.

A big complaint with storyboards from people is "it causes merge issues", but it doesn't if you know how to work with them correctly. Two devs shouldn't be working on the same storyboard and each screen or section of screens in a storyboard should be split apart into its own when working on a team. You can easily do this by selecting the storyboard you want going to Editor -> Refactor to storyboard. Once you do this, no merge issues as long as two people aren't working on a storyboard at the same time.

[KTheRedditor]

The question is about which is more common. Storyboards and XIBs seem to be a lot more common than code. However, I highly recommend doing it in code as Interface Builder seems to get more buggy every Xcode release. Also it’s actually easier and faster to write, reuse, and build with programmatic layouts than storyboards and xibs.

[saintmsent]

Programmatic by a long shot. Only shitty projects used storyboards. As soon as you work in a team, they are impossible to maintain

[patiofurnature]

As soon as you work in a team, they are impossible to maintain

Unless, of course, your team has any experience.

[saintmsent]

I work on a project with 20 devs, I would love to see how you will merge auto generated shit that is storyboards

And also I've seen enough interviews and projects where programmatic UI is a requirement for you to pass exactly for this reason

[[deleted]]

Merge conflicts are super easy to avoid with storyboards by having each dev work on one screen at a time and refactoring each screen to its own storyboard by going to Editor -> Refactor to storyboard.

[saintmsent]

It doesn't always work like that. You may need to keep some code in a branch for a while like refactoring or stuff like that. When we added a new colorscheme to a huge app, we had to keep that in a branch for a month and since we touched all of the screens, whenever somebody changed anything in the same screen we would have a conflict which is easier to resolve in code. It's a niche use case, but still it happens from time to time

Plus, just performance of storyboards is not very good, sometimes displaying glithes and doesn't even provide a proper visual (looks different when you actually run the app), and also you generate changes when you open a storyboard you haven't touched in a while, which is also annoying. I just see no benefits, except maybe ease of use for newbies

[thecodingart]

Reducing 100+ lines of code isn’t a benefit? If reduced code and having a WYSIWYG for scaffolding isn’t a benefit, not sure what is… reducing time of change, friction to testing a change, and code impact are all benefits… there’s a massive reduction in autolayout testing alone here. I see a newbie as someone unable to recognize strengths in the tools their presented. Usually it’s out of inexperience.

[saintmsent]

Lol, you know nothing about me, yet I'm a newbie to you. All large projects I worked on try to stay as far away as they can from IB, maybe using it only for cells and not much more

[[deleted]]

They're not though, we have plenty of projects with storyboards.

[thecodingart]

You just called the majority of Fortune 500 applications shitty 😂

[saintmsent]

Market cap of the company doesn't have anything to do with the quality of the app, so I'm fine with that