I have been searching everywhere and struggling to find a clear answer. I would like to know if when in background mode, or when the phone is locked, a pebble watch app can communicate with the iPhone to send events.
An example of what I am using it for (in its most basic form) is a stopwatch that runs on your phone and watch. The user can start, stop etc from the pebble watch and the iPhone will send user events to a server...
Any help would be much appreciated.
The Watchface <-> Phone app documentation clearly states that:
Only one iOS application can be connected to the watch at a given time;
Only the iOS application can (re-)open the channel to the watch app.
So your watchface app will be able to send messages to the app, as long as:
Your iOS application is the last 3rd party app that used the channel to the watch
Your iOS application was not killed in the background (for example, you declared a background mode to make sure you would stay online)
Finally, note that the SDK provides you with a callback when the message are not delivered so your watchface app would know if the app was killed and would be able to display a specific message to the user.
This is my understanding of the documentation but I have not been able to try that yet.
Related
I want my iOS Swift app to run in the background. The things I want to run in the background are:
Timer - that pings server periodically and retrieves data from it and then its displayed on the tableView.
Audio - If a certain condition is encountered in the retrieved data, I play a local audio clip from the app via the avf framework.
The app is working as expected. I have done the following to allow backgrounding:
It does work in the background. However, is there any additional thing that I need to do? such that the app doesn't get rejected from the Apple App store.
“Timer That pings the server periodically” - that will make Apple hate you. And if Apple allowed it on the App Store, users whose battery you are emptying will hate you.
Read up on push notifications. No pinging, no energy use at all. Doesn’t even use WiFi or mobile data - your phone service provider sends you the push at a level below mobile data.
Update:
Ok i will explain again i want to know if the phone contacts changed not my data
is there a way to know if contacts were changed without looping all contacts while the app were close
Notification.name.CNContactStoreDidChange work only after app is lunched
Note:
android version is broudcastreceiver notify you for that change even if your app is killed
The short answer is no. In iOS, apps do not support operations that happen when your app is inactive. Thus it is impossible for something like a contact changing to be registered in your app when it is in this inactive state.
The only way that your app can receive data is for example if it comes from an external source (i.e. an online notification) or if you have a time-specific notification that is pre-set when your app is running.
In order to check for something like this you would have to manually search through the contacts upon app startup.
You can see these answers for more details: Broadcast receiver / service in Android vs. iPhone and Can iOS receive broadcasts like Android?
Now for those who don't know, can go to https://web.whatsapp.com/ and sync your Whatsapp chats by exchanging a QR code and chat via the web extension of the app.
I am not interested in how they have an initial handshake( might be communicating with whatsapp servers) nor how they sync data so fast for chatting (might be using Open sockets directly from device to client).
I am curious as to how the app works in Background on iOS . AFAIK running a background Intent Service is pretty simple. But not for iOS. iOS allows only up to 30 seconds after the app is shut down normally.
1) I tried crashing the App(swipe up) (Still the web version was running normally)
2) I disabled Background App refresh the web version didn't stop.
3) Even disable Notifications still the web version worked normally.
4) As well they do not have a Blue bar the likes when Google Maps is giving you directions that indicates the app is running in BG
5) Are they using Dummy Geo Fencing to keep them alive? (but that d require BG App Refresh too)
Is it some new feature on iOS 8 that was introduced and I am not aware of
Just as a side note, Apple introduced the Notification Service extension point in iOS 10, which can be used to achieve this. The following applies only to iOS 9.x or earlier.
No app in iOS can be long alive in background with a keep-alive socket, or
guaranteed to wake by remote notifications except those using VoIP background mode (OT: and IIRC Bluetooth background modes).
An app has only ~5 seconds of runtime on applicationDidEnterBackground: after being put in background, unless it is registered for any background modes or tasks. The app would be terminated if it runs out of time in this delegate method.
The background task model mentioned by #xoail has a app-specific, system-imposed time limit (up to 30 seconds...?) and cannot be extended. It is for an app to complete its current work, e.g. uploading a media, before being suspended. Background Transfer Service, since iOS 7.0, is an alternative for long running file transfer.
Silent Remote Notificaiton is observed to be triggered consistently only on charger and Wi-Fi, but always throttled by iOS otherwise. So it is sort of indeterministic - let alone the fact that this can be switched off by flipping the app's Background App Refresh switch.
VoIP background mode (in iOS 8 and later) guarantees to call the app's handler when a VoIP notification is received from APNs. But App Review Guidelines states clearly that background modes should only be used for their intended purpose.
So either Apple waives WhatsApp the use of VoIP background mode for purpose other than WhatsApp Call, or WhatsApp happens to get away from the "use your phone to sync" architecture and does something new for the iPhones.
As per the docs the app can remain in the background performing finite updates to the App. You can continue extending the background process one after the other. Look into Perform finite-length tasks. I think killing the app from background still executes registered actions by the system.
Whatsapp does some clever web session token + background app token generation to keep session valid.
As mentioned in #32112433 by Steven Darbey this is most likely implemented using the new iOS 8 PushKit Service which includes a VoIP service notification type, allowing applications to resume from background. A misuse of the API for non-VoIP purposes, but Apple apparently putting a blind eye on it.
https://developer.apple.com/library/prerelease/ios/documentation/Performance/Conceptual/EnergyGuide-iOS/OptimizeVoIP.html
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 am creating a private distribution app and I am wondering if it is possible, using any methods or private API's, to open my app when a bluetooth connection has been made.
What I have discovered so far is that with iOS 7 and the ability to use iBeacons you can enter into bluetooth proximity and you can have your app send a notification to allow the user to then open the app.
What I am hoping to do then is have the app running in the background and listen for an iBeacon connection and, if one has been made, actually launch the app without the users control instead of just sending a notification.
I realize this would never be allowed publically, however is there anything private I can look at to achieve this without jailbreaking? I know to launch some apps you can do [[UIApplication sharedApplication] openURL:[NSURL URLWithString:url]]; however I want my app to listen for an iBeacon and then open itself up.
Is there any way or work around to achieve this?
Moving app from background to foreground without user interaction is pain in the ass. Sorry, don't have a solution, just want to share some information:
I asked the same question here and posted a bounty on it and got no good response:
Show some UI from background in audio player or VOIP app on iOS
At some moment I found a solution with the help of another person. It was based on usage of GSEvent (sending clicks to UI). You can look following questions. However, as I know, in iOS 7 these API became protected by entitlement. So, this method is dead (most likely).
Using GraphicsServices.h/GSEvent as well as compiling CLI iPhone tools with Xcode
Use GSEvent to send touch event,but it's invalid.
Simulating System Wide Touch Events on iOS
iPhone, how to fire a button event in programmatically
Apps can use region monitoring to be notified when the user crosses geographic boundaries or when the user enters or exits the vicinity of a beacon. While a beacon is in range of the user’s device, apps can also monitor for the relative distance to the beacon.
In iOS, regions associated with your app are tracked at all times, including when your app is not running. If a region boundary is crossed while an app is not running, that app is relaunched into the background to handle the event. Similarly, if the app is suspended when the event occurs, it is woken up and given a short amount of time (around 10 seconds) to handle the event. When necessary, an app can request more background execution time.
For detailed info:
https://developer.apple.com/library/ios/documentation/UserExperience/Conceptual/LocationAwarenessPG/RegionMonitoring/RegionMonitoring.html#//apple_ref/doc/uid/TP40009497-CH9-SW1
There are two scenarios: you either want users to be able to do something with your device other then use your app, or you want them to always be locked into your app.
In the former case you should trust user. Just show the push, timer or location notification and let them decide to launch the app or not.
In the latter case just lock the device using guided access mode.