Last week Forrester released a report that recommends this approach as the most productive approach for magazine and news publishers. You can buy the whole report for $499 here.

Forrester defined four possible content platforms:

• Native
• Hybrid apps (native code with HTML and JavaScript)
• Mobile middleware platforms
• A web approach (HTML5 and JavaScript)

Of course, I’m going to end up arguing for plain web—and save Apple’s 30 percent cut—but if you want to distribute via the app stores, then go for hybrid—specifically, Treesaver in a native slipper. Let’s look at the alternatives.

Native: For now this means building on four separate platforms: iOS, Android (including Amazon’s version in the Fire), WP7 and RIM. Plus, you are probably doing a web site in any case. Then, you have to figure out how to feed any or all of the apps with content. A static monthly might be happy with an XML export from the print edition, at least until readers start asking for live updates, video, and comments. So that means a dedicated CMS, and staff. (How many CMSs do you have so far?)

Hybrid apps: You can save some of this pain, and a lot of the operating cost, by making an HTML site that fits into native shells. PhoneGap, acquired last year by Adobe, provides shells for all of the platforms.

Mobile middleware: A solution more for developers than publishers. If, like The New York Times, you have a staff of 120 programmers working on your site and apps, then by all means let them figure this out, unless of course you wanted to have a common workflow and code bad for all of your products, and a cost structure that will cheer the shareholders.

Web apps: If I were king, than we would forget about native apps for publications, and go with the web approach. We could develop entirely with HTML, CSS and Javascript. It would help if browser makers and the W3C would enhance the presentation. They’ve figured out web fonts, and Safari finally added full-screen view. How about allowing full-screen trigger via Javascript. On mobile platforms, the browsers need better swiping and other touch animations. And it would be nice if users could make desktop bookmarks more easily than they can in, say, iOS Safari.

We already make adaptive or responsive sites that work beautifully on phones, tablets and PCs, from the same HTML. I point, proudly, to Treesaver’s web edition of The Sporting News iPad app, powered by the same HTML feed. And there are more conventional layouts, like the BostonGlobe.com.

Of course, HTML can’t yet match the typographical niceties you get can achieve in print, which is the only excuse to go with a PDF solution, like Zinio, other than laziness. But we how have the fonts, and Mozilla has offered type refinements that might become W3C standards eventually. (And I don’t think it’s going to take as long as it did to get a standard for web fonts.)

But the real rub is distribution. To get into Apple’s App Store, Google’s Android Market and Amazon’s Appstore, you gotta have an app. Forrester recommends, “Start with a web approach; move to a hybrid approach as needed.” This makes the sense, for now.

Dan Rowinski, the prolific Read Write Web blogger (@Dan_Rowinski), summarized the Forrester report. “It is more likely that development studios will find talented coders that are well-versed in Web technology” he writes, than coders who know “the variety of languages it takes to create an app for the four major platforms.” And few individuals are good in all of them—Objective C, C++. Java, plus other code for the visual layers.

It’s not just the development cost that argues against all-native apps. It’s the constant support for the frequent OS revs. Raise your hand if you had to do some sudden fixes when Apple moved, with little warning, to iOS 5. (The only people who didn’t raise their hand were those who didn’t have any iPad or iPhone apps.)

Nevertheless, you need the shell or the wrapper around your HMTL, and increasingly it makes sense to go for a third party developer who can keep up with the revs and help you revise the HTML and CSS when needed. The big guys aside, which magazine or news publisher wants to keep a lot of native developers on the payroll, waiting to smooth over bugs that weren’t bugs before the latest update?

No, in a perfect world, we do not want the native apps. But the world is imperfect. People have come to believe, “there’s an app for that.” We have little choice but to give ’em apps. The first iOS apps were not for the content crowd; they were games and things that used OS power and features like geolocation like Google Maps—real applications, that had nothing to do with reading stories in text form. Since the user interface was fit to the small screen (with big buttons and swipe), users liked apps. Apple introduced the App Store in 2008, which—at least in the beginning, before there were half a million apps—made it easy to find and buy one. The first bestselling content apps were Net News Reader and . . . The New York Times. (Business Insider has a fun list.)

It’s the combination of the small-screen UI and the App Store that led publishers to build apps instead of mobile web sites. Remember when iPhone arrived five long years ago, the mobile web was still pretty primitive. The browsers were poor, and there were many dumbed-down WAP sites since there was no way to adapt a standard site to a small screen with CSS.

There are still only three ways to buy digital publications: App Store, Android Market and Amazon. By the time Google made the Chrome WebStore, it was too late. I remember putting free samples of Nomad editions in there in late 2010, but few picked them up. Users were going to the Android Market. Although it’s like an open Turkish market compared to Apple’s indoor mall, but hey, it’s Android, it’s just about about even with Apple now, according to Dan Rowinski.

To make the web approach enticing enough to move publishers out of the native apps, we gotta do three things:

• Continue to work on adaptive design until we do anything any app can do, but on all screen sizes.
• Build a web pub marketplace. (I mean, surely we can do better than Apple’s Newsstand, which is about as user-friendly as a magazine rack at a gas station convenience store on I-s95.)
• Get the browser makers and W3C to sweeten the user experience, and otherwise do for HTML anything the native platforms can do.

---

Recommended strategy for publishers: “Hybrid Plus”

For now, we have to make hybrid apps—as well as web apps. (Check out The Sporting News in the App Store, running from the same HTML as the web edition.) One advantage of doing Hybrid Plus is that shared links can actually be followed to the web site, without having to download the app.

We’re building our own native shells at Treesaver and Ready-Media, and experimenting with PhoneGap. (Wouldn’t it be funny if it was Adobe who enabled this interim hybrid era?)

Not all publishers still believe that the native approach is the way to Valhalla. The most famous drop-out is the Financial Times which quit the Apple App Store (although they still have iOS devs on the payroll to support their legacy subscribers). Instead, FT promoted a web app—but only for iPhone and iPad. (If you are reading this on one, check out http://app.ft.com.

But it’s not complicated. The FT web app doesn’t work on Android. (You get a non-supported notice on the Samsung Galaxy Tab, and are redirected to a mobile site on an Android phone.) Late last year they announced a nicer UI in a free Android app distributed through the Market—but not through Amazon. It works fine on Android phones and tablets.

What happened? Did they lose their nerve, or was it just about Apple’s bite? Subscriptions are offered in the app—and fulfilled by Financial Times, not Google. Something tells me that with a publication called Financial Times, it may just be the money.

In a saner move, two of Treesaver’s newest clients are going to launch on the web, and wait to see if they need hybrid apps. For startups, let’s build the solution that we ultimately want.

Sites and apps are like chutes and ladders. If you build an adaptive site that can fit into a native shell, then updating content is a downhill slide. With all-native, it’s like climbing stairs, forever.