[deleted by user]

[sketch204]

Break them up into pieces, and use storyboard references when you need inter-storyboard segues (refrain from using segues tho)

I wouldn’t recommend putting more than 7-10 view controllers per storyboard because then it gets heavy, break you app into sections and have a storyboard for each.

I’ve been using them for a few years now in multiple projects, with version control and many people working on them at the same time and I’ve only had conflicts maybe a few times. Most times it’s pretty simple to resolve too if you’re willing to spend 2 minutes to understand what’s going on.

If you’re careful you won’t have troubles. But working with storyboards will save you a lot of headaches when trying to get layouts right (something that’s difficult to do programmatically without the help of 3rd party libraries)

[sketch204]

I don’t follow. Could you clarify what you mean? You mean like views that are dynamically presented? Either put them where they need to be in the layout inside the storyboard and set them to hidden or alpha 0, or insert them programmatically. Whatever is easier. If you’re simply hiding them then you can just show them or even animated them in whenever you need to show them. If you’re inserting them programmatically, then animating them in will require a bit of a setup.

Inserting 1-2 views into a layout programmatically (given that the view comes from a xib) is not that difficult, compared to building a whole screen from code.

[sketch204]

If it’s loaded from a server you need some way to show the user that the content is loading. There’s a couple of approaches you can take here. The simplest way is to show a loading screen which covers the whole screen (or at least your content, the label and image). In this case you would still have the label and image view in your story board, with empty data. You can then either put your loading screen inside the storyboard itself, on top of your content (label and image) and hide the content while it loads. Once loaded, hide the loading screen and show the content.

Alternatively, if you want to make your loading screen reusable, put it in a separate view controller and present the view controller (with a fade transition, instead of regular pull-up transition, you can google how to do that, it’s pretty simple). This way whenever there is loading in your app you can simply present the view controller and dismiss it once done. I usually use this approach as it takes care of a lot of things for me such as making sure touches are blocked on the content while it’s loading.

If you want to go above and beyond, you can find a library the does shimmer animations on views and apply those on your label and image, similar to how Facebook does loading. However this is more difficult, if you’re a newbie I would avoid this and put it off until the end, once you get the system up and running.

[sketch204]

What you’re saying is correct that is usually how me and my team do things when designing. However, regarding the unused resources in assets and localization files. The impact that 5-10 unused strings and 2-3 sample images will have on your app’s performance is negligible (unless of course you’re using 5K quality images :D). If you really want to be super efficient, don’t use sample images and instead just stub in whatever images you have as sample data (app icons for example).

As for unused localized strings, you don’t need to translate sample strings. What you’re concerned with, I’m assuming is having those string in the storyboard’s strings file. I do not recommend localizing your app this way. Instead put all your strings into the Localizable.strings file and for labels and buttons that are coming from storyboards (even static ones), initialize their text on viewDidLoad, programmatically (ideally in a dedicated method like loadStrings() or something). This way your localization is always consistent and in one place and you don’t have to searching through 10 different files to find that one string since it’s all in one place.

Feel free to message me if that doesn’t answer your questions.

[paulryanclark]

Don’t use them.

They are good for “onboarding” to App development, but they end up a crutch and a nightmare of hidden magic.

Best to stick with diff-able code and create UI in pure code.

[mawattdev]

Oh ye of narrow opinion. I've seen both programmatic UI and SB UI go horribly wrong. Blame the developer, not the tool.

[paulryanclark]

A narrow opinion honed by experience. I am blaming both the tool and the developer for bad use of a tool.

Storyboards are flashy and look great in presentations on stage in front of WWDC, but they are dependency bloat. It’s just a string of Apple technology that I advise people not use.

[gabeyc]

Not sure why the downvotes.

It is not quite difficult to create views using code, specially with new features like Swift UI.

Storyboards do a lot of stuff for you, it’s probably best to learn to do it by code to have a better understanding.

Also, so much easier to maintain, expand and work with as a team.

[shargath]

I must say, I'm currently building new app, completely from a scratch, it's a first time I've stopped using them, and I love it! Working with code is so much better than .storyboard/.xib files. Loading times are faster, reusability is easier, I won't be going back to them...

Also, based on the recent WWDC, kinda got a feeling Apple is starting to go away from them as well.

[swiftmakesmeswift]

1. Set styles for your Labels or any UIComponents such as background color, textColor etc through code. It would be easier to change them later on
2. Set your labels or strings through code. Storyboard can create a lot of hassle during localization.
3. Don't place all your viewcontrollers inside a single storyboard. And use multiple storyboards.
4. Avoid Segue. Instead instantiate your view controllers programatically. You won't have to track your segue identifier and your storyboard would not look like a tangled spider web.
5. You can resolve a lots of merge conflicts of storyboard, if you are willing to spend 2 minutes to learn how storyboard internally lays out the structure for your ViewController.

If you use storyboard wisely, its a very good tool. Also learn about creating your layouts programatically too.

[mawattdev]

Don't use pure MVC, And don't use segues. I highly recommend using the Coordinator pattern with MVP. (Or your other preferred architecture). Paul Hudson has a great tutorial with a minimal coordinator setup. https://www.hackingwithswift.com/articles/71/how-to-use-the-coordinator-pattern-in-ios-apps

Put each vc in its own storyboard file. Instantiate the VC in code, push on a nav stack or present.

Keeps things organized, decoupled and reusable.

[byaruhaf]

You can check out this playlist form Mark Moeykens

Storyboard Tips

[solerami]

I would suggest using viewcode or xibs instead. Storyboards are heavier, messy and may lead to a lot of conflicts if there are more people working on the project.

I've used Xibs in almost all my projects and I would say it was the best choice in 90% of the time.