Thoughts from an iPad

John Gruber:

Maybe the answer to the iOS address book situation is to require the user to grant explicit permission through a dialog box, but it’s not a slam-dunk decision. Every dialog box has a cost.

That’s one answer, sure. But I think you’re solving the wrong problem. I think theres an inherit flaw in how all of the APIs come together and the assumptions developers are allowed to make when it comes to privacy.

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.

You need to learn Objective-C. Go mess with MonoTouch or whatever if you want. Then go grab a fruit roll-up, think about what you did, and realize you should have just learned Objective-C.

An entertaining post with an amazing level of truthfulness. What more can I say?

Chris Eidhof, who just launched TrackMe for iOS:

Applications are very polished, and you can see that developers really put effort into building their products. This is a lot of fun and very inspiring for a developer. It pushes you to raise the bar and have higher standards.

But of course you have to make money too:

It’s a lot easier to sell to high-end customers.

Everyone is going crazy about the issue of iOS devices storing your location data in an unprotected file. Which just happens to get copied over to your computer when you backup your device. As far as I’m concerned this is only an issue because how far back the data dates.

If the data was no longer than a few days old then I wouldn’t have a problem with it. Recent data is helpful to the phone for various reasons. If your phone has data from an hour ago, then when it won’t necessarily use as much energy to figure out what GPS satellites it should be looking for the next time you look at the map. This is just one example, but the same concept applies to the rest of the data as well.

I would like to urge you to take the time and read this article which explains it in much more detail. It’ll also give you some history about this file, and the story of where it was before iOS 4.

Jon Evans from TechCrunch:

 Why should you care? Because these are (often) the main reasons why your apps suck, or crash, or both.

I’d argue he is incorrect. I don’t think “what app developers want” is relevant. It’s really simple: if you want to develop for the iOS then you follow Apple’s guidelines, rules and documentation. If your app isn’t good enough, it gets rejected. 

WWDC sold out faster than ever before. People want to develop for the iOS. Sure Apple could make things easier for developers, but that won’t make much of a difference to the user’s experience. If anything that would bring even more poorly put together applications to the app store - something I don’t look forward to.

Look at the actual app icon on the actual device. A lot. No amount of mocking up in Photoshop is good enough; the designer should absolutely check the real binary with the final icon on an iPad and confirm that everything is copacetic.

It’s simple advice, but it isn’t followed nearly enough. You take the time to make an application for the iPhone or iPad, and then rush it to the market and miss the little details?