So helpful, but it's crazy to me that Apple provides such horrible options for creating UI for iOS. AutoLayout is verbose confusing mess and using storyboards is a disaster. Why can't we have simple declarative markup to create UI? Android's xml files are a pleasure to work with.
Storyboard XML’s are not meant to be edited manually: no sane documentation or Xcode intellisense support exists. They are not source control friendly either. Lack of styling is also a problem. Compare that to VS WPF/UWP support which is the epitome of comfortable UI development imho.
What IB allows you to do is to subclass UIView, design your own controls in code and preview the results of changing instance variables directly in IB.
Yes, exactly that, but you don't need to go the full way.
It depends on what kind of rendering one wants to present to the user/developer, even with DesignerAttribute one can provide a custom rendering for the control.
Here with a forms example, but similar way can be done for the XAML variants.
Lack of styling in terms of color and fonts is generally not a problem, but it is true that Apple limits more advanced styling for many standard UI components. For example iOS navigation bars (as in UINavigationBar) are not very customisable.
If one wants to customise the look entirely, for example make the bar taller than the standard 44pt, one has to implement the component from scratch.
My perception is that the limited customisability is done on purpose by Apple to enforce a common look-and-feel of UI elements across all apps on the system. Also it of course reduces the API surface that Apple have to maintain.
I pretty much like it, both because it indeeds lead to a more consistent look and feel, but also because makes it easier for us to reject the weirdest design wishes from our clients - we can refer to that implementing the components from scratch will take a lot of time (= money).
As the VFL docs say, "The notation prefers good visualization over completeness of expressibility." For example, it's impossible to create an item with equal height and width in VFL. It's definitely not more capable than other layout systems. It's strictly less capable than auto-layout, for one.
"A disaster" because what? Do you develop for iOS?
I do, I think they are the best UI design tool out there (used Microsoft tools, Android tools and GTK designer) and simply has no comparasion.
Most of the times, people poo-pooing AutoLayout are people that start rushing out the design without thinking about it, or people that rush to stack overflow to "fix" the problem and don't care to learn the system (apple provied great videos from WWDC).
It's funny to me that people can hold the belief that the iOS UI design tools are somehow the worst while iOS has consistently had the best mobile UI in terms of aesthetics (subjective), usability and performance (objective).
If the tools were so bad, why do they always seem to achieve a superior result?
A lot of stuff comes "for free" with iOS, and I find that iOS developers tend to care more about usability and design than developers for other platforms since it's heavily incentivized by Apple and iOS users.
> Android's xml files are a pleasure to work with.
I would disagree with this statement.
I hate anything XML when I have to touch it manually.
I greatly prefer yaml or even json for something usable by humans.
Autolayout notation can look confusing, but I have a light background in CAD and I reason with Screw theory. IE what are the smallest number of constraint for my system to be stable …
> I hate anything XML when I have to touch it manually. I greatly prefer yaml or even json for something usable by humans.
So... is there an export to/import from JSON option or tool? Seems like this is something that wouldn't be too hard, given you likely have rules for how the XML is supposed to be defined, so if the JSON is ill-formatted it can just report a useful warning about why.
Storyboards aren't a disaster, I think people's grasp of storyboard best practices is really the disaster.
For our team, storyboards are for flow and they are broken up into individual storyboards where possible. Individual xibs are used for views and view controllers. We don't put any UI in storyboards at all.
Autolayout is as easy or as hard as you want to make it. As with almost all things, less is more. I think people definitely need to have an a-ha moment with it.
I consider it a knock against you if you can't sort out interface builder or autolayout, if I'm being honest.
> The only reason to not use it, is because some of those Apps are built with third party multi-platform frameworks and not UIKit (React)
Anecdote: I’ve worked on a few large iOS teams at well-known companies. At all of them, we have moved toward building UI in code and specifically banning the use of XIBs and Storyboards (we still use all of Apple’s frameworks — e.g. UIKit). Part of the reason is merge conflicts — in much the same way that merging Xcode project files requires every engineer to understand and be able to parse the syntax when looking at a diff, merging changes in XIBs and Storyboards is fraught with danger (at best).
We use storyboards and xibs extensively for a pretty large app (50+ unique view controllers, hundreds of use-cases).
Although I grant that our team size is pretty small (< 10). But even with a much larger organisation, I would expect different teams to be assigned to different features, so there shouldn't be more UI-related merge conflicts.
Interface builder is very useful for previewing constraints with different size classes and device models, and also for previewing localisations (app localized to 20+ languages).
With some exceptions, we only have a single view controller in a storyboard file.
This, and managing UI tasks so that just one or two developers work in the same part of the UI makes us have very few xib and storyboard merge conflicts.
A testiment for AutoLayout’s power is that the web has 2 separate layout APIs (grid and flexbox) both which are just limited special cases of AutoLayout’s functionality.
However, if you don’t take your time to understand linear constraint systems, then you’re entering a world of pain.
To work effectively (and correctly) with SQL, you have to learn to think in terms of relations.
To work effectively (and correctly) with AutoLayout, you have to learn to think in terms of linear constraint systems.
So this is like a weird form of victim blaming. Even if it wasn't, I think some blame rightfully lies with apple here -- they made tools (and accompanying documentation) that is so difficult to use correctly that a large swath of developers can't figure it out. And what's worse, they've forced this tool on every developer.
Disclaimer: I'm admittedly very biased towards cross platform approaches like Nativescript/React Native & Flutter vs taking time out of my day to learn and keep up with Google/Apple's latest "design language" and accompanying tooling. This makes me a terrible mobile developer (no sarcastic/snarky intent), but makes me a very productive developer who happens to have to make mobile apps that are "good enough" sometimes.
You're right -- No one should have to learn React! I'm personally not even a React fan. However standards-driven web components[0] are progressing rather slowly (as they should be, arguably), so frameworks like React/Vue/Polymer/Mithril exist to get you some of that goodness faster than is otherwise possible in a cross-platform way.
My more subtle point was that HTML and CSS despite all their warts have solved these problems -- I've expressed the sentiment here before -- design languages with their use of XML or more constricted DSLs or whatever else are just subsets of HTML + CSS, except I never find that they're engineered to minimize conceptual reuse. Both platforms make their own thing, claim it's good/the best from their own rooftop, and call it a day, expecting app developers to join the cult. I don't like that, and I know it makes me a worse mobile developer (I sacrifice the ability to relatively immediately solve some really deep UI layout bug in the native platform), but I'd gladly be able to write "good enough" cross platform apps two times quicker than being able to right a top performing/fully native optimized application two times quicker. Most app these days are as simple as webpages.
Also just for posterity I don't necessarily want every platform to take HTML/CSS wholesale (though I thought FFOS was perfect, RIP) and implement a completely by-the-spec implementation, because at that point you'd just have a browser. Make your own subset and make your own choices, but don't re-solve problems HTML and CSS have already solved. For example, take the structural layout concepts from CSS Flexbox but maybe throw out the cascading if you want.
BTW, I think Flutter is a trojan horse that's going to very likely be successful. Google was crazy enough to draw every pixel, then start building combinatorically from there. Right now it "embeds" in Android and iOS and also Fuscia (!!). Eventually It'll get a QT embed (because Google can afford to throw devs at it, just like they threw devs at the ridiculous-on-its-face "draw every pixel" approach), and whatever else and might actually be the first thing to be usable for all platforms without much worry.
From what I understand JavaFX is one of the only similar UI frameworks to Flutter in application land and people who use it seem to love it.
> My more subtle point was that HTML and CSS despite all their warts have solved these problems
I am so glad that CSS is not the dominant design/layout solution on mobile. CSS may seem natural to work with after years of experience, but it is very unintuitive and sub-optimal for solving basic design problems, and I'm glad they started fresh on mobile platforms. I mean it's only relatively recently that there is a somewhat easy way to center a div vertically and horizontally on screen which does not seem like a total hack.
CSS is basically a tool designed for the simple formatting styling of text documents which has been patched to the point of absurdity to support modern design needs. The iOS tools in particular are extremely powerful and purpose-built for the task.
Could you be more specific about which part of CSS you find the most un-intuitive and sub-optimal for solving basic design problems? I want to remind you that the basics of CSS are targeting some piece of layout and applying styles to it, separate from the element itself. Basic HTML + CSS is like an hour or two worth of learning for an absolute beginner (especially with the simplicity of HTML5), and after that you're mostly limited by your imagination, for simple things.
I'm just assuming you mean cascading and/or specificity as the thing that's unintuitive and sub-optimal, but other than that I'm having trouble differentiating basic CSS (e.x. using only element ids and styling rules) and how you end up styling components on mobile now...
Maybe where we're differing is on a more fundamental level as far as whether styling should be separate from layout in the first place? But even then you have access to `style` attributes in HTML...
It's enormous! How could anything be intuitive when there are hundreds of keywords?
To give a more specific case, I would argue that CSS is eminently un-guessable. Take for example the CSS property clear:
#MyDiv {
clear: both;
}
"clear" is a magic word I just have to know when I'm dealing with float layouts so that my elements end up the place I want them to. It's not a concept that flows naturally from the way designers think about layouts, it's essentially a special case , an implementation detail which has been sloppily bubbled up to the CSS API. CSS is full of these special cases.
By contrast, a constraint-based layout is built on a few extensible contexts. Essentially you have a hand-full of layout anchors on each object, and you have a short list different possible relationship types between anchors. From those core principals you can build up any kind of layout you want.
> It's enormous! How could anything be intuitive when there are hundreds of keywords?
But I covered this though -- you don't have to take the whole HTML/CSS spec, because if you did you'd just be making a browser.
Even if there are hundreds of keywords, you generally don't have to know (or support, as an implementer) every single one.
> To give a more specific case, I would argue that CSS is eminently un-guessable. Take for example the CSS property clear: [example]
The example you gave is pathological -- a more reasonable one for a "basic design problem", which is what you said CSS was bad for:
#MyDiv {
background-color: black;
}
Your very next sentence betrays how pathological the case is:
> "clear" is a magic word I just have to know when I'm dealing with float layouts so that my elements end up the place I want them to. It's not a concept that flows naturally from the way designers think about layouts, it's essentially a special case , an implementation detail which has been sloppily bubbled up to the CSS API. CSS is full of these special cases.
"clear" isn't magic, it requires knowing what a float layout is, and having used a float layout before. It is a special case reserved for building float layouts, that is necessary because of how they work.
I don't disagree with you that float layouts are terribad and shouldn't be used these days, but that's the beauty all those keywords in the CSS spec -- you don't have to use it. These days we have Flexbox & Grid, decently engineering solutions for layouts.
> By contrast, a constraint-based layout is built on a few extensible contexts. Essentially you have a hand-full of layout anchors on each object, and you have a short list different possible relationship types between anchors. From those core principals you can build up any kind of layout you want.
Could you de-jargon these sentences? Maybe this is where we differ, I think what you just described is more complex than CSS from principles. Also, I want to note that not many in this thread have stuck up for the simplicity/ease of use of AutoLayout.
> These days we have Flexbox & Grid, decently engineering solutions for layouts.
Flexbox was proposed in 2009, and it hasn't been widely available until years after that. The iOS and Android layout systems are functionally older than the "good" parts of CSS you speak of (I would agree FlexBox and Grid are actually fine, although not as complete of a solution as constraint-based layouts).
Moreover, if mobile did just use a subset of CSS for it's layout system, you'd just worsen the fragmentation problem that CSS currently suffers from: in order to write "cross-platform" css, which you cited as one of the benefits of this approach, you would need to account for _even more_ platforms with slightly different APIs. To make a layout which works on, say, IE 9 and Android you would still have to implement twice, or resort to workarounds like polyfills.
> Could you de-jargon these sentences?
If that seems like jargon to you, I would have the suspicion that you have never put the time in to learn the basic auto-layout concepts. If that's the case I'm not sure how you can compare them.
The point is that with autolayout, the total number of things you can do could be written on one page. You have a hand-full of general-purpose building blocks, and you compose them together to do whatever layout you want. That's compared to CSS where there's a large collection of tools, each of which has holes.
> Flexbox was proposed in 2009, and it hasn't been widely available until years after that. The iOS and Android layout systems are functionally older than the "good" parts of CSS you speak of (I would agree FlexBox and Grid are actually fine, although not as complete of a solution as constraint-based layouts).
And when was AutoLayout introduced? Even with that, it's evolved and been improved over time -- I bet you wouldn't want to use AutoLayout from 2016 today if you could avoid it. Either way, Apple could have introduced AutoLayout as a private extension of CSS that doesn't worry about being spec-compliant, without completely rebuilding their own framework for styling.
Are you implying the android layout systems are older than CSS itself? Because one of the "good" parts of CSS I was talking about was basic targeting and separation of concerns between styling and layout. That's fundamental CSS, and long predates any mobile platforms.
People writing mobile apps, especiallly native ones don't give a shit about cross-platform anything, I don't understand why you'd all of a sudden start worrying about that if you used CSS. I keep repeating this, but they can make their own private subset of the CSS spec that only their developers have to care about.
You've framed the burden of cross-platform support as a bad thing, but it's a good thing -- whatever that cost is, you pay it once, for everyone -- you prefer a world where cross-platform support is just impossible?
> If that seems like jargon to you, I would have the suspicion that you have never put the time in to learn the basic auto-layout concepts. If that's the case I'm not sure how you can compare them.
This a common mindset that I've never agreed with. If you can't explain the simplest uses of your abstraction without a sentence full of jargon, this is a red flag for me, it's a shitty abstraction. Jargon is calcified complexity that is so burdensome to try and explain/analogize that you just pick a word and say it instead. This is like what people say who build ridiculous Java class/pattern riddled sand castles all day, then say that if I don't understand why they needed a AbstractThingFactoryMakerService then I didn't learn the basics.
This is precisely why I will never willingly enter the quagmire that is fully native development, there are people like you in the wild waiting to justify any bad design decision the native platform makes once they've paid the cost of learning a subpar abstraction/re-engineering of a mostly solved problem that's been foisted upon them. You'll to shout how good AutoLayout is from the rooftops while devs flock to alternatives because of the BS.
NativeScript and Flutter are gaining popularity because the platforms have issues. You can ignore it for however long you want.
> This is precisely why I will never willingly enter the quagmire that is fully native development, there are people like you in the wild waiting to justify any bad design decision the native platform makes once they've paid the cost of learning a subpar abstraction/re-engineering of a mostly solved problem that's been foisted upon them.
Actually you seem to be the one who is guilty of exactly this. I am speaking from experience with CSS _and_ mobile layout systems, and _you_ seem to be the one who is afraid to step out of your CSS comfort zone, and assume that the system which is familiar to you is the best system without trying (or apparently reading up on) the alternatives. Your entire argument against AutoLayout seems to be that other people don't like AutoLayout. If you haven't bothered to learn about the basic concepts, how can you possibly know it's so bad? And frankly the level of projection and vitriol in your comments is disappointing to see on Hacker News.
> Are you implying the android layout systems are older than CSS itself?
No, I'm implying that it would have been a bad decision for the mobile UI systems to have been built around CSS before it had decent layout solutions like flex-box and grid.
> And when was AutoLayout introduced?
It's not relevant. AutoLayout is an evolution of the iOS UI system, so comparing the origin of AutoLayout to the origin of FlexBox is orthogonal to my point.
> Actually you seem to be the one who is guilty of exactly this. I am speaking from experience with CSS _and_ mobile layout systems, and _you_ seem to be the one who is afraid to step out of your CSS comfort zone, and assume that the system which is familiar to you is the best system without trying (or apparently reading up on) the alternatives. Your entire argument against AutoLayout seems to be that other people don't like AutoLayout. If you haven't bothered to learn about the basic concepts, how can you possibly know it's so bad? And frankly the level of projection and vitriol in your comments is disappointing to see on Hacker News.
You've also assumed that because I think CSS is better at solving basic problems these days that I haven't used used AutoLayout. I have used AutoLayout and it wasn't a good experience. I've also used Android's XML soup based layout, neither is fun and they solve problems CSS has already solved. I write both android and ios apps and have moved off native development because of frustrations with the little differences between both of the platforms.
> No, I'm implying that it would have been a bad decision for the mobile UI systems to have been built around CSS before it had decent layout solutions like flex-box and grid.
Yeah except like I've said roughly 5 times now, they didn't have to take ALL of CSS. They could have built extensions to it, possibly benefiting the whole ecosystem, or anyone else -- at the very least, leverage what CSS has already solved well and then build upon it.
> It's not relevant. AutoLayout is an evolution of the iOS UI system, so comparing the origin of AutoLayout to the origin of FlexBox is orthogonal to my point.
Of course it isn't relevant -- because you don't have a choice. I was comparing the origin and evolution of AutoLayout to the origin and evolution of CSS -- CSS might move slow, but it's pushed forward by entities that do exploratory work, contribute back and improve things for everyone.
AutoLayout does not improve on the basics that CSS offers -- targeting and styling an element is basically the simplest it gets, and it's straight-forward to understand. CSS has iteratively gotten better over the years, steered by a bunch of groups, and is sufficiently extensible to contain AutoLayout's functionality. A world where CSS could be worse than AutoLayout basically doesn't exist, because you could literally make a CSS, strip whatever you don't like out, and implement AutoLayout.
Not using storyboards due to the widely exaggerated git merge issue is throwing the baby out with the bathwater. In my experience, if you keep storyboards small merge issues are a minor, extremely rare annoyance.
If you compare the time spent on merge issues to the enormous amount of time waisted on coding UI manually it's not even close.
i do keep using xib, because they’re confined to one viewcontroller, and it makes it more possible to split to work between people.
storyboard are meant to design workflow, so at least two screen but often more than that. The more you put screens in the same storyboard, the more the chances of a git merge issue.
Git merge on storyboard aren’t a minor issue, they can take someone about an hour a day every day for the duration of the project, since most work on an iphone app is correlated with GUI changes.
( and then again it gets worse the more screens you have in a single storyboard).
I personnaly didn’t think it was a problem until i had to manage a team of 11 ios developers working in parallel on a single app in rush mode. In that case storyboard are simply out of question.
So your storyboard just defines segues and types, then your view controllers call initWithNib?
That sounds very reasonable. I find IB to be excellent for creating layouts quickly, especially combined with @IBDesignable and @IBInspectable.
My problem with relying on storyboards has been when I need to reuse a layout in a separate workflows. What’s nice about your technique is that it allows separate storyboards but also layout reuse with nibs.
Knock against me all you want, that's fine. I understand storyboards just fine. I also understand that they are a poor way to build apps. Drag and drop WYSIWYG interface crap is what I did in high school to make webpages.
Creating a programmatic router to create view controllers is a much better, faster, and most importantly, testable way to do things.
The core point - you can't code review storyboards/XIB - still stands. That makes them untenable for large teams of professional developers where quality matters.
Interface Builder and Auto Layout were both designed for the Mac and have never really fit in on iOS. The best way is honestly just to write code: implement a -layoutSubviews method which updates the UI to match your app state, then call -setNeedsLayout whenever the state changes.
This might have been true when there was a single screen size on iOS and people could get away with hardcoded “pixel perfect” frames, but that’s just sloppy.
That’s how you get half-baked apps that don’t properly support right-to-left languages or accessibility features like dynamic type.
I'm not talking about hardcoded layout; the math to position a view a certain distance away from an edge is very easy to write.
In fact, it's easier to make dynamic views in code. What if you want some part of your layout to change based on the size of a view (as determined by screen size, dynamic type setting, language and so on)? Do you create two separate XIB files? How do you keep them in sync?
> What if you want some part of your layout to change based on the size of a view (as determined by screen size, dynamic type setting, language and so on)? Do you create two separate XIB files? How do you keep them in sync?
IB has the resources to handle exactly that, it's called "vary for traits".
If you are doing the math, AutoLayout is precisely made to that for you.
Even if you want to not use constants (ex: use the sinus function), you can do just the important part in code and alter the IB constraints's constants. Done.
Vary for traits doesn't do that, though! "Size of a particular view" isn't a trait, and "value of a single constraint" is different from the layout of the view.
Let me give a concrete example. Say you're writing a view to display a photo in a swipeable gallery. You want to position the associated UI elements where there happens to be room around the photo. That is, when the photo is tall, you want the UI to be placed on the side, but when the photo is wide, you'd prefer the UI to go on the bottom. The individual UI elements are mostly the same, but the layout is different for each state.
With -layoutSubviews, you can write your two layouts as usual, then use an if statement to switch between them:
Shared code can be factored out as necessary. Animation can be done with the following pattern:
[view layoutIfNeeded];
// -setTallMode: sets the layout needed flag if the value changed
[view setTallMode:shouldBeTall];
[UIView animateWithDuration:duration animations:^{
[view layoutIfNeeded];
}];
How would you specify these two states using IB/autolayout? And how would you animate between the states as you swipe between photos?
That's not what you said in the first post, was it?
If I wanted to do that, I would but the buttons with two constraints to the bottom and to the trailing (right), and I would change the constants of those two constraints, it's even easy because it's just swapping the constants of the constraint pair.
And that's the same reason HTML/CSS are so complex. Everyone is contributing to standards, which is already hard to do, and many of the contributing parties have competing platforms. It's in their best interest to, if not sabotage, at least make the web platform super complex and clunky to discourage or slow down development.
I agree 100% and this is why its such a clustfuck: the only way out is for me to create my own, competing, UI standard. Oh damn, its a burning pile of garbage, I'll just throw some more on it ..
AutoLayout isn't too bad with something like SnapKit. Alternatively you can use a custom layouting implementation based on frames, like FlexLayout/PinLayout. Works well too. Storyboards? Don't use them, problem solved.
Android XML has a lot of bad stuff in it too. Like all the styling that needs to be done through obscure XML tags, selectors, layer-lists, style-inheritance in separate files and so on.
Also ConstraintLayout is basically AutoLayout, I have been using Anko Layout DSL more and more instead of XML, which then really isn't that different from iOS+SnapKit.
I don’t quite see the need for LayoutProxy, or a layout method. Why not just extend UIView with a category which defines properties that add constraints when assigned to?
But when people use these libraries that “helpfully” set `translatesAutoresizingMaskIntoConstraints = false` for them and they don’t understand what’s going on under the hood, their layout breaks and they start complaining about autolayout being “buggy”.
What's the solution in such a scenario? If I'm making custom cells, I'm going to constrain my views to the contentView. If I use a library like SnapKit, then the library sets translatesAutoresizingMaskIntoConstraints to false. Should I override that somehow and set it back to true? Should I use normal NSLayoutConstraints for all constraints involving contentView? That doesn't seem ideal.
You can use the regular NSLayoutConstraints.activate() API, or you can set it back to true.
Also, notice that translatesAutoresizingMaskIntoConstraints will only be set on the view which you call `layout` on. I.e. this is bogus:
self.contentView.layout { make in
make.left.equal(self.otherView)
}
But this is “fine”:
self.otherView.layout { make in
make.left.equal(self.contentView)
}
Of course now you’re relying on implementation details of SnapKot/Masonry/whatever.
I personally just use the built-in anchor APIs with a few helpers (e.g. to create constraints to match all 4 edges of two views). In swift you have operator+ for arrays, so NSLayoutConstraints.activate(...) can be pretty succint this way.
75 comments
[ 3.7 ms ] story [ 33.4 ms ] threadFor your claim of Microsoft's superiority, I find it very unfounded, it's superior in which way?
With Apple's tools, I can write my on controls, and change my own values and see them updated live in the designer.
What IB allows you to do is to subclass UIView, design your own controls in code and preview the results of changing instance variables directly in IB.
It depends on what kind of rendering one wants to present to the user/developer, even with DesignerAttribute one can provide a custom rendering for the control.
Here with a forms example, but similar way can be done for the XAML variants.
https://msdn.microsoft.com/en-us/library/ms171824.aspx
My perception is that the limited customisability is done on purpose by Apple to enforce a common look-and-feel of UI elements across all apps on the system. Also it of course reduces the API surface that Apple have to maintain.
I pretty much like it, both because it indeeds lead to a more consistent look and feel, but also because makes it easier for us to reject the weirdest design wishes from our clients - we can refer to that implementing the components from scratch will take a lot of time (= money).
I don’t agree with grandparent’s characterization of autolayout, though.
It can generate very complex layouts, without inputing a single line of code.
It's more capable than any other layouting system.
> "The notation prefers good visualization over completeness of expressibility."
That phrase (that you googled) is taken OUT OF CONTEXT, and it's context is AutoLayout, and only AutoLayout.
It is possible to edit EVERYTHING on IB and VFL.
> it's impossible to create an item with equal height and width in VFL
Again, you prove that you don't know anything about AutoLayout.
https://i.imgur.com/UQQMdDj.png
Can you explain what does that do?
> It's definitely not more capable than other layout systems.
It is, deal with that.
> It's strictly less capable than auto-layout, for one.
Auto-Layout is part of VFL.
I do, I think they are the best UI design tool out there (used Microsoft tools, Android tools and GTK designer) and simply has no comparasion.
Most of the times, people poo-pooing AutoLayout are people that start rushing out the design without thinking about it, or people that rush to stack overflow to "fix" the problem and don't care to learn the system (apple provied great videos from WWDC).
If the tools were so bad, why do they always seem to achieve a superior result?
I don't want a WYSIWYG editor for UI. No other platform does this. Because it doesn't scale.
Tried to merge storyboards before? Ha.
Even programmatically...I'm sorry, but nobody can convince me that the following is a sane way to create UI:
NSLayoutConstraint.constraints( withVisualFormat: "V:|-23-[appNameLabel]", metrics: nil, views: views)
I would disagree with this statement.
I hate anything XML when I have to touch it manually. I greatly prefer yaml or even json for something usable by humans.
Autolayout notation can look confusing, but I have a light background in CAD and I reason with Screw theory. IE what are the smallest number of constraint for my system to be stable …
So to me, oddly, I always found Autolayout easy. https://en.wikipedia.org/wiki/Screw_theory
So... is there an export to/import from JSON option or tool? Seems like this is something that wouldn't be too hard, given you likely have rules for how the XML is supposed to be defined, so if the JSON is ill-formatted it can just report a useful warning about why.
For our team, storyboards are for flow and they are broken up into individual storyboards where possible. Individual xibs are used for views and view controllers. We don't put any UI in storyboards at all.
Autolayout is as easy or as hard as you want to make it. As with almost all things, less is more. I think people definitely need to have an a-ha moment with it.
I consider it a knock against you if you can't sort out interface builder or autolayout, if I'm being honest.
And yes, autolayout is a shitshow, hence the countless utilities and frameworks built on top of it to make it more palatable.
Source for that?
The only reason to not use it, is because some of those Apps are built with third party multi-platform frameworks and not UIKit (React)
> hence the countless utilities and frameworks built on top of it to make it more palatable
So, having layers of abstraction, now means it sucks?
No, people make layers of abstraction because the underlying layer is useful, powerful, configurable.
People do encapsulate AutoLayout because it works, and is good, or else, they would be doing their own code programatically.
Anecdote: I’ve worked on a few large iOS teams at well-known companies. At all of them, we have moved toward building UI in code and specifically banning the use of XIBs and Storyboards (we still use all of Apple’s frameworks — e.g. UIKit). Part of the reason is merge conflicts — in much the same way that merging Xcode project files requires every engineer to understand and be able to parse the syntax when looking at a diff, merging changes in XIBs and Storyboards is fraught with danger (at best).
Interface builder is very useful for previewing constraints with different size classes and device models, and also for previewing localisations (app localized to 20+ languages).
With some exceptions, we only have a single view controller in a storyboard file. This, and managing UI tasks so that just one or two developers work in the same part of the UI makes us have very few xib and storyboard merge conflicts.
However, if you don’t take your time to understand linear constraint systems, then you’re entering a world of pain.
To work effectively (and correctly) with SQL, you have to learn to think in terms of relations.
To work effectively (and correctly) with AutoLayout, you have to learn to think in terms of linear constraint systems.
Sorry webdevs ¯\_(ツ)_/¯
Disclaimer: I'm admittedly very biased towards cross platform approaches like Nativescript/React Native & Flutter vs taking time out of my day to learn and keep up with Google/Apple's latest "design language" and accompanying tooling. This makes me a terrible mobile developer (no sarcastic/snarky intent), but makes me a very productive developer who happens to have to make mobile apps that are "good enough" sometimes.
Isn't HTML + CSS the universal language for GUI's?
My more subtle point was that HTML and CSS despite all their warts have solved these problems -- I've expressed the sentiment here before -- design languages with their use of XML or more constricted DSLs or whatever else are just subsets of HTML + CSS, except I never find that they're engineered to minimize conceptual reuse. Both platforms make their own thing, claim it's good/the best from their own rooftop, and call it a day, expecting app developers to join the cult. I don't like that, and I know it makes me a worse mobile developer (I sacrifice the ability to relatively immediately solve some really deep UI layout bug in the native platform), but I'd gladly be able to write "good enough" cross platform apps two times quicker than being able to right a top performing/fully native optimized application two times quicker. Most app these days are as simple as webpages.
Also just for posterity I don't necessarily want every platform to take HTML/CSS wholesale (though I thought FFOS was perfect, RIP) and implement a completely by-the-spec implementation, because at that point you'd just have a browser. Make your own subset and make your own choices, but don't re-solve problems HTML and CSS have already solved. For example, take the structural layout concepts from CSS Flexbox but maybe throw out the cascading if you want.
BTW, I think Flutter is a trojan horse that's going to very likely be successful. Google was crazy enough to draw every pixel, then start building combinatorically from there. Right now it "embeds" in Android and iOS and also Fuscia (!!). Eventually It'll get a QT embed (because Google can afford to throw devs at it, just like they threw devs at the ridiculous-on-its-face "draw every pixel" approach), and whatever else and might actually be the first thing to be usable for all platforms without much worry.
From what I understand JavaFX is one of the only similar UI frameworks to Flutter in application land and people who use it seem to love it.
[0]: https://developer.mozilla.org/en-US/docs/Web/Web_Components
I am so glad that CSS is not the dominant design/layout solution on mobile. CSS may seem natural to work with after years of experience, but it is very unintuitive and sub-optimal for solving basic design problems, and I'm glad they started fresh on mobile platforms. I mean it's only relatively recently that there is a somewhat easy way to center a div vertically and horizontally on screen which does not seem like a total hack.
CSS is basically a tool designed for the simple formatting styling of text documents which has been patched to the point of absurdity to support modern design needs. The iOS tools in particular are extremely powerful and purpose-built for the task.
I'm just assuming you mean cascading and/or specificity as the thing that's unintuitive and sub-optimal, but other than that I'm having trouble differentiating basic CSS (e.x. using only element ids and styling rules) and how you end up styling components on mobile now...
Maybe where we're differing is on a more fundamental level as far as whether styling should be separate from layout in the first place? But even then you have access to `style` attributes in HTML...
https://www.w3.org/TR/css-2017
It's enormous! How could anything be intuitive when there are hundreds of keywords?
To give a more specific case, I would argue that CSS is eminently un-guessable. Take for example the CSS property clear:
"clear" is a magic word I just have to know when I'm dealing with float layouts so that my elements end up the place I want them to. It's not a concept that flows naturally from the way designers think about layouts, it's essentially a special case , an implementation detail which has been sloppily bubbled up to the CSS API. CSS is full of these special cases.By contrast, a constraint-based layout is built on a few extensible contexts. Essentially you have a hand-full of layout anchors on each object, and you have a short list different possible relationship types between anchors. From those core principals you can build up any kind of layout you want.
> https://www.w3.org/TR/css-2017
> It's enormous! How could anything be intuitive when there are hundreds of keywords?
But I covered this though -- you don't have to take the whole HTML/CSS spec, because if you did you'd just be making a browser.
Even if there are hundreds of keywords, you generally don't have to know (or support, as an implementer) every single one.
> To give a more specific case, I would argue that CSS is eminently un-guessable. Take for example the CSS property clear: [example]
The example you gave is pathological -- a more reasonable one for a "basic design problem", which is what you said CSS was bad for:
Your very next sentence betrays how pathological the case is:> "clear" is a magic word I just have to know when I'm dealing with float layouts so that my elements end up the place I want them to. It's not a concept that flows naturally from the way designers think about layouts, it's essentially a special case , an implementation detail which has been sloppily bubbled up to the CSS API. CSS is full of these special cases.
"clear" isn't magic, it requires knowing what a float layout is, and having used a float layout before. It is a special case reserved for building float layouts, that is necessary because of how they work.
I don't disagree with you that float layouts are terribad and shouldn't be used these days, but that's the beauty all those keywords in the CSS spec -- you don't have to use it. These days we have Flexbox & Grid, decently engineering solutions for layouts.
> By contrast, a constraint-based layout is built on a few extensible contexts. Essentially you have a hand-full of layout anchors on each object, and you have a short list different possible relationship types between anchors. From those core principals you can build up any kind of layout you want.
Could you de-jargon these sentences? Maybe this is where we differ, I think what you just described is more complex than CSS from principles. Also, I want to note that not many in this thread have stuck up for the simplicity/ease of use of AutoLayout.
Flexbox was proposed in 2009, and it hasn't been widely available until years after that. The iOS and Android layout systems are functionally older than the "good" parts of CSS you speak of (I would agree FlexBox and Grid are actually fine, although not as complete of a solution as constraint-based layouts).
Moreover, if mobile did just use a subset of CSS for it's layout system, you'd just worsen the fragmentation problem that CSS currently suffers from: in order to write "cross-platform" css, which you cited as one of the benefits of this approach, you would need to account for _even more_ platforms with slightly different APIs. To make a layout which works on, say, IE 9 and Android you would still have to implement twice, or resort to workarounds like polyfills.
> Could you de-jargon these sentences?
If that seems like jargon to you, I would have the suspicion that you have never put the time in to learn the basic auto-layout concepts. If that's the case I'm not sure how you can compare them.
The point is that with autolayout, the total number of things you can do could be written on one page. You have a hand-full of general-purpose building blocks, and you compose them together to do whatever layout you want. That's compared to CSS where there's a large collection of tools, each of which has holes.
And when was AutoLayout introduced? Even with that, it's evolved and been improved over time -- I bet you wouldn't want to use AutoLayout from 2016 today if you could avoid it. Either way, Apple could have introduced AutoLayout as a private extension of CSS that doesn't worry about being spec-compliant, without completely rebuilding their own framework for styling.
Are you implying the android layout systems are older than CSS itself? Because one of the "good" parts of CSS I was talking about was basic targeting and separation of concerns between styling and layout. That's fundamental CSS, and long predates any mobile platforms.
People writing mobile apps, especiallly native ones don't give a shit about cross-platform anything, I don't understand why you'd all of a sudden start worrying about that if you used CSS. I keep repeating this, but they can make their own private subset of the CSS spec that only their developers have to care about.
You've framed the burden of cross-platform support as a bad thing, but it's a good thing -- whatever that cost is, you pay it once, for everyone -- you prefer a world where cross-platform support is just impossible?
> If that seems like jargon to you, I would have the suspicion that you have never put the time in to learn the basic auto-layout concepts. If that's the case I'm not sure how you can compare them.
This a common mindset that I've never agreed with. If you can't explain the simplest uses of your abstraction without a sentence full of jargon, this is a red flag for me, it's a shitty abstraction. Jargon is calcified complexity that is so burdensome to try and explain/analogize that you just pick a word and say it instead. This is like what people say who build ridiculous Java class/pattern riddled sand castles all day, then say that if I don't understand why they needed a AbstractThingFactoryMakerService then I didn't learn the basics.
This is precisely why I will never willingly enter the quagmire that is fully native development, there are people like you in the wild waiting to justify any bad design decision the native platform makes once they've paid the cost of learning a subpar abstraction/re-engineering of a mostly solved problem that's been foisted upon them. You'll to shout how good AutoLayout is from the rooftops while devs flock to alternatives because of the BS.
NativeScript and Flutter are gaining popularity because the platforms have issues. You can ignore it for however long you want.
Actually you seem to be the one who is guilty of exactly this. I am speaking from experience with CSS _and_ mobile layout systems, and _you_ seem to be the one who is afraid to step out of your CSS comfort zone, and assume that the system which is familiar to you is the best system without trying (or apparently reading up on) the alternatives. Your entire argument against AutoLayout seems to be that other people don't like AutoLayout. If you haven't bothered to learn about the basic concepts, how can you possibly know it's so bad? And frankly the level of projection and vitriol in your comments is disappointing to see on Hacker News.
> Are you implying the android layout systems are older than CSS itself?
No, I'm implying that it would have been a bad decision for the mobile UI systems to have been built around CSS before it had decent layout solutions like flex-box and grid.
> And when was AutoLayout introduced?
It's not relevant. AutoLayout is an evolution of the iOS UI system, so comparing the origin of AutoLayout to the origin of FlexBox is orthogonal to my point.
You've also assumed that because I think CSS is better at solving basic problems these days that I haven't used used AutoLayout. I have used AutoLayout and it wasn't a good experience. I've also used Android's XML soup based layout, neither is fun and they solve problems CSS has already solved. I write both android and ios apps and have moved off native development because of frustrations with the little differences between both of the platforms.
> No, I'm implying that it would have been a bad decision for the mobile UI systems to have been built around CSS before it had decent layout solutions like flex-box and grid.
Yeah except like I've said roughly 5 times now, they didn't have to take ALL of CSS. They could have built extensions to it, possibly benefiting the whole ecosystem, or anyone else -- at the very least, leverage what CSS has already solved well and then build upon it.
> It's not relevant. AutoLayout is an evolution of the iOS UI system, so comparing the origin of AutoLayout to the origin of FlexBox is orthogonal to my point.
Of course it isn't relevant -- because you don't have a choice. I was comparing the origin and evolution of AutoLayout to the origin and evolution of CSS -- CSS might move slow, but it's pushed forward by entities that do exploratory work, contribute back and improve things for everyone.
AutoLayout does not improve on the basics that CSS offers -- targeting and styling an element is basically the simplest it gets, and it's straight-forward to understand. CSS has iteratively gotten better over the years, steered by a bunch of groups, and is sufficiently extensible to contain AutoLayout's functionality. A world where CSS could be worse than AutoLayout basically doesn't exist, because you could literally make a CSS, strip whatever you don't like out, and implement AutoLayout.
But if you’re working alone on a small project , doing everything in the storyboard could be an option.
Unless two people change the same view at the same time, it won't have problems.
And that's a management problem of putting two people doing the same problem.
It's XML and it's easy to understand even.
Also, separate components into different storyboards.
If you compare the time spent on merge issues to the enormous amount of time waisted on coding UI manually it's not even close.
storyboard are meant to design workflow, so at least two screen but often more than that. The more you put screens in the same storyboard, the more the chances of a git merge issue.
Git merge on storyboard aren’t a minor issue, they can take someone about an hour a day every day for the duration of the project, since most work on an iphone app is correlated with GUI changes.
( and then again it gets worse the more screens you have in a single storyboard).
I personnaly didn’t think it was a problem until i had to manage a team of 11 ios developers working in parallel on a single app in rush mode. In that case storyboard are simply out of question.
That sounds very reasonable. I find IB to be excellent for creating layouts quickly, especially combined with @IBDesignable and @IBInspectable.
My problem with relying on storyboards has been when I need to reuse a layout in a separate workflows. What’s nice about your technique is that it allows separate storyboards but also layout reuse with nibs.
- In the storyboard, delete the root view for the view controller.
- Create a new xib named the same as the view controller's class and that will get loaded without having to do anything additional.
Here's a quick example of what I'm talking about: https://github.com/jawngee/StoryboardWithXibs
Creating a programmatic router to create view controllers is a much better, faster, and most importantly, testable way to do things.
The core point - you can't code review storyboards/XIB - still stands. That makes them untenable for large teams of professional developers where quality matters.
This might have been true when there was a single screen size on iOS and people could get away with hardcoded “pixel perfect” frames, but that’s just sloppy.
That’s how you get half-baked apps that don’t properly support right-to-left languages or accessibility features like dynamic type.
In fact, it's easier to make dynamic views in code. What if you want some part of your layout to change based on the size of a view (as determined by screen size, dynamic type setting, language and so on)? Do you create two separate XIB files? How do you keep them in sync?
IB has the resources to handle exactly that, it's called "vary for traits".
If you are doing the math, AutoLayout is precisely made to that for you.
Even if you want to not use constants (ex: use the sinus function), you can do just the important part in code and alter the IB constraints's constants. Done.
Let me give a concrete example. Say you're writing a view to display a photo in a swipeable gallery. You want to position the associated UI elements where there happens to be room around the photo. That is, when the photo is tall, you want the UI to be placed on the side, but when the photo is wide, you'd prefer the UI to go on the bottom. The individual UI elements are mostly the same, but the layout is different for each state.
With -layoutSubviews, you can write your two layouts as usual, then use an if statement to switch between them:
Shared code can be factored out as necessary. Animation can be done with the following pattern: How would you specify these two states using IB/autolayout? And how would you animate between the states as you swipe between photos?If I wanted to do that, I would but the buttons with two constraints to the bottom and to the trailing (right), and I would change the constants of those two constraints, it's even easy because it's just swapping the constants of the constraint pair.
Having spent years on this crap, I can only conclude that it is such a dire, revolting mess for one reason and one reason only: vendor lockin.
You're not going to be taking that UI code anywhere else. And that's the point, imho.
Android XML has a lot of bad stuff in it too. Like all the styling that needs to be done through obscure XML tags, selectors, layer-lists, style-inheritance in separate files and so on.
Also ConstraintLayout is basically AutoLayout, I have been using Anko Layout DSL more and more instead of XML, which then really isn't that different from iOS+SnapKit.
What I loved about Android XML was the live preview stuff. Made dev much, much faster.
Nibs and storyboards are simple, declarative XML files. They just come with a nice GUI editor.
Warning: you MUST NOT do this for UITableViewCell/UICollectionViewCells’ contentViews.
https://github.com/SnapKit/Masonry/issues/492
But when people use these libraries that “helpfully” set `translatesAutoresizingMaskIntoConstraints = false` for them and they don’t understand what’s going on under the hood, their layout breaks and they start complaining about autolayout being “buggy”.
Also, notice that translatesAutoresizingMaskIntoConstraints will only be set on the view which you call `layout` on. I.e. this is bogus:
But this is “fine”: Of course now you’re relying on implementation details of SnapKot/Masonry/whatever.I personally just use the built-in anchor APIs with a few helpers (e.g. to create constraints to match all 4 edges of two views). In swift you have operator+ for arrays, so NSLayoutConstraints.activate(...) can be pretty succint this way.