The Promise of the iOS 5 Accounts Framework

I recently signed up for Path, a mobile-only social network that is meant to be used for more intimate sharing than something like Facebook with an inherently smaller and more intimate social graph.  Path was initially only available on the iPhone but apparently now has an Android client as well.  Given its historical close ties to the iOS platform and lack of a web interface, I was curious to see what the account creation process would be.  It turns out, the account creation process is basically the same as for every other web service.  Enter an email address, select a password.

Given that the application has historically only been available on the iPhone and my iPhone certainly already knows who I am, I thought the process might be lower friction and more automatic.  I haven't done any iOS development but I thought that surely there must be some sort of single sign on capability offered by the iOS SDK.

I did some research and it turns out that as of iOS 5 there sort of is and sort of isn't.  With iOS 5, Apple has released the Accounts Framework which provides a centralized store of account information that applications can query to authenticate against web service providers.  But it currently seems only to support Twitter.  Which means, in practice, that if I wanted to create an application that supported sending tweets on behalf of the user I could tie it into the existing Twitter authentication stored on the device.  That's certainly a nice to have feature, but it's an awfully limited vision.

From looking at the Accounts Framework documentation it seems that it could also be used to store any arbitrary authentication information, such as OpenID or OAuth credentials for other services.  I don't know if anyone has actually implemented anything other than Twitter clients using it or whether it would actually work with third party accounts right now.

I'm really surprised that Apple hasn't gone the further step and decided to offer authentication in a more native way.  Every iPhone user and most iPad and iPod Touch users have an Apple Store account.  Why not expose this account, perhaps using an existing technology such as OpenID, to allow me to authenticate to third party sites?

As a developer I have no great need to own the login credentials of my site's users.  As long as I have their email address, I don't really care what password, software certificate, biometric, or smartcard methodology they are actually using to authenticate themselves.  It's one less thing to worry about when developing an application if I can leverage an existing authentication infrastructure.

As an end user, I'd love for unlocking my phone to also unlock my stored credentials and enable true web application single sign on from my mobile device.  I hope Apple sees the opportunity and includes this in iOS 6.

Does Google's Mobile Sync Replace Sync in a Blink?

I've written a lot here about the iPhone Sync in a Blink application.  Recently sync_in_a_blink_logoGoogle has released their own mobile sync solution.  It masquerades as an Exchange server from the iPhone's perspective and offers automatic wireless over the air syncing.  While running Sync in a Blink to manually sync contacts is not a huge burden for me, I'm always up for services that make my life easier.  So I've set up Google mobile sync for the iPhone to compare it to Sync in a Blink.

While Google mobile sync does indeed sync my contacts automatically, it does not provide the same sync quality as Sync in a Blink.  I had forgotten that one of the things that drove me to Sync in a Blink originally was that many of my contacts do not have email addresses.  Unfortunately, Google's sync algorithm still seems to key everything off of the email address.  Which means that notes or updates that I add on the iPhone do not propagate to my Google contacts database when those contacts do not have email addresses.

I suspect I'll turn off mobile sync and go back to using Sync in a Blink.  I may try to get them working together, although my initial attempt at doing that clobbered my contact list and I ended up having to restore my iPhone from a backup.  So I'll be more careful if I decide to go down that road again.

Figured Out the Sync in a Blink Problem

I figured out my problem with Sync in a Blink. It turns out that my five mystery different contacts had no name or company name - only email addresses. I never could find them in the Contacts app but I happened to install the iPhone Peeps app (sort of a Coverflow for contacts thing - not as great as it could be, but that's another story). Anyway, one good thing about Peeps is that it showed these five mystery contacts and I was able to edit them and add names.

Once I did that, Sync in a Blink's show ungrouped contacts option stopped crashing the app and instead correctly displayed these five rogue contacts.

Sync in a Blink Now Supports Contact Group Editing

I downloaded version 2.1 of Sync in a Blink last night and to my delight, the app now sync_in_a_blink_logosupports editing contact groups.  I had written about my somewhat complicated procedure for putting contacts into a specific contact group and then sycning with Google contacts.  Having this capability integrated into the app is definitely better.

Unfortunately the ability to see contacts not already in a group is not working for me.  It crashes every time I attempt to refresh the contact list.

I'm not sure if this is due to my having a large number of contacts or for some other reason.  I've posted on the Sync in a Blink support forum, so hopefully someone from the company will reply soon.  I will be very glad to be able to automatically filter and determine which contacts are not in contact groups.  With over 320 contacts, it's a huge pain to keep track of that manually.