7 ms·

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

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).
    - bunnycorn 8y ago
      We don't have that problem, we have CI with UI tests.
      - mpweiher 8y ago
        Wow, your CI automagically fixes merge conflicts?
    - jchb 8y ago
      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.
- aaaaaaaaaab 8y ago
  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. Sorry webdevs ¯\_(ツ)_/¯
hardwaresofton 8y ago
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.
- bunnycorn 8y ago
  Then, why should anyone learn React? Isn't HTML + CSS the universal language for GUI's?
  - sdegutis 8y ago
    React sits on top of those. It uses HTML+CSS for visualization. React just does the logic for what HTML and CSS to display.
    - bunnycorn 8y ago
      React is that, but React Native which competes with WPF, UIKit, and android.view is not that.
  - hardwaresofton 8y ago
    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. [0]: https://developer.mozilla.org/en-US/docs/Web/Web_Components https://developer.mozilla.org/en-US/docs/Web/Web_Components
eugeniub 8y ago
So all of the scenes in your storyboards are blank? According to whom is this a "best practice"?
- bsaul 8y ago
  According to anyone that has ever tried to git merge a storyboard. But if you’re working alone on a small project , doing everything in the storyboard could be an option.
  - bunnycorn 8y ago
    What's the problem then? 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.
  - skohan 8y ago
    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.
    - bsaul 8y ago
      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.
programmarchy 8y ago
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.
- jawngee 8y ago
  Actually, iOS will automagically load your xib for your view controllers at runtime. - 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 https://github.com/jawngee/StoryboardWithXibs
matchbok 8y ago
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.

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).
  - bunnycorn 8y ago
    We don't have that problem, we have CI with UI tests.
    - mpweiher 8y ago
      Wow, your CI automagically fixes merge conflicts?
  - jchb 8y ago
    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.
aaaaaaaaaab 8y ago
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. Sorry webdevs ¯\_(ツ)_/¯

hardwaresofton 8y ago

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.

bunnycorn 8y ago
Then, why should anyone learn React? Isn't HTML + CSS the universal language for GUI's?
- sdegutis 8y ago
  React sits on top of those. It uses HTML+CSS for visualization. React just does the logic for what HTML and CSS to display.
  - bunnycorn 8y ago
    React is that, but React Native which competes with WPF, UIKit, and android.view is not that.
- hardwaresofton 8y ago
  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. [0]: https://developer.mozilla.org/en-US/docs/Web/Web_Components https://developer.mozilla.org/en-US/docs/Web/Web_Components

eugeniub 8y ago

So all of the scenes in your storyboards are blank? According to whom is this a "best practice"?

bsaul 8y ago
According to anyone that has ever tried to git merge a storyboard. But if you’re working alone on a small project , doing everything in the storyboard could be an option.
- bunnycorn 8y ago
  What's the problem then? 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.
- skohan 8y ago
  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.
  - bsaul 8y ago
    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.

programmarchy 8y ago

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.

jawngee 8y ago
Actually, iOS will automagically load your xib for your view controllers at runtime. - 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 https://github.com/jawngee/StoryboardWithXibs

matchbok 8y ago

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.