同樣是「開發一套應用程式」，Windows、macOS、iOS、Android、Web 其實是五種不同的開發問題，因為軟體最後要執行的平台不同，使用的工具、UI 設計、測試方式與發布流程也會跟著不同。這篇會先建立「目標平台」的基本地圖，再說明為什麼平台選擇本身就是軟體設計的一部分。
一、應用程式開發有哪些平台？先分清平台、工具與開發環境
很多人一開始接觸應用程式開發，很容易把「Windows」「Visual Studio」「C#」「SDK」「開發環境」全部當成同一件事在講，但這幾個詞其實回答的是完全不同的問題。
「目標平台」回答的是：軟體最後要在哪裡執行。Windows、macOS、iOS、Android、Web，都是目標平台。「開發工具」回答的是：用什麼東西把它做出來，例如 Visual Studio、Xcode、Android Studio，或是一般的程式碼編輯器。而「開發環境」則是更完整的概念，指開發者電腦上一整套工具、SDK、Runtime、設定檔與相依套件所組成的工作環境，讓程式可以被寫出來、編譯、執行與除錯。
先把這三者分開，接下來看應用程式開發常見的五大目標平台，會清楚很多。Windows 主要面向桌面軟體與企業環境，常見主力工具是 Visual Studio 等開發工具；macOS 則是 Apple 的桌面生態系，官方主線工具是 Xcode；iOS 是 iPhone、iPad 這類行動裝置，同樣以 Xcode 為主要開發工具；Android 要面對品牌與尺寸都非常多樣的裝置，官方主線是 Android Studio；Web 則比較特別，開發者用一般的程式碼編輯器寫程式，但真正的執行舞台是使用者的瀏覽器，這也是 Web 應用程式和前面四種平台最大的差異。
這五個平台各自代表不同的使用情境與限制，也各自延伸出獨立的工具鏈與開發習慣，可以先用下表建立整體印象：
| 平台 | 常見主力工具 | 典型特色 |
| --- | --- | --- |
| Windows | Visual Studio 等 | 桌面軟體、企業環境 |
| macOS | Xcode | Apple 桌面生態 |
| iOS | Xcode | iPhone／iPad 行動 App |
| Android | Android Studio | 多品牌、多尺寸裝置 |
| Web | 編輯器＋瀏覽器 | 瀏覽器跨平台 |
這張表只列出各平台最主流、最具代表性的工具與特色，不代表唯一選擇。接下來幾節，會依序把每個平台的關鍵差異說清楚，最後再回頭談「同一套應用程式，是不是一定要為每個平台重寫一次」這個實務上最常被問到的問題。
二、Windows 應用程式開發：同一個平台也有很多技術路線
很多人以為 Windows 應用程式開發等於「C# 加 Visual Studio」，但實際上 Windows 平台內部同時存在好幾條不同的技術路線，選哪一條會直接影響開發方式與後續維護。
在程式語言與框架層面，Windows 桌面應用程式常見以 C# 撰寫並建立在 .NET 之上，也可以直接用 C++（例如透過 Win32 或 C++／WinRT）開發，兩條路線的底層機制並不完全相同。UI 框架方面，微軟目前推廣的現代原生方案是 Windows App SDK 搭配 WinUI 3，同時支援 C# 與 C++ 開發，但市場上仍大量存在使用 WPF、WinForms，甚至更底層 Win32 API 開發的既有軟體與新專案。也就是說，「Windows」這一個目標平台底下，同時容納了新舊好幾種 UI 技術，開發團隊必須先決定要走哪一條路線，而不是預設只有一種寫法。除了原生技術路線，Windows 上也存在不少跨平台方案，可以讓同一份程式碼同時支援其他作業系統，這部分會留到本文最後一節整體討論原生與跨平台的取捨。
真正需要記住的重點是：平台和框架不是一對一的關係。同樣鎖定 Windows 這個平台，寫出來的應用程式可能長得完全不一樣，因為背後選的框架、語言版本、甚至目標處理器架構（例如 x64 或 ARM）都可能不同。開發者在寫 Windows 應用程式時，也需要處理桌面環境特有的操作方式，包括滑鼠、鍵盤、不同螢幕的 DPI 設定，以及近年逐漸普及的觸控輸入。等到程式開發到一定階段，還會遇到封裝與簽署的問題，這關係到應用程式最終要怎麼安裝到使用者電腦上，或是否要上架到 Microsoft Store。
這也呼應一個常被忽略的觀念：程式能在自己電腦上跑起來，不代表這套軟體已經完成部署。從寫完程式碼，到真正打包、簽署，再到讓一般使用者順利安裝與執行，中間還有一段路要走，而這段路本身就是 Windows 平台開發需要額外處理的工作。
三、macOS 應用程式開發：和 iOS 共用工具，不代表是同一個平台
Apple 的生態系統常給人一種「工具都一樣」的印象，因為 macOS 與 iOS 開發都以 Xcode 為主要開發工具，程式語言也同樣以 Swift 為主，UI 框架則常用 SwiftUI。但共用工具和共用語言，不代表 macOS 和 iOS 是同一個平台，也不代表同一份介面可以直接照搬過去。
macOS 是桌面作業系統，使用者操作應用程式時面對的是視窗、滑鼠與觸控板、實體鍵盤，還有畫面上方固定存在的選單列。這些都是桌面環境特有的互動方式，也會直接影響應用程式的介面設計。舉例來說，macOS 應用程式通常需要考慮多視窗管理、選單列上的操作項目，以及使用者習慣用鍵盤快捷鍵處理各種指令，這些都是 iOS 應用程式不太需要處理的情境。macOS 應用程式也經常需要面對桌面環境的檔案處理流程，例如開啟、儲存、匯出到不同資料夾，這和行動裝置上以 App 為中心、檔案系統相對隱藏的使用邏輯也不一樣。
也就是說，共用開發工具、共用程式語言，甚至共用部分程式碼邏輯，都不等於一個 App 可以在 macOS 和 iOS 之間直接照搬。介面配置、互動方式，甚至使用情境，都必須依照各自平台重新設計。
平台之間的差異，也會延伸到軟體最後要怎麼交到使用者手上這件事。macOS 應用程式可以透過 Mac App Store 發布，也可以透過開發者自行簽署（Developer ID）與 Apple 的公證流程（Notarization）以 App Store 之外的方式發布給使用者。這說明了平台不只是決定「軟體在哪裡執行」，也會影響「軟體要用什麼方式送到使用者手上」。相較之下，Windows 應用程式的封裝與發布邏輯又是另一套規則，這正是不同平台之間需要分別處理的其中一項差異。
四、iOS App 開發：iPhone App 不是把 Mac 軟體縮小
如果說 macOS 是桌面環境，那麼 iOS 就是完全不同性質的行動平台。有些人會誤以為 iPhone 應用程式只是把 Mac 軟體的畫面縮小塞進手機螢幕，但實際上，行動平台需要處理的問題，遠比畫面尺寸縮小複雜得多。
iOS 開發的典型流程，是在 Mac 電腦上使用 Xcode，以 Swift 搭配 SwiftUI 撰寫程式，先在 Simulator（模擬器）上測試基本功能，再拿到實機上驗證真實使用情境。開發到一定階段後，開發者通常會透過 TestFlight 讓測試使用者先行體驗，確認沒有問題後，才正式送交 App Store 上架。
這一連串流程之所以存在，是因為行動平台本身帶有桌面軟體不需要面對的限制。手機螢幕遠比電腦螢幕小，使用者主要用手指觸控操作，而不是滑鼠與鍵盤。應用程式在背景執行的方式也被系統嚴格管理，不能像桌面軟體一樣長時間占用大量資源，否則會影響裝置的電池續航力。此外，行動裝置上有一套完整的 App 生命週期管理機制，決定應用程式在什麼時候會被喚醒、暫停或關閉。權限管理也是行動平台的重要一環，舉凡讀取相機、定位、通訊錄等敏感資料，都必須先取得使用者明確授權；相較於傳統桌面應用程式，iOS 對 App 的權限與系統資源存取有更明確的沙盒與授權限制。最後，App Store 本身也有一套審核規則，決定什麼樣的應用程式可以上架、什麼內容不被允許。
這些限制加起來，說明了一件事：平台不只是決定「程式在哪裡執行」，也同時規定了「程式可以怎麼執行」。iOS 開發者必須在設計階段就把這些行動平台特有的規則考慮進去，而不是先把桌面版的邏輯寫好，之後再想辦法「塞進手機裡」。
五、Android App 開發：同一套 App 要面對更多裝置差異
如果說 iOS 的挑戰在於行動平台本身的限制，那麼 Android 面對的挑戰又更複雜一層：同一個平台內部，就存在大量不同的執行環境。
現代 Android 開發的官方主線，是使用 Android Studio 作為開發工具，以 Kotlin 作為主要程式語言，搭配 Jetpack Compose 建立使用者介面，並透過 Android SDK 存取系統功能。這套組合本身和 iOS 開發的邏輯類似：一套官方工具鏈、一套主推的程式語言與 UI 框架。但 Android 真正的教學價值，不在工具清單本身，而在於裝置生態的多樣性。
因為 Android 系統開放給眾多手機品牌採用，同一套 Android App 實際上可能要跑在手機、平板，甚至摺疊機這類特殊型態的裝置上。這些裝置的螢幕尺寸差異極大，從小尺寸手機到大尺寸平板都要能正常顯示。使用者手上安裝的 Android 版本也不會整齊劃一，新舊版本並存是常態，開發者必須決定應用程式最低要支援到哪一個 API Level，並確保功能在不同版本上都能正常運作。近年隨著大螢幕裝置與摺疊機愈來愈普及，多視窗（Multi-window）操作也成為開發者需要額外考慮的情境，也就是使用者可能同時把兩個 App 並排在螢幕上使用，應用程式的版面配置必須能夠因應。
正因為裝置與環境的多樣性遠比其他平台明顯，開發者在設計介面時，通常會採用能夠彈性因應不同螢幕尺寸的版面配置方式（Adaptive Layout），而不是針對單一裝置尺寸寫死畫面。完成開發後，應用程式主要透過 Google Play 發布給使用者。
這裡也可以回頭呼應軟體開發流程中「測試」這個階段：在自己一支手機上把 Android App 跑成功，並不能代表這套應用程式已經完成完整的測試。裝置多樣性正是 Android 平台開發時，最需要放在心上的客觀事實，而不是應該被視為缺點的「碎片化問題」。
六、Web 應用程式開發：瀏覽器本身就是執行平台
前面四個平台，不論是 Windows、macOS、iOS 還是 Android，基本上都可以簡化理解成一條路徑：應用程式安裝在作業系統上，作業系統再管理裝置本身的硬體資源，也就是「App → OS → Device」。但 Web 應用程式多了關鍵的一層：使用者不是直接在作業系統上安裝這套軟體，而是透過瀏覽器進入它，也就是「Web App → Browser → OS → Device」。
這一層差異，讓 Web 應用程式擁有其他平台少見的特性：同一套 Web App，可以從 Windows 上的 Chrome、macOS 上的 Safari、iPhone 上的 Safari，或是 Android 手機上的 Chrome 進入，不需要為每一種裝置或作業系統另外安裝一次。使用者只需要一個瀏覽器，就能使用同一套服務。
在技術組成上，Web 前端主要以 HTML、CSS、JavaScript 建立畫面與互動邏輯。如果應用程式需要處理帳號、資料儲存或比較複雜的商業邏輯，通常會再建立一層 Server／Backend，並連接 Database 儲存資料，形成「Browser → Server／Backend → Database」這樣的基本架構。前端、後端與其他服務之間，經常會透過 API 交換資料，這裡先點出這個概念，詳細的 API 運作方式留到之後的文章再展開。
Web 常被誤解成「只能做簡單網站」，但 Figma 這款設計工具，正好是打破這個刻板印象的公開案例。Figma 是一套以瀏覽器為主要執行環境（browser-based）的專業設計工具，底層採用 C++ 並透過 WebAssembly 編譯到瀏覽器中執行；渲染技術上，Figma 最初以 WebGL 處理畫面渲染，近年隨著瀏覽器支援度提升，主力渲染逐步改採效能更好的 WebGPU，並保留 WebGL 作為相容性備援。不論哪一代渲染技術，這種做法都讓原本被認為只適合跑在桌面軟體上的高複雜度繪圖與即時協作功能，得以直接在瀏覽器裡順暢執行，說明了瀏覽器本身的能力，已經足以承載相當專業、複雜度不低的應用程式，而不只是靜態網頁的容器。
七、應用程式一定只能選一個平台嗎？原生、跨平台與 Web 怎麼選
看完前面五個平台的介紹，很自然會產生一個問題：如果 Windows、Mac、iPhone、Android、Web 都想支援，是不是每一個平台都要重新寫一次程式？
答案是不一定。實務上，開發團隊通常會在三種基本策略之間做選擇。第一種是 Native（原生），針對每一個目標平台，分別採用該平台官方推薦的原生技術來開發，例如 Windows 用 WinUI 3、iOS 用 SwiftUI、Android 用 Jetpack Compose。這種做法通常較容易充分利用平台原生能力，也較容易做出貼近平台特性的使用體驗與效能最佳化，但代價是每個平台都要投入獨立的開發與維護成本。第二種是 Cross-platform（跨平台），盡可能讓同一份程式碼同時支援多個平台，但仍然需要處理平台之間無法共用的差異部分。第三種是 Web，讓瀏覽器成為主要的執行入口，好處是不需要使用者額外安裝，幾乎任何裝置都能透過瀏覽器使用。
這三種策略沒有哪一種永遠是最好的答案。真正該考慮的是：使用者主要在哪個平台上使用這套服務、是否需要深度整合作業系統的功能、是否需要離線也能運作、產品本身是不是同時有桌面版與行動版的需求、團隊能負擔的開發與維護成本、預期的發布方式，以及對效能與使用體驗的要求高低。
Spotify 是說明跨平台策略如何實際運作的一個很好的公開案例。根據 Spotify 官方在 2021 年公開的工程說明，Spotify 讓 Desktop 版與 Web Player 逐步收斂到共用同一套以 React 打造的使用者介面與大量功能程式碼，大幅減少了過去分別維護兩套介面的重複工作。桌面版透過 CEF（Chromium Embedded Framework）承載這套原本針對瀏覽器打造的 Web UI，讓同一份介面程式碼可以同時在桌面應用程式與瀏覽器中執行。但即使 UI 大量共用，登入機制、播放系統、資料來源，以及部分只有桌面版才需要的原生能力，仍然保留平台各自的實作，並透過一層 TypeScript 撰寫的 Platform API 把這些平台差異隔離開來，讓共用的 UI 程式碼不需要關心底層平台的細節差異。這正是跨平台策略的核心精神：重點不是強迫所有程式碼在每個平台上都長得一模一樣，而是找出真正可以共用的部分，把必須不同的部分留給各自的實作處理。
技術方案也不是一旦決定就永遠不變。Microsoft Teams 的架構演進，是另一個很好的參考案例。早期的 Teams（Classic Teams）採用 Electron 搭配 AngularJS 打造，隨著使用者規模擴大，微軟後續重新打造了新版 Teams，改用 React 搭配 Fluent UI，並在 Windows 端改採 WebView2 作為承載元件。這次重構的主要目的，包括提升執行效能、降低記憶體與磁碟使用量，以及改善長期的程式碼維護性。這說明了即使是大型產品，原本選定的技術架構，也可能隨著產品規模與需求成長，重新評估並調整，技術選擇從來不是一次性的決定。
選對平台，是應用程式真正落地的第一步
回到最開始的問題：軟體設計不是只有畫面配置這一件事。當一套產品決定要開發 Windows、macOS、iOS、Android 或 Web 版本的那一刻，平台本身就已經開始影響後面的開發、測試、部署與維護工作，而不是等到程式寫完才需要考慮的後續問題。而在真正動手寫程式之前，不論是人類開發者或是借助 AI 協助撰寫程式碼，都需要先確認清楚：這套產品最終要在哪裡運作、使用者會怎麼使用它，以及每個目標平台各自帶有哪些限制。把這些問題想清楚，才是讓一套應用程式真正順利落地的第一步。
