Hacker News Reader

Comment by moca | Hacker News Reader

iOS apps use fixed layout, so they can't scale up/down with different display sizes. Since iOS only did double density once so far before iPhone 6 Plus, apps are quite easy to handle it. Android has way more variety, which is a pain for app developers.

View on HN

This isn't correct. If you've ever resized an application window in OS X, it's likely that you've used autolayout. iOS has the same functionality. In addition to a flexible layout system, iOS has the concept of size classes which determine appropriate content to show based on display size.

But I can imagine that many iOS apps still use 'a fixed layout', as the parent comment stated (or perhaps at max use the old struts and springs mechanism). This may be quite a few and they could all break if Apple had not come up with the 'cheat', as the top comment called it.

I doubt that too many do, or at least many that are actively maintained.

The introduction of the taller iPhone 5 screen, and Apple's subsequent rejection of "letterboxed" apps (ones that don't make any use of the additional screen space) mean that most developers will almost certainly have switched to autolayout.

I still don't understand the "cheat". Any well-designed app that wants to take advantage of larger screen sizes on the new iPhones to display more content will use autolayout and the new size classes (compact and regular). There is no cheating involved.

For transition purposes, apps that haven't been updated yet will simply be scaled up (everything on screen will be slightly bigger). This is similar to when the iPhone 5 introduced a lengthened screen and apps were letterboxed until they submitted an update confirming that they were compatible with the larger screen.

iOS has always been able to do fluid layouts. It was possible with Springs and Struts (though a PITA), and from iOS 6 onwards has Auto Layout, which I personally find better (more declarative) than Android's box model.

I would also like to point out that there is a JailBrake tweak, FullForce, that lets you stretch most iPhone apps to iPad screen. Most iPhone apps can actually stretch and grow, and can actually do so pretty well. And, it worked even before auto layout. Apple, stupidly, did not allow legacy apps to auto stretch on iPhone 5 because (a) they wanted to force developers to update, and (b) they are paranoid about some things not working perfectly. A tweak like full force could have starched 90% of all iPhone 4 apps to iPhone 5 screen, but Apple would not allow it because of the 10% that would not work so well. But the software supports it, and to claim otherwise is silly.

I agree that it isn't as big a deal as some people are making out. But at the end of the day you can't disagree that it was a massive flaw from the beginning of the iPhone (and its days before it let people develop apps for it) driven likely by the megalomaniac supposition that if you build a phone you can't reach all parts with from your thumb: "no one's going to buy that."*

*http://goo.gl/pTwfws

Can't agree with this at all. Auto Layout can do some things that are very hard to do with Android layouts but for the common cases I find Android's layouts vastly more logical and maintainable than the typical Auto Layout mess. There are fewer things I dread more than opening up a complex xib file to dig into a complex Auto Layout scheme. Let the hunt & peck party begin!

I can open up an Android layout file and almost instantly understand how it works and what I have to do to change it.

It might be too late for your project, but I'd highly recommend using Masonry (https://github.com/Masonry/Masonry) for Autolayout. It's a DSL for specifying constraints that is far better than Apple's NSConstraint API and constraint language.

Since discovering it I've fallen in love with Autolayout and its abilities — where I used to dislike it before.

For me, it comes down to the fact that I find Auto Layout more declarative. I'm `saying what I mean` when I apply constraints - that can be done in code too, of course, although Xcode 6 is getting pretty good at surfacing that information. Whereas when I'm dealing with a box model I'm having to play compiler in my head. LinearLayout, RelativeLayout - these are terms that are optimised for the computer to understand. Constraints are the way we humans think about things. "Element A should always be 10 points to the left of Element B".

It's a bit like imperative vs. functional programming. In the former model, I have an idea in my head and I need to nest containers step by step to get to the final form. In the latter I'm simply building up a ruleset.

But like I said, that was my personal preference. I guess we'll have to differ on opinions ;)

Reply on news.ycombinator.com