I'm building a simple VPN app.
I got networking entitlements, and I created the app extension.
I've configured the VPN to be "on demand" and active while sleeping.
My question is - What happens when the app is in background mode ?
Should I add more app capabilities, or is it enough ?
(And a following question - while in a background mode, the app extension functions like startTunnelWithOptions(...) are still getting called, Am I right? )
The application which starts the Packet Tunnel Provider is called as container app. Here your application is the container app.
The container app and packet tunnel provider runs in separate process. Container app and the Packet Tunnel provider process communicate through IPC.
Even when your application goes background your packet tunnel provider keeps running and handle your application according to packet tunnel provider(VPNManager) status when moving from background to foreground. You need not add any other capabilities.
Related
I have a pretty unique situation:
My iOS app has companion hardware that it's connected to via Wi-Fi. The Wi-Fi creates a local network, meaning that when the phone is connected, there is no outside internet access.
I want to be able to post analytics up to a centralized server that we've built via a simple REST API. The issue is that users may only ever open and close the app while they're connected to the network, meaning that when they do have outside internet access, the app may have been terminated (or at the very least, put in the background).
If I run code inside of
-(void)applicationWillResignActive(UIApplication *)application
OR
-(void)applicationDidEnterBackground:(UIApplication *)application
OR
-(void)applicationWillTerminate:(UIApplication *)application
They may only get called when the user is still connected to the Wi-Fi network with no outside access.
Is there any way you can think of uploading some simple data to our server even under these circumstances? Is there a way to spin up a quick background process to do this after the fact?
Thanks!
You can use NSURLSession to do uploads from the background. Once you submit the upload task, the system keeps it running even if your app moves to the background or is terminated.
I am wondering how to do Inter-App Communication on iOS in iOS 7. It occurred to me that if I was the foreground app I could bind to sockets and act like a server, and if I was the background app (and had a background entitlement like audio) then I can connect to servers. So it seemed to me like it would be possible to do Inter-App Communication by agreeing on a port between 2 apps and simply switching which app binds to a port based on whether it is in the foreground or not.
Problem is, I can never seem to connect to localhost from the background, for example I have this code on a loop:
truct addrinfo *server_address;
int ret = getaddrinfo("localhost", "1666", NULL, &server_address);
int connection_id = connect(self.socketHandle, server_address->ai_addr, server_address->ai_addrlen);
And connection_id is always -1. I am unsure why I cannot connect given the bind process does not throw any errors.
Check this answer: iOS - Is it possible to communicate between apps via localhost?
Also, remember to make sure that you're background app is not stopped when the other app is entering in the foreground (by default the app will be stopped)
But generally speaking I don't think it's the good way to do interapp communication: the 'spirit' of iOS is to generally have only one app running in the foreground. So why do you need to communicate with a background app? I am quite sure that you can find a better way to achieve your result.
Certain kinds of iOS apps are allowed to periodically run in the background. For a background-audio, bluetooth-central, or location-fencing app (as listed in the app's capabilities plist), can the iOS app open a BSD network socket (assuming the device has appropriate network connectivity) when given time in the background?
If so, what kind of problems might one encounter when doing this (errors, timeouts, etc.) other than those that an app would see when networking in the foreground?
I believe other than the services you mentioned the only other background task you are allowed is via the NSURLSession class. Using the NSUrlSession class you are allowed to make HTTP requests to a web server while the application is in the background.
For example, you're app could monitor for significant location changes in the background, and during the location change event you could send the GPS coordinates to the web sever via an NSURLSession.
However, from what I understand this is the ONLY networking you're allowed todo while the application is in the background without hacks. Therefore, I do not believe it is possible to open a BSD socket connection while you're app is in the background.
Our company has a requirement to build an app that needs to have a service constantly running on the background listening for multicast packets and cache its content into variable size files to enhance user experience, the background service needs to run regardless of the app being running. The suggested approaches I saw here and in the docs such as working with notifications wouldn't work as it is mandatory that these contents arrive over multicast which requires the socket to be constantly opened, also fetching using TCP would not be an option as it would increase network load which we're trying to avoid by using multicast. Another approach would be to register the app as VoIP so the app would be awake by the OS when new data arrives in that socket (which would be the multicast socket), but I'm not sure if that fits what apple considers to be a VoIP application, so I'm concerned we would have problems getting the app approved.
Any suggestions on how to implement this solution would be greatly appreciated!
Edit:
This is not an enterprise app, it is intended to be used on a dedicated WiFi and rely on our servers (deployed on the same WiFi) for multicast. It also needs to be public on the store for our customers to download.
According to Apple:
1. Re: Long Running Background listening for multicast packets.
In response to Daniel Inc. on Oct 17, 2014 1:16 AM
Our company has a requirement to build an app that needs to have a
service constantly running on the background listening for multicast
packets [...]
AFAIK there's no supported way to do this on iOS.
Another approach would be to register the app as VoIP so the app would
be awake by the OS when new data arrives in that socket (which would
be the multicast socket), but I'm not sure if that fits what Apple
considers to be a VoIP application, so I'm concerned we would have
problems getting the app approved.
Regardless of the approval issues, the VoIP infrastructure only supports TCP data sockets.
Share and Enjoy
Quinn "The Eskimo!" >
Apple Developer Relations, Developer Technical Support, Core OS/Hardware
In an iOS application if you had to access corporate remote services, through VPN, what would be your pattern to ensure you have connectivity and inform the user if that's not the case:
check that your network and VPN are working (by checking if some host like google.com and some private enterprise host are reachable) and if that's the case then call the remote service?
or call directly the remote service, and if there is a network exception, then check if both a network host and an enterprise host are reachable? (to find-out what's going on and inform the user)
or you would do it differently?
Usual approach:
1)User opens VPN client enables VPN connectivity
2)User uses the app.
Alternative approach:
If you are developing an enterprise application
then you could possibly start and stop VPN connection right from the app using apple's private api.
Advantages of the approach:
So that all the network connections from the app are routed through VPN and user doesn't have to enable VPN connection every time he uses the app.
Reference:
You could find some hot discussions on this topic in the following threads.
Thread 1
Thread 2
Thread 3