The Waffler

Pricing Byline 4 or: How to Do Paid Updates in the App Store Without Shafting Your Customers

The App Store has improved in many ways in the two-and-a-half years since Byline was first released. Back then there were only five-hundred apps, and though the road to the hundreds of thousands of apps you see today has been bumpy at times, Apple has done a good job of improving the nuts and bolts of the store for developers by shortening review times, clarifying approval criteria, and extending the control we have over how and when our apps appear in the store.

But some shortcomings of the App Store have become entrenched. The lack of support for paid updates is a particularly insidious example, and combined with the rise of the iPad it has the potential to cause real harm to the relationship between developers and our users.

The problem

Bringing an iPhone app to the iPad presents developers with a dilemma: either make the app universal and forget about charging existing users for that big new feature, or release a separate iPad version and sell it at a single price for new and old users alike.

The first option — one universal app — is very generous, and over the short term it makes nearly everyone happy. Apple is happy, because the App Store remains neat and easy to use. The users are happy, because their purchase turns out to be even better value for money than they thought it was, especially if there have been other juicy free updates in the interim. The developer, however, is probably somewhat unhappy, because giving away the fruits of hard work to a large group of people who are willing to pay for it is no way to run a business, and people who run unsuccessful businesses don’t tend to be happy. Over the long-term, apps are abandoned because continuing to improve them isn’t economically viable, and everyone loses out.

The second option — separate iPhone and iPad apps — is more-or-less fair, but pleases nobody for any length of time at all. Apple doesn’t like it, because it forces users to micromanage their purchases based on which devices they have. The users don’t like it, because even if they didn’t expect iPad support when they bought the app, they’d like to get some recognition for their loyalty. The developer doesn’t like it either, because they wish they didn’t have to risk offending their users with such a blunt tool of an upgrade mechanism.

Most developers seem to have opted for the second option, as the lesser of two evils, but I say: meh.

My solution

Byline is currently available in two versions: one paid, the other free with the same features plus advertising. Here’s the magic:

• The free version of Byline will become universal (for iPhone, iPod touch and iPad). It’ll show ads out of the box, but you can upgrade in-app to remove the ads. Once purchased, you can restore the upgrade on all your devices — no need to pay more than once. The kicker: existing users get to purchase the upgrade half price.

• The paid version of Byline will remain in the store for iPhone and iPod touch only. Aside from the lack of iPad support, it’ll be updated with all the same new features and improvements as the universal version, so for this release at least there’ll be no difference at all between the two versions an iPhone or iPod touch.

How does it work?

The discount is shown and applied automatically. It’s that simple. The only exception is if the paid version of Byline has never been used on the device with which you’re making the purchase. If you’ve bought Byline but aren’t offered the discount, just reinstall the app from iTunes or download a fresh copy and open it once on the device before upgrading.

This technique isn’t perfect: developers still have to juggle two versions of the app, though new users only need to download one. Nonetheless, in the absence of built-in support for paid updates, this is the best we can do. If someone else is already doing this kind of thing, I’ve yet to hear of it; and if not, why not? It’s easy, elegant, and above all totally legitimate. Interested developers need only take a close look at the Keychain documentation to see how it’s done.

So Byline is finally, actually coming to the iPad?

Yes, it is! Sorry for the long wait. Look out for it 1st March. (Pending approval, of course.)

Byline 3 — Not Your Grandpa’s Google Reader iPhone App

I’m pleased to announce the release of Byline 3, the long-awaited successor to the first and best Google Reader app on the App Store. (Well, I think it’s the best, but then I would, wouldn’t I?) Byline has been pulled apart and reworked from the inside out, and the result is a lean little monster of an app that’s more functional and elegant than ever before. I’m very excited about this update, and I think you will be too when you get your paws on it.

Streamlined

I wanted to add features to Byline without adding bloat — in fact, I wanted Byline 3 to be even more sleek and spare than its predecessors. Sounds like an impossible goal, doesn’t it? Yet this kind of magic is what the iPhone’s all about. Who needs abstract on-screen buttons when you can just reach out and grab what’s in front of you. Intuitive scrolling gestures have been part of the iPhone since the beginning, yet RSS apps tend to make you to stab at fiddly little buttons to get from one article to the next. Apple‘s own Mail app suffers from a bad case of the buttons too, but it’s RSS apps that really feel the pinch (as it were), since you’re likely to have a far greater volume of feed articles to sift through than email messages.

No more. Byline 3 lets you swipe from page to page with a natural sideways motion that feels just like moving between images in the Photos app. It’s amazing how fast and frictionless reading your feeds becomes when you no longer have to concentrate on controls — the interface seems to just disappear. Using Byline now feels completely natural whether you like hold your iPhone in both hands, your right hand, your left hand, your teeth … maybe not your teeth, but you get the idea. Once you’ve tried it you’ll never look back.

Smart

One of Byline’s most useful features is offline browsing, which allows you to read full web pages linked to by your feeds — with images and CSS — when you’re on the subway, in the sticks, or just stuck with a slow connection. The trouble is that caching web pages was an all-or-nothing affair in earlier versions of Byline, so you’d either have to wait a long time for Byline to cache your feeds or risk not having your links available when you really need them.

Byline 3 caches web pages up to twice as fast as before, but that’s just the beginning: caching is smart now. Byline 3 continuously analyses your feeds and automatically decides which ones really need to be cached, usually because the RSS feed contains only short snippets of text. Instead of wasting time caching web pages when the full text of the article is in the feed anyway, Byline just caches the web pages you’re likely to want, making your offline browsing experience far more complete than before even if you don’t have much time to let Byline cache when you’re online. This all happens automatically, but if you want to fine-tune the process you can manually enable or disable web page caching for individual feeds.

Social

Byline is now tightly integrated with Twitter, Instapaper, and Read It Later. I’m especially pleased with the Twitter implementation, which automatically handles URL shortening if the Tweet becomes too long to post otherwise. You can even compose Tweets offline — if necessary Byline will automatically shorten the link before posting the tweet when you’re next online. Instapaper and Read It Later are handled in a similarly robust and offline-friendly way.

Emailing an article has been improved by embedding the full item content in the message, and sending it without leaving Byline. If you use Evernote you’ll love this, because it lets you save items by sending them to your Evernote email address.

Sexy

Byline 3 doesn’t try to reinvent the wheel — it just gives it a good polish. All the graphics in the app have been tweaked till they shine by the ridiculously talented Emanuel Sá of Iconlicious. The result is a cleaner interface and a more beautiful app.

What’s next?

Big as this update has been, I don’t intend to rest on my laurels. I’m working on more goodies, including a native iPad version of Byline. Watch this space.

A Bit About the Basics

Before I go into more detail about the big new features and interface improvements in Byline 3.0, I’d like to talk a little about the fundamentals.

The first thing you’ll notice upon opening Byline 3.0 is that syncing is faster than ever. Byline now loads your items all in one go, rather than loading each folder separately. This offers several advantages besides faster syncing, not least the elimination of performance problems experienced by users who have a large number of folders. The only downside to this new approach is that high-volume feeds have the potential to swamp not only the folder they’re in but the whole app — if this is a problem for you, there’s a new setting to restrict syncing to feeds which appear in a particular folder. You’ll still see other folders, provided the feeds inside are also in the designated “main” folder.

Caching is still a necessarily slow process, but Byline is now much smarter about what it chooses to cache. By default, Byline will automatically cache web pages if it thinks the feed content for that item is incomplete, a determination it makes through statistical analysis of the length and content of each feed’s posts. This efficient little heuristic makes it more likely that the full article will be available at those frustrating moments when you want to read more but you’re offline and the feed only gives you the first few sentences of each article. You’ll also be able to manually enable or disable full web page syncing on a feed-by-feed basis.

Byline now saves data to permanent storage after every sync, and has a clever new way of keeping track of page caches. This means that if Byline crashes or isn’t given enough time to write data while quitting, the worst that can happen is that you’ll lose the most recent changes to the read, starred, or shared properties of items. You’ll never lose items loaded and cached in the last sync.

I’m excited about these changes, and I’m sure many of you who use Byline on a regular basis will be too. I’m working hard to get these improvements in your hands as soon as possible.

On The Horizon

Byline 3.0 has been in development for a long time, much longer than I expected due to various distractions and a failure to be realistic about the time I would need to make such sweeping changes to the app. I’ve been reluctant to release information about the project until its final form begins to take shape, which has led to some speculation that development has stalled altogether. I regret creating such an impression, and would like to assure you that Byline 3.0 is alive and well, albeit late. The success of Byline thus far does not mean I no longer care about improving the app; on the contrary, the knowledge that so many people are waiting for Byline 3.0 has only made me feel worse about taking so long over it — and will no doubt make the euphoria of finishing and releasing it even sweeter.

I haven’t reached the home stretch yet, but I feel it’s close enough to start sharing some details. Perhaps I just can’t wait to show off the cool things I’ve been working on. Either way, let’s start with the new “Folders” screen.

The redesign features icons by Emanuel Sá, who seems to get more talented every time I work with him. Besides being pretty, the new icons are a little smaller, which allows more rows to appear on screen. The unread totals are shown in grey bubbles on the right — just like Mail, and much clearer and more balanced than before.

The real star of the show, however, are the blue disclosure triangles to the far right of each folder. When tapped, these swivel open to reveal the feeds within, which can finally be browsed individually. I love everything about the way these work, from their iPhone-native appearance and smooth animation to the bare fact that they allow total control over the way you browse without adding another level to the app’s hierarchy.

Finally, you’ll note that Byline’s settings are now within the app. I’ve been considering this for a while, as I get the impression that many iPhone users simply don’t think to look in the main Settings app for third-party settings. In the end, my hand was forced by my desire to add some smart, dynamic new settings which can only be accomplished in-app. I’ll be talking about these in an upcoming post, so keep an eye out over the coming weeks, and in the meantime feel free to tweet feedback to @phfish.

Pushing It

I’ve been receiving an increasing number of requests for Byline to make use of the new Push Notification service in iPhone OS 3.0. Many people seem to assume — understandably, given Apple’s enthusiasm — that push notifications are just as effective as allowing apps to run in the background, and that using the service is relatively easy for developers given that Apple provides a large part of the infrastructure.

Both assumptions are more true for some apps than for others. Neither are very true for Byline, unfortunately.

The Benefit

Push notifications could be used to periodically update Byline’s unread count on the home screen.

… That’s all. No data can be loaded or processed beyond the notification itself, so Byline would still have to be launched with an internet connection available in order to sync, download and cache the new items. Note also that the updates would be periodic, not truly pushed as soon as new items appear in Google Reader.

The Cost

I would have to set up one or more servers with a high-bandwidth commercial internet connection. I would have to write custom software to receive and store the Google username and password of users who wish to receive push notifications. After that, I’d probably want to consult a lawyer. Then, I’d get the custom software to periodically poll each and every Google Reader account for the total number of unread items. Any changes would be pushed to Apple’s server. And so on, until Google blocks my IP address.

Value

Like most developers I love being challenged; difficulty alone is not enough to dissuade me from trying something. But a great effort should bring a great result, one which makes the app better for a large proportion of its users, and which justifies using time which could have been spent on other improvements.

For the vast majority of users, there’s no value in adding push notifications to Byline. Anyone who subscribes to more than a few feeds is likely to have new items appearing in their Google Reader account on a regular basis, so knowing the precise number of unread items awaiting them at all times just isn’t that important.

Conclusion

Apple’s Push Notification service is a good idea, but it does have limitations. It’s not very useful for apps which need to do more while they’re not active than simply attract the user’s attention, and it’s not very practical for developers who don’t control both the app and the web service on which it relies. Still, I’m not complaining — there’s no better solution until background processing becomes feasible, which I don’t see happening until the iPhone gets at least 512MB RAM and a dual-core processor.

How Not to Design an iPhone Icon

The new icon is a blunder, one which I find particularly embarrassing because it’s Byline’s third icon in under a year, and I really should have gotten this right by now. Why haven’t I?

Byline 1.0	The best icons consist of a simple, distinctive visual metaphor which hints at the app’s function. I spent a long time considering suitable metaphors for Byline, but there are no easy answers. The idea of an RSS reader is fairly abstract — a newspaper is the obvious choice, but newspapers tend to be neither simple nor distinctive when depicted at the tiny size required for an iPhone icon. In the end I settled on a modified version of the standard RSS icon, but it proved to be too generic, as dozens of other RSS apps with similar icons began to appear in the App Store.
Byline 2.0	This was beautifully drawn by Everaldo Coelho, but when shrunk to the appropriate size the newspaper is rather indistinct and jagged (as I had feared). There’s just a little too much going on in this icon for it to work in so few pixels. Many users didn’t realise that the object sitting on top of the newspaper was supposed to be a coffee cup, and some found the icon distracting when glancing at their iPhones due to its similarity with the red notification badge. In addition, this icon is not a very good match for the new interface in Byline 2.5.
Byline 2.5	I thought that a bold typographic design would make up for the lack of a visual metaphor, but I should have known better. This is more logo than icon, and logos — especially unfamiliar ones — have no place on the iPhone. The black background makes it appear to have an unusual shape when viewed on the iPhone’s home screen; it stands out, but at the expense of being wilfully inconsistent with other icons. I don’t think the design is actually ugly, it’s just entirely inappropriate as an icon. I have no idea how I let myself think it was a good idea.

Slowly Getting Faster

Byline went from 1.0 to 2.0 in little over three months, gaining along the way a totally redesigned interface, support for folders, a built-in web browser, and a host of other features. Byline 2.5, on the other hand, offers very few new features, yet when it is released in mid-April it will have been a whole six months since 2.0. Why?

Part of the answer is boring; other programming projects, moving house and general sloth all contributed to a much longer development time than I expected. But the other part of the answer is much more interesting — or at least slightly less boring, I hope.

What was wrong with Byline 1.0?

Byline 1.0 was the result of only three months of frenzied development. It had a number of shortcomings; one of the main ones was that it would only sync twenty-five items from each list at a time. When syncing each list it would initiate a download of data for the newest twenty-five items, wait for the download to finish, and then use the data to update the list. This was easy to code, as all the Atom parsing and updating of the data model and user interface could be done in a single step.

So what was wrong with Byline 1.0?

Nothing! This method of syncing worked well, because Byline only ever had to process twenty-five new items at a time. There wasn’t a problem until Byline 1.0.2, which offered an option to sync up to two hundred items at a time from each list. Suddenly, the processing time required to parse the data for a whole list in one big chunk was long enough to make the user interface freeze noticeably. The processor would sit idle until the data had downloaded in full, and then kick into overdrive, delaying the whole syncing process and leaving the interface unresponsive for several seconds.

Should I have done things differently from the beginning?

Not really. Less code is better code, and the best code is no code. Most of the time. In rare cases fast code is better than less code, but it’s usually impossible to work that out before you’ve written the concise version and tested it to death with performance tools.

What have I done to solve the problem?

I’ve implemented progressive syncing. In other words, as soon as Byline begins to receive data for the list it’s syncing, it starts parsing the data and updating the list. New items are added gradually starting from the top of the list, and a heuristic is applied to determine which items should be removed from the list as the sync proceeds, so that you don’t see a jumbled mess if you view the list while it’s syncing. Because the data is parsed a little at a time the user interface never becomes unresponsive, and you can start browsing new items straight away, as soon as they appear.

The only downside is that there is a performance penalty incurred by parsing the data in small chunks and updating the user interface gradually throughout the syncing process. This results in marginally slower syncing over a very fast Wi-Fi connection, when the data would typically load very quickly anyway and processor speed is the major bottleneck. Over a 3G or Edge connection syncing is now faster, as the processor gets put to work straight away rather than waiting around for significant periods of time while the data it needs is downloaded in full.

In any case, it all feels faster now that the user interface is responsive.

What else is new in Byline 2.5?

Most other improvements are also related to performance. Byline is now much more reliable when handling large numbers of folders, and should be less prone to forgetting data between runs, a problem which was caused by the length of time it took to write the data model to permanent storage.

One major new feature is a button to toggle a “sort by feed” mode — this should make quite a few people happy! Other than that, you’ll have to wait and see … but not for very much longer.