編注：我們希望用一萬(wàn)字的篇幅，系統(tǒng)、深度地分享有價(jià)值的內(nèi)容，讓少數(shù)派讀者可以享受獲得新知的愉悅。

【資料圖】

▍尋找靈感

靈感來(lái)源于生活。許多視頻博主都會(huì)做這樣一個(gè)挑戰(zhàn)，將地圖貼在遠(yuǎn)處的墻上，蒙著眼睛扎飛鏢。博主和觀眾約定扎到哪里就去哪里。本篇文章中，我們將以此為例，構(gòu)思一個(gè)隨機(jī)地名生成器的應(yīng)用。二可以借此講解獨(dú)立應(yīng)用開發(fā)的完整流程，幫大家梳理出一份學(xué)習(xí)指南。

明確大概想要做什么之后，接下來(lái)需要做的便是將抽象的地標(biāo)生成器概念具體化。我們會(huì)將其轉(zhuǎn)化為可執(zhí)行的應(yīng)用方案，并確認(rèn)目標(biāo)人群。開篇提到，本應(yīng)用的靈感來(lái)源于飛鏢扎中地圖上的地名，那么在手機(jī)上創(chuàng)建一個(gè)飛鏢扎地圖小游戲合適嗎？

好像也不合適，當(dāng)我們把地圖顯示出來(lái)，并給予用戶一個(gè)飛鏢時(shí)，用戶還是可以根據(jù)地圖位置判斷可能被扎中的區(qū)域。進(jìn)一步思考將其變成可行應(yīng)用的方法，可以考慮回到問(wèn)題的本源來(lái)。我們想要的無(wú)非是給用戶一個(gè)具體的、可前往的城市名稱。

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

目標(biāo)用戶 Target Audience

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

用戶畫像 Persona

在產(chǎn)品設(shè)計(jì)中，有時(shí)會(huì)進(jìn)一步描述目標(biāo)用戶中的一個(gè)明確個(gè)體，這一流程叫做制作用戶畫像。用戶畫像可以是設(shè)計(jì)中的一個(gè)理想的客戶描述。本應(yīng)用的用戶畫像則可以是一個(gè) 20 歲左右管理 Bilbili 頻道的男性、他經(jīng)營(yíng)的是一款美食探索欄目，他比較喜歡嘗試新鮮事物，看到目前比較火的隨機(jī)目的地挑戰(zhàn)，他也有興趣參與進(jìn)來(lái)，去一個(gè)未知的目的地拍一期視頻嘗試當(dāng)?shù)靥厣朗场?/p>

▍

可行性驗(yàn)證

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

網(wǎng)友 @BasilBricks 制作的樂(lè)高迪士尼城堡模型 -?Reddit

試想你在拼裝一個(gè)迪士尼樂(lè)園的樂(lè)高玩具，比如上圖所示，你會(huì)如何規(guī)劃拼裝流程呢？你也許會(huì)按照說(shuō)明書一步一步來(lái)，先完成塔尖、完成大門、最后完成城堡的安裝。城堡本體安裝完成后，雖然距離迪士尼樂(lè)園建設(shè)完成的大業(yè)還有很長(zhǎng)距離，但你已經(jīng)可以看出這一項(xiàng)目的基本雛形。

在以上的設(shè)想中，我們將具體的創(chuàng)作流程分為以下三個(gè)階段。

靈感萌芽 Ideation

基于你對(duì)生活的觀察，你可能會(huì)發(fā)現(xiàn)身邊不同領(lǐng)域存在的改進(jìn)空間。在這一階段，你可以使用不同方法來(lái)完善一個(gè)靈感，比如頭腦風(fēng)暴。

基本可行性產(chǎn)品?MVP

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

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

V代表可行的，它意味著在此階段，這些基本功能可以被一些用戶拿來(lái)進(jìn)行嘗試。程序設(shè)計(jì)者常犯的一個(gè)錯(cuò)誤便是憑空猜測(cè)，假設(shè)用戶需要這些那些的功能，并將自己所知的內(nèi)容自然而然地當(dāng)做用戶也知道。實(shí)際則不然，對(duì)于用戶來(lái)說(shuō)，他們對(duì)你的想法、理念一無(wú)所知。制作完 MVP 之后，你就可以拿著你的 MVP 去請(qǐng)用戶盲測(cè)了。你可以自己設(shè)計(jì)一個(gè)簡(jiǎn)單的問(wèn)卷，事先不作說(shuō)明。拿著 MVP 產(chǎn)品去請(qǐng)用戶盲測(cè)，之后再按設(shè)計(jì)好的問(wèn)題提問(wèn)，來(lái)驗(yàn)證用戶的使用流程是否如你預(yù)期，以及你所創(chuàng)作的產(chǎn)品是否可以滿足用戶的實(shí)際需求。

P代表有價(jià)值的成品。

不太完美的 MVP - Unsplash @markkoenig

對(duì)于樂(lè)高迪士尼樂(lè)園項(xiàng)目來(lái)說(shuō)，MVP 大概是你拼好了迪士尼城堡，把迪士尼樂(lè)園廠區(qū)的磚塊放在大板子上的時(shí)候。雖然迪士尼樂(lè)園的其他地方還很空曠，城堡本身的細(xì)節(jié)也沒(méi)有拼裝完美，但別人已經(jīng)可以由你的迪士尼城堡看出其他區(qū)域建成后的樣子。

迭代周期 Design Cycle

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

無(wú)論你是哪類人，你可能都要面對(duì)產(chǎn)品迭代的周期，來(lái)對(duì)不同功能點(diǎn)，根據(jù)反饋評(píng)估，對(duì)產(chǎn)品進(jìn)行更新，最終完善產(chǎn)品。這一流程一般來(lái)說(shuō)是一個(gè)完整的設(shè)計(jì)、思考與評(píng)估閉環(huán)。

對(duì)于應(yīng)用程序來(lái)說(shuō)，新需求可能來(lái)自你自己或用戶評(píng)論。你的用戶會(huì)提出許多他們想要的功能，你需要根據(jù)產(chǎn)品在市場(chǎng)中的定位，來(lái)決定是否采納這些功能建議。決定后，下一步便是創(chuàng)建歸類描述不同需求的待辦事項(xiàng)，并為其功能進(jìn)行設(shè)計(jì)，滿意后便可以將代碼落地并發(fā)布更新。有些開發(fā)者還會(huì)選擇諸如 A/B 測(cè)試來(lái)將同一種需求制作兩個(gè)或多個(gè)變種，并根據(jù)用戶反饋來(lái)決定哪一種進(jìn)入最終版。

▍記錄需求

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

值得注意的是，應(yīng)用程序的開發(fā)從來(lái)不是一步到位的，我的建議是將需求拆成多個(gè)可執(zhí)行條目，并制定階段性目標(biāo)。比如下圖中，我將隨機(jī)城市應(yīng)用的需求拆分，并放置在了 GTD 項(xiàng)目管理工具中，比如 Things 或 OmniPlan。在制作你自己的獨(dú)立應(yīng)用時(shí)，你也可以根據(jù)此方法歸類，并適當(dāng)調(diào)整需求排序，將最重要的需求放在前面優(yōu)先完成。

隨機(jī)城市 Things 需求 - 王禹效

核心需求

需求記錄中，你可以從 MVP 的角度來(lái)思考你的核心需求。什么是這個(gè)應(yīng)用程序最重要的部分？在隨機(jī)城市應(yīng)用中，最核心的部分便是創(chuàng)作一個(gè)翻牌的界面，來(lái)實(shí)現(xiàn)翻牌并給出隨機(jī)城市的功能?？墒沁@好像還不夠，我還希望 MVP 產(chǎn)品中用戶可以做些微的自定義，因此將切換「自己國(guó)家/全世界」的范圍選擇按鈕也加入考量。

優(yōu)化需求

我們?cè)诘芷谥薪榻B過(guò)新需求的來(lái)源。在應(yīng)用開發(fā)中，這些來(lái)源可能是一些符合基本用戶認(rèn)知的需求、幫助程序發(fā)展的本地化需求、來(lái)自你自己的主觀創(chuàng)意、應(yīng)用商業(yè)模式需要的收益需求等等。在隨機(jī)城市應(yīng)用中，我羅列的優(yōu)化需求包括一個(gè)翻牌時(shí)的延遲動(dòng)畫、翻拍期間的聲音與震動(dòng)反饋、定價(jià)方案的制定等等。

▍設(shè)計(jì)考量及 UI 框架

已經(jīng)有了需求，接下來(lái)我們便來(lái)將需求對(duì)應(yīng)的設(shè)計(jì)落地。這個(gè)應(yīng)用放在什么地方比較合適？便是對(duì)目標(biāo)設(shè)備的考量，對(duì)于一款生成隨機(jī)地名的應(yīng)用來(lái)說(shuō)，最適合的使用場(chǎng)景很可能是離手邊最近的手機(jī)，因此我們將其作為主要考慮對(duì)象。

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

Sketch 設(shè)計(jì) - 王禹效

你可能會(huì)發(fā)現(xiàn)我們這個(gè)隨機(jī)城市應(yīng)用翻牌前后界面差異巨大，這便是得益于 SwiftUI 視覺(jué)框架可靈活拼裝的特性。在 iOS 端，用作生成應(yīng)用程序界面的代碼我們稱作 UI 框架，它的目的是把設(shè)計(jì)好的產(chǎn)品原型變成應(yīng)用可以執(zhí)行的代碼。比如上圖中，我們的產(chǎn)品設(shè)計(jì)原型由 Sketch 制作而成，接下來(lái)，我們便需要將這個(gè)設(shè)計(jì)作為代碼落地。

視覺(jué)框架

在 iOS 生態(tài)系統(tǒng)中，常用的視覺(jué)框架有三種。第一種叫做 Flutter，它是由 Google 主導(dǎo)開發(fā)的 Android 與 iOS 跨平臺(tái) UI 框架，目前使用此技術(shù)的代表應(yīng)用為阿里巴巴的閑魚。Flutter 底層的語(yǔ)言是 Dart，有額外學(xué)習(xí)成本；其次是 Flutter 并非 Apple 第一方框架，因此使用中遇到的小毛病不方便獲取 Apple 官方支持，個(gè)人不太推薦。但若你感興趣，F(xiàn)lutter 描述性語(yǔ)言的特質(zhì)與本教程學(xué)習(xí)的 SwiftUI 概念類似，你可以比較容易地做知識(shí)遷移。

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

UIKit 的視覺(jué)編輯器 - 王禹效

上圖便是 UIKit 的視覺(jué)編輯器，叫做 Storyboard。顧名思義，它允許開發(fā)者將應(yīng)用程序的不同界面像制作故事板一樣，依次排開在編輯器的界面中。左側(cè)的是 UI 的大綱界面，開發(fā)者通過(guò)此面板來(lái)了解界面要素的層級(jí)關(guān)系。右下角展開的界面為自動(dòng)排版的面板。

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

聽我的描述，你可能會(huì)發(fā)現(xiàn)這個(gè)自動(dòng)排版好像沒(méi)那么自動(dòng)。事實(shí)也確實(shí)如此，自動(dòng)排版以人為給定的一系列約束條件作為運(yùn)作原理。比如某一界面元素需要以另一個(gè)界面元素為基準(zhǔn)錨定在一起，寬度不得超過(guò)多少、位置需要居中等等。它需要開發(fā)者羅列出所有規(guī)矩，自動(dòng)排版會(huì)根據(jù)這些規(guī)矩在不同設(shè)備上計(jì)算出 UI 界面的唯一解。

NSViewController - Apple Developer Documentation

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

每個(gè)視覺(jué)元素在某件事情發(fā)生時(shí)都會(huì)提供一系列狀態(tài)控制的通知函數(shù)，積少成多，一個(gè)看似普通的界面往往需要幾十個(gè)控制界面狀態(tài)的函數(shù)堆放在一起以實(shí)現(xiàn)理想的界面邏輯。這些控制函數(shù)放在一起，我們稱作 ViewController 視覺(jué)元素控制器。這一文件常常因?yàn)榭刂平缑鏍顟B(tài)的函數(shù)過(guò)多而變得非常大而被開發(fā)者戲稱為「過(guò)度肥胖」。

當(dāng)控制界面的函數(shù)過(guò)多時(shí)，就容易在開發(fā)者不注意的地方產(chǎn)生沖突，也就是程序 Bug。當(dāng)控制界面因函數(shù)過(guò)多而變得復(fù)雜時(shí)，我們便很難繼續(xù)處理好每一個(gè)界面間的關(guān)系，而需要投入大量精力來(lái)尋找原因。

難道就沒(méi)有一個(gè)更好的方法了嗎？答案是有的，這便是第三種 UI 框架 SwiftUI。SwiftUI 是 Apple 官方于 2019 年發(fā)布的最新 UI 框架，它在 UIKit 上更近了一步，不再是提供一套一致的界面來(lái)強(qiáng)行適配不同平臺(tái)，而是根據(jù)不同平臺(tái)因地制宜，在不同平臺(tái)上，用符合該平臺(tái)設(shè)計(jì)規(guī)則的方式將界面元素呈現(xiàn)出來(lái)。

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

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

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

在可預(yù)期的未來(lái)，SwiftUI 都將是 Apple 生態(tài)系統(tǒng)下的重中之重，會(huì)受到官方的最優(yōu)先的支持。基于以上優(yōu)勢(shì)，我們將在本教程中使用這一最新框架，來(lái)了解基于它的應(yīng)用構(gòu)建方式。

Apple 平臺(tái) - Apple Developer Documentation

各平臺(tái)的思考

在產(chǎn)品定位時(shí)，創(chuàng)作者需要將發(fā)布的平臺(tái)考慮進(jìn)去。具體來(lái)說(shuō)，你需要知道各平臺(tái)的優(yōu)劣與定位，并據(jù)此決定應(yīng)用是否要登陸不同平臺(tái)。

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

那么想放的各種功能應(yīng)該放在哪里呢？這時(shí)你應(yīng)該考慮 iOS 應(yīng)用。在 Apple 生態(tài)系統(tǒng)的 15 億用戶中，iPhone 用戶占大多數(shù)。因?yàn)榛鶖?shù)很大，將應(yīng)用放在這里，基本上可以確保擁有廣闊的市場(chǎng)發(fā)展空間。iPhone 擁有的傳感器最為豐富，你想實(shí)現(xiàn)的各種功能都可以把它當(dāng)作試驗(yàn)田。

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

觸摸板、鍵盤、多點(diǎn)觸控、Apple Pencil、鼠標(biāo)共同構(gòu)建了 iPad 系統(tǒng)的輸入方式。當(dāng)你對(duì)這些輸入方式進(jìn)行更多優(yōu)化時(shí)，當(dāng)你對(duì)大屏幕的體驗(yàn)進(jìn)行更多思考時(shí)，你的思考不會(huì)平白浪費(fèi)。Apple 在基礎(chǔ)框架的構(gòu)建上付出了很多努力，許多問(wèn)題你只需要解決一遍，就會(huì)發(fā)現(xiàn)這些功能在各平臺(tái)上都完成了適配，這時(shí)你優(yōu)秀的 iPad 應(yīng)用可以很平滑地變成一個(gè)同樣優(yōu)秀的 Mac 應(yīng)用。

最后要說(shuō)的，便是國(guó)人不太熟悉，但海外有一定用戶基數(shù)的平臺(tái) tvOS。Apple TV 用戶選用的屏幕往往是家中最大的那一塊，因此它在影視游戲等方面都具備獨(dú)特的先天優(yōu)勢(shì)。當(dāng)你在思考 tvOS 應(yīng)用程序時(shí)，你考量的可能是如何將最核心的內(nèi)容放在易于觀看的大屏幕上。在你做這些努力時(shí)，你會(huì)發(fā)現(xiàn)你的代碼在同一時(shí)間也完成了對(duì)使用外接顯示器用戶的適配。

▍尋找支持

在前幾個(gè)小節(jié)中，我們探討了隨機(jī)城市應(yīng)用的需求與設(shè)計(jì)，那么務(wù)實(shí)地說(shuō)，誰(shuí)能讓我們把這個(gè)應(yīng)用做下去？作為獨(dú)立開發(fā)者，這個(gè)應(yīng)用的最大助推者很大可能是你自己。作為對(duì)這個(gè)產(chǎn)品的定位、發(fā)展方向最了解的人，你要做好在沒(méi)人支持情況下持續(xù)工作一段時(shí)間的心理準(zhǔn)備。

獨(dú)立應(yīng)用開發(fā)對(duì)創(chuàng)作者多元能力的期望值較高。每個(gè)人的背景不同，強(qiáng)壓著自己所有的部分對(duì)于某些人來(lái)說(shuō)可能不現(xiàn)實(shí)，效果可能也達(dá)不到你的預(yù)期。在這種情況下，你可以選擇和你優(yōu)勢(shì)互補(bǔ)的人共同經(jīng)營(yíng)一個(gè)產(chǎn)品，發(fā)揮你的個(gè)人優(yōu)勢(shì)，并在短板處尋求幫助。在互聯(lián)網(wǎng)時(shí)代，將你最薄弱的地方直接請(qǐng)擅長(zhǎng)的人來(lái)做也不失為一種選擇。

作為獨(dú)立應(yīng)用的制作人，你不得不耐得住寂寞。前幾個(gè)月應(yīng)用程序無(wú)人問(wèn)津那是絕對(duì)正常的，獨(dú)立應(yīng)用發(fā)布初期普遍會(huì)處在一個(gè)相對(duì)薄弱的競(jìng)爭(zhēng)劣勢(shì)上，需要你持續(xù)迭代一陣子才能達(dá)到一個(gè)能打仗的水平。再者而言，市面上應(yīng)用眾多，你的獨(dú)立應(yīng)用不過(guò)是滄海一粟，用戶很大可能根本看不見(jiàn)。

Unsplash - @micheile

那么什么時(shí)候是尋找?guī)椭椭С值淖罴褧r(shí)機(jī)呢？在你的構(gòu)思流程基本完成、可以闡述你的產(chǎn)品想法時(shí)，便比較適合向了解行情的人尋求建議與支持。獨(dú)立應(yīng)用開發(fā)最大的消耗便是你個(gè)人的時(shí)間成本，當(dāng)你的產(chǎn)品在 MVP 階段時(shí)，便比較適合尋找孵化器或者天使投資人加入其中。具體如何尋找財(cái)務(wù)上的、技術(shù)上的幫助、怎么介紹你的產(chǎn)品等話題，我們會(huì)單獨(dú)開文展開。

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

▍落實(shí)代碼

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

Swift

編程時(shí)我們用什么語(yǔ)言呢？你也許已經(jīng)由 SwiftUI 的名字猜到了，我們要用的是一款名為 Swift 的編程語(yǔ)言。Swift 是一款由 Apple 在 2014 年發(fā)布的跨 Apple 生態(tài)系統(tǒng)的編程語(yǔ)言，據(jù)淘寶開發(fā)團(tuán)隊(duì)統(tǒng)計(jì)，截至 2020 年，北美市場(chǎng)近 80% 的應(yīng)用都用上了 Swift。編程語(yǔ)言就好比樂(lè)高的積木塊，是一切的基礎(chǔ)。如同我們說(shuō)話需要中文一樣，與電腦溝通時(shí)則可以使用 Swift 語(yǔ)言。

以隨機(jī)城市這款應(yīng)用的核心需求為例，我們需要一張卡片，共正反兩面。正面是一個(gè)問(wèn)號(hào)，背面是一個(gè)隨機(jī)的地名。下圖便展示了這個(gè)邏輯用 Swift 語(yǔ)言的寫法。我們創(chuàng)建了一個(gè)包含三個(gè)城市名稱的列表，從中選出一個(gè)隨機(jī)城市。當(dāng)卡牌正面向上時(shí)顯示問(wèn)號(hào)，背面向上是顯示隨機(jī)城市的名稱。

上面代碼中被標(biāo)注為粉色的文字比如 var，let，我們將這些粉色的文字稱作 Swift 語(yǔ)言的關(guān)鍵字。類似「let 什么 = 什么」的這類書寫結(jié)構(gòu)，稱作 Swift 語(yǔ)言的語(yǔ)法。在學(xué)習(xí)過(guò)程中，我們要學(xué)習(xí)和掌握的核心便是關(guān)鍵詞與語(yǔ)法結(jié)構(gòu)。若你現(xiàn)在還看不懂也沒(méi)關(guān)系，我們會(huì)在講解 Swift 語(yǔ)言的文章中具體展開。

SwiftUI

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

對(duì)于 SwiftUI 來(lái)說(shuō)，它可以理解 Swift 的語(yǔ)法，因?yàn)檫@是它的基礎(chǔ)。與此同時(shí)，SwiftUI 還具有一些專用的語(yǔ)法結(jié)構(gòu)，用來(lái)實(shí)現(xiàn) UI 界面的構(gòu)建邏輯。

上面你看到的便是將我們剛剛寫好的最核心 Swift 邏輯放入 SwiftUI 界面中的效果。對(duì)于 SwiftUI 來(lái)說(shuō)，任何我們?cè)诔绦蚪缑嫔纤吹降臇|西都屬于它的能力范疇。比如一個(gè)可滑動(dòng)的視圖，視圖中滑動(dòng)的手勢(shì)、按鈕、圖片、動(dòng)畫效果、圖片邊的陰影等等都屬其中。

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

框架

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

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

Technologies - Apple Developer Documentation

目前 Apple 放開了?233 個(gè)技術(shù)框架給開發(fā)者，以后還會(huì)更多。從這些框架的數(shù)量上你也許不難發(fā)現(xiàn)，想熟練掌握全部框架幾乎是件不可能、且沒(méi)必要的事情。你可以將這些框架看作你的知識(shí)庫(kù)，在應(yīng)用需要某個(gè)技術(shù)時(shí)，學(xué)習(xí)對(duì)應(yīng)用法即可。我們將在教程的第四章中詳細(xì)探討框架的用法。

本小節(jié)中，我們介紹了將代碼落地的三片拼圖，現(xiàn)在你大概了解了它們?cè)讵?dú)立應(yīng)用開發(fā)的過(guò)程中所處的地位。Swift 負(fù)責(zé)應(yīng)用程序邏輯，SwiftUI 負(fù)責(zé) UI 界面，系統(tǒng)框架負(fù)責(zé)提供讓創(chuàng)作者使用設(shè)備上不同功能的途徑。對(duì)于以上這些話題，我們將在教程的二三四章中對(duì)這些技術(shù)一一展開。

▍應(yīng)用上架

找到了需求，完成了設(shè)計(jì)，落實(shí)了代碼。接下來(lái)便是將應(yīng)用程序分享出去，讓這個(gè)世界分享你的創(chuàng)作喜悅。在本小節(jié)中，我們來(lái)討論應(yīng)用上架過(guò)程中你會(huì)遇到的幾個(gè)重要概念。

應(yīng)用打包

對(duì)于開發(fā)者來(lái)說(shuō)，許多工作都由 Xcode 和 App Store 代勞了，不需要額外操心應(yīng)用的分發(fā)和瘦身等。開發(fā)者需要提供一個(gè)叫做 IPA 的應(yīng)用打包文件，這個(gè)文件包含了應(yīng)用程序?yàn)椴煌O(shè)備所設(shè)計(jì)的所有美術(shù)素材、代碼等內(nèi)容，由開發(fā)者在 Xcode 中直接提交給應(yīng)用商店。

商店審核

應(yīng)用程序提交至應(yīng)用商店后，并不能直接上架。你需要等待大概 1-3 天的審核期，這個(gè)審核過(guò)程是需要 Apple 那邊商店審核人員參與的，主要負(fù)責(zé)查驗(yàn)應(yīng)用是否符合一系列規(guī)則。在此期間，你會(huì)看到應(yīng)用程序處于「待提交，待審核，審核中，被拒絕，可銷售」這幾個(gè)狀態(tài)中的一個(gè)。等到變?yōu)榭射N售時(shí)，你的應(yīng)用程序便可以在世界上的應(yīng)用商店中顯示出來(lái)，供用戶下載。

App Store Connect

這是你與 Apple 商店團(tuán)隊(duì)、以及用戶的銜接橋梁。應(yīng)用程序上架后，你可以在?App Store Connect?中做更新內(nèi)容的提交、用戶評(píng)價(jià)的反饋、銷售數(shù)據(jù)的查詢等事情。以下圖中應(yīng)用「書空」為例，你可以看到世界上哪些國(guó)家和地區(qū)的用戶在使用你的應(yīng)用、銷量、使用情況等等。我們會(huì)在第六章中展開講解這一系統(tǒng)中重要數(shù)據(jù)的意義。

書空 App Store Connect 界面 - 王禹效

應(yīng)用營(yíng)收

當(dāng)你的應(yīng)用程序開始滿足用戶需求時(shí)，用戶便會(huì)以不同方式來(lái)支持他們喜歡的應(yīng)用。常見(jiàn)的營(yíng)收選擇有一次性購(gòu)買、廣告、應(yīng)用內(nèi)購(gòu)、自動(dòng)訂閱等方案。針對(duì)應(yīng)用的屬性，你也可以自由選擇一種或多種營(yíng)收方案的組合。每種營(yíng)收方案適用于不同類型的應(yīng)用，我們會(huì)在第六章中詳細(xì)探討方案的要求與用法。

▍獲取用戶

對(duì)于隨機(jī)城市應(yīng)用，我們的目標(biāo)用戶與定位比較明確，為有出行需求的用戶提供一個(gè)驚喜的旅行地點(diǎn)。但是在應(yīng)用程序上架后，很大概率我們的應(yīng)用仍會(huì)無(wú)人問(wèn)津。那么如何獲取用戶呢？

產(chǎn)品描述

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

俗話說(shuō)「酒香不怕巷子深」，問(wèn)題是在有海量應(yīng)用程序的今天，許多用戶也許壓根聞不到你的酒香味。應(yīng)用程序的描述界面就好像餐廳進(jìn)門的裝修，有沒(méi)有用心用戶第一時(shí)間便會(huì)有明確感知，建議仔細(xì)考量。若你還想做得更好一些，可以根據(jù)用戶所在地的語(yǔ)言來(lái)定制每個(gè)地區(qū)商店頁(yè)面的顯示內(nèi)容，讓用戶感覺(jué)到開發(fā)者對(duì)當(dāng)?shù)赜脩舻那袑?shí)考慮。

廣告

為你的應(yīng)用打廣告一定會(huì)帶來(lái)流量、關(guān)注、用戶群體。但是對(duì)誰(shuí)廣告、如何優(yōu)化廣告、花多少錢廣告、在哪里廣告都是你需要思考的范疇。在我看來(lái)，決定是否使用這個(gè)廣告商的標(biāo)準(zhǔn)，便是開銷小于獲取用戶的成本。若你的應(yīng)用程序由廣告帶來(lái)的用戶收益大于實(shí)際廣告支出，則說(shuō)明你摸索出了一個(gè)針對(duì)你應(yīng)用的可行廣告方案。對(duì)于廣告優(yōu)化中常見(jiàn)的數(shù)據(jù)解讀，我們將在第六章 - 如何宣傳你的應(yīng)用中詳細(xì)展開。

多媒體渠道

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

權(quán)重優(yōu)化

產(chǎn)品在應(yīng)用商店的排位決定了產(chǎn)品的曝光量，曝光決定了有機(jī)會(huì)看到你應(yīng)用的用戶數(shù)量，用戶數(shù)量決定了你的收益，收益多少?zèng)Q定了你的應(yīng)用是否覆蓋投入，可以長(zhǎng)期做下去。而是誰(shuí)決定了你的產(chǎn)品在商店中的排位呢？這便是關(guān)鍵詞權(quán)重。

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

蟬大師 - 搜索結(jié)果

「去哪兒」可能是個(gè)非常不錯(cuò)的搜索詞，且搜索權(quán)重很高，但由于競(jìng)爭(zhēng)對(duì)手太多，新應(yīng)用使用熱門關(guān)鍵詞的排位會(huì)更低，以至于用戶根本關(guān)注不到你的應(yīng)用，還會(huì)白白消耗關(guān)鍵詞配額。建議你在考慮關(guān)鍵詞時(shí)將當(dāng)前關(guān)鍵詞下應(yīng)用總數(shù)考慮進(jìn)去，選擇與你的應(yīng)用相關(guān)，但可能獲得更高排位的相關(guān)關(guān)鍵詞中。

權(quán)重優(yōu)化是一個(gè)相對(duì)來(lái)說(shuō)需要花些時(shí)間，但回報(bào)頗豐的事情。作為獨(dú)立應(yīng)用開發(fā)者，你可以在每次應(yīng)用更新時(shí)一并更新你的關(guān)鍵詞，并記錄每次的效果。我們會(huì)在教程中單獨(dú)開篇講解關(guān)鍵詞及權(quán)重優(yōu)化。

▍更新維護(hù)

作為開發(fā)者，你會(huì)希望更多積極的評(píng)論顯示在應(yīng)用商店的評(píng)論區(qū)；對(duì)于 Bug 反饋，則更適合直接反饋給開發(fā)者，以便及時(shí)修復(fù)。開發(fā)者與用戶需要交流反饋，然而正常使用時(shí)，用戶不會(huì)有那么多去反饋的沖動(dòng)；反而是有負(fù)面體驗(yàn)時(shí)想到商店評(píng)價(jià)。那么有什么解決辦法呢，其中一個(gè)可行方案便是在恰當(dāng)?shù)臅r(shí)機(jī)提出問(wèn)題。

在某個(gè)驚喜的功能推送后，是否詢問(wèn)用戶愿意幫忙反饋來(lái)讓更多人發(fā)現(xiàn)你的應(yīng)用？在 Apple 提供的眾多技術(shù)框架中，StoreKit 負(fù)責(zé)用戶評(píng)價(jià)等事宜。你可以直接在應(yīng)用中向用戶收取商店的評(píng)分或文字反饋，也可以考慮使用不同的反饋方案，在用戶需要的時(shí)候?yàn)樗鼈兲峁┲苯幽苈?lián)系到你的方式。?

更新公告

在開發(fā)完整流程的最后，我們來(lái)討論每個(gè)開發(fā)者都會(huì)面對(duì)的應(yīng)用更新。更新的具體原因有很多，但大致目的可能為用戶提供新功能、或要修復(fù)某個(gè)應(yīng)用 Bug。

更新公告不應(yīng)該敷衍了事，因?yàn)槟愕挠脩艨赡芊?wù)的某一個(gè)小眾用戶群，這些用戶真切的關(guān)注應(yīng)用發(fā)展，而更新公告便是他們認(rèn)知你這邊更新的主要途徑。對(duì)于獨(dú)立應(yīng)用創(chuàng)作者來(lái)說(shuō)，你也可以把這些更新公告當(dāng)作對(duì)每件事的梳理。開發(fā)者需要對(duì)每一次調(diào)整用戶數(shù)據(jù)存儲(chǔ)方式的更新尤為謹(jǐn)慎，對(duì)于這些更新你需要仔細(xì)測(cè)試，確保用戶可以平滑地跨度到最新的存儲(chǔ)方案中。

▍總結(jié)

Unsplash - @jeremybishop

在本文中，我們概括性地講解了獨(dú)立應(yīng)用開發(fā)中的常見(jiàn)概念。你可以把它看作是本教程的梳理，也可以在制作自己的獨(dú)立應(yīng)用時(shí)拿出來(lái)當(dāng)做參考。

做一個(gè)應(yīng)用真的像種一朵花，在前期栽培時(shí)你可能除了辛苦付出什么也看不到，因?yàn)榉N子還深埋在泥土里，在獨(dú)立開發(fā)的流程中也適用。但這場(chǎng)歷程總是值得的，耐下心來(lái)，等待萌芽破土，花莖抬頭，花朵一點(diǎn)一點(diǎn)綻放開來(lái)。就讓我們一起開始這場(chǎng)創(chuàng)作之旅吧！

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

作者：王禹效

責(zé)編：數(shù)字工具組

關(guān)鍵詞：