I know that I can keep a socket alive in the background for VOIP applications with kCFStreamNetworkServiceTypeVoIP. However this is deprecated on iOS 9 and they recommend to use the PushKit Framework for VOIP purposes.
My problem is that my App is suppose to work without internet connectivity so I have no way of using remote notifications. The App connects to a SIP device for VOIP calling purposes.
Any suggestions would be helpful for a future proof solution.
Thank you
By the way, when building with the iOS 10+ SDK, this feature has been removed entirely. See QA1938. Apple does mention that some applications like yours don't have access to the Internet, but then says the only way to do it is for you to open certain ports to the APNS servers, which still requires some Internet, so it doesn't really answer your question.
Some VoIP apps are specifically designed to work in special networks,
ones that don’t provide access to the wider Internet. To use PushKit
in such an environment you must configure the network to allow iOS
devices to access the Apple Push Notification Service. See TCP and UDP
ports used by Apple software products for information on how to do
this.
Related
I am developing a VoIP app using Twilio for iOS. The app should be able to receive incoming connections. For that, I have checked the VoIP and Sound capabilities so that the app keeps running and listening for ports.
To achieve this, I have initialized a TCDevice in my appDelegate and set the appDelegate to be the TCDeviceDelegate so that the system keep listening for new connections. But the app will eventually go into background, or even be terminated at some point. So what should I do at this point?
Is this the correct way for keeping the app listening even when in background? I have been reading that I need to use a setKeepAliveTimeout in my didEnterBackground method, but Apple says when using iOS8+ , we should be registering for Remote Notifications instead.
Also, I am reading the Apple documentations, and they say that sockets should be tagged properly for the system to keep these sockets alive. Does Twilio's library take care of these details?
I am very confused about the whole process. Does Twilio take care of everything? if so, how?
The Twilio SDK calls the setKeepAliveTimeout for you so you don't need to call that or worry about the sockets. All you need to do is add the two background settings to your info.plist for Playback of Audio and VOIP.
The Twilio online documentation is not that great, however if you download the iOS SDK and untar it you will find a FAQ which is NOT online that explains more. You will also find a BasicPhone Xcode project that is way more fleshed out than the Monkey project.
Also I found that unless you cough up some money then none of the calls will actually go through.
If you encounter any problems then the Twilio email support is great for the first 48 hours of each issue and then they tend to go silent. YMMV.
All of this is information I could have done with 2 months ago, hope it helps.
For a project I need many clients to subscribe to different hardware devices. In this setup the clients are iOS - Devices. The hardware is something like a raspberry pi but i don't think this matters. This hardware devices send a signal if it measures some kind of information. This is a rare event and possibly could never happen.
Purpose of the app is to warn the user when some kind of event appears in a location he is interested to.
I planed to implement this using the MQTT protocol.
That is where my problem is. To work with MQTT the app needs to send PINGREQ every few minutes even when the app is in background. Also the app needs to receive its subscriptions and handle them immediately.
This is what I planned to do:
Set the "UIBackgroundModes" key in Info.plist to "voip".
Mark the socket as voip socket to wake the app when it receives something
Set the keepAliveTimer:callback: and send the PINGREQ
.. as described here
My questions are: Will Apple allow this? My app is not an VoIP app. If no, are there any alternatives to this approach?
If Apple policies doesn't allow your to put your MQTT client App running in the background, then the solution should be to implement an additional push service.
A push service subscribes to your MQTT broker and sends push notifications to your mobile devices, so that either they have the MQTT client App running or not they will get the events.
Yes!
There is a chance that apple can reject your application when you are using VOIP(even though your app is not a VOIP Kind of application) to keep application alive!
I'm using Location services which is a proper solution to keep application alive in background mode.
Ask permissions to use location services even when the app in background mode & after getting the allow call back,set your location manager's desired accuracy to worst,distance filter to 99999(means your app will be notified if the user travels more than 99999 Meters from last location update call back)
By altering the desired Accuracy and distance filters you can save the user's battery consumption,otherwise your app will consumes lot of energy
That was one proper way which makes your application to run in background for more than 2 days continuously (Already using in our projects).
HTH! Have fun in coding :)
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
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 trying to build a hack so that I can echo incoming TCP packets to local UDP (to connect to 3rd party control surfaces that don't support TCP).
I don't care if Apple won't approve it, I only need to do this on my own iPads. I tried pretending that my app supported audio but that didn't work.
Is this posible (without jail breaking?)
I haven't actually tried this but you might be able to do it by setting the app up as a VoIP app.
From the developer documentation:
Rather than keep VoIP apps awake all the time, the system allows them to be suspended and provides facilities for monitoring their sockets for them. When incoming traffic is detected, the system wakes up the VoIP app and returns control of its sockets to it.