Matrix 首页推荐
Matrix 是少数派的写作社区,我们主张分享真实的产品体验,有实用价值的经验与思考。我们会不定期挑选 Matrix 最优质的文章,展示来自用户的最真实的体验和观点。
文章代表作者个人观点,少数派仅对标题和排版略作修改。
看到标题的你可能已经在嘀咕,「又一个倒数日 App,为什么?」
一年前,我刚完成 Browser Deputy 的开发,一个可以通过全局快捷键搜索浏览器书签的原生 Mac 应用。实际上它还有很多功能,比如可以添加自定义的搜索引擎和脚本,支持搜索当前应用的菜单项等。我在这里提及 Browser Deputy,并不是为了给它带来一点曝光度——它已是一个失败的项目。我想探讨背后的原因,一个使得我最后决定开发一个倒数日 App 的原因。
一个产品失败自然有很多原因,比如:
Browser Deputy 可能有上述的全部问题,但在我这里,失败的门槛很高,问题也可以被解决,这些问题都不足以让我把它列为失败。它真正失败的原因是没有简洁清晰的产品定义,而这个问题是应用诞生伊始就存在的,解决这个问题意味着做一个新的产品。这也导致我在介绍这个应用时,只能罗列它的功能,试图让读者通过具体的功能去想象这个应用。而简洁清晰的产品定义是这样的:「To-Do App」。你不会用「可以记录提醒事项并标记为完成」这样的字眼去描述 Things。
简洁清晰的背后是共识。换言之,与其去解决一个个具体的问题,然后打包成一个产品,不如在已经已有的门类里做一个产品,然后加入新功能。
完成 Browser Deputy 后,我也没有立即开始构思下一个产品,而是用了四个月的时间,推出并迭代 Anybox 2.0。Anybox 是 macOS/iOS 上的书签管理工具。瞧,原来我早就知道简洁清晰的产品定义是什么样的。
我在 Things 里有一个 Ideas 项目,里面记录着许多想法,有些是灵感,有些是长期的思考总结。去年十月的某天我开始考虑下一个项目是什么。
这个项目首先得是个 iOS App,这样才有比 Mac App 更大的市场;然后它的功能简单,对技术的要求不高,这样才能在三个月后发布。
于是我打开了 Things 的 Ideas 项目,里面的 iOS 主题下有:
老实说,我已经忘记烟花小组件和节气小组件是什么意思,但我猜当时我脑子里一定有着很美好的画面;简单的资产管理其实实现起来不简单,想想就知道;体重记录是想模仿喝水羊驼的设计,比如如果你的体重超过两百斤,那么你在应用中会看到一只熊;看来看去,只有纪念日/倒计时 App 满足前提,并且有广大受众。
我的执行力是脉冲式的。
决定好做倒数日 App 后,我就开始想应用名称,从过期的 .app 域名里找合适的,很快就注册了 pinning.app。但一个月后我才开始创建项目,进入产品设计和实现阶段。
倒数日 App 的历史几乎和 App Store 一样长。它受到的开发者关注虽不如 To-Do 工具,但新鲜的倒数日 App 也的确源源不断。
奇怪的是,如果你在 App Store 内搜索「倒数日」或者「countdown」,你会发现时光在这些热门倒数日 App 上似乎停止前进了。下载量最高的这些倒数日 App,有些有着过时的设计风格,有些有着放在任何时代看起来都很奇怪的图片背景,有些有着可谓简陋的设计。这些应用当然都能完成工作,但现在是一个天气 App 会和你讲笑话、日记 App 会和你说加油的年代,这些应用却停止了进化。
难道用户想要的就是这些吗?Things 是 App Store 的第一批应用,于 2008 年 7 月上线,至今仍在更新,不断改进。最老的也可以是最好的。
如果你把 App Store 的搜索结果页翻滚到后面,你会发现新鲜面孔。这些 App 有现代或另类但绝不老土的设计,有更多的功能和更友好的交互。但老实说,我也未发现有任何一款应用具备了我心目中最关键的功能:iCloud 协作。
我是苹果提醒事项 App 的用户,平常会和家人通过共享列表记录如购物清单这样的生活琐事。因此当我思考倒数日 App 的功能时,第一个想到的就是,通过 iCloud 协作共享生日、恋爱周年纪念日、结婚纪念日等特殊节日,不重复记录。其他的功能,如农历、按日/周/月/年重复等,都是必不可少的基础功能。
有着大概的功能列表后,我就开始着手代码实现了。
作为上线过多个应用的个人开发者,我已不会在前期产品设计上花费太多时间。因为你总会在原型文档或原型图遗漏某些细节,但在编码实现时,每一个你设计时遗漏的细节,都会以 Bug 的形式出现,让你无法忽视。而且编码也是思考的过程,随着代码量的增多,App 也越来越具体,届时对于功能的判断也愈加准确。
我在这篇文章《从不懂 iOS 开发到 App Store 上架,开发过程和经验全分享》里介绍过自己从网页前端开发入门学习 iOS 开发的经历。文章内有个章节是关于技术选择的,其中谈到 2019 年苹果在 WWDC 发布的 SwiftUI 让我对 iOS 开发建立了信心,但试过之后,发现 SwiftUI 存在着太多问题,于是我最终决定使用 UIKit 开发我的第一个应用 Seamless。后续我发布的应用,大多也是基于 iOS 的 UIKit 和 macOS 的 AppKit。
但 SwiftUI 已经来到了第五个版本了,愈加稳定和成熟。
在 WWDC 2023 的 State of Union 上,苹果的高级总监 Josh Shaffer 说「The best way to build an app is with Swift and SwiftUI.」
再顽固的 UIKit 拥趸,也不得不跟着 Apple 指的方向走。事实上,苹果这几年也发布了一些 SwiftUI Only 或更友好的框架,如小组件就只能通过 SwiftUI 实现。
最近迎来发布十周年的播客应用 Overcast,其作者 Marco Arment 也在新版更新中把 App 的语言和 UI 框架由 Objective-C 和 UIKit 转向了 Swift 和 SwiftUI。
我相信 UIKit 在短时间内不会消失,因为苹果有着比任何公司都多的 UIKit 代码库。
但作为苹果平台的开发者,在技术趋势上,只能顺势而为,所以在 UI 框架上,Pinning 选择了 SwiftUI。
我这几年写的 UI 代码还是以 UIKit 为主,对 SwiftUI 的理解并不深,对更高级的性能优化更是一无所知,而 SwiftUI 的列表是很容易出现性能问题的。
无论什么技术,最终目的都是为了给用户带来更好的体验。但我也没有兴趣和时间去研究 SwiftUI 的性能优化,所以我在边栏和事件列表页面上也毫不犹疑地选择了通过 UIKit 实现,以此保证用户能流畅地滚动列表。除此之外,Pinning 的其他页面都由 SwiftUI 实现。
事实证明,选择 SwiftUI 是个正确的选择。
看似简单的倒数日 App,却有着出乎意料多的 UI。如果项目一开始选择了 UIKit,有些功能如自定义重复,可能就会因为复杂的 UI 而被放弃。项目的进度和更新也会比现在慢。
我说过我是提醒事项 App 的用户,对吧?如果你不记得的话,那从 Pinning 的边栏设计里一定可以看出来。
在最开始想如何设计边栏时,我就想到了提醒事项的设计:从上到下为内置列表、自定义列表;内置列表采用卡片设计,每行展示两个。这也是 Anybox 边栏的设计。
但我最初没想到的是,倒数日、提醒事项以及日历日程三者有着很多共同点,甚至可以说三者的相同之处要远多于不同之处。当我明白这点后,在做 UI 时,参考应用不再是现有的倒数日 App,而是日历和 To-Do App,这也使得 Pinning 更像一个效率工具。
而主页的事件展示,我考虑过列表和卡片设计,但为了新意,最终决定使用在查快递时常见的时间线设计:左侧显示日期,右侧显示内容。但列表设计实在太常见了,而且有着更大信息密度,所以也在应用内加入了列表视图,以供切换选择。
事件详情的设计本意是为了更好地以图片在社交网络分享事件,所以在字体方向上选择居中,通过主题色和较大的字体强调内容。但当应用功能开始偏向效率工具时,我意识到这样的设计和效率工具的风格并不一致,所以我一度放弃字体居中和主题色,以类似日历 App 详情的、更简洁的方式展示事件信息。但风格一致的设计反而没受到好评,所以我最终决定保持原有设计,用「纯粹的效率工具是无聊的」这样的话来说服自己。
看完前面这些文字,你肯定还是不明白 Pinning 和已有的 App 有什么不同。所以我决定以列表的形式,逐一介绍它的功能。
Pinning 在今年三月初上线,上线时并没有这个功能。当我在 Anybox 的用户群里介绍这个应用时,收到的第一个 App Store 评论就是说不能同步日历。当时我看到这个三星评价其实有点生气:「为什么倒数日 App 需要同步日历?而且你已经可以很便捷地从日历中添加事件了。」
但当气消之后,我开始思考这个评论:既然我都可以直接从日历中添加事件了,为什么不能直接同步日历呢?我想不出为什么,所以在两个月后,同步日历功能上线了。
既然可以同步日历了,同步计划的提醒事项自然也是应该的。
提醒事项的优先级本来比较低,毕竟日历的用户远多于提醒事项的。但今年六月的 WWDC 大会上,苹果宣布 iOS 18 的日历 App 中可以直接显示计划的提醒事项,这让我不得不提高同步提醒事项的优先级:系统内置 App 有的功能,用户会理所当然地认为第三方 App 也应该有。
iOS 会自动订阅当地的节假日日历,通过同步日历功能,Pinning 用户可以清晰地看到下一个节假日还有多久到来。
同步日历是我最喜欢的功能,因为即使你不在 Pinning 内添加任何事件,你仍然能把 Pinning 作为效率工具的一环,在 Pinning 查看日历日程。
你可以在 Pinning 内添加三种类型的事件:生日、纪念日和通用事件。
和日历一样,Pinning 也支持为事件添加备注、URL、推送通知等。
还可以为事件添加 SF Symbol 或者 Emoji 图标,设置时间显示单位,设置标签等。
你还可以把事件加入到某个记事本,以实现事件分类。
此外,你还可以从直接日历中添加事件。
记事本是 iCloud 协作的基本单位,你可以把事件加入到某个共享记事本以实现共享事件,但不能直接共享某个事件。
很多倒数日 App 都有类似文件夹的功能,但当你在这些 App 添加事件时,你不能控制某个事件的事件显示单位,但事实上有些事件确实不需要知道已经过去多久,这样的设计反而会让人觉得繁杂。
在 Pinning 内,你可以精细地控制每个事件的时间显示单位。
比如对于大学毕业那天,你可能只想知道过去多少个年与月;而对于爱情,你可能想知道过去了多少天;而对于诸如项目进度的事情,你可能只想知道具体的日期。
我在 Pinning 中有个列表就叫 Pinning,用于记录 Pinning 的项目相关,如发布日、新版本更新等。配合「新版本」标签和事件间隔显示,我可以方便地看到上一个版本的发布日期,以及两个版本之间的间隔时长。
配合 Pinning 的分享时间线为图片功能,你可以在社交网络上分享某个项目的时间线,这个项目可以是恋爱时间线,也可以是申请大学进度、签证、甚至是人生关键节点。
Pinning 内置 8 个列表,这些列表本质是智能列表,即根据不同的条件过滤事件,以适应不同的需求。
当然,不是每个人都需要如此之多列表。所以在 Pinning 里,你可以隐藏任一内置列表,也可以调整列表顺序,甚至置顶某个记事本。
我不是小组件的重度用户,使用的小组件都是 iOS 的智能叠放,提醒事项、设备电量显示、照片之类的。我的其他 App 也不以小组件为卖点。但我也明白自定义小组件 App 是很热门的一个分类,好看的小组件也是很多人下载一个 App 的理由。
显而易见,对于倒数日这种 App,小组件必不可缺。所以我在项目开始就把小组件放在了功能列表里,花费了很多功夫去设计和实现小组件,但没想到还是在这上面栽了一跟头。
我最初以为,小组件的大小在不同设备上虽然不一样,但大差不差,只要在我的 iPhone 12 上看着还行就可以了。但直到用户向我反馈了 Pinning 小组件的截屏,其中标题被挤出小组件外,我才知道同一个小组件在不同设备上占据的像素空间最大能有 50% 的区别。按照苹果的 iOS widget dimensions,仅 iPhone 就有十种不同的分辨率,小组件在不同的分辨率下有着不同的像素;而且原来 iPad 的锁屏界面上还能放置中尺寸的小组件,并且锁屏小组件不能显示颜色;此外还有 StandBy 小组件……
如果想充分利用像素空间,提高信息密度,那小组件的设计就必须根据设备的不同而不同。这也是我最终选择做的,按照苹果给的尺寸信息,从大到小分五类,不同类别用的字体大小和间距不一样,显示的列表项数量也可能不一样。这不是难活,但是苦力活。后来更新还加入交互式小组件,前后在小组件上花费了两个月时间,可谓最耗时功能。
最终的结果就是 Pinning 支持几乎所有大小的小组件,从锁屏的行内小组件到主屏的大型小组件;除了有可展示某个事件详情的事件小组件,还有可同时显示多个事件的列表小组件,并且还有可翻页的交互式小组件。
捷径的功能很强大,但即使在今天,它仍然只是少数玩家的工具。
尽管如此,Pinning 还是在捷径上花费了不少功夫,尽可能地提供更多功能,把可能性放到用户手里。你现在可以通过捷径创建事件和记事本、查找事件、打开或删除事件。
我在 Pinning 的旁白(VoiceOver)和动态字体(Dynamic Type)上花了很多时间,不停地调整界面元素在不同字体大小下的位置和大小,尽可能地改善大字体下的 UI 设计。但我一直不确定这样的付出是否值得。因为在国内,绝大部分会下载第三方 App 并为之付费的人,都是相对年轻,视力无障碍的人。
但「好的科技,应让人人都适用」。而且我喜欢那种「App 变得更好了」的感觉,即使绝大部多人都发现不了,我知道最终一定会有人用就好。
Pinning 上线没多久后,就收到了一个关于旁白的反馈,我很快就修复并提交了更新。过了几天后发现这位用户在 App Store 留下了一个意大利语的评论。这种能帮助别人的感觉,让我确认所有的付出都是有意义的。
对于原生 iPhone App 而言,支持 iPad 往往意味着在 Xcode 内勾选 iPad,在 iPad 上运行,从头到尾测试一遍功能,只要测试过程没有崩溃,整个支持过程就算完了。
以前的我也是这样做的:iPad 用户量远不如 iPhone,在 iPad 不看视频而是干活的则更少了,何必要给自己徒增工作量呢?
但这次的 Pinning 不一样。
在最初的计划里,Pinning 没有原生的 Mac 版,只会有基于 Catalyst 技术的 Mac 应用。所以,做好 iPad 应用相当于做好 Mac 应用。为此我测试了不少 iPad 应用,看了一些 iPad 相关的 WWDC 视频,给 Pinning 加上了快捷键支持,并根据大屏这一特点做了许多布局和交互优化。比如事件详情是以弹窗展示的;创建事件添加属性时,也尽可能地弹出弹窗,而不是导航至新页面。
Pinning 的 iPad 版本仍有很多优化空间,因为本质上 iPad 版本仍是 iOS 版本的放大版,它没有专门为大屏这一特点设计的新功能。这和我不是 iPad 效率工具的重度用户有很大关系,所以我会尝试多使用 iPad 完成工作,从写作开始:这篇文章大部分内容是在 Bear for iPadOS 上完成的。
倒数日 App 必须支持 Apple Watch,没办法,这是 Apple Guidelines 写的。这也是我第一次接触 watchOS 开发,也是我接触代码以来,经历过的最糟糕的开发体验:Xcode 无法和我的Apple Watch Series 4 配对,即使在重置 Apple Watch 后。
在开发前期还能通过模拟器上运行应用,但有些功能如同步和提醒事项,只能在真机上测试。好在后来找到了一个在真机上安装 Pinning 的办法:手机安装 TestFlight 版本,然后再在 Watch 应用里安装 Pinning。毫无疑问,即使有 Xcode Cloud 可以自动发 TestFlight 版本,这个过程仍然是极其低效的。我不记得为了解决一个在模拟器上能正常工作,在真机上无法使用的问题,到底安装了多少次 TestFlight 版本。
但好在最终问题都解决了,你可以在表盘内添加 Pinning 的小组件,抬手就能看到最近的事件。
Pinning 有着原生的 visionOS 版本,对,原生的,不是 iPad 版本。老实说,我没有 Apple Vision Pro,对其也不感兴趣,不会去买。所以 Pinning 的 visionOS 版本是在模拟器上开发完成的,开始到上线,花费了大约三周时间。
我最初的想法是,visionOS 上原生 App 很少,如果能有原生的倒数日 App 上架,或许能得到苹果的推荐。
于是抱着营销目的,我开始把 Pinning 迁移到 visionOS,整体过程不难,就是要改的背景颜色比较多,而且 Apple Vision Pro 模拟器极大地降低了效率,因为使用鼠标操作它很不顺畅。
现在回头看,这个决策浪费了不少时间。Apple Vision Pro 仍是有钱人的玩具,在过了最初的新鲜感后,它的销量和活跃度都在下降。再来一次的话,我不会把时间用在这里。
隐私是我作为用户在选择服务时非常在意的一个因素。
一个网站或者一个 App,如果不是由大公司出品但需要注册账号,那我会非常谨慎。我并不是在说大公司更值得信任,而且在谈论一个细节问题:如果一个产品只有很少用户,你如何能控制开发者不连接上数据库,查看里面的内容?但如果这个产品已有成百上千万数据,开发者就算要看数据库,也有更大概率是使用脚本分析,而不是漫无目的地浏览用户数据。
这也是我这几年做的 App,都是基于苹果平台的原因之一:因为我知道我无法取得用户信任,让他们能安心地把数据交给我,所以不如把数据都放在我也无法接触的地方。
所以 Pinning 只能在 Apple 平台上使用,通过 iCloud 实现数据同步,开发者未保存任何用户数据,连内购实现都从原来 App 使用的 RevenueCat 换成了苹果的 StoreKit 2。正常情况下打开应用,只有 Apple 的网络连接,因为 Pinning 没有所谓的使用分析(Usage Analytics)。仅有在应用崩溃时,Pinning 才会把崩溃信息发送至第三方错误追踪平台 Sentry。
Pinning 提供了按月订阅(¥6/月,免费试用三天)、按年订阅(¥48/年,免费试用一周)和永久买断(¥98)三种选项,每种选项还提供家庭共享版本。
作为开发者,我自然希望有稳定的收入,我的 App 应该仅提供订阅选择,因为无法多小的软件都有维护成本和售后成本。
现阶段的订阅买断混合制存在着「一次买断,终生售后」的问题,因为你无法再像原来的软件大版本升级那样再次向买断用户收费。虽然每个地区对订阅制的接纳程度不一样,但「用户不喜欢订阅制」这句话总体是成立的,特别是订阅制兴起后,很多软件的按年订阅比以往买断还贵。
不提供买断选项,意味着放弃一大批用户。为了面对市场需求,Pinning 提供了所有选项。
对于「一次买断,终生售后」这个问题,我的思路是:随着 App 订阅用户增多,逐渐提高买断价格。
当前阶段,Pinning 的买断价格还未提高过。如果你看到这里了,不妨下载应用,免费试用几天后再做决定。
iOS 18 还有一个月就要正式发布。所以适配 iOS 18 是后面的工作重点,包括着色(tinted )和深色图标、着色小组件、控制中心小组件等,当然还有重头戏 Apple Intelligence。
Apple Intelligence 的想象空间太大了,几乎每一个应用都能受益,任何一个开发者都无法忽视。我目前无法体验 Apple Intelligence,所以很难具体地评估未来的工作量。但今年的 WWDC 视频 Design App Intents for system experiences 里,有一句话流传很广:
Now, anything your app does should be an app intent.
第三方应用接入 Apple Intelligence 离不开 App Intents,但 Pinning 仍然只在 Siri Shortcuts 使用到了 App Intents。如果真的要实现苹果所说的,任何一件事都应该通过 App Intent 实现,那重构应用的工作量将会很大。
所以探索如何接入 Apple Intelligence 将会是短期内的工作重点。
macOS 版本的 Pinning 原本不在计划内。
倒数日 App 虽然在 iPhone 上满地都是,但在 Mac 上却不常见,本质还是因为需求较低。而在最初的设想里,Pinning 就是一个简洁的支持 iCloud 协作的倒数日 App,并没有同步日历和计划的提醒事项功能。但加入了这些功能后,它不只是一个倒数日 App,还是一个日程查看工具,一个任务管理工具,一个效率工具。而效率工具自然要支持尽可能多的平台。
一般而言,macOS 版本的开发工作量要大于 iOS 版本,而且开发的同时还需要兼顾 iOS 版本的维护,所以我把 macOS 版本的上线时间设为 2025 年,希望届时能推出符合 macOS 平台设计的 Pinning。
Pinning 现在的形式,是我最初未预想到的。它没有任何一个功能是独家专享的,但所有的功能和设计聚合在一起后,它是独一无二的。
我本来不是一个倒数日 App 的用户,但我现在是 Pinning 最忠实的用户,不仅仅是因为它作为一个效率工具,能同时显示日历和提醒事项,还因为它还能记录和回顾生活:我可以在里面看到四年前的今天我去体检了,三个月前的今天我去某地吃饭了。它内置的事件系统,提供了介于日历和日记之间的功能。
如果你喜欢体验新 App,那么请不要错过,无论最终喜欢与否,我相信你都可以感受得到那份新意。
在 App Store 下载:Pinning - 日历倒数
> 关注 少数派小红书,感受精彩数字生活 🍃
> 实用、好用的 正版软件,少数派为你呈现 🚀