Pics.io is the service that says it can deliver all of this and it has several videos to show off the concept. For example, a browser can’t typically display a RAW image file because it essentially doesn’t know what to do with the sensor data that comprises the image. That’s why we collectively use different file formats, such as .JPG, .PNG, .TIFF and others on the web. This video shows that RAW images can be converted in the browser, viewed and even edited, although no heavy image manipulation is being done.

The support for RAW images is a big deal, but leveraging the cloud is another: The uncompressed and unprocessed data in a RAW image file causes the file sizes to be much larger than compressed versions. So if one had a high resolution Chromebook Pixel and say, a terabyte of Google Drive data to go with it — see where I’m going here? — Pics.io would be a hugely useful service. Here’s how the company describes it:

Imagine all your photos finally in one place. So you can enjoy them from any device – iPad, laptop, smartphone – without hardcore syncing and dealing with storage issues. Organized and searchable. Nope? Still not great? How about advanced post processing workflow (picture a combination of Lightroom and Photoshop)? And special algorithms to make photos of kittens even cuter. Well, maybe just the last is impossible.

There’s plenty more to see on the Pics.io site and I’m looking forward to seeing if it actually delivers. If so, I may dust off my old Canon DSLR and play with some RAW imagery in Chrome OS. Thanks much to Rick Huizinga for pointing out Pics.io. As he says, there’s one less potential barrier for people to use a web-based computer: “With a RAW photography tool, ChromeOS can now totally replace my need for a computer using a classic operating system.“

Related research and analysis from GigaOM Pro:
Subscriber content. Sign up for a free trial.

• HTML5’s a Game-Changer for Web Apps
• What Does the Future Hold For Browsers?
• Survey: How apps can solve photo management

Sorry, Mozilla, the Google news is bigger … for now

Depending on your point of view, this situation at its base level is either very good or very bad. On the positive side, both efforts are intended — at least partially — to create browser engines that take better advantage of multi-core chips and parallel processes to speed up the web on mobile devices. That’s great, but the biggest downside is the potential for websites to be rendered differently through different browser engines; that’s bad for users and for web developers, of course.

The Mozilla/Samsung effort is a long way off from any public final releases. And Mozilla isn’t really a force in the mobile web space these days, even though it makes a solid mobile browser. Samsung’s Android devices can obviously run Google’s Chrome browser now and Samsung has also skinned a browser for its devices; personally, I find Chrome to be a better choice, but opinions will certainly vary.

So the real story here, at least for the short- and medium-term, is Google’s effort. It has greater influence on more web users due to adoption of the Chrome browser on the hundreds of millions of desktops, laptops and mobile devices. And between Chrome and Safari, more people use the WebKit browser engine than any other. Here is worldwide browser/engine usage data from StatCounter, measured in March of 2013:

• Chrome (WebKit): 38.07%
• Internet Explorer (Trident): 29.3%
• Firefox (Gecko): 20.87%
• Safari (WebKit): 8.5%
• Opera (Presto): 1.17%

The current browser state and Google’s reason for the change

The open source WebKit rendering engine is currently used by Apple’s Safari browser — both on OS X and iOS — Chrome, BlackBerry 10 and, ironically, Samsung’s Tizen platform. As a result, it’s the most widely used browser engine. But Apple owns the trademark for the name WebKit, and that tells you part of the reason Google is forking it. The other part? Google already has its own JavaScript engine in Chrome called V8, even though it uses WebKit for rendering.

Google doesn’t want to use browser technologies that have been primarily used or built by others when it thinks it can fork or build its own code to make the web faster. And that’s a good part of the reason for the fork: speed. Not just speed the end user will see, which was partly why Chrome was built — the other part was clearly strategic — but speed of development. From the Chromium blog, emphasis mine:

“However, Chromium uses a different multi-process architecture than other WebKit-based browsers, and supporting multiple architectures over the years has led to increasing complexity for both the WebKit and Chromium projects. This has slowed down the collective pace of innovation – so today, we are introducing Blink, a new open source rendering engine based on WebKit.”

As an open source project, WebKit has many chefs in the kitchen, which is not necessarily a bad thing. But it also has different customers on varying platforms, so in order to keep it working for all, it takes a larger amount of effort in coding and testing than if it were used by a single entity. Alex Russell, a Google developer explains:

“Directness of action matters, and when you’re swimming through build files for dozens of platforms you don’t work on, that’s a step away from directness. When you’re working to fix or prevent regressions you can’t test against, that’s a step away. When compiles and checkouts take too long, that’s a step away. When landing a patch in both WebKit and Chromium stretches into a multi-day dance of flags, stub implementations, and dep-rolls, that’s many steps away. And each step hurts by a more-than-constant factor.”

As Russell works directly on Chrome for Google, it’s fair to question his motives here. It’s up to you to believe him or not. For my part, I do. I worked for years as a Software Quality Assurance tester in a Fortune 100 company and I’ve seen exactly what Russell is talking about. Projects were routinely delayed because the primary team made software changes that had negative downstream effects on other teams using the same code. Coordination was a nightmare.

The other side of the story: Web standards and bad intentions

The obvious question here is how much of Google’s effort is truly meant to improve the web versus how much of it is to take a shot at Apple? That’s a business question that can have a negative impact on web users as a whole if web standards are ignored or changed in favor of a particular browser component. Out of all the reactions I’ve read, Rob Isaac’s interpretation of the Blink news illustrates this best. He translates Google’s effort as:

We have a direct strategic interest in destroying Apple’s mobile platforms because their lack of participation in our advertising and social ecosystems does not benefit our long term goals. You should expect Chrome and Blink changes in the short term to be focused in this direction.

In the longer term, we aim to have sufficient control over the installed base of web browsers to dictate whatever conditions we consider most appropriate to our business goals at the time.

Snarky? Yes. But possibly part of Google’s rationale? Sadly, also yes. Google’s entire business is built upon the web, so exerting control over the web protects that business. In the Blink announcement Google says it will maintain transparency and use open standards, although it’s possible — likely even — that any new functions or features in Blink could be lobbied for becoming standards:

In practice, we strive to ensure that the features we ship by default have open standards. As we work on features, we track their progress in the web standards community with the Chromium Features Dashboard, which lets us be transparent about the status of each feature and about how we make decisions about which features to enable by default for the open web.

If, indeed, the Blink effort creates any new standards, it wouldn’t likely happen for a long, long time. For all the talk about HTML 5 over the past several years, the standard itself isn’t expected to be stable until 2014. But make no mistake: there’s clear potential for Google to have more direct influence over standard web browser technology as the result of Blink. And that’s something that no single company really should have.

It’s too early to say if the good outweighs the bad

For now, the situation is well worth watching over the next six to 12 months. We’ll see what Mozilla and Samsung actually produce with their collaboration, for starters. We should see a leaner and meaner Chrome as Google starts paring out code — up to 4.5 million lines and 7,000 files, says Google — from WebKit in Blink. Those are clearly good things. But we’ll also have to see what, if anything, from Blink looks like it could be pushed as a web standard. That will be the clearest warning flag that Google’s “Do no evil” theme is just a front in the new browser battle.

Related research and analysis from GigaOM Pro:
Subscriber content. Sign up for a free trial.

• What Does the Future Hold For Browsers?
• HTML5’s a Game-Changer for Web Apps
• Where new opportunity lies in the mobile operating system space

Yet, here it is three years on, and we’re still waiting for that “interactive and intimate” browsing experience (and hoverboards, for that matter).

A recent study conducted by Onswipe revealed that iPads account for a whopping 98.1 percent of tablet traffic on websites. Despite this, the actual experience of surfing the web on an iPad is underwhelming at best and infuriating at worst. Simply put, today’s state-of-the-art tablet browsers, especially Safari, don’t do the Internet, the user, or the iPad justice. Apple wasn’t totally wrong: The iPad has proven itself to be a revolutionary device that absolutely has the potential to offer a transformative web-browsing experience. It just hasn’t yet. Which means there’s a gap in the market for an intuitive, immersive, innovative iPad browser. Whoever develops it is going to win big.

Safari is deliberately hobbled

As more and more of the services we use on a daily basis have migrated to the cloud, the web browser has become the computer’s most essential app. And when we surf the web on a computer, we encounter few obstacles. Though we may have to scale the occasional paywall or sit through an obligatory five seconds of an ad before accessing content, the navigational experience of a computer user is fluid and frictionless — as anyone who’s gone down the rabbit hole researching alpaca breeds or underrated Val Kilmer films at 3 a.m. can attest.

Surfing the web is far less pleasurable on an iPad. Visiting a site frequently presents one with a pop-up and a dilemma: Download the app, or endure the diminished experience of a website designed for another device. Safari is essentially a limited version of its desktop sibling – and apps almost always provide a better experience. (Or, as Firefox UX Lead Alex Limi has summed it up, it’s ”kind of sucky.”)

Of course, this is sort of the point. It’s in Apple’s, or any tablet maker’s, best interest to make using (read: buying) apps preferable to visiting websites. Safari is designed to make using web-based apps on an iPad inconvenient, if not impossible. In response, most companies focus their mobile development resources on creating native apps rather than optimizing their content for tablet browsers. The result is a browsing experience full of flow-breakers. In short, on a computer the browsing experience is limitless; on a tablet, it’s filled with blind alleys and false doors.

Why web browsing still matters

There is an impulse among some to assume that the rise of apps – or, more sensationally, the death of the website – will eventually render browsers, or at least mobile ones, obsolete. While it’s true that more and more content is consumed through apps, and that personalization has shifted our approach to content from searching to getting, the average number of Google searches per day has steadily increased – by an astounding one trillion each year.

But even if we accept that the importance of mobile websites is on the wane, there’s no reason for mobile browsers to beat them to an early grave. There is plenty of room for resurrection, but only if we throw out desktop-based notions of what a browser looks and feels like. Freed of all the tasks and responsibilities that other apps accomplish, tablet browsers should offer an absorbing, engaging innovative experience. Further, they should evolve the idea of what a browser is and can be on a tablet. Take GarageBand, for example: The iPad version is infinitely more interactive and tactile than the desktop version.

I’ve mostly been picking on Safari. As the native browser for a tablet that accounts for 98.1 percent of tablet traffic, its influence is enormous. However, that’s not to say there aren’t more innovative browsers taking steps in the right direction. Dolphin, for instance, allows you to create your own gestures for various functions. And though there are any number of other browsers contending in the space, as of yet none has emerged as the standard-setter or must-have. Mozilla’s forthcoming iPad browser, Junior, which completely throws out desktop-inspired design and focuses on simplicity, could be a contender, but for now we have to wait and see.

What we’ve lost

As it currently stands, the shoehorning of hobbled desktop browsers onto tablets is forcing us to move from a browser to app-navigation experience. This is not necessarily a negative development, but we must carefully consider what we lose as our web experience becomes siloed, or, alternately, take into consideration in our app design how we can ensure and better enable the type of surfing serendipity that made web browsing valuable in the first place.

The web as we have known it was designed to facilitate the browsing experience – to be a boundlessly linked rhizomatic structure of hypertext. But we have quite willingly begun to fence it off as we have shifted our experience to the iPad and individual apps. Even worse, though, is that most of the apps and services that have attempted to fill the browsing void have only further constricted the experience of the web via the tablet.

Under the claim of “personalization” and making the browsing and discovery experience more individually valuable and meaningful, they really provide little more than constricting customization confined to picks of an editor or your social graph. Most of it is expected or retreaded.What is lost is the magic of blazing a trail from one page to the next, the anticipation of revealing the unknown that lurks behind the next link. Personalization shouldn’t be an either/or experience of web discovery, and neither should browsing on the tablet.

While we will continue to make strides in personalizing the web, and hopefully even enhancing the web experience on tablets, I’m also looking forward to a browser that lets me fall down an unexpected rabbit hole once in awhile. As long as there are alpacas and Val Kilmer movies, there will be surfers. It’s up to developers to provide the hoverboards.

Hank Nothhaft is the co-founder and chief product officer of Trapit, a personalized content discovery platform.

Have an idea for a post you’d like to contribute to GigaOm? Click here for our guidelines and contact info.

Related research and analysis from GigaOM Pro:
Subscriber content. Sign up for a free trial.

• What the Google-Motorola deal means for Android, Microsoft and the mobile industry
• Mobile Q2: Smartphone growth surges; iPad’s rule continues
• What Google’s Honeycomb Means for Apple and Microsoft

While Apple has a hard time keeping secrets lately, there was a time — before blogs and Twitter and small, portable devices — that the company was really, really good at it. Friday brings us an entertaining post from a former Apple engineer on the story behind how he and his colleagues very cleverly kept Apple’s Safari browser a secret as they were developing it more than 10 years ago.

There were no Fight Club posters, no cutesy codes names for the team building Apple’s web browser; just a dedicated group who valued extreme secrecy, according to Don Melton, the guy who led the Safari and WebKit projects at Apple.

“Nobody at Apple was stupid enough to blog about work, so what was I worried about? Server logs. They scared the hell out of me,” he wrote.

How did he get around this fear in order to test the browser on the open web? Head over to Melton’s blog to hear about the creative lengths his team went to in order to ensure that Safari caught the world by surprise at its big reveal on stage at MacWorld 2003.

Related research and analysis from GigaOM Pro:
Subscriber content. Sign up for a free trial.

• Forecast: Tablet App Sales To Hit $8B by 2015
• What Does the Future Hold For Browsers?
• Connected consumer first-quarter 2013: Analysis and outlook

Broadband observers should be delighted to note that the U.S. saw a 76 percent year-over-year growth in the number of connections at high broadband levels — speeds greater than 10 Mbps during the quarter. It is not surprising as many U.S. customers are leaving slower DSL connections and are switching to cable or other higher-speed options such as fiber networks.

Some key findings from the report:

• The global average connection speed increased 13 percent to 3.0 Mbps from the first to second quarters of 2012, continuing a trend of strong growth.
• South Korea continued to have the highest average connection speed at 14.2 Mbps for the quarter.
• Japan was second at 10.7 Mbps and Hong Kong was third at 8.9 Mbps.
• Among top countries ranked by average measured connection speed, Japan experienced largest year-over-year percentage growth (21 percent)
• Year-over-year trends remained generally positive, with global average connection speeds increasing by 15 percent, including growth in seven out of the top 10 countries.
• The global average peak connection speed grew 44 percent year over year, including increases of 10 percent or more across all of the top 10 countries.
• The global average peak connection speed one again showed strong improvement, growing 19 percent in the second quarter to 16.1 Mbps.
• Worldwide, 126 countries saw increases, six of which grew in excess of 100 percent between the second quarters of 2011 and 2012.  In contrast, only eight countries saw year-over-year declines.

However, it wasn’t all good news:

• The global high broadband adoption rate declined slightly in the second quarter, losing 1.6 percent.
• Seven of the top 10 countries also had negative quarter-over-quarter changes, with wildly varying magnitudes of change, ranging from a trivial loss of just 0.6 percent in Latvia (to 26 percent) to a much more concerning decline of 24 percent, seen in both the Netherlands and Belgium (to 17 percent and 14 percent respectively).
• After moving up in the first quarter of 2012, the global broadband adoption level saw a minor decrease in the second quarter, losing 2.8 percent and declining to 39 percent.

However, U.S. broadband had a great summer:

• Nine of the top 10 states saw positive quarter-over-quarter changes in average connection speeds, with the largest increase seen in Delaware.
• Top 10 states saw average connection speeds increase on a year-on-year basis.
• With 41.6 Mbps, Delaware had the highest average peak connection speed.
• A total of 37 states and the District of Columbia saw their high broadband (higher than 10 Mbps) adoption levels increase quarter-over-quarter.

In this edition of SOTI, Akamai is introducing a new Mobile Connectivity that includes mobile browser data from Akamai IO for the month of June 2012.

• The volume of mobile data traffic doubled from the second quarter of 2011 to the second quarter of 2012, and grew 14% between the first and second quarter of 2012.
• The fastest mobile average connection speed in the second quarter of 2012 was 7.5 Mbps, delivered by a mobile provider in Russia.
• A UK The fastest mobile average peak connection speed for the quarter came from a provider in the U.K. at 44.4 Mbps.
• Mobile browser data from Akamai IO for the month of June shows approximately 38 percent of requests on cellular networks came from Android Webkit.  Some 33 percent came from Mobile Safari; and about 4 percent from Blackberry.
• However, add Wi-Fi, the numbers shift in favor of Mobile Safari, which accounted for an average of approximately 60 percent of requests.  Android Webkit represented about 23 percent. Of course, it shouldn’t surprise since many folks own iPod Touches and iPads that use Wi-Fi for connectivity.

Related research and analysis from GigaOM Pro:
Subscriber content. Sign up for a free trial.

• Best practices in optimizing content for social engagement
• Takeaways from mobile’s second quarter
• 12 tech leaders’ resolutions for 2012

Related research and analysis from GigaOM Pro:
Subscriber content. Sign up for a free trial.

• The future of mobile: a segment analysis by GigaOM Pro
• Takeaways from mobile’s second quarter
• Connected world: the consumer technology revolution

Related research and analysis from GigaOM Pro:
Subscriber content. Sign up for a free trial.

• Who and what to watch in the new era of the living room
• 2012: Data, spectrum and the race to LTE
• CES 2012: a recap and analysis

The incident stems from a highly publicized incident in February in which a Stanford graduate student discovered that Google was using trickery in order to by-pass ad-blocking settings on Apple’s Safari browser. The scheme involved coding ads to masquerade as form submissions in order to install advertising cookies (see my colleague Tom Krazit’s great explanation of the tricky business — and its relation to Google+ — here).

While other companies and app makers may have engaged in similar chicanery, the Federal Trade Commission appears determined to hit deep-pocketed Google hard. The Journal reports that the FTC’s $22.5 million punishment is based on Google’s failure to tell the truth about its advertising practices.

The federal agency has in recent years emerged as the country’s de facto chief privacy cop even though the laws governing the agency aren’t particularly designed to do this. While other countries have special Privacy Commissioners, the FTC instead relies on its traditional powers to regulate “deceptive” and “unfair” trade practices.

The FTC recently used these powers to slap a 20-year “consent decree” on Google to punish it for missteps related to its ill-fated Google Buzz social network. That consent decree in turn provided the FTC with powers to fine Google $16,000 a day if it violated the terms of the decree. That is what appears to have happened here: Google didn’t comply with terms of the decree that requires it to tell users about its advertising practices.

Google also faces a series of private class action suits over the Safari incident. The news of the FTC fine comes at a time when every large technology company is confronting lawsuits and regulatory scrutiny over their privacy practices.

(Image by Suzanne Tucker via Shutterstock)

Related research and analysis from GigaOM Pro:
Subscriber content. Sign up for a free trial.

• What Does the Future Hold For Browsers?
• Survey: How apps can solve photo management
• Sector RoadMap: Content personalization in 2013

I’ve been covering the wireless industry for 12 years, and for seven of those years I was sort of an unofficial wireless consultant for my decidedly non-technical friends. Every few months, I’d get asked my opinion on what phone to buy, and I would go on about 2G versus 3G, Symbian and BlackBerry vs. Java and BREW. Usually after a few minutes, my friends would cut me off and impatiently ask “which phone makes the best phone calls?”

I say “for seven of those years” because around five years ago those questions stopped. Sure, I would have conversations with friends about devices and the merits of different carriers, but my supposed expertise was no longer needed. Suddenly all these lawyers, teachers, cooks, writers and artists – and even some of their children — were no longer mystified by smartphone or mobile data services. They stopped asking questions about voice quality because the phone was no longer a mere telephony device.

What happened, of course, was the introduction of the iPhone. It certainly wasn’t the first smartphone to emerge in the wireless industry, but it was the device that bridged the gap between the technical and the consumer classes. Through Apple’s innovations with the Safari mobile browser, the touch user interface and the App Store, the iPhone first demonstrated that more than just a rudimentary Internet and computing experience could be had on our handsets.

It may have had precursors, but it was the iPhone that kicked off the mobile data revolution. The astonishing thing is Apple succeeded where the rest of the wireless industry had failed. Carriers, network vendors, handset makers and OS developers had the same vision as Steve Jobs and Apple. They just couldn’t execute it.

The first 3G network went live in 2001 in Japan. What followed was six years of missed opportunities and dashed expectations. Palms and BlackBerrys and Symbian devices – as well as the hordes of feature phones — added some traffic to the network, but few people were signing up for data plans, and those that did were only willing to pay a handful of dollars a month.

In Europe, carriers began grumbling that they had far overpaid for their 3G spectrum. The biggest single source of mobile data revenue for operators was SMS – a 2G service. That cockamamie idea — the unlimited plan — was born, haunting operators to this day. At the time carriers’ 3G networks were still largely unused and no one could conceive of a smartphone consuming more than 100 MB a month. Why not open up the spigot?

Well, the wireless industry got what it wanted, and now it’s drowning in its own riches. The iPhone, followed by Android, has precipitated an explosion of traffic on their networks. But it was hardly a controlled reaction. The mobile apps and services that now abound aren’t the voice, SMS, ringtones and wallpapers that carriers could easily monetize in years past. Instead they’ve become dumb pipes, and though their networks are carrying far more data than voice traffic, they’re still largely dependent on old-school voice and text revenue for their profits.

What’s more, that explosion in traffic quickly filled up their 3G networks, forcing them to invest billions in 3G upgrades and accelerate their 4G plans. If mobile data, however, continues to grow at the pace that Cisco Systems, Ericsson and independent analyst firms claim it will, then those investments will hardly be enough. Operators will need to radically change the fundamental designs of their networks – and grab as much spectrum as they can – to meet that demand.

Ironically, carriers once again find themselves dependent on Apple to keep the mobile data revolution going. The mobile data boom is now much bigger than the iPhone, but Apple’s devices are so pervasive that the choices it makes in radio technologies will have big repercussions throughout the industry. As I wrote in a recent GigaOM Pro analysis piece (subscription required), so long as Apple continues to make 3G iPhones, operators will be forced to continue investing in 3G networks.

I know some of you are going to accuse me of exaggeration here – that I’ve minimized the contributions of Palm, RIM and Nokia. I give those companies their due credit for some of the key innovations that led to the modern smartphone. But none of this produced a seismic shift in the mobile industry. The iPhone was the fault line, and ever since its first tremors issued forth in 2007, wireless has never been the same.

Please check out the rest of our stories on the fifth anniversary of the iPhone, collected here.

Related research and analysis from GigaOM Pro:
Subscriber content. Sign up for a free trial.

• Why LTE in the iPhone matters
• Mobile 2012 and beyond
• How to deliver the next-generation web experience

A unified experience on desktop and mobile

Before getting to my own experiences, let me share a thoughtful piece that hones in on what Apple is doing, from Jean-Louis Gassée’s point of view. Here is a key excerpt from his most recent Monday post:

For a company that prides itself on simplicity and elegance, it only makes sense that Apple would offer a consistent UX across all its devices, a GUUX, a Grand Unified User Experience. Apple customers should be able to move easily and naturally from one device to another, selecting the best tool for the task at hand. Add another unification, iCloud storage services, and Apple can offer more reasons to buy more of its products.

In typical fashion, Gassée nails the concept with a descriptive term, a “grand unified user experience.” I had a similar epiphany over the past weekend as I kicked the tires of Apple’s Mountain Lion software, but Gassée penned it perfectly. And even before I read his post, I noticed something that I hadn’t been doing for ages. I started reaching for my iPhone 4S instead of my Android phone, the Samsung Galaxy Nexus.

Does this mean I will no longer be a daily Android user? No, I will keep using Android alongside iOS and even Windows Phone. Of course, I am an outlier: I try to use all platforms to see which is best for the different tasks and use cases people have. However, it is telling that my Galaxy Nexus — and even my Galaxy Tab 7.7 slate — have not been used much since I installed Mountain Lion.

How these two platforms work together

Take a look at the feature set in Mountain Lion and you can see the integration between desktop and mobile. Use Mountain Lion, however, and you will start to experience something new; at least, that’s how I’m feeling. It begins to matter less if you are on a desktop, laptop, phone or a tablet: You can use similar apps and interfaces to get things done.

The new Notifications in OS X works and looks just like its counterpart on iPhones and iPads running iOS 5. And reading an email on my iPhone, for example, removes the notification for that message on my desktop. That is huge, as people don’t need to see the same email or notification for it multiple times as they move across devices.

The new Messages in OS X, which you can actually download now, is another example. It looks and acts similar to iMessages in iOS 5. Plus the conversation follows you whether you are on a Mac, iPad, iPhone or iPod touch. Over the weekend, I had a long chat with my son and was able to seamlessly carry on the conversation regardless of which Apple product I had in hand. Of course, FaceTime is supported on both OS X and iOS, so with a single tap we were video chatting without worrying which devices we were using.

Reminders and Notes in Mountain Lion are also lifted from iOS, where they are simple and effective. But the killer feature of both is the ability to sync data across iCloud between the desktop and mobile devices. Again, it doesn’t matter which device you are using at a given time: You will still see your notes or get your reminder alarm at the appropriate time. These are just a few of the new iOS tie-ins. Here is a complete list.

So what does this have to do with Android?

Simply put, Android doesn’t have native integration with a true desktop platform. Instead, it is cloud-focused from a data perspective while leaning heavily on third-party apps, browser extensions and its own Chrome browser to offer a “use anywhere” experience. It works, but based on what I have seen from Mountain Lion so far, it is looking more disjointed.

Perhaps Google’s ChromeOS, used in ChromeBooks, will eventually bring this type of integration for Android users, but today it doesn’t exist in a Google platform, with the exception of the Chrome browser and the web in general. For example, there is no true Google Tasks apps, unless you consider the applet that is part of Gmail in the web. And there is no mobile Tasks app from Google. Instead, there are several third-party apps that synchronize with Google Tasks.

The new Chrome browser for Android is a step in the right direction, as it can show you open tabs from Chrome on a desktop. Safari can’t do that yet, but it does support bookmark synchronization through iCloud, which is good enough for most people now. The odd thing is that I have used Chrome as my go-to browser for the past three years or so. But again, with Mountain Lion, I flipped over to Safari 5.2, which I find faster than the current version of Chrome, and it supports a synchronized reading list between my iPhone and my MacBook Air.

I smell a trend

Clearly, Apple is unifying the experience across all of its devices, based on the examples here. Google is doing it to a lesser degree between Android and the Chrome browser. And I wouldn’t be surprised to see it attempt to do the same with its ChromeOS, possibly at this year’s Google I/O developer event. But even Microsoft is working the same angle with Windows 8 and Windows Phone.

Both will use the Metro user interface, presumably to provide a seamless experience. It is for this reason among others that I made the prediction of Microsoft handsets outselling BlackBerrys by the end of this year. In December I suggested that “Windows 8 will actually help create demand for Windows Phone in the second half of the year as desktop upgraders will want the Metro user interface on their phones for a unified experience.”

How much could this interaction between Mountain Lion and iOS hurt Android sales? That is hard to say. Those who prefer a greater range of control over their mobile devices will still likely choose an Android device in the near term. But people looking for a “grand user interface unification” may give up some control in order to gain a seamless experience across devices and choose iOS, especially if they are current or new Mac OS X users when Mountain Lion arrives this summer.

I will still continue to rotate through my gadgets based on my needs so that I am always using the best tool for my tasks. Plus I enjoy customizing my Android devices and using my phone to wirelessly pay for goods. However, there is something to be said for Apple’s core integration competency, and I think I said it best in a tweet last week:

It's easy to whine about what a closed system can't do, but If done right, it's hard to whine about what it can do. #Apple #GOM—
Kevin C. Tofel (@KevinCTofel) February 16, 2012

Related research and analysis from GigaOM Pro:
Subscriber content. Sign up for a free trial.

• Analyzing the wearable computing market
• Takeaways from mobile’s second quarter
• Siri: Say hello to the coming “invisible interface”