編注：我們希望用一萬(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)用戶是視頻博主和熱愛旅行但又不希望總被熱門目的地左右的背包客。這些潛在用戶去搜索，嘗試一款隨機(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ù)最高的視覺權(quán)重。搜索的自定義范圍作為用戶的常用功能，被安排在了界面的下方。

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

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

視覺框架

在 iOS 生態(tài)系統(tǒng)中，常用的視覺框架有三種。第一種叫做 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ì)在其它地方見到此技術(shù)的使用，我們簡(jiǎn)單介紹下。

UIKit 的視覺編輯器 - 王禹效

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

在 UIKit 中，開發(fā)者需要明確定義各界面元素之間的邏輯關(guān)系。任何一個(gè)界面元素，你都需要明確地告知它在界面元素中的位置。比如應(yīng)用中常見的分類大標(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è)視覺元素在某件事情發(fā)生時(shí)都會(huì)提供一系列狀態(tài)控制的通知函數(shù)，積少成多，一個(gè)看似普通的界面往往需要幾十個(gè)控制界面狀態(tài)的函數(shù)堆放在一起以實(shí)現(xiàn)理想的界面邏輯。這些控制函數(shù)放在一起，我們稱作 ViewController 視覺元素控制器。這一文件常常因?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ò)是滄海一粟，用戶很大可能根本看不見。

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 常見的，諸如 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í)用到的觸覺反饋為例，我們需要使用的便是這些技術(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)用。常見的營(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)品描述

用戶見到你產(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)容，讓用戶感覺到開發(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)化中常見的數(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ā)中的常見概念。你可以把它看作是本教程的梳理，也可以在制作自己的獨(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)鍵詞：