I have a requirement to develop an app that is capable of receiving pushed information from a server - which as its not possible to intercept SMSs or apple push notifications would probably have to be implemented as a poll and see what's there or similar type of thing.
However of course such a thing isn't possible if the app isn't executing in the background.
The app couldn't be considered to be musical or voip related, however its possible that it could be considered to be gps related as the pushed information would be displayed to the user based on certain triggers, and one of those triggers could be location.
Would this app with a UIBackgroundMode of gps submitted to the app store stand a good chance of being accepted?
i have been trying to do the same thing and here is what i found
iPhone - Backgrounding to poll for events
(top answer: update 2)
shows a method that should be ok, meaning your app wont be rejected for using it. the guy who posted it said it should be ok and i have asked other members who said the same (i have not verified this myself).
here is my implementation of that post
local notifications?
You don't have to use a hack for your requirements.
iOS provides a facility whereas your application is suspended but your socket is still monitored. If there's any incoming traffic on the socket, the app is woken up and handed back the control of the socket.
Advanced App Tricks
Look under the heading, "Tips for Developing a VoIP App"
Related
We have been looking for a reliable way to periodically get data from a URL from an iOS app, regardless of the state of execution of the app on the device (foreground, background, suspended or terminated/force-quit).
We have gone through all the questions on this topic that are on this site, and their answers, as well as all the relevant iOS documentation from Apple and blog posts we can find on the subject. But, we have not yet found a solution that will work.
Here is what has been considered/implemented:
Background fetch - This is our current implementation. It works at the whim of the OS as far as the frequency and timing of the fetch goes, and only when the app is not "terminated" or "force-quit" by the user. This has been found to be totally unreliable, as the users themselves don't understand the quirks of iOS, and force-quit the app, yet expecting it to function even after that. The app deals with financial information, and thus can result in loss of potential financial gains to the users if the fetches are not performed on a schedule.
Change notifications from the server - this is not an option, as we neither store nor wish to store certain information on a server, for privacy reasons. Therefore, we cannot use this.
Silent notifications from the server to trigger fetch - again, this won't work if the app has been force-quit, as the notifications are not delivered to the app in that state.
PushKit - this is what apps like WhatsApp or Vonage would use to fire the app regardless of its state of execution. However, this is only available to VoIP apps, and we don't fall into that category. Can this still be used by non-VoIP apps? If so, we could settle for this but only as a last resort, as the preferred option is to have it all done from the app without involving a server to generate "empty" push notifications, simply for the purpose of triggering a URL download.
Given the nature of the app and the potential for the user to benefit financially, it seems rather harsh that iOS would not allow a simple operation such as a periodic download of a URL. So, hoping that someone knows how to overcome this challenge.
As an aside, the exact same functionality on Android works like a charm, regardless of the app's state of execution.
I am starting an application using Restroom and have a few questions about the iOS SDK.
I read through the documentation here http://documentation.telestax.com/restcomm-ios-sdk/doc/html/Classes/RCDevice.html#//api/name/listen
I have also checked out this:
https://github.com/RestComm/restcomm-ios-sdk
I see that the RCDevice class has a listen method and an unlisten method. If I want the device to always be available to receive calls should I have the listen method always going? If so, is this going to be terrible for battery life?
How do I make sure that the application is always running on the device so that it can always receive calls? I am pretty sure that iOS 10 will stop background connections unless the app is running in the foreground.
Is there a way to wake the application or open the application in the case of an incoming call? Can I use push notifications or something similar to wake/open the app?
I already replied to this question on the Restcomm Forum, but let me also answer here for better visibility by the community:
Yes, once you call unlisten() you will no longer be registered and hence receive no incoming events.
Ok, so it varies per platform. For Android since the SDK is wrapped in an Android Service even when the App leaves the foreground, the SDK continues running and you are able to receive events (we still need to check some updates on Android O though on that respect). For iOS we haven't implemented that yet so once you leave the foreground you are not able to receive any events :(. However, the plan is to move to Push Notifications functionality on both platforms soon.
Please check (2). Also, without Push Notifications, we were planning of supporting this with https://github.com/RestComm/restcomm-ios-sdk/issues/153, but also this isn't ready yet.
Best regards,
Antonis Tsakiridis
I have always coded for Android, and now I'm looking to expand my knowledge to iOS development; so I'm really new at this, please be patient.
I understand that only a small group of apps are allowed to run indefinitely in the background. Those are VoIP, Music players and location tracking apps.
I want to write a chat app using the XMPP framework. Everything is fine until the user puts the app in the background, in which case, the app will stay connected for about ten minutes to then be killed by the system and therefore the user won't be able to receive new messages.
I am aware of hacks to keep the app alive. Hacks such as defining it as a music playing app in the info.plist file and then just play some empty sound indefinitely. But I'm also aware that Apple will reject the app when it's time to publish to the App Store.
So, normally, how do other apps do it? How can other chat apps stay alive in the background to receive new messages from the servers? Apps like Google Hangouts, IM+ and such?
Ideally, they aren't really running in the background, but use push notifications, as others have mentioned.
But some chat clients seem to do something else: I've verified (by sniffing the traffic of an idle iOS device) that at least Google Hangouts, Facebook and Skype all keep a persistent socket opened in the background, and regularly send traffic to keep it alive.
I'm suspecting that they are using the VoIP exceptions to Apple's otherwise strict background execution policies. iOS allows "VoIP apps" to run in the background and keep one socket open to be notified about incoming calls and messages.
Maybe they are also using the new "background fetch" feature of iOS 7, but as far as I know, that doesn't allow persistent socket connections.
The iOS operating system allows for the existence of something called a PUSH NOTIFICATION
There exists hundreds of tutorials online which teach you how to implement the notification code and how to respond accordingly when you receive such a message!
http://www.raywenderlich.com/32960/apple-push-notification-services-in-ios-6-tutorial-part-1
Check this link out for an in-depth tutorial on push notifications!
http://maniacdev.com/2011/05/tutorial-ios-push-notification-services-for-beginners
I think most of these apps use push notifications and just load the last messages from the server as soon as the app is being opened.
While there are some hacks, and your app can ask for more time when it goes in background (up to a point, and with no guarantees), this is a perfect application for push notifications.
The server tells the phone there's a message, and iOS wakes your app up to process it.
https://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/Introduction.html
As of iOS 7 there is a new background-execution mode - 'fetch' for apps that need to periodically fetch new data. It sounds like your case would meet that definition.
You can find the information in the iOS App Programming Guide -
Fetching Small Amounts of Content Regularly
In iOS 7 and later, an app that retrieves content regularly from the
network can ask the system for background execution time to check for
new content. You enable support for background fetches from the
Background modes section of the Capabilities tab in your Xcode
project. (You can also enable this support by including the
UIBackgroundModes key with the fetch value in your app’s Info.plist
file.) At appropriate times, the system gives background execution
time to the apps that support this background mode, launching the app
directly into the background if needed. The app object calls the
application:performFetchWithCompletionHandler: method of its app
delegate to let you know when execution time is available.
You can also use push notifications, but that requires some server infrastructure
An app running in the background has limited capability. Read App States and Multitasking thoroughly to decide how best to design your app. Chat is not listed as one of the specific exceptions that can operate with a more relaxed policy. You will never be able to "keep [your] app live in background forever." You might be able to leverage an iOS 7 feature also described in this guide, Fetching Small Amounts of Content Regularly.
iOS App Programming Guide: App States and Multitasking
https://developer.apple.com/library/ios/documentation/iPhone/Conceptual/iPhoneOS ProgrammingGuide/ManagingYourApplicationsFlow/ManagingYourApplicationsFlow.html
I have a chat application developed by JS. I want to send PING to server once in a while. Its not a problem if app runs on fore ground. The problem is when user minimizes it or open another app. My app looses its focus and gets into suspended state.
I have following two use-cases.
To keep the chat session open I need to send PING to server (Its an IRC server) every X minutes even the app runs in background.
We also need to check for new messages (by ajax on a local http server) and add a local notification to the notification queue so when user clicks on it app can resume
I have found apple does not allow running apps in the background. if they allow they require special permission. I found some apps does it by requesting finite length execution time.
What is the best way to get highest possible background execution time? As a chat app can I request permission for voip, location or any other way ?
Note: the app will be running in an environment where there is no Internet. Hence push notification will not work here.
Update: After doing a lot searching I found background fetch. It seem background fetch will suite it. But still the problem remains, its not called in a timely manner.
This sounds like an interesting problem. From reading the various comments, it sounds like you want this to work when you're on a local network - so you have wifi, but the wifi router/base station isn't connected to the actual internet?
Because background refresh isn't going to be predictable - you'll never know when it is going to update - you might want to get creative.
You could look into exploiting iOS VOIP support, only without the Voice! Apple has some tips on VOIP here. VOIP basically uses something called SIP (Session Initiation Protocol), which is signalling layer of the call, and a lot like HTTP. It's this SIP layer that you want to take advantage of.
This isn't going to be terribly easy, but it should be achievable. Setup your app to use VOIP, and then look into something like PJSip as your SIP library. Then, on your local network have a SIP Server (I'm sure there are plenty open source implementations) that you can register your iPhone against (so your server knows where your phone is, pretending to be a VOIP phone). This should work, because it doesn't need to go through Apple as far as I am aware... And will run happily on your local network.
Then, the server can send a message via SIP to the handset, as if it were instigating a VOIP session. You app is awoken, gets the messages - ideally from the SIP message if possible - and then just doesn't start the session. SIP was designed just for creating sessions, not just VOIP. When I worked in Telecoms R&D (a long time ago) we were using it to swap between Text/Voice/Video, all using local servers.
You'll have to jump a lot of hoops to make this work, but it would be pretty awesome. I have never tried this actual use case - especially with iOS, but I'm fairly sure it will work. It is a bit of a fudge, but should get you where you need to go.
Good luck!
You can use something like PubNub to build this chat app with iOS using native Objective-C code, or with the Phonegap (Cordova) libs.
The beauty with using a real-time messaging network like PubNub is that when the app goes to the background, you can easily have the chat messages come in on APNS.
When the app is in the foreground, it can just receive them as the native (PubNub) message. And if it needs to "catch-up" with the messages it missed while in the background (but received via APNS), its trivial to implement.
Also, PubNub is platform agnostic -- so you can easily also use it on Web, Android, BB, Windows Phone, etc.
http://www.pubnub.com/blog/build-real-time-chat-10-lines-code/
http://www.pubnub.com/blog/html5-websockets-beautiful-real-time-chat-on-mobile-using-pubnubs-channel-presence/
https://github.com/pubnub/objective-c/tree/master/iOS
https://github.com/pubnub/javascript/tree/master/phonegap
geremy
I'm developping an app, that one one his tasks, is to send messages in tcp to a server. I want that the app continuos sending that tcp messages, even if the user quits the app.
I've that I could do that with:
"In your Info.plist set LSBackgroundOnly to 1."
But it don't work (I just tested on the simulator).
Thanks a lot for the help!
I'll just put Holex's comment into answer form to take care of this question. As he states, there are only 3 types of services allowed to run in the background of an application, location services, audio, and VoIP. A great read on what you can and cant do is the following http://developer.apple.com/library/ios/#DOCUMENTATION/iPhone/Conceptual/iPhoneOSProgrammingGuide/ManagingYourApplicationsFlow/ManagingYourApplicationsFlow.html from Apple. Fairly detailed article of the structure of what happens when an application loses focus.
Alternatively however, if you don't plan on releasing through the app store, it is possible to fake a VoIP application and send/receive messages in the background. This is not a legitimate solution however, and really should be used for nothing other than if you need something quick, and extremely dirty.
iOS Voip Socket will not run in background That question, and any related ones are good places to start.