Absolutely, most big mobile development teams I know do not use storyboards or NIBs because they are not easily human reviewable. (A small change will rearrange sections for seemlying no reason.)
Storyboards are great - they simply force separation of concerns among developers.
One person handles one part of the app, and other people keep their hands off of it.
Each person has their storyboard/collection of nib files.
Multiple people should absolutely not be tinkering with the same files randomly - obviously I hope.
As for things rearranging for 'no reason' - it'd help if people took 2 days to understand auto layout. Every person I've ever met who dislikes sql, or storyboards/auto layout etc, simply doesn't understand what is happening.
It's trivial to create a mess in auto layout, if you don't know what you're doing, just like people create cocoapod soup in every other iOS project. There is no silver bullet for curing mediocrity - just make sure you're not part of the problem :)
Oh come on. For most parts of an application Interface Builder is just fine. Sure, for the stuff that actually matters the code is necessary because IB is not turing complete anyways.
But to arrange the view controllers and segways + some static tables it is mighty fine.
But you use live reload, no? That's just webshit for an UI editor.
WPF has(d?) this figured out. No drag and drop of UI elements (aka "components"); that gets you into "absolute position" hell of Windows Forms. Instead you have a DSL that you use to build the UI with grids and other standardized layout containers and the WYSIWYG view is there mostly as a preview and navigation help.
Of course their fatal mistake was having no code whatsoever in the DSL. They wanted to make it so designers would use it; designers will never use anything but Photoshop, so the other half of them that isn't resistant to learning now calls themselves frontend developers. The model binding on steroids helped some but still "inverting" an enum required 15 lines of code somewhere else to create a converter.
I think that is a uniquely iOS thing since they insist on using computer generated IDs to link objects together, while %100 human editable UI formats like HTML or Android's UI XML formats don't do that.
It's the same issue that project.pbxproj has in Xcode.
Exactly. I feel like the design experience of HTML/CSS is the best of both worlds. You're designing in code, but it's not imperative code, which is what you have to do in iOS if you want to escape the NIB. Using declarative code to define your interface just...makes sense.
Using a UI to build UI is slow and clunky. There is no "moving past" it. That's a bad way to develop stuff. We don't do it with HTML, do we? No.