4 ms·

> You don't have to forego all of the features of the IDE just because you prefer to do UI layout in code. I don't understand why you would do your UI layout i

> You don't have to forego all of the features of the IDE just because you prefer to do UI layout in code. I don't understand why you would do your UI layout in code if you can avoid it. If someone ever joins my team or inherits my code base, they're now partly responsible for maintaining the UI. Xib's and storyboards help with maintainability, legibility, and drastically lower the number of lines of code. The author even says: > Find an example program that works then reduce lines until I can reduce no more making a minimal example that works - then understand every line If you care about the line count, then why are you doing all your UI in code?

seivan 11y ago
Well until Xcode 6 (I think). Neither xibs nore storyboards were indexable. Meaning if you wanted to find something related to your layout, you would had to search through xml. Also much easier to refactor typed code than xml ;)
- allsystemsgo 11y ago
  Wait, why would you fix your layout bugs by searching through XML? Why not just use interface builder?
  - seivan 11y ago
    Because you'd have to manually go through maybe > 39 scenes spread across 10 storyboards manually keep track of what's changed and find the next outlet you want to modify.
cballard 11y ago
Layout done in code: - Is type-safe, which is verified at compile-time. - Will break at compile-time if a breaking change is made. - Can be null-safe, without having to use Optional for everything. - Can do things iteratively. - Can use constants, so that you can easily modify standard paddings and sizes globally with one change. So those are some of the advantages of doing layout in code.
- allsystemsgo 11y ago
  Right but you'd have to document what each constant represents. Interface builder gives us a universal language. You know what the UI will look like or how it will resize etc. because it's right there. There's no confusing constant names with magic numbers. You know the why behind the constraint values because you can see it.
  - deleted 11y ago
    [deleted]
  - rimantas 11y ago
    Constants are not magic numbers. And with proper naming they document themselves. For more cusotm UI's you won't know how UI will look like. It got better with @IBDesignable but still not enough.
mahyarm 11y ago
xibs are not mergable. Have 2-3 people working on the same xib, and it's a mess to merge. It needs to become human editable. That is the major reason why for most larger projects. Also xib tooling can be a pain for complicated layouts.
- allsystemsgo 11y ago
  Yeah I disagree. I work for an agency that's almost all giant big-brand apps. You just task developers with separate sections in the app. You can use multiple storyboards in your app (which comes as a surprise to some). So you break down the user flows so its more manageable. The merge conflicts should be few and far between. How is setting up constraints a pain in xibs? It's hardly anymore difficult than typing it in code.
  - mahyarm 11y ago
    So basically, you have to lock xib files, coordinate that your locking xib files and are unable to work simultaneously on the same xib file? With android you have human editable xib equivalents, so you don't have to do any of that. Go to any large iOS project and you'll find them not using xibs eventually. Also I'm guessing your agency doesn't have 10-100 iOS engineers working on the same app, for years, with different engineers in different buildings? You're probably small teams working on contract for a starbucks app for example? That is usually teams of 5 iOS engineers max, where xibs work. xibs can be pretty annoying to work with if you have multiple overlapping views. It simpler for me to deal with them in code. Masonry also makes specifying constraints pretty easy.
    - im_down_w_otp 11y ago
      With all due respect... what in the name of holy hell mobile app can possibly require 100 engineers working together over several years all on the parts that touch the UI? I can barely think of even the most complicated thick-client enterprise apps (where the UX is just awful and customizable to death with window upon window upon pane upon tab upon tab upon pane clusterf*ck layouts) I've ever seen that required anywhere near that many core UI engineers. That just seems like a number of engineers toiling away in parallel that raises a "maybe you're doing it wrong" flag for me. :-/ This is genuine curiosity because I find that just epically flabbergasting.

seivan 11y ago

Well until Xcode 6 (I think). Neither xibs nore storyboards were indexable. Meaning if you wanted to find something related to your layout, you would had to search through xml. Also much easier to refactor typed code than xml ;)

allsystemsgo 11y ago
Wait, why would you fix your layout bugs by searching through XML? Why not just use interface builder?
- seivan 11y ago
  Because you'd have to manually go through maybe > 39 scenes spread across 10 storyboards manually keep track of what's changed and find the next outlet you want to modify.

cballard 11y ago

Layout done in code: - Is type-safe, which is verified at compile-time. - Will break at compile-time if a breaking change is made. - Can be null-safe, without having to use Optional for everything. - Can do things iteratively. - Can use constants, so that you can easily modify standard paddings and sizes globally with one change. So those are some of the advantages of doing layout in code.

allsystemsgo 11y ago
Right but you'd have to document what each constant represents. Interface builder gives us a universal language. You know what the UI will look like or how it will resize etc. because it's right there. There's no confusing constant names with magic numbers. You know the why behind the constraint values because you can see it.
- deleted 11y ago
  [deleted]
- rimantas 11y ago
  Constants are not magic numbers. And with proper naming they document themselves. For more cusotm UI's you won't know how UI will look like. It got better with @IBDesignable but still not enough.

mahyarm 11y ago

xibs are not mergable. Have 2-3 people working on the same xib, and it's a mess to merge. It needs to become human editable. That is the major reason why for most larger projects. Also xib tooling can be a pain for complicated layouts.

allsystemsgo 11y ago
Yeah I disagree. I work for an agency that's almost all giant big-brand apps. You just task developers with separate sections in the app. You can use multiple storyboards in your app (which comes as a surprise to some). So you break down the user flows so its more manageable. The merge conflicts should be few and far between. How is setting up constraints a pain in xibs? It's hardly anymore difficult than typing it in code.
- mahyarm 11y ago
  So basically, you have to lock xib files, coordinate that your locking xib files and are unable to work simultaneously on the same xib file? With android you have human editable xib equivalents, so you don't have to do any of that. Go to any large iOS project and you'll find them not using xibs eventually. Also I'm guessing your agency doesn't have 10-100 iOS engineers working on the same app, for years, with different engineers in different buildings? You're probably small teams working on contract for a starbucks app for example? That is usually teams of 5 iOS engineers max, where xibs work. xibs can be pretty annoying to work with if you have multiple overlapping views. It simpler for me to deal with them in code. Masonry also makes specifying constraints pretty easy.
  - im_down_w_otp 11y ago
    With all due respect... what in the name of holy hell mobile app can possibly require 100 engineers working together over several years all on the parts that touch the UI? I can barely think of even the most complicated thick-client enterprise apps (where the UX is just awful and customizable to death with window upon window upon pane upon tab upon tab upon pane clusterf*ck layouts) I've ever seen that required anywhere near that many core UI engineers. That just seems like a number of engineers toiling away in parallel that raises a "maybe you're doing it wrong" flag for me. :-/ This is genuine curiosity because I find that just epically flabbergasting.