这篇文章和 iOS 本地推送机制有关，但是不讨论琐碎的代码细节，因此不懂技术的朋友大可放心看。
很多人知道iOS本地推送，但是具体怎么用才算用的好，了解的却不多。绝大多数人只是把本地推送当成一个“周期拉活工具”。即在用户唤起 App 时就埋好某个时间弹出的推送。例如 “一天快要结束了，今天的打卡也要记得完成哦” 之类的例行拉活，或者纯粹当一个本地闹钟提醒。其实本地推送结合一点小小的服务器配置，还有更多大有可为的玩法。下面举个小例子来讲本地推送的妙用。
假定我们有一个电商类产品，今年有以下产品需求：
希望在圣诞节的前一天做一次群体推送，对用户推送圣诞 500 积分兑换活动，并且提示具体的兑换礼品。
对于积分不足 500 的用户，则推送文案为该用户还差多少分，让他加油攒积分兑换。
对于积分满 500 的用户，推送明天记得领取礼品。
看到以上需求，可能有些团队第一考虑的是用远程推送解决问题。那么我们拆解以上任务，看看用远程推送解决这个问题需要做哪些步骤。
用户的当前积分通过客户端明确无误的上传到服务器保存，这样才能计算每个用户是否满足领券条件或还差多少积分可以领券。
用户的推送令牌通过客户端上传到服务器保存。
服务器检索所有用户的推送令牌，对每个用户计算积分后生成对应的文案，通过苹果的 APNS 服务推送到每个用户设备里。
以上方案切实可行，对一些团队来说可能不是什么问题。但是对个人开发者或者想节约开发成本（包括服务器成本）的团队，可能会需要三思下，甚至直接会选择放弃这个推送需求，因为设计一套针对不同用户推送不同内容的推送机制以及准备推送服务器都是要花费技术和设备成本的。
这时候就要介绍如何用本地推送来重新设计方案了。我将方案拆解为以下步骤：
在服务器保存一个节日推送数据，例如未来几年几月几日几分推送，并写明推送所满足的积分要求、文案格式等。
客户端每次被唤起时（在推送日期之前），读取到服务端的推送数据，生成本地推送。
好了，方案写完了，是不是很简单？
其实，整个原理从大的层面上就是这么简单，只是根据不同团队可以不断的细化丰富而已，例如可以不断丰富服务端的json数据格式，形成不同的推送规则在客户端导入实现。最大的优点就是低成本，无论是开发成本还是设备成本，都非常低。
因为服务端只要保存推送数据，所以完全可以用一个静态文件（例如json格式的文件）来完成，甚至对于超小规模的开发者，前期都不需要自己配服务器，用 github 等做文件托管就能完成。
像这种推送策略，开发者完全可以把它“抽象化”为更通用的推送机制，这方面不同需求的产品大可以自己发挥。
当然了，很多细心人士可能发现这个推送机制存在一些小弊端，例如如果服务器配置了个推送机制，客户端唤起后把它保存了起来，这时候运营人员修改了服务器的推送日期，但是如果客户端在上一个配置的推送日期前没有被唤起过，客户端会无法读到新的推送日期而只执行旧的推送任务，诸如此类。但是，这些都是小弊端，比起该机制巨大的便捷性和低成本来说，对很多团队都是可以接受的。
这种方案比较容易被技术人员想到，而不是产品人员。因为技术人员会摸索苹果的不同的技术框架，并且大体知道这个技术框架该怎么用，但是他们未必会从产品运营角度去思考这个东西可能的潜力在哪里，而产品人员会思考产品运营设计难题，但是他们可能没有功夫去了解原生平台的机制细节。如果技术和产品之间没有在这方面交流和配合，就很可能错过很多好的方案，除非存在一个跨域精通的角色来统筹方案。这就带来了一个问题：技术人员究竟应该怎么和产品人员进行认知交换。这部分话题已经超出本文讨论范畴，留待后续记录。
附：移动开发者联盟入群指引