According to Dominik Balogh, the developer of a push-enabled “to do” list application for iPhone called NotifyMe, the Push Notification technology provided by Apple does not appear to be working on any “unlocked” iPhones. Unlocked phones are those that have been modified to work on unsupported carriers. For example, in the U.S., this would mean phones that were hacked to work on T-Mobile’s network instead of on AT&T. This is different than “jailbroken” phones, which are phones modified to allow the installation of unapproved third-party applications.
At first, you might dismiss this problem since it only affects a small subset of users, but Balogh brings up an important question: “what should the developers do?” People who have purchased his application are now angry that it doesn’t work, yet there’s nothing he can do to help them.
The Problem with Push
A few weeks ago, Apple released their updated mobile OS, the iPhone OS 3.0, which included support for Push notifications among many other things. The two available NotifyMe applications were configured to use the new technology in both the free and paid versions. With these applications, users can receive push messages that remind them of items on their to-do list that need their attention.
Almost immediately after the company released the apps to the iTunes App Store, the support requests began rolling in. Balogh quickly realized there was a problem. Around 80% of the requests were from users who had installed NotifyMe on an unlocked phone. The users were complaining that the app either didn’t work reliably or didn’t work at all. Unfortunately, there was nothing Balogh or his co-developer Pavel Serbajlo could do to fix the situation.
Says Balogh, the problem involves the Push Notification service:
“…Every Push application has to request the unique token from the Apple’s APNS servers to identify the device it’s running on. Thanks to that token, APNS servers always know which device is yours. The token can be understood as an IP address — the server has to know where to send the notification and for which application. APNS can also change your token regularly for higher reliability, so it’s critical that the application requests the token again on every start (or when enabling the Push feature) to replace the old one if new token is forced by APNS.
On any unlocked iPhone, the application requesting the token is stuck. APNS does not provide any response at all and the application can either cancel the request completely by automatic timeout or let user wait with the progress bar forever. Either way, the user will never receive any Push message, because APNS has not provided the token.”
In other words, if you’re running an unlocked phone, you can forget about Push.
What Should Developers Do?
It may be easy for iPhone owners who haven’t hacked their device to scoff at this issue: “Well, that’s what you get for monkeying around with the firmware!” But the matter is not that simple.
Developers will have to determine how they’re going to proceed now that they’re aware of this limitation. Should they try to support the hacked phones? Should they just place a warning message in their app’s description in the iTunes App Store? Should they ignore the problem (like Apple is doing)? Should they refund the money for the purchases?
Even worse, many of the unsatisfied customers are leaving poor, 1-star reviews when rating the application since they’re unhappy it wasn’t working for them. That seems incredibly unfair to the developer who has created a perfectly good application that works within the confines put forth by Apple. Yet now, new potential customers – including those content with their unmodified phones – will see these negative reviews and likely choose not to purchase, potentially overlooking great applications that would have worked just fine for them.
Apple’s Involvement: Zip, Zero, Nada
Apple has every right to ignore this situation, we suppose, and that’s exactly what they’re doing. After all, the issue affects only a small community of hackers who have modified their phones. Or does it?
Does Apple have any responsibility to communicate this limitation to the developer community so they’re not caught off-guard as Balogh was? After all, it’s the developers who have to deal with the fallout – the overwhelming support requests, the unhappy customers, the bad reviews, etc.
At the very least, Apple could configure their APNS (push) servers to return an error message of some sort to let the developers know what caused the connection to fail, suggests Balogh. That way, the developers could at least plan to put a warning message in their app’s description to cover themselves against these sorts of complaints.
Does that seem like a fair request? What do you think either Apple or the developer community should do regarding this issue?
