开发应用程序其实可以和培养一朵小花一样浪漫，你需要找到适合的种子，精心的培育，等待花开。本篇会介绍独立应用程序开发的完整流程，从灵感汇集到设计考量，从落实代码到应用上架等，来和我一起培养属于你的「花」吧。

寻找灵感

灵感来源于生活。许多视频博主都会做这样一个挑战，将地图贴在远处的墙上，蒙着眼睛扎飞镖。博主和观众约定扎到哪里就去哪里。本篇文章中，我们将以此为例，构思一个随机地名生成器的应用。二可以借此讲解独立应用开发的完整流程，帮大家梳理出一份学习指南。

明确大概想要做什么之后，接下来需要做的便是将抽象的地标生成器概念具体化。我们会将其转化为可执行的应用方案，并确认目标人群。开篇提到，本应用的灵感来源于飞镖扎中地图上的地名，那么在手机上创建一个飞镖扎地图小游戏合适吗？

好像也不合适，当我们把地图显示出来，并给予用户一个飞镖时，用户还是可以根据地图位置判断可能被扎中的区域。进一步思考将其变成可行应用的方法，可以考虑回到问题的本源来。我们想要的无非是给用户一个具体的、可前往的城市名称。

落到实处，我们可以创造一个能展示随机城市名的界面。提供一个随机按钮，用户按下后，程序直接显示出城市名好像有些枯燥。那么用带点赌博性质的游戏开箱子的机制如何？似乎更有娱乐性一些。我们可以将正面有随机城市名的卡牌背面朝上，当用户翻牌时，卡牌不会立马反面，而是会播放一个小动画拉高用户期待。

目标用户 Target Audience

大想法已定，接下来我们需要考虑目标用户。在本应用中，我们的目标用户是视频博主、和热爱旅行但又不希望总被热门目的地左右的背包客。这些潜在用户去搜索，尝试一款随机地名生成器应用的可能性更大。

用户画像 Persona

在产品设计中，有时会进一步描述目标用户中的一个明确个体，这一流程叫做制作用户画像。用户画像可以是设计中的一个理想的客户描述。本应用的用户画像则可以是一个 20 岁左右管理 Bilbili 频道的男性、他经营的是一款美食探索栏目、他比较喜欢尝试新鲜事物，看到目前比较火的随机目的地挑战，他也有兴趣参与进来，去一个未知的目的地拍一期视频尝试当地特色美食。

可行性验证

有了灵感之后，你是不是着急着想要开始制作了？别急，在制定具体需求前，用一个案例介绍几个与产品相关的重要概念。

试想你在拼装一个迪士尼乐园的乐高玩具，比如上图所示，你会如何规划拼装流程呢？你也许会按照说明书一步一步来，先完成塔尖、完成大门、最后完成城堡的安装。城堡本体安装完成后，虽然距离迪士尼乐园建设完成的大业还有很长距离，但你已经可以看出这一项目的基本雏形。

在以上的设想中，我们将具体的创作流程分为以下三个阶段。

灵感萌芽 Ideation

基于你对生活的观察，你可能会发现身边不同领域存在的改进空间。在这一阶段，你可以使用不同方法来完善一个灵感，比如头脑风暴。

基本可行性产品 MVP

这一阶段则是验证灵感的最重要阶段，MVP 的英文全称为 Minimal Viable Product，你可以将其翻译为最基本的可行的产品。

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

V 代表可行的，它意味着在此阶段，这些基本功能可以被一些用户拿来进行尝试。程序设计者常犯的一个错误便是凭空猜测，假设用户需要这些那些的功能，并将自己所知的内容自然而然地当做用户也知道。实际则不然，对于用户来说，他们对你的想法、理念一无所知。制作完 MVP 之后，你就可以拿着你的 MVP 去请用户盲测了。你可以自己设计一个简单的问卷，优先不做说明。拿着 MVP 产品去请用户盲测，之后再按设计好的问题提问，来验证用户的使用流程是否如你预期，以及你所创作的产品是否可以满足用户的实际需求。

P 代表有价值的成品。

对于乐高迪士尼乐园项目来说，MVP 大概是你拼好了迪士尼城堡，把迪士尼乐园厂区的砖块放在大板子上的时候。虽然迪士尼乐园的其他地方还很空旷，城堡本身的细节也没有拼装完美，但别人已经可以由你的迪士尼城堡看出其他区域建成后的样子。

迭代周期 Design Cycle

在不同领域中，迭代周期的概念被广泛使用，重复推进这一循环的步骤可以帮你更好的推进当前产品。收获了产品反馈后，做产品的人通常会选择两个方向继续前进。一类人会将 MVP 完善后直接推向市场，由市场反馈决定接下来的需求和迭代方向；另一类人会继续坐下来完善产品，直到期望的所有功能都完成后再推向市场。

无论你是哪类人，你可能都要面对产品迭代的周期来对不同功能点，根据反馈评估，对产品进行更新，最终完善产品。这一流程一般来说是一个完整的设计、思考与评估闭环。

对于应用程序来说，新需求可能来自你自己或用户评论。你的用户会提出许多他们想要的功能，你需要根据产品在市场中的定位，来决定是否采纳这些功能建议。决定后，下一步便是创建归类描述不同需求的待办事项，并为其功能进行设计，满意后便可以将代码落地并发布更新。有些开发者还会选择诸如 A/B 测试来将同一种需求制作两个或多个变种，并根据用户反馈来决定哪一种进入最终版。

记录需求

在上一节可行性验证中，我们使用乐高迪士尼乐园的案例，展开探讨了灵感可行性验证和产品迭代的思想。接下来将回到本文的核心案例，随机地名生成器例中，将具体需求记录下来。

值得注意的是，应用程序的开发从来不是一步到位的，我的建议是将需求拆成多个可执行条目，并制定阶段性目标。比如下图中，我将随机城市应用的需求拆分，并放置在了 GTD 项目管理工具中，比如 Things 或 OmniPlan。在制作你自己的独立应用时，你也可以根据此方法归类，并适当调整需求排序，将最重要的需求放在前面优先完成。

核心需求

需求记录中，你可以从 MVP 的角度来思考你的核心需求。什么是这个应用程序最重要的部分？在随机城市应用中，最核心的部分便是创作一个翻牌的界面，来实现翻牌并给出随机城市的功能。可是这好像还不够，我还希望 MVP 产品中用户可以做些微的自定义，因此将切换「自己国家/全世界」的范围选择按钮也加入考量。

优化需求

我们在迭代周期中介绍过新需求的来源。在应用开发中，这些来源可能是一些符合基本用户认知的需求、帮助程序发展的本地化需求、来自你自己的主观创意、应用商业模式需要的收益需求等等。在随机城市应用中，我罗列的优化需求包括一个翻牌时的延迟动画、翻拍期间的声音与震动反馈、定价方案的制定等等。

设计考量及 UI 框架

已经有了需求，接下来我们便来将需求对应的设计落地。这个应用放在什么地方比较合适？便是对目标设备的考量，对于一款生成随机地名的应用来说，最适合的使用场景很可能是离手边最近的手机，因此我们将其作为主要考虑对象。

Apple Watch 似乎也是不错的候选对象，且应用迁移成本较低，因此也纳入考虑。初版设计如下。应用的核心部分便是生成随机城市名的卡牌，因此占据最高的视觉权重。搜索的自定义范围作为用户的常用功能，被安排在了界面的下方。

你可能会发现我们这个随机城市应用翻牌前后界面差异巨大，这便是得益于 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 的视觉编辑器，叫做 Storyboard。顾名思义，它允许开发者将应用程序的不同界面像制作故事板一样，依次排开在编辑器的界面中。左侧的是 UI 的大纲界面，开发者通过此面板来了解界面要素的层级关系。右下角展开的界面为自动排版的面板。

在 UIKit 中，开发者需要明确定义各界面元素之间的逻辑关系。任何一个界面元素，你都需要明确地告知它在界面元素中的位置。比如应用中常见的分类大标题文字，你需要人为定义文本框的上边栏锚定在距机器顶部 20px 的位置，文本框左侧边栏在距离机器左侧 20px 的位置上。

听我的描述，你可能会发现这个自动排版好像没那么自动。事实也确实如此，自动排版以人为给定的一系列约束条件作为运作原理。比如某一界面元素需要以另一个界面元素为基准锚定在一起，宽度不得超过多少、位置需要居中等等。它需要开发者罗列出所有规矩，自动排版会根据这些规矩在不同设备上计算出 UI 界面的唯一解。

自动排版的方案下，各界面元素互相依赖，后期想做设计调整也很麻烦，可谓牵一发动全身。明确给出各种约束条件使这些规则约束的界面实际上非常不灵活。然而消耗开发者头发的事情到这里还没有结束，我们不能只将界面罗列出来，而需要为界面元素添加功能。如上图所示，界面的要素管理由许多状态控制的函数决定。

每个视觉元素在某件事情发生时都会提供一系列状态控制的通知函数，积少成多，一个看似普通的界面往往需要几十个控制界面状态的函数堆放在一起以实现理想的界面逻辑。这些控制函数放在一起，我们称作 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 年才给出以上界面的官方支持。

在可预期的未来，SwiftUI 都将是 Apple 生态系统下的重中之重，会收到官方的最优先的支持。基于以上优势，我们将在本教程中使用这一最新框架，来了解基于它的应用构建方式。

各平台的思考

在产品定位时，创作者需要将发布的平台考虑进去。具体来说，你需要知道各平台的优劣与定位，并据此决定应用是否要登陆不同平台。

Apple Watch 是用户最亲密的设备，它具备一些最基本框架的支持。用户长时间举着胳膊并不是个很好的体验，因此为它开发应用时，你需要将用户与应用的交互时间，以及耗电量共同考虑进去。手表的表现力不像手机，若你强行将应用的所有核心功能放置其中，性能会被大幅打折，导致用户不愿意使用。你的应用所提供的，应该是一个适合手表端的简介操作，这一操作可以是 MVP 的精华，也可以是对核心功能的补充。

那么想放的各种功能应该放在哪里呢？这时你应该考虑 iOS 应用。在 Apple 生态系统的 15 亿用户中，iPhone 用户占大多数。因为基数很大，将应用放在这里，基本上可以确保拥有广阔的市场发展空间。iPhone 拥有的传感器最为丰富，你想实现的各种功能都可以把它当作试验田。

iPad 是许多开发者忽视的设备类别。但实际上 iPad 平台具有独特体验，且用户消费意愿很高。这类设备通常能提供更高一个层级的性能，购买 iPad 的用户常常对生产力应用有更高需求。除此之外，值得注意的还有 iPad 所具备的更大屏幕，你的应用程序如何设计才可以更好地利用这些空间？无论你的思考为何，切忌将 iOS 的应用直接照搬，原封不动的照搬很可能会导致原先精心设计的界面在大屏幕上显得杂乱无章。

触摸板、键盘、多点触控、Apple Pencil、鼠标共同构建了 iPad 系统的输入方式。当你对这些输入方式进行更多优化时、当你对大屏幕的体验进行更多思考时，你的思考不会平白浪费。 Apple 在基础框架的构建上付出了很多努力，许多问题你只需要解决一遍，就会发现这些功能在各平台上都完成了适配，这时你优秀的 iPad 应用可以很平滑地变成一个同样优秀的 Mac 应用。

最后要说的，便是国人不太熟悉，但海外有一定用户基数的平台 tvOS。Apple TV 用户选用的屏幕往往是家中最大的那一块，因此它在影视游戏等方面都具备独特的先天优势。当你在思考 tvOS 应用程序时，你考量的可能是如何将最核心的内容放在易于观看的大屏幕上。在你做这些努力时，你会发现你的代码在同一时间也完成了对使用外接显示器用户的适配。

寻找支持

在前几个小节中，我们探讨了随机城市应用的需求与设计，那么务实地说，谁能让我们把这个应用做下去？作为独立开发者，这个应用的最大助推者很大可能是你自己。作为对这个产品的定位、发展方向最了解的人，你要做好在没人支持情况下持续工作一段时间的心理准备。

独立应用开发对创作者多元能力的期望值较高。每个人的背景不同，强压着自己所有的部分对于某些人来说可能不现实，效果可能也达不到你的预期。在这种情况下，你可以选择和你优势互补的人共同经营一个产品，发挥你的个人优势，并在短板处寻求帮助。在互联网时代，将你最薄弱的地方直接请擅长的人来做也不失为一种选择。

作为独立应用的制作人，你不得不耐得住寂寞。前几个月应用程序无人问津那是绝对正常的，独立应用发布初期普遍会处在一个相对薄弱的竞争劣势上，需要你持续迭代一阵子才能达到一个能打仗的水平。再者而言，市面上应用众多，你的独立应用不过是沧海一粟，用户很大可能根本看不见。

那么什么时候是寻找帮助和支持的最佳时机呢？在你的构思流程基本完成、可以阐述你的产品想法时，便比较适合向了解行情的人寻求建议与支持。独立应用开发最大的消耗便是你个人的时间成本，当你的产品在 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 框架。这一框架允许我们自定义手机的振动方式，并像录制音频一样准备好一段非常独特的震动反馈。

目前 Apple 放开了 233 个技术框架 给开发者，以后还会更多。从这些框架的数量上你也许不难发现，想熟练掌握全部框架几乎是件不可能、且没必要的事情。你可以将这些框架看作你的知识库，在应用需要某个技术时，学习对应用法即可。我们将在教程的第四章中详细探讨框架的用法。

本小节中，我们介绍了将代码落地的三片拼图，现在你大概了解了它们在独立应用开发的过程中所处的地位。Swift 负责应用程序逻辑，SwiftUI 负责 UI 界面，系统框架负责提供让创作者使用设备上不同功能的途径。对于以上这些话题，我们将在教程的二三四章中对这些技术一一展开。

应用上架

找到了需求，完成了设计，落实了代码。接下来便是将应用程序分享出去，让这个世界分享你的创作喜悦。在本小节中，我们来讨论应用上架过程中你会遇到的几个重要概念。

应用打包

对于开发者来说，许多工作都由 Xcode 和 App Store 代劳了，不需要额外操心应用的分发和瘦身等。开发者需要提供一个叫做 IPA 的应用打包文件，这个文件包含了应用程序为不同设备所设计的所有美术素材、代码等内容，由开发者在 Xcode 中直接提交给应用商店。

商店审核

应用程序提交至应用商店后，并不能直接上架。你需要等待大概 1-3 天的审核期，这个审核过程是需要 Apple 那边商店审核人员参与的，主要负责查验应用是否符合一系列规则。在此期间，你会看到应用程序处于「待提交，待审核， 审核中，被拒绝，可销售」这几个状态中的一个。等到变为可销售时，你的应用程序便可以在世界上的应用商店中显示出来，供用户下载。

App Store Connect

这是你与 Apple 商店团队、以及用户的衔接桥梁。应用程序上架后，你可以在 App Store Connect 中做更新内容的提交、用户评价的反馈、销售数据的查询等事情。以下图中应用「书空」为例，你可以看到世界上那些国家和地区的用户在使用你的应用、销量、使用情况等等。我们会在第六章中展开讲解这一系统中重要数据的意义。

应用营收

当你的应用程序开始满足用户需求时，用户便会以不同方式来支持他们喜欢的应用。常见的营收选择有一次性购买、广告、应用内购、自动订阅等方案。针对应用的属性，你也可以自由选择一种或多种营收方案的组合。每种营收方案适用于不同类型的应用，我们会在第六章中详细探讨方案的要求与用法。

获取用户

对于随机城市应用，我们的目标用户与定位比较明确，为有出行需求的用户提供一个惊喜的旅行地点。但是在应用程序上架后，很大概率我们的应用仍会无人问津。那么如何获取用户呢？

产品描述

用户见到你产品的第一印象便是在应用商店中浏览，因此你的产品描述必须展示出应用亮点。开发者常忽略对宣传文字、截图及视频的琢磨，而这恰恰是用户决定是否下载的关键时刻。如下图所示，你会发现每个应用最多可以有 3 个视频宣传和 10 张截图。取决于你的应用功能多少，建议最少提供 1 个视频及 4 张以上的截图。

俗话说「酒香不怕巷子深」，问题是在有海量应用程序的今天，许多用户也许压根闻不到你的酒香味。应用程序的描述界面就好像餐厅进门的装修，有没有用心用户第一时间便会有明确感知，建议仔细考量。若你还想做得更好一些，可以根据用户所在地的语言来定制每个地区商店页面的显示内容，让用户感觉到开发者对当地用户的切实考虑。

广告

为你的应用打广告一定会带来流量、关注、和用户群体。但是对谁广告、如何优化广告、花多少钱广告、在哪里广告都是你需要思考的范畴。在我看来，决定是否使用这个广告商的标准，便是开销小于获取用户的成本。若你的应用程序由广告带来的用户收益大于实际广告支出，则说明你摸索出了一个针对你应用的可行广告方案。对于广告优化中常见的数据解读，我们将在第六章 - 如何宣传你的应用中详细展开。

多媒体渠道

用户获得信息的方式早已不局限于广告。仔细想想，上一次你装某个新东西时，是不是某个人和你说「哎那个不错，要不你去试试？」当你的应用成熟时，你可以考虑出传统广告商之外的其他途径，比如网站媒体、视频博主等渠道宣传。市场上有非常多的人在做这些工作，也愿意与独立开发者建立互助关系。

权重优化

产品在应用商店的排位决定了产品的曝光量，曝光决定了有机会看到你应用的用户数量，用户数量决定了你的收益，收益多少决定了你的应用是否覆盖投入，可以长期做下去。而是谁决定了你的产品在商店中的排位呢？这便是关键词权重。

那么什么又是关键词呢？这便是与你的应用程序相关，用户可能搜索的词汇。你可以通过许多途径来判断目前使用的关键词是否可以为你带来用户。以随机城市为例，我们需要考量的不仅是应用程序名，而是用户用来搜索的方式。

「去哪儿」可能是个非常不错的搜索词，且搜索权重很高，但由于竞争对手太多，新应用使用热门关键词的排位会更低，以至于用户根本关注不到你的应用，还会白白消耗关键词配额。建议你在考虑关键词时将当前关键词下应用总数考虑进去，选择与你的应用相关，但可能获得更高排位的相关关键词中。

权重优化是一个相对来说需要花些时间，但回报颇丰的事情。作为独立应用开发者，你可以在每次应用更新时一并更新你的关键词，并记录每次的效果。我们会在教程中单独开篇讲解关键词及权重优化。

更新维护

作为开发者，你会希望更多积极的评论显示在应用商店的评论区；对于 Bug 反馈，则更适合直接反馈给开发者，以便及时修复。开发者与用户需要交流反馈，然而正常使用时，用户不会有那么多去反馈的冲动；反而是有负面体验时想到商店评价。那么有什么解决办法呢，其中一个可行方案便是在恰当的时机提出问题。

在某个惊喜的功能推送后，是否询问用户愿意帮忙反馈来让更多人发现你的应用？在 Apple 提供的众多技术框架中，StoreKit 负责用户评价等事宜。你可以直接在应用中向用户收取商店的评分或文字反馈，也可以考虑使用不同的反馈方案，在用户需要的时候为它们提供直接能联系到你的方式。 

更新公告

在开发完整流程的最后，我们来讨论每个开发者都会面对的应用更新。更新的具体原因有很多，但大致目的可能为用户提供新功能、或要修复某个应用 Bug。

更新公告不应该敷衍了事，因为你的用户可能服务的某一个小众用户群，这些用户真切的关注应用发展，而更新公告便是他们认知你这边更新的主要途径。对于独立应用创作者来说，你也可以把这些更新公告当作对每件事的梳理。开发者需要对每一次调整用户数据存储方式的更新尤为谨慎，对于这些更新你需要仔细测试，确保用户可以平滑地跨度到最新的存储方案中。

总结

在本文中，我们概括性地讲解了独立应用开发中的常见概念。你可以把它看作是本教程的梳理，也可以在制作自己的独立应用时拿出来当做参考。

做一个应用真的像种一朵花，在前期栽培时你可能除了辛苦付出什么也看不到，因为种子还深埋在泥土里，在独立开发的流程中也适用。但这场历程总是值得的，耐下心来，等待萌芽破土，花茎抬头，花朵一点一点绽放开来。就让我们一起开始这场创作之旅吧！

下一篇文章中，我们将认识让这一切开始的工具：Xcode。