Thursday, June 25, 2009

Making calls within your iPhone app - iPhone OS 3.0 breaks existing paradigm

When Apple introduced the iPhone SDK last year, developers around the world stood up, took notice and cheered. In the year since the release more than 50,000 apps have been created and pushed up into the App Store; more than 1,000,000,000 copies of applications were downloaded within only 9 months.

As there is no multitasking or background tasks allowed on the iPhone (aside from a few of Apple's apps that are part of the iPhone OS such as SMS, iPod, etc.) there are only limited ways for one app to working cooperatively with another. One method is to open a URL, allowing an app to launch a web page in Safari or the native Google Maps app. Developers can also design their applications to handle other URL schemes besides http://. Apple built a set of standard URL schemes into the iPhone OS, including tel://, which allows an application to "open" a phone number. Opening a tel:// URL causes the iPhone to launch the native Phone app, which in turn places a phone call for you. The code looks something like this:

[[UIApplication application] openURL:[NSURL URLWithString:@"tel://8005551212"]];

People started making all sorts of apps, from simple rotary dialers (a personal favorite) to pictographic contact managers. Just enter the phone number you want to dial or touch an icon of a contact you wish to call and a method was fired off and your call was placed. It was great, simple and seamless.

There were other apps that took notice of this functionality and coupled it with other features of the phone, most notable "security" apps and monitors (Able Pear just completed a baby monitor app that's up for review). Then came along iPhone OS 3.0, a welcome upgrade with over 1000 new APIs including peer-to-peer connections (over Bonjour), access to users' iPod music libraries, a new Google Maps API, push notification support and, yes finally, a clipboard for cross-app copy and pasting.

However, many little things were not mentioned, one being a "bug" fix to how the system handles opening tel:// URLS and places phone calls. With iPhone OS 3.0 installed, when an app calls openURL: with a tel:// URL, a new alert box pops up asking for confirmation -- totally breaking current applications that make use of automatic calling as a core feature. Now a good number of applications (that have been downloaded thousands of times) are no longer working -- well they sort of work, but now hang, waiting for confirmation to place a call.

The adoption rate of the new iPhone OS 3.0 should be about 80% over the course of 3 months. Unfortunately, when users who currently have apps that make use of this functionality upgrade, their apps will stop working as they had been. Who will those customers be mad at? Apple, for a wonderful new iPhone OS or the developers who sold them an app that is no longer working? I think Steve Balmer said it best: developers, developers, developers.

Now I know that developers and customers alike are contacting Apple to ask for a resolution to this newly introduced issue. But since Apple has "fixed" this bug, it may be a difficult situation to change. One resolution, as offered up by a good friend, was that Apple could validate the application's use of making the call, much like location-aware applications ask you for permission to use your location. A confirmation dialogue pops up the first time your app tries to make a call, asking for your permission to allow the app to place phone calls. This sounds like a great solution for a huge problem.

I would love to hear your feedback on this; your thoughts on this matter and what you think Apple could do to help the developers and customers in an ecosystem that they themselves have devised. Comment below, Digg, Reddit, tweet and re-tweet this blog entry; make some noise - maybe we'll all be lucky and Apple will hear the clamor and help developers, users and themselves alike with a solution to this problem.

Developers, please submit the enhancement request via the Bug Reporter tool at

Julian Romero Nieto has a good description of the bug and cites the (updated) Apple documentation and shows the issue at hand. You can read his posting to Oper Radar here.


aronnelson said...

I am totally irritated at Apple for doing this. I had a complete app ready to go - all I did was test on 3.0 for the "final test". Now it's completely useless.

This isn't a "bug fix", this is a ridiculous change made by a programmer. He should be let go for doing something like this to existing developers.

"THINK" before you make a stupid change.

Kevin Bomberry said...

@formersjsu: Yes, we share your frustration, but I don't believe that it was just one programmer; or rather would hope that no one programmer would wield so much power over the code. (^_^) Remember, if you are a developer and this is a problem for your app to file an "enhancement" bug request (the link is above in case you don't have it). Hopefully if a bunch of us developers make enough noise, Apple will hear us. Good luck and happy coding.

Kevin Bomberry said...

@Mario Grgic: Yes, the allow/disallow functionality would be great and that's basically what we're pushing for. But as to your comment about a auto-dialing app that calls random numbers and then play a recorded message, well, that's not an option for the iPhone (but there are several apps that do just that for the Mac and PC).

Once you hand off control of the app to the phone to place the call you loose any control of anything else, ergo, you cannot play a prerecorded message via the AudioToolkit piped into the phone call - same as you cannot record phone conversations, etc... Had that been possible, I could see hundreds of "use your iPhone to make $300.00 a day" spam emails all over the place. Just the thought scares me.

Kevin Bomberry said...

Thank you Julian Romero for your bug filing and your complete accounting of the issue at hand. You can read Julian's bug report on Open Radar:

Pieter said...

This is likely done in response to a serious bug that has existed in previous versions of the OS where a malicious application or web page could place a phone call that the handset owner could not disconnect.

Personally, if this was in fact part of the reason for the change, I welcome it.

ilinker said...

please apple get out of the way of your developers, they mean well. and those that don't, well you have this entire approval process in place to deal with that. come on!

Unknown said...

As a user of a babyphone app, I was really annoyed and disappointed when I noticed this change of behavior. And there was no warning at all to users. I almost left my kid alone with the app that I used many times before. It's a good thing I made a test to be 200% sure everything worked as usual before leaving. At least apps that do not work anymore should have a warning or be disabled. Anyways, I would say this poor or minimal bug fixing at best. I agree with your suggestion. Can we ask a refund in the meantime ? (the cost should be borne by apple...)

Bobby T. said...

Also keep in mind that all apps go though apple testing before they are approved.

It would be very difficult to create an app that hijacked the phone without the users knowledge as apple's screening process is in place specifically to check for these types of things.

Unknown said...

The confirm dialog is gone in iPhone OS 3.1, but now the user is no longer returned to the app after dialing, but remains in the Contact dial screen.

Any workarounds?

Kevin Bomberry said...

@Jason: Thanks for bringing this information to our attention. This is good to know and I will look into this and respond accordingly when I found out more. Cheers!