Storyboard v/s SwiftUI

Every experienced iOS developer is familiar with Interface Builder and storyboards, and perhaps even XIBs too. They might not like them, but they are at least familiar with them. If you haven’t used these before, you should just skip this bit.

Still here? That means you’ve used IB before and are probably curious how SwiftUI is different. Well, let me ask you this: have you ever edited a storyboard or XIB by hand?

Probably not. Well, apart from that one time once, but broadly the answer is no – storyboards and XIBs contain a fairly large amount of XML that isn’t easy to read or easy to edit.

Worse, storyboards have a habit of growing larger and larger over time. Sure, they might start off small, but then you add another view controller and another, and another, and suddenly you realize that you have ten screens of data in a single file, and any source control changes you make are suddenly quite painful.

But although being a single point of failure isn’t great, and it’s basically impossible to see what’s changed when someone opens a pull request with a storyboard modification, storyboards and XIBs have a bigger problem.

You see, Interface Builder doesn’t know much about our Swift code, and our Swift code doesn’t know much about Interface Builder. As a result, we end up with lots of unsafe functionality: we Ctrl-drag from IB into our code to connect something to an action, but if we then delete that action the code still compiles – IB really doesn’t mind if the code it intends to call no longer exists.

Similarly, when we create view controllers from a storyboard or dequeue table view cells, we use strings to identify important objects in our code – a system so pervasive, it even has its own name: “stringly typed APIs”. Even then we need to use typecasts because Swift can’t know that the table view cell it got back is actually a MooncakeTableViewCell.

These problems exist because IB and Swift are very separate things. This isn’t a huge surprise – not only does Interface Builder date from way before the original Mac OS X was a thing, but it’s also very much designed around the way Objective-C works.

SwiftUI makes a hard break from that past. It’s a Swift-only framework, not because Apple has decided that it’s time for Objective-C to die, but because it lets SwiftUI leverage the full range of Swift’s functionality – value types, opaque return types, protocol extensions, and more.

Anyway, we’ll get onto exactly how SwiftUI works soon. For now, the least you need to know is that SwiftUI fixes many problems people had with the old Swift + Interface Builder approach:

• We no longer have to argue about programmatic or storyboard-based design, because SwiftUI gives us both at the same time.
• We no longer have to worry about creating source control problems when committing user interface work, because code is much easier to read and manage than storyboard XML.
• We no longer need to worry so much about stringly typed APIs – there are still some, but significantly fewer.
• We no longer need to worry about calling functions that don’t exist, because our user interface gets checked by the Swift compiler.

In the interface builder like storyboard and xib you can see what you are doing. You take a component and then add it to the storyboard and that’s how you design the UI, but if you do the same thing programmatically then it gets a lot harder as you can not see anything and you have to be experienced to do so. Every time you have to build an app to see the changes in the UI but SwiftUI solves this issue as it gets updated constantly as you write code. To solve this, Apple came up with SwiftUI which helps you to see what is going side by side. Anyone can move from Storyboard to SwiftUI.

Personally, I have started from Storyboard then moved to XIB and then I went to Flutter which was quite different and SwiftUI is quite inspired by Flutter. You have to keep in mind that SwiftUI support starts from iOS 13. You have to start from storyboard and then when you have gained experience then you can move to SwiftUI.

An honest response:

The debate between the newly released SwiftUI and the Swift Interface Builder is never-ending, with each and every person with their own unique thoughts and opinions. I’ve come to settle this, by looking at the different properties of both SwiftUI and the Interface Builder.

Both are equally capable, but its all up to the developer and their specific needs. With that in mind, I will talk both about the advantages and disadvantages of SwiftUI and the Interface Builder (Storyboard).

SWIFT UI:

Swift UI follows more of an interactive side to programming, with the environment being far more simple and easy to understand.

The drag and drop concept in SwiftUI makes it far easier for the user to understand how Swift works without getting intimidated.

Unfortunately, I found that SwiftUI can increase the chances of errors in the view since there are very big consequences for placing an element in the wrong place. Since SwiftUI isn’t that detailed, its, at times, hard to be sure if everything is perfectly correct and in-line, thus making the entire debugging process more time taking.

On the other hand, SwiftUI is absolutely perfect for beginners, with terms and methods of implementation being boiled down to a couple simple words. Since its quite new, there are very less tutorials and most likely, not many of your questions have already been asked on Stack Overflow.

Does this mean you should completely abandon SwiftUI? Hell no!

Just like Objective C, Swift was a language that people took time to migrate into. Now, nearly every iOS developer is using Swift for their projects. The Interface Builder has been in the eyes of the public for a long time, but Swift UI is coming up quite fast. It definitely won’t be much of a surprise that Swift UI turns out to be the next “big thing” everyone is jumping on after a couple of years. Better off to get a head start, right?

SWIFT INTERFACE BUILDER:

Similar to SwiftUI, the Interface Builder relies heavily on the concept of visualization and making concepts and the entire process of development easier of a developer.

Unlike SwiftUI, there are TONS of resources on the Swift Interface Builder from tutorials on YouTube to amazing and in-depth courses on Udemy. If you ever have a question about a bug or an issue you might be facing using the Interface Builder, there’s a 90% chance it’s already been asked in Stack Overflow, therefore making it easier for any developer to speed up their debugging process.

The detail and work put into the building of the Interface Builder is clearly imminent as soon as the user opens up a project using Storyboard. Its far easier to navigate to certain specific places in your project.

Unfortunately, this only applies to those who HAVE experience using Storyboard. Without prior experience, it can be a living hell to new programmers who have no experience with any platform similar to Xcode at all.

In addition, there definitely are a lot of technical problems with the Interface Builder. One of the most noticeable are merge conflicts, where a user might want to move their files or code to another project. This would pose numerous problems in terms of dependencies. Resolving such issues usually take hours, depending on how many files you moved and how large the project is.

If you’re building a big and complex app, the Interface Builder shouldn’t be your first choice. While the Interface Builder gives the user the ability to create segues between different views, a app with multiple pages and a complex design can make this entire flow quite hard to understand, which could lead to further problems.

For example, overlapping arrows or arrows hiding behind other View Controllers can make the entire process time consuming and making the code more prone to further errors.
— — — — — — — — — — — — — — — — — — — — — — —
With all this said, I would like to once again state that both platforms are absolutely amazing, but vary in need based on what the developer wants to make.

To learn more about Swift and programming and get content like this, make sure to follow me! Thank you, the support means a lot!!!

Performance is quite better as compared to a storyboard.

CONS:

1.Requires enough expertise for iOS app development.

2.Small changes required in compilation of source codes.

To eliminate such problems, Apple has introduced Swift UI.

There are always some advantages and disadvantages of new technology and now we are going to figure out them.

Advantages:

1. Easy to use, less number of codes for larger purposes.
2. With its declarative property, you don’t have to compile code every time as changes will reflect immediately.

Disadvantages:

1. If you wish to give the support before iOS, you cannot adopt the Swift UI.
2. It‘s a new technology and different from traditional Apple development.

In my opinion, Apple brought major changes in its development technique which is quite surprising for the majority of developers at first but as I can see that this is a much better option rather than resolving the conflict on a server and handling a larger bunch of codes.