10 ms·

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 i

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.

mmjaa 8y ago
>Why can't we have simple declarative markup to create UI? 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.
- oblio 8y ago
  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.
  - mmjaa 8y ago
    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 ..
saagarjha 8y ago
This may be pedantic, but storyboard files are XML too. And Apple does have a DSL for AutoLayout: it’s call the Visual Formal Language.
- sedatk 8y ago
  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.
  - bunnycorn 8y ago
    The "lack" of styling is because you are supposed to declare the theming programmatically and be done with it (UIApperance) For 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.
    - pjmlp 8y ago
      Just like you can when using Blend.
      - bunnycorn 8y ago
        No, Blend only works one way. 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.
        pjmlp 8y ago
        You can do that by implementing designer aware controls since .NET 1.0, so I don't see the difference, other than having a bit extra code maybe.
        jchb 8y ago
        I suppose you are referring to this WPF functionality https://docs.microsoft.com/en-us/dotnet/framework/wpf/controls/creating-a-control-that-has-a-customizable-appearance https://docs.microsoft.com/en-us/dotnet/framework/wpf/contro..., and similarly in UWP: https://docs.microsoft.com/en-us/windows/uwp/design/controls-and-patterns/control-templates#specify-the-visual-behavior-of-a-control https://docs.microsoft.com/en-us/windows/uwp/design/controls...? While it looks powerful, I have to say that the Xcode interface builder and code annotation approach has a lot less friction.
- setpatchaddress 8y ago
  VFL can’t express anything beyond the most simple relationships. I don’t agree with grandparent’s characterization of autolayout, though.
  - bunnycorn 8y ago
    Define "simple". It can generate very complex layouts, without inputing a single line of code. It's more capable than any other layouting system.
    - ken 8y ago
      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.
      - bunnycorn 8y ago
        You clearly don't know nothing about what you are talking about. > "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 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.
bunnycorn 8y ago
"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).
- skohan 8y ago
  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?
  - saagarjha 8y ago
    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.
    - skohan 8y ago
      Yes, and one of those things that comes for free is a very good UI layout system and tooling.
- matchbok 8y ago
  I do, actually. Have been for about 6 years. 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)
acoye 8y ago
> 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 … So to me, oddly, I always found Autolayout easy. https://en.wikipedia.org/wiki/Screw_theory https://en.wikipedia.org/wiki/Screw_theory
- kbenson 8y ago
  > 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.
jawngee 8y ago
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.
- ardit33 8y ago
  To be honest, storyboards are either a rookie tool, or usable for small to medium apps. Most large apps don't use them at all. And yes, autolayout is a shitshow, hence the countless utilities and frameworks built on top of it to make it more palatable.
  - bunnycorn 8y ago
    > Most large apps don't use them at all. 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.
    - Aqua_Geek 8y ago
      > 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).
panic 8y ago
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.
- aaaaaaaaaab 8y ago
  Pardon? 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.
  - panic 8y ago
    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?
    - bunnycorn 8y ago
      > 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.
      - deleted 8y ago
        [deleted]
      - 8y ago
tabs_masterrace 8y ago
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.
- matchbok 8y ago
  Love SnapKit. Agreed on the weird XML stuff though. What I loved about Android XML was the live preview stuff. Made dev much, much faster.
wool_gather 8y ago
> Why can't we have simple declarative markup to create UI? Android's xml files Nibs and storyboards are simple, declarative XML files. They just come with a nice GUI editor.
- matchbok 8y ago
  Simple? They aren't editable outside of the GUI editor. It's a mess.

mmjaa 8y ago

>Why can't we have simple declarative markup to create UI? 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.

oblio 8y ago
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.
- mmjaa 8y ago
  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 ..

saagarjha 8y ago

This may be pedantic, but storyboard files are XML too. And Apple does have a DSL for AutoLayout: it’s call the Visual Formal Language.

sedatk 8y ago
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.
- bunnycorn 8y ago
  The "lack" of styling is because you are supposed to declare the theming programmatically and be done with it (UIApperance) For 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.
  - pjmlp 8y ago
    Just like you can when using Blend.
    - bunnycorn 8y ago
      No, Blend only works one way. 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.
      - pjmlp 8y ago
        You can do that by implementing designer aware controls since .NET 1.0, so I don't see the difference, other than having a bit extra code maybe.
        jchb 8y ago
        I suppose you are referring to this WPF functionality https://docs.microsoft.com/en-us/dotnet/framework/wpf/controls/creating-a-control-that-has-a-customizable-appearance https://docs.microsoft.com/en-us/dotnet/framework/wpf/contro..., and similarly in UWP: https://docs.microsoft.com/en-us/windows/uwp/design/controls-and-patterns/control-templates#specify-the-visual-behavior-of-a-control https://docs.microsoft.com/en-us/windows/uwp/design/controls...? While it looks powerful, I have to say that the Xcode interface builder and code annotation approach has a lot less friction.
setpatchaddress 8y ago
VFL can’t express anything beyond the most simple relationships. I don’t agree with grandparent’s characterization of autolayout, though.
- bunnycorn 8y ago
  Define "simple". It can generate very complex layouts, without inputing a single line of code. It's more capable than any other layouting system.
  - ken 8y ago
    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.
    - bunnycorn 8y ago
      You clearly don't know nothing about what you are talking about. > "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 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.

bunnycorn 8y ago

"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).

skohan 8y ago
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?
- saagarjha 8y ago
  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.
  - skohan 8y ago
    Yes, and one of those things that comes for free is a very good UI layout system and tooling.
matchbok 8y ago
I do, actually. Have been for about 6 years. 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)

acoye 8y ago

> 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 … So to me, oddly, I always found Autolayout easy. https://en.wikipedia.org/wiki/Screw_theory https://en.wikipedia.org/wiki/Screw_theory

kbenson 8y ago
> 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.

jawngee 8y ago

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.

ardit33 8y ago
To be honest, storyboards are either a rookie tool, or usable for small to medium apps. Most large apps don't use them at all. And yes, autolayout is a shitshow, hence the countless utilities and frameworks built on top of it to make it more palatable.
- bunnycorn 8y ago
  > Most large apps don't use them at all. 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.
  - Aqua_Geek 8y ago
    > 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).

panic 8y ago

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.

aaaaaaaaaab 8y ago
Pardon? 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.
- panic 8y ago
  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?
  - bunnycorn 8y ago
    > 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.
    - deleted 8y ago
      [deleted]
    - 8y ago

tabs_masterrace 8y ago

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.

matchbok 8y ago
Love SnapKit. Agreed on the weird XML stuff though. What I loved about Android XML was the live preview stuff. Made dev much, much faster.

wool_gather 8y ago

> Why can't we have simple declarative markup to create UI? Android's xml files Nibs and storyboards are simple, declarative XML files. They just come with a nice GUI editor.

matchbok 8y ago
Simple? They aren't editable outside of the GUI editor. It's a mess.