Recent announcements from publishers detailing plans for optimization of their web-based content for the iPad are a clear indication of Apple's clout. Publishers who distribute content in digital formats have been conditioned to anticipate the launch of new Apple devices with deferential trepidation. This time it's the print industry's turn and, as a whole, the industry seems determined to keep pace with the perceived shift in consumer behavior the device is expected to bring.
At the same time, agencies and their clients are increasingly creating unique content as a way of keeping websites fresh and staying relevant to communities that have formed around their brands. The push toward content creation has aligned the concerns of dedicated publishers with content producing brands. Both want to be sure that their content will be accessible on new platforms as they are made available.
We know that The Financial Times, The WSJ, Wired and doubtless many more publishers are looking for ways to deliver high-fidelity experiences on the iPad or at least to make sure what they've already got is accessible from it.
In practical terms this means two things. Developing a Flash-free version of their website optimized for the iPad and finding an alternative to Flash for everything from audio and video playback to animations and display ad units. OR, development of a native application.
For most brands, and likely for publishers too, it makes more sense to adopt a combination CMS and site architecture that will make it easy for developers to ensure that content looks and feels good in a Webkit-based browser, more specifically, in the iPad's implementation of Safari. Equally important is to ensure that video and other multimedia assets are accessible in-browser. This is most easily accomplished through dedicated streaming services that dynamically adjust their embedded media player units based on detected browser type.
Taken together, these two steps amount to an approach to content delivery that will reach the broadest possible audience at the lowest possible development costs. Put another way it makes more sense to build websites optimized for the iPad, iPhone, Android, Android Tablets, Windows 7 and so on than it does to build native apps for each platform.
The alternative dependence on native apps more often than not means subjecting one's brand to arbitrary approval processes or lackluster distribution. Ultimately, there's no better way to combat fragmentation while hedging against dominance of a single platform.
That said, it is important to understand what can be done with a native app that can't be done in a browser. Brands that can afford to both optimize for tablet browsers and develop native apps should experiment with native apps, but do so in a way that takes advantage of the unique features of that device. If you want to do something that requires access to a device's camera or microphone or other low level APIs, then you should build a native app. In fact, if you're building a native app it makes sense to go out of your way to make use of some of these APIs.
For agencies, this new dynamic means that development of high quality in-browser websites and web apps that support multi-touch and gestures may become an important point of differentiation. Now is a good time to make some time for your devs, designers and UX buffs to play around with these devices, their SDKs and HTML5.