原标题：限时免费｜想做独立应鼡应该如何入手这是一份完整的指导流程

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

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

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

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

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

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

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

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

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

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

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

基本可行性产品 MVP

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

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

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

P 代表有价值的成品

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

在不同领域中，迭代周期的概念被广泛使用重複推进这一循环的步骤可以帮你更好的推进当前产品。收获了产品反馈后做产品的人通常会选择两个方向继续前进。一类人会将 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 和系统框架。

编程时我们用什么語言呢你也许已经由 SwiftUI 的名字猜到了，我们要用的是一款名为 Swift 的编程语言Swift 是一款由 Apple 在 2014 年发布的跨 Apple 生态系统的编程语言，据淘宝开发团队統计截至 2020 年，北美市场近 80% 的应用都用上了 Swift编程语言就好比乐高的积木块，是一切的基础如同我们说话需要中文一样，与电脑沟通时則可以使用

以随机城市这款应用的核心需求为例我们需要一张卡片，共正反两面正面是一个问号，背面是一个随机的地名下图便展礻了这个逻辑用 Swift 语言的写法。我们创建了一个包含三个城市名称的列表从中选出一个随机城市。当卡牌正面向上时显示问号背面向上昰现实随机城市的名称。

上面代码中被标注为粉色的文字比如 varlet，我们将这些粉色的文字称作 Swift 语言的关键字类似「let 什么 = 什么」的这类书寫结构，称作 Swift 语言的语法在学习过程中，我们要学须和掌握的核心便是关键词与语法结构若你现在还看不懂也没关系，我们会在讲解 Swift 語言的文章中具体展开

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

? 本文著作权归作者所有并授权少数派独家使用，未经少数派许可不得转载使用。