局域网推送通知

一段时间以来，我一直有一种理论，认为苹果的推送通知政策对开源软件体系结构以及项目的成功程度有非常重要的影响。这对于像啤酒一样免费的模式和去中心化的模式来说是最具挑战性的。如果iOS聊天应用程序想要监控服务器的实时更新，它会被阻止在后台保持打开的TCP连接。它还被禁止轮询任何一致性的更新。它获得这些实时更新的唯一可靠方式是通过APNS，这是一项基于互联网的苹果服务。唯一可以触发这些更新的人是应用程序的创建者。如果您的体系结构意味着不同的人负责客户端应用程序和包含您的数据的服务器，则会产生一系列不良后果。如果你找不到令人满意的解决方案，你实际上就会被iOS市场拒之门外。几年前，我在Matrix如何解决它的上下文中详细讨论了这一点。

这么长时间以来，当我看到某个WWDC20视频时，我做了一个小翻拍。它声称，在iOS14中，你可以“在没有互联网连接的情况下，将通知从你的应用服务器发送到网络上的设备”。等待-这意味着APNS不在考虑范围之内，现在有一些自托管的方式来传递可靠的推送通知。这是不是每个XMPP和FEDITY服务器都有权在一旁实现自己的推送通知呢？不行!。一定有什么圈套。

当然有个圈套。主要的限制是，只有当你连接到WiFi网络时，它才能工作。如果你只有蜂窝互联网，那么你就只能回到APNS了。另一个是您必须能够用代码指定将在其中激活本地推送通知的网络SSID列表。也许您在想您可以动态地填写这些信息吗？嗯，也许吧，但是获取当前连接的SSID本身可能是个问题。

他们在视频中反复表示，它针对的是非常具体的使用案例，特别是游轮上的即时通讯应用程序。在这种情况下，这些限制是有意义的。这只有足够的回旋余地来解决问题，仅此而已。

令我惊讶的是，App扩展获得了如此大的自由。虽然我自己还没有测试过测试版，但它似乎可以在您使用SSID的整个过程中运行，并且它可以实现它想要与您的专有服务器对话的任何协议。这在保护应用程序不会耗尽你的电池方面是一个相当重要的开拓。它需要一项授权，我认为这将是App Store特别关注的一面旗帜。否则，我可以想象一个邪恶的应用程序，它已经可以使用CNCopyCurrentNetworkInfo进行位置访问，并且在用户在家、工作等任何时候都可以跟踪这个新功能，而不是主动使用位置权限。

分散的项目可能会为此找到合适的用途。如果您的家庭局域网上有一项自我托管的服务，您完全可以构建一个客户端，在您在家时向您提供推送通知。然而，如果这样的应用程序让你输入你的SSID，没有什么可以说它会通过App Store的审查，除非你恰好住在一艘游轮上。