We added silent notifications which require PushKit and enabling VoIP in the Info.plist
See Apple's PushKit Doc
Now my app is rejected by Apple:
Your app declares support for VoIP in the UIBackgroundModes key in your Info.plist, but does not include any Voice over IP services.
Please revise your app to either add VoIP features or remove the "voip" setting from the UIBackgroundModes key.
The app is NOT a VoIP therefore it doesn't require VoIP features.
Removing the VoIP from UIBackgroundModes causes the silent notifications to stop working.
Anyone know what I should do?
What VoIP feature can I add (even if I dont use it, just to pass the review)?
I asked Apple but they got back with an auto generated response with the same rejection reason.
You should likely be using iOS Service Extensions to decrypt the message.
https://developer.apple.com/reference/usernotifications/unnotificationserviceextension
You use this extension to modify the notification’s content or download content related to the extension. For example, you could use the extension to decrypt an encrypted data block or to download images associated with the notification.
You can also learn more about how this works at this WWDC talk.
https://developer.apple.com/videos/play/wwdc2016/707/
Implementing VoIP features to do this is complete overkill.
Update on the resolution -
We installed a third party VoIP solution and implemented VoIP calls in our app. Awkward to be forced to add a feature but in our case it was right for our app.
In iTunesConnect submission page, under "App Review Information" "Notes" I had to state that we added a new feature VoIP calls, with steps to test VoIP calls.
This caught the reviewers attention to the new VoIP call feature and the app passed.
When I added the new feature under "whats new in this version", the app continued to get rejected.
We have also faced same issue -
You can't use voip background mode unless you implement voip
features.
Just implement IM(chat) feature in your app then you will be capable to publish your
app at Appstore.
Good luck!
Related
This is a long shot, but are there any public (or private) APIs that allow us to read existing push notifications on an iOS device? For example, can an app running in the background poll the system every X seconds to determine if the device has received a push notification from the Stack Exchange app and get its contents?
The thought here is there are some services (such as the Ring Video Doorbell) that do not yet have public REST APIs. But when there is motion detected on the Ring camera, it sends a push notification. Similar to the popular IFTTT service, this app would poll for that notification on the device and then do something based on criteria set by the user.
I imagine there has to at least be a private API since Apple shows the device's recent notifications in the Notification Center.
Even if it was possible to use an unsupported API that violated app security, the contents of the push notification are encrypted and you may not be able to read the contents.
However, Apple's Developer site has information on relaying and interacting with other app's push notifications over bluetooth for a bluetooth ANCS.
"The purpose of the Apple Notification Center Service (ANCS) is to
give Bluetooth accessories (that connect to iOS devices through a
Bluetooth low-energy link) a simple and convenient way to access many
kinds of notifications that are generated on iOS devices."
https://developer.apple.com/library/content/documentation/CoreBluetooth/Reference/AppleNotificationCenterServiceSpecification/Introduction/Introduction.html#//apple_ref/doc/uid/TP40013460-CH2-SW1
This may not be applicable to you, but it is Apple's approved method for interacting with, and relaying push notifications from other apps to bluetooth devices.
No, that's not possible. It seems that it will be a privacy issue if other apps will read other apps push notifications content.
Apple would never give such API private/Public, this will violate apps security.You can only read your apps push notifications.
if you use private API , there is good chance that your app will be rejected when you submit to app store.
some possible solutions to your app.
1) Figure out is there any way your app gets that push notification.
2) Or you have to use Inter-App Communication.
I interpret this question to be asking specifically in the lens of a IFTTT device that could already read/write data to a "standard" IFTTT app, and you're wondering how that's done. To me, that's the question, and not asking about a hacky private API push notification system.
With that in mind, the solution is generally referred to as HomeKit from what I know. It's one of Apple's "Kits", with general docs found here
What I think you're looking to do is more along the lines of database observation, where you're maybe looking to build some aggregator app of this data set stored on the device (which Apple has a standard method of asking users for permissions, and is fully allowed on the system just like Camera/Health/Photo permissions, etc).
Observing HomeKit database changes is found at a developer doc linked from the first, but found here
I haven't used this before myself, but from the docs, I can see there are methods for observation using regular old iOS KVO:
[[NSNotificationCenter defaultCenter] addObserver:self selector:#selector(updateHomes:) name:#"UpdateHomesNotification" object:nil];
[[NSNotificationCenter defaultCenter] addObserver:self selector:#selector(updatePrimaryHome:) name:#"UpdatePrimaryHomeNotification" object:nil];
There's a lot more info there, and I'm sure StackOverflow itself (and old WWDC videos of course) have lots of info on HomeKit.
I hope this was the intended interpretation the question-asker meant.
Similarly, though, each of the supported channels for events (HealthKit, MapKit, etc) can send you "push notification" type updates about what your user is doing with built-in APIs.
If you're attempting to simply read from other application's push payloads, then the other answers are correct and that is not possible on a pure privacy basis that Apple sandboxes your application: Apple Sandbox Docs Link
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.
Recently, Apple has introduced "WatchKit Services Certificate" to its development portal. From the description below, it appears to allow users to leverage push notifications to update Watch Complications directly. But, the CLKComplicationDataSource protocol contains no information how how to implement this. Does anyone have any further information on this?
From Apple's Developer site:
"Establish connectivity between your notification server, the Apple Push Notification service sandbox, and production environment to update ClockKit complication data. When utilizing HTTP/2, the same certificate can be used to deliver app notifications, update ClockKit complication data, and alert background VoIP apps of incoming activity. A separate certificate is required for each app you distribute."
No one knows on the Apple forums:
https://forums.developer.apple.com/thread/19594
CLKComplicationDataSource Protocol Reference
https://developer.apple.com/library/watchos/documentation/ClockKit/Reference/CLKComplicationDataSource_protocol/
More documentation, but no implementing details:
http://images.apple.com/certificateauthority/pdf/Apple_WWDR_CPS_v1.13.pdf
Thanks for any help you can provide!
Checkout the WWDC 2015 video called Introducing Watch Connectivity. Take a look at about minute 50. This describes how you go about registering your complication for push notifications using PushKit. It doesn't go into detail about using a WatchKit Services Certificate, so I would try to use the normal iOS Push Notification certificate to actually send the notifications first, and if that doesn't work try sending the same message using the WatchKit Services Certificate instead.
We just add VOiP capability to our app (messaging app), now we will use VOiP (PushKit Framework).
Can anyone tell me if we can use only that notifications (VOIP notifications)? Meaning even for text message for example (not for a call)? I talk about Apple Appstore Guides, they can reject the app or block the notifications if they found that we use that notification to notify the user about other things then a VOIP call?
The answer is yes, i used the VOiP notification for a no-voip notifications (like a text message) and Apple accept the app (and i can can confirm, after some tests, that whatsapp use the same thing as my app).
You need to implement VOIP functionality in order to not to be rejected. I've tried to use it for messages between users and it was not approved. So if you really don't have VOIP functionality, modify your server to your needs.
I have also implemented VOIP push notification in our app. But app is rejected by app store by saying
"We continue to find that your app declares support for VoIP in the UIBackgroundModes key in your Info.plist, but it does not include any Voice over IP services.
Please revise your app to either add VoIP features or remove the "voip" setting from the UIBackgroundModes key.
We recognize that VoIP can provide "keep alive" functionality that is useful for many app features. However, using VoIP in this manner is not the intended purpose of VoIP.".
I need to use this API to perform a remote-wipe operation for my app:
Apps that use push notifications to notify the user that new content is available can fetch the content in the background. To support this mode, include the UIBackgroundModes key with the remote-notification value in your app’s Info.plist file. You must also implement the application:didReceiveRemoteNotification:fetchCompletionHandler: method in your app delegate.
However, I saw some posts in a forum that this may require your app to be a Newsstand app. That said, I couldn't find anything on Apple.com saying that the above API is only for use by Newsstand - indeed, the docs appear to imply this is a general API. Needless to say, my app is not a newsstand app and so want to confirm this officially.
Can anyone confirm this one way or another? If there is a Newsstand requirement, do you have a link to an Apple.com resource that says that?
Thanks!
I found very good explanation at ios-silent-push-notifications link!
Difference between normal push and silent push is as follows:
Normal Push:(Payload contains)
aps {
content-available: 1
alert: {...}
}
Silent Push(Payload contains)
aps
{
content-available: 1
}