Posts tagged with "google"

Google Announces Cardboard SDK for iOS, VR View for Apps and Websites

Interesting updates for the only VR viewer I own: starting today, iOS developers can create native apps for Google’s Cardboard VR thanks to a new iOS SDK, and they can also embed VR views in their apps and websites.

VR views take 360 VR images or videos and transform them into interactive experiences that users can view on their phone, with a Cardboard viewer, or on their desktop computer. For native apps, you can embed a VR view by grabbing the latest Cardboard SDK for Android or iOS and adding a few lines of code. On the web, embedding a VR view is as simple as adding an iframe on your site. We’re open-sourcing the HTML and JavaScript for web developers on github, so you can self-host and modify it to match your needs.

Google’s blog post has an example of a VR view – tap a button, put your phone in the Cardboard, and view the content in VR. Very nice.

Permalink

On Google’s iOS Apps

MacStories readers and listeners of Connected are no strangers to my criticism towards Google’s Docs suite on iOS. For months, the company has been unable to properly support the iPad Pro and new iOS 9 features, leaving iOS users with an inferior experience riddled with a host of other inconsistencies and bugs.

Earlier today, Google brought native iPad Pro resolution support to their Docs apps – meaning, you’ll no longer have to use stretched out apps with an iPad Air-size keyboard on your iPad Pro. While this is good news (no one likes to use iPad apps in compatibility mode with a stretched UI), the updates lack a fundamental feature of the post-iOS 9 world: multitasking with Slide Over and Split View. Unlike the recently updated Google Photos, Docs, Sheets, and Slides can’t be used alongside other apps on the iPad, which hinders the ability to work more efficiently with Google apps on iOS 9.

Today’s Google app updates highlight a major problem I’ve had with Google’s iOS software in the past year. One of the long-held beliefs in the tech industry is that Google excels at web services, while Apple makes superior native apps. In recent years, though, many have also noted that Google was getting better at making apps faster than Apple was improving at web services. Some have said that Google had built a great ecosystem of iOS apps, even.

Today, Google’s iOS apps are no longer great. They’re mostly okay, and they’re often disappointing in many ways – one of which1 is the unwillingness to recognize that adopting new iOS technologies is an essential step for building solid iOS experiences. The services are still amazing; the apps are too often a downright disappointment.2

No matter the technical reason behind the scenes, a company the size of Google shouldn’t need four months (nine if you count WWDC 2015) to ship a partial compatibility update for iOS 9 and the iPad Pro. Google have only themselves to blame for their lack of attention and failure to deliver modern iOS apps.


  1. I could mention the slowness to adopt iOS 9 across their other apps, or the lack of Picture in Picture and background audio in YouTube, or the many problems with rich text in Google Docs, or the lackluster iOS extension support across all their apps. ↩︎
  2. And for what it’s worth, Apple’s services still leave a lot to be desired, too – especially Siri. ↩︎


Chrome for iOS Switches to Modern Web View API

Big news from Google’s Chrome for iOS team today: the app has moved from the legacy UIWebView API to WKWebView, promising notable speed improvements and 70% less crashing.

Here’s Andrew Cunningham, writing for Ars Technica:

Chrome’s stability on iOS should also see a big improvement. The UIWebView process in older versions needed to run within the Chrome process, so if a complex or badly behaving page made UIWebView crash, it would bring the whole Chrome browser down. With WKWebView, Google can move the process for individual pages outside of the app, better approximating the process isolation that Chrome uses on other platforms. Now when a page crashes, you’ll see the standard “Aw, Snap” Chrome error page. Google estimates that Chrome 48 will crash 70 percent less than older versions.

Apparently, Google worked with Apple to fix some of the bugs that prevented them from using WKWebView in Chrome before iOS 9. Developers have long been positive about the benefits of WKWebView (see my story on iOS web views from last year) and it’s good to see Google moving to a faster, more stable engine.

I’m curious to know if Google’s dedicated search app has been or will be upgraded to WKWebView as well. I don’t use Chrome (I like the unique perks of Safari, like Safari View Controller and the ability to access webpage selections with action extensions), but I prefer the Google app for traditional Google searches – it has a native interface for the search box with handy suggestions and links to past queries. Not to mention Google Now, which I’ve grown to like to track shipments, get weather reports, and receive time to leave notifications.

An important note for VoiceOver users: today’s update seems to break support for this key accessibility feature in the app.

Permalink

Google Paid Apple $1 Billion to Keep Search Bar on iPhone

Joel Rosenblatt, reporting for Bloomberg:

Google Inc. is paying Apple Inc. a hefty fee to keep its search bar on the iPhone.

Apple received $1 billion from its rival in 2014, according to a transcript of court proceedings from Oracle Corp.’s copyright lawsuit against Google. The search engine giant has an agreement with Apple that gives the iPhone maker a percentage of the revenue Google generates through the Apple device, an attorney for Oracle said at a Jan. 14 hearing in federal court.

It’s not surprising at all that Google is paying Apple for the benefit of being the default search engine on iOS, but this is the first time it has been confirmed, and a dollar figure provided. But it is also an awkward revelation for Apple, which has recently started to more aggressively position itself as the company that protects its user’s privacy. Remember Tim Cook’s note on “Apple’s commitment to your privacy”?

A few years ago, users of Internet services began to realize that when an online service is free, you’re not the customer. You’re the product. But at Apple, we believe a great customer experience shouldn’t come at the expense of your privacy.

Our business model is very straightforward: We sell great products. We don’t build a profile based on your email content or web browsing habits to sell to advertisers. We don’t “monetize” the information you store on your iPhone or in iCloud. And we don’t read your email or your messages to get information to market to you. Our software and services are designed to make our devices better. Plain and simple.

Apple’s subtle (or perhaps not so subtle) privacy dig at Google looks a bit absurd and hypocritical in light of this court transcript. Apple may not build a profile on its users to sell to advertisers, but it lets Google do that (by default) and then profits from Google’s actions.

Unsurprisingly, Google and Apple weren’t happy about the disclosure by an Oracle attorney and sought to seal and redact the transcript. As Bloomberg reports;

The specific financial terms of Google’s agreement with Apple are highly sensitive to both Google and Apple,” Google said in its Jan. 20 filing. “Both Apple and Google have always treated this information as extremely confidential.”

The transcript vanished without a trace from electronic court records at about 3 p.m. Pacific standard time with no indication that the court ruled on Google’s request to seal it.

Permalink

Google’s Second-Class iPad Pro Apps

Serenity Caldwell, writing for iMore:

Despite receiving several updates in the last few months, Google’s apps haven’t been updated for Apple’s larger tablet. And there’s no hope, as there is with Facebook, of using Google’s in-theory-HTML5-and-therefore-iPad-compliant website: Google’s standard web view on an iPad flat-out punts you to the apps—if the website even correctly detects you have the app installed. I can’t count the number of times I’ve seen the websites try and send me to the App Store to open a spreadsheet, when I clearly have Sheets already available.

Trying to request the desktop version of the website won’t work, either: You won’t be able to scroll, or tap on anything that requires a double-click, and any link you do manage to make work will send you right back to the mobile environment.

As I’ve tweeted for the past two months, Google’s suite of Drive apps for iOS is an embarrassment.

Compare Google’s subpar iPad Pro “work” to Microsoft, which was quickly ready for the iPad Pro, iOS 9 multitasking, and Apple Pencil. I’ve switched to Office 365 for my personal spreadsheets and Word documents, and, if the situation doesn’t improve, I’ll consider other solutions for collaborative docs as well.

Permalink

Inbox by Gmail to Add New Smart Reply Feature This Week

Inbox by Gmail is about to get a whole lot smarter this week with a new feature called Smart Reply. Bálint Miklós on the Official Gmail Blog explains:

Smart Reply suggests up to three responses based on the emails you get. For those emails that only need a quick response, it can take care of the thinking and save precious time spent typing. And for those emails that require a bit more thought, it gives you a jump start so you can respond right away.

The feature will be rolling out to the Inbox by Gmail app on iOS and Android later this week, but will only work in English for now. Smart Reply uses machine learning to recognize which emails need responses and then generate three appropriate responses for the user to pick from. The Google Research Blog also has some more details on how the researchers got the feature to work.

And much like how Inbox gets better when you report spam, the responses you choose (or don’t choose!) help improve future suggestions. For example, when Smart Reply was tested at Google, a common suggestion in the workplace was “I love you.” Thanks to Googler feedback, Smart Reply is now SFW :)

Permalink

Google’s App Indexing Adding Support for iOS 9 Universal Links

Google Developers, on surprisingly-it’s-still-around Google Plus:

Getting your app content found on Google just got easier. App Indexing is now compatible with HTTP deep link standards for iOS 9, as it has been on Android from the beginning. That means that you can start getting your app content into the Search results page on Safari in iOS, simply by adding Universal Links to your iOS app, then integrating with our SDK. With this improvement, we will no longer support new integrations on iOS 7 and iOS 8. Users will start seeing your app content in Safari on iOS at the end of October.

Google has additional documentation here. I’m glad they’re adding support for this relatively soon.

Permalink

Apple’s New ‘Move to iOS’ Android App

Zac Hall, writing for 9to5Mac on Apple’s first Android app to move user data to iOS:

Once you complete the selection process, the app creates a private Wi-Fi network used by both devices to wirelessly transfer content. After the transfer process is complete, Move to iOS will notify you if any content was not able to move to your new iPhone or iPad, then recommend recycling your old Android phone at a local Apple Store. After continuing the setup process on the iPhone or iPad, the settings and content should appear intact.

The process is integrated with iOS 9’s new setup flow – you get an option to import data from Android when setting up an iOS 9 device for the first time. The Android app is available here (and it’s got some…interesting customer reviews.)

Permalink