2

iOS guidelines apparently don't allow to use background tasks for more than 10 minutes. I am designing a cooking timer app that allows the user to set a specific time and begins a count down.

However it appears impossible to set a background task (e.g. using UILocalNotification or adding an NSTimer to [NSRunLoop mainRunLoop]) that runs for more than 10 minutes.

Is there a work around this? How do developers designs apps that trigger timers that last longer than 10 minutes?

Possible solutions:

  • A: use server service and run the timer remotely, push notification from server once timer finishes to "warn" user. Cons: expensive to run server, time costly to develop.
  • B: once the app starts keep it active in the foreground (don't allow the screensaver to trigger). Cons: battery expensive.

Any other ideas?

EDIT: I would like the app to work with iWatch. Hence displaying a glance notification on iWatch once the timer should trigger. As this is guided by the iPhone app I would not be able to do so unless the app is active.

Community
  • 1
  • 1
mm24
  • 9,280
  • 12
  • 75
  • 170
  • 1
    I believe you can schedule a `UILocalNotification` with whenever `fireDate` you want. The limited period of time you mention is for keeping your program running in background, but I think you can schedule local notifications for whenever you want. – Rob Jan 06 '15 at 12:18
  • @Rob thanks for the comment. So I should be able to set a fireDate in one day? Will this fire also if the App gets killed? Is there anywhere I can find this clarified on the official Apple documentation? – mm24 Jan 06 '15 at 12:28
  • PS: What do you think about this Q/A: http://stackoverflow.com/questions/19762071/uilocalnotification-dosent-prompts-after-10-mins-in-background?lq=1 – mm24 Jan 06 '15 at 12:30
  • 1
    I think that question is trying to keep an app running indefinitely, running HTTP requests every minute even after the user exits the app. You cannot/shouldn't do that. He appears to be trying to use local notifications to hack around this limitation which is a horrible idea (and I personally welcome Apple's prohibition of that practice). But you're not doing anything like that. You just need to show a notification in some point in the future. That's precisely what local notifications was designed to do. – Rob Jan 06 '15 at 12:47

1 Answers1

3

The documentation for UILocalNotification says:

A UILocalNotification object specifies a notification that an app can schedule for presentation at a specific date and time. The operating system is responsible for delivering local notifications at their scheduled times; the app does not have to be running for this to happen.

So, this limit of running apps no more than a few minutes in background does not apply with notifications (as the app doesn't have to be running).

For more information, see the Local and Remote Notification Programming Guide.

Rob
  • 415,655
  • 72
  • 787
  • 1,044
  • excellent. Thank you very much for this. I guess I should design my App around this and handle the behaviour in the did receive local notification method once the app awakes. – mm24 Jan 06 '15 at 12:48
  • 1
    See the _Handling Local and Remote Notifications_ in that guide, which talks about the various hooks you need. The `didReceiveLocalNotification` only happens if the app happens to be running in the background when the notification comes in, methinks. If the app is started because the user tapped on default/custom buttons in the alert, various other methods are called, if I recall correctly. – Rob Jan 06 '15 at 12:50
  • tip - application:didReceiveLocalNotification: is called even if the app is running in the foreground. application.applicationState can be checked for UIApplicationStateActive, UIApplicationStateInactive, UIApplicationStateBackground. btw, @Rob's answer is much appreciated! – finneycanhelp Apr 04 '15 at 22:15