好像也不合适，当我们把地图显示出来，并给予用户一个飞镖时，用户还是可以根据地图位置判断可能被扎中的区域。进一步思考将其变成可行应用的方法，可以考虑回到问题的本源来。我们想要的无非是给用户一个具体的、可前往的城市名称。
落到实处，我们可以创造一个能展示随机城市名的界面。提供一个随机按钮，用户按下后，程序直接显示出城市名好像有些枯燥。那么用带点赌博性质的游戏开箱子的机制如何？似乎更有娱乐性一些。我们可以将正面有随机城市名的卡牌背面朝上，当用户翻牌时，卡牌不会立马反面，而是会播放一个小动画拉高用户期待。
目标用户TargetAudience
用户画像Persona
在产品设计中，有时会进一步描述目标用户中的一个明确个体，这一流程叫做制作用户画像。用户画像可以是设计中的一个理想的客户描述。本应用的用户画像则可以是一个20岁左右管理Bilbili频道的男性、他经营的是一款美食探索栏目，他比较喜欢尝试新鲜事物，看到目前比较火的随机目的地挑战，他也有兴趣参与进来，去一个未知的目的地拍一期视频尝试当地特色美食。
▍可行性验证
网友BasilBricks制作的乐高迪士尼城堡模型-Reddit
试想你在拼装一个迪士尼乐园的乐高玩具，比如上图所示，你会如何规划拼装流程呢？你也许会按照说明书一步一步来，先完成塔尖、完成大门、最后完成城堡的安装。城堡本体安装完成后，虽然距离迪士尼乐园建设完成的大业还有很长距离，但你已经可以看出这一项目的基本雏形。
在以上的设想中，我们将具体的创作流程分为以下三个阶段。
灵感萌芽Ideation
基于你对生活的观察，你可能会发现身边不同领域存在的改进空间。在这一阶段，你可以使用不同方法来完善一个灵感，比如头脑风暴。
基本可行性产品MVP
这一阶段则是验证灵感的最重要阶段，MVP的英文全称为MinimalViableProduct，你可以将其翻译为最基本的可行的产品。
M代表着基本、最骨干的功能，用户看到后会知道你在做什么。
V代表可行的，它意味着在此阶段，这些基本功能可以被一些用户拿来进行尝试。程序设计者常犯的一个错误便是凭空猜测，假设用户需要这些那些的功能，并将自己所知的内容自然而然地当做用户也知道。实际则不然，对于用户来说，他们对你的想法、理念一无所知。制作完MVP之后，你就可以拿着你的MVP去请用户盲测了。你可以自己设计一个简单的问卷，事先不作说明。拿着MVP产品去请用户盲测，之后再按设计好的问题提问，来验证用户的使用流程是否如你预期，以及你所创作的产品是否可以满足用户的实际需求。
P代表有价值的成品。
不太完美的MVP-Unsplashmarkkoenig
对于乐高迪士尼乐园项目来说，MVP大概是你拼好了迪士尼城堡，把迪士尼乐园厂区的砖块放在大板子上的时候。虽然迪士尼乐园的其他地方还很空旷，城堡本身的细节也没有拼装完美，但别人已经可以由你的迪士尼城堡看出其他区域建成后的样子。
迭代周期DesignCycle
在不同领域中，迭代周期的概念被广泛使用，重复推进这一循环的步骤，可以帮你更好地推进当前产品。收获了产品反馈后，做产品的人通常会选择两个方向继续前进。一类人会将MVP完善后直接推向市场，由市场反馈决定接下来的需求和迭代方向；另一类人会继续坐下来完善产品，直到期望的所有功能都完成后再推向市场。
无论你是哪类人，你可能都要面对产品迭代的周期，来对不同功能点，根据反馈评估，对产品进行更新，最终完善产品。这一流程一般来说是一个完整的设计、思考与评估闭环。
▍记录需求
在上一节可行性验证中，我们使用乐高迪士尼乐园的案例，展开探讨了灵感可行性验证和产品迭代的思想。接下来将回到本文的核心案例，随机地名生成器例中，将具体需求记录下来。
值得注意的是，应用程序的开发从来不是一步到位的，我的建议是将需求拆成多个可执行条目，并制定阶段性目标。比如下图中，我将随机城市应用的需求拆分，并放置在了GTD项目管理工具中，比如Things或OmniPlan。在制作你自己的独立应用时，你也可以根据此方法归类，并适当调整需求排序，将最重要的需求放在前面优先完成。
随机城市Things需求-王禹效
核心需求
需求记录中，你可以从MVP的角度来思考你的核心需求。什么是这个应用程序最重要的部分？在随机城市应用中，最核心的部分便是创作一个翻牌的界面，来实现翻牌并给出随机城市的功能。可是这好像还不够，我还希望MVP产品中用户可以做些微的自定义，因此将切换「自己国家/全世界」的范围选择按钮也加入考量。
优化需求
▍设计考量及UI框架
已经有了需求，接下来我们便来将需求对应的设计落地。这个应用放在什么地方比较合适？便是对目标设备的考量，对于一款生成随机地名的应用来说，最适合的使用场景很可能是离手边最近的手机，因此我们将其作为主要考虑对象。
AppleWatch似乎也是不错的候选对象，且应用迁移成本较低，因此也纳入考虑。初版设计如下。应用的核心部分便是生成随机城市名的卡牌，因此占据最高的视觉权重。搜索的自定义范围作为用户的常用功能，被安排在了界面的下方。
Sketch设计-王禹效
你可能会发现我们这个随机城市应用翻牌前后界面差异巨大，这便是得益于SwiftUI视觉框架可灵活拼装的特性。在iOS端，用作生成应用程序界面的代码我们称作UI框架，它的目的是把设计好的产品原型变成应用可以执行的代码。比如上图中，我们的产品设计原型由Sketch制作而成，接下来，我们便需要将这个设计作为代码落地。
视觉框架
在iOS生态系统中，常用的视觉框架有三种。第一种叫做Flutter，它是由Google主导开发的Android与iOS跨平台UI框架，目前使用此技术的代表应用为阿里巴巴的闲鱼。Flutter底层的语言是Dart，有额外学习成本；其次是Flutter并非Apple第一方框架，因此使用中遇到的小毛病不方便获取Apple官方支持，个人不太推荐。但若你感兴趣，Flutter描述性语言的特质与本教程学习的SwiftUI概念类似，你可以比较容易地做知识迁移。
第二种UI框架叫做UIKit，它由Apple官方出品，是过去十余年iOS界面开发的主力军。在UIKit的世界中，UI适配各种不同机型屏幕尺寸机器的技术称作AutoLayout自动排版。因UIKit在iOS开发上占有特殊地位，你可能会在其它地方见到此技术的使用，我们简单介绍下。
UIKit的视觉编辑器-王禹效
上图便是UIKit的视觉编辑器，叫做Storyboard。顾名思义，它允许开发者将应用程序的不同界面像制作故事板一样，依次排开在编辑器的界面中。左侧的是UI的大纲界面，开发者通过此面板来了解界面要素的层级关系。右下角展开的界面为自动排版的面板。
在UIKit中，开发者需要明确定义各界面元素之间的逻辑关系。任何一个界面元素，你都需要明确地告知它在界面元素中的位置。比如应用中常见的分类大标题文字，你需要人为定义文本框的上边栏锚定在距机器顶部20px的位置，文本框左侧边栏在距离机器左侧20px的位置上。
听我的描述，你可能会发现这个自动排版好像没那么自动。事实也确实如此，自动排版以人为给定的一系列约束条件作为运作原理。比如某一界面元素需要以另一个界面元素为基准锚定在一起，宽度不得超过多少、位置需要居中等等。它需要开发者罗列出所有规矩，自动排版会根据这些规矩在不同设备上计算出UI界面的唯一解。
NSViewController-AppleDeveloperDocumentation
自动排版的方案下，各界面元素互相依赖，后期想做设计调整也很麻烦，可谓牵一发动全身。明确给出各种约束条件使这些规则约束的界面实际上非常不灵活。然而消耗开发者头发的事情到这里还没有结束，我们不能只将界面罗列出来，而需要为界面元素添加功能。如上图所示，界面的要素管理由许多状态控制的函数决定。
每个视觉元素在某件事情发生时都会提供一系列状态控制的通知函数，积少成多，一个看似普通的界面往往需要几十个控制界面状态的函数堆放在一起以实现理想的界面逻辑。这些控制函数放在一起，我们称作ViewController视觉元素控制器。这一文件常常因为控制界面状态的函数过多而变得非常大而被开发者戏称为「过度肥胖」。
当控制界面的函数过多时，就容易在开发者不注意的地方产生冲突，也就是程序Bug。当控制界面因函数过多而变得复杂时，我们便很难继续处理好每一个界面间的关系，而需要投入大量精力来寻找原因。
难道就没有一个更好的方法了吗？答案是有的，这便是第三种UI框架SwiftUI。SwiftUI是Apple官方于2019年发布的最新UI框架，它在UIKit上更近了一步，不再是提供一套一致的界面来强行适配不同平台，而是根据不同平台因地制宜，在不同平台上，用符合该平台设计规则的方式将界面元素呈现出来。
还记得我之前提到的界面不够灵活、界面状态管理繁杂的问题吗？SwiftUI从根本上解决了这两个问题。SwiftUI不需要你明确给出每个界面具体受哪些条条框框的限制，你只需要描述出你希望的界面与其它元素的逻辑位置关系即可。
比如上图中界面里的例子，我们希望左侧有一个Swift的图标，右侧是一段文字描述。具体到代码来说，我们只需要向SwiftUI描述：横向排版HStack{Image+文本Text}即可。使用SwiftUI的流程更像是在和电脑对话，你将你想要的界面描述给它，至于如何显示、间距、界面状态等复杂事物都由电脑操心。也正因为SwiftUI高度灵活、可自由组合的特性，我们才可以实现随机城市中翻牌后截然不同的两套界面。
SwiftUI不在乎你的背景如何，非常易学易用，且具有极佳的跨系统支持。但同时你需要认识到SwiftUI是一款新生框架，处在逐渐完善的过程中。比如UIKit所支持的CollectionView或者ActivityIndicator这些成熟界面元素的替代品，SwiftUI在2020年才给出以上界面的官方支持。截至2023年，你所需要的绝大多数功能，都已经能在SwiftUI上原生实现啦。
在可预期的未来，SwiftUI都将是Apple生态系统下的重中之重，会受到官方的最优先的支持。基于以上优势，我们将在本教程中使用这一最新框架，来了解基于它的应用构建方式。
Apple平台-AppleDeveloperDocumentation
各平台的思考
在产品定位时，创作者需要将发布的平台考虑进去。具体来说，你需要知道各平台的优劣与定位，并据此决定应用是否要登陆不同平台。
那么想放的各种功能应该放在哪里呢？这时你应该考虑iOS应用。在Apple生态系统的15亿用户中，iPhone用户占大多数。因为基数很大，将应用放在这里，基本上可以确保拥有广阔的市场发展空间。iPhone拥有的传感器最为丰富，你想实现的各种功能都可以把它当作试验田。
iPad是许多开发者忽视的设备类别。但实际上iPad平台具有独特体验，且用户消费意愿很高。这类设备通常能提供更高一个层级的性能，购买iPad的用户常常对生产力应用有更高需求。除此之外，值得注意的还有iPad所具备的更大屏幕，你的应用程序如何设计才可以更好地利用这些空间？无论你的思考为何，切忌将iOS的应用直接照搬，原封不动的照搬很可能会导致原先精心设计的界面在大屏幕上显得杂乱无章。
触摸板、键盘、多点触控、ApplePencil、鼠标共同构建了iPad系统的输入方式。当你对这些输入方式进行更多优化时，当你对大屏幕的体验进行更多思考时，你的思考不会平白浪费。Apple在基础框架的构建上付出了很多努力，许多问题你只需要解决一遍，就会发现这些功能在各平台上都完成了适配，这时你优秀的iPad应用可以很平滑地变成一个同样优秀的Mac应用。
▍寻找支持
独立应用开发对创作者多元能力的期望值较高。每个人的背景不同，强压着自己所有的部分对于某些人来说可能不现实，效果可能也达不到你的预期。在这种情况下，你可以选择和你优势互补的人共同经营一个产品，发挥你的个人优势，并在短板处寻求帮助。在互联网时代，将你最薄弱的地方直接请擅长的人来做也不失为一种选择。
作为独立应用的制作人，你不得不耐得住寂寞。前几个月应用程序无人问津那是绝对正常的，独立应用发布初期普遍会处在一个相对薄弱的竞争劣势上，需要你持续迭代一阵子才能达到一个能打仗的水平。再者而言，市面上应用众多，你的独立应用不过是沧海一粟，用户很大可能根本看不见。
Unsplash-micheile
也许你的初心便是创作一款心中所想的应用，但你必须意识到，与你自身不同，外来资本的介入需要投资回报，因此你必须让利。是否寻求外来资本的帮助与介入，需要你自己根据实际情况来做判断。本文中我们随机城市的例子规划格局比较小，因此不需要额外资本的介入。
▍落实代码
上文我们介绍了UI框架SwiftUI，在代码截图中你可能发现了SwiftUI常见的，诸如Text("文本")这样的写法。在本小节中，我们将介绍独立开发代码落地阶段最重要的三片拼图，它们分别是Swift、SwiftUI和系统框架。
Swift
编程时我们用什么语言呢？你也许已经由SwiftUI的名字猜到了，我们要用的是一款名为Swift的编程语言。Swift是一款由Apple在2014年发布的跨Apple生态系统的编程语言，据淘宝开发团队统计，截至2020年，北美市场近80%的应用都用上了Swift。编程语言就好比乐高的积木块，是一切的基础。如同我们说话需要中文一样，与电脑沟通时则可以使用Swift语言。
以随机城市这款应用的核心需求为例，我们需要一张卡片，共正反两面。正面是一个问号，背面是一个随机的地名。下图便展示了这个逻辑用Swift语言的写法。我们创建了一个包含三个城市名称的列表，从中选出一个随机城市。当卡牌正面向上时显示问号，背面向上是显示随机城市的名称。
SwiftUI
说完了Swift，那么与它名字相似的SwiftUI又是什么呢？SwiftUI是一款DSL语言，全称为domain-specificlanguage，它具有专有语法来实现专有用途。若你将Swift理解为日常用语，那么SwiftUI便好像是一系列专业术语。它依托于日常用语，又依靠独特词汇提供了日常语境中不涉及的专业内容。
对于SwiftUI来说，它可以理解Swift的语法，因为这是它的基础。与此同时，SwiftUI还具有一些专用的语法结构，用来实现UI界面的构建逻辑。
上面你看到的便是将我们刚刚写好的最核心Swift逻辑放入SwiftUI界面中的效果。对于SwiftUI来说，任何我们在程序界面上所看到的东西都属于它的能力范畴。比如一个可滑动的视图，视图中滑动的手势、按钮、、动画效果、边的阴影等等都属其中。
将Swift带来的逻辑与SwiftUI带来的UI界面相组合，我们便得到了此应用程序的核心功能。上图中代码的运行效果如下。
框架
在代码落地的讨论范畴中，我们还缺最后一片拼图，这便是系统框架。那么什么是系统框架呢？系统框架也被Apple官方列在科技列表中，它代表的是一系列设备本身所具备的硬件能力。这些能力经Apple工程师之手规整好，之后将更容易理解，可直接使用的函数直接开放给开发者，便形成了框架。这些框架可以由创作者根据自身需求自由选用。
框架的涉及范围也非常广泛，比如负责云数据同步的CloudKit框架、负责AR交互的ARKit框架、负责异步事件处理的Combine框架等等。以随机城市中我们想在翻牌时用到的触觉反馈为例，我们需要使用的便是这些技术框架中的CoreHaptics框架。这一框架允许我们自定义手机的振动方式，并像录制音频一样准备好一段非常独特的震动反馈。
Technologies-AppleDeveloperDocumentation
目前Apple放开了233个技术框架给开发者，以后还会更多。从这些框架的数量上你也许不难发现，想熟练掌握全部框架几乎是件不可能、且没必要的事情。你可以将这些框架看作你的知识库，在应用需要某个技术时，学习对应用法即可。我们将在教程的第四章中详细探讨框架的用法。
本小节中，我们介绍了将代码落地的三片拼图，现在你大概了解了它们在独立应用开发的过程中所处的地位。Swift负责应用程序逻辑，SwiftUI负责UI界面，系统框架负责提供让创作者使用设备上不同功能的途径。对于以上这些话题，我们将在教程的二三四章中对这些技术一一展开。
▍应用上架
应用打包
对于开发者来说，许多工作都由Xcode和AppStore代劳了，不需要额外操心应用的分发和瘦身等。开发者需要提供一个叫做IPA的应用打包文件，这个文件包含了应用程序为不同设备所设计的所有美术素材、代码等内容，由开发者在Xcode中直接提交给应用商店。
商店审核
应用程序提交至应用商店后，并不能直接上架。你需要等待大概1-3天的审核期，这个审核过程是需要Apple那边商店审核人员参与的，主要负责查验应用是否符合一系列规则。在此期间，你会看到应用程序处于「待提交，待审核，审核中，被拒绝，可销售」这几个状态中的一个。等到变为可销售时，你的应用程序便可以在世界上的应用商店中显示出来，供用户下载。
AppStoreConnect
这是你与Apple商店团队、以及用户的衔接桥梁。应用程序上架后，你可以在AppStoreConnect中做更新内容的提交、用户评价的反馈、销售数据的查询等事情。以下图中应用「书空」为例，你可以看到世界上哪些国家和地区的用户在使用你的应用、销量、使用情况等等。我们会在第六章中展开讲解这一系统中重要数据的意义。
书空AppStoreConnect界面-王禹效
应用营收
▍获取用户
对于随机城市应用，我们的目标用户与定位比较明确，为有出行需求的用户提供一个惊喜的旅行地点。但是在应用程序上架后，很大概率我们的应用仍会无人问津。那么如何获取用户呢？
产品描述
用户见到你产品的第一印象便是在应用商店中浏览，因此你的产品描述必须展示出应用亮点。开发者常忽略对宣传文字、截图及视频的琢磨，而这恰恰是用户决定是否下载的关键时刻。如下图所示，你会发现每个应用最多可以有3个视频宣传和10张截图。取决于你的应用功能多少，建议最少提供1个视频及4张以上的截图。
多媒体渠道
权重优化
产品在应用商店的排位决定了产品的曝光量，曝光决定了有机会看到你应用的用户数量，用户数量决定了你的收益，收益多少决定了你的应用是否覆盖投入，可以长期做下去。而是谁决定了你的产品在商店中的排位呢？这便是关键词权重。
蝉大师-搜索结果
▍更新维护
在某个惊喜的功能推送后，是否询问用户愿意帮忙反馈来让更多人发现你的应用？在Apple提供的众多技术框架中，StoreKit负责用户评价等事宜。你可以直接在应用中向用户收取商店的评分或文字反馈，也可以考虑使用不同的反馈方案，在用户需要的时候为它们提供直接能联系到你的方式。
更新公告
在开发完整流程的最后，我们来讨论每个开发者都会面对的应用更新。更新的具体原因有很多，但大致目的可能为用户提供新功能、或要修复某个应用Bug。
▍总结
Unsplash-jeremybishop
在本文中，我们概括性地讲解了独立应用开发中的常见概念。你可以把它看作是本教程的梳理，也可以在制作自己的独立应用时拿出来当做参考。
做一个应用真的像种一朵花，在前期栽培时你可能除了辛苦付出什么也看不到，因为种子还深埋在泥土里，在独立开发的流程中也适用。但这场历程总是值得的，耐下心来，等待萌芽破土，花茎抬头，花朵一点一点绽放开来。就让我们一起开始这场创作之旅吧！