此罕见非彼罕见
太长不看 🔗
简单来说，我们在接入Sign With Apple的Web版时，遇到了一个罕见的BUG：在确认后台配置好Sign With Apple的服务并保存后，我们所做的任何修改都无法生效。期间我们进行的操作有：
-
新增一个Service ID
-
删除一个之前添加过的Service ID
-
修改Redirect URL
我们再三确认了后台配置正确，但这些操作无一例外地没有生效。使用配置好的Service ID和Redirect URL访问Sign With Apple的Web登录界面，依然得到Invalid Client或Invalid Redirect URL。更为奇妙的是，我们在删除旧的Service ID后，它依然可以正常使用！并且在此之前，我们修改其Redirect URL配置也一直没有生效，甚至在删除后，我们依然可以用最原始的配置使用这个被删除掉的Service ID。
被逼无奈的情况下，我们选择了联系苹果的技术支持，得到的结论是：技术支持团队认为这是一个BUG，应该使用苹果的反馈系统向苹果反馈。没办法，只能照做。经历了漫长的等待，苹果终于给到回复：该问题已修复，请验证是否已解决。
测试后发现，确实没问题了，也就印证了这确实是个BUG，而非我们的配置错误。
当时在网上搜索了很多信息，都没有找到类似问题的解决方案，也无法确认到底是我们的配置错误还是苹果的BUG。可能是因为该服务使用的人群确实不够多吧？如果有碰到类似问题的朋友，再三确认自己没有配置错的话，赶紧联系苹果解决吧！
背景 🔗
相信绝大多数App接入Sign With Apple服务的起因都只是因为苹果要求接入第三方登录的App也必须同时接入Sign With Apple（参考：App Store 审核指南）吧。我也不例外。而此次接触该服务主要是因为我们的产品早期图省事，只接入了短信验证登录（当然也是为了符合国家关于实名制的相关规定），对于国内用户还好，对于国外的用户可就要了老命了：国际短信太！TM！贵！了！每个月因为国际短信我们都要花掉不少钱，为了节省成本，我们决定在App中引入Sign With Apple来引导海外用户尽可能不要发送昂贵的国际短信，同时也为了提升国内用户的使用体验，我们还决定同时接入微信登录。这样即满足了苹果的要求，又实现了我们降低成本的需求，好耶！
对于Target到iOS 13以上版本的App来说，到这一步，已经不存在什么问题了，参考文档，加入一个ASAuthorizationAppleIDButton，写一写delegate，拿到OAuth的code，发给App后端，后端按照相关文档处理登录/注册请求即可。但是众所周知，国内的App的兼容性都好得吓人（褒义），例如美团最新版本（11.18.200）依然Target到了iOS 10，抖音最新版本（19.7.0）也Target到了iOS 10。我们的App在攥写本文时是Target到了iOS 11。在低于iOS 13的设备上，ASAuthorizationAppleIDButton显然是不可用的，那么对于低版本的iOS，有两条路可以选择：
-
进行一个不管，因为Apple的审核员只会使用最新版本的iOS对App进行审核，老版本系统中Sign With Apple不可用并不影响App的审核与上架。
-
在低版本的系统中使用
WKWebView，使用Sign With Apple的Web版来实现该功能。
本着不放弃任何一个用户的原则，我们选择了第二种方式（其实是一开始压根没想过原来还可以选择放弃低版本的用户），为低版本系统的用户增加额外的兼容性。
问题出现 🔗
最初的开发还是比较顺利的，我们添加了一个测试用的Service ID，将它的Redirect URL配置到了example.app用以进行手动的测试。在这段时间内，我们遇到的唯一一个问题就是在配置完成后，访问Sign With Apple的Web页面，依然会提示Invalid Client，这是一个表示Service ID无效的错误码，搜索后发现似乎是苹果缓存服务的问题，可以尝试稍微等一等后再尝试。等了几个小时后，该问题就不再出现了，于是就没有深究（而且也没办法深究）。
在以手动的方式跑通整个流程后，我们准备修改之前使用的Service ID的Redirect URL的配置，使其指向我们的测试服务器，而非example.app，以进行下一步的开发和测试工作。此时问题出现了：当使用新配置的Redirect URL请求Sign With Apple服务时，苹果的服务器告诉我们：Invalid Redirect URL，这是一个表示Redirect URL无效的错误码。说明我们之前的配置似乎没有生效。考虑到之前遇到的缓存问题，我们决定等一等，先继续进行开发，之后再来测试。随着时间慢慢过去，苹果的服务器依然还是告诉我们使用Redirect URL无效，并且即使在我们删除掉example.app的配置后，依然可以正常使用其作为Redirect URL。在经历了两天没有任何进展后，我们决定尝试再创建一个新的Service ID，看看新的Service ID能否正常使用。
然而事情的进展却不尽如人意，这个新创建的Service ID在接下来的几天尝试中都一直处于不可用的状态，苹果的服务器一直告诉我们：Invalid Client。实在没有办法，我们决定尝试删除掉最开始添加的那个Service ID，祈祷这能够唤醒苹果的缓存服务，更新一下我们的配置。然而不仅后续创建的这个新的Service ID依然处于不可用状态，删除掉的Service ID也还可以正常使用！
这就证实了我的猜想：我们所做的一切配置（除了最开始添加的那个Service ID和当时配置的Redirect）都没有生效，我们遇到了苹果的BUG。
联系技术支持 🔗
在Google上换着关键词搜索了一整天后，依然没有得到任何有价值结果。最终我们决定使用一年免费两次的技术支持服务（Technical Support Incident，TSI，Requesting Technical Support - Support - Apple Developer），希望技术支持团队能够帮助我们解决该问题。
我们在2022年2月11日向苹果提交了技术支持请求，在2022年2月16日得到了苹果技术支持团队的回复，他告诉我们：他们认为这是一个BUG，他们也无法解决，建议我使用苹果的反馈助理（Feedback Assistant，MacOS上也预装了该程序）向相关团队反馈。同时由于他们未帮我们解决问题，返还了这次的服务额度。
嗯……怎么说呢，虽然他们确实没帮我们直接解决问题，但起码也没扣掉这次额度，也算是厚道吧🤣🤣🤣。
基于此，我们了解到这个问题可能还需要一段时间以后才能解决，所以我们选择了换一条路，暂时不使用Sign With Apple的Web版来为使用iOS 13以下设备的用户提供Sign With Apple服务，先满足绝大部分使用新版iOS系统的用户（截止到文章发表时，根据苹果给出的数据，有超过93%的iPhone和超过86%的iPad使用的是iOS 14以上的版本，参考），同时也是为了尽快降低我们的短信服务费用的支出。
Feedback Assistant 🔗
在完成新版本App的上架后，我才有空开始琢磨怎么使用这个Feedback Assistant来提交反馈。最初我使用的是网页版的Feedback Assistant，在我写完问题描述，点击提交，以为完事儿了以后，发现事情不太对劲：这个东西怎么一直在转，一直在Preparing？
再多次重复尝试后，发现点击发送按钮后，并没有任何网络请求被发出，也就是说，点完按钮以后，这个网页就一直在这里转，也不知道在转什么，也不知道在Preparing什么。并且我还尝试了不同的浏览器：Firefox、Safari、Chrome，无一例外的都是这样。难道Feedback Assistant本身就有BUG？那我应该去哪里反馈Feedback Assistant的BUG呢？
至此，我本来都打算放弃了，反正App也上架了，使用iOS 13以下的用户也不多，也没必要追着这个问题不放了。偶然有一天，我突然发现：欸，Mac好像有这个Feedback Assistant的App欸，要不要试一下App能不能提交反馈？闲着也是闲着，就稍微那么尝试了一下，点击发送按钮以后，很快嗷，反馈就发出去了。好嘛，真是网页版有BUG是吧，苹果，你行😅😅😅。要是我不试那么一下，怕是这辈子都不知道怎么给苹果反馈问题了。
总而言之，在2022年2月18日，我成功使用Mac上预装的Feedback Assistant App向苹果提交了该问题。2022年3月4日，苹果回复：感谢您的耐心等待，我们已修复该问题，请验证该问题是否已解决。
嗯……我确实挺耐心的，嗯等了两周，都快给我等忘了还有这么一回事儿了😅😅😅。
经过验证，我们的配置都成功生效了，并且都按照我们的预期在运行。
总之，最终该问题算是解决了。
总结 🔗
“Once you eliminate the impossible, whatever remains, no matter how improbable, must be the truth.” - Sherlock Homes”
希望这篇文章能够帮助到其他遇到了类似问题的朋友。