Thoughts from an iPad

Marco:

When implementing these features, I felt like iOS had given me far too much access to Address Book without forcing a user prompt. It felt a bit dirty. Even though I was only accessing the data when a customer explicitly asked me to, I wanted to look at only what I needed to and get out of there as quickly as possible. I never even considered storing the data server-side or looking at more than I needed to.

When I had to access the address book I felt the exact same way. Most users, however, don’t care. Going back to Apple’s basic concept: it just works. Location, unlike address book, is time-sensative. There is a specific time associated with the location. Depending on how wide of a span worth of data you have, the creepier you can be (e.g. calculating speed, possible routes, destinations, etc). He goes on:

But Apple can, and should, assure users that no app can read their contact data without their knowledge and explicit permission. I don’t know why this hasn’t always been required, but it probably isn’t a good enough reason to justify the erosion of user trust in iOS apps that this could cause.

Come on. I’ll meet you half way: give users an option to decide this on an app-by-app basis, but not by default. A little toggle in Settings.app to lock down the address book with a bunch of on/off toggles for each app that pop-open below.

And he goes on:

Apple needs to change the Address Book API to require user permission first, like Core Location and Push Notifications do. I don’t care how many applications break as a result.

Consider this from a development perspective, oh mighty developer. Every application that uses a single ABAddressBookRef or any related function breaks. Except wait, they linked to AddressBook framework. So when AddressBook framework can’t talk to Apple’s hooks, AddressBook framework causes your app to crash. The only way to see this is to update your dev tools and realize none of the function hooks exist anymore. Or maybe they do exist, but Apple is blocking the thread so that it can popup the UI alert. The only way this is possible is to deprecate AddressBook framework as is, for the whole course of iOS 5.1, or even iOS 6. And provide the new alternative as the “go to” method. In iOS 7, they can finally remove it. Alright, sounds good. 2 years later.

John Gruber:

Why not run the iBookstore the way they’re running the Mac App Store? The fact that Mac apps can be sold directly doesn’t seem to be slowing the growth of the Mac App Store.

When it comes to Mac apps, Apple had no choice but to allow external sales. Mac apps have always had that exposure, and Apple knows most users would rather have all their apps under an account where they (a) don’t worry about serials (i.e. digging through old emails), (b) don’t wonder which apps they bought, (b) can re-download with 1 click anytime.

So naturally users will generally want to use the Mac app store. But with the iPhone there was never another official way to install apps, so Apple could set the standard. Code signing, limited APIs, etc. But more importantly, their store is the only way to install apps - and it’s better for everyone.

They’re doing the same thing with textbooks. Up until now you either used a standard e-book, or wrote a custom app. Standard e-books are ugly and boring. Custom apps are big projects, but allow 100% customizability. Apple went right in the middle - they made a tool easy enough for authors and publishers to use, but they kept their standards as high as the iOS app store.

Complain about it all you want, but textbooks is a godsend for publishers and independent authors.

John Gruber:

Android smartphones have grown enormously in order to accommodate LTE. Currently-available LTE chipsets are physically bigger […] and because they’re so power-hungry, they require bigger batteries. Thicker phones aren’t going to fly. Thus: wider and taller phones with displays expanding to fill the surface.

Great collection of photographs. They fit perfect on my iPhone 4.