I'm building an activity analyzer application for iPhone and I use iOS 7. In order to do these i use CMMotionManager and I access accelerometer data.After this I write the datum to database. My application has to work also in background and I used queues, GCD, blocks and other such things in my code to do this properly. Problem is, all of these are working properly when iPhone is plugged in with Xcode but if I run the app without Xcode, app runs about 4 or 5 minutes.After, it is terminated.What is the reason for this?
iOS apps can only run in background, if they fit in one of apples defined background modes such as "App registers for location updates","App provides Voice over IP services","App plays audio","App processes Newsstand Kit downloads","App communicates using CoreBluetooth"",App shares data using CoreBluetooth" and a few more. All background modes you will find in xcode in the capabilities section auf your project(click on project name upper left->mainwindow->second tab).
if your app fits into one of these modes, you must enable this in your app.plist by setting the checkbox in the capabilities section.
if your app doesn't fit in any of these modes you can run in background only a limited amount of time and then iOS stops all activities.
For testing you could start any background mode. but when your app shall be reviewed for deploying via app store apple will reject the app if you use the background mode without legitimation.
The reason for this is that iOS 7 (actually all versions of iOS) will suspend a background task, and potentially terminate it if it's misbehaving, only certain kinds of apps can keep running. Here is the apple doc on it: https://developer.apple.com/library/ios/documentation/iphone/conceptual/iphoneosprogrammingguide/ManagingYourApplicationsFlow/ManagingYourApplicationsFlow.html#//apple_ref/doc/uid/TP40007072-CH4-SW20
So, given your situation, you'd most likely have to "lie" about what type of app your app actually is, which will get you rejected from the app store.
If you do decide to go the route of a hack, be very careful about battery life, cpu usage, and memory usage, as there is a reason apple did this.
FYI: The "type" is set in your Info.plist file.
Related
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.”
Suppose I am using one App (no other App is active). Now I lock the iPad by simply clicking the lock button or may be I put it in background mode and put my iPad somewhere.
After what amount of time, the App will get killed automatically by system if I don't use that App? Is there any specification by Apple or we cannot say anything that App will launch from scratch in some scenarios.
Note that in any scenario, I don't kill my App manually.
iOS generally (at least in current versions) doesn't kill apps after some arbitrary time. It kills them when it needs to free up resources. Since modern iPads have quite a bit of memory, that means that apps can stay in the background for a very long time depending on how the iPad is used. As Andreas notes, however, there are no promises about that.
I have a Timer which plays AVAudio at a specific time while the screen is locked (app in foreground when locked and plist setting 'Application does not run in background' set to YES).
When I run my code while my iPhone is connected to Xcode it works as desired, playing audio while locked even when the iPhone has been locked for hours.
Now if I disconnect my iPhone and just open the app by tapping the icon the audio won't be played if it's set for more than a minute.
Is there a difference that causes this problem? If I would publish my App to the AppStore which behaviour would my users get?
That 'Application does not run in background' flag is a very old flag that means your app does not support multitasking and should be terminated when the user presses the home button. There's no good reason I can think of to set that flag on a newly developed application. Unless you understand exactly what it's for and are positive that setting it to yes is the correct thing to do, don't do that.
(That flag was added when iOS 4 was released, to allow apps that could not handle multi-tasking to request the old terminate-on-home-button behavior from iOS 3. Given that we're now 6 major iOS releases from iOS 4, it seems outdated.)
So remove that flag. It probably doesn't have any impact on your question, but remove it or set it to no in any case.
If you want to run a timer while the phone is locked and play sounds at designated times then you will probably need to set your app up as a background sound player, and ask for more background time when you get a message that you are going to the background.
That being said it's likely that Apple will reject your app. Running a timer from the background means that the processor on the phone has to run at full speed all the time, which will DRAMATICALLY reduce battery life.
Apple only allows a very small subset of apps to run in the background, and then only under specific circumstances (like a background sound playing app when the user is actively listening to music, or a navigation app that is actively tracking the user's location and notifying them when it's time to make a turn to follow directions.)
Should be no different. If you'd like to feel what do your users' feel then you can publish it to TestFlight which is the best app beta test environment. Find some testers or try it yourself.
The directions should be to verify the playing logic and the sound file relationship which link to the connection.
I want to know if there is anyway to keep my WatchKit app running in the background, or if I can possibly program it to launch (i.e. transfer from inactive state to active state) once a certain condition is fulfilled?
My app is running perfectly while the WK App is open and active, and it even runs fine when the iPhone is asleep, or when the parent iOS app is in BG mode. However, I really need my app to continue running in the background on the watch itself. Is this possible?
Not possible. Because Apple Document for watchkit clearly mentions that "WatchKit extensions do not support background execution modes,they run only while the user is interacting with the corresponding app on Apple Watch.".
You can refer apple document Link to Apple Doc
Read Communicating Directly with Your Containing iOS App.
I am really stuck on this problem and I need your help! I'm doing an iPhone app.When iPhone swap between app and Facebook redirection in safari , iPhone shutdown the app for memory saving.
What I am doing is I am providing fb sharing in background from my app.
When I am doing fb sharing its shares successfully in background and comes back to my app successfully.At that time my app is not crashing. But when I go to safari and type Facebook and open fb site to check my shared post , in background my app is crashing.
This issue is coming in iPhone with iOS 7, I am not facing this issue in iOS 8.Check this post : Prevent IOS to shutdown an app when it app switch to facebook for login and permission request but this solution doesn't work for me as I am using pod to install fb and doing background share.
Though it's too late to answer this but I believe it may be helpful for others.
In App Programming Guide for iOS under "Being a Responsible Background App" section it was said that
your background running app would be terminated if it doesn't follow one of the given requirements.
You can familiarize with the full documentation. I'll quote 2 of them which exactly fit your problem:
Being a Responsible Background App
The foreground app always has precedence over background apps when it comes to the use of
system
resources and hardware. Apps running in the background need to be
prepared for this discrepancy and adjust their behavior when running
in the background. Specifically, apps moving to the background should
follow these guidelines:
Do not make any OpenGL ES calls from your code. You must not create an EAGLContext object or issue any OpenGL ES drawing commands
of any kind while running in the background. Using these calls causes
your app to be killed immediately. Apps must also ensure that any
previously submitted commands have completed before moving to the
background. For information about how to handle OpenGL ES when moving
to and from the background, see Implementing a Multitasking-aware
OpenGL ES Application in OpenGL ES Programming Guide.
Do minimal work while running in the background. The execution time given to background apps is more constrained than the amount of
time given to the foreground app. Apps that spend too much time
executing in the background can be throttled back by the system or
terminated.
To sum up, maybe your app is doing one of the above-given tasks when it's moved to the background after Facebook sharing.