Archive for the ‘push notifications’ tag
The first Chirpy feature update was released on the iPhone App Store today. Aside from a nasty crash-inducing bug, the initial launch went smoothly. We were pleased to receive a great deal of positive feedback. As is the case with all 1.0′s, however, there was definitely room for some improvement. We think this update addresses the most pressing deficiencies in 1.0. Here are the changes:
- Added a ‘find username’ button to the new message view (shows a batch of 100 friends)
- Added an automatic refresh when a push notification is received while the app is running
- Updated address book entries to include both the Chirpy url and the twitter.com user page
- Fixed bugs related to sending a message to a new recipient
- Fixed bug where ‘Add to Contacts’ button was enabled after adding a contact and restarting the app
- Fixed errant ‘dismiss’ button title that resulted after sending a new message
- Fixed some obvious landscape orientation bugs
We think it’s a nice little update, but you can expect that we won’t stop here. Enjoy!
Last week we launched a major upgrade to our push notification server. We had added some tweaks and minor enhancements to our server previously, but otherwise, the code was pretty similar to our original proof-of-concept. And that implementation held up pretty well for us — until recently. Our aim was to consistently poll Twitter for updates every 3 minutes which meant push notifications were delayed roughly a minute and a half on average. When everything was running smoothly, we were able to do just that, but we struggled with consistency.
Those days are behind us. With some thoughtful improvements, our early tests indicate that our push server is now more than 13 times more efficient than the previous version. And, there are still more optimizations we can make. Additionally, while our push server hardware is respectable, there’s a lot of room to upgrade.
The performance improvements aren’t the whole story, however. Twitter is doing its part to make timely notifications possible. As much as computing resources are a consideration for determining a polling frequency, so is Twitter’s quota on updates for 3rd party applications. When we started development on Twitbit that quota was 100 updates per hour. If we query your account for both DMs and mentions, that’s 100 updates per hour / 2 updates per query / 60 min. per hour = 1 query every minute and 12 seconds. And of course we didn’t want to consume your entire quota just to support notifications. Today, Twitter allows 350 updates per hour and they’ve announced that the limit will eventually be 1500! That means Twitter quotas are becoming less relevant and we can start to query for updates as often as our computing resources will allow.
Reliability: Our server has been cruising without so much as a hiccup since the upgrade.
Promptness: Messages are currently being delivered in less than a minute and are taking mere seconds on average.
We don’t want to make any promises yet, but suffice it to say that we’re still in the process of pushing the delay time down — not letting it creep back up. Look for even more improvements in the coming days. Don’t take our word for it either, test it out and let us know what kind of delays you’re seeing. Send your results to @twitbitapp. We appreciate your patience while we worked through this growing pain. Thanks!
Last week Ars Technica posted an interesting article about whether or not it’s feasible for small iPhone developers to support the “push notification” service Apple plans to include in version 3.0 of the iPhone OS.
I can speak to this not only because we’re a small company (tiny, really) building iPhone applications, but because at least one, maybe two, and probably more of our applications could be improved by adding “background notifications,” regardless of whether the implementation takes the form of processing done on our server and a small notification pushed to the phone, as Apple proposes, or processing done in the background on the client.
First, let me say that I can understand the reasons why Apple is hesitant to open up the phone to background processing. My own iPhone currently has about 5 or 6 “pages” of applications. The vast majority are ones I’ve downloaded, run once or twice, and have never run again, a pattern which seems to be representative. Furthermore, the quality of those apps varies dramatically.
Many of these apps would run in the background if they could. Would I want them to? I’m not sure. While it would be possible for developers to write background processes that are well-behaved, and therefore don’t needlessly suck up CPU cycles and battery life, I’m not convinced that would be the common case.
The cost to the user of a misbehaving background app is pretty high. Worse, troubleshooting the problem isn’t exactly straightforward. All the user knows is that his phone seems sluggish, or that his battery life doesn’t seem to be what it was. Is it the phone or an app? If it’s an app, which one out of the 30 or 40 that have been installed is the problem?
I can definitely understand why Apple wants to sidestep this whole issue.
All that said, I think the utility of Build Watch would be increased dramatically if notifications of failed builds could be pushed to users in the background. Let’s consider what would be required for Build Watch to leverage push notifications.
First, we’d have to replicate most of the business logic that’s implemented in the app within a web application. This would include storing the list of servers for each user, the show/hide status of each project (since we don’t want to be sending notifications for projects they don’t care about), and the most recent build status for each project, so we know when that status changes. This would all have to be new code, since we’re not going to be running Objective-C on our web servers. The iPhone and web applications would then have to be maintained in parallel as new features are added and bugs are fixed. (Maybe this duplication means that the architecture of iPhone apps leveraging background notifications will fundamentally shift over time. All important state and business logic will live on the server, and the native iPhone client will reduce to just a pretty front-end.)
Some functionality won’t work at all. For example, it’s currently possible to hide and unhide projects even when the phone doesn’t have an Internet connection. This is just configuration stored locally, so the current implementation is simple. Getting this working in conjunction with push notifications requires us either to forbid the behavior altogether, which is a clumsy compromise, or devise some mechanism for syncing the user’s offline changes with the server’s state. The latter can only be performed the next time the user opens the app while connected to the Internet. In the meantime, perhaps confusingly, they’ll continue to receive updates for projects they don’t care about and/or miss updates for projects they do care about.
More critically, consider people whose build servers are protected behind corporate firewalls. I suspect the majority of our users fall into this category. A web service pushing notifications doesn’t work at all for these users. One might argue that they’re not any worse off than they are now, but push notifications as a general purpose solution has no answer for this problem. Background processes, on the other hand, would work quite nicely.
Next we have to consider cost. Build Watch currently costs $2.99, and that’s a price point we like and will likely follow for future apps that are similar in scope. That’s about the price of a small latte. If we want to support background notifications, we can no longer just code up the app, release, and move on. We now have server processes we have to continue to develop, pay for, and maintain, with no obvious path for earning continuing revenue from the user.
All this must be overcome just so our little app can download a few kilobytes of RSS data and alert the user if necessary. Seems a little disproportionate, doesn’t it?
This becomes an even bigger problem for small shops like us as background notifications become a user expectation. Will users even bother checking out our apps if we don’t support this behavior?
I’m not terribly concerned with the scaling issue pointed out in the Ars article. Granted, we’re not building Twitter clients, but even if we were I’d consider scaling problems to be a good one to have. Several hundred thousand paying customers sounds just fine to me. I’m much more concerned about its limited usefulness for a large class of applications that could benefit tremendously from background processing.