iOS每次升级后，苹果表表盘通知额度归零问题的处理
我是苹果表的老用户了。有多老？初代苹果表可以预购的第一天，我就预定了一只42mm的不锈钢苹果表。除了2018年苹果表电池把屏幕拱开，维修返厂的那几天，我天天都戴着它。
我写的应用，有一个叫Stand Minus的，提交到了苹果商店后，被审核的工作人员认为功能太少给拒绝上架了。我觉得它现有功能“增一分则肥，减一分则瘦”，拒绝修改。所以这个应用我就自己这一个用户。今天我要说的就是和这个Stand Minus相关的内容。
感谢git的存在，我们可以知道，Stand Minus是我在2017年1月31日最初创建的。
Stand Minus有两种工作方式，根据当前表盘是否有Stand Minus的小部件来判断。
发现问题
根据苹果的文档，当iOS向watchOS发送消息的时候，可以使用WCSession，其中最好用的方法是transferCurrentComplicationUserInfo(_:)。这个方法，同时还能唤醒手表端扩展的后台。因为能唤醒后台，会导致额外的耗电，所以苹果规定每天唤醒次数最多只能有50次，超过就自动变成不能唤醒后台的transferCurrentComplicationUserInfo(_:)调用。
一天有24小时，50次限制约等于每小时2次。我们可以使用remainingComplicationUserInfoTransfers属性来获得剩余的次数。
Stand Minus设计就是每小时发送两次，一天50次肯定是用不光的。但在实际使用中，有时候表盘小部件并没能及时更新。通过手表端查看我发现，提示剩余次数为0。
这个问题不常见，但是有时也会出。经过多次观察，我最终发现，这个问题和iOS升级有关，每次iOS升级完成之后，剩余次数都会归零。解决的办法很简单，额外再重启一次手机，然后就好了。
尝试解决问题
时光荏苒，到了2019年，因为升级到iOS 13 beta之后，我一直使用的推送OneSignal失效了。不得不重新折腾起一直用得好好的Stand Minus。同时，我尝试测试究竟是什么原因导致了次数归零。
我将代码
remainCountsLabel.text = String(session.remainingComplicationUserInfoTransfers)
改成了
remainCountsLabel.text = {
guard session.activationState == .activated else {
return "Session状态不是.activated。"
}
guard session.isWatchAppInstalled else {
return String("对应手表应用正在安装中……")
}
guard session.isComplicationEnabled else {
return "错误：手表当前表盘未安装Stand-的小部件。"
}
return String(session.remainingComplicationUserInfoTransfers)
}()
然后等待iOS的更新再测试。我最终发现了，导致错误的原因是，虽然手表的表盘上有Stand Minus的小部件，但是session.isComplicationEnabled返回的是否。而对于当前表盘没有对应小部件的情况下，session.remainingComplicationUserInfoTransfers返回0。
找到了更确切的原因，就可以解决问题了。我找了不用重启iPhone的办法。先切换手表的表盘到另外的表盘，然后再切回来，然后再点击Stand Minus的表盘小部件，打开手表应用。
经过上面的步骤，再重新打开手机上的应用查看，就会显示正确的剩余次数了。
最终解决方案
每次iOS升级之后，都做一遍切表盘，切表盘，开应用的操作。不算麻烦，但是也挺讨厌的。有没有有什么更好的办法呢？
我用的苹果表初代，在2018年的watchOS 5就不能更新了，我曾经猜测苹果应该早就修复了这个问题。我今年卖了苹果表5，手表到手之后，我发现苹果表5还是有这个问题。苹果怎么回事？这都watchOS 6了啊。
我尝试绕过这个问题。观察代码，手机向手表发送消息的核心代码如下：
if session.activationState == .activated && session.isPaired && session.isComplicationEnabled {
session.transferCurrentComplicationUserInfo(userInfo)
}
即当一切正常，且当前表盘存在对应小部件的时候，发送能够唤醒后台的消息。已知出错的是session.isComplicationEnabled，那么可否移除它，直接发送唤醒后台的消息呢？
阅读文档，苹果是这么说的：
Call this method when you have new data to send to your complication. Your WatchKit extension can use the data to replace or extend its current timeline entries.
This method can only be called while the session is active—that is, the activationState property is set to WCSessionActivationState.activated. Calling this method for an inactive or deactivated session is a programmer error.
原来，调用transferCurrentComplicationUserInfo(_:)方法，只要求WCSession为活跃就可以，其余的都是可以忽略的。
于是我删掉了session.isComplicationEnabled的检测。这相当于主动忽略了系统出错的部分。
不过，因为不再检测当前表盘是否存在小部件，相对于Stand Minus的原本架构，在不使用表盘小部件的情况下，手表的额外耗电理论上会多一些。
其它
我这边能做的就是这些。API的错误，最终还是需要苹果来解决。