I have been looking at the "find my iPhone" app and it seems like it is using iCloud and no push notification to receive a alertView about a notification. By having some mechanism in the background running and alerting the user once it receives a notification.
What I am wondering is that is this app a special exception Apple made for this app, and all other apps have to do push notification? Or can I make an app that runs in the background just like the "find my iPhone" app and communicate via iCloud.
Thank you in advance.
Apple uses iCloud for Find My iPhone, yes, but I believe their reason for this is tying it to your iCloud account so that if your phone is stolen, you can log in your account at icloud.com to attempt to track it. The Find My iPhone app itself works by pinging the GPS location, saving that location, and syncing it with iCloud. For general developer use however, there's no direct API for communicating via iCloud, nor is it likely there will be. iCloud's main purpose is synchronization and backup, and since Apple already has the Push Notification service in place it wouldn't make sense at this point to put that in iCloud. What functionality are you wanting that Apple's Push doesn't allow?
When your app is in the foreground you have the capability of receiving data from an external source a number of different ways. However when your app is terminated either by the user or the system memory watchdog, Push Notifications are the only real route. So at this stage, integrating the APNS is your best solution. There's a few great services that make APNS integration relatively painless, such as Urban Airship.
Related
I have an application which has communication with a remote server. The server should push data into it using remote notification silently, and I need to get and store these data into a CoreData database. The user won't be aware of the whole process.
I can successfully get notified when the app receives a remote notification, while it is either in the foreground or background mode. However, I need to get data while the app is terminated as well.
I searched for the possible solutions. For example, this SO question was good if I don't tend to use silent notification. I also saw the PushKit capability, but I am not sure about the Apple Review result.
What is the possible solution?
If I want to use VoIP and PushKit to get notified when the app is terminated, would Apple reject my application?
If you’re not creating a VoIP app and you want your app to be in the App Store then the correct answer is: it is not possible. The only thing that can be done is adjusting your requirements in some way.
For instance you can send some notifications that will be visible for user in the Notification Center and wait until the user taps the notification or starts the app the usual way. Then the app will be able to do all the operations you need.
The delivery of push notifications is not guaranteed, so you should not rely on them to synchronise data.
For example, if multiple push notifications are sent while the device is offline, only the last notification is delivered when the device comes back online; the earlier notifications are lost.
When your app launches one of the first things it should do is check with your server for new data.
Since push notifications may not be delivered sometimes (you can lose a few of them), you can not run code after the iPhone is turned on to check if there is new information available from the server, and you can not run code if your iOS App is closed... What can you do if you want to be as more accurate as possible in for example a Chat App in iOS?
I mean, inform the user as faster as possible that he has new info available. Comparisons: WhatsApp is updated without any delay.
You can do background fetch if your App is in background. But if the App is closed and you miss a push, it's not going to be up to date until the next push arrives or user opens the App. The same with silent notifications. If the app is terminated by the user, you are not going to receive it. Is there any way to solve it? It must be because other Apps do it... If there is any "private and secret" API that they are using (I read about this answer when no one know how to do that)... Is there any way to apply to use it?
UPDATE:
I'm using push notifications. The goal is to fix when a push doesn't arrive. Example: User A send chat message to user B. User B doesn't have the App open. The system lose the push. User B is not going to receive the message until he open the App.
Push notifications seems to be your only way even if you do loose a few of them, which I don't know how you would since they are pushed to apples secure server... but what do I know. As long as the user turns on the push notifications you should be fine. They may be delayed due to apples way of handling them. Honestly push seems to be the future, having your app constantly every minute or two check for new messages is a huge battery water in conjunction with normal texting apps. Your app should provide the best live data but since apple restricts to push notifications when the app is off or not running just stick to push notifications and only push major events to the user. I believe you can set up a job scheduler using quartz or schedulator to setup your server to push notifications to your app.
I want to sync my local DB with server when Push notification came, but I am not able to do it with Silent Notification because application:didReceiveRemoteNotification:fetchCompletionHandler not called when app killed by user. So, I did not know how to do it, then I read about push kit but don't know is it possible to use push kit without VoiP feature. Please tell me is it possible or not??
If not, suggest me any other idea , how will I run background task when app killed by user??
In my experience as well as others on SO - you get rejected for trying to leverage VOIP as a workaround. See below for actual response from apple dealing with a similar attempt.
2.16: Multitasking apps may only use background services for their intended purposes: VoIP, audio playback, location, task completion, local notifications, etc.
2.16 We found that your app uses a background mode but does not include functionality that requires that mode to run persistently. This behavior is not in compliance with the App Store Review Guidelines.
We noticed your app declares support for VoIP in the UIBackgroundModes key in your Info.plist but does not provide any Voice over IP services.
We recognize that VoIP can provide "keep alive" functionality that many app features would like to use. However, using VoIP in this manner is not the intended purpose of VoIP, which, as indicated in the iOS Application Programming Guide, is that: "A Voice over Internet Protocol (VoIP) application allows the user to make phone calls using an Internet connection instead of the device's cellular service."
Seems that the only way to restart the app when it was killed by user is to use PushKit.
It is possible to use PK framework in your app without Voip functionality, but I can't guarantee you, that your app will not be banned while posting to AppStore.
I have an iOS app with a Rails backend (and frontend). I am using Parse for push notifications.
I am trying to figure out the best way to only send push notifications that will be received; that is, I want to avoid sending them to:
Users who only use the web app and don't have the iOS app
Users who had the iOS app but then uninstalled it
The way that the Parse Push API works is that I can broadcast a notification on a certain channel, and any device that is listening to that channel will receive the notifications. Therefore, I am planning to make separate channels for each user.
Obviously, I am going to need to store some sort of information on the server side about who is running the iOS app. I'm curious as to whether anyone out there has experience solving a problem like this and can offer any wisdom. Thanks!
Parse already stores information about who is running iOS and Android apps. Check out the Data Browser, there is an Installation table with a deviceType field.
Have the iOS app register a unique (per-user) channel. If you're only sending push notifications on user channels, it will only be sent to users who have installed the iOS app.
There's not much you can do for users who had the iOS app but uninstalled it. Apple doesn't provide a way for applications to run any code before being uninstalled, so you can't unregister the device with Parse. I'm not sure if Parse does this, but Urban Airship polls the APNS servers and removes devices that have had the app uninstalled after a certain amount of days.
Quick question, I am working on an APNS enabled app and I just want to know if there is a way that when the app is not open (not in background) and the app receives a remote notification;
Can I open the app in the background, unbeknownst to the the user, and do do what needs to be done.
I have looked at the docs but it doesnt explicitly say that this can or cannot be done (from what I read), it says that the user has to open the app manually (either from tapping an alert or the app icon).
I think it is clear what I'm looking to do however i'll put an example aswell.
Example)
The default Mail app alerts the user of new emails with a badge icon, showing the number of new emails, aswell as a sound. The user must then tap the app icon to open the app and download the new emails.
I want to be able to have the badge and sound but open the app in the background (silently) and download the new emails, so that when the user does get around to opening the app the emails will already be there, ready to read.
Thanks for any help.
unfortunately, what you describe is not possible.
the only way you could get something like that is to build a voip app. see the relevant section in this document.
Implementing a VoIP Application
A Voice over Internet Protocol (VoIP) application allows the user to make phone calls using an Internet connection instead of the device’s cellular service. Such an application needs to maintain a persistent network connection to its associated service so that it can receive incoming calls and other relevant data. Rather than keep VoIP applications 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 application and returns control of its sockets to it.
anyway, I doubt that your app would get into the App Store, then...