When in background it doesn’t do any trace or log of the location. The only reason I need it for the app is to be prompt with precise location when user brings it into foreground.
Imagine the use case when you make your location notes during a paintball game. If my app would exit and nothing else would be keeping location updates coming, then after getting into foreground it would take 10+ seconds to get some accurate GPS reading within +-10 meters. It’s too slow when you have only few moments to mark a place!
I provided all that reasoning for the resolution center and in my appeal. Approximately in 24 hours after the appeal I got a message from AppReview team that they are going to call me in the next available time slot. This time came in about 36 hours later and thanks to them for calling during reasonable CET time as I’m CET located (may happen by random luck though).
AppReview team member was very polite and provided very useful information right on the rejection subject. She gave enough space to me to re-explain my reasons and to confirm that actually the reason of “having accurate location readings promptly available after going into foreground” is not enough to justify “location” in the UIBackgroundModes. I’d have to have some navigational features.
For my previous rejection for Speedometer, it sufficed that it calculates the distance traveled, average and max speed (and of course give an audio alert when user is over the preset speed limit) when in background:
In case of my notes application, I guess I’m going to remove that “Work in background” option for a moment and resubmit asap as I also want to try a new AppStore icon for it. Later on I’ll add distance and map tracking for Here&Near notes (to be able to use it as odometer and a reverse odometer) and I have a strong hope that its “location” background mode will be approved then.
On my previous rejections: http://plainoldstan.blogspot.cz/2012/06/story-of-on-iphone-app-rejection-x2.html