SwiftUI：独立开发者指南

作者: 时光啊混蛋_97boy | 来源:发表于2020-12-03 17:53 被阅读0次

原创：知识点总结性文章
创作不易，请珍惜，之后会持续更新，不断完善
个人比较喜欢做笔记和写总结，毕竟好记性不如烂笔头哈哈，这些文章记录了我的IOS成长历程，希望能与大家一起进步
温馨提示：由于简书不支持目录跳转，大家可通过command + F 输入目录标题后迅速寻找到你所需要的内容

一、开发理念
- 1、做一个独立开发者
- 2、极具创造力的思维方式
- 3、凭一腔热血做完的应用发现没有人用
二、构思产品
- 1、寻找灵感
- 2、目标用户
- 3、可行性验证
- 4、记录需求
- 5、设计考量及 UI 框架
- 6、寻找支持
三、开发产品
- 1、Swift语言
- 2、SwiftUI的DSL语言
- 3、系统框架
四、应用上架
- 1、应用打包
- 2、商店审核
- 3、App Store Connect
- 4、应用营收
五、获取用户
- 1、产品描述
- 2、广告
- 3、多媒体渠道
- 4、权重优化
参考文献

一、开发理念

1、做一个独立开发者

a、学习独立开发

现有教程大多侧重于程序员教程序员，这听起来很合理，但实际并不完全适合独立开发。太多人跟着网课照猫画虎，做了个和视频里一模一样的应用，然后不知道接下来如何。究其原因，是教程作者普遍缺乏跨学科思考的能力，只看到眼下用所有编程技巧所创作出的范例应用，却不曾想这些应用的实用价值。作为程序员的授课老师常精通代码，却通常不具备发现市场需求的能力。

太多人把编程当作掌握各种语言、科技、算法，而忽略其实际应用，这非常可惜。学习独立开发其实适用于所有人，它会教给你一种极具创造力的思维方式。你可以用自己的创造，解决他人的实际问题。

b、跨领域的关联

现有的知识体系注重培养一个人专强的能力，却忽视了知识间跨领域的关联。而知识的关联性，就如同点穿成线，线穿成网，从而形成知识的储备。值得注意的是，许多精彩的创造恰恰来自于对多领域的了解，和跨领域的碰撞。

如同影视，运用了镜头、音乐、叙事等，来将某个观念传递出去；建筑，包涵了对美学、数学、空间理论等的理解，来创作出与社会环境相和谐的设施；而切准需求、定位独特、能更好服务受众的的应用程序，依靠的不仅是你对编程，算法和计算机理论有多熟练，而是将不同领域的东西拿来，像拼积木一样组装在一起。以企业学的发现问题来介绍创作内容、平面与交互设计来剖析界面设计、计算机科学的基本理论及编程知识来讲程序实现、商业模式来解读应用营收、广告学的基本知识来带你了解应用宣传。

c、寻找需求

我个人很少去找需求，但时常会发现需求送到手边。学乐理的时候发现编谱设计软件的冗杂；和商店老板聊天的时候，老板对需要一个帮助进货管理的软件，目前商业大厂的产品反而不适合个企；和语言学教授探讨语言培训时，发现其对语言教学软件知晓颇深，市面上现有的语言培训软件反而缺乏语言学的理论支撑。世上非常多需求，自己见到不满的，见到别人不满的，想改变的事都可以转换成需求。甚至有些时候，你会发现和别人聊天之后，第二天便会收到一份诚意满满的需求档案。有想法，熟悉自己领域的人很多，能帮助他们把想法变现的人不多。

2、极具创造力的思维方式

a、POEMS 法则

用 POEMS 法则来对上述描述归类，该授课场景中的人群是：老师、学生、还有喝咖啡的顾客，偶尔有新来的学生，学生背景各异；物品有：店里售卖的的咖啡、学生的笔记本、老师的 iPad、老师准备的讲义；环境：较为嘈杂、授课地点为租用的场地、人多时会坐在 10 人桌子上，人少时也可以选择 2 - 4 人的小桌子；信息：一般上课前学生会自由交流一段时间，课程常会直接使用场景中的物品进行介绍，比如带学生询问咖啡师问题；服务：老师提供授课，咖啡师提供学生午餐或饮料。

b、头脑风暴

当你得到了一个想解决的问题后，可以使用头脑风暴 Brainstorm 对该问题的解决方案思考。头脑风暴很简单，坐在桌子前花上十分钟的事把你关于这个问题的所有想法写在纸上即可。进行头脑风暴时，记住这些想法不分对错，疯狂的、傻的、成本高昂的想法全部都可以被记录下来，日后筛选即可。

c、SCAMPER 方法

SCAMPER

在考虑 SCAMPER 方法时，每个领域有些方法你可以参考。比如替品可以考虑：时间、流程、设计、颜色、风格等的替换；组合可以考虑：灵感、概念、任务、功能等的组合；适应可以考虑：市场定位、内需还是外需等；修改可以考虑：能被用在哪些领域、如何定制独特功能；别用可以考虑：能不能拆分功能、还能被用在什么地方、能提供哪些相关产品服务；移除可以考虑：什么是必须有的、什么是不必要的、功能有没有增加价值等；反转可以考虑：如果增加限制会怎么样、反转后有哪些体验上的提升或降低等。

d、用 SMART 法则设定目标

鲜少有公司或企业可以没有目标地盲目前进，比如 Apple 大概在 2022 年会发布的 AR 眼镜，其目标定制至少是在十年以前。目标一般分为短期目标、中期目标和长期目标。短期目标指的是几个月至一年的时间周期，比如今年年底应用销量应提升 10%；中期目标指的是一至五年的时间周期，比如两年内应用要登陆十个海外市场；长期目标指的是五年以上的时间周期，比如 6 年内该产品达到业界前三。

明确具体 Specific ：明确到具体的点，如应用应完成繁体中文的翻译。
可衡量 Measurable ：有明确指标测试其完成度，如繁体中文版发布至商店后目标才达成。
可达成 Achieveable：在计划的时间内可行，如你具备繁体中文的翻译能力。
相关 Relevant：与你的产品相关，如你的计划是对某个应用完成翻译。
明确时限 Time-framed：指定目标完成的预计时间，如翻译至上线时间为两周。

3、凭一腔热血做完的应用发现没有人用

a、做好规划及前期调研

做产品，不就是有了灵感之后把它做出来嘛。其实不然，你可能在应用商店上看到许多开发者制作的应用，下载者寥寥无几，这便是因为其没有考虑到市场需求，凭一腔热血做完的应用才发现没有人用。还有一些情况，开发者一开始就制定过大的规划，导致项目无法落实并继续下去。

b、领导力及管理能力

在日常的工作中，你有可能依旧习惯让上级告诉你需要做什么事情。但作为独立开发者，更常见的情况是没人会告诉你需要做什么，此时便需要你靠自己的能动性来推进项目，你需要做自己的上级。

变革型领导力：指的是具备远见，找到需要改变之处，并指明方向的能力。这种能力通常也被简称为领导力 Leadership。具备变革型领导力的人通常能发现机遇并协助团队向其看到的方向前进。

交易型领导力：指的是监督、能合理分工、推动效益的能力。这种能力通常也被简称为管理能力 Management。具备交易型领导力的人通常能做好项目分工，承担责任，制定计划并确保项目按计划进行。

以 Apple 的创始人乔布斯为例，他曾是一位典型的变革型领导。在大众眼中，他似乎永远可以看到下一个前进的方向，比如早期制定 Mac 图形交互界面的发展方向，回归 Apple 后又看到了唱片行业存在的问题，适时地推出了广受市场接纳的 iPod 系列音频设备。

在 Apple 公司创建不久后，乔布斯也主导了一系列相对不稳妥的产品开发，比如由其小女儿命名的丽莎 Lisa 电脑，这一系列产品由于定位失误，销量很低。接下来乔布斯又做出了几个稍欠考虑的决策，最终让他被 Apple 董事会开除。这一时期，他所缺乏的恰恰是上文中提到的作为领导者的另一重要能力，即管理能力。当乔布斯数年后跟着 Next 电脑团队重回苹果后，此时的他积累并磨练出了更充分的管理经验。而后在商业上做出了许多经典决策，如大幅消减产品线至四条，专注产品发展。

Apple 的现任 CEO 库克恰好是个稍欠缺变革型领导力、但管理能力极佳的人，因此在过去二十几年中 Apple 运作都相对平顺。

领导不仅代表官级更大的人。打江山和守基业指的是两种差异很大的能力，乔布斯是领导者的优秀代表，而库克是管理者的优秀代表。总的来说，领导力决定方向、管理能力决定执行力。二者在大公司中缺一不可，作为独立开发者也是如此。领导力决定了你观察问题的角度，为产品设定的方向是否可靠；管理能力决定项目能否顺利推进，如期完成。

项目	宰相	内阁首辅
制定计划	安排时间并考虑成本。制定每一个阶段性目标的具体执行计划，并预留出足够的时间及资源来落实每个小目标。比如你在制作应用时，若仍有其它全职工作，应从家庭生活、工作时间外预留出一部分时间来安排给应用开发。	确定方向。考虑短期、中期、长期项目将实现怎样的目标。思考在这些目标的过度时，你需要做出哪些改变，需要什么新资源。
安排人事	考虑人员安排。明确人员之间的沟通方式，明确每个人所具备的职责。若应用由你一人独立开发，可以使用项目管理工具，安排自己什么时候应该写文档、什么时候做设计、什么时候做客服解决用户问题、什么时候写代码增加功能、什么时候修复 Bug。	让参与项目的人了解你的目标。直接与团队成员明确交流，并倾听团队反馈。若应用有部分内容外包给第三方，则需要与第三方明确沟通你的应用的设计理念及风格。
执行计划	调控并解决问题。执行计划期间难免会遇到变动及挫折。应予以正视，若原方案无法继续，主动寻找可替代的方法并解决问题。	激励项目进行。鼓励团队成员，或者自己去推进项目。在完成里程碑时适时奖励自己。
成果产出	预期项目将会达到什么样的成果。比如吸引哪些用户、用户对应用的满意程度如何。	根据用户反馈，安排应用下一步更新的计划。考虑收到的那些意见符合应用的设计初心、应予以添加，哪些不做考虑，哪些新技术可以被纳入考虑，是否有新机遇。考虑竞品的表现，制定提升产品竞争力的策略。

领导与员工最大的区别在于需要承担责任。对于独立开发者来说，你便是自己的产品或小团队的领导，你做的选择会有后果，好的坏的都有可能。比如你花费了几个月的时间，产品定位不佳导致没有受众，或只是因为突发事件让你想做的市场并被别人抢占了，最终应用失败。这几个月的时间精力的付出确实流失了，你需要接受结果，汲取经验，然后换条路重新出发。

c、评估商业环境 Business Model Canvas

重要伙伴：谁能帮到你？若你需要内容，谁为你供货？
关键业务：为确保商业模式可行，你的应用需要做哪些事情？
核心资源：你有哪些资源？
价值主张：用几句话概括，你的应用能为你服务的人群创造什么价值？
客户关系：你的应用怎样与客户交流？如何维护客户关系？
渠道通路：别人如何找到你的应用？
客户细分：你的应用解决了谁的问题？服务哪几类人群？
成本结构：你要付出些什么？运作该应用所需的有哪些成本？
收入来源：你有哪些收入渠道？能得到什么？

以下图中的健身运动应用 KEEP 为例，首页开屏即可看到它的价值主张。在不同页面切换时，你还会看其客户关系、收入来源等信息。你也可以下载这款应用并熟悉其界面，根据上文对每个区域的介绍，尝试分析并得出该应用的商业模型画布。

Keep

下图是对其应用商业模型画布得出的结果。

商业模型画布

d、制定发展策略及方向

专注：将精力投入产品的某一个功能点并加大投入。
成长：市场渗透 - 增加推广投入来提升应用在当前地区的销量；区域扩张 - 将应用的服务范围扩大到新的市场；产品开发 - 改善产品及服务，并提升产品力。
整合：垂直整合 - 增加对同一产品上下游需求的整合，比如之前你的应用使用的是官方库提供的功能，现在可以考虑购买优秀第三方库的版权及功能；水平整合 - 购买或布局同类型产品，降低竞争对手或合力发展。
多样化：关联多样化 - 增加同一产品的新功能，比如 Procreate 增加了动画制作的功能；多元化经营 - 增加全新的产品或应用，比如 Procreate 增加了为手机研发的 Procreate Pocket 新应用。
降低成本：去除不必要开支，比如之前外包的活自己做，削减某一功能上的人力物力投入。

比如你有多个想法等待被做成应用，但分身乏术，此时可以考虑专注的策略，选择你最想实现的想法并投入其中；比如你的应用在中国区市场表现不错，但营收并不令你十分满意，可以考虑成长的策略，加大对海外新市场的布局；比如你的应用与其它应用提供的功能相近，可以考虑多样化策略，为应用增加一些定位独特的小功能。

二、构思产品

1、寻找灵感

灵感来源于生活。许多视频博主都会做这样一个挑战，将地图贴在远处的墙上，蒙着眼睛扎飞镖。博主和观众约定扎到哪里就去哪里。落到实处，我们可以创造一个能展示随机城市名的界面。提供一个随机按钮，用户按下后，程序直接显示出城市名好像有些枯燥。那么用带点赌博性质的游戏开箱子的机制如何？似乎更有娱乐性一些。我们可以将正面有随机城市名的卡牌背面朝上，当用户翻牌时，卡牌不会立马反面，而是会播放一个小动画拉高用户期待。

2、目标用户

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

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

3、可行性验证

有了灵感之后，你是不是着急着想要开始制作了？试想你在拼装一个迪士尼乐园的乐高玩具，你会如何规划拼装流程呢？你也许会按照说明书一步一步来，先完成塔尖、完成大门、最后完成城堡的安装。城堡本体安装完成后，虽然距离迪士尼乐园建设完成的大业还有很长距离，但你已经可以看出这一项目的基本雏形。在以上的设想中，我们将具体的创作流程分为以下三个阶段。

a、灵感萌芽 Ideation

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

b、基本可行性产品 MVP（Minimal Viable Product）

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

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

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

c、迭代周期 Design Cycle

在不同领域中，迭代周期的概念被广泛使用，重复推进这一循环的步骤可以帮你更好的推进当前产品。收获了产品反馈后，做产品的人通常会选择两个方向继续前进。一类人会将 MVP 完善后直接推向市场，由市场反馈决定接下来的需求和迭代方向；另一类人会继续坐下来完善产品，直到期望的所有功能都完成后再推向市场。无论你是哪类人，你可能都要面对产品迭代的周期来对不同功能点，根据反馈评估，对产品进行更新，最终完善产品。这一流程一般来说是一个完整的设计、思考与评估闭环。

完整的设计、思考与评估闭环

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

4、记录需求

a、需求列表

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

b、核心需求

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

c、优化需求

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

5、设计考量及 UI 框架

a、目标设备

已经有了需求，接下来我们便来将需求对应的设计落地。这个应用放在什么地方比较合适？便是对目标设备的考量，对于一款生成随机地名的应用来说，最适合的使用场景很可能是手机，因此我们将其作为主要考虑对象。Apple Watch 似乎也是不错的候选对象，且应用迁移成本较低，因此也纳入考虑。

初版设计如下。应用的核心部分便是生成随机城市名的卡牌，因此占据最高的视觉权重。搜索的自定义范围作为用户的常用功能，被安排在了界面的下方。

初版UI设计

你可能会发现我们这个随机城市应用翻牌前后界面差异巨大，这便是得益于 SwiftUI 视觉框架可灵活拼装的特性。在 iOS 端，用作生成应用程序界面的代码我们称作 UI 框架，它的目的是把设计好的产品原型变成应用可以执行的代码。比如上图中，我们的产品设计原型由 Sketch 制作而成，接下来，我们便需要将这个设计作为代码落地。

b、视觉框架

在 iOS 生态系统中，常用的视觉框架有三种。第一种叫做 Flutter，它是由 Google 主导开发的 Android 与 iOS 跨平台 UI 框架，目前使用此技术的代表应用为阿里巴巴的闲鱼。Flutter 底层的语言是 Dart，有额外学习成本；其次是 Flutter 并非 Apple 第一方框架，因此使用中遇到的小毛病不方便获取 Apple 官方支持，个人不太推荐。但若你感兴趣，Flutter 描述性语言的特质与本教程学习的 SwiftUI 概念类似，你可以比较容易地做知识迁移。

第二种 UI 框架叫做 UIKit，它由 Apple 官方出品，是过去十余年 iOS 界面开发的主力军。在 UIKit 的世界中，UI 适配各种不同机型屏幕尺寸机器的技术称作 Auto Layout 自动排版。

UIKit 的视觉编辑器，叫做 Storyboard。顾名思义，它允许开发者将应用程序的不同界面像制作故事板一样，依次排开在编辑器的界面中。左侧的是 UI 的大纲界面，开发者通过此面板来了解界面要素的层级关系。右下角展开的界面为自动排版的面板。

Storyboard

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

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

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

每个视觉元素在某件事情发生时都会提供一系列状态控制的通知函数，积少成多，一个看似普通的界面往往需要几十个控制界面状态的函数堆放在一起以实现理想的界面逻辑。这些控制函数放在一起，我们称作 ViewController 视觉元素控制器。这一文件常常因为控制界面状态的函数过多而变得非常大而被开发者戏称为「过度肥胖」。

当控制界面的函数过多时，就容易在开发者不注意的地方产生冲突，也就是程序 Bug。当控制界面因函数过多而变得复杂时，我们便很难继续处理好每一个界面间的关系，而需要投入大量精力来寻找原因。

难道就没有一个更好的方法了吗？答案是有的，这便是第三种 UI 框架 SwiftUI。SwiftUI 是 Apple 官方于 2019 年发布的最新 UI 框架，它在 UIKit 上更近了一步，不再是提供一套一致的界面来强行适配不同平台，而是根据不同平台因地制宜，在不同平台上，用符合该平台设计规则的方式将界面元素呈现出来。

还记得之前提到的界面不够灵活、界面状态管理繁杂的问题吗？SwiftUI 从根本性解决了这两个问题。SwiftUI 不需要你明确给出每个界面具体受哪些条条框框的限制，你只需要告诉描述出你希望的界面与其它元素的逻辑位置关系即可。

示例

import SwiftUI

struct ContentView: View
{
    var body: some View
    {
        HStack
        {
            Image(systemName: "swift")
            Text("你好，谢佳培，SwiftUI欢迎您")
        }
    }
}

struct ContentView_Previews: PreviewProvider
{
    static var previews: some View
    {
        ContentView()
    }
}

比如上图中界面里的例子，我们希望左侧有一个 Swift 的图标，右侧是一段文字描述。具体到代码来说，我们只需要向 SwiftUI描述：横向排版 HStack { 图片Image + 文本Text} 即可。使用SwiftUI的流程更像是在和电脑对话，你将你想要的界面描述给它，至于如何显示、间距、界面状态等复杂事物都由电脑操心。也正因为SwiftUI高度灵活、可自由组合的特性，我们才可以实现随机城市中翻牌后截然不同的两套界面。

SwiftUI 不在乎你的背景如何，非常易学易用，且具有极佳的跨系统支持。但同时你需要认识到 SwiftUI 是一款新生框架，处在逐渐完善的过程中。比如 UIKit 所支持的 CollectionView 或者 Activity Indicator 这些成熟界面元素的替代品，SwiftUI 在 2020 年才给出以上界面的官方支持。

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

c、各平台的思考

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

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

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

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

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

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

6、寻找支持

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

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

那么什么时候是寻找帮助和支持的最佳时机呢？在你的构思流程基本完成、可以阐述你的产品想法时，便比较适合向了解行情的人寻求建议与支持。独立应用开发最大的消耗便是你个人的时间成本，当你的产品在 MVP 阶段时，便比较适合寻找孵化器或者天使投资人加入其中。

也许你的初心便是创作一款心中所想的应用，但你必须意识到，与你自身不同，外来资本的介入需要投资回报，因此你必须让利。是否寻求外来资本的帮助与介入，需要你自己根据实际情况来做判断。

三、开发产品

Swift 负责应用程序逻辑，SwiftUI 负责 UI 界面，系统框架负责提供让创作者使用设备上不同功能的途径。

1、Swift语言

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

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

var isCardFaceUp = false
let potentialNames = ["上海","北京","成都"]

let cardFront = "?"
let cardBack = potentialNames.randomElement()

print(isCardFaceUp ? cardFront : cardBack)

2、SwiftUI的DSL语言

a、UI 界面的构建

SwiftUI 是一款 DSL 语言，全称为 domain-specific language，它具有专有语法来实现专有用途。若你将 Swift理解为日常用语，那么 SwiftUI 便好像是一系列专业术语。它依托于日常用语，又依靠独特词汇提供了日常语境中不涉及的专业内容。

对于 SwiftUI 来说，它可以理解 Swift 的语法，因为这是它的基础。与此同时，SwiftUI 还具有一些专用的语法结构，用来实现 UI 界面的构建逻辑。

UI 界面的构建

上面你看到的便是将我们刚刚写好的最核心 Swift 逻辑放入 SwiftUI界面中的效果。对于SwiftUI来说，任何我们在程序界面上所看到的东西都属于它的能力范畴。比如一个可滑动的视图，视图中滑动的手势、按钮、图片、动画效果、图片边的阴影等等都属其中。

将 Swift 带来的逻辑与 SwiftUI 带来的 UI 界面相组合，我们便得到了此应用程序的核心功能。上图中代码的运行效果如下。

运行效果

b、项目运行顺序：App > Scene > View

创建 Xcode 项目时选择的 Multiplatform App 是一个跨平台模版，使用此模版创建的应用程序会自动包含运行在 iPhone、iPad 与 Mac 上的能力，并具有起始代码。在这个模版中，真正负责执行命令并在虚拟机中显示文字的只有 LegolasDemoApp 和 ContentView 文件中的代码，如下图所示。若你也在跟着操作，可能会发现此图中省略掉了 ContentView 中的后半部分代码，并将其前半部分代码与 LegolasDemoApp 中的代码拼合在一起，程序依旧可以顺利运行。

范例应用中 LegolasDemoApp 与 ContentView 两份文件拼接在一起

程序运行的完整流程如上图。Xcode 通过@main找到起点后，创建了LegolasDemoApp的应用instance实例来运行，此实例使用WindowGroup Scene来显示ContentView里的内容。应用运行时，显示的场景内容是 ContentView 的 instance 实例。依次而下，最终将 ContentView 里 body 的内容显示在屏幕上。若你目前对这个流程感到困惑也没关系，毕竟还没有学 Swift 编程语言，但你可以根据上面图片里的流程图大致感受一下应用程序的运作。

为什么将代码拼接在同一文件中也行呢？这是因为在同一个 Xcode 项目中，所有不同.swift文件中的代码都会被执行，因此开发者将代码放在不同文件、或是在同一文件中本质上没有区别。正因如此，可以将这两部分的代码拼合在一起。你操作时不需要这么拼接，但你需要理解代码放在不同文件中的缘由，更大程度上是为开发者的阅读及管理而已，并不一定需要分开。

c、项目与目标的关系：Project - Target

Project - Target

在创作应用程序时，我们时常需要考虑登陆不同平台，比如 iOS 和 macOS。如何根据不同平台的设备提供不同的功能，规划一套分类管理系统呢？Xcode 给出的这套分类系统便是 Project - Targets，即项目 - 目标，它允许开发者将不同需求的资源从主项目中划分给不同目标。针对一个项目 Project，如 LegolasDemo，可以设定多个不同目标 Target，如 iOS 和 macOS。

你可以将 LegolasDemo 这个根文件夹，看作是 LegolasDemo 应用所需要的全部代码、图片等内容的资源的集合。在理想情况下，我们也许希望应用在所有系统下使用完全一样的代码。实际情况却常告诉我们说这不现实，比如你有一套负责震动体验的代码，由于没有振动马达，这套代码放在 iPad 或 Mac 上则毫无价值。

把 Xcode 程序项目称作一个 Project，你可以在这个项目下创作许多目标 Target。当想要管理 Project 和 Target时，它们有什么区分呢？Project 作为项目的最高层，负责管理这个项目中采用什么第三方库等基本信息。而旗下的每一个目标 Target，需要开发者提供一系列与目标平台相关联的信息。

3、系统框架

在代码落地的讨论范畴中，我们还缺最后一片拼图，这便是系统框架。那么什么是系统框架呢？系统框架也被 Apple 官方列在科技列表中，它代表的是一系列设备本身所具备的硬件能力。这些能力经 Apple 工程师之手规整好，之后将更容易理解，可直接使用的函数直接开放给开发者，便形成了框架。这些框架可以由创作者根据自身需求自由选用。

框架的涉及范围也非常广泛，比如负责云数据同步的 CloudKit 框架、负责 AR 交互的 ARKit 框架、负责异步事件处理的 Combine 框架等等。以随机城市中我们想在翻牌时用到的触觉反馈为例，我们需要使用的便是这些技术框架中的Core Haptics 框架。这一框架允许我们自定义手机的振动方式，并像录制音频一样准备好一段非常独特的震动反馈。

系统框架

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

四、应用上架

1、应用打包

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

应用打包

2、商店审核

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

3、App Store Connect

这是你与 Apple 商店团队、以及用户的衔接桥梁。应用程序上架后，你可以在 App Store Connect 中做更新内容的提交、用户评价的反馈、销售数据的查询等事情。

App Store Connect

4、应用营收

当你的应用程序开始满足用户需求时，用户便会以不同方式来支持他们喜欢的应用。常见的营收选择有一次性购买、广告、应用内购、自动订阅等方案。针对应用的属性，你也可以自由选择一种或多种营收方案的组合。

五、获取用户

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

1、产品描述

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

产品描述

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

2、广告

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

3、多媒体渠道

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

4、权重优化

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

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

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

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

五、更新维护

1、Bug 反馈

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

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

2、更新公告

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

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