We’ve all seen the Android statue, placed above the entrance to the building on Google’s campus in which Chrome is developed and maintained. The speculation ran rampant, and still does. Is Android going to destroy Chrome? There is a line of code present in Chrome that mentions Android, lending credence to the panic. Google is saying nothing, as usual, so we’re still left to wonder why that statue is there, and what (if anything) it means.
The natural assumption is that Android and Chrome OS are merging, or that Chrome OS will get Android somehow woven into it. When the statue emerged, we were pretty sure there was going to be some kind of Android inside of Chrome OS. Some cheered, many jeered. Do we need that? Do we want that? The Chrome faithful thought it to be a slight against their OS, while Android fans were just confused as to why Google would do that.
To some, it seemed a concession that Chrome OS was less-than, and needed Android to survive. Chrome OS is severely lacking in apps, which means it simply doesn’t have the functionality it should. Being based on the web has a downside, and that’s a major one. Was Google making a simple fix for the app situation by baking Android in?
They may both be Google services, and share some traits, but Chrome OS and Android are very different. Take a similar function, like Google Drive: Chrome has the full-fledged version, while Android has an app. A great mobile app, but nowhere near the functionality of the desktop version. Without more functionality, it’s hard to be truly productive.
There are apps for Android, like Quickoffice, that really are better suited for Chrome, yet Chrome OS goes wanting (for now). We wondered if somehow implementing Android was a quick way to add a bunch of functionality and appeal to Chrome. It makes immediate sense, but on closer review… that may not work, or even be smart.
The Chromebook Pixel is meant to pave the way for Chrome OS, and a large part of that is the touchscreen. While the touchscreen on the Pixel is really cool, it has a long way to go. So far, we can press some buttons, or scroll through pictures as in Android, but not nearly the gamut of function we would like. We can’t pinch to zoom on every page, which is the immediate desire when looking at something small. All that functionality is available in Android, which is probably why we want it on the Pixel.
To our minds, a touchscreen is a touchscreen. We neither want or care to differentiate between platforms or devices. If I can do something on my phone or tablet, I want to be able to do it on the desktop. The mind wants what it wants, and it doesn’t want to think critically about can and can not before taking action. The touch interaction is the most glaring benefit of Android to Chrome, and it just makes more sense to take some really good functionality and implement it rather than build your own.
Here is where it gets tricky. If Android isn’t coming to Chrome, are we getting it the other way around? Why does Chrome have a mobile browser, and an additional Chrome beta browser? It’s pretty clear the Chrome team is up to something, but exactly what that is remains a mystery.
The Chrome browser you have for Android isn’t all that old, nor out of beta for very long. It was put through its paces, then released to the wild. Chrome has now been cloned into a new beta, which does some different stuff. It has full-screen functionality, which is pretty awesome, especially on a tablet.
So, why do we need a beta on top of the stable Android version? When released, the beta version of Chrome for Android was version 25, same as the desktop Chrome variant. The stable Android version of Chrome was release 18. Google would like to have both Chrome variants updated on the same 6-week cycle, so this move would satisfy that. Both versions of Chrome for Android are now on the same update, but the beta is still being toyed with.
The same version of Chrome solves an update issue (a small concession, really), but it has much more implication than that. The same iteration of Chrome, updating at the same time, with the same functionality sounds more like Google wants a single Chrome browser than it does anything else. We’d all love a true cross platform browser, so this is a great move by Google… but is it just another sneaky way for Google to get us to do their beta testing?
There are a few other platforms which utilize web apps rather than native apps in Firefox and Ubuntu. Those are two platforms that, while lacking in comparison to Google and Chrome, will have a cross platform presence. Web apps may be a bit cumbersome right now, but the usability on all devices is convenient and welcome. It also makes Chrome OS on mobile a much more salient option, and perhaps one that suits a larger need. Google has admitted to Chrome OS coming to mobile, but nothing has come to light.
Let’s ponder a company with employees on the go. They’re in the office about 50% of the time, and the rest of the week they’re out in the field. If those employees could tote a tablet around, rather than a Computer or even a Chromebook, it makes a bit of sense. If your needs don’t require a full-fledged computer while out of the office, Chrome OS for mobile is a great option. An office full of Chromeboxes, and a staff armed with tablets. This makes apps like docusign much more useful for Chrome OS, where an e-signature is required.
Pinching a bit of project butter or the Android keyboard into Chrome OS makes the platform much more viable for a greater cause, which is enterprise. The more arrows Google has in their quiver, the more companies will begin to see the benefit of their services. With Google’s recent acquisition of Quickoffice, enterprise seems to be the new battleground… and Google is serious about controlling it.
Just what is going on with Chrome Os for mobile? Nobody has a clear answer. We can, however, follow the breadcrumbs. Those breadcrumbs lead us to a trail, and it also answers a few questions about development of Chrome OS and how it relates to mobile.
First, development. Web apps are harder to develop for touch, and the industry standard keep shifting. This may be why the push for HTML5 has been so widespread, and the shift so sudden. It seemed that, overnight, companies were willingly dumping languages like Java for HTML. Let’s forget the security implications for a minute and consider just how radical a shift this was, and is. Apple paved the way, but everyone following suit so quickly thereafter is telling.
Now for the breadcrumbs. Google announced a Chrome OS for mobile in 2011, and went on to say there would be tablets running the it. When the Pixel was released, the story was that it was two years in the making. In 2011, we had Chrome OS for mobile being developed, which is primarily a touch-based platform. We now have a Chrome OS machine.. touchscreen and all… meant for developers. It’s all coming together, now.
Android has a lot of functionality to offer Chrome OS, especially if that platform really is coming to mobile. If we take a look at the evidence, it seems as though Android functionality is being folded into Chrome because of Google’s desire to take that platform mobile. We may not get full Android within Chrome, but the functionality is welcome. Apps and widgets would be cool, but the core functionality is of more consequence to Chrome OS.
What does this mean for Android? Nothing… yet. Right now, Android is at the top of the food chain, and taking up more of the market share all the time. Is it wise to have two platforms? Google seems to be doing well with it, just as Apple is. Shared functionality is one thing, a copycat platform is another. Then again, if Linus Upson, Google’s Vice President of Engineering, was right, Android may be counting the days to retirement. Look at the picture above and tell me… does that look like a wave hello, or goodbye?