我正在Swift中编写一个消息传递应用程序，人们可以在其中聊天，类似于短信或其他流行的聊天应用程序的工作方式。支持API在AWS上，以C＃编写。
这里有一些有趣的地方：
我们不想提示用户询问他们是否对此应用程序发送通知感到满意，因为除了新的聊天到达之外，我们没有向他们发送标语或任何视觉效果。 APNS是否有此要求？我觉得这意味着有人可以说“不”，然后我们就无法实时更新聊天应用，因为它不会运行。
我假设一种简单的方法是从消息ViewController运行某种计时器/循环，其中每隔一秒或两秒就会到达API，并询问是否有新消息，但这对我来说似乎是错误的-该应用必须是健壮的，并且可能有成千上万的人在使用它-这是许多API请求，而且在许多情况下，可能没有新消息，因此浪费了调用。显然这不是要走的路，对吗？
问题＃1 我当时在想应该使用APNS，但是不确定它是否需要提示用户要求他们许可从Apple接收任何东西？再次我担心的是，聊天气泡应该实时出现，并且不希望使用户能够以某种方式看不到它们（破坏应用程序）
如果要使用APNS，并且必须提示他们，那么我假设流程是，我将收集我的设备ID（在appdelegate中创建，保存在C＃db中，并与每个消息线程相关联），并且只要有人键入一条消息，然后转到我的API，将其保存在消息数据库表中，然后将一条消息发送到APNS，并将其发送给每个人的设备ID。
Apple将其排队，然后发送给每个人，如果他们在屏幕上，则消息会出现。
这是我应该如何利用APNS实现我想要的吗？
问题2 ：我看到其他人建议使用SNS（与APNS结合使用），但是我不明白为什么。 APNS既不充当适当的队列又充当通知服务，从而使使用AWS的SNS / SQS的需求完全失效了吗？对我来说似乎是多余的，但也许我只是不理解为什么同时需要两种技术的想法。
提前感谢任何人的时间，如果他们能为我提供一些启示！
谢谢！
答案 0 :(得分：0)
即使您正在使用WebSockets（如@stevenpcurtis所述），当应用程序处于后台/挂起状态时，您仍需要通知用户有关用户收到消息的事实。是的，您必须“强迫”用户为应用程序启用通知并解释其需求。根据经验，如果用户安装了Messenger，则他会了解通知的用途以及启用通知的原因。
从移动角度看，当应用程序处于后台或挂起状态时，当用户收到通知时，SNS仍会传递推送通知。从后端的角度来看，您可以使用SNS。
从移动设备的角度来看，您有2种模式：
您还可以选中This question以获得更多信息。