1

I just had an app rejected because I have a user changeable setting which allows the user to disable screen lock via 

[UIApplication sharedApplication].idleTimerDisabled = YES;

Apple says I used an undocumented API but it IS indeed documented here: https://developer.apple.com/library/ios/documentation/uikit/reference/UIApplication_Class/index.html#//apple_ref/occ/instp/UIApplication/idleTimerDisabled

My app graphs the barometric pressure and if you want the graph to run longer than a minute or two, it is important to disable screen lock. The default behavior is screen locking as usual, but there's an option in the settings to disable screen lock and this seems to be what Apple took issue with. I've had academic users request this feature, and I have used it in other apps successfully, however this time Apple rejected my app for using it. Is this normal? Is disabling screen lock via UIApplication really now allowed?

Jackson
  • 3,555
  • 3
  • 34
  • 50
  • Seems like the basic standard for doing what you're trying to do, unless something's changed in ios8. Perhaps a bad reviewer, or they linked to the wrong section of your code by mistake in the error report? – Joe Oct 13 '14 at 19:04
  • I responded to the reviewer saying the API is indeed documented, showed where it was documented, and told them why I wanted to use it. I hope it doesn't take weeks to hear back from them, and not sure what to expect from a response to a rejection anyway (this is my first rejection). – Jackson Oct 13 '14 at 19:09

2 Answers2

1

I am not sure but I think the issue is that note under the important heading with the documentation you shared;

"You should set this property only if necessary and should be sure to reset it to NO when the need no longer exists. Most apps should let the system turn off the screen when the idle timer elapses ..."

You should write into resolution center and confirm this;

Shoaib
  • 2,286
  • 1
  • 19
  • 27
  • I wrote the resolution center and their response was: In order to bring your app into compliance with the guidelines, it would be appropriate to remove this feature from your app. At your earliest convenience, please make the necessary changes and upload a new binary for review. Kind Regards, App Store Review – Jackson Oct 13 '14 at 22:42
1

We use that capability to prevent idle sleep when we are updating the firmware on a BlueTooth device. Immediately upon completing the update, we restore idle timeout. Apple never said a thing to us about it.

However, in your case, there is no technical reason to disable the idle timer. Your data collection is not going to fail because the system went idle. There is no adverse or unusual customer experience going to be had. That is probably what Apple took exception to.

Three possible paths exist:

1) Gather your data at intervals in the background while the system is idle and update the graph when the app again comes to the front.

2) Add messaging to your app to tell the user that if they want continuous display, they will need to change the idle timeout period in system settings. (With caveats about impact on battery charge duration.)

3) State your case to Apple.

I would go for both 1 & 2

CuriousRabbit
  • 2,124
  • 14
  • 13
  • Sometimes a user (a meteorologist for example) might want the screen to stay on while the app is graphing. During a hurricane for example. There were numerous users running my app during the typhoon this weekend in Japan and they asked for this feature. I've used it in other apps with no problem so I don't see why it is an issue here, or why Apple would call their API undocumented or private. – Jackson Oct 13 '14 at 19:34
  • I suppose I could change the UISwitch to a button and when you click it it just displays an alert and tells the user to go to settings and do it themselves but that seems so un-Apple like. I could see why a user doesn't want to change their system wide settings for screen lock, only while viewing real-time pressure data. – Jackson Oct 13 '14 at 19:35
  • Well, Apple is clearly wrong where the "undocumented or private" claim is concerned. The Apple-like behavior is to preserve battery under all possible circumstances. Also, avoid doing system things in an app when there is adequate control provided by Apple, and Apple gets to define "adequate." ¯\_(ツ)_/¯ – CuriousRabbit Oct 13 '14 at 20:46
  • I agree that Apple is wrong with the undocumented or private claim. The interesting this is my app was later accepted with the same feature, possibly with a different reviewer who properly followed the rules. – Jackson Feb 09 '15 at 01:43