iClock 要求 iOS 26.1 以上版本，以支持完整的功能特性。
TestFlight 地址：https://testflight.apple.com/join/Yg8DgbQK
大家好，这里是 iClock 开发者，我们将在2月1日前开启 iClock 的 TestFlight 测试。从内置铃声剪辑自定义、调休日历闹钟、快速复杂排班等等，你能想到的或不能想到的功能，在 iClock 中或许都能实现。
iClock 的基础特性之三
闹钟”作为一个工具，失效是绝对不允许的。因此在发布 TestFlight 前，开发者和朋友们进行了诸多测试，包括一些匪夷所思的极端工况。在目前我们能够想到的场景中，iClock 均已通过测试。但由于整个“团队”的人数、精力有限，且大家都并非专业的 iOS 开发者和测试人员，我们无法保证 iClock 绝对不会出错。因此，本次 TestFlight 测试包含两方面意图：
1. 希望 iClock 能先以免费的形式为大家服务一段较长的时间，至少陪伴大家度过春节，让 iOS 用户不需要再手动应对调休、调班。对于广大医生、护士、从事运维等需要复杂排班、调休的朋友，希望 iClock 能陪伴你度过一段“闹钟全托管”的轻松时光，不用再每天检查和手动配置闹钟；
2. 同时，春节这样的复杂调休、调班，对于 iClock 是一次严苛的实际生产环境测试，它能否安然度过这次考验，也是我们进行 TestFlight 公开测试的一大目的。
开发故事
项目初期，设计制作这样一款 App 只是希望实现“方便、自由地选择铃声，自动根据调休响起”这两项简单的功能。然而，找到一个自己喜欢的音乐，将它转换为 m4a 格式、手动剪辑、再使用某些软件导入手机，最后在系统的时钟应用里启用——这太麻烦了。同时也在想，为什么 iOS 长久以来都没有人做“调休闹钟”这么简单的功能呢？
Apple 埋下的“大坑”——其一：做个闹钟还不简单？
当初版 iClock 完成后，开发者兴奋地让朋友进行测试，结果却发现闹钟无法响起。经过一番搜索，才知道原来 iOS 这么多年来都没有对第三方 App开放过系统级的闹钟 API：也就是说，只有系统自带的那个“时钟”App，才有资格安排闹铃，难怪 iPhone 这么多年都没有“调休闹钟”这么简单的功能！
正当准备放弃时，朋友告诉我，2025年的WWDC上公布了一个 AlarmKit API，它允许第三方 App 调用系统级闹钟——而此时，那些“先进的 AI”们还不知道有这么一个 API 可以实现闹钟。
iClock 所基于的 AlarmKit API
于是，基于 AlarmKit API，iClock 对调休日历完成了适配，至此初步开发完成。故事本来应该到这里结束了，当把那个婴儿般的 iClock 交予朋友，并说想要解决每天手动管理闹钟的痛点时：
确实有点痛了
他不仅有几乎毫无规律的工作、休息日更替安排，甚至还有不同的上班地点：地点的变更使他有时需要更早地起床。这已经不叫“痛点”了，完全是“痛苦”。
我也回想起有一年住院时，护士与我聊天，提到她的“白班、大夜班、小夜班”，也是一种几乎没有规律、需要根据排班规则进行临时变动的日程安排。我的朋友里还有未来的医生，他们在规培阶段或许也在受着这样的“折磨”。苹果，你为什么 2025 年了，才开放这个API？
在此之后，才是真正的开发。
Apple 埋下的“大坑”——其二：iOS，你是说只要调用系统已有组件，就会有无穷无尽的Bug，是吗？
像上面那样的排班形式，应该有颜色和文字作为区分，那就可以直接调用系统的取色器；有些用户可能对定制铃声没有需求，那就应该提供原生的声音选项；日历可能不需要计算，而是直接取用系统的就好；……
然而在开发过程中，调用系统的取色组件，曾经出现过取色滴管永久卡在系统的最表层，连关机都无法做到的恶性 Bug；iOS 的奇怪系统限制，那些普通的系统铃声居然不让调用；调用系统的调休日历匹配需要引导用户去操作 iOS 自带的日历 App，又担心用户的待办事项和 iClock 发生奇怪的联动导致失效……
这些开发之前从未想过的错误，和 iOS 离奇的系统限制，一切的一切都需要 iClock 自行从头设计和计算，尽可能避免调用系统提供的功能——哪怕是一个静音的闹钟，都需要自行准备一个空白音频。
当这些事项全部完成，开发者以为 iClock 的公开测试终于可以提上日程的时候，iOS 又发力了。
Apple 埋下的“大坑”——其三：所有的安全余量都需要自己设置，为了不犯错而反复试错
正当开发者和测试人员都认为功能性开发已完成，可以开始尝试“闹钟全托管”静默测试的时候，意外毫不意外地出现了：iOS 对一个 App 能够注册的闹钟数做了限制——而这还需要经过调查才能发现。
这太致命了。当你放心的把未来一两个月的日程交给 iClock 之后，突然有一天它开始不响了，你查看小组件，发现小组件上赫然写着“星期X之前没有闹钟”。
iClock 的桌面和锁屏组件，提供了快捷闹钟显示和跳过、修改功能
然而打开 iClock 之后，所有闹钟又都回来了，究竟发生了什么？如果不能实现全托管，那么之前所有的努力都将付之东流——谁会想要一个嘴上宣称“便捷”，却要日日担惊受怕它突然“罢工”，夜夜需要打开它“激活”的闹钟呢？
战斗对象此刻不再是用户需求与代码实现，而是 iOS，而它几乎是一个深不可测的黑箱。就像在 moba 或者 RTS 游戏的战争迷雾里，只能一点一点地探索这个敌人的“全貌”：一个 App 只被允许向系统注册有限个 AlarmKit 闹钟，一个 App 只被允许向系统申请有限个通知……
那我要注册多少个，以防用户在一些特殊情况下增加的闹钟，因超出允许范围而被取消？我要在什么时候通知，在尽可能减少打扰的情况下，告知用户可能需要打开一次 App 以完成后续闹钟的系统级注册？用户在什么情况下可能不小心注册过多的闹钟，这些闹钟的属性是什么，安全余量是多少？如何向用户发出预警……
此刻，我既是开发者，又是用户，还是产品经理。我不仅要实现功能，还要把用户体验放在第一位，既要保证“托管”的长期安全性，又要保证将“托管”思路贯彻到底，这是根本安全与用户体验的双重折磨。
好在，这个不是 Bug 的 Bug 在 1.2 内测版本中尝试解决了，现在是2026年的1月23日，距离 1.3 版本的静默测试过去了一周以上的时间，据测试员报告没有遇到Bug。而现在的 1.41 版本经过一些用户体验和显示上的 Bug 修复，希望 1.41 能成为“0 Bug”的最后一块拼图。
写在最后：iClock 想实现什么？
基础功能远远不够，既然敢取名叫“全功能闹钟”，就应该做到名副其实，必然不能做任何妥协。iClock 不一定能够满足每一位用户的特殊定制化需求，但它必然具有其他 App 所不具备的特性或能力：从基础“时钟 app”的秒表、计时器、世界时钟，到新的内置铃声剪辑，再到基于“特殊事件”实现的快速排班闹钟，为你所想，一应俱全；全新的客制日历、按日历重复响起规则、日历导入和导出，甚至全数据导入导出功能，我们考虑重视用户使用 iClock 时可能面临的一切需求和负担。探索 iClock 的每一个角落，总能发现一些传统闹钟上从未见过的惊喜。
“闹钟响起”是 iClock 的安全底线，是在所有极端工况中的唯一合格标准，现在，它应该挺过来了，并站到了 TestFlight 上，接受诸位的检验。
在使用之前，我们仍要建议大家“不要完全信任 iClock”——它真的还有可能犯错，你一定需要系统闹钟为你兜底。我们必须提醒：任何一次闹钟失效，对你而言都可能造成巨大的损失。因此，请在使用 iClock 期间同步地设置系统原有闹钟（时间差距取几分钟内为宜，同样的时间设置可能导致相互取消或无法判别究竟是哪边在响起），以确保日程安全无虞。同时体验 iClock 能否实现“全托管”的便捷体验，以及记录可能的 Bug。
最后，欢迎，并感谢大家使用 iClock，开发者期待你的反馈、功能意见，以及最重要的：Bug 和复现手段。请大家仔细阅读用户引导，以便了解更多的风险，以及让 iClock 能够更好地为你服务。
集诸多功能于一身，并随着用户反馈持续进化，iClock 将努力成为真正的全功能闹钟。
