In its latest update, Google Chrome for iOS has added a native Read Later feature to quickly save articles for later consumption. From the app’s release notes:
If you find an interesting article that you want to read later, tap the Share icon and then Read Later to add the page to your Reading List. Articles on your Reading List are saved on your device so you can read them wherever you are, even when you aren’t connected to the web.
Although the release notes mention tapping the Share icon to save articles, I’ve found the quicker way to be long-pressing a link, which presents a menu that contains the ‘Read Later’ option.
In testing the offline functionality, I discovered that Chrome will not save a webpage’s full formatting for offline viewing; instead, it stores a stripped down version of the page. All of the necessary content, including images, is still preserved, but the viewing experience is not as pleasant as that of other read-later services.
Overall, although there’s nothing particularly interesting or innovative about the way Read Later works, it’s still a nice feature addition for Chrome users.
Yesterday, Benjamin Mayo reported that Apple published public webpages for “some landmarks and points of interest” listed in Maps:
Apple is now publishing public web pages for landmarks and POI in its Apple Maps database: here’s one such place. The website link shows details about the place such as location, name, telephone number and reviews. The design is identical to the cards in the iOS 10 Maps app.
When on an Apple platform, these URLs appear to act as deep links into the native Maps app. If viewing in Chrome or on a non-Apple device like Android, the fallback webpage is loaded. The purpose for these URLs is unclear, but it may possibly foreshadow a larger move by Apple to offer its own online mapping service to compete with Google Maps on the web.
I did a bit of digging, and I discovered that you can open any Apple Maps place or address in another web browser if you reformat the URL properly.
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.
Chrome for iOS has been updated today with support for Physical Web, an initiative aimed at interacting with beacons based on the new Eddystone protocol through webpages instead of apps. Now, Chrome’s Today widget on iOS (previously used to open tabs and voice searches) can scan beacons broadcasting URLs nearby and offer to open them in Chrome directly.
From the blog post:
When users who have enabled the Physical Web open the Today view, the Chrome widget scans for broadcasted URLs and displays these results, using estimated proximity of the beacons to rank the content. You can learn more about the types of user experiences that the Physical Web enables by visiting our cookbook and joining the open source community on GitHub.
This is Google’s attempt at improving upon one of the biggest shortcomings of Apple’s iBeacon: app discoverability. iBeacons can achieve great utility if an associated/compatible app is already installed on a user’s device and sends a notification, but iOS doesn’t have a simple, consistent way to browse nearby beacons and start interacting with them right away. With Eddystone and Physical Web, Google is hoping that the transition from OS to discovered beacon and beacon functionality (for the smart device) can be smoother thanks to the web. Here’s how they explain it:
The Physical Web is an approach to unleash the core superpower of the web: interaction on demand. People should be able to walk up to any smart device - a vending machine, a poster, a toy, a bus stop, a rental car - and not have to download an app first. Everything should be just a tap away.
Essentially, Google wants to give every smart device a web address that doesn’t require an app store. This plays in favor of Google’s strengths and, potentially, core business model, but it also sounds like a superior solution for some cases if the overhead of app discovery is out of the equation altogether (for more on the differences between iBeacon and Physical Web, see this). The Physical Web implementation in Chrome for iOS looks clever and well done, and I’m hoping that I’ll get to play with it at some point. Seems crazy that all this is available in an iOS widget.
Kevin C. Tofel, writing for Gigaom:
Google’s strategy to use the Chrome browser as a desktop replacement took another step forward on Friday. Users of Chrome Canary, an experimental version of Google’s browser, can now associate Mac files with supporting Chrome apps in the Finder. This means that instead of opening a basic text file with the native OS X TextEdit, you can open it with a Chrome app like Text, Caret or Simple Text.
Interesting move from Google, but not a surprise either. Google has been building an ecosystem of apps on iOS for over a year, and it’s only obvious that they’re going to continue extending the effort to OS X, where they have even less limitations.
On iOS, they redirect YouTube links to the YouTube app, leverage x-callback-url for Chrome, and make sure you always use Google apps when opening links; on OS X, the Finder’s “Open With” menu makes perfect sense to redirect users to Chrome – especially for Office-type documents.
As The Omni Group keeps working on OmniFocus 2 for Mac and Apple continues seeding new betas of iOS 7 and OS X Mavericks to developers, I have been reconsidering Reminders’ simplicity and enjoying the built-in iCloud sync, which, unlike other types of iCloud, is working fine for me. However, two things I miss from OmniFocus are the possibility to integrate the app with a web browser through bookmarklets and the system-wide Quick Entry panel; I use both tools on a daily basis to easily save a browser’s tab into OmniFocus’ Inbox, or to bring up a text field where I can jot down an idea and know that, no matter the app I’m using, it’ll be saved into OmniFocus. Luckily for me, Apple’s Reminders app comes with a good AppleScript Dictionary, which is likely something that Reminders’ core mainstream audience won’t ever care about, but that we can leverage to extend the app’s capabilities and input areas beyond Mountain Lion’s leather-and-paper window.
Pending an official announcement from Google, Google Chrome for iOS now contains the previously announced voice improvements that lets you search the web without typing out a single letter. Covering the extra row of keys that used to present themselves as you typed, a floating bar replaces the previous voice button from the omnibox. Tapping it brings up a microphone where you can speak your query, and depending on the question, Google will read the answer back to you (for example, ask it what time it is in Italy). Just like Google Search, Chrome will read back the text to you as you speak, and the results feel nearly instant.
You can download Chrome for iOS from the App Store.
I recently got annoyed by the fact that Google Chrome couldn’t open iTunes links in the iTunes app on my Mac, so I decided to look for a solution.
I haven’t been following Chrome’s (numerous) updates in quite a while, so I don’t remember when the app got a redesigned Settings page. In spite of the cleaner look, though, there’s still an option to manage “protocol handlers”, which are the settings that determine how Chrome should work with webpages that request to open other applications installed on a computer, such as Apple’s iTunes Preview website and iTunes. Read more
Released earlier today, Google Chrome for iOS has been updated with built-in Messages sharing and a new menu to access previously-visited webpages.
Available from the Share menu in the top toolbar, Messages integration brings up a modal Messages window to send a webpage’s title and URL to someone else. This is a good addition – I’ve long relied on bookmarklets and third-party apps to forward Chrome links to Messages – but unfortunately one I’ll make little use of, as iOS doesn’t let you quickly address a message to a pre-defined group of contacts.1
I find the new History menu much more interesting for my daily Chrome workflow. Similarly to Safari, you can now tap & hold the Back/Forward buttons to show a list of websites you have navigated to; tapping on one will take you back to that page. Like Apple’s implementation, this is a per-tab history; unlike Safari, the list of pages is shown in a dropdown menu rather than a full-screen modal view (on iPhone).