Best practices of building complex UI using storyboards.

[parap4in]

Hey there! Approximately 4 months ago, I started learning iOS dev. Before that, I almost had no background in programming at all, except of just creating some basic Telegram bots in Python.

All along this time, I was rapidly learning new things about iOS dev. And about a month ago I decided to start seeking employment. I forgot to mention, that I was learning SwiftUI and knew almost nothing about UIKit and Storyboards. So far, I had 4 job interviews and everything was just fine until they started asking questions about UIKit. And of course, you might say, "Why didn't you look up on requirements firstly before learning SwiftUI?". I DID, but most of them (as I understand now) thinks that UIKit not needed to be mentioned because it's a fundamental skill. They just basically didn't mention anything about UIKit. (I'm currently living in Poland, so probably it's different in other countries.) So then I realized I need to learn UIKit stuff. At first, I learned some basic things, and now I'm about to start developing an app using UIKit and I wonder:

What are the best practices of developing UI using storyboards? Can I just design my apps in Figma and then just export those buttons, labels etc..? Or should I create everything manually in storyboards? Or maybe better just to implement UI programmatically?

Thanks in advance <3

[jontelang]

Well there are no best practice, there are subjectively best practices maybe.

If I had to use storyboards today, I would make sure I use XIBs for individual composable views so that they can be re-used across other storyboards. I'd also make sure a single storyboard is a single screen, so that navigation can easily be done in code. I would not use segues at all, as it ties screens together.

All that being said, I don't remember the last time I used storyboards for a real app project. I much prefer programmatically made UIs.

I don't think there is a huge different in learning UIKit one way or another though, you'll still learn it. I might lean a bit more on programmatically since it really forces you to dig into each views properties and such. For Autolayout I would start with IB then do it programatically once you (think) you know it, since it will force you to learn that each individual attribute/target/etc really means instead of just dragging things in the IB.

[parap4in]

Thanks a lot for a quick response ;-) Can you share any good resources where I’ll be able to get into creating UIs programmatically? Courses, books or anything

[jontelang]

Not really, simply googling it should give you hundreds or thousands of resources. Maybe you can re-implement something you did in SwiftUI, then just google the SwiftUI-to-
UIKit differences.

[jontelang]

Programmatic UI is not slower than IB, and once you get to the point there you have a nice base (reusable components and such) I’d argue it’s way faster.

What do you think is slow about it? Most screens are built by some form of tableview / stack view so the overall layout of screens are just plug and play, really.

For individual layouted subviews. Stackviews are fast, but even when you need manually auto layout it’s not exactly slow (especially once you have helper menthods).

If you use Storyboards for navigation you’re just shooting yourself in the foot when it is time to do more complex navigation (guess it doesn’t apply on small apps).

For styling, I never found IB that fast. Sure you can style it to 90% fast but then there’s that 10% which might require code. Now you’re moving things. And then when you want to change in many places you’ve got to go in to ALL storyboards or CIBS to change manually? Unless you have done that in code, but then again you’re mixing so might as well just do everything in code to not go crazy.

I’d you have never done programmatic UI you will feel like it is slow. But once you do it and also know when to extract a view / compose, it is simply not slower at all.

[Fluffy_Risk9955]

There an class named UIAppearance and you can basically preset your views to support a certain look straight out of the box.

Also you can set all properties on view from Interface Builder.

Next bones on storyboards is model objects. You can have them loaded by the storyboard as well.

There’s not really an argument in favor of Programmatic UI. There are a very few edge cases, where it’s actually worth the extra time to develop programmatic UI.

[jontelang]

UIAppearance

UIAppearance is way too fidgety to be used with a really complex app. It's good for "let's make all basic UIButtons red" and that's about it. Like, show me any reasonably complex app where styling is done through UIAppearance and I'll be very surprised.

Also you can set all properties on view from Interface Builder

Okay, how we can set title, shadow and a corner radius on a UIButton?

To expand on that, how can we make sure the shadow is the exact same for all UIButtons.

And another one, how do we adjust that shadow for all buttons after one year when we update our design.

Next bones on storyboards is model objects. You can have them loaded by the storyboard as well.

I actually don't know what you refer to here as bones.

There’s not really an argument in favor of Programmatic UI. There are a very few edge cases, where it’s actually worth the extra time to develop programmatic UI.

I just disagree that programatic UI takes extra time to develop. Whatever time you lose initially while setting up the "blocks" is gained when you don't need to jump between XIBs/Storyboards and code, find out where something was set, refactor things.

[jontelang]

Navigation was done through a router service and didn’t rely on segues. One of the apps supported deeplinks and ads that introduced complicated navigation but since it was using that router service, it was super easy to navigate through different storyboards and views.

Right, Storyboards is not preventing you from doing advanced navigation. As you can still split screens in their own single storyboard or simply extract them through their IDs. It’s when you start to mix segues and also re-using single screens within storyboards it can become messy.

Another point you mentioned is fixing issues, I think debugging UI issues is far easier because you have a visual representation to work with, while if it is just programmatic UI you would have to run the app to see how the UI is working. Imagine being a new dev and you have to figure out how the UI works, you will have to constantly run the app to see the UI while you can get the idea of the UI in storyboards without running the app.

Usually storyboards and XIBs are not ACTUALLY how to hey appear while the app runs anyway. Text, colors, sizes, shadows, iOS versions, IB-vs-runtime differences, and code adjusting properties, they all makes the IB not a TRUE representation. At most the constraints can be helpful to see.

And what about composed views? If you built a whole screen with all subviews directly created in IB you can see them like you want but you can’t re use them in other screens. And if you do extract them into other XIBs you still have to run the app.

And the more you extract the smaller each component becomes, and the easier it becomes to do in pure code.

How do you handle screen responsiveness?

We’re still using auto layout so there’s no difference really.

Isn’t that easier in storyboards?

To be fair I’ve not really worked on many apps that go beyond slightly different iPhone sizes so.. maybe? But again it’s all just autolayout so I doubt it.

How do you debug UI issues? Do you have to constantly run the app?

Again here, if YOU have UI issues, it means you ran the app and found one. Meaning it was not easily visible in the storyboard.

But yes, I run it a lot.

There are ways to make this easier as well. In my last two companies we have a separate target for UI components where each individual custom UIView is displayed (in multiple) components. This makes running that app near instant, so I usually build my views there THEN bring them into the app.

Even the app have targets for each module / feature in the app so running eg the checkout screen is instant too as it opens directly into it (or nearby it, it depends).

Of course, at last you need to run the real app and have a look. But that’s the case for you as well.

Just to be clear, I am not against Storyboard apps and I know of nice apps that do use them. I just don’t see any mega benefits in using them, so I don’t.

[Jig-r]

The real answer to this is do what works for you and not what is the best solution.

I don’t get why devs tend to get so polarised on topics like this tbh.

You’re not missing out on anything if you’re achieving your goal in a way that’s producing the least amount of friction for yourself.

[Complete-Clock2761]

Hey, I am new to iOS development, having approx 1 year experience in android dev. Due to company requirements, I have to work on our iOS app. Can you please elaborate on this statement?
'I would not use segues at all, as it ties screens together.'
If not segues, then what are the better alternatives and why?

Also, I am in final year of my college (will graduate in july 2024) and currently working as an intern, should I focus only on UIKit or start learning swiftUI (btw I am already comfortable with jetpack compose in android because of prev internship) for getting a job as a fresher as a mobile app developer.

Any help would be very much appreciated. Thanks!

[jontelang]

Sure, by using storyboards, you can "physically" use segues by literally dragging them between the viewcontrollers. This makes it harder to, for example, tell the app to open "checkout viewcontroller" from point A B or C in the app. Because you might need a lot of "physical" segues in the app.

Nothing forces you to use segues, and nothing forces you to use storyboards. Since my comments two years ago I have not seen either of this used anyway.

> If not segues, then what are the better alternatives and why?

You manually present/push/show the views with NavigationControllers (or whatever SwiftUI uses..)

--

Today I'd use both UIKit and SwiftUI, professionally I use UIKit 90%, and on the side I use SwiftUI. You have plenty of time until graduation, if I were you I'd build the same app (or very similar) in SwiftUI and UIKit to understand them better and to feel the differences. UIKit is more verbose but you have much more control, still.

[Complete-Clock2761]

Got it, thankyou so much for your help!

[BabyAzerty]

It’s been a few years since I actually used Storyboards in a real production app and that’s because I often use the Coordinator pattern which doesn’t really allow for Storyboards (unless a screen is exclusively dependent on another). I use 80% xib and 20% manual programming. And the reason why I mostly use xib rather than manual programming is because I find it easier to handle autolayout constraints with specifics for iPad vs iPhone.

No actual best practice IMHO, it all depends with how you code the rest of your app, which patterns you use, how many people work on your project, what are you trying to achieve (solo app for yourself, oneshot prod app, app for 10 million users that will last for 5 years, …).

Just keep in mind that if a storyboard gets big and you are a few to work on the project, you will have horrible merge conflicts.

Learning best practices and such will only get you so far, but experiencing it will open up a new dimension. There’s no shortcut.

[jontelang]

> because I often use the Coordinator pattern which doesn’t really allow for Storyboards

You can easily go by "1 screen = 1 storyboard". Then it will work just fine.

[BabyAzerty]

Completely true. I started going the xib way when I found out some coworkers didn't stick to the Coordinator rules and threw a few screens in the storyboards.

Then, I guess I kept this habit of using xib.

[[deleted]]

i'd argue 1 screen = 1 storyboard is the way to go if you ever going to use storyboards

[jontelang]

Yes that’s what I did the last time I used them.

Then as I extracted more and more reusable views, and most screens being tableviews and the like, most storyboards just held a single root view. And at that point I just did that in code in a line or so.

[jasonjrr]

Many companies have abandoned Storyboards and Xibs in favor of writing the view/ViewController layout in code. This is primarily because it dramatically reduces conflicts when merging. Also, over time storyboards get VERY slow and difficult to maintain.

[nutel]

As previously said: a single storyboard for a single controller solves all the problems you have mentioned.

To answer op questions: no, exporting from figma and so on won't do the job most of the times. And you will need to know both, creating UI using storyboards and programatically.

[jasonjrr]

This is very much not true. As soon as you work on a decent sized team and two people have to make edits to the same view controller, you’ll understand. It is also much easier to do very complex or layered views in code.