2015 年 9 月，Apple 重磅發(fā)布了全新的 iPhone 6s/6s Plus、iPad Pro 與全新的操作系統(tǒng) watchOS 2 與 tvOS 9（是的，這貨居然是第 9 版），加上已經(jīng)發(fā)布的 iOS 9，它們都為前端世界帶來了哪些變化呢？作為一個 web 開發(fā)者，是時候站在我們的角度來說一說了！
注！該譯文存在大量英文術(shù)語，筆者將默認(rèn)讀者知曉 ES6、viewport、native app、webview 等常用前端術(shù)語，并不對這些已知術(shù)語進(jìn)行漢語翻譯 對于新發(fā)布或較新的產(chǎn)品名稱與技術(shù)術(shù)語，諸如 Apple Pen、Split View 等專有名詞，筆者將在文中使用其英文名，但會嘗試對部分名詞進(jìn)行漢語標(biāo)注 另外，出于對 wiki 式閱讀的偏愛，筆者為您添加了很多額外的鏈接，方便您查閱文檔或出處
簡而言之
如果你不想閱讀整篇文章，這里為你準(zhǔn)備了一個總結(jié)：
新的設(shè)備特性
iPhone 6s 與 6s Plus 擁有“3D Touch”，這是一個全新的硬件特性，它可以偵測壓力，是一個可以讓你拿到手指壓力數(shù)據(jù)的 API
iPad Pro 的 viewport 為 1024px，與以往的 iPad 全都不同
想在 iPad Pro 上支持新的 Apple Pen？不好意思，目前似乎并沒有適用于網(wǎng)站的 API
新的操作系統(tǒng)特性（與 web 相關(guān)的）
iPad 上的 Safari 現(xiàn)在可以通過Split View（分屏視圖）與其他應(yīng)用一起使用，這意味著新的 viewport 尺寸將會越來越常見
新的 Safari View Controller（SFSafariViewController）可以讓你在 native app 內(nèi)提供與 Safari 界面、行為連貫一致的應(yīng)用內(nèi)網(wǎng)頁瀏覽體驗(yàn)
注意啦！Safari 新加入了 Content Blocker（內(nèi)容攔截器）。以后，并不是所有的訪問都一定會出現(xiàn)在你的 Google Analytics 了
Universal Links可以讓應(yīng)用的擁有者在 iOS 內(nèi)部“占有”自己的域名。因此，訪問 yourdomain.com 將會打開你的應(yīng)用（類似 Android 的 Intents 機(jī)制）
App Search（應(yīng)用搜索）：現(xiàn)在，Apple 將會抓取你的網(wǎng)頁內(nèi)容（與 native app 內(nèi)容）用于 Spotlight 與 Siri 的搜索結(jié)果，想知道你的標(biāo)簽都兼容嗎？
你的網(wǎng)站現(xiàn)在可以通過 JavaScript API 訪問 iCloud 的用戶數(shù)據(jù)
新的 API 支持
Performance Timing API在 iOS 9 得到回歸
關(guān)于 HTML5 Video，你現(xiàn)在可以在支持Picture in Picture（畫中畫）的 iPad 設(shè)備上提供這項(xiàng)新功能；你的視頻甚至可以在 Safari 關(guān)閉后繼續(xù)播放
更好的 ES6 支持：classes（類）, computed properties（可計(jì)算屬性）, template literals（模版字符串）等
Backdrop CSS filters（背景濾鏡）
CSS @supports 與 CSS Supports JavaScript API
CSS Level4 偽選擇器
用于支持分頁內(nèi)容的 CSS Scroll Snapping
WKWebView 現(xiàn)在可以訪問本地文件了
我們?nèi)匀恍枰却?Push Notification，camera access，Service Workers 這些現(xiàn)代 web API 的到來
新的操作系統(tǒng)
新一代 Apple TV 的tvOS： 沒有瀏覽器，也沒有 webview。但是 JavaScript、XHR 和 DOM 可以通過一個叫做 TVML 的標(biāo)記語言來使用
Apple Watch 的watchOS：完全沒有任何瀏覽器和 webview
再注！由于原文寫于 Apple 發(fā)布會之前，為了不讓讀者感到奇怪，筆者將會對文章進(jìn)行適當(dāng)改寫與補(bǔ)充，以保證本文的連貫性
新的 iOS 設(shè)備特性
iPhones 6s 與 3D Touch
從 web 設(shè)計(jì)與開發(fā)的角度來說，新的 iPhone 6s 與 6s Plus 與之前的版本并沒有太多差別。不過，有一個特性注定會吸引我們的目光：3D Touch
我們無法確定 Apple 是不是只是重命名了一下 “Force Touch”（用于 Apple Watch、TrackPad 2 與最新的 MacBook 上）或者 3D Touch 的確是一個為 iPhone 定制的似曾相識卻不同的東西。3D Touch 允許操作系統(tǒng)和應(yīng)用偵測每一個手指與屏幕接觸時的壓力。從用戶體驗(yàn)的角度來說，最大的變化莫過于當(dāng)你用點(diǎn)力去觸碰或者拖拽屏幕時，操作系統(tǒng)將會觸發(fā)諸如 peek，pop 這些新機(jī)制。那么問題來了：我們是否能夠在網(wǎng)站中使用這個新玩意呢？讓我們一點(diǎn)點(diǎn)來看：
iOS 9 搭載的 Safari 包含了一些用于 “Force Touch” 的新 API，但它們其實(shí)并不是那個用于 iPhone 6s 3D Touch 的 API。你可以理解為這些 API 就是 MacBook 版 Safari 里為 Force Touch 準(zhǔn)備的那些 API ，因?yàn)楣蚕硪惶?codebase，所以它理所當(dāng)然得存在了 iOS 版里而已。
Force Touch API 為我們添加了兩個新東西：
你的 click 事件處理函數(shù)將會從 MouseEvent 中收到一個新的屬性：webkitForce
DOM 也新增了四個事件：(webkit)mouseforcewillbegin，mouseforcedown，mouseforceup與mouseforcechange。下邊的示意圖將告訴你這些事件是在何時被觸發(fā)的：
相信你已經(jīng)從它們的名字中意識到了，這些事件都是基于鼠標(biāo)而非觸摸的，畢竟它們是為 MacBook 設(shè)計(jì)的。并且，TouchEvent 也并沒有包含webkitForce這個屬性，它僅僅存在于 MouseEvent 里。在 iOS Safari 里，你確實(shí)可以找到onwebkitmouseforce這一系列事件處理器，但是很可惜它們并不會被觸發(fā)，click 返回的 MouseEvent 也永遠(yuǎn)只能得到一個webkitForce: 0
可喜可賀的是，故事還沒有結(jié)束。Touch Events v2 draft spec（觸摸事件第二版草案）中正式添加了force屬性。3D Touch 也得以在 iPhone 6s 與 6s+ 中通過 TouchEvent 訪問到。不過，筆者也要在這里提醒大家，由于沒有webkitmouseforcechange這樣給力的事件，在手機(jī)上我們只能通過輪詢 TouchEvent 的做法來不斷檢測壓力值的改變……非常坑爹
@Marcel Freinbichler第一個在 Twitter 上曬出了自己的Demo。在 6s 或 new Macbook 的 Safari（目前僅 Safari 支持）上訪問就可以看到圓圈會隨著壓力放大。墻內(nèi)的小伙伴可以試試訪問Forcify，體驗(yàn)下 3D/Force Touch 帶來的的奇妙體驗(yàn)。
如果你不巧在用不支持 3D/Force Touch 的設(shè)備，發(fā)現(xiàn)尼瑪用力按下去之后居然圓圈也有反映！？
放心，這真的不是你的設(shè)備突然習(xí)得了“感應(yīng)壓力”這項(xiàng)技能，而是因?yàn)?a target="_blank" rel="nofollow">Forcify是一個用于在所有設(shè)備上 polyfill 3D/Force Touch API 的 JS 庫……它不但封裝了 OSX/iOS 兩個平臺之間 API 的差異，還使用"長按"來模擬了force值的變化……
iPad Pro
全新的 iPad Pro（12.9 寸）打破了以往 iPad 渲染網(wǎng)站的方式。在此之前，市面上所有的 iPad（從初代 iPad，到 iPad Air 4，到 iPad Mini）都是以 768px 的寬度提供 viewport。
而屏幕更大的 iPad Pro 選擇了寬 1024px 的 viewport，這使得它天生就能容納更多的內(nèi)容。不少人說iPad Pro 就是抄 Microsft Surface Pro 的嘛……嗯哼，IE/Edge 在 Surface Pro 上就是以 1024px 作為視口寬度的……
從交互的角度上來說，iPad Pro 雖然不支持 3D Touch，但是可以搭配 Smart Keyboard 與/或 Apple Pen（帶有壓力偵測）使用。對于鍵盤其實(shí)并沒有什么好說的，如果一個網(wǎng)站在搭配鍵盤的桌面電腦上好用，它在 iPad Pro 上應(yīng)該也不賴。而對于 Apple Pen，很可惜，目前似乎并沒有 API 能讓你在網(wǎng)站上獲得這根筆的壓力與角度。
新的 iOS 操作系統(tǒng)特性
iPad 上的多任務(wù)處理
自 iOS 9 起，iPad 允許兩個應(yīng)用在同一時刻并肩執(zhí)行，有三種方式：Slide Over，Split View與Picture-in-Picture。不過，每一種方式都有其硬件需求，比如說 Slide Over 需要 iPad Air, iPad Mini 2 以上的設(shè)備，而 Split View 由于對內(nèi)存的要求目前只支持 iPad Air 2 與 iPad Pro。
Slide Over（滑過來！）
Slide Over 支持的 App 并不多，不過 Safari 名列其中，這意味著我們的網(wǎng)站將可能在這個模式下被渲染。當(dāng)網(wǎng)站處于 Slide Over 模式下時，它將在屏幕的右 1/4 位置渲染，并且置于其他 native app 之上。
這個模式也為 Responsive Web Design（響應(yīng)式網(wǎng)站設(shè)計(jì)）提出了新的挑戰(zhàn)：一個只為 iPad 優(yōu)化的網(wǎng)站，也需要能在該設(shè)備上以無需手動刷新的形式支持小屏幕的渲染。因此，如果你正在使用服務(wù)器端探測（RESS），那么你的 iPad 版本需要以某種方式包含手機(jī)版本的網(wǎng)站，或者在進(jìn)入該模式后重新加載一次。（如果你不了解 RESS，你可以觀看我的另一篇博文）
在這個模式下，無論橫屏還是豎屏，所有的 iPad（包括 Pro）都會把你的網(wǎng)站以 320px 的 viewport 寬度進(jìn)行渲染，就好像在一個大 iPhone 5 上一樣。你可以在 CSS 中通過 media query（媒體查詢）探測到這個模式：
/* iPad Air or iPad Mini */(device-width:768px)and(width:320px)/* iPad Pro */(device-width:1024px)and(width:320px)
Split View（分屏視圖）
在較新版本的 iPad 上，你可以將 Slide Over 的 Side View（側(cè)視圖）升級為 Split View。此時，兩個應(yīng)用將以相同比例在你的屏幕上同時工作。
在這個模式下，我們的網(wǎng)站將可能……
以屏幕 1/3 比例渲染時，viewport 在 iPad Air/mini 猶如 iPhone 5，寬 320px。而在 iPad Pro 上則像是 iPhone 6：寬 375px
以屏幕 1/2 比例渲染時，viewport 在 iPad Air/mini 上呈現(xiàn)為 507px 寬，而在 iPad Pro（橫屏）下呈現(xiàn)為 678px 寬
以屏幕 2/3 比例渲染時，viewport 在 iPad Air/mini 上呈現(xiàn)為 694px 寬，而在 iPad Pro（橫屏）下呈現(xiàn)為 981px 寬
Picture in Picture（畫中畫）
在一些較新版本的 iPad 上，使用 HTML5 video 標(biāo)簽的網(wǎng)站可以將其暴露到 Picture in Picture 機(jī)制中。通過 API（本文稍后會講）或用戶的觸發(fā)，視頻可以獨(dú)立于網(wǎng)站在其他應(yīng)用的上方繼續(xù)播放。
iOS 9 下的響應(yīng)式網(wǎng)頁設(shè)計(jì)
下圖向你展示了 iOS 9 所有可能的 viewport 尺寸，檢查檢查你的響應(yīng)式斷點(diǎn)都包含它們了嗎？
Safari View Controller
如果你用過 Twitter 或者 Facebook（或者微信，微博……），那么你一定知道很多 native app 在打開一個網(wǎng)頁鏈接時并不會默認(rèn)使用 Safari。它們試圖讓你留在它們的應(yīng)用里，所以通過提供 webview 讓你在應(yīng)用內(nèi)進(jìn)行網(wǎng)頁瀏覽。可是問題在于，這類 webview 并不會與瀏覽器共享 cookies，sessions，autofill（自動填充）與 bookmark（書簽），為了解決這些問題，就有了 Safari View Controller。
現(xiàn)在，native app 可以使用 Safari View Controller 來打開網(wǎng)站，它提供與 Safari 完全一致的隱私政策、local storage，cookies、sessions 同時讓用戶留在你的 app 中，它通過一個 “Done”（完成）按鈕使用戶可以回到 native app 的上一個 controller。這個全新的 controller 還可以讓我們在 Share（分享）按鈕上添加自定義的操作，這些操作在用戶使用 Safari 應(yīng)用時并不會出現(xiàn)。同時，native app 對這個自定義 Safari 實(shí)例具有完全的內(nèi)容控制，你可以屏蔽不想被渲染的內(nèi)容。
當(dāng)你需要基于 web 的鑒權(quán)，比如 OAuth 時，使用 Safari View Controller 同樣是一個好主意，這樣就不再需要打開瀏覽器再重定向回你的應(yīng)用。不過注意了，Safari View Controller 只適用于在線、公開的 web 內(nèi)容。如果你的 web 內(nèi)容假設(shè)在本地或者私服，那么 WKWebView 仍然是最推薦的選擇。
筆者八卦一下，Safari View Controller 實(shí)際上也算是半個社區(qū)推進(jìn)的產(chǎn)物。早在 2014 年 12 月，Tumblr 的 iOS 工程師 Bryan 就發(fā)表了一篇著名的We need a “Safari view controller”敘述現(xiàn)有 webview 在第三方登錄鑒權(quán)時的窘境。 2015 年 6 月，Apple Safari 工程師 Ricky Mondello 的 Twitter 宣告了這個設(shè)想的落地：You all asked for it. Come see me introduce it. Introducing Safari View Controller 1:30 PM, Tuesday. Nob Hill.
Safari Content Blockers
現(xiàn)在，iOS 9 上的 Safari 支持一種全新的 App Extensions（應(yīng)用拓展）：Content Blocker（內(nèi)容攔截器）。這類拓展以 native app 的形式存在，你可以在 App Store 上下載到，它們可以攔截 Safari 內(nèi)的任何內(nèi)容，包括：跟蹤器、廣告、自定義字體、大圖片、JavaScript 文件等等。
作為 web 開發(fā)者，盡管我們不能禁用 Content Blocker，我們?nèi)匀粦?yīng)該注意到它們的存在。諸如 Crystal 的一些攔截器宣稱他們可以提高網(wǎng)頁的打開速度。Crystal 聲稱可以加快網(wǎng)頁的加載速度 3.9 倍并且少用 53% 的帶寬。不過問題是：到底哪些東西被攔截器攔截了？這篇文章提到了一些我們未來可能會遇到的問題。
在 iOS 9 發(fā)布后，Peace，一個 Content Blocker，曾在 App Store 排名躋身前十。從用戶的角度來說，如果一個網(wǎng)站由于被 Content Blocker 攔截了某些重要資源而不能正常工作，你可以長按重新加載按鈕并且以不啟用 Content Blocker 的方式重新加載這個網(wǎng)站（見下圖，來自 MacWorld.com）
Content Blocker 能隱藏元素，也有能力通過 CSS 選擇器、域名、類型、或者 URL 來過濾并攔截某個文件的加載，Purify Blocker給用戶提供了攔截某一種內(nèi)容類型的進(jìn)階選項(xiàng)，比如 Web Fonts。
WKWebView 的增強(qiáng)
UIWebView 已經(jīng)被官方棄用，雖然它還在在那，不過它再也不會得到什么升級。與此相反，WKWebView 正在取代它的位置。一個最受期待的特性現(xiàn)在終于推出：加載本地文件到 WKWebView。因此，現(xiàn)在 Apache Cordova 應(yīng)用與其他 web 內(nèi)容都可以直接從 iOS 包中使用本地文件了，不再需要各種詭異的 hack 了。
此外，還有一些新特性也一并推出。比如說，通過 WKWebsiteDataStore，Objective-C 或 Swift 有能力查詢與管理 webview 的本地存儲（比如 localStorage 或 IndexedDB）。這就允許我們將原有的數(shù)據(jù)存儲替換成新的某些東西，比如說替換成一個不永久的（Chrome for iOS 的隱身模式就需要這種東西）
Universal Links（通用鏈接）
如果你既有一個網(wǎng)站，又有一個 native app，你現(xiàn)在可以通過 Universal Links 來增強(qiáng)用戶體驗(yàn)。它允許你在操作系統(tǒng)內(nèi)“占有”自己的域名，這樣，一切指向你網(wǎng)站的鏈接都會被重定向到你的 app。
目前，所有的 app 都是通過自定義 URI 來達(dá)到這個效果的，比如comgooglemaps://就可以用來從網(wǎng)站或者其他原生 iOS 應(yīng)用中打開 Google Maps。
想要提供這個特性的話，你首先需要在 native app 中實(shí)現(xiàn) Deep Linking（深度鏈接），讓應(yīng)用中的內(nèi)容與 Safari 的 URL 吻合。然后，你需要在 Apple 的網(wǎng)站上關(guān)聯(lián)你的域名，取得這個域名的 SSL 認(rèn)證并且把簽名后的 JSON 部署到該域名上。這是為了防止第三方的應(yīng)用“占據(jù)”了屬于你而不屬于他們的域名，比如說 twitter.com 被非 Twitter 的其他應(yīng)用占據(jù)掉。
目前唯一的缺點(diǎn)是用戶好像并不能決定到底以哪種方式來打開內(nèi)容（使用 web 還是 app），不過我們可以觀望一段時間看看它會如何發(fā)展。在不遠(yuǎn)的這段時間里，你可能會發(fā)現(xiàn)在網(wǎng)站或 Google 搜索里點(diǎn)擊一個鏈接時會沒有任何預(yù)警的就跳進(jìn)了 native app 里。
App Search（應(yīng)用搜索）
Apple 帶著自己的 web 蜘蛛殺進(jìn)了搜索的市場，而我們需要支持它得以在 Siri 與 Spotlight 中提升自己的曝光率。這在我們同時擁有網(wǎng)站與 app 時尤為重要，因?yàn)楝F(xiàn)在 Apple 會索引你網(wǎng)站的內(nèi)容，但打開時卻可能將用戶帶到了 app 里去。
盡管這會開啟 SEO 的新篇章，不過卻相當(dāng)容易。你需要使用一些標(biāo)簽標(biāo)準(zhǔn)，諸如Web Schema、AppLinks、OpenGraph或者Twitter Cards，配合上 App Banner 與app-argument，如果你有你自己的 native app 的話。
關(guān)于“讓你的網(wǎng)頁支持 Apple 搜索”的更多詳情，請查閱 Apple 官方文檔Mark Up Web Content
Apple 剛剛發(fā)布了一個App Search Validation Tool（應(yīng)用搜索驗(yàn)證工具）來幫助你搞清楚，需要向你的網(wǎng)站添加什么才能支持 App Search
CloudKit JS
如果你擁有一個 native app，你很可能會將用戶數(shù)據(jù)保存在 iCloud 上。在過去，只有 iOS 與 Mac 應(yīng)用被允許使用它。現(xiàn)在，通過 CloudKit JS，你的網(wǎng)站也可以連接上 iCloud 數(shù)據(jù)了。
Back Button
現(xiàn)在，當(dāng)你鏈接到一個 native app 時（通過自定義 URI 或者 Universal Link），Safari 會詢問用戶是否想要使用 native app 打開這個鏈接（見下圖）。如果用戶同意了，這個應(yīng)用將被打開，并且在左上角會有一個返回按鈕可以返回 Safari ，返回到你的網(wǎng)站。
新的 API 支持
Navigation Timing API
Navigation Timing API 在 iOS 9 迎來了回歸。讓我們回憶一下，這貨添加于 8.0 卻在一周后的 8.1 中去掉了。這對于 Web 性能是個好消息。通過這個 API，我們可以更精確的測量時間，還可以獲得一系列有關(guān)加載過程的時間戳，它們對于追蹤與在真實(shí)場景中做決策來改進(jìn)用戶體驗(yàn)都非常有用。
Picture in Picture
PiP API（被稱為 Presentation Mode API）目前只支持 iOS，它允許我們手動讓一個元素進(jìn)入或離開 PiP 模式如果video.webkitSupportsPresentationMode是支持的。
舉個例子，我們可以在內(nèi)嵌模式與 PiP 模式中切換：
video.webkitSetPresentationMode(video.webkitPresentationMode==="picture-in-picture"?"inline":"picture-in-picture");
我們還可以通過新的onwebkitpresentationmodechanged事件來檢測 Presentation Mode（展示模式）的變化。
Backdrop CSS
iOS 7 與最近的 Mac OS 使用 Backdrop filter（背景濾鏡）來模糊背景（指 native 開發(fā)），而在網(wǎng)站上實(shí)現(xiàn)這個卻并不容易。
iOS 9 上的 Safari 現(xiàn)在支持了來自 Filter Effect v2 spec（濾鏡特效第二版規(guī)范）的backdrop-filter。比如說，我們可以使用一個半透明的背景并且對其背后的
header{background-color:rgba(255,255,255,0.4);-webkit-backdrop-filter:blur(5px);backdrop-filter:blur(5px);}
CSS Scroll Snapping
在 web 上實(shí)現(xiàn)分頁內(nèi)容（比如相冊跑馬燈）總是非常麻煩，無論是使用 JavaScript 框架、touch 事件還是 hacking 滾動條等等。Apple 新添加了一個很贊的 CSS 特性叫做 CSS Scroll Snapping。這個特性新增了一系列的 CSS 屬性讓你定義規(guī)則或者不規(guī)則的 snap zone（停留區(qū)域），這樣滾動的位置就會“啪”地一下停在這個區(qū)域，而非像以前一樣可以停在任何地方。
來看個例子：
#photo-gallery{width:100%;overflow-x:scroll;-webkit-scroll-snap-points-x:repeat(100%);-webkit-scroll-snap-type:mandatory;}
想要看個跑起來后的例子？筆者為大家準(zhǔn)備了 webkit 的官方demo，不過這個屬性目前只支持 iOS 9 Safari 哦，并不支持 webview
CSS Supports
CSS Supports，包括 CSS@supports與來自 CSS Conditional Rules Module Level 3 spec 的 JavaScript CSS Supports API 都在 iOS 上迎來降臨。現(xiàn)在，我們可以針對某個 CSS 屬性的特定值的支持情況來編寫代碼：
@supports(-webkit-scroll-snap-type:mandatory){/* we use it */}
同樣，使用 JavaScript：
if(CSS.supports("-webkit-scroll-snap-type","mandatory")){}
一些細(xì)微的改進(jìn)
ECMAScript 6 的更完善支持：classed、computed properties、template literial 與 week sets
新的 CSS Level4 偽類/元素選擇器：:not、:matches、:any-link、:placeholder-shown、:read-write、:read-only
Native app 現(xiàn)在可以通過 extension 來向 Safari 的 Shared Links（分享鏈接）窗口上注入信息
大量無前綴 CSS 屬性的支持（終于），比如 transition、animation、@keyframes、flex 與 columns
Mac OS El Capitán 上的 Safari 9 提供了一個全新設(shè)計(jì)的 Web Inspector（Web 檢查器）。幸運(yùn)的是，iOS 9 的遠(yuǎn)程調(diào)試完全兼容 Mac OS 上的 Safari 8，所以你倒是不用急著升級你的 Mac OS
iOS 9 通過-apple-font加入了一些 Dynamic Fonts（動態(tài)字體），并且它們現(xiàn)在應(yīng)用的是 Apple 的新字體：San Francisco，筆者的博客就已經(jīng)用上它啦
scrollingElement 現(xiàn)在可用了
現(xiàn)在允許你從 iCloud Drive 與已安裝的第三方應(yīng)用，比如 Google Drive 中選擇文件
當(dāng)你加載一個 HTTPS 協(xié)議的頁面時，你不能混用 HTTP 與 HTTPS 的資源
Bugs
Bug 通常都要在幾周之后才會顯露出來，我也會持續(xù)跟進(jìn)并更新這篇文章。目前為止，我的發(fā)現(xiàn)如下：
對于 Home Screen webapps（添加至主屏的 web 應(yīng)用），apple-mobile-web-app-status-bar-style這個 meta 標(biāo)簽不起作用了！所以你現(xiàn)在不能再像過去一樣使用black-translucent讓你的 webapp 渲染在狀態(tài)欄的后面了。
Speech Synthesis API （語音綜合 API）不再工作了
仍在等待……
當(dāng) Mac 上的 Safari、桌面電腦與 Android 上的 Chrome 都已經(jīng)為網(wǎng)站支持 Push Notification （通知推送）時，iOS 上的 Safari 仍然不支持這個特性。就 API 而言，我們?nèi)匀粵]有：WebRTC、getUserMedia、Service Worker、FileSystem API、Network Information API、Battery Status API、Vibration API 等等……你又在 iOS 上等待哪些特性呢？
watchOS 與 tvOS
新發(fā)布的 watchOS 2.0 與 tvOS 9.0 都是基于 iOS 的操作系統(tǒng)，它們針對特定的設(shè)備發(fā)行（Apple Watch 與新的 Apple TV）。從用戶的角度來說，那里并沒有瀏覽器了。從開發(fā)者的角度，那里也沒有 Webview 了。
盡管有不少人抱怨（大部分都是針對 webview 的缺失），我并不能確定這是不是個壞主意。我猜測 Apple 會嘗試通過 Siri 來將 “web” 帶給 TV、手表、甚至 CarPlay 的用戶。所以，如果你遵循了上述的 “App Search” 的步驟，你的內(nèi)容將可能通過 Siri 在這些設(shè)備上以 widget（小部件）或者快捷回復(fù)的形式變得可以訪問。
對于 Apple TV ，它支持使用 JavaScript、DOM API 與 XMLHttpRequest 來讓我們構(gòu)建某種類似 Client-Server webapp 的東西。沒有 HTML 和 CSS，這是什么把戲？其實(shí)它支持的叫 TVML，是一種基于 XML、為那些可以被渲染在 TV 屏幕上的特定內(nèi)容而優(yōu)化后的標(biāo)簽。這些標(biāo)簽只可以在來自應(yīng)用商店的 native app 中渲染，但是這些 TVML 是由服務(wù)器端來生成的。
著作權(quán)聲明
