Michael Gartenberg Michael Gartenberg has covered the personal technology beat for more than two decades at places like Gartner, Jupiter Research and Altimeter Group. Most recently, he spent a few years at Apple as Sr. Director of Worldwide Product Marketing.

The relationship between Chrome OS and Android were always baffling to me.

For a long time, Android and Chrome OS were two different initiatives at Google. They were led by two different product teams. They clearly had separate goals.

The Android team's mantra, under Andy Rubin, was "Android everywhere". It wasn't just for phones. Android was for everything, all devices, all the time. Chrome OS, on the other hand, was for Chromebooks, devices almost the antithesis of Android. The simplicity of life in a browser was a sharp contrast from the complexities of mobile devices.

Google TV was a disaster but the humble Chromecast, much more successful

But Android everywhere never actually played out. Google TV, for example, was an unmitigated disaster. The humble Chromecast, though, has been much more successful. (Even the recently announced Google Home is reportedly based on Chromecast, not Android.)

Chromebooks have also started selling well. As prices continue to fall and the devices themselves have become more capable in terms of performance, they've become an interesting tool for the classroom.

Now, Google is bringing Android to Chrome OS: Soon, Android apps will be able to run in Chromebooks.

Let's face it, while Chrome does a lot, to date it hasn't competed well when compared with rich, full featured apps. For example, want to edit 4K video on a Chromebook? Not going to be pleasant. That's where Android comes in, providing a richer layer of applications than Chrome can deliver.

Call me skeptical, though. Taking two diverse things and trying to merge them into one, historically, hasn't been a recipe for success. It takes the simplicity of a Chromebook then adds the complexity of Android. It takes Android apps, which have struggled to scale to the tablet, and stretches them out to the PC. It puts the demands of a completely different set of input expectations, namely the traditional computer mouse/trackpad and pointer system, on software designed for multitouch and fingers.

There's a danger that trying to develop for — and use — both will result in compromise, confusion, and frustration for all involved. By contrast, this is exactly why Apple's approach with iOS and OS X makes sense to me.

Apple's goal has never been to see if they can create a single platform for all devices. iOS and OS X aren't likely to come together anytime soon — or ever. There's no good reason for Apple to make this happen.

That's not to say they won't work better together over time. We've already seen how iOS gestures have made their way into OS X via the trackpad. We've also seen Continuity handoff content and sync activity state from OS X apps to their iOS counterparts and back.

iOS and OS X implement features in ways that let each platform be true to itself and the devices it runs on.

There's no need for OS X to run iOS apps, because each system can learn from the other and implement features in ways that let each platform be true to itself and the devices it runs on.

When all you have is a hammer, everything is a nail. When you've been carefully building your toolset for years, though, you can pick the right one for the right job.

You can get the richness and capability of OS X applications. And you can get the accessibility and convenience of iOS apps. That's about the best experience any vendor can deliver right now. Not both on one device, but each on the best device, creates the optimum potential for customers.