app开发 从不懂 iOS 开发到 App Store 上架，开发过程和经验全分享

应用简介

我做的应用是 Seamless，一个基于 CloudKit 的文件和文本传输工具，目前有 iOS 版、Mac 版以及网页版。除同步文件外，Seamless 的 iOS 版也是一个剪贴板应用。

应用从开发到上架历经九月，开发时间为工作日晚上和周末。在此分享整个过程所经历的事情，及一点经验和见解，希望能为同样有志于 iOS 开发的朋友提供些许帮助。

为什么开始 iOS 开发，应用想法如何诞生？

WWDC 2019 时，看到 SwiftUI 的发布，我有点兴奋。因为全职工作是前端开发，而 SwiftUI 一眼望去和平常写的 React 相似；平时对独立应用开发兴致勃勃，有好些项目都开了个头。我想 SwiftUI 应该能降低 iOS 开发的入门成本，说不定写起来真的和 React 差不多（剧透提醒：不是的）。于是我就想，我能做一个什么 App 呢？

想来想去，只能从自己的需求出发。

我平时不在工作 Mac 上登录微信，但有时候需要在微信上分享一些电脑上看到图片或文件。用多了 AirDrop，其实会发现 AirDrop 也没那么方便，配对过程有时会过长，而且 AirDrop 没有文件管理。

许多人为了同步文件和文本，往微信的文件传输助手发文件或文字。但这种方式的缺点也显而易见：文件有过期的风险、文件管理过于简陋。思索着这个需求的解决方案有值得优化的地方，于是 Seamless 应运而生。

所以*早的开始，Seamless 的定位就是一个更好的文件传输助手。

自己的需求靠谱吗？

为自己开发是比较容易的，但自己的需求不一定通用。上架三个月以后，Seamless 的销量不尽人意，这里面有推广的问题，也有应用需求的问题。

如果你开发应用不仅仅是为了入门和学习，那么确认需求前，*好看看 App Store 是否有同类应用，和身边的朋友聊聊自己的应用想法，获取一些外界输入，确定这个应用是否真的有需求。

我觉得现状是，如果一个应用在 App Store 没有大量同类型应用，那么大概率是它没有大量需求，而不是你的想法绝妙。

所以选一个热门分类，然后比同类 App 做得更好比埋头做全新的产品有更大的概率获得成功。记账、To-Do App、笔记 App 等品类都非常热门，需求是已经验证过的。

开始学习 Swift

我平时写的语言是 JavaScript，对 iOS 开发的所知有限，大概就是知道需要 Mac 和 XCode，以及要会 Swift 语言。兵马未动，粮草先行。于是我开始学习 Swift，学习资料是由志愿者翻译的官方文档《Swift 编程语言》。

虽然我是程序员，但如果正在阅读的你并不懂程序开发，我觉得也不要让这个成为你的绊脚石。除开在程序语言学习和编程经验上有优势外，iOS 开发和前端开发差别颇大，包括使用的工具、代码的组织形式等。绝大部分 iOS 开发相关的知识这些对我而言也是新的。

Swift 当然不是 iOS 开发的必需，现在有很多可选的跨平台技术方案，比如目前较热门的 Flutter。但据我观察，iOS 开发的盈利概率和水平仍是较高的，而采用原生的技术开发的 App 能提供*好的体验，这相对提高了盈利可能。

如果你不知道该选跨平台技术还是 Swift，那么你就应该选 Swift。

开始学习 SwiftUI

Swift 语言上手以后，我就开始学习 SwiftUI 了，学习资料也不过是苹果官方的 SwiftUI 文档，当时除了这个以外，也没有其他的了。我跟着这个 Swift Tutorial 一行行地写，学完之后的心情如下图：

当时的 SwiftUI 还是**个版本，许多功能不完整，而且相关学习资源稀有，对于初入 iOS 开发的人来说，一旦遇到问题就很容易落入困境，难以解决。再加上自己三天打鱼两天晒网的性格特点，学一阵子后我就弃 SwiftUI 而去，应用开发就此搁置，此时仍是 2019 年，世界仍和往常一样。

开始学习 UIKit

时间快进到 2020 年。

WWDC 2020 的新闻让我想起了这个应用，总不能一次次地挖坑而不填坑，于是一狠心一咬牙，在 WWDC 2020 前订阅了苹果开发者帐号。那时候我已确认 SwiftUI 还不是成熟技术，UIKit 仍然是首选，于是开始学习 UIKit。

UIKit 的学习资源非常丰富，我当时看的是 Programming iOS 13，遇到某个书中没有详解的知识点时再搜索相关文章。iOS 社区非常活跃，许多问题都能在 Stack Overflow 或者 iOS 开发者的博客看到解决方法。

如果你是一个没有编程经验的新手，那么在搜索相关答案时，尽量还是使用英文关键字和对英文搜索支持更好的搜索引擎（Google 或者 Bing 都可以）。

SwiftUI 还是 UIKit？

随着 WWDC 2021 的发布，SwiftUI 也已到了第三个大版本。经过两年沉淀的 SwiftUI 不再像两年前那么孤零无助，已有着非常丰富的学习资源。

现在国内有由 Objc 中国出版的不错的 SwiftUI 套装，国外也有斯坦福出的公开课 CS193p，Hacking with Swift 的 SwiftUI by Exmaple，以及诸如 Design+Code 的各种各样的付费课程。

如果你现在需要做一个应用的话，SwiftUI 是更好的选择。

iOS 14 新添的桌面小组件只能由 SwiftUI 实现。iOS 15 更是带来了由 SwiftUI 重写的天气应用，SwiftUI 在 iOS 系统应用里也有了一席之地。SwiftUI 是苹果平台应用开发的未来，但这个未来更近了。

UIKit 尽管更成熟，有更多的解决方案。但 SwiftUI 有高得多的开发效率和上手速度：我用 SwiftUI 画过一个 App 的原型，只需区区数十行代码。

过去四年发布的 iPhone 里，有 90% 运行着 iOS 14。按照以往经验，iOS 15 发布后，很快就有大量 iPhone 升级至*新系统。这意味着，如果你现在开始规划一个 App，那么它的*低要求系统可以是 iOS 15，这样你就能用上*新的 SwiftUI。

需求文档

虽然需求来源于自己，但这不意味着不需要需求文档，这只意味着你可以以任何方式来记录需求。而 Seamless 的需求文档*早是一篇用 Bear 写的笔记，里面解释了应用的基本功能。后续的开发过程中需求逐渐明确，文档滞后于实际产品，反正脑海里产品已明确，索性不再更新文档。

需求越来越清晰后，我就开始用 Things 管理项目。在 Things 里新建项目，然后新建「功能」、「Bug」、「其他」等标题，再在标题下添加待办事项。

项目管理是整个应用的生命周期里都是必不可少的。如果我要开发下一个应用，那么我会在项目开始就引入项目管理。而管理工具我觉得选择自己*喜欢的 To-Do App 即可。

原型

*早的原型是我用中性笔在 A4 纸上画的。绘制的过程也是产品的规划过程：界面有几个 tab、每个 tab 表示什么、列表需要展示什么信息。

当然，我知道有更专业的原型工具，但我比较抗拒这里的软件学习过程（就是懒），所以我的原型仅仅停留在页面元素展示，没有任何的交互过程。

我后来也体验过一些在线原型应用，比如用 Whimsical 画线框图也有很不错的体验。

设计

设计是许多程序员难以逾越的问题，我也不例外。

Seamless 的设计并不出众，在你有过硬的设计能力前，尽量贴近原生风格是不错的选择：Seamless 的设计参考了 iOS 的「文件」应用和 macOS 的「访达」应用，大部分组件也是原生 UIKit 组件。

苹果官方的 Human Interface Guidelines 是必读的，除了解苹果的设计语言外，里面罗列了系统自带组件以及其使用场景，在设计应用交互时获益匪浅，即使从头到尾地粗略翻翻也能获取不少新知。

应用图标

应用图标是不少人的难题。Seamless 的图标我也不觉得「好看」，但与许多个人开发者自制的图标而言，这个图标可谓「不丑」。

我本身没有使用设计工具的经验，Photoshop、Sketch 之类的甚至没有安装，唯一安装的设计软件只有 Pixelmator Pro，所以 Seamless 的图标是在上面完成的。

图标的概念很简单，就是云和闪电作为主题，星星是装饰。有了图标概念后，就要开始绘制，而我是不会使用这些作图工具的，那应该如何是好？

我开始在网上找免费的图标库，然后找到里面的云、闪电和星星，再全部拖到 Pixelmator Pro 里面拼凑。但事实是，找到合适又免费的图标库要比想象中难。后来我灵机一动，想起苹果在 WWDC 2019 发布的 SF Symbols 是可以导出 SVG 文件的。

导出这三个图标的 SVG 文件，然后拖到 Pixelmator Pro，拼拼凑凑，这里点几下那里点几下的就解决了图标问题。

现在我年纪更大，更有智慧了，发现用 Figma 的图标模板做图标更快更好，我也建议大家用免费的 Figma，然后配合 SF Symbols 做图标。

图标完成后，还可以使用 Asset Catalog Creator 导出符合 XCode 标准的 Asset Catalog。

AppKit

Seamless 除了 iOS 版本外，还有一个由 AppKit 开发的 macOS 应用，而 AppKit 的问题是遇到了问题找不到答案。所以 Seamless for Mac 的代码量虽然远远少于 iOS 版本的，但给开发过程带来的心理负担却也不小：这东西到底该怎么弄，怎么文档一点用都没有，苹果到底在干嘛，我 100 刀的服务费就换来这样的东西？

如果你的应用一定要有 macOS 版本而且 Catalyst 不符合你的要求的话，那么开源 macOS App 项目是很好学习资料和参考对象。我在开发过程中主要参考了 RSS 阅读器 NetNewsWire 的实现。

或者也可以直接用 SwiftUI 写 macOS 版本，不过这方面的经验我也不多，仅提供一个想法。

应用审核

作为一个经验尚浅的的苹果开发者，我认为苹果对新应用的审核较严格，而后续的版本更新一般能在 24 小时内通过，有时甚至能在一小时内通过。

Seamless 的**次审核通过耗时三周，期间被拒绝三次，大部分时间都在等待苹果审核。

所以我觉得不要等到功能全做完再提交审核，当你觉得完整功能大概还需一月就能完成时即可提交审核。提交审核后是否上架在于开发者，但其实上架也无妨：反正也没人下载。

应用网站

有一个应用网站能带来不少好处，因为网站能容纳更多内容，而且无需苹果审核。除了必须的隐私政策和基本的应用介绍，你还可以附上用户协议、帮助指南、常见问题、社交账号等。

如果你的应用功能较多，并且你希望长期运营应用，那么搭一个应用网站，宣传应用时把流量指向网站也是不错的。

建站的教程有许多，这里我不细谈。Seamless 用的是免费的 Vercel 和开源项目 Next.js，整体体验非常好。

如果你需要分析网站访问，那么可以使用有着简单清晰控制台的 SplitBee 而不是 Google Analytics 或类似的老一代产品。在产品初期阶段，免费版应该足矣。

本地化

英语是必须的，不然你就失去了完整的国际市场。

虽然 Seamless 的用户还是以大陆用户为主，但原因也不过是因为我更熟悉中文互联网，能在许多中文网站上推广。而据我有限的英文网站推广经验而言，美国用户的付费率较高，如果你的应用能受到大陆用户欢迎，那没理由放弃付费率更高的发达国家用户。

如果你对自己的英文没有信心，那么就认真做好简体中文，然后直接使用广受好评的 DeepL 翻译完成英文版本。