Autolayout is a cool feature Apple introduced several years ago which transforms the way in which developers think about laying out their views. In short, autolayout is incredibly easy to set up and use with Interface Builder – but quite a pain in the neck when doing so in Objective-C code.
For those of us code purists that refuse to use Interface Builder – the question remains – to use autolayout or NOT to use autolayout? Should we just continue to set the frame of each view and simply set the autoresizing mask when the view needs to be adjusted dynamically? After all, adding and removing constraints is a real pain, so why not just set the frame and have a nice day?
My answer is the following: always do what is simplest and works best – the path of least resistance is the golden path. In some cases, the extra overhead of laying out views with autolayout in code is actually worth it! This applies for universal apps with a responsive design that must adjust to screen rotation (portrait and landscape mode). But for those apps that only support one screen orientation on a single device type, it may be simpler to set the frame in code.
The debate between using NIB Files vs laying out screens in pure code has been raging on since the birth of Apple’s Interface Builder. In one camp are the visual developers that love being able to see their screen in Interface Builder and laying all views out visually. In the other camp are code purist developers that worship code and detest any tools that do “magic and wonders” behind the scenes but with little to no understanding of the magic. The battle is symbolic of the ongoing rivalry between the two biggest mobile companies in Silicon Valley: Google and Apple. Google has banned the use of NIB/XIB files several years ago in their iOS projects – while Apple has made it clear that NIB’s are the preferred way to go.
I am NOT here to fight for either camp. I will only say that developers should be able to work in whichever way they prefer – what is good for me may NOT be the best for another developer. So long as everyone is happy – I don’t care what is your sexual orientation, ethnicity, nationality, religion … or your coding habits (that is so long as you deliver quality work).
That being said, with the release of iOS 8 and the larger screen sizes introduced with the iPhone 6 and iPhone 6 Plus, developers in the pure code camp may be in for some trouble! Several years ago Apple has introduced a new technology and screen layout methodology known as Autolayout. What exactly is Autolayout? From Apple: “Auto Layout is a system that lets you lay out your app’s user interface by creating a mathematical description of the relationships between the elements. You define these relationships in terms of constraints either on individual elements, or between sets of elements. Using Auto Layout, you can create a dynamic and versatile interface that responds appropriately to changes in screen size, device orientation, and localization.”
For anyone that has tried massing around with Autolayout using Interface Builder – you’ll soon realize that it doesn’t take long to learn the ropes and get moving quickly with it. For anyone that has tried getting Autolayout to work in code – good luck! It’s a real pain in the butt. A single view rendered in code using Autolayout requires some 20 lines of code – and NOT only in Objective-c – but in a whole new language called Visual Format Language (VFL). As if learning Objective-c wasn’t hard enough to learn …
The alternative to Autolayout (and its predecessor) is simply setting the frame of the view in code using an old and favorite function known as CGRectMake. If the view has to be dynamically resized for any reason – no problem! All one has to do is set the automask property of its subviews to resize along with their superview.
The issue with this old and trusted approach is that the new phones released last month have a larger point resolution than the 320 point width of the older iPhone 3/4/5. You may ask yourself, why didn’t Apple simply make the iPhone 6 and iPhone 6+ have a 320 point width so that existing apps wouldn’t have to be re-written? There are many answers to this – but my guess is that Apple expects everyone to migrate to Autolayout along with Interface Builder – and if you don’t … well, you’re on your own.
Initially, I decided to throw in the towel and become another lamb in the Apple clan – but then I remembered why I became an iOS freelance app developer in the first place – I have a brain and I like to use it for myself! I stared thinking about how I can continue to set view frames in code without reverting to Interface Builder or spending 100’s of hours writing Autolayout in code. I soon came up with two solutions to this problem – and both are working like charms for me. If anyone is interested to learn more – simply contact me and I’ll share the two solutions (it’s simpler than you may think).
There are plenty of wire-framing software out there. Among them is the well known Prototypr, FluidUI, UX Pin, Balsamiq, Moqups, Proto.io, Mocking Bot, Mocking bird, Pidoco, Appery, Realizer, Mock Flow, Hot Glue, Mokk.me, and the famous and industry loved Invision. And for the real pros: Photoshop. But there is an easier way to get started: Enter Google Drive Drawing! Below is a link to a complete wireframe for a simple five screen iPhone app that I was able to make for a prospective client in the span of only 30 minutes:
Example Wireframe Set
The beauty of Google Drive Drawing is that you can remotely share it with your client and update it in real time for them to see.
As can be in seen in the wireframe set – it is incredibly easy and fast to make these wireframes! Start out by asking your client: “What is the first thing the user will see when they enter this app”? Then simply place down on the screen whatever UI elements the client tells you. As you start drawing buttons and inserting images – the client is impressed and at the same time excited by your ability to quickly and seamlessly take an abstract idea for an app and put it on paper.
It is important to pick the client’s brain about every UI element that you end up drawing. You’ll be asking questions such as:
1. Which screen will this button take the user to?
2. Does this screen need a back button?
3. What happens when the user presses the pin on the map?
4. What will the be the popup message if the bar code scanning fails?
The answers to all these questions must be written clearly and expounded further in the form of annotations which appear below each wire-screen.
Imagine being able to scope out every small detail of an app within the span of an hour? You and your client are on the same page – the expectations of the project are NOT only evident – but clearly visible – and if there are any design mistakes or loopholes – those can be easily traced and addressed as well. As a designer or developer you now have a solid foundation for giving the client a solid quote for the next phase of the project.