編者注：本文作者為James Clancey，他是Google音樂播放器gMusic的創始人，現擔任移動端跨平臺開發框架Xamarin的高級開發者。

　　經過了秋、春兩季的發布會后，“炒作”了大半年的AppleWatch還得等上一個多月直到4月24日才能正式發售。雖然說消費者們還在煎熬的等貨中，其實奮戰在開發第一線的碼農早都已經開工了，因為在去年11月時，蘋果就已經向開發者發放了專用于AppleWatch的開發工具WatchKit。

　　AppleWatch作為一個“戴在手腕上的小玩意兒”，它將智能可穿戴設備的功能發揮到最大，我們可以借助這可小屏幕來控制更多的事物、實現更復雜的操作。

　　當然不能把開發AppleWatchapp的工作當作“單純的是從iPhone大屏到Watch小屏的移植過程”。手機和手表的功能定位、使用場景、用戶依賴都大相徑庭，所以開發者需要一種能創新的方法來實現手表app的延展。

　　接下來我將會以我過去幾個月開發WatchKit的經驗，列出3點AppleWatch

　　1、首先你需要徹底擺脫掉iPhone的設計思路

　　AppleWatch與iPhone的開發，是兩種完全徹底不同的體驗。

　　首先AppleWatch的超迷你的屏幕（共有兩種尺寸，分別為38mm和42mm），意味著用戶在一個滿屏上基本上只能看全3—4個單詞。所以這意味著開發者不能添加臃腫冗余的文字通知消息。

　　另外你還不能依賴于UIKit。因為iPhone上的設計語言與邏輯架構在Watch上統統不適用。所以對于開發者來說，這的確需要一定的學習時間來適應習慣智能手表上全新的排版布局，來打造精簡易用的流線型AppleWatchapp。

　　2、信息呈現、交互動畫和導航菜單都需要重新的設計

　　想必許多專業的iOS開發者們對App Extensions一定不會陌生，它允許開發者提供了應用程序的“便捷入口”，更像是一種“簡略閹割版的視窗縮略。不過不要天真的以為，諸如此類的簡略信息對于Watch來說是再簡單不過了。但實際的問題是，Apple Watch使用的是全新的、自己專屬的沙盒機制，與iOS平臺的又是完全不一樣。

　　不過現有的數據庫資料中已經有不少的經驗知識，開發者們需要花上一定的時間來搞清楚如何讓框架截然不同的iPhone和AppleWatch之間，實現“大小屏的信息流動和共享”。

　　而iOS開發者們需要適應的另一個變化就是——iOSapp通常有“動畫華麗”的特點，而這一點在超迷你屏幕的AppleWatch上基本不適用了。因為考慮到屏幕的尺寸和耗電量，開發者們必須要找的更加適配的方式來進行動畫呈現，而不再是iOS的華麗酷炫風格了。

　　WatchKit的頁面導航的方式也有所變化。在iOS中，用戶可以綜合使用“滑動至下一個頁面”或者“點擊進入下一頁”兩種方式。然而WatchKit要求只能在一個app中選用其中的特定一種的導航方法，這也就是說開發者需要重新設計寫更加簡單的設計語言了。

　　Siri在AppleWatch也發揮了很大的作用。這也就意味著，開發者可以為自己的app設計一個獨一無二的語音識別信息。

　　3、并不是所有的應用都需要一個Watchapp

　　其實這個問題，每一位開發者在做項目之前都需要問自己，“在Watch的小屏幕上，將現有的iOSapp拓展到AppleWatch，當真是足夠有有價值、實用的嗎？”

　　當然，AppleWatchapp對某些應用來說是再適合不過的了。比如借助了定位功能的電燈自動開關應用，用戶可以在Watch上簡單的選擇“開燈”還是“關燈”獨兩個選項。

　　而一些需要大量文字操作、閱讀的app無疑是一個糟糕的選擇，而將它們應用到Watch上或許就是可以預見的失敗。

　　不過現在蘋果還未向開發者開放AppleWatch的心律數據以及HealthKit的相關功能。不過相信隨著日后Watch生態圈的壯大，開放API也是水到渠成的事情，沒準要不了多久我們就能用上一款音樂app，它能夠隨著我們的心律節奏播放匹配的音樂。