客戶提出了個問題：
「我可不可以直接用響應式設計的網頁(Responsive Web Design, RWD)，來取代App，這樣在開發成本上是不是比較省？」
這真是個好問題，而且的確是個不錯的想法！先來分析一下這之間的利弊吧~
先說優點，使用響應式設計的網頁，相較於App，至少有這些優點：
- 跨平台通用：一個網頁，可以在各種平台上直接共用，不論是電腦、iOS、Android、Window phone系統，還是手機、平板，一個設計，全盤適用，這當然是最大的優點了。
- 修改容易：修改網頁的架構、版型、美工…等，只要改好上傳到伺服器就好，使用者不用更新介面，沒有新舊版本相容的問題；同時網頁更新後立即生效，不用像App的上架，必須經過送審的機制。
- 便宜：沒錯，就是便宜。因為開發網頁可以一個工程師就搞定了，但開發多種平台的App，可能除了伺服器端的工程師之外，還要有iOS、Android工程師，也許還會需要Window phone工程師，在這麼多人力需求下，報價自然會比單一網頁來得高多了。
不過，相較於響應式網頁設計，原生App還是有它專屬的優勢(不然寫App做什麼？)，原生App至少還是有這些優點：
- 反應快： 響應式設計的網頁除非預先讀取(preview)的機制做得很好，並應用大量的ajax技術，否則在使用者操作的感受上，會覺得比原生App來得慢一點。原因在於原生App在接受到觸控操作時，會直接從行動裝置上存取資源並回應，網頁卻要透過瀏覽器執行後，再存取網路資源來回應，因此效能上會有明顯的差距。而且，即使前述的preview與ajax處理做得很好，也只能拉近網頁與原生App的操作體驗差距，仍無法完全比擬。
- 內建感測機制：行動裝置內建了GPS、重力感測等感測器(有些還可以偵測心跳、掃描指紋、感應付費…)，而這些感測器都是網頁無法存取的。雖然網頁也可以從瀏覽器取得使用者的位置，但精度仍難以與GPS抗衡。此外在不同瀏覽器與版本下，偵測使用者位置的功能還不一定有支援。
- 背景執行：App是可以背景執行的，或是透過某些背景服務觸發事件(例如時間到了要有提示聲、使用者走到某個座標附近要傳送推播…等)，但這些背景執行的功能在行動裝置的網頁上，是完全無法實作的。
其它還有許多「App能、網頁卻不能」的事(如存取使用者的連絡人資訊、使用IAP付費…等)，在此就不多著墨了。
基於以上的優缺點，在實務上是否要選用原生App，或是簡單地使用響應式網頁設計，就要看專案本身的需求了；我在某些專案裏，也曾看過客戶要求實作的App，是完全沒有必要以「App」的方式來製作的，因為這些的App實際上只是用來顯示資訊，幹嘛不做個行動版網頁就好？
那麼…有沒有折衷的辦法？當然有！
原生App是可以內嵌網頁的，若專案對於使用者體驗沒有那麼高的要求，其實可以做個原生App的框架，以內嵌網頁來呈現主要的資訊，再利用原生App可存取GPS等感測器的特性，來達成背景執行與取得使用者位置等。這樣實作的App，可以大幅精簡App工程師的開發時間，又可以發揮響應式設計的優點，一舉數得。不過仍然必須注意以下這些問題：
- 原生App為了取得行動裝置的參數(如GPS座標)，可能會頻繁地與伺服器溝通，大量的網路流量會造成行動裝置電力快速耗損。
- 網頁在App中若要有良好的整合，網頁前端工程師必須針對App內嵌的網頁，作許多優化的處理。
最後，是不是這樣就用不到App工程師了？錯！！！
這些感測器的資源存取，以及App與網頁的溝通整合，還是需要App工程師來處理的。也許人力工時可以精簡一些，但請不要誤以為可以有多大幅度的精簡。尤其若是專案需要大量存取行動裝置的感測器，那麼也許用原生App還是會好一點。