4 ms·

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 s

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.
  - mahyarm 11y ago
    Facebook is one example. At my last company, there was 1 full time iOS engineer (me) and we later grew to about 18 full time iOS engineers. The xibs are painful point started happening around 8 full and part time iOS engineers. You have many part time iOS engineers who may need to touch UI once in a while, and that can cause issues. After a dozen 'I have to throw away all of my xib work and recreate it because they've committed a new version of the xib', you become fine with just not using xibs any more.
    - rimantas 11y ago
      Another annoying point is that Xcode tends to modify xib any time you open it. You don't need to do anything, just open it and boom, it gets that "M" in source control.

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.
- mahyarm 11y ago
  Facebook is one example. At my last company, there was 1 full time iOS engineer (me) and we later grew to about 18 full time iOS engineers. The xibs are painful point started happening around 8 full and part time iOS engineers. You have many part time iOS engineers who may need to touch UI once in a while, and that can cause issues. After a dozen 'I have to throw away all of my xib work and recreate it because they've committed a new version of the xib', you become fine with just not using xibs any more.
  - rimantas 11y ago
    Another annoying point is that Xcode tends to modify xib any time you open it. You don't need to do anything, just open it and boom, it gets that "M" in source control.