I have an app that runs in the background. This application is called to be able to update and then goes to sleep.
For some reason, it stops working after a few hours.
I have some theories but I can not find documentation about them.
iOS closes applications when there's a lack of memory.
Does anyone know the order used in this process?
Does it choose applications that have been running longer, which occupy more memory, or does it simply randomly close apps to get the needed memory?
Is there a maximum time limit that an application may be running in background?
Is there a maximum number of repeats for an NSTimer?
Does iOS close applications in the background if battery levels are reduced in order to conserve power?
If anyone can answer these questions, or provide some information about them, that would be great.
The theories are founded on the basis of report of clients.
To answer point by point (in a simplicistic way):
An app running in background which is going into out of memory condition should get killed by the operating system, but its application delegate should receive an applicationWillTerminate message.
No time limit is officially stated for background running apps.
NSTimer can only be of one kind out of two: repeating or non-repeating. You can refer to the NSTimer class reference documentation for the evidence of such aspect.
The app can't do that, by Apple policy if I can remember correctly. If the device is running low on battery, it must not intervene on open apps to extend battery duration.
For a complete description of apps background running modes you should refer to Apple Developer Documentation at this link.
It is a good starting point to understand multitasking and the correct policy to adopt if your app has to responsibly run in the background.
In the Apple Docs you can find a very analytical description of the allowed background execution modes, under which circumstances you can use each one and also some best practices to follow. If your app follows nothing of the above, then things are getting fairly arbitrary. AFAIK there is no way to know when the operating system will kill your app or do anything to prevent it.
Start by looking into the crash report with XCode Organizer. The crash report will have an exception code that shows why the application went away.
If you have a problem with the background operation, as hinted in the question and the answer from spassas, you will see the exception code 0xbad22222 in the crash report.
See the Apple doc on exception codes for more details.
Related
According to the docs, sending sendMessage from the WatchKit app will wake the iPhone app if it is inactive.
I would like to know the differences between such a wakeup app startup and a normal one. Surely a background process has a lot of differences to a normal foreground app. However, I could not find a thorough documentation on the subject.
Here's what I found so far:
Since such a "wakeup" is not a normal app startup, I expect didFinishLaunchingWithOptions to receive a special launchOptions key. After all, the user did not start the app on the home screen, so there should be an indication in launchOptions. But when I tried it out, launchOptions was nil. Doesn't that contradict the docs?
I also thought there should be differences because there is no UI present in a background process. So perhaps [UIScreen mainScreen] might be nil. But there seems to be no difference in mainScreen in the background process. In my AppDelegate.m, the code that creates the main window seems to run exactly the same way as in the foreground process.
I also expect that there are limits to the background process. Since the user did not actively start the process, I'm pretty sure that it cannot run for an infinite amount of time. Maybe there are also stricter memory limits.
Is there a way I can debug such a background process in XCode? Can I tell XCode "wait until the app runs on the iPhone", such that the debugger gets attached as soon as the app runs?
I also tried this in a React Native app. The Objective-C code in AppDelegate.m seemed to run exactly the same way, regardless of background or foreground process. However, the whole Javascript part of the app did not run (which is kind of expected, because in a background process, we do not need any React UI). But there must be a difference in the process that causes the Javascript part to not run.
Please don't consider this question to be about "more than one question". The question of this post is quite clear: I want to know all the differences between a didReceiveMessage background process and a normal one. In the enumeration above, I just listed all the differences I would expect or that I have encountered so far, and the lack of documentation on those topics.
I think the background mode is just a UIKit concept. The app is started (thanks to the UIApplicationMain function) as a regular one but your app UI is not rendered.
It is just a warning: this is a transition state, your app can be suspended at any moment, be concise. The documentation is clear.
Regular UIKit APIs are available (if it was not the case, imagine all the potential crashs). But you won't receive any external events like touches.
Some external tasks like asking permissions, launching audio sessions etc would probably not be available too.
You can wait for the app to be launched by using the wait for the executable to be launched option in the scheme panel.
But when I tried it out, launchOptions was nil. Doesn't that contradict the docs?
Unfortunately LaunchOptions doesn't cover all ways an app gets launched. So if you see it nil then your case is one them too.
But there seems to be no difference in mainScreen in the background process.
That's true and expected. Things all get launched using the main thread. See here
Is there a way I can debug such a background process in XCode?
GaetanZ Has already answered this. Additionally you can use os.log and console together. That gives you a more realistic approach. Xcode interruptions are not fun to deal with. The wait for the executable to be launched scheme change often makes debugging super slow or often Xcode just disconnects or even throws you weird errors and the app gets killed without even giving you the option to attach to the debugger again.
I often use reboot the phone entirely. And then use oslog to see what happens to my app without ever having Xcode connected. For more on that see here.
A reboot is different to user-termination because often things don't get launched after-user termination. That being said I don't think the OS restricts app launch if user engages with their watch — even after a user-termination. Because user-engagement trumps everything.
However, the whole Javascript part of the app did not run (which is kind of expected, because in a background process, we do not need any React UI).
You then also said "which is kind of expected, because in a background process, we do not need any React UI"
I know very little of React, but also I'm confused what your question is about if you say it's expected.
But the part that the AppDelegate goes through all it's life-cycle is expected as previously mentioned.
You need to add a gazzilion amount of logs to see where you have a different code-path.
Most developers don't know that launching the app into the background will go all the way till the root viewController of your app and all its child viewcontrollers and stuff. But you learned it the hard way. Just as I did. Congratulations!
But once you know of that then the next thing is making sure your app doesn't segue into a different code-path i.e. on a normal launch you get WillBecomeActive and willEnterForeground, for a launch into the background you get something else. I'm not sure what it is right now. I think it's WillBecomeActive & didEnterBackground. Not sure.
Or like you may not be setting the delegate of your webview before things fire off and you miss its callbacks.
Remember app being in a background state doesn't mean things get executed on background queue. everything gets executed on the same queue/thread as it would in a foregrounded app. The only thing different is that the OS will often restrict network calls when an app isn't provisioned for them.
Likely that's what's happening. Like the OS doesn't want a webview to make network calls when it hasn't informed the app to be using and background Tasks as mentioned here or here
It seems like older versions of iOS allowed your app to run for 10 minutes in the background. Now it seems like iOS only allows your app to run for a maximum of 3 minutes. I haven't found any documentation mentioning when, or in which versions, this changed, or any estimates provided by Apple for how long your app can run in the background.
I need to be able to run in the background, because my app is connected to an external device via TCP. I already know about the hacks you can do with VOIP and playing silent audio (both will get your app rejected).
Is there anything I can do to get my app to keep running in the background longer than 3 minutes?
We haven’t had the old 10 minute window for years so that is simply no longer applicable. That was reduced to 3 minutes in OS 7, and further reduced to 30 seconds in iOS 13. (There is a new concept of background tasks, for running tasks longer than 30 seconds, but the the OS will run these at its own discretion, e.g. at night, when the user is charging their device, so that’s not really applicable here).
The short answer to your question is that you cannot submit apps to the store that run in the background indefinitely unless it’s one of a very limited list of permitted background modes.
If you can go to the “Signing & Capabilities” tab of your target and add “Background Modes” and you can see the list of alternatives:
So, with the caveat that you cannot do precisely what you asked, here are a few observations:
The “External accessory communication” background mode (see ExternalAccessory) seems promising, but that’s for bluetooth or wired connections only. So unless you can refactor/reengineer how your devices communicates, that is likely not a viable solution.
There’s an interesting question of whether just keeping the app running in the foreground might be helpful (e.g. judicious use of idleTimerDisabled). I know this solves a different problem (and should be used only where essential), but perhaps it’s option for you.
If your external device is Internet-enabled and you want it to inform the app of some event, perhaps you can have it communicate its intent to some web service that then triggers an APNS push notification that your device can receive.
Bottom line, you can’t do what you ask, but if you edit your question with more details about the nature of the device and what your iOS app wants to do with that device, we might be able to provide better counsel. But in answer to the general question “can I just keep app running perpetually in the background”, the answer is “no.”
I am facing a very weird issue: my iPhone is restarting.
This issue occurs in a particular scenario only.
Step 1: I have a sync process in which I'm loading data for the whole app. So I'm basically doing a heavy API call by uploading 4-5 camera captured images and syncing the app data;
Step 2: After syncing, I'm pressing the iPhone home button to make the app go in background;
Step 3: I'm locking the iPhone screen(by using side button);
After a few seconds I'm seeing the apple logo and the phone seems to restart. This is not replicating when the app is connected in debug mode. I checked the debug navigator app is using only 125 MB of memory, disk and network values is 0%. Energy Impact is showing high, I'm not sure this is due to high energy impact. I'm facing this issue only on iOS 12.4.
The fact that the phone (or possibly just springboard) restarts, and not just your application means this is Apple's bug. You're not supposed to be able to crash iOS even if you try.
Finding a likely cause will be hard since the system is not behaving the way it's supposed to. The device's logs may have more information from things other than your app. This may be a system API breaking due to any number of actions from your application.
Often with this kind of thing the next OS version will fix it, but if that's not the case or it's important to track down I would try removing ways you're interaction with the system (background APIs, notifications, etc.) and see if anything fixes the issue.
If you find the problem, you may even be doing things the "correct" way according to the documentation and have to find a workaround. If you have the time you can submit a bug to Apple so the underlying issue has a better chance of being fixed.
It seems when your app is in the background and phone locked, Automatic Reference Counting (ARC) closes some connection or deallocates a resource that makes the iPhone restart. Are you closing all connections and removing all references once the upload is complete?
Phones do not spontaneously restart just because of an app’s actions. You’re having an issue with your phone, not with a program. You need to repair or replace the phone.
I haven't been doing this long, but this is the first time that I've had an app rejected. This is what was in my rejection.
PLA 3.3.1
Your app uses public APIs in an unapproved manner, which does not comply with section 3.3.1 of the Apple Developer Program License Agreement.
Specifically, your app contains a mechanism to keep a device awake. Please see attached screenshot(s) for reference.
Since there is no accurate way of predicting how an API may be modified and what effects those modifications may have, Apple does not permit unapproved uses of public APIs in App Store apps.
The screenshot that they included showed my setup screen where I give users the option to have the application keep the device awake. I tested it, and it only keeps the device awake when in the application. I did not come up with this idea all by myself. I've seen it as an option in other apps.
I am not using anything non-apple to do this. This is my code for keeping the device awake.
UIApplication.sharedApplication().idleTimerDisabled = keepDeviceAwake
where keepDeviceAwake is a Bool that is turned on or off by a user setting.
Is there something wrong with the way that I'm using this or what I'm doing with it?
To give more of an idea, this app is a counter app. I was thinking that it would be really annoying to have to keep turning on the iDevice when counting things, so I give the option to keep the device on while in the app.
The documentation note on idleTimerDisabled says:
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. This includes audio apps. With appropriate use of Audio Session Services, playback and recording proceed uninterrupted when the screen turns off. The only apps that should disable the idle timer are mapping apps, games, or programs where the app needs to continue displaying content when user interaction is minimal
Apple probably feels that your app doesn't fall within the guidelines.
I searched informations about possibilities when running an iOS app on background, but I didn't found same on different sites.
My application has to read the battery level (with step of 1%) and the time, but I don't know if I can read that when running on background.
Please if someone is sure about it or know a site to read these infos, it will be very nice.
EDIT : I've one more question, can I just open my app (to perform more actions) when the notification center return a battery state under 5% for example ?
No, you can't.
It's not possible to let your app running on background, it's iOS system's limitations.
In iOS 7.0 and later, you have opportunity to do some pre-fetch stuff even your app is not running, through the method like application:performFetchWithCompletionHandler:, but you should tell the device by posting remote notification from your server.