Pros and cons of programatic AutoLayout
Why choose programatic AutoLayout:
- Easier to maintain than InterfaceBuilder 👌
- Easy to debug once something goes wrong (as appose to Interface Builder)
- Faster to cognitively grasp what AutoLayout does. IB has too many parameters all over the place
- Easier to setup for complex rich interactivity / animation (This is almost impossible in IB)
- Less parameters for more impact (Use of one-liners in snapKit, TinyConstraints and Spatial)
- The future is more and more Advance UI/UX and less boilerplate generic looks
- The parameters are in pure code so it’s easy to comment edge cases and gotchas (Impossible in IB)
- All autolayout code is in the swift files so it’s easy to do code-reviews on github
- Programatic AutoLayout is version-controllable in a sane way. 🧘
- No more abstract and unreadable .xib syntax
- Many of the biggest apps in the world already use SnapKit. As such your knowledge about it is important for your career.
- Programatic AutoLayout is the industry standard for higher-end apps 👔
- IB layout used to be WYSIWYG. As apps have advanced in complexity WYSIWYG editors simply can’t keep up
- No more convoluted AutoLayout constraint error messages, you’ll have absolute control over AutoLayout
- As developers we need to ascend to a higher level of UI/UX programming. A place where using ReactiveNative is impossible.
- Whats more readable 4-5 panels with 100s of checkboxes, OR the line:
- InterfaceBuilder crashes xcode if there are too many views 💥
- InterfaceBuilder is really slow when there are many views
- More advance conventions and workflows regarding Interfacebuilder and autolayout quickly becomes non-sensical
- Segues etc are better captured and handled in code.
- InterfaceBuilder is not suited for making fancy responsive UI/UX
- merge conflict increases when you have many people working on one storyboard
- The more programatic AutoLaytout you know the easier it will be to live in a IB/Code hybrid world. You cannot survive on InterfaceBuilder alone.
Unable to simultaneously satisfy constraints, will attempt to recover by breaking constraint💀
- The comments surrounding the programatic AutoLayout code is crusial, as we can spend a lot less time deriving the context the original problem was solved. If this statement sounds unambigiouse then please read my article on commenting and its effect on cognition
- ios 9 edge cases needs documentation
- When subContent sets parent constraints, things gets complicated and commenting and subclassing is needed to keep the code readable and maintainable
- My final argument is that Programatic AutoLayout enables you to have a steel grip over your UI / UX. No more half baked transitions that are fair enough. Own your design. Make it shine ✨
- Slight learning-curve for iOS beginners
- Depends on third party lib to really write code efficiently (Vanilla Autolayout code is not very maintainable, as its too verbose)
- Apples own programatic AutoLayout is verbose and powerful but more code means less simple to maintain
- Takes slightly more time to initially setup than IB.
- IB AutoLayout is ok for beginners. Or really simple apps. Or trying out an idea.
- Birds eyeview of views are cool. But to make IB + AL work you have to create many storyboards, and the effect is lost.
- IB is great for simple looking vanilla apps. ✌️