With Opera Software’s announcement that the company is this week demonstrating an iPhone-app version of its eponymous Web browser, we’ve seen quite a bit of commentary about the app being dead in the water, along with some legitimate speculation as to whether or not Apple will approve a third-party Web browser. (The company hasn’t yet submitted Opera Mini to Apple for approval, although our colleagues at Macworld UK got a look at it earlier today.)
There were rumors back in late 2008 that an Opera iPhone app had been rejected; however, Opera never actually submitted a browser to the App Store. So the upcoming submission of Opera Mini for the iPhone appears to be significant in two respects. First, there’s sure to be demand for the app, as the company claims it’s dramatically faster than Safari, requires much less bandwidth to display the same Web pages (see below), and offers a number of unique features, including a “speed dial” screen that displays thumbnails of favorite sites for easy access. Second, Opera Mini may be the first Web browser submitted to Apple for approval that doesn’t use the iPhone’s WebKit as its base.
But the situation is a bit more complex. Taking into account developer guidelines, past approvals and rejections, and the actual functionality of Opera Mini for iPhone, here’s a look at the biggest reasons for App Store rejection speculation.
Reasons for rejection?
The two most-common reasons we’ve seen given for possible rejection of Opera’s app are that the app duplicates existing functionality, and that a Web browser needs to download and execute code within the app.
“Duplicates existing functionality” Apple has in the past rejected a number of apps that, in the company’s view, duplicated functionality already provided by the iPhone’s built-in applications. A third-party Web browser would thus appear to be destined for rejection, given not only the existence of Mobile Safari but also Apple’s focus on Safari as one of the iPhone’s flagship apps.
However, the company has loosened up a bit on this front. Back in January of 2009, Apple began allowing third-party Web browsers in the App Store. In fact, a search for “Web browser” in the App Store today produces 141 results, with perhaps a quarter of them being actual Web browsers of some sort. So the idea that Apple will reject Opera Mini simply because it “duplicates” Mobile Safari isn’t very convincing.
“No downloading and execution of code” The bigger issue would appear to be the code underlying the Web browser. The third-party browsers currently in the App Store all appear to use the iPhone’s built-in WebKit engine—the same one on which Safari itself is based. In other words, even feature-rich browsers such as iCab use the iPhone’s own browser code; they just provide different interfaces and feature sets than Safari.
This is significant because a modern browser doesn’t just render HTML code and present a static, readable Web page; it must also be able to run code. For example, many sites use JavaScript, so a browser needs a JavaScript engine that processes this code. But Apple’s developer guidelines for the iPhone prohibit an app from downloading and executing code within the application. So, in this example, a third-party Web browser can’t provide its own JavaScript engine. (WebKit-based browsers get around this restriction because, in the JavaScript example, JavaScript code is handled by WebKit, rather than by the third-party app itself.)
The obvious concern is thus that Apple won’t approve a browser that isn’t based on WebKit. However, it appears this limitation won’t apply to Opera Mini because of the way the app works. We spoke with Christen Krogh, Chief Development Officer at Opera Software, and he explained that Opera Mini isn’t what you’d consider a traditional Web browser, but rather is a client for the company’s Opera server software.
How this client-server system works is that when you request a Web page in Opera Mini, the app sends the URL to an Opera server, rather than to the destination Web server. The Opera server actually sends the request to the Web server, and then downloads the page’s content, processes any scripts or other dynamic content, and compresses the resulting page into Opera Binary Markup Language (OBML). The Opera server then sends the resulting “page”—which is up to 90 percent smaller than the original Web page—to the client on your phone.
(It’s this client-server approach, along with caching of frequently accessed Web pages, that provides Opera Mini with its speed advantages over Safari. The company claims browsing using Opera Mini is up to six times faster than with Safari because so little data needs to be transferred to the client—an approach that’s also useful to people with limited data plans.)
In other words, the Opera Mini app is essentially a thin client, rather than a full-blown Web browser, and doesn’t download and execute any code itself. This approach would seem to keep the app from being rejected for in-app download and execution of code.
Limitations
The downside to Opera Mini’s client-server approach is that it places some significant limits on the types of content the app can handle. For a Web page that includes lots of JavaScript, Ajax, or other dynamic content, Krogh told Macworld that the Opera server lays the page out on a virtual screen, executes as many actions on the page as it can, and then sends a mostly static page to the client. If the page requires user interaction, there are triggers on the OBML version that can send data back to the Opera server and result in a new version of the page being sent to the client. This allows you, for example, to fill out JavaScript forms in Opera Mini.
Krogh said that in the company’s testing, this technology works for the majority of the Web’s most popular sites. However, it won’t be able to accommodate every type of content. Sites that have real-time animation—Krogh used the example of a live-updated clock—won’t render as expected, and Opera Mini won’t be able to execute background scripts.
(Opera Mini will be able to handle most types of iPhone-supported media; as with Mobile Safari, Opera will hand off those kinds of media to the iPhone’s native media player—the one that appears when, for example, you tap a link to .mp4 video in Safari.)
Opera Mini would also be subject to the same limitations as other third-party browsers for iPhone. For example, unlike with Mac OS X, there’s no way on the iPhone to change your default browser—the one used when you tap a link or button from within another app. So tapping a link in a Mail message will still open that URL in Safari, rather than your preferred browser. Similarly, while you can sync your browser bookmarks between Safari for Mac or Windows and Mobile Safari, you won’t be able to do so with Opera Mini or any other third-party iPhone-app browser. And, of course, no iPhone browser can support Flash content.
Prospects good?
The company’s official position, noted in a blog post, is that Opera hopes “that Apple will not deny their users a choice in Web browsing experience.” But clearly Opera Software chose to bring Opera Mini, the mobile-phone browser, to the iPhone, rather than the more-full-featured Opera Mobile, which is based on Opera’s own browser engine, because of concerns over Apple’s app guidelines and app-approval process. And while we’re not privy to the inner machinations of that process, from where we sit, it looks like Opera Mini has a good shot at approval.
If the app isn’t approved, you can be sure the tech press will latch onto that story as yet another example of problems with the App Store approval process. Indeed, given Opera’s visibility, it seems the company’s decision to publicly demonstrate Opera Mini for iPhone—and announce that demonstration before the app’s submission—was a savvy PR move that refocuses attention on the App Store approval process and puts a bit of extra pressure on Apple to approve the app.