Storyboards are simple and brisk approach to begin making a little iOS applications. However, would they say they are reasonable for all the complex applications? Or, then again when you are working in a team? What are the advantages and disadvantages of utilizing Storyboards? Do experienced designers suggest them?
In light of my 4 years of iOS development experience, I am going to highlight few aspects of using storyboards. So the Simplest question is, do the mainstream apps use storyboards and the answer is YES.
I’m not even going to attempt to guess how many, but I can tell you that I have worked on many apps for clients and company’s projects that are currently in the App Store that are built using Storyboards. Personally, I know many successful developers in my circle, who use Storyboards for developing apps.
Although it is recommended by most of the developers but like all other technologies there are few naysayers developers who does not use them or recommend them. So I looked into more detailed aspects of storyboards. So I try to point its advantages and disadvantages here.
Pros & Cons of Using Storyboards in iOS Development
|Integreated relationships||Merge conflicts are difficult|
|Runtime view of App||Tricky code reviews|
The Main advantage of utilizing them (particularly finished xibs/nibs) is that you can perceive how the screens in your application are connected. When you simply begin chipping away at an in advance venture (or restarting an old one), they give you a simple approach to finish the stream application and zoom out to get an abnormal state review of what the application does.
Runtime View of App
Another preferred standpoint of utilizing Storyboards is that; you get the opportunity to perceive what My view will look like at runtime without running your application. You can rapidly roll out an improvement in Interface Builder and instantly observe what it will resemble – without sitting tight for Xcode to aggregate and run. (Xibs/Nibs also helps you to create runtime view.)
Another advantage of utilizing storyboards is that one can make static table perspectives in them. So in the event that you have a Settings screen, for instance, with tappable lines of static content, Storyboards enable you to rapidly and effectively make them – no code required.
In the event that the advantages sound pleasant, consider the cons, as well, before settling on a choice about whether to fabricate your application with Storyboards.
On teams, Storyboards are deceitful yet tricky to use for the following reasons:
Merge conflicts are Difficult
At a point, when two individuals of a team alter the same Storyboard record, in the meantime, it causes a union clash. It is dubious to deal with how to consolidate the progressions.
Reason: Some portion of this is a result of the organization of the Storyboard record (it’s XML) and part of it is, on account of Xcode improves components and rolls out improvements in the Storyboard when you open it – regardless of the possibility that you don’t touch anything. What’s more, when you do touch something, it’s that much more terrible.
Code Reviews Are Tricky:
In the event that we direct code surveys on our team, assessing changes to a Storyboard document is troublesome. Again, the configuration is XML with heaps of difficult to-comprehend traits and components. So checking on a “diff” and making useful remarks is difficult.
Moreover, those are quite recently the cons to chipping away at a team. Regardless of the possibility that you’re taking a shot at your own, there are a few cons to utilizing Storyboards:
Confusion When They Become Complicated:
On the off chance; you have a generally vast application and you continue including new view controllers; your Storyboard will end up noticeably confounded. Those beautiful bolts that associate one view controller to the following begin covering each other or getting covered up under view controllers – and it’s truly difficult to perceive what’s going on in the application.
Xcode comes to a standstill when opening an extensive Storyboard: Once more, in case we are taking a shot at a moderately vast application. Storyboards can be troublesome since it takes Xcode a while to stack them into the editorial manager.
Personally, I’m working on an app with around 50 controllers in a Storyboard, and it takes various seconds (5-7) to stack the Storyboard at whatever point I need to alter it.
At whatever point I have dealt with a team, we have consented to make isolate Storyboards for various streams to keep away from the perplexity and execution issues of enormous Storyboards. Furthermore, we have generally been mindful so as to impart about which Storyboard we are chipping away at’ before we begin to roll out improvements so we can abstain from dealing with untidy union clashes. The code review issue exists, and will continue to exist, until the point when Apple changes the game plan of the XML in the Storyboard record.
In Ontrack fitness app we had used storyboards. We worked as team as Ontrack is quite large application and it was very difficult task to manage it.
Following were the challenges we faced;
Storyboard file became very large and it was difficult for xcode to manage it.
In a team it was very difficult to handle updates and merging commits.
Xcode take huge amount of time to compile it, wasting a large time on small updates.
So what we did was divide single story board to multiple small storyboards. One storyboard for each feature. While doing this, we not only were able to take advantage of storyboards we also managed to minimize its disadvantages.