Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The whole Address Book framework on iOS seems to have gotten the shit end of the doody stick when they were handing out skilled programmer-hours at Apple.

For example it's inexplicably implemented as a bunch of low-level Core Foundation calls even though it's not remotely a performance bottleneck in any conceivable use case and 90% of the apps using it immediately wrap every query result in some kind of half-baked Objective-C container. And although 99.9% of the code using it wants to use it a simple contacts database, the APIs are designed to be as general as possible and thus are even more needlessly hard to use.

My guess is there has been a "Do something about Address Book on iOS" item on Apple's to-do list for the last couple of years and this permission business always got pigeonholed under that item, until this latest shitstorm demanded a short-term fix.

It's going to be interesting how they implement this for existing apps, since there is no "The user said 'No'" return value for any of the APIs. I guess they're just going to have to return an empty address book or a "record deleted" result code when the user declines access for an app.



It would be interesting to see what might happen in either of those use-cases for an app which syncs address books with a remote service, such as Google, Yahoo! or CRM tools. It's entirely conceivable that if a user hits no it could have rammifications to other systems which wouldn't expect either of these results.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: