auto-layout · gui · ios · objective-c

Does iOS really need any kind of auto-layout?

ios9

In case it’s not clear from the above image, a Google search result,, apparently iOS 9 is the biggest iOS release ever. Whatever that means. All I know is that lots of folks are talking about the shiny new adaptive layout, but once again, after losing a day twirling around this new toy, I’ve come to the conclusion that some for-idiots style widgets should be avoided…and autolayout continues to be one of them.

Laying out GUIs for different screen sizes doesn’t have to be that hard.Different screen sizes don’t bother me programming-wise is that I make no assumptions about screen size…or at least I try not to make any that matter. Every UIVIewController I use first detects its window’s width and height and does all layout relative to these measures precisely to ensure that view components are laid out in a way to preserves a desirable appearance over many screen sizes.

The .m header for almost every view controller I use starts this way:

@interface ViewController()
@property float height;
@property float width;
@end

Which is then initialized in viewDidLoad:

- (void) viewDidLoad {
...
self.height = [[UIScreen mainScreen] bounds].size.height;
self.width = [[UIScreen mainScreen] bounds].size.width;
}

Then all layout is done in terms of these two constants. Also all UITextViews and UILabels are resized to content, and content itself has a font that can be chosen in response to screen size. Smaller screens get smaller fonts…to a point.

I’m sure there are downsides to this, and sometimes I deal with those downsides. There’s a lot of boilerplate, but over time I have built up many well-structured and easy-to-read starting templates that suit me well. Also I know the newer adaptive layout schema lets you include or not include things according to screen size. I’ve built view controllers on my own that do this too, and the nice thing is that when I build them I know exactly how they work and my imagination is the limit, not the Xcode manual. I am often disappointed by how happy iOS developers are to avoid writing code and take the for-dummies Xcode button clicks approach.

In contrast to coding, all I see are downsides on the side of auto or adaptive layout. I’m no expert at autolayout, but I’ve worked with through some tutorials, including a full day with the new Adaptive Layout.  I’m not impressed.

All I see are traps for the unwary and the same drudgery of any GUI layout any programmer faces, but now enlarged a million times because check boxes and links and text fields in the Xcode application must be checked rather than just plain text. When you use auto or adaptive layout, your project is not what you see is what you get in terms of the code. Rather you’ve got to check dozens of places to make sure everything is alright, and trouble-shooting no longer becomes as easy as putting in a few breakpoints in a debugger or commenting out lines of code.

So here’s my list of why I’ll avoid auto or adaptive layout whenever I have the choice:

  1. I love WYSIWYG. That’s why I love Latex and don’t like MS Word, and it’s the same reason I’ll never be a fan of these automatic layouts. Anything Apple can do when you check a box is something you can do when you write a line of code. But when you write the line of code you don’t forget what you did…because it’s right in front of you.
  2. Perhaps there’s a way to diff check box settings…but I know there’s a way to diff different versions of a file very easily so I can see just what’s changed over time in my layout by seeing how I’ve modified the layout-related code in an app. Knowing what you’ve done and what’s been changed helps you measure progress.
  3. Debugging should always of primary importance when you are thinking of how to design a programming project…particularly one with lots of people. I am sure some big app projects out there do use auto layout and all the rest, but the more complex the app gets, the more difficult I imagine it is to debug appearance-related issues. Why make it harder by having to debug both code and check marks? You don’t get rid of the code entirely, you just give yourself something else to do too.
  4. You can’t improve on a silly process like checking boxes; you can always streamline your code. I try to do things methodically in a way I know I can refine over time. As far as I can tell, there’s a limited upside to conforming to a system of check boxes…you can only get so good at it. With code, the sky’s the limit.

To improve is to change; to be perfect is to change often. ~Winston Churchill

I want to keep improving, so I’ll stick with coding up my app layouts.

p.s. I’m more than ready to be proven wrong. I know lots of folks do fantastic work with auto layout and adaptive layout. What bothers me is the unquestioning acceptance of the ‘check-marks-as-app-development’ model Apple seems to be pushing as hard as it can.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s