Why I have given up on Interface Builder and Story Boards

I just ran into another case where Interface Builder did not allow me to do what I wanted to do and I finally just gave up and pulled everything but the first view controller from the storyboard. This is the story of how I got to this point.

My first iOS app was one of "finish this". Another developer who was no longer with the company had developed the app. I had the job of finishing the app and converting it to Android. I already knew Java and had written an Android app that was in the store. The iOS version used NIBs as this was back in the iOS 4 timeframe.

I continued down the NIB path and converted the app to be universal with special code for iPad layouts. There was special cases for landscape vs. portrait on one of the screens as well. Seemed to work OK but it was a fairly straightforward app.

I worked only on Android apps for a some time before my next position where I did both iOS and Android work again.

The next iOS app I worked on was written by another developer and he used storyboards. Still using the old style layouts with pixel perfect positioning. I kept the storyboards in place seeing some of the advantages of using them and added the iPad storyboard side of things. I liked how much easier it was to get things going, used segues and like the idea of seeing the program flow in a visual designer. Took quite a bit of web research to understand how it all tied together and a lot of clicking on tabs in IB to find all the secret nooks and crannies where you could set things.

I did a couple of other apps for the company that I got to write from scratch. I used the new found storyboards for them as well. Sadly none of these apps went to market as they never finished the server side of the work. Lots of pretty apps to demo at sales meetings but they were just demos.

For my current job I am again getting to write the app from scratch. I am doing the same with the Android side of things. I started out using storyboards and it was time to get into autolayout. Since I have been doing Android work and I have also done a lot of Java desktop work I have a solid understanding of doing layouts that scale.

I dove into autolayout and found it rather confusing. It appears to me to be written in the land of academia instead of the land of real world programming. One layout to rule them all no matter how you have to force things into it. Very verbose in one code only format and very terse in the other. If you do it in Interface Builder then you just have to know how to do things. Click here, Ctrl + Click here, set up constraints, delete them, set them up again, have them conflict, pull hair. Always something wrong and it get really bad when you have a complex layout. For a company that prides itself in UI and UX I must say IB is not a good reflection of that goal.

After fighting it and working with other iOS devs over chat I found Masonry and switched to that. Yes, it is code and not WYSIWYG but I could create complex layouts and have them work. I could do different layouts for iPad and iPhone and follow them logically. I still have storyboard layouts but most of them were empty as the code created the real layout. I was just using them for segues and to see program flow. That was until yesterday.

There I was back in Interface Builder. I just wanted a UITableView to move down one level, to have another UIView as its parent. IB fought me tooth and nail. I could and a UIView to the list but it would not show up under the UIViewController no matter how I dragged and dropped and clicked. I then said screw it and deleted that entire view controller and created a new one where I could re-add the UITableView but then all my segue links broke and all the IBOutlets into the code broke and I would have to do it again for the iPad storyboard and all the work went on and on. Plus Xcode crashed more than once while I was in it doing simple things.

Storyboards end up sucking pretty quickly. There is not enough screen room to see your iPad layouts. You get to see one scene at a time. Sure you can zoom out but the minute you edit something it zooms back in. Just opening a storyboard seems to trigger Xcode into thinking there was a change. If you look in the XML you will see it changed x = 4.0 to x = 3.999999999 or something just as stupid. Everything I did I had to do twice, once for iPhone and once for iPad. The IDE does not tell you if you forget to wire up a UIView to an IBOutlet. Objective C does not care if you send messages to a nil object. Moving a UIView can screw up the whole layout quickly. You can't see all the constraints in one place, you have to look in each level of the layout to see them and they are terse and unrelated to each other. When you try to Ctrl+Drag a UIView into the code you hardly can see anything else on screen.

I gave up. IB was fighting me not helping me. I converted all the code to Masonry and I was able to control that layout exactly. I had to move all the segue processing in code as well. It took me all day to get my code back to where it was before but now I am in control of all of it.

I don't have to do things twice. iPad and iPhone both work from one code base. I may have some if statements in code to tweak layout for iPad but I don't have to double layout it out in a crappy UI editor called IB and I don't have to double connect every UIView to a IBOutlet.

I can move a control around in my layout by changing a few lines of code instead clicking a bunch of times in IB and having it get pissed and redo other constraints.

I can name my controls so when I do get log messages about my layout being screwy I know exactly which UILabel it is mad about instead of guessing.

Another issue that bit me, I fixed, that bit me again and I fixed the right way arose. I needed a second line for the title area on iPhone. iPad has enough horizontal space to not need this. I was using the navigation prompt property which adds a second line of text to the title area. On Android I could use title / subtitle to do same thing but on Android this requires no extra vertical space.

How did this bite me twice? A number of months ago I wanted to add a UILabel above my UITableView but I could not due to same issues that I just covered, I could not get the UITableView hosted by another UIView. Thus I used the prompt property. It worked OK. After the conversion away from storyboards everything in this UIViewController aligned just fine the first time I displayed it but when I tapped a table row and moved to the detail screen then back to the table screen setting the prompt caused the navigation area to grow and it covered up part of my table. Rotating to landscape and back would fix it. I tried all sorts of relayout, needs display, calculation of offsets etc. and could not get it to work. Why autolayout would not stay in sync is beyond me but I got sick of fighting that.

Then I remembered what I originally wanted to do - put a UILabel above the UITableView on iPhone only. Now I am in control as I am using Masonry. Put the UILabel in place and changed all code references from prompt = to promptLabel.text = and I have a working layout the way I originally wanted.

I have no plans use prompt again due to it screwing up layouts and I will not be using storyboards or Interface Builder either. They just are not stable and cause more trouble than they are worth. I also do most of my work in AppCode instead of Xcode as AppCode does a much better job in a lot of areas. Better editor, much better refactoring, GIT actually works properly and it is stable. I have had it crash on me once in the two plus years I have been using it.

The other added benefit - I can take my code and drop it in another project and it will work. I have no dependencies on copying the layouts twice and having to manually reconnect every single freaking UIView to an IBOutlet. My code is self contained. It lays itself out and knows how to talk to all of its controls.

Goodbye IB and storyboards. I don't miss you.

Switched to autolayout via Masonry

I have known for some time that I needed to start using autolayout for my iOS development. My current app is universal so I was doing things twice already in Interface Builder which was getting to be a real pain. Add the control, drag and drop the IBOutlet connections and don't forget to do it on the other side.

I tried to use autolayout in Interface Builder and finally got my fairly simple login screen to work but I cussed at it the whole time. Move a control, have IB tell you the constraints and form are out of sync, correct it and repeat. If you move a control that was used as a reference anchor for other controls then it got really lost. You end up manually deleting constraints that show up either below the control you are moving or maybe at the root view. Just way to painful and error prone.

Here is where https://github.com/Masonry/Masonry comes into play. I have used a number of layout managers in the past including standard Java layouts, MigLayout for Java and the Android XML layouts. Masonry is similar to each of them in a number of areas.

A new layout with about 35 controls was the tipping point. No way I was going to do that after all the venom I spewed at IB doing the login view with only 7 controls. I got the new layout working pretty quickly in Masonry then I went back and ripped the login from IB and did it in Masonry where I can easily see the exact constraints and view relationships.

I attempting to use the Apple flavor of programmatically doing autolayout but I found it to be very verbose and nearly as confusing as IB. The other shorter syntax messed with my mind also. Masonry seemed to go right down the middle.

Not a huge fan of checking in the code for iPhone vs. iPad but for a universal app where you want special layouts that is what you get to do. Not sure what will happen when the new iPhone 6 comes into play.

I am now skipping story boards and all their headaches and just doing my layouts in code. This also means is a new developer was to come on board we would not be walking on top of each other when we change a layout which stinks with storyboards and version control. That developer would get to learn Masonry but it is reasonable straight forward. I still run into some odd layout issues that send me scrambling to stack overflow but in general it has been pretty smooth.

UIScrollView gave me the most fun but once I figured out how to anchor the scroll view to the main view then anchor child views of the scroll view to the scroll view it all worked out.

The error messages given by autolayout are not super helpful. Some trial and error is involved but I don't run into errors very often anymore.

AAAARRGGGG iOS layouts stink!

I hate iOS layout management. Yes, everyone loved it when you knew the iPhone had this one resolution and you could perfectly layout everything. All phones were held in portrait only mode. Even the auto code generator blocked landscape by default. We knew what you had and how you would use it so just shut up. All Apple devs told Android devs they were hosed with their stupid layout managers without true WYSIWYG editing. Na-na-na-na-boo-boo.

This meant if you wanted to support landscape you added code to move things around and resize them during orientation changes. You could still use IB to see that pristine portrait view. Then came the iPad which was used in landscape a lot. Just do IB in that mode.

Well IB sucks. Adding storyboards just allowed it to suck in some new ways. Sure you can tie you portrait screens together and you can do separate iPad and iPhone screens but you have to manually tie all the controls back to your source code with crazy Ctrl + Click drag and drop if you can get the right source file to appear in a squished down window below the stupid layout that is way too damn big for iPad screens that wants to constantly scroll and resize every freaking time you click on it!

You are an idiot - use auto layout. If you don't then you are hosed. But Apple did not backport that, you had to wait until most users were on iOS 6. Google backports, Apple does not. Apple is a jerk in this area. iOS 6 seems like a safe enough target at this point.

Auto layout has a new set of issues. IB really blows here. It has to have everything in perfect order even though when you are creating the layout you can't get it in perfect order until the layout is fully loaded with all the controls. They IB rewrites the damn file over and over. You lose the battle every single time wasting a huge amount of effort.

So screw IB, it has been screwing you. Besides if you want a team working on things they can't all have the storyboard open because version controls DIFF is nearly impossible. It is a SNAFU. Time to write it all in code and skip everything related to IB.

You have a couple of choices. Use the auto layout weird ASCII stuff, which is just ugly to read, or use NSLayoutConstraints manually. I think I am going NSLayoutConstraints. If I am getting no WYSIWYG support I might as well take full controls. That ASCII stuff is too bizarre. Honestly this all feels like I am moving back into the land of GridBagLayout in Java.

GridBagLayout was the end all do all layout manager for Java back in the day. Yes, I did some crazy layouts with it that worked and even allowed you to resize the panel and flow properly. The code was ugly and not maintainable. You could not look at it and tell what the hell was going to display on screen and you could not add a new control between other controls without totally screwing everything up. I worked with developers that used GridBagLayout for everything even though a simpler BorderLayout would have worked. Use the right tool for the job people.

Look Apple there were a ton of other good examples of how to do things. MigLayout for example if you only want one layout manager. The Android XML way of doing things if you don't might multiple layout managers that deal with each other. At least with Android you can layout portrait and landscape and just put them in different directories. There is a WYSIWYG viewer too. I use it to preview the code changes I make in XML and so far have been able to build every layout I have wanted. The Android side is not perfect but is better than what I have seen from Apple.

Nope, Apple just puts all of that on you. Now I get to manually code all this crap and other devs will be able to see what it looks like when they run the code.

I just wanted to convert a current screen from a table view to a normal view. The original developer misused a table view for the screen and I need to clean it up and give a better look. IB does not like it when you try to change view types. Time to punt. Yes, I am using Xcode 5.x and I know it is supposed to have better auto layout support but it is still a mess.

Having spoken to my other iOS developer friends they have all stated it is time to move as far away from IB as possible. It has done nothing but screw them over. They think I am a fool for attempting to stick with IB as long as I have. I really just wanted to get the current project off the books but that is not going to happen. I can try and blow away the current table with a normal view then reattach the segues to the new view and leave it at that but that seems a new waste of effort.

I am going to have to learn auto layout. It is the new Apple way of doing things. It is the only hope if Apple decides to ever come out with a new resolution, which I really think they should. People are expecting HDTV on their devices. 1024x768 on the iPad mini is not cutting it anymore.

Maybe someone will come out with an excellent layout manager for iOS that will solve a number of these issues. At this time I don't care about WYSIWYG at the start. Something that is easy to code and maintain is what I want. I enjoyed working with MigLayout. I converted over 300 Java desktop screens from old NetBeans format to MigLayout at a previous company. I find the Android layout managers more difficult that MigLayout but still serviceable. The new Android Studio does a really nice job showing me a preview of my screens as I edit the XML. The layouts work and scale on various device sizes.

Done with my rant. Off to code NSLayoutConstraints.