Hi, thank you for the detailed answer, I'll add some thoughts:
> Yes, IB is basically used as a visual header file when I do it this way (you save a few lines of code since you don't have to instantiate views in code, but yes).
That's what I thought. And I don find this a bit messy on the long term.
I've had to update large projects where many devs did that, and it was quite messy, especially when the unused elements are not removed. You end up with a view containing dozens of elements with zero visibility, as appearence is done in code. Maintaining can become a nightmare.
(thanks to that, since Xcode 6 apple provides the IBDesignable for elements done in code to appear automatically on the view, with no need to declare them in IB at all).
> For all three approaches I mentioned above, there is no direct way to do it in Interface Builder.
Actually, from what I see, the problem here isn't IB, but the design choice. That's why the design should be handled by the design team (for my teams, I split the work where designers only touch storyboards and XIBs, and programmers touch the code, with merge requests when IBOutlets are declared, this avoids conflicts and everyone can focus on its work without worrying).
Now, I do understand that not every project has large teams on it. So one good thing I see is the new stack views for iOS.
One thing can be done on your array of buttons is that if they are in (C, C), you switch the axis between vertical and horizontal which can be done in IB alone, but can be done in code if orientation for the 3.5 and iPad are required ... (That's where I'd like complex expressions for IB, such as a boolean comparing height and width of parentview or the screen).
> Well, I think there should be a default configuration (perhaps like the way things are now). But if the developer determines that the default way size classes are is not going to suit the layout, he should be able to easily modify the defaults and customize it.
Well, while I agree that giving more contrl to developers is the best thing that can be done, but in this specific case, it's Apple who decides which sizes are available for the end user (both screens and splits), so I guess it's fine if they decide which are the steps.
Now, when you make your layout, you can easily customize only the class that you want, and let the others act normally, for example, most of the designs I've received have two layouts depending on orientations and a specific layout for the 3.5 or iPads, so my size classes are all set to (Any, Any) with a 600 priority, then only the one extra hack for the specific class at a higher priority.
Of course, I regret more choices, such as a "Large" size class for iPads, it would help differenciate a landscape 1/2 split and full screen (now both receive (R,R) and there is no way to differenciate between them even in code).
> As bad as CSS/HTML/JS even CSS has support for applying styles based on the dimensions of the browser.
I aggree but that's because a browser can beresized on whim, while size classes (from the end user point of view) are limited to few choices (1/3, 1/2 and full, and it depends on the device). Also, which different density of pixels, it can be hard to decide few things (I've worked on projects where the buttons have to adapt to their image, and the images @1, @2 and @3 have completely different sizes not based on aspect but on screen lisibility ... this was an awcward one for normal apps, bur completely normal for games).
Also, the steps in CSS depend largely on which framework you'd use (unless you code everything from scratch), and the philosophy is quite close to current size classes with the grid system (here also, the number of steps is greatly different depending on the framework, Foundation for example doesn't handle eXtra Small sizes while Bootstrap does ... It's hard to find a system that pleases everyone).
> but I really feel like I can write flexible layout code faster most of the time.
That's nice, of course it's better to chose what gets your work done the fastest and easiest way. But when in large corps and having projects that extends on many years accross many developers, IB saves the sanity of many.
I find it also easier to change the interface or adapt to new layout changes more easily in IB.
Of course, my point of view holds true especially when you have dedicated designers, as it's their job to have the UI/UX correct on all devices , orientations and splits. Programers can focus and backend code only, and specific scenarios (activating some constraints depending on orientation of iPad for example, but even in this case, the constraint should be done in IB, and the designer should have verified that activating it doesn't break any other constraint).
> Even with the default configurations now, you are encouraged to make as many constraints as you can for all devices.
May I ask where you have seen that? Because, from what I understand from your point, I was told the exact opposite at the WWDC from an UIKit engineer.
The idea is to do the minimum constraints possible for a design to work (no complaints from IB), then add only the specific override point, by switching the IB display to that size class, and be sure that are no warnings/erros in IB (somehow like in CSS where you append an override only for the specific element in a specific scenario).
> I think the best solution would be to apply reasonable behavior as the default configuration, but make it easy for developers to create custom size classes and associate them with devices for complex cases at the developer's discretion.
Completely agree with that. Actually filling a ticket for an enhacement: A "Custom expression" in IB, where we can input things such comparisons and if/else expressions.
> As far as I know, there's no supported way to give the 3.5 inch iPhone a diff. font size in IB as the other devices that share the same size classes.
iPhone 3.5 would have the same height in landscape as the 4 and 4.7, in which case adding a specific (C, C) expression would work for all.
You can explore thestack views if your project is iOS9+ only.
Now, buttons are pretty hard to handle for internal font size (that's the only example where I had to subclass), on other things (labels for example), giving the font size a large value then allowing it to scale down (or a minimum font size) and let the container scale automatically can fix things.
My projects are mostly for South East Asia, so even when subclassing it's pretty hard to get the correct size and baselines for the custom fonts. The work around is to have a button without text and a label on top of it, both centered and equal width/height of their container view, it solves the problem but hard to implement and maintain (UIStackViews do exactly the same things with ease, but for iOS9+ only projects).
