この記事は iOS 版 Chrome、ソフトウェア エンジニア、Gauthier Ambard による Chromium Blog の記事 "Changing the Chrome on iOS User Agent for Request Desktop Site" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。


 iOS 版 Chrome は、ユーザーがリクエストするサイトの種類により、2 つの異なる User-Agent 文字列を送信します。

M84 以前では、PC 版サイトをリクエストするオプションを選択したときに送信される User-Agent 文字列は、デスクトップ版 Safari が使う文字列と一致していました。

Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_5) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/11.1.1 Safari/605.1.15

M85 以降では、PC 版サイトをリクエストするオプションを選択したときに送信される User-Agent 文字列が CriOS/<MajorVersion> タグを含むように変更されます。

Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_5) AppleWebKit/605.1.15 (KHTML, like Gecko) CriOS/85 Version/11.1.1 Safari/605.1.15

これにより、モバイル版のサイトをリクエストしたときに使われるデフォルトの User-Agent 文字列との一貫性が向上します。モバイル版のサイトをリクエストした場合に送信される User-Agent 文字列は変わりません。Version/<VersionNum> の代わりに CriOS/<ChromeRevision> となるだけで、その他は Mobile Safari のユーザー エージェントと一致します。

Mozilla/5.0 (iPhone; CPU iPhone OS 10_3 like Mac OS X) AppleWebKit/602.1.50 (KHTML, like Gecko) CriOS/56.0.2924.75 Mobile/14E5239e Safari/602.1

この変更の目的は、デベロッパーが iOS 版の Chrome と Safari の違いを考慮してユーザー エクスペリエンスを調整できるようにすることです。今回の変更で PC 版の User-Agent 文字列に情報が追加されることになりますが、User Agent ヘッダーにブラウザ名とメジャー バージョンを入れることは、Chrome のユーザー エージェント情報削減計画の目的にも合致しています。



Reviewed by Eiji Kitamura - Developer Relations Team

この記事は 上流釣り師、Rohit Rao による Chromium Blog の記事 "Open-sourcing Chrome on iOS!" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

これまで、Chrome for iOS のコードは、他のプラットフォームにはない複雑さがあることから、他の Chromium プロジェクトとは別に管理されてきました。そして何年も慎重にリファクタリングを重ねてきた結果、すべてのコードが Chromium に再結合され、オープンソース レポジトリに移す作業が行われています。

iOS プラットフォームの制約により、すべてのブラウザは WebKit レンダリング エンジン上に構築する必要があります。Chromium にとって、これは WebKit と他のプラットフォームで使われている Chrome のレンダリング エンジンである Blink の両方をサポートしなければならないことを意味します。これによって複雑さが増すことになりますが、私たちはそれを Chromium のコードベースに配置することは避けたいと考えました。

Chrome のオープンソース化という約束を守るため、これまでの数年間、Chrome for iOS のコードを Chromium に統合するために必要な変更を行ってきました。そして本日（翻訳当時）その作業が完了し、デベロッパーの皆さんは、他のバージョンの Chromium と同じように iOS 版の Chromium をコンパイルできるようになったことをお知らせします。Chrome for iOS のすべてのテストが Chromium コミュニティ全体で利用可能になり、コードがチェックインされるたびに自動的に実行されるようになったため、開発のスピードも速まります。

私たちは、オープンソース コミュニティやコントリビューターのみなさまを尊重しています。そこにようやく Chrome for iOS が加わったことを嬉しく思っています。


Posted by Eiji Kitamura - Developer Relations Team

[この記事は Jake Leichtling、Physical Web 調査担当による Chromium Blog の記事 "Exploring the Physical Web with Chrome for iOS" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]

インターネットに接続されている現在の世界では、人々と瞬時に電子的なやりとりをする方法が数多く存在します。たとえば、高度なパーキング メーターではクラウドを介して支払いをすることができます。ただし、開発者にとっては、人々が簡単にアクセスできるコンテクスチュアルなエクスペリエンスの構築は容易ではありません。スマートフォンが普及した現在でも、ユーザーは外出中にアプリのインストールをしたり URL の入力をしたがらないという傾向があります。

Physical Web は、ユーザーが抵抗なく使用できるコンテクスチュアルなインタラクションを構築するために役立つオープン ソース アプローチです。数か月前、Chrome for iOS に Today ウィジェットが追加され、ユーザーが新しいタブを開いたり、通知センターから直接音声検索を実行したりできるようになりました。 また、新しい Chrome for iOS では Physical Web が Chrome Today ウィジェットに統合され、ユーザーが自分に関係のある Web コンテンツのオンデマンド リストにアクセスできるようになりました。
先日発表されたオープン Bluetooth Low Energy ビーコン フォーマットである Eddystone を使用した Physical Web により、コンテンツを検索可能にすることが容易になりました。Eddystone では、各種のユースケースのために複数のフレーム タイプがサポートされます。Physical Web は、圧縮された URL を表示するために設計されたビーコン フレーム タイプの Eddystone-URL を使用し、ブロードキャストされるコンテンツを表示します。コンテンツを Physical Web に追加するには、Eddystone-URL をサポートするビーコンを設定して、選択した URL を送信するだけです。

Physical Web を有効にしているユーザーが Today ビューを開くと、Chrome ウィジェットがブロードキャストされた URL をスキャンしてその結果を表示し、ビーコンとの距離を推測してコンテンツをランク付けします。Physical Web によって実現されるユーザー エクスペリエンスをより詳しく知りたい場合は、Google の Cookbook にアクセスし、GitHub のオープン ソース コミュニティに参加してください。

新しい Chrome for iOS は、ユーザーの日々のモバイル エクスペリンスに、Physical Web へのアクセスを追加するための最初の試みといえます。エコシステムの拡充に伴い、 Google は Physical Web を ユーザーの手元に届ける新しい方法を模索し続けます。みなさんの開発した新しいコンテクスチュアル エクスペリエンスに出会える日を楽しみにしています。

Posted by Eiji Kitamura - Developer Relations Team