廠商搶攻龐大的智慧型手機應用程式服務商機的同時，卻會面臨該開發原生或網路行動應用程式的抉擇。原生行動應用程式受到蘋果iPhone大力鼓吹，建立更高標的使用者經驗；而網路應用程式則具備成本優勢，如何選擇端視各廠商業務目標，以及對使用者使用習慣的調查。
大多數的企業會同時提供網路(Web-based)與原生(Native)行動應用程式服務，決定的因素包括使用經驗品質、應用程式的複雜度、目標平台、成本、靈活度與風險。
目前的網路技術與架構，包括HTML5，皆有助提高行動網路應用程式的範圍與豐富性，但不會取代原生碼(Native Code)。
打算提供消費者行動服務的客戶經常詢問可否發展精簡型(網路)或原生行動應用程式。
本文中，將網路應用程式定義為在行動裝置上透過瀏覽器使用的軟體；原生應用程式則定義為從網路商店下載安裝到行動裝置上的軟體(表1)。
業務目標/使用習慣為關鍵
研發原生或網路行動應用程式的任何決策，皆須取決於業務目標和顧客使用習慣。
業務目標提供重要決策資訊，如顧客身分、解決方案的預期壽命、可接受的風險程度與成本限制等。不見得每次都能訂出全面與量化的行動業務目標，但即使是不甚完全的目標亦有益做出決策。
行動服務的目標客群會影響技術的選擇，尤其是在20112012年，許多客戶尚未擁有智慧型手機。了解高價值顧客的使用裝置和習慣非常重要，若可能，應先調查顧客使用的手機類型及是否使用行動網路或下載行動程式。
原生應用程式使用經驗品質較佳
原生應用程式的主要優勢之一是提供最好的使用經驗。原生應用程式可讀取感應器，如全球衛星定位系統(GPS)衛星導航系統與加速度計(Accelerometer)，並可使用複雜的繪圖、觸控螢幕與手勢、提供先進的視覺效果，如擴增實境(Augmented Reality)。未來可期待HTML提供更多這類的功能，如同原生應用程式可滿足最佳使用經驗。
Android、蘋果(Apple)iOS、Symbian和RIM等行動作業系統(OS)演變迅速，每年都推出一款以上的新平台。新增的應用程式介面(API)可增加新平台功能與雲端服務，如導航、情境、網路商店支付與行動商務。行動作業系統演變將超過HTML標準演進的速度，因此原生應用程式可使用更進階的功能。情境式行動應用程式須即時監控使用者行為並主動發出通知，此動作須取得裝置代碼，因此不適合透過網路進行。
網路應用程式具成本優勢
了解應用程式的使用者數量對成本效益分析相當重要。能執行動態轉換的行動網路工具可支援絕大多數的手機，包括功能型手機(Feature Phone)，甚至智慧型手機專屬網站可以服務的用戶數，遠比單一原生應用程式版本還多。在許多情況下，程式設計師必須在用戶規模和使用經驗中擇一選擇。
行動網路應用程式的每位用戶成本較低，因為只要花一次費用，便可支援許多裝置，因此目標客群是鎖定一般的大眾。原生應用程式的成本則會隨著複雜度而變化，目標客群通常較為少數，如特定平台用戶。隨著智慧型手機的普及化，成本結構也將有所變動。
另外，行動網路應用程式較具彈性，可以在伺服器上直接變更程式和立即發布。原生應用程式較不具彈性的原因包括，其通常是透過網路商店提供，申請與審核流程需數週才能完成，一旦提供新版的應用程式後，使用者必須進行安裝，舊版可持續使用一段時間，以及若須支援多平台，原生應用程式的開發和測試流程較為複雜和緩慢。
網路應用程式技術/商業風險較低
原生應用程式涉及的技術風險比網路應用程式高，因為開發的過程較複雜、風險較大，甚至測試本身就很複雜。如觸控螢幕、衛星導航系統和加速度計等涉及使用者經驗的應用，不同的平台或許須開發多種應用程式版本。
一些行動網路程式轉換工具(Mobile Web Adaptation Tools)是由發展完善且在業界擁有良好聲譽的公司所提供，因此，要找到商業風險低的工具及供應商是有可能的。不需額外開發工具的行動網路程式，可能承受的風險甚至更低。
使用多平台開發工具的原生應用程式，若是創新但規模較小的供應商，開發風險通常較高。企業得在以下兩者中做困難的抉擇，一種是安全、但費用相對較高的方式，如使用原生軟體開發工具包(SDK)與工具開發不同的應用程式版本。另一種是速度較快、費用較低，但風險較高的方式，如使用小型供應商的多平台開發工具。在評估供應商風險之際，企業不僅要考量供應商未來生存的可能性，也須評估其支援能力。
網路狀況影響網路應用程式效能
行動網路應用程式通常須要搭配好的手機網路或無線區域網路(Wi-Fi)訊號，因此企業須了解消費者使用情境。採用原生或網路應用程式還需要其他操作上的配套，如手機的電池壽命等，另一常見的問題是網路效能，原生應用程式可被寫入以除去許多網路效能變數，但有些網路應用程式會隨著網路的品質造成效能上的差異。
行動網路的安全性相對較佳，係因留在行動裝置的資料通常很少或完全沒有，不過安全或驗證的選項數量通常少於原生代碼，原生應用程式可支援更廣的安全策略。
多數情況下，支援網路應用程式較容易，因為客戶端裝置較不容易出錯。原生應用程式的支援部分則較為複雜，尤其是支援Android等較不完整平台時。不過，隨著網路應用程式複雜化，使用客戶端代碼(Client-side Code)開發比重越來越高，支援情況將變得越來越複雜，兩者的差異將縮小。
以消費性應用程式為例，假設一個競爭對手推出原生應用程式，多數行動網路應用程式便相形見絀，即使都提供相同的功能。蘋果(Apple)iPhone等部分平台鼓勵開發商開發原生應用程式，以使用更多的平台應用程式介面。這為使用者期待設下高標準，讓網路應用程式變得較不具競爭力。
不過，開發原生應用程式比開發行動網路應用程式需要更進階的技術，主要是因為工具市場高度分散，這類技術較為缺乏。
行動網路應用程式開發方式
不同的行動網路應用程式開發方式，造就不同的應用程式特色，以下將一一說明。
| ‧ |
|
| |
用於創造行動網路應用程式的開發工具，須投注大量的資金與努力，才能開發出適用於行動裝置的高品質產品；此類型的部分工具能同時開發網路與原生應用程式。 |
| ‧ |
|
| |
有助開發商創造更複雜、客戶端應用程式，有時可使用部分底層的平台API。 |
| ‧ |
|
| |
這類工具根據不同裝置的需求，利用現有網路或入口網站動態轉換內容或網站架構。特色是能夠快速部署，但品質不如專為手機用戶優化的應用程式。 |
| ‧ |
|
| |
搭載先進HTML瀏覽器的智慧型手機，可以讀取傳統網站的頁面，只要內含vanilla HTML，以及不支援Flash和外插式裝置等功能即可。假使能知道使用此類裝置的用戶數量，就可以利用現有工具創造一個網站，為手機用戶提供小型、簡單的網頁服務。 |
| ‧ |
|
| |
亦即假設用戶會用自己的手機去讀取現有的網站，所以無須進行任何程式開發。雖然是免費的，但這種瀏覽方式不太能提供令人滿意的使用經驗。 |
原生應用程式開發方式
與行動網路應用程式開發方式相同，不同的開發方式，亦會發展出不同的原生應用程式，以下介紹原生應用程式開發方式。
| ‧ |
|
| |
提供最深度的整合與最豐富的功能，但僅限於單一平台。 |
| ‧ |
|
| |
可支援一種以上的行動平台，不過，「寫入一次便可到處執行」的目標仍處於想像階段，因為犧牲讓步無法避免。亦即有些工具提供行動裝置共通的API，但會讓單一來源應用程式犧牲掉某些特定平台功能，因此無法開發出能與原生軟體開發工具相互競爭的應用程式。有些工具可以讓開發人員呼叫原生平台的API創造更具競爭力的應用程式，但條件是須要支援各應用程式的多種變數。不過，目前大部分的多平台開發工具尚未能支援全部的智慧型手機平台。 |
| ‧ |
|
| |
用於開發特定應用程式的工具，如零售商店前端使用的應用程式，雖然不具普遍性但有助提高生產力。 |
| ‧ |
|
| |
行動Java近幾年較不流行，因為太過分散，且像原生代碼般複雜，無法提供原始API功能或多種平台工具。不過，行動Java適用於絕大多數的手機，包括許多功能手機，因此對新興市場很重要。 |
值得注意的是，過去24個月來，可看到小型供應商推出許多新的多平台工具，相較於知名的供應商，小型供應商推出的工具可能會帶來更高的商業風險。
HTML5不會取代原生應用程式
HTML5為行動瀏覽器應用程式帶來許多進步，包括更高階的JavaScript、支援離線應用程式、部分手機服務，如衛星定位、更先進的繪圖軟體和影音服務，以及資料可永遠儲存在瀏覽器內的功能，有助開發商在日後推出更高階、使用性更高，以及可某種程度離線操作的應用程式。相對地，這會模糊網路和原生應用程式之間的區隔；不過從手機的角度來看，HTML5並非可攜式產品的萬靈妙丹。
這是由於HTML還沒有定義清楚。目前不是所有的行動瀏覽器都可支援HTML5。即使在HTML5裝置推出後，以手機平均壽命只有18～24個月的情況下，用戶若不定期更新手機操作系統，就無法使用HTML5的功能。
此外，許多功能手機並不完全支援HTML5，且使用HTML5標準並不代表就能使用許多平台的API來開發進階手機應用程式，例如感測器、付款功能、行事曆與進階地理定位等。Gartner預估JavaScript程式碼和標準會逐漸運用在這些領域上，但會耗時多年，也僅能用於作業系統應用程式介面的一小部分。
另外，某些多平台工具開始將HTML5發展為一種功能產生程式碼(Code-generation)，以提供原生碼或HTML5作為輸出格式的選項。
(本文作者為Gartner副總裁)