I know that iOS has its own task management method and users may never need to care about the processes background. But my requirement is to ALWAYS keep a program alive, it cannot be killed under any circumstance.
Is there a way to do this like "LOCK" or something else function already existed? I'm using iPad4 ios6.01 system.
Thanks
No, that's not possible. (Nor should it be if you think about it. What's to stop every app from saying that it can't be killed?)
The closest you can get is for things like VoIP apps that do run in the background and automatically respawn when they die.
The alternative is to work like every other app: when your app goes into the background you save state so you can restore if it gets killed. iOS 6 even has the state restoration functions.
Short and simple
No, there is no way to make your App "unkillable".
A bit longer
If your App requires to receive location updates while it is running in background, you can use the standard way Apple offers to do so.
Two other options are: your App is an VoIP application (afaik they also get autostarted on system boot) or you're playing audio in the background. Without knowing too much details about how iOS handles such Apps, they might get killed if the iDevice runs out of memory (or the user kills it). But you probably already knew that.
However, as you already mentioned, iOS manages everything on it's own and will kill Apps that run in background to free memory. Additionally as we all know, a user might kill your App at any time using the task switcher of iOS.
And don't try to use the described methods just to run tasks in the background. If Apple finds out about it, your App will be rejected/removed from the App Store quickly.
Related
I have a VPN-Client app that asks the user to pause the connection for 5, 30, and 120 Minutes. The user probably leaves the application to do some work outside of my app in this period, therefore I need to Reconnect the app even if is in the background.
I tested these ways:
UIApplication.shared.beginBackgroundTask: It only leaves the app unsuspended for 30 seconds.
DispatchQueue.global(qos: .background).asyncAfter: It waits to app enter the foreground to toggle.
Thread.sleep in Background Thread: This waits to launch as DispatchQueue
Local Notification: Unfortunately it does not support silent mode as APNS.
My problem with possible ways:
Using APNS and Scheduled Push Notification` to send a silent message: This way probably works, but I prefer to handle it without a server.
Using Background Fetch from Capabilities in Background Modes: I searched a lot about this, and I think it was used for background app refresh and cycling tasks that should be run every day, hour, etc. Therefore, my case can't be used, or it's not efficient at all.
Using Background processing from Capabilities in Background Modes: I searched a lot about this too, I didn't quite catch that it can be used once, or this should be used in a cyclic way as Background Fetch. and my task to reconnect is not that heavy and long to use this strict feature that many times apple mentioned using alternative ways if possible.
Apple only allows a very limited set of app types to run in the background:
Music streaming apps, turn-by-turn navigation apps, VoIP apps, and maybe one or 2 more. (I haven't looked at this in detail for a couple of years so my info is a little stale.)
They do support various tasks like background downloading that the system performs on your app's behalf, but you want your app to re-launch after the designated period and start running again. (Even if the user just locks their phone while your app is paused, the app won't get any CPU time and may be terminated without warning.)
In short, I suspect you are out of luck.
It seems like a VPN app is another class of app that should get "always running in the background" status.
If you are a licensed Apple developer I suggest using one of your pre-paid support tickets to ask about OS support for what you are trying to do, but I have a feeling the answer is going to be "no dice."
I'm working on a big app that has a huge Firebase footprint, and is constantly updating to stay in sync with other similar apps and a web service.
The app was designed as a kiosk app, but we discovered users are switching between it and other apps - in some cases often.
While we don't know of any problems, the question came up - when we get moved to the background, should we disable keepSynced, wait some seconds to allow inflight messages to complete, then on coming into the foreground re-enable it?
In a general sense, I don't see any advantage to doing this. iOS and Android automatically manage the lifecycle of apps the move to the background. Backgrounded apps may be killed outright to save memory and battery, and in that case, it doesn't matter what Firebase APIs you may have invoked previously - the app process is dead. I would just let the OS deal with moving things around and not try to optimize any further, unless you have some very specific requirements.
I’m trying to make a focus timer app like Forest, that detects if you leave the app, either by going to the home screen, switching to another app or by first locking the phone and later proceeding to a different app through notifications, widgets, camera etc..
What I can’t figure out is how to monitor such state changes even after the phone has been locked for a while. There are no “background modes” covering this use case, so I would expect the app to get suspended after a while in the background. Nevertheless, apps like Forest do this successfully. Do I need a workaround to keep the app awake, or am I missing some approach that doesn’t require background execution at all?
Help much appreciated!
If I had to guess, it's probably a combination of a few things:
Use the normal app delegate callbacks for app state transitions to determine if the app is still able to execute code. That's the easy part.
You could do something with string and regex processing of console logs to detect when other apps open, close, etc. and other activity which would allow you to detect activity on the device coming from places other than your app.
You need to use some sort of framework that Apple says can get data even in background state. One such framework is Core Motion. There may be others as well that suit your app's specific needs better.
See Execution States for Apps.
See Background Execution.
See Cocoanetics: Accessing the iOS System Log.
See Keep iOS App Awake To Monitor Movement.
See Apple System Log Facility.
I have a volume control app in the iOS store, but one problem that my users have frequently is that the device kicks it for memory control. Is there any way to either force it to stay active (by permission) or to at least alert the user when its no longer active or in danger?
All the answers are under Background Execution in the iOS Developer Library.
Of course, here's the philosophy:
Always try to avoid doing any background work unless doing so improves
the overall user experience.
See Table 3-1 for the types of background execution. There's a category for audio but it requires audio to be played from the app. It does not sound like your app fits in here. So you'll want to look at notifying the user.
You could send a notification to the user when the app falls to background with applicationDidEnterBackground(), or just before it quits with applicationWillTerminate(), supposedly time-permitting.
Running in the background is permitted. I have an app that does it and while the rules have changed and adapting to it has been gut wrenching at times, it is pretty straightforward. In your case, I would think that you could setup to be notified and then just disappear, no? waking from a notification is part of the state changing protocol and you should be able to do that.
As a point of comparison, in Android, background operations like yours would be implemented as services and would have no fear of being terminated. The strangest thing about the way ios chooses to allow background activity is that you are applying for status one time. In Android, I was able to indicate that a single activity should be kept alive when the app is backgrounded, all others could be terminated. There is no way to do that in ios.
I take it my disappear and wait for notifications is probably not going to work for you because there is no way to be notified of volume changes. You must be polling? In which case, you probably are going to have to ask to be kept alive. Would be nice if you could just piggyback on other services, e.g. keep me alive while music is playing.
To answer your other question, yes you will get notified if/when you really are going to get termed, so you could send a notification at that point.
I am trying to create a GPS location app that will monitor and send the location to a server. I want the location service to be able to continue to run even after the app is terminated/killed(not just in the background).
Does anyone have any idea on how to do this?
You can do this, but your options are very limited
Your app won't be able to be in the store:
2.8 Apps that install or launch other executable code will be rejected
https://developer.apple.com/appstore/resources/approval/guidelines.html
It might get kill on background
Save user data and app state information. All unsaved changes should be written to disk when entering the background. This step is necessary because your app might be quietly killed while in the background for any number of reasons. You can perform this operation from a background thread as needed.
http://developer.apple.com/library/ios/#documentation/iphone/conceptual/iphoneosprogrammingguide/ManagingYourApplicationsFlow/ManagingYourApplicationsFlow.html
But if you still want to do this, check this out:
I guess the answer is 'sort of'. If you don't want to jailbreak phones, your options are rather limited. As long as you're only intending to distribute internally, you can look into the VOIP background services.
It's part of iOS 4's background services, and is intended to allow VOIP apps to run constantly in the background to pick up events such as incoming calls, etc. It is possible to use it to achieve other things, such as a regularly scheduled service (I think there was a recent question where somebody wanted to use it to act as a 'data counter', again for the enterprise program).
From Here: iphone daemon process