Google Just Snuck Most of Chrome OS Onto the iPad | Hacker News Reader

Google Just Snuck Most of Chrome OS Onto the iPad

thenextweb.com

122 pointsevo_940 comments

This article makes no sense.

Apple has already "snuck most of Chrome OS onto the iPad" - it's called mobile Safari, and it shares the same WebKit foundation as Chrome/Chrome OS.

Google's new search app can act as a portal into the various Google Apps, and that's somehow "sneaking in" their OS? All it's doing is taking features already present on the iPad and making them (slightly) more visible.

"snuck" sounds ugly because it implies Google surreptitiously crawled itself into the iPad.

Google implemented a combination of APIs provided by Apple. I don't see something wrong with it, they don't appear to be breaking any rules. I would have done the same.

While sharing the same foundation code is not as valuable as search + ads, Google has a positive outcome, which stems from more scrutiny and active development. In the end, it benefits both Chrome and Safari.

They "sneak in" in the sense that the experience is far better with the App. To me, that makes a huge impact in user perception.

i read the tone of the article as entirely the opposite - namely, that despite some bullshit rules that apple has scattered like caltrops around the ipad development landscape, google has, admirably enough, snuck in most of chrome os. the word here implies a certain cleverness on google's part

"snuck" sounds ugly because the correct word is "sneaked".

Honestly, if Google were to continue to update this app, replacing each of the web versions of these apps with native ones, it could easily end up with a fully iOS-native version of Google Chrome, running on the iPad.

Um, what? I think this guy is confused. iOS-native Google Apps would be great to have, but they wouldn't be Chrome. Chrome is a browser and app platform, which Apple will certainly not allow on the App Store, ever.

Given that they use the same renderers, and Apple is gradually copying Chrome's security / reliability features (sand-boxing using subprocess) in every part of their OS (it's arguably the biggest feature in Lion), I don't think it really matters.

If Safari (and the tech behind it) really starts lagging, Google might worry a little, but I can't see how it's a big deal.

Google is using the strategy Microsoft seems to have given up on - don't rely on your ability to monopolise everything, just keep a foot in every door, and keep pushing at every level.

It's the "app platform" parts of Chrome that are and will continue to be missing from Safari. Things like WebGL, NaCl, WebM/P, Dart VM, and various extension-only APIs that Chrome has introduced. WebGL may be enabled in Safari eventually, but the rest have basically no chance as far as I can see. Not that Safari necessarily should implement all Chrome features, but it would be nice if Chrome was actually available as competition.

I think that's the subtle beauty of what Google has done here. Sure, we care about WebGL and the like, but consumers? They just want easy access to the tools that they use.

Your point about extensions is a big one, though. That's part of what makes Chrome and the Chrome OS so infinitely useful, and it's something that has a snowball's chance of ever landing on iOS.

"Consumers" would care if they weren't able to access some killer app because they don't have WebGL. Some of us are working on making tools comsumers will want to use that are only possible with WebGL.

> Things like WebGL, NaCl, WebM/P, Dart VM, and various extension-only APIs that Chrome has introduced.

Can someone explain this to me: why such a move, when performed by microsoft is considered EEE (embrace, extend & extinguish) and when performed by google it suddenly becomes way to go?

WebGL started at Mozilla, then Opera. Apple/Google/Mozilla and Opera are part of the working group that are developing it.

WebM/P solved a problem that people have been asking for for years.

Nacl and Dart could be considered EEE, but really the web has always been about experimenting to push tech as google are doing, all these technologies are open to be implemented elsewhere. Microsoft actively broke existing technologies and attempted to replace them with closed ones

Yeah, my problem was with NaCl and DartVM, not WebGL/WebM.

When developers start using <script type="text/dart"> scripts, they will break web for a huge segment of users. And NaCl is only marginally better than ActiveX. That's why I think both these technologies will not gain much recognition outside google and some cool side projects.

> Both these technologies will not gain much recognition outside google and some cool side projects

...Which is probably why there was little mention of "EEE" when they were announced—how can Google extinguish when nobody uses their alternative?

wtf editor lets a writer get away with using honestly?

Google could get away with an app platform, I think, but if it doesn't beat the mediocre performance of a web-based app you can run in any browser, there is no point in it. But if they can make a native app that runs Chrome OS "native" apps with iOS native performance, then they will really have something, something companies will build on.

Honestly I am already planning to build for Chrome OS. It is little now, but it will take off just like Android has.

An honest question about the quote: Was it not the purpose of the Chrome OS to be rid of native applications in the first place, and replace them with well tailored (specific to the rendering engine in Chrome) web applications? Does making all the Google applications native to the iPad go against the entire purpose of Chrome/Chrome OS?

Chrome OS or not asides, wow, I really love the UI presented in the new Google Search app. If they add some more browsing features (address bar, open in new tab), it would become a really great Mobile Safari alternative...

That may be precisely the problem, though - I'd venture to say that Apple will be looking closely at that app. If it becomes a browser replacement/alternative, then chances are it won't be given continued life.

True, but then there's already a lot of alternative browsers in the App Store (just that all of them tries to replicate desktop browser UI, which doesn't translate to touch quite well) there's a chance Apple might let it pass...

What? Why not? iCab, Opera mobile, Opera mini, and dozen other browsers have already existed in the App Store for a while now. There's no rule against shipping a browser that uses UIWebView.

(There was some fuss around Opera mini because it doesn't use WebKit but it was eventually approved as it doesn't render HTML directly, it's like Amazon's Silk.)

I wish this was available on the Kindle Fire. One of the worst things about my new Fire is that it doesn't have any native Google apps on it... so it is particularly ironic that an Android based tablet has worse integration with Google apps (like contacts and gmail and G+) than the Apple tablet!

This isn't sneaky at all, the author is perpetuating this google/apple hate war. Google have put together a great app completely within the guidelines of the appstore.

Android vs iOS tablet stories are getting so old already. Both platforms are almost practically the same technologically as they are just both mobile Unix variants with the same or equivalent hardware. It's just a matter of design preferences and price points. Apple software tends to be less utilitarian and more simple and consumer friendly while Google lays on the utilitarian techie feel really thick.

The most interesting aspect of this otherwise-thin article is that it highlights the ongoing internal competition between Chrome as a web OS vs the rich client-side framework offered by Android. I have the feeling that the two teams within Google see this as something of a zero-sum game.

This app just feels wrong on the iPad. While the main screens are nicely done, the individual apps are just the mobile or web versions. This makes for a very inconsistent UI and experience.

Personally I don't think this app should exist. Google search is built into the safari UI after all.

Things that make it at top of HN these days!

This post embodies so much that is wrong with tech blogs. A false, inaccurate narrative to fit the conflated ideas of app UX with browser/OS use case. He's been called out by myself and others in the comments and doesn't care that he's wrong or misleading. Totally senseless.

This is not the first time Chrome OS got onto the IPad !!!

Other than via Jailbreak? Source?

Wow the video really portrays chrome os 2.0

The thing I like most about the iOS Gmail app is that it’s an elegant solution, they packaged the excellent webapp (the soon to be released redesign) and endowed it with native notification capability. It’s a cost-effective solution and one that makes sense, packaging webapps and augmenting them with native capabilities, voice control in the case of the search app. Now my question is when will we see the new Google design on the desktop?

I don't see why it is necessary for the desktop. Gmail web app already supports notifications and file attachment drag-and-drop (if you use Chrome). And on desktop, you have much more resource and don't need to worry about closing the gmail tab to release resources.

Web-app repackaging instead of a tailored native app seems mostly of benefit to the developer rather than users. I don't especially care how easy a time developers of apps I use had.

Reminds me a bit of the "console port" phenomenon that ruffles PC gamers sitting with their gleaming machines.

Even when the webapp is great? I don't see why they or anyone else should maintain several versions of the same app, focusing on one version and iterating quickly is surly to everyone's benefit.

Some desktop app developers don't see why they should maintain several versions of their app, put out a single Java GUI across platforms, and get shunned for it. (Granted, web look and feel on mobile likely won't be that bad).

I think this issue boils down to perceived ROI on development costs (and 'push web technologies' agenda in Google's case) rather than quality.

The web app is fine, but there's definitely room for improvement in a native app. This thing offers me nothing that I can't get by using the web app for most stuff, and using Mail.app for notifications. Which is what I've been doing for a year, and will continue to do.

I wouldn't describe the webapp as great. Since it attempts to emulate aspects of UIKit it suffers greatly from the uncanny valley effect. The performance and feel is poor compared to a native app.

I realise it's more convenient for Google, but I struggle to believe that's the primary concern when a company of their size develops an app for a platform with hundreds of millions of users.

To me it feels the app is intentionally crippled for some business reason. Perhaps it would be more difficut to target ads in a native app, or maybe they want to push people towards Android. As a user, I really don't care and it reflects poorly on them to produce a substandard experience for their users.

Roll on Sparrow for iOS.

The iOS Gmail app was a sore disappointment, for me. I desperately wanted it to support multiple accounts, and the fact that it doesn't is my deal-breaker.

Granted, I get it, I'm probably a fringe case. But still, I think that elegant solution or not doesn't matter when it doesn't do what I need it to do.

One of the advantages of repackaging webapps is that they can be quickly iterated upon and in any case that is the Google way: release early, iterate often. The app should gain the missing features soon enough.

That's the argument that one of my fellow writers made, as well, when he felt I was overly-critical of the app. Here's the problem, for me - I didn't use it on day 1. What are the chances of me installing it later, if I'm Joe User?

Honest question there. I really don't know the statistics about that, other than to say that I'd guess the chances are lower after a poor first impression.

The app wasn't meant to attract new users but mainly to support existing ones, so it's an option that is "good to have" rather than the product itself. If a user or a company deploying Google Apps felt that they needed a native option then it's available, and for Google it won't cost much to maintain because they are already investing in the webapp.

Reply on news.ycombinator.com