运行后台服务、ios和;应用程序拒绝

运行后台服务、ios和;应用程序拒绝,ios,background-process,appstore-approval,Ios,Background Process,Appstore Approval,我已经阅读了有关ios后台执行指南的章节() 从文档中可以明显看出,当应用程序需要使用后台服务时,通过应用程序审批流程并不容易。应用程序必须有使用此类服务的合法理由,如VOIP和地理跟踪。不幸的是,我的两个都不是 我的应用程序在日出日落时播放一个notif音频文件(加上震动设备)。这就是整个应用程序的全部内容。(我有一个公式,可以根据用户当前的纬度/对数和时区计算每天的日出/日落时间。) 一旦它计算出当天的每日时间,它只需设置一个计时器并等待确切的时刻。随着日期的变化,它会再次计算公式,因此新一

我已经阅读了有关ios后台执行指南的章节()

从文档中可以明显看出,当应用程序需要使用后台服务时,通过应用程序审批流程并不容易。应用程序必须有使用此类服务的合法理由,如VOIP和地理跟踪。不幸的是,我的两个都不是

我的应用程序在日出日落时播放一个notif音频文件(加上震动设备)。这就是整个应用程序的全部内容。(我有一个公式,可以根据用户当前的纬度/对数和时区计算每天的日出/日落时间。)

一旦它计算出当天的每日时间,它只需设置一个计时器并等待确切的时刻。随着日期的变化,它会再次计算公式,因此新一天的日出/日落时间会透明地调整

由于日出和日落的时间每天都在变化,所以不可能像闹钟应用程序那样安排一个设定的时间

最简单、最合乎逻辑的方法是通过定时器。由于这个原因,我认为这个应用对后台服务的需求是非常合法的。但我真的怀疑苹果会这么想


如果苹果拒绝了这一点,我会用什么策略(作为替代方法)来实现同样的目标?有什么想法吗?(我不想使用push notif)

为什么不使用本地通知?您可以计算未来10天(或任何时间)的日出和日落时间,并安排一组通知。谢谢。不过,本地通知不会播放音频(由用户设置)。在我的应用程序中,用户可以选择打开/关闭振动和选择音频文件。有了本地通知,它就变成了一个全有或全无的交易。另外,10天或任何一天之后会发生什么?此外,当用户更改其位置时,旧的设置时间将不再适用。日出/设定时间不仅是日期和时区的函数,也是纬度/长的函数。正是因为这些原因,我原以为本地通知不是一个好的选择。你找到办法了吗?