[1]: http://useyourloaf.com/blog/xcode-visual-memory-debugger/
- Don't throw all your screens into one file, you can even use one screen per file just like xibs
- Use code to style items and create controls you use more than once
- Render all the controls in code dynamically in interface builder so you won't end up with "ghost town" storyboards but everything is visible at a glance
Unless you're working at "Facebook scale" Interface Builder in the hands of an expert will get you very far.
Would you throw all your code in one big 8kloc controller? Of course not, but somehow people manage to cram every screen into the same .storyboard file, just because you can do it. Then they'll complain about merge conflicts, which isn't really a surprise given the fact that you're managing an 8kloc file.
Would you set the background, border, font and color of every button every time you use it in code? Of course not. You specialise a button class. But somehow people are selecting every button manually and setting those properties time and time again once they start using Storyboards while you can use a specialized class that will render in Interface Builder exactly like it will look in the app.
How do you fix these issues?
- Fixing misplaced views when transitioning from retina / non-retina screens or even different retina screen resolutions.
Reasoning: When I worked at Amazon this was extremely annoying - You didn't even have to touch the storyboard, you only had to open it and tons of misplaced views showed up. This causes a problem when working with any version control system because the XML changes are reflected in git even though nothing actually changed.
- Rendering Snapshots
Reasoning: I use snapshot tests to verify all views via unit tests. You can use IB to capture the view and load it programmatically, but you end up having to load the whole storyboard just to render one view controller.
- Setting all properties via IB
Reasoning: When I setup a button or a view, if half of my properties are in IB and half of my properties are in code, how do you determine what goes where. Apple did add IBDesignable, but wiring that up is so that you can click a drop down is more complicated than just setting the property on the object (and it renders in snapshots correctly and it never suffers from misplaced view and property configurations are in one place).
The teams that I've worked on aren't that big, but I can say that teams I've been a part of that don't use IB have worked a lot faster than IB teams. You may be a lot better at IB than I am, I only stopped using it 1 year ago for my projects after about 4 years of using it.
No solution. Non-retina users should carefully commit :(
> Rendering Snapshots
I don't think I understand the problem. Nothing is stopping you from rendering just one of the view controllers alone?
> Setting all properties via IB
I'm doing more and more in code nowadays, including constraints that are also rendered in IB. Makes it easier to change things like ratios or heights all across the app.
Interface Builder then glues it all together and I can throw in some one-off items.
I've had several people at Apple tell me they generally don't use interface builder internally.
I heard the same claims about Swift. I have no idea what to believe.
That was what I was highlighting, not the fact that Visual Studio somehow doesn't have that functionality.
I recommend this video to see some good example about reverse debugging with gdb. https://www.youtube.com/watch?v=713ay4bZUrw