IPhone application rejected due to battery usage and heat.

Question

My application is rejected for the following:

13.2 - Apps that rapidly drain the device battery or generate excessive heat will be rejected 

I have two assumptions as to why this could be rejected:

• My app is an LED candlestick app that uses the patented candlelight flicker algorithm. Thus, it turns on / off the LED, very quickly resembling a candle. Using an LED will obviously drain the battery faster than most applications. So there wouldn’t be a lot of “LED flashlights” applications on the market.

• Do I have code that recursive loops and loop code, for example, can kill a battery?

  NSTimer.scheduledTimerWithTimeInterval(timeTillFlicker, target: self, selector: "candleFlickerLoop", userInfo: nil, repeats: false)

  Does it create such cycles with timeTillFlicker around 0.0065 Seconds burns the battery? Is there a better way to do this?

So, of these two things, do you think this is the reason for this rejection of the apple?

Does anyone have any tips on working with such reviews?

Any advice would be greatly appreciated. I feel rather discouraged from this review process.

Answer 1

First of all, do not discourage. One of my apps, which now has over 1M users, has been rejected due to excessive battery usage. My problem was the use of GPS (drainage batteries such as crazy). After I realized this, I changed the way I use it and solved the problem.

The next time I sent it for viewing, it was accepted.

To find out what the problem is, you can use the tool tool.

You can follow Apple's guide at this https://developer.apple.com/library/ios/documentation/DeveloperTools/Conceptual/InstrumentsUserGuide/MeasuringEnergyImpact.html

Answer 2

I am not a specialist in the mobile environment, but I am in other areas where performance is even more important (server systems).

I really don't know all the specifications for scheduling functions inside iOS, but what I can tell you is that I saw recursive use of scuduling only for animation in javascript. Otherwise, you should use scedule for upcoming events that should occur in minutes, hours or days when the selling thread will be meaningless. But for your scenario (stream-oriented device) I will use shure to create a stream and implement a recursive loop. Perhaps the planning is controlled in such a way as to increase the consumption of the plunger and, consequently, the battery. I'm sure Apple is aware that the battery is running out of power. I think they refused because you created a hotspot on a ram with a schedule.