views:

2739

answers:

5

There is a newly introduced issue with iPhone 3.0 SDK and how it deals with the NSURL method for automatically making phone calls. It used to be that you could call a method (NSURL), pass in a string with a URL prefix (tel://, sms, etc...) and the iPhone OS would dispatch the message to the device, such as iTunes, App Store, Phone, SMS, Mail, Safari, etc... The code goes something like this:

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

When the method was called the phone call would be placed automatically. With the iPhone OS 3.0 when the method is called the app pops up a dialogue box asking for confirm the phone call. This breaks several existing apps as well as one that we just pushed into the App Store for review.

Can anyone think of a fix to this issue? I'm currently at a loss for what to do and trying to decide what other ways to handle this new wrench in the works.

I blogged about this and suggested that people contact Apple and make them aware of this issue. I also recommend a fix that a friend and I were thinking about - and that is to use the same "authorization" that location aware apps have; an app knows it's location aware and asks the user if it's okay to use their location.

Again, if anyone has a fix for this issue (and that is within the realm of the iPhone SDK as to not be rejected by Apple) please let me know; I would be greatly appreciative.

Update: 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.

+2  A: 

I believe this is included as a security feature - imagine an app that called a 900 number at 3am every day for 10 minutes. If you compare it to the new 'In-App Purchase' API - it's much the same.

The location API comparison is a bad example - getting the users location is a privacy concern, not a financial one.

Chaos
Yes and no. I can see how you can site a security concern and that is a valid point, but with the "confirmation of service" when you start the app this would not be an issue as much. And I'm sure that if anyone put in an app like which you mentioned (the 1-900 app) that not only would apple pull the app but pull the developers' account.I have placed a bug request with Apple (as an Enhancement) as well as contact various other developers to do the same. I also pinged a few people on the iPhone Core team to get their reaction to this issue. All apps purchased like this, just broke. :(
Kevin Bomberry
+1  A: 

You can't fix this issue as this is what is intended - anything you do to "fix" the issue will result in an app that won't be approved.

The user experience is considered not to be good when an app can choose to dial a number without the user's consent. It would be possible for software to dial "premium" numbers that cost the user a lot of money without them realising.

This is standard across all mobile software platforms and OS - if it just changed in OS 3.0 then this shows that it must have been an issue that initially Apple thought they could get around. However I think that Mobile Operators will have put pressure on Apple to introduce this as often then end up having to refund the user - but will have already paid out the money to the "premium" number.

I am not sure if "premium" numbers exist in the US as much as they do in Europe and that maybe the reason this is hard to understand.

Grouchal
@Grouchal: Interesting, and much like the answer that Chaos presented, but again, not quite on the mark. So far as I know this has not been an issue, I scrubbed the media and could not find a case where an app was dialing (premium, as you say) numbers automatically, leaving the users with a huge phone bill.This is more a change in the way the handling of the method (for making telephone calls) is processed. I don't see carriers applying pressure to Apple on this issue, but rather an internal "fix". Talking with Apple they suggested filing a "enhancement" via Bug Reporter; link in blog post.
Kevin Bomberry
Good luck with the fight! Perhaps once you win with Apple tomorrow you can take on Nokia and the others on Monday.
Grouchal
(^_^) I just lol'd in my pants.
Kevin Bomberry
I just updated the entry and added Julian Romero Nieto's description of the bug and his citation the (updated) Apple documentation and shows the issue at hand. You can read his posting by following the link above.
Kevin Bomberry
A: 

The RFC for tel:// says to NOT allow autodialing of numbers via the tel: scheme.

So they have to chose between RFC compliance and breaking these few apps.

I hope the chose to ignore the RFC, at least to allow apps to keep dialing if they allow it.

A: 

I question whether this is intentional on Apple's part to push users to purchase a new iPhone if they want voice dialing - this problem breaks all of the 3rd party voice dialing apps, making them unsafe and basically useless.

Let's keep up the pressure on Apple to make this a user-configurable setting.

A: 

Perhaps you meant newly introduced feature instead of issue?

I don't think you will get Apple to remove the confirmation popup, especially if it is RFC compliance.

Lemmy quote Joel (http://www.joelonsoftware.com/items/2009/06/10c.html) regarding broken apps:

A good platform always has opportunities for applications that aren’t just gap-fillers. These are the kind of application that the vendor is unlikely ever to consider a core feature, usually because it’s vertical — it’s not something everyone is going to want. There is exactly zero chance that Apple is ever going to add a feature to the iPhone for dentists. Zero.

I would not want some application to make calls, send sms or even connect to internet (living in a country where unlimited mobile data plans are still far in the future) without my consent.

Certainly operator's headache when customers complain about unknown calls on bills.

stefanB