Opera Mini 8 for iOS | Hacker News Reader

Opera Mini 8 for iOS

itunes.apple.com

41 pointsjacobr27 comments

I can see the usecase for this. Especially abroad (expensive data) and in areas with poor data (Edge connection or even GPRS) this would be a life-saver.

Some GSM operators in Europe already do that, transparently in the backend, so you get heavily compressed images etc. on poor connections.

>in areas with poor data (Edge connection or even GPRS) this would be a life-saver.

I have had Opera Mini installed on my iPhone since it was released for exactly this reason—it performs noticeably better than Safari when at the very fringes of data service coverage. It's not really a situation I'm in terribly often, but it has saved the day a handful of times.

I've been a massive fan of Opera Mini for years now, and this is really impressive! I wonder how it's implemented? Years ago, on Windows Mobile (not Windows Phone) it struggled with Javascript. Is that still the case? Is it merely UIWebView + a proxy to do the compression?

I believe it does server side compression and JavaScript parsing, then sends it to the device in a compressed format. So technically it's not really even a web browser.

Kind of. Current version has 3 modes. Regular browser, Mini mode (which sends pre-rendered web pages back to the phone) and Turbo mode which compresses images and videos.

Using Turbo mode for now, best of both worlds - data savings and compatability with all websites.

Since Apple only allow browsers use built-in webkit engine in iOS. The turbo mode is use Opera's proxy to compress data, and render them by webkit. Therefore the user agent says they are AppleWebKit:

Mozilla/5.0 (iPhone; CPU iPhone OS 7_1_1 like Mac OS X) AppleWebKit/537.51.2 (KHTML, like Gecko) OPiOS/8.0.0.78865 Mobile/11D201 Safari/9537.53

But for "Opera Mini" mode, it will render the page at their server, then send to iOS device. so they can bypass the limit from Apple and save many bandwidth. Therefore the user agent is complete different:

Opera/9.80 (iPhone; Opera Mini/8.0.0/35.3088; U; zh) Presto/2.8.119 Version/11.10

> Presto/2.8.119

Wow. I'm surprised that Mini is still that far behind Desktop (2.12.388), but I guess updating Presto isn't exactly a high priority compared with moving to Blink.

This release has a secondary new mode that we hope will replace the older OBML-without-javascript mode over time, as devices get faster. It's basically Opera Turbo v2, attempting to get optimally efficient network benefits of the old Opera Mini to work with full web rendering using webkit. (On iOS Apple have been thoughtful enough to make it possible to make it possible to replace the network layer of the built-in webkit component.)

Cool, so OBML remains on Presto until it is phased out completely?

Can you point to any papers/specs/sources concerning OBML or the likes?

I was always fascinated by it (and have been trying to do something similar for my own amusement, most recently with webkit), but while getting a serialised render tree to display is trivial, making something half as usable as Opera Mini has always been seems impossible.

I believe there is still a huge market for smaller devices (probably smaller than feature phones) on which this style of web access is much thought after.

Sorry, all of that is proprietary.

As a side note if you haven't checked out Opera's Other Browser "Coast". I would really recommend playing around with it. It feels closer to the Web as OS concept than anything else I've seen.

I like almost everything except I quite detest the fact that it must reload every time I navigate back and forth. That previous versions DIDN'T do that was a huge draw for me.

Perhaps the devs could make it so it only reloads if you tap the back/forward buttons, and doesn't if you use the back/forward swipe gestures. I think that would be ideal both functionally and aesthetically.

The reason for not reloading is two-fold: 1) Much snappier browsing experience. 2) Reduced data usage.

Chrome for iOS also had this "halfway mode" where the transport is compressed but the render is WebKit. In eagerly awaiting the speed comparisons...

Personally I had to turn it off in chrome as a handful of links stopped working (presumably due to abuse originating from the shared proxy IPs)

http://dev.opera.com/blog/opera-mini-8-for-ios has some further info for developers

I really like the built-in QR code scanner. I noticed that my private certificate authorities I've installed don't seem to work -- is this an iOS limitation?

If you are using the "Opera Mini" data savings mode it's Opera's fault, otherwise it's an iOS limitation.

Ah yeah, I turned that off first thing. Seems strange that private CAs wouldn't work in apps

Private CAs do work in apps unless the app itself is doing something strange.

I gave Chrome a go as well and get the same certificate error as I got in Opera. Ah well.

Awesome! The UI is very smooth

How does it handle authenticated and SSL pages?

Does this use Blink? If not, that's a shame.

The "Opera Mini" mode renders webpages into a specialised format (OBML), so they function more like interactive images; I'd bet they finally implemented a OBML rendering/UX layer for iOS. "Opera Turbo" would be a standard iOS UIWebView except it routes your requests through a caching and optimisation server for smaller payload and quicker downloads.

Chrome on iOS renders in a UIWebView, too, and enables a similar "bandwidth saving proxy" technique by default which achieves similar results.

More about Opera Mini's compression, OBML (outdated but gives a good overview): http://dev.opera.com/articles/opera-binary-markup-language/

Sadly, I seem to only be able to install the previous version of the app which is a vastly different experience to the screenshots in the App Store. It might not have caught up to Australia's cache servers yet.

What would the benefit of that be?

Support for WebRTC, among the many other features Blink has over WebKit.

I thought Blink was just a rendering engine.

Reply on news.ycombinator.com