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.
Related
I have been looking at the options available to do a user driven on demand sync of a large data set (roughly 1gb) to a iOS device from a central server. The intention is that the user will go offline some time after the sync is complete, and use the app in offline mode for some time afterwards. However, I am running into a lot of iOS restrictions that seems to prevent this.
The beginBackgroundTask does not allow enough time to complete a sync before its suspended as it only allows up to 30 seconds of background processing. I have seen a few references to this being increased by using audio or gps functions however neither of these are applicable to my situation.
The BGProcessingTask apis are at the systems discretion as to when they are run, so are not sutiable for an on demand process.
The NSURLSession api allows for downloads to occur while the app is suspended, however the problem with this api is that it requires the server to extract all necessary data to a temporary file before it can be downloaded, this process can take several minutes. This introduces the problem where the application can be suspended before the server has completed generating the file to download.
I'm aware a background push can be used to wake the app and start the download using the NSURLSession api if the app has been suspended, however this approach places the execution of the download back at the discretion of the OS which can lead to significant delays in the sync actually starting, which makes for a rather undesirable solution.
Its also worth noting that precalculating and caching the data to download in advance is not a viable option due to the number of updates that occur and different permutations of data depending on permissions assigned to each user.
With that, are there any apis that I have not considered, or any misinterpretations to the ones above that would allow me to achieve an on demand sync of such a large data set?
It seems iOS is missing the ability for a user to explicitly opt in to starting a long running process and allow it to continue till complete. I'd assume some other enterprise apps would have come across a similar problem before, and I would be gratefull to see how its been solved.
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 want to create an iOS app using React Native. One of the primary features of the app is that it runs constantly in the background. It also requires using GPS btw (in case that is important).
I have had a number of devs tell me its not possible to do this for iOS, however I have read that it is do-able.
Is this possible to do in the iOS environment? Mainly, if the app is running when the phone is powered off, can you make it open when the device is restarted without the user opening it?
I should say that I am a RN novice and any help is much appreciated.
If your app gets permission to get location while it's not in the foreground, then you will get periodic updates and some time to process it.
For example, if you are giving driving directions.
https://developer.apple.com/library/content/documentation/UserExperience/Conceptual/LocationAwarenessPG/CoreLocation/CoreLocation.html#//apple_ref/doc/uid/TP40009497-CH2-SW10
If there is no good user benefit for you to get the location in the background constantly, you might be rejected. Apple suggests region monitoring instead
iOS supports the delivery of location events to apps that are suspended or no longer running. The delivery of location events in the background supports apps whose functionality would be impaired without them, so configure your app to receive background events only when doing so provides a tangible benefit to the user. For example, a turn-by-turn navigation app needs to track the user’s position at all times and notify the user when it’s time to make the next turn. If your app can make do with alternate means, such as region monitoring, it should do so.
I have no idea how RN wraps this behavior, but no matter what it does (or what a plugin might do), the core iOS behavior is how it is described in that URL.
I verified yesterday (at least on iOS 11.2 simulator) that automatically restarting the app (and the location tracking) after phone reboot works.
The key point is that startMonitoringSignificantLocationChanges needs to be on to wake up the app after reboot. For me the difficult part was figuring out when to turn it on, because I couldn't find a reliable way to detect when the phone is being rebooted or run any code at that point. However, based on initial testing it looks like startMonitoringSignificantLocationChanges is independent and doesn't negatively impact the usual location updates, so now I just leave it on all the time and toggle startUpdatingLocation / stopUpdatingLocation on top of it based on Core Motion-detected activity.
Otherwise requirements are the same as for any location tracking on the background, i.e. handle permissions and don't process too much. Apple documentation explains how to detect that the app was relaunched by a location event.
Here's a react native module which basically helps you achieve what you're describing: https://github.com/transistorsoft/react-native-background-geolocation
I have been investigating iOS background fetch for our enterprise applications. According to articles like this, there are limitations like having 30 seconds to download before the app is terminated and the may be (unconfirmed) a penalty where after 3 timeouts, an app gets banned from background sync. Also if the user kills the app, fetches stop happening -noted here.
The goal is to be able to retrieve data from our servers periodically when app is suspended/not running but sometimes the transfers can take minutes due to long running SQL. I don't want to implement sending periodic notifications to all users.
Before I go down the path of developing for the iOS background sync, I needed to do some due diligence and research alternatives to iOS's background sync and didn't find anything.
Has anyone seen or developed an alternative to iOS's background sync or dealt with this issue for their enterprise apps?
As an enterprise app there's nothing extra you can do except that you can use whatever background modes you want (audio, location, voip etc,) without needing to have a legitimate reason to do so.
Where this might assist is:
you could make use of a significant location change (as opposed to a regular location change) notification to run your app in the background. The problem with this is it of course depends on the user of your app to move around. However, assuming everybody in your workforce commutes to/from work with their iPhone then you would have two opportunities each day for the app to run in the background. A app run due to a location change can be made to execute in the background for more than 30 seconds.
voip pushes: Unlike a regular push notification, a voip push will launch the app even if the user has force terminated it. To make use of this functionality is only a tiny bit more effort than using regular push, you don't have to do anything regarding making or receiving an actual voip call, you just need the voip capability and voip certificates instead of normal push certificates.
The comment in that link is not correct regarding force quitting and background fetch - a user force quitting an app does not make it ineligible to run for a background fetch, I have force quit my own app that uses background fetch but it will still be started by the OS, however what will happen is that the frequency when the app is run will decrease lots, and if the user never runs the app again then the OS will stop launching it.
A user force quitting an app will prevent other things from happening, such as it running in the background in response to a silent push notification for example (unless its a voip push).
Also the 30 seconds in not related to download times, NSURLConnection would stop after 30 seconds, NSURLSession is designed to continue to download on your app's behalf. But if you are downloading and then applying lengthy SQL processing it would be an issue. But minutes of processing time seems excessive, are you sure its all optimized?
The goal is to be able to retrieve data from our servers periodically when app is suspended/not running
The only reliable way to achieve such a behaviour is implementing a User-facing Remote (Push) Notifications framework on backend & apps.
You can append 4kB (or 5 for VOIP) worth of data in the push JSON payload, eliminating need for a network fetch request if implemented in a handshake mechanism.
You can evaluate usage on Silent Remote Notifications to augment content updation & fetch small amounts of content opportunistically, though it has the same as Background App Refresh.
You can definitely improve the API that can take minutes due to long running SQL
And remember you need to have the app updated only when the user actually fires it up. Evaluate implementing a catchy & smooth fetching content screen that transitions into the actual screens once all data is fetched.
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.