React Native Permissions库中iOS日历权限请求的Bug分析与修复

在React Native生态系统中，权限管理一直是一个重要且复杂的议题。react-native-permissions作为最受欢迎的权限管理库之一，近期在iOS日历权限处理上出现了一个值得开发者注意的问题。

问题背景

在iOS 17及以上版本中，苹果对日历权限的请求方式进行了调整，引入了"完全访问"和"仅添加"两种权限级别。这一变化导致react-native-permissions库在处理日历权限请求时出现了不一致的行为。

具体表现为：当用户在系统弹窗中选择"完全访问"权限后，库仍然返回"denied"状态。这个问题在iOS 17+设备上尤为明显，特别是使用物理设备测试时（如iPhone 15 Pro运行iOS 18.1）。

技术分析

问题的根源在于库内部对iOS权限状态的判断逻辑。在旧版本实现中，库依赖于EKEventStore的authorizationStatusForEntityType:方法来获取权限状态，这个方法会返回一个状态码。然而在iOS 17+的新权限模型中，这种方法已经不再完全适用。

更准确的做法应该是检查请求权限时返回的granted布尔值，这个值直接反映了用户在系统弹窗中的选择。旧实现中忽略了这一点，导致状态判断不准确。

此外，测试中还发现一个有趣的现象：连续多次请求权限时，状态会变得不一致，有时会在第三次请求后突然返回正确的"granted"状态。这表明iOS内部可能存在某种竞态条件或状态同步延迟。

解决方案

库维护者迅速响应并发布了修复版本5.2.2。新版本主要做了以下改进：

1. 优先使用请求权限时返回的granted布尔值来判断权限状态
2. 保持对EKEventStore的单例使用模式，避免多次创建实例
3. 优化了权限状态判断逻辑，确保与iOS 17+的新权限模型兼容

开发者建议

对于正在使用react-native-permissions库的开发者，特别是需要处理日历权限的应用，建议：

1. 立即升级到5.2.2或更高版本
2. 在iOS 17+设备上进行充分的权限测试
3. 注意处理权限请求可能需要的重试逻辑
4. 考虑在UI中加入适当的引导，帮助用户理解"完全访问"和"仅添加"两种权限级别的区别

这个案例也提醒我们，随着操作系统版本的更新，权限模型可能会发生变化，开发者需要保持对这类变化的敏感度，及时更新依赖库和调整实现逻辑。