Monday, December 14, 2009

SBFormatPhoneNumber is a LIE!


STOP!
To the one person that has read the previous post ... yes besides me! ... STOP USING SBFORMATTEDPHONENUMBER.  SBFormattedPhoneNumber is evil and wrong.  If you use SBFormattedPhoneNumber Apple has the right to refer you to the seventh level of Sandbox hell!  DO NOT USE SBFormattedPhoneNumber!
There.  I think that I got Google's attention with all that.
Earlier I was bemoaning the fact that using SBFormattedPhoneNumber was soooooooooo difficult.  Weeeeeeeeeeellllllllllll that's because we weren't supposed to be using it in the first place.  It belongs to that special category of API calls that are just far too useful for us to be trusted with.  SBFormattedPhoneNumber is the sort of thing that I imagine caused Jay Freeman to lead the charge for the Jail Broken movement.
Here's the story.  Officially Apple does not want your app to have access to things that are fundamental and personal on the iPhone.  There have been a lot of cases of misuse so you can't really blame them - there have even been some law suits.  So now that the platform is maturing Apple is tightening the seals around possible issue leaks.  The word has come down as of the latest SDK agreement that use of undocumented APIs will be grounds for rejection - no exceptions or questions.  People are starting to get rejected for using it.  Here's an example of actual text from a rejection letter:

"'For security reasons, iPhone OS restricts an application (including its preferences and data) to a unique location in the file system. This restriction is part of the security feature known as the application's "sandbox." The sandbox is a set of fine-grained controls limiting an application's access to files, preferences, network resources, hardware, and so on.'"

The device's phone number is not available within your application's container. You will need to revise your application to read only within your directory container and resubmit your binary to iTunes Connect in order for your application to be reconsidered for the App Store."

So, having access to the iPhone's default phone number is both in the "Fundamental and personal" camp and in the "undocumented API" camp.
It's fundamental and personal because it's information that can be exploited both accidentally and maliciously.  But it's the undocumented part that I wonder about. 
What was it doing there in the first place?  Why can't we find a way to use that info in a safe way for those times when it really does make the user's experience better?
A little guesswork
SBFormattedPhoneNumber seems to be part of the Scripting Bridge framework.  I know; you are immediately saying, "Wait!  Scripting!? iP*!?"  What can I say?  I'm wondering if at one time it was really useful to have that functionality on the iP* and it didn't get taken out because ... well, it's just too useful.
The Scripting Bridge framework was introduced in 10.5 which is also where iP* OS has its origins so they share a commonality there.  The framework enables Objective C in OS X to talk to common scripting languages in order to fire off Apple Events.  Sounds pretty useful no? No!
Or at least not on the iP*.  No scripting on the iP*!  Bad developer!  No donut!  Seriously it makes sense though.  We are a couple revs at least from really having the power to handle that kind of thing on the iP*.  But it does seem to suggest that Apple at least agrees that it would be pretty cool if we could ... maybe on some new device ... maybe one with a little more power ... maybe one with a little more space to hold that power ... maybe rhymes with shmiShmablet?
But for now ignore my last post.  Just don't use the phone number for anything.  Forget that API call is there.  Don't think about the user-friendly apps you could make with it.  And most of all don't think about the possibility that there will be scripting on the iTablet ... I mean smiShmablet.

2 comments: