編注：我們希望用一萬字的篇幅，系統、深度地分享有價值的內容，讓少數派讀者可以享受獲得新知的愉悅。

【資料圖】

▍尋找靈感

靈感來源于生活。許多視頻博主都會做這樣一個挑戰，將地圖貼在遠處的墻上，蒙著眼睛扎飛鏢。博主和觀眾約定扎到哪里就去哪里。本篇文章中，我們將以此為例，構思一個隨機地名生成器的應用。二可以借此講解獨立應用開發的完整流程，幫大家梳理出一份學習指南。

明確大概想要做什么之后，接下來需要做的便是將抽象的地標生成器概念具體化。我們會將其轉化為可執行的應用方案，并確認目標人群。開篇提到，本應用的靈感來源于飛鏢扎中地圖上的地名，那么在手機上創建一個飛鏢扎地圖小游戲合適嗎？

好像也不合適，當我們把地圖顯示出來，并給予用戶一個飛鏢時，用戶還是可以根據地圖位置判斷可能被扎中的區域。進一步思考將其變成可行應用的方法，可以考慮回到問題的本源來。我們想要的無非是給用戶一個具體的、可前往的城市名稱。

落到實處，我們可以創造一個能展示隨機城市名的界面。提供一個隨機按鈕，用戶按下后，程序直接顯示出城市名好像有些枯燥。那么用帶點賭博性質的游戲開箱子的機制如何？似乎更有娛樂性一些。我們可以將正面有隨機城市名的卡牌背面朝上，當用戶翻牌時，卡牌不會立馬反面，而是會播放一個小動畫拉高用戶期待。

目標用戶 Target Audience

大想法已定，接下來我們需要考慮目標用戶。在本應用中，我們的目標用戶是視頻博主和熱愛旅行但又不希望總被熱門目的地左右的背包客。這些潛在用戶去搜索，嘗試一款隨機地名生成器應用的可能性更大。

用戶畫像 Persona

在產品設計中，有時會進一步描述目標用戶中的一個明確個體，這一流程叫做制作用戶畫像。用戶畫像可以是設計中的一個理想的客戶描述。本應用的用戶畫像則可以是一個 20 歲左右管理 Bilbili 頻道的男性、他經營的是一款美食探索欄目，他比較喜歡嘗試新鮮事物，看到目前比較火的隨機目的地挑戰，他也有興趣參與進來，去一個未知的目的地拍一期視頻嘗試當地特色美食。

▍

可行性驗證

有了靈感之后，你是不是著急著想要開始制作了？別急，在制定具體需求前，用一個案例介紹幾個與產品相關的重要概念。

網友 @BasilBricks 制作的樂高迪士尼城堡模型 -?Reddit

試想你在拼裝一個迪士尼樂園的樂高玩具，比如上圖所示，你會如何規劃拼裝流程呢？你也許會按照說明書一步一步來，先完成塔尖、完成大門、最后完成城堡的安裝。城堡本體安裝完成后，雖然距離迪士尼樂園建設完成的大業還有很長距離，但你已經可以看出這一項目的基本雛形。

在以上的設想中，我們將具體的創作流程分為以下三個階段。

靈感萌芽 Ideation

基于你對生活的觀察，你可能會發現身邊不同領域存在的改進空間。在這一階段，你可以使用不同方法來完善一個靈感，比如頭腦風暴。

基本可行性產品?MVP

這一階段則是驗證靈感的最重要階段，MVP 的英文全稱為 Minimal Viable Product，你可以將其翻譯為最基本的可行的產品。

M代表著基本、最骨干的功能，用戶看到后會知道你在做什么。

V代表可行的，它意味著在此階段，這些基本功能可以被一些用戶拿來進行嘗試。程序設計者常犯的一個錯誤便是憑空猜測，假設用戶需要這些那些的功能，并將自己所知的內容自然而然地當做用戶也知道。實際則不然，對于用戶來說，他們對你的想法、理念一無所知。制作完 MVP 之后，你就可以拿著你的 MVP 去請用戶盲測了。你可以自己設計一個簡單的問卷，事先不作說明。拿著 MVP 產品去請用戶盲測，之后再按設計好的問題提問，來驗證用戶的使用流程是否如你預期，以及你所創作的產品是否可以滿足用戶的實際需求。

P代表有價值的成品。

不太完美的 MVP - Unsplash @markkoenig

對于樂高迪士尼樂園項目來說，MVP 大概是你拼好了迪士尼城堡，把迪士尼樂園廠區的磚塊放在大板子上的時候。雖然迪士尼樂園的其他地方還很空曠，城堡本身的細節也沒有拼裝完美，但別人已經可以由你的迪士尼城堡看出其他區域建成后的樣子。

迭代周期 Design Cycle

在不同領域中，迭代周期的概念被廣泛使用，重復推進這一循環的步驟，可以幫你更好地推進當前產品。收獲了產品反饋后，做產品的人通常會選擇兩個方向繼續前進。一類人會將 MVP 完善后直接推向市場，由市場反饋決定接下來的需求和迭代方向；另一類人會繼續坐下來完善產品，直到期望的所有功能都完成后再推向市場。

無論你是哪類人，你可能都要面對產品迭代的周期，來對不同功能點，根據反饋評估，對產品進行更新，最終完善產品。這一流程一般來說是一個完整的設計、思考與評估閉環。

對于應用程序來說，新需求可能來自你自己或用戶評論。你的用戶會提出許多他們想要的功能，你需要根據產品在市場中的定位，來決定是否采納這些功能建議。決定后，下一步便是創建歸類描述不同需求的待辦事項，并為其功能進行設計，滿意后便可以將代碼落地并發布更新。有些開發者還會選擇諸如 A/B 測試來將同一種需求制作兩個或多個變種，并根據用戶反饋來決定哪一種進入最終版。

▍記錄需求

在上一節可行性驗證中，我們使用樂高迪士尼樂園的案例，展開探討了靈感可行性驗證和產品迭代的思想。接下來將回到本文的核心案例，隨機地名生成器例中，將具體需求記錄下來。

值得注意的是，應用程序的開發從來不是一步到位的，我的建議是將需求拆成多個可執行條目，并制定階段性目標。比如下圖中，我將隨機城市應用的需求拆分，并放置在了 GTD 項目管理工具中，比如 Things 或 OmniPlan。在制作你自己的獨立應用時，你也可以根據此方法歸類，并適當調整需求排序，將最重要的需求放在前面優先完成。

隨機城市 Things 需求 - 王禹效

核心需求

需求記錄中，你可以從 MVP 的角度來思考你的核心需求。什么是這個應用程序最重要的部分？在隨機城市應用中，最核心的部分便是創作一個翻牌的界面，來實現翻牌并給出隨機城市的功能。可是這好像還不夠，我還希望 MVP 產品中用戶可以做些微的自定義，因此將切換「自己國家/全世界」的范圍選擇按鈕也加入考量。

優化需求

我們在迭代周期中介紹過新需求的來源。在應用開發中，這些來源可能是一些符合基本用戶認知的需求、幫助程序發展的本地化需求、來自你自己的主觀創意、應用商業模式需要的收益需求等等。在隨機城市應用中，我羅列的優化需求包括一個翻牌時的延遲動畫、翻拍期間的聲音與震動反饋、定價方案的制定等等。

▍設計考量及 UI 框架

已經有了需求，接下來我們便來將需求對應的設計落地。這個應用放在什么地方比較合適？便是對目標設備的考量，對于一款生成隨機地名的應用來說，最適合的使用場景很可能是離手邊最近的手機，因此我們將其作為主要考慮對象。

Apple Watch 似乎也是不錯的候選對象，且應用遷移成本較低，因此也納入考慮。初版設計如下。應用的核心部分便是生成隨機城市名的卡牌，因此占據最高的視覺權重。搜索的自定義范圍作為用戶的常用功能，被安排在了界面的下方。

Sketch 設計 - 王禹效

你可能會發現我們這個隨機城市應用翻牌前后界面差異巨大，這便是得益于 SwiftUI 視覺框架可靈活拼裝的特性。在 iOS 端，用作生成應用程序界面的代碼我們稱作 UI 框架，它的目的是把設計好的產品原型變成應用可以執行的代碼。比如上圖中，我們的產品設計原型由 Sketch 制作而成，接下來，我們便需要將這個設計作為代碼落地。

視覺框架

在 iOS 生態系統中，常用的視覺框架有三種。第一種叫做 Flutter，它是由 Google 主導開發的 Android 與 iOS 跨平臺 UI 框架，目前使用此技術的代表應用為阿里巴巴的閑魚。Flutter 底層的語言是 Dart，有額外學習成本；其次是 Flutter 并非 Apple 第一方框架，因此使用中遇到的小毛病不方便獲取 Apple 官方支持，個人不太推薦。但若你感興趣，Flutter 描述性語言的特質與本教程學習的 SwiftUI 概念類似，你可以比較容易地做知識遷移。

第二種 UI 框架叫做 UIKit，它由 Apple 官方出品，是過去十余年 iOS 界面開發的主力軍。在 UIKit 的世界中，UI 適配各種不同機型屏幕尺寸機器的技術稱作 Auto Layout 自動排版。因 UIKit 在 iOS 開發上占有特殊地位，你可能會在其它地方見到此技術的使用，我們簡單介紹下。

UIKit 的視覺編輯器 - 王禹效

上圖便是 UIKit 的視覺編輯器，叫做 Storyboard。顧名思義，它允許開發者將應用程序的不同界面像制作故事板一樣，依次排開在編輯器的界面中。左側的是 UI 的大綱界面，開發者通過此面板來了解界面要素的層級關系。右下角展開的界面為自動排版的面板。

在 UIKit 中，開發者需要明確定義各界面元素之間的邏輯關系。任何一個界面元素，你都需要明確地告知它在界面元素中的位置。比如應用中常見的分類大標題文字，你需要人為定義文本框的上邊欄錨定在距機器頂部 20px 的位置，文本框左側邊欄在距離機器左側 20px 的位置上。

聽我的描述，你可能會發現這個自動排版好像沒那么自動。事實也確實如此，自動排版以人為給定的一系列約束條件作為運作原理。比如某一界面元素需要以另一個界面元素為基準錨定在一起，寬度不得超過多少、位置需要居中等等。它需要開發者羅列出所有規矩，自動排版會根據這些規矩在不同設備上計算出 UI 界面的唯一解。

NSViewController - Apple Developer Documentation

自動排版的方案下，各界面元素互相依賴，后期想做設計調整也很麻煩，可謂牽一發動全身。明確給出各種約束條件使這些規則約束的界面實際上非常不靈活。然而消耗開發者頭發的事情到這里還沒有結束，我們不能只將界面羅列出來，而需要為界面元素添加功能。如上圖所示，界面的要素管理由許多狀態控制的函數決定。

每個視覺元素在某件事情發生時都會提供一系列狀態控制的通知函數，積少成多，一個看似普通的界面往往需要幾十個控制界面狀態的函數堆放在一起以實現理想的界面邏輯。這些控制函數放在一起，我們稱作 ViewController 視覺元素控制器。這一文件常常因為控制界面狀態的函數過多而變得非常大而被開發者戲稱為「過度肥胖」。

當控制界面的函數過多時，就容易在開發者不注意的地方產生沖突，也就是程序 Bug。當控制界面因函數過多而變得復雜時，我們便很難繼續處理好每一個界面間的關系，而需要投入大量精力來尋找原因。

難道就沒有一個更好的方法了嗎？答案是有的，這便是第三種 UI 框架 SwiftUI。SwiftUI 是 Apple 官方于 2019 年發布的最新 UI 框架，它在 UIKit 上更近了一步，不再是提供一套一致的界面來強行適配不同平臺，而是根據不同平臺因地制宜，在不同平臺上，用符合該平臺設計規則的方式將界面元素呈現出來。

還記得我之前提到的界面不夠靈活、界面狀態管理繁雜的問題嗎？SwiftUI 從根本上解決了這兩個問題。SwiftUI 不需要你明確給出每個界面具體受哪些條條框框的限制，你只需要描述出你希望的界面與其它元素的邏輯位置關系即可。

比如上圖中界面里的例子，我們希望左側有一個 Swift 的圖標，右側是一段文字描述。具體到代碼來說，我們只需要向 SwiftUI 描述：橫向排版 HStack { 圖片 Image + 文本 Text} ?即可。使用 SwiftUI 的流程更像是在和電腦對話，你將你想要的界面描述給它，至于如何顯示、間距、界面狀態等復雜事物都由電腦操心。也正因為 SwiftUI 高度靈活、可自由組合的特性，我們才可以實現隨機城市中翻牌后截然不同的兩套界面。

SwiftUI 不在乎你的背景如何，非常易學易用，且具有極佳的跨系統支持。但同時你需要認識到 SwiftUI 是一款新生框架，處在逐漸完善的過程中。比如 UIKit 所支持的 CollectionView 或者 Activity Indicator 這些成熟界面元素的替代品，SwiftUI 在 2020 年才給出以上界面的官方支持。截至 2023 年，你所需要的絕大多數功能，都已經能在 SwiftUI 上原生實現啦。

在可預期的未來，SwiftUI 都將是 Apple 生態系統下的重中之重，會受到官方的最優先的支持。基于以上優勢，我們將在本教程中使用這一最新框架，來了解基于它的應用構建方式。

Apple 平臺 - Apple Developer Documentation

各平臺的思考

在產品定位時，創作者需要將發布的平臺考慮進去。具體來說，你需要知道各平臺的優劣與定位，并據此決定應用是否要登陸不同平臺。

Apple Watch 是用戶最親密的設備，它具備一些最基本框架的支持。用戶長時間舉著胳膊并不是個很好的體驗，因此為它開發應用時，你需要將用戶與應用的交互時間，以及耗電量共同考慮進去。手表的表現力不像手機，若你強行將應用的所有核心功能放置其中，性能會被大幅打折，導致用戶不愿意使用。你的應用所提供的，應該是一個適合手表端的簡潔操作，這一操作可以是 MVP 的精華，也可以是對核心功能的補充。

那么想放的各種功能應該放在哪里呢？這時你應該考慮 iOS 應用。在 Apple 生態系統的 15 億用戶中，iPhone 用戶占大多數。因為基數很大，將應用放在這里，基本上可以確保擁有廣闊的市場發展空間。iPhone 擁有的傳感器最為豐富，你想實現的各種功能都可以把它當作試驗田。

iPad 是許多開發者忽視的設備類別。但實際上 iPad 平臺具有獨特體驗，且用戶消費意愿很高。這類設備通常能提供更高一個層級的性能，購買 iPad 的用戶常常對生產力應用有更高需求。除此之外，值得注意的還有 iPad 所具備的更大屏幕，你的應用程序如何設計才可以更好地利用這些空間？無論你的思考為何，切忌將 iOS 的應用直接照搬，原封不動的照搬很可能會導致原先精心設計的界面在大屏幕上顯得雜亂無章。

觸摸板、鍵盤、多點觸控、Apple Pencil、鼠標共同構建了 iPad 系統的輸入方式。當你對這些輸入方式進行更多優化時，當你對大屏幕的體驗進行更多思考時，你的思考不會平白浪費。Apple 在基礎框架的構建上付出了很多努力，許多問題你只需要解決一遍，就會發現這些功能在各平臺上都完成了適配，這時你優秀的 iPad 應用可以很平滑地變成一個同樣優秀的 Mac 應用。

最后要說的，便是國人不太熟悉，但海外有一定用戶基數的平臺 tvOS。Apple TV 用戶選用的屏幕往往是家中最大的那一塊，因此它在影視游戲等方面都具備獨特的先天優勢。當你在思考 tvOS 應用程序時，你考量的可能是如何將最核心的內容放在易于觀看的大屏幕上。在你做這些努力時，你會發現你的代碼在同一時間也完成了對使用外接顯示器用戶的適配。

▍尋找支持

在前幾個小節中，我們探討了隨機城市應用的需求與設計，那么務實地說，誰能讓我們把這個應用做下去？作為獨立開發者，這個應用的最大助推者很大可能是你自己。作為對這個產品的定位、發展方向最了解的人，你要做好在沒人支持情況下持續工作一段時間的心理準備。

獨立應用開發對創作者多元能力的期望值較高。每個人的背景不同，強壓著自己所有的部分對于某些人來說可能不現實，效果可能也達不到你的預期。在這種情況下，你可以選擇和你優勢互補的人共同經營一個產品，發揮你的個人優勢，并在短板處尋求幫助。在互聯網時代，將你最薄弱的地方直接請擅長的人來做也不失為一種選擇。

作為獨立應用的制作人，你不得不耐得住寂寞。前幾個月應用程序無人問津那是絕對正常的，獨立應用發布初期普遍會處在一個相對薄弱的競爭劣勢上，需要你持續迭代一陣子才能達到一個能打仗的水平。再者而言，市面上應用眾多，你的獨立應用不過是滄海一粟，用戶很大可能根本看不見。

Unsplash - @micheile

那么什么時候是尋找幫助和支持的最佳時機呢？在你的構思流程基本完成、可以闡述你的產品想法時，便比較適合向了解行情的人尋求建議與支持。獨立應用開發最大的消耗便是你個人的時間成本，當你的產品在 MVP 階段時，便比較適合尋找孵化器或者天使投資人加入其中。具體如何尋找財務上的、技術上的幫助、怎么介紹你的產品等話題，我們會單獨開文展開。

也許你的初心便是創作一款心中所想的應用，但你必須意識到，與你自身不同，外來資本的介入需要投資回報，因此你必須讓利。是否尋求外來資本的幫助與介入，需要你自己根據實際情況來做判斷。本文中我們隨機城市的例子規劃格局比較小，因此不需要額外資本的介入。

▍落實代碼

上文我們介紹了 UI 框架 SwiftUI，在代碼截圖中你可能發現了 SwiftUI 常見的，諸如 Text("文本") 這樣的寫法。在本小節中，我們將介紹獨立開發代碼落地階段最重要的三片拼圖，它們分別是 Swift、SwiftUI 和系統框架。

Swift

編程時我們用什么語言呢？你也許已經由 SwiftUI 的名字猜到了，我們要用的是一款名為 Swift 的編程語言。Swift 是一款由 Apple 在 2014 年發布的跨 Apple 生態系統的編程語言，據淘寶開發團隊統計，截至 2020 年，北美市場近 80% 的應用都用上了 Swift。編程語言就好比樂高的積木塊，是一切的基礎。如同我們說話需要中文一樣，與電腦溝通時則可以使用 Swift 語言。

以隨機城市這款應用的核心需求為例，我們需要一張卡片，共正反兩面。正面是一個問號，背面是一個隨機的地名。下圖便展示了這個邏輯用 Swift 語言的寫法。我們創建了一個包含三個城市名稱的列表，從中選出一個隨機城市。當卡牌正面向上時顯示問號，背面向上是顯示隨機城市的名稱。

上面代碼中被標注為粉色的文字比如 var，let，我們將這些粉色的文字稱作 Swift 語言的關鍵字。類似「let 什么 = 什么」的這類書寫結構，稱作 Swift 語言的語法。在學習過程中，我們要學習和掌握的核心便是關鍵詞與語法結構。若你現在還看不懂也沒關系，我們會在講解 Swift 語言的文章中具體展開。

SwiftUI

說完了 Swift，那么與它名字相似的 SwiftUI 又是什么呢？SwiftUI 是一款 DSL 語言，全稱為 domain-specific language，它具有專有語法來實現專有用途。若你將 Swift 理解為日常用語，那么 SwiftUI 便好像是一系列專業術語。它依托于日常用語，又依靠獨特詞匯提供了日常語境中不涉及的專業內容。

對于 SwiftUI 來說，它可以理解 Swift 的語法，因為這是它的基礎。與此同時，SwiftUI 還具有一些專用的語法結構，用來實現 UI 界面的構建邏輯。

上面你看到的便是將我們剛剛寫好的最核心 Swift 邏輯放入 SwiftUI 界面中的效果。對于 SwiftUI 來說，任何我們在程序界面上所看到的東西都屬于它的能力范疇。比如一個可滑動的視圖，視圖中滑動的手勢、按鈕、圖片、動畫效果、圖片邊的陰影等等都屬其中。

將 Swift 帶來的邏輯與 SwiftUI 帶來的 UI 界面相組合，我們便得到了此應用程序的核心功能。上圖中代碼的運行效果如下。

框架

在代碼落地的討論范疇中，我們還缺最后一片拼圖，這便是系統框架。那么什么是系統框架呢？系統框架也被 Apple 官方列在科技列表中，它代表的是一系列設備本身所具備的硬件能力。這些能力經 Apple 工程師之手規整好，之后將更容易理解，可直接使用的函數直接開放給開發者，便形成了框架。這些框架可以由創作者根據自身需求自由選用。

框架的涉及范圍也非常廣泛，比如負責云數據同步的 CloudKit 框架、負責 AR 交互的 ARKit 框架、負責異步事件處理的 Combine 框架等等。以隨機城市中我們想在翻牌時用到的觸覺反饋為例，我們需要使用的便是這些技術框架中的 Core Haptics 框架。這一框架允許我們自定義手機的振動方式，并像錄制音頻一樣準備好一段非常獨特的震動反饋。

Technologies - Apple Developer Documentation

目前 Apple 放開了?233 個技術框架給開發者，以后還會更多。從這些框架的數量上你也許不難發現，想熟練掌握全部框架幾乎是件不可能、且沒必要的事情。你可以將這些框架看作你的知識庫，在應用需要某個技術時，學習對應用法即可。我們將在教程的第四章中詳細探討框架的用法。

本小節中，我們介紹了將代碼落地的三片拼圖，現在你大概了解了它們在獨立應用開發的過程中所處的地位。Swift 負責應用程序邏輯，SwiftUI 負責 UI 界面，系統框架負責提供讓創作者使用設備上不同功能的途徑。對于以上這些話題，我們將在教程的二三四章中對這些技術一一展開。

▍應用上架

找到了需求，完成了設計，落實了代碼。接下來便是將應用程序分享出去，讓這個世界分享你的創作喜悅。在本小節中，我們來討論應用上架過程中你會遇到的幾個重要概念。

應用打包

對于開發者來說，許多工作都由 Xcode 和 App Store 代勞了，不需要額外操心應用的分發和瘦身等。開發者需要提供一個叫做 IPA 的應用打包文件，這個文件包含了應用程序為不同設備所設計的所有美術素材、代碼等內容，由開發者在 Xcode 中直接提交給應用商店。

商店審核

應用程序提交至應用商店后，并不能直接上架。你需要等待大概 1-3 天的審核期，這個審核過程是需要 Apple 那邊商店審核人員參與的，主要負責查驗應用是否符合一系列規則。在此期間，你會看到應用程序處于「待提交，待審核，審核中，被拒絕，可銷售」這幾個狀態中的一個。等到變為可銷售時，你的應用程序便可以在世界上的應用商店中顯示出來，供用戶下載。

App Store Connect

這是你與 Apple 商店團隊、以及用戶的銜接橋梁。應用程序上架后，你可以在?App Store Connect?中做更新內容的提交、用戶評價的反饋、銷售數據的查詢等事情。以下圖中應用「書空」為例，你可以看到世界上哪些國家和地區的用戶在使用你的應用、銷量、使用情況等等。我們會在第六章中展開講解這一系統中重要數據的意義。

書空 App Store Connect 界面 - 王禹效

應用營收

當你的應用程序開始滿足用戶需求時，用戶便會以不同方式來支持他們喜歡的應用。常見的營收選擇有一次性購買、廣告、應用內購、自動訂閱等方案。針對應用的屬性，你也可以自由選擇一種或多種營收方案的組合。每種營收方案適用于不同類型的應用，我們會在第六章中詳細探討方案的要求與用法。

▍獲取用戶

對于隨機城市應用，我們的目標用戶與定位比較明確，為有出行需求的用戶提供一個驚喜的旅行地點。但是在應用程序上架后，很大概率我們的應用仍會無人問津。那么如何獲取用戶呢？

產品描述

用戶見到你產品的第一印象便是在應用商店中瀏覽，因此你的產品描述必須展示出應用亮點。開發者常忽略對宣傳文字、截圖及視頻的琢磨，而這恰恰是用戶決定是否下載的關鍵時刻。如下圖所示，你會發現每個應用最多可以有 3 個視頻宣傳和 10 張截圖。取決于你的應用功能多少，建議最少提供 1 個視頻及 4 張以上的截圖。

俗話說「酒香不怕巷子深」，問題是在有海量應用程序的今天，許多用戶也許壓根聞不到你的酒香味。應用程序的描述界面就好像餐廳進門的裝修，有沒有用心用戶第一時間便會有明確感知，建議仔細考量。若你還想做得更好一些，可以根據用戶所在地的語言來定制每個地區商店頁面的顯示內容，讓用戶感覺到開發者對當地用戶的切實考慮。

廣告

為你的應用打廣告一定會帶來流量、關注、用戶群體。但是對誰廣告、如何優化廣告、花多少錢廣告、在哪里廣告都是你需要思考的范疇。在我看來，決定是否使用這個廣告商的標準，便是開銷小于獲取用戶的成本。若你的應用程序由廣告帶來的用戶收益大于實際廣告支出，則說明你摸索出了一個針對你應用的可行廣告方案。對于廣告優化中常見的數據解讀，我們將在第六章 - 如何宣傳你的應用中詳細展開。

多媒體渠道

用戶獲得信息的方式早已不局限于廣告。仔細想想，上一次你裝某個新東西時，是不是某個人和你說「哎那個不錯，要不你去試試？」當你的應用成熟時，你可以考慮除傳統廣告商之外的其他途徑，比如網站媒體、視頻博主等渠道宣傳。市場上有非常多的人在做這些工作，也愿意與獨立開發者建立互助關系。

權重優化

產品在應用商店的排位決定了產品的曝光量，曝光決定了有機會看到你應用的用戶數量，用戶數量決定了你的收益，收益多少決定了你的應用是否覆蓋投入，可以長期做下去。而是誰決定了你的產品在商店中的排位呢？這便是關鍵詞權重。

那么什么又是關鍵詞呢？這便是與你的應用程序相關，用戶可能搜索的詞匯。你可以通過許多途徑來判斷目前使用的關鍵詞是否可以為你帶來用戶。以隨機城市為例，我們需要考量的不僅是應用程序名，還有用戶用來搜索的方式。

蟬大師 - 搜索結果

「去哪兒」可能是個非常不錯的搜索詞，且搜索權重很高，但由于競爭對手太多，新應用使用熱門關鍵詞的排位會更低，以至于用戶根本關注不到你的應用，還會白白消耗關鍵詞配額。建議你在考慮關鍵詞時將當前關鍵詞下應用總數考慮進去，選擇與你的應用相關，但可能獲得更高排位的相關關鍵詞中。

權重優化是一個相對來說需要花些時間，但回報頗豐的事情。作為獨立應用開發者，你可以在每次應用更新時一并更新你的關鍵詞，并記錄每次的效果。我們會在教程中單獨開篇講解關鍵詞及權重優化。

▍更新維護

作為開發者，你會希望更多積極的評論顯示在應用商店的評論區；對于 Bug 反饋，則更適合直接反饋給開發者，以便及時修復。開發者與用戶需要交流反饋，然而正常使用時，用戶不會有那么多去反饋的沖動；反而是有負面體驗時想到商店評價。那么有什么解決辦法呢，其中一個可行方案便是在恰當的時機提出問題。

在某個驚喜的功能推送后，是否詢問用戶愿意幫忙反饋來讓更多人發現你的應用？在 Apple 提供的眾多技術框架中，StoreKit 負責用戶評價等事宜。你可以直接在應用中向用戶收取商店的評分或文字反饋，也可以考慮使用不同的反饋方案，在用戶需要的時候為它們提供直接能聯系到你的方式。?

更新公告

在開發完整流程的最后，我們來討論每個開發者都會面對的應用更新。更新的具體原因有很多，但大致目的可能為用戶提供新功能、或要修復某個應用 Bug。

更新公告不應該敷衍了事，因為你的用戶可能服務的某一個小眾用戶群，這些用戶真切的關注應用發展，而更新公告便是他們認知你這邊更新的主要途徑。對于獨立應用創作者來說，你也可以把這些更新公告當作對每件事的梳理。開發者需要對每一次調整用戶數據存儲方式的更新尤為謹慎，對于這些更新你需要仔細測試，確保用戶可以平滑地跨度到最新的存儲方案中。

▍總結

Unsplash - @jeremybishop

在本文中，我們概括性地講解了獨立應用開發中的常見概念。你可以把它看作是本教程的梳理，也可以在制作自己的獨立應用時拿出來當做參考。

做一個應用真的像種一朵花，在前期栽培時你可能除了辛苦付出什么也看不到，因為種子還深埋在泥土里，在獨立開發的流程中也適用。但這場歷程總是值得的，耐下心來，等待萌芽破土，花莖抬頭，花朵一點一點綻放開來。就讓我們一起開始這場創作之旅吧！

https://sspai.com/post/76333?utm_source=wechat&utm_medium=social

作者：王禹效

責編：數字工具組

關鍵詞：