I am looking forward to submitting an iPad application which uses CoreAnimation a lot and so it's heavy.
In "App Store Review Guideline", it shows:
13.2 Apps that rapidly drain the device's battery or generate excessive heat will be rejected
While working my application on real iPad, it drains the battery to half in 4 hours, let the device to become a little bit warm. Will this be a reason enough to be rejected?
Related
I am working with ibeacon. I created an application for tracking devices. But I am facing a problem with the application. The app works well in the terminated state for iPhone SE whereas it is not working (in the locked state) for iPhone 7+.In the unlocked state it is working for 7+ also but still it is very slow compared to iPhone SE. Is there any specific reason for this problem. If it can be solved, what could be the possible solution to this problem.
I am really helpless and clueless about this issue.Please do help me and assist me with your knowledge Sir. Thank you in advance.
When an iOS app is in the background, it relies on two different mechanisms to detect beacons:
Hardware filters. These are byte patterns stored on the Bluetooth chip that alert the OS when a BLE advertising packet is received that matches your beacon region. This mechanism is very fast and delivers results within a second, but it is a limited resource. Once all slots are full, it will no longer work. There is no documentation about the number of slots available on each iPhone model, but experiments suggest the number is ~30.
Software scans. A full BLE scan is performed to find all beacons even if they are not stored in a hardware filter. In the foreground with ranging active, software scans are constant. In the background they are periodic to save battery, so detections based on software scans are much slower. The rate is undocumented, but experiments suggest software scans are performed every ~10 minutes in the background in the typical phone state. An additiona softwarel scan is also performed when the screen is unlocked.
The problem description is consistent with hardware filters (1) not working on the iPhone 7+. This may not be a problem with the phone model, it could be a problem with the specific device, or more likely the software state on the phone. A typical cause is the installation of multiple beacon apps that use up all the slots. Each beacon app can register up to 20 beacon regions for monitoring, so just two apps could use up all the slots!. The first apps to run and register slots may hold them forever.
A few troubleshooting tips:
Uninstall any other apps you think may. be detecting beacons, then re-install yours.
Restart your device.
If the above does not help, you may have a hardware problem with your device. Try another iPhone 7+ to see if you can reproduce.
I have a watch app using the same API as it is on iPhone. The request code are total same. But the response time on watch is slower than iPhone about 3-4 seconds. Is this normal? Can we improve this experience on watch?
Thank.
First, comparing Apple Watch's speed with iPhone, no matter what area that is, is pointless.
Apple Watch is smaller in size, which has less battery, less CPU power and a much smaller antenna. It should be so much slower than iPhone. That's part of the reason it's been locked out from lots of standard iOS APIs. You already saw how slow when it loads an app before 3.0 beta.
Secondly, although Apple Watch support WiFi, unlike iPhone, it supports only 802.11b/g/n 2.4GHz. Not 5GHz or ac.
Keep in mind that it's an extension of your iPhone, not a standalone device that to be used extensively like you do to your iPhone. If it's slow, maybe you shouldn't let it do it at the first place. Instead, use your phone to do the work and send the data to your Watch.
I've developed an iOS app that connects to a BLE peripheral and retrieves heart rate data of one person during the night.
The app runs on the foreground and also on background using Bluetooth accessories background mode.
It receives heart rate data every second and appends it into a file, in order to save a report for the whole night.
The app is working fine in some devices (it writes data during the whole night), but in other devices (tested an iPhone 5s) it relaunches automatically every 1.5 or 2 hours. I found that sometimes iOS kills background apps due to memory pressure, so I made some memory tests with the profiler, but the app only consumes 8MB, and it never gets more than that, so there is no memory issue.
It is really important for me to prevent the app suspending, so I can detect any possible anomaly on the heart rate and trigger an alert.
Any clue on this?
I have created a project which consists of coredata core location there is a lot of stuff doing with coredata my project is in final stage now I installed the application in my iPhone the battery usage is taking more than 90% is that a problem apple accepts it or not
This is really a critical issue if you app taking more than 80% of battery. After iOS 8.0 the OS will automatically kill your app if it will take such huge amount of device battery. So I don't think Apple will reject but this is not a good situation for any app user.
What's the best way to benchmark an iPhone app's battery usage?
I'm working on an iPhone app that uses location services and runs in the background. It seems like the battery drains significantly faster with it running, but when I try to do some structured tests, the results are inconclusive.
The steps I'm taking are:
charge the battery to 100%
remove the SIM (I need it for my other phone)
turn off push for mail/calendar/contacts
reinstall the app
restart the phone
start the app
return to SpringBoard (the app selection screen)
I then wait for about 15 hours and see what the battery is at. The results so far are:
App not running - 69% left
App running - 65% left
App running - 83% left
Turns out the answer is to use Apple's Measure Energy Impact in Xcode.
The info it provides really helped track down what was causing our battery draining issue.
In retrospect, I should have said that I was completely new to iOS, and was not a developer (working on the app as QA).
Doesn't that just tell you that there's not a high correlation between battery usage and your app running? It looks like there's something else that's causing battery drain?
(Watch out though, that something else might be the number of gps satellites passing at the time - the faster it gets GPS, the less battery usage your app will consume - you might have to take a look at how much time your app actually spends running vs sleeping for each test)