iOS, Xcode, Storyboards…our story so far in the Apple world!
Since the inception of my software consultancy journey two years ago, I’ve had a chance to delve into multiple aspects of full-stack development. One of the cornerstones of our consultancy has been iOS development. Providing quality iOS consultancy services to clients proved to be a challenge initially. This was due to multiple reasons…(why on earth would Apple take 2–3 weeks just to approve a simple App! 😮 ). We made mistakes, learnt from them quickly, never to repeat them back. Recently I got an opportunity to share our learnings of iOS Storyboarding @ SwiftIndia, PuneChapter.
In this post I’d like to share the same lessons while using iOS Storyboards.
We got our first iOS App requirement in early 2015. We were all excited to deliver goods on this opportunity. By that time I had experimented on iOS stack, got acquainted with Xcode and the fairly new Swift (as compared to ObjectiveC) language. The concept of storyboard was appealing since it had multiple advantages when I started out. A few of them were:
Storyboards provided a complete conceptual overview of the App
They made understanding of views and corresponding transitions easy
With storyboards the AutoLayout became a lot easier
In form storyboards Xcode provided an excellent tool integrated right into the IDE from designer point of view
Storyboards helped achieve speed up in designing and prototyping
Exploiting the obvious advantages of storyboarding we built Apps for our first couple of clients. Since prototyping was super fast, the iOS development timelines were correspondingly faster as compared to our Android development.
Until this point we were using a single storyboard for the entire project and continued the same strategy for our new requirements, until one fateful project which resulted in a strategy shift in terms of our storyboard usage. We were approached by a medical services aggregator for their App development in late 2015. This App was an aggregator of medical services like clinics, hospitals, pathology labs, chemists, ambulance-services etc. We completed the design phase and started building the corresponding storyboard for the App. However, we observed the following concerning issues:
App had 51+ screens on a single storyboard, and it started becoming too big
As a result, the storyboard loading time started getting bigger
Storyboard flow started becoming glitchy, which made working on it a challenge
Repository merging conflicts started becoming real pain as multiple developers started working on the project
With these issues, we started pondering over the possible solutions. We assessed the suggestions given in the tech. blogs, did our study, and came up with the following action plan:
Separated the functionalities into multiple storyboards
Made One-to-One mapping of storyboard and the corresponding controllers
View-Controller separation based on functionality paved way for less repo merge conflicts since every developer worked on one functionality at a time
And voilà! The storyboards started loading smooth-n-easy. They became lucid and functional. With this strategy we thought that we had found a success formula for iOS App Development! We built the next few Apps using the storyboard breakup approach and everything seemed under control for a while.
It was mid-2016 when our perception of iOS storyboards and their working changed yet again. We got a requirement from a client in EduTech domain to build an App for training of SalesRepresentatives in big retail stores. The App was to be launched across Asia, Australia and Europe; hence, had to support localisation. It contained a lot of multimedia-rich training content including text-with-audio-sync, videos, animated quiz etc. We started all guns blazing using the strategy we had learnt and the expertise we had gained over the development of past Apps. Everything seemed to be working fine across the devices we had (iPhone 6, iPhone 6S, iPad Air, iPad2), and we were updating the App UI as per the client feedback.
However, one day we were perplexed when we tested the App on iPhone 6S Plus, and found that the constraints that we had set for the labels were not working across the devices of same size-class/traits. For e.g.: The size-class/trait for iPhone6S and iPhone6SPlus is the same in portrait mode. Even then there was a difference in appearance of layout.
This was nothing short of a disaster! Our text (label) positioning constraints started breaking across the different devices (6S vs 6S Plus). Moreover, handling the constraints and dimensions became a nightmare. Convincing the client that this issue needed a considerable rework was a huge task in itself. After a few discussions the client graciously agreed on the delay, and we set forth to work on a solution for the same.
Finally we came up with the following solution: We removed the existing layout constraints of various elements in a screen, and updated the same at runtime based on type of device. This strategy was a saviour, and we could successfully deliver on the project.
To conclude, I’d say that we’ve learnt the following about storyboards during our journey in iOS development till date:
Storyboards are awesome for quick prototyping
They provide a great bird’s eye view of complete App workflow
However, as complexity increases the storyboards tend to get slow to load, inconvenient to traverse, and need to be broken down in order to exploit their advantages
Autolayout works best independent of constraint dependencies for devices belonging to the same size class
If ever there is a need of laying out elements relatively, then to cater to the layout constraints for different devices of same size class, one needs to enforce them at runtime
As true as a life philosophy, almost nothing in the world is inherently good or bad…it depends on the circumstances, scenarios and time! I guess same is the case with iOS Storyboards… 😉
- Peace \m/