Hussain Fakhruddin
Latest posts by Hussain Fakhruddin (see all)
- How do mobile apps help small businesses? - October 10, 2019
- Top 15 Mobile App Ideas For 2020 - October 1, 2019
- Top 15 Software Development Trends To Watch Out For In 2020 - September 18, 2019
App developers working with storyboards often rave about the extra speed advantage that they offer. There are several other advantages of storyboarding too, along with a few (admittedly, rather minor) problems. Let us here find out whether the highs of Storyboards indeed outweigh their lows.
The practice of designing the entire interface of apps programmatically is on the wane. For scene designing and transitions, most professional mobile application developers prefer using visual interface builders, like Storyboard or XIB. The former, in particular, has become extremely popular worldwide – since its debut with the iOS 5 platform. We have here diagnosed whether Storyboarding is indeed worth the hype:
- Visual help – Apart from offering real-time app design and transition views, Storyboards come in real handy for table-viewing. The feature has built-in static cells and prototype cells functionality – which helps iphone app developers to iron out errors while working with tables in the app infrastructure. Doing the same via manual coding involves a lot of extra hassles.
- XCode problems – With XCode 6, this is more of a rarity – but reports do come in about bugs in the XCode framework developers are working with. While storyboarding, presence of these bugs necessitate complete flushing of the DerivedData folder (at times, more than once). Otherwise, there is every chance that the concerned app will have inconsistencies in its designs/scene transitions.
- Data addition – Many iOS app developers (particularly those who have taken the pain of having to manage delegate patterns earlier) love the segue unwinding option in Storyboards. With segue, relatively short and simple method calls can be used to build up the interaction between the view controllers that are being used. As already pointed out, with XCode becoming progressively more robust, chances of errors while adding data/code snippets are also going down.
- Working in a team – No matter how great individual developers might find the concept of storyboarding, there is no way a full app development team can use Storyboards. The reason is simple enough: everyone can (and probably will) update/modify the root file(s). As a result, confusions can easily ensue. Storyboards are meant to be used by a single mobile app designer at any time.
- Prototyping and multi–device compatibility – Creating detailed app prototypes is vital, and Storyboards are instrumental for this purpose. Most contemporary companies are into making apps that are compatible with a wide range of iOS devices. This is yet another area where storyboarding proves to be a smart option. Multiple views can be organized with ease on a Storyboard. The alternative would have been separately naming the files – and that is not a convenient option. At all.
- Support for previous iOS platform versions – All the buzz is about iOS 8 at present – but there still remain many iPhone app development experts who create apps for iOS 4.3 (or similarly older versions). They have no chance of checking out the advantages of storyboarding – since Storyboards were introduced with iOS 5, and there is no downgraded support option available. Not many developers still take up iOS 4 projects – but for those who do, programmatic designing is the only way to go.
- Types of transitions – The chief purpose of Storyboards has always been facilitating scene transitions in apps – and it’s fair to say that they more than satisfactorily fulfill this requirement. Developers can use several types of Segues (depending on the precise need of their projects) – ranging right from Modal and Push Segues, to the Unwind and the Sourceless Segue options. There is even a Custom Segue feature – which can be maintained as a subclass of UIStoryboardSegue. To make app UIs properly customized, Storyboards are indeed a big help.
- Need for coding for mockups – Minimal, and at times, nil. Storyboarding allows users to create mockups of their apps, without having to write big programs and complicated codes. As a direct result, chances of app designing mistakes are also lowered. For creating mockups of certain types of app designs with Storyboards, there is no need for coding at all. Fair to say, storyboarding has taken away much of the complicacies associated with creating mockups.
- Are Storyboards ideal for all apps? – Such a sweeping statement in favor of Storyboards would not be accurate. They make the ask of developers working on apps with a limited number of screens and a relatively simple in-app navigation/transition really easier. However, for projects that involve larger amounts of complex coding, working with Storyboards is not the smartest idea. Data handling can become a tough task, which, in turn, lead to design mistakes cropping up.
- Initial design placements and modifications – The most proficient of app developers would agree that programmatic UI/UX designing involves multiple (often, troublesome) iterations – at least in the initial stages. Storyboarding is probably the best way to do away with such problems. Correct (read: ‘pixel-perfect’) design placements at the first go becomes easier than ever – and what’s more, making changes is a straightforward process too. On this count, Storyboards are way more flexible than XIB.
- Merging conflicts – This is one rather frequently-faced downside of Storyboards. App developers often need to merge Storyboards in GIT/SVN – and if the boards are conflicted, things can get messy pretty soon. There are ways to work around such merge conflicts, but if you are new in the domain of iOS app development – you might not be familiar with them yet. Suffice to say, Storyboards are not completely optimized for GIT/SVN.
- Need–based usage – There is no compulsion that Storyboards have to be used right from the start of any iOS application development project. A developer can simply uncheck the Storyboard option when (s)he starts to make an app – and move over to storyboarding later. Starting off new projects with Storyboards is often unnecessary, and it’s easy to avail of this feature whenever it is actually required.
- Sharing designs – It’s an ‘all-or-nothing’ scenario with Storyboards. Apart from the odd problems that developers might face while making app transitions/scenes with a large number of views – storyboarding makes it virtually impossible to share single files. While sharing, the entire set of files have to be transferred. This can make the overall process more time-consuming. As already highlighted above, there is no file owner in a Storyboard.
- Creating demo projects – Nearly all decent mobile app companies have the policy of sharing demo views of apps to clients. Working with Storyboards is the simplest possible way to add mock data to the user-interface of any project. With repeated additions, the overall workflow/functions of the app can be built up – and that too, with minimal amounts of coding. The demos created with Storyboards are generally interactive, which makes it easy for clients to check their projects thoroughly, and give their feedback.
Contrary to what most programmers believed earlier, XIB can be included in Storyboards, if and when required. Storyboarding can be used to make apps that are optimized for both iPhones and iPads – which rules out the need for separate device-based customization. From the above discussion, it might appear that Storyboards are a bit of a mixed bag, with a fair share of demerits. However, the disadvantages that we have pointed out can mostly be worked around – and it won’t be out of place to say that storyboarding is indeed helpful for iOS developers.
Have you worked with Storyboards? If yes, do share your experience…