Looking to iOS6

I was asked to go over my most anticipated features in iOS6, so here goes:

Auto-Layout

Already been said but Apple is doubling down on this and wants developers to take it seriously. At it's simplest, instead of putting a button at (x: 138, y: 406), you describe it as being in the horizontal middle and 10 points from the bottom of it's parent view. For the past five years, doing it the old way has worked fine because iPhones were always 320x480 and iPads were always 1024x768. But if Apple released a device or platform with new or variable dimensions, then these methods would break down (Apple has one such platform and already implemented Auto-Layout on it: OS X Lion).

I wrote a long time ago in What separates the iOS SDK from the Android SDK? that a big differentiator between iOS and Android is how UIs are coded. Although Apple hasn't gone so far as to add an XML structure for interfaces, Auto-Layout does bring the two platforms (a tiny bit) closer in mindset. It invalidates a lot of old tutorials and books and will take some getting used to, but it really is for the better.

Maybe Apple won't release a different form factor or platform in the near-future, but it would be naive to think that we'll forever and always deal with the above two resolutions (or retina scales of them). Auto-Layout the future, and you should code to support it.

Passbook/Pass Kit

I really like this one, but it's definitely a more complex architecture for developers. If you're making an app or website which interacts with real-world goods or experiences, you can store items relating to it in the user's Passbook. Apple gives examples like boarding passes, coupons, tickets, and membership cards.

To implement it, you generate a bunch of information on your server about the pass (all the text, styles, identifiers, etc...there's just a load of options you can use). iOS6 will install this pass data through your app, an email, or a web link. You can use your app to edit existing passes, but they must be constructed on the server. There's also a lot of work to be done in keeping passes in-sync between client and server (did the user change their seats? upgrade their membership? stuff like that). Good opportunity for a Ruby library to help out with this stuff.

As a user, this is what I'm the most excited about. There are multiple startups already trying to solve the same problem, but Apple has the sheer size and pull to make it go mainstream. Color me excited.

Privacy

After the giant contacts-privacy debacle, Apple has added privacy dialogs for most pieces of user data (location, contacts, calendars, reminders, photos). Backwards compatibility exists if permission is denied by returning no data in pre-iOS6 apps, but new apps will need to monitor for changes in permission to refresh their data (i.e. I change my mind about denying your app my contact data, so I allow it in Settings.app).

Identifiers

Apple made a big hubbub when they deprecated UIDevice#uniqueIdentifier. In iOS6, there is a distinction between identifiers for advertisers and identifiers for vendors (i.e. your ID on all the apps that Facebook makes). Use the global advertiser ID only when necessary.

This was originally an answer to a Quora question