I want to send push notification from a iOS device to another iOS device without using backend server. Is it possible for an iOS device to act like a server and send push notification to APNs server?.
Thanks in advance.
Theoretically you can send Apple Push Notifications from a device directly to another device. All you need are the push certificate of the app, the device token of the device you are sending the notification to, and code that establishes a secure TLS connection to the APNS servers.
However, there are several practical problems that make the use of a server almost mandatory :
You need a single place where all the device tokens of all the devices that installed your app will be sent to and persisted in. The best such place would be a server. Without a server, how would device A send its device token to other devices that want to send it push notifications?
Apple require that you keep connections with the APNS server open for as long as possible and use the same connection for sending many notifications. If you open a connection to APNS server on your device, it will probably be short lived (since devices switch networks frequently, and don't stay connected to the internet all the time). Therefore, if you try to send many notifications frequently, and each time use a new connection to APNS, you will probably be banned (since Apple would treat this as DDoS attack).
If you store the push certificate in each device that installs your app (to allow it to send push notifications to other devices directly), aside from the security issue of storing the certificate in many places, you'll have to publish a new version of your app each time the push certificate expires (once a year), and push notifications would stop working for users who don't upgrade to the new version.
Try NWPusher.
It has an iOS framework for sending pushes and has an iOS demo application that sends push notifications from iOS to iOS.
You also need to consider Server costs (other than maintenance and development time if you code your own server).
By sending the push directly from the app device:
- you obtain a much better scalability (since you don't have to centralize everything on your server)
- you don't have to pay for server cost or other service's cost
You can use for iOS:
- https://github.com/noodlewerk/NWPusher Pusher
And for Android:
- Send push notification GCM by java
Related
I work perfectly with Push Notifications for iOS using APNS. So for some customers, I need an on-premise or local solution, where I could send notifications to the device without APNS and without dependence on the internet. Somebody knows? can you help me?
Not possible. You cannot get notification from APNS without internet.
What you can do to accomplish this is you send message from your server to the app while it is in background mode and generate local notification accordingly.
Let me clarify your question.
"Locally" means: you got either no internet connection, a local network without connection to APNS OR the users simply did not register for push notifications.
1. iBeacon with Local Push Notification
So, here is an alternative, and that's kind of NOT what it is basically used for, but as you may know. iBeacons can be used to transport small data chunks, very very small ones. If your users did enable location services, you could include these for your application to trigger certain events (in this case, a very small notification that users came into range of a point of interest).
Downside: The application bundle requires either a static "notification text" to beacon mapping or you have to dynamically download the mapping from a web source, so you could update the notification's text.
2. Bluetooth with Local Push Notification
Another alternative would be to use bluetooth instead.
Devices could auto connect to your Bluetooth Station "Peripheral" - These devices now (with the help of your app) would register to a broadcasting characteristic of your Peripheral.
The peripheral could send messages to the registered devices.
If now the device does receive such a broadcasted message, you could perform a local push. - Without any network connection, just with the help of bluetooth, which itself also requires user permissions, of course.
3. Internet Connection / Silent Push with Local Push Notification
If your application of course had a working internet connection, you could avoid the APNS from Apple and send your own notifications to the device as silent push notifications.
As of iOS 14 this is available through Local Push Connectivity, but you will require the App Push Provider entitlement that you must apply for specifying why you are unable to use APNS.
Apple sample code is available here.
APNS works only with internet. If you need to push a message to the user without internet one solution (probably only solution currently) is using SMS api. But that requires user mobile number. Using URL Schema the user can open your app from the SMS message.
As far as I can read, it is technically possible to initiate an Apple Push Notification from an iOS App instead of via a server/service.
It would require the push notification certificate to be bundled with the app, and device tokens for the receiving devices must be exchanged.
Offhand this seems like a usable solution for some notification scenarios, but are there other limitations? Would such a setup not be accepted in an App submitted to the app store? Would exchanging device tokens pose some sort of risk? It would save the cost of a notification service and it would distribute the processing to the clients instead of the server.
What am I missing?
try NWPusher...
this is a third party but sends notification from ios to
How do iOS "push" notifications get delivered to a particular device without that device needing to poll a server?
For example, let's say I have received a new message on Facebook. Facebook notifies Apple that my device should receive a notification as such. But how does Apple know which device/IP to push the message to?
Each device can be updated with data using their own unique device tokens. This picture explains everything . .
It was too much for me to put in a comment so.
From the documentation.
Apple Push Notification service (APNs) propagates push notifications to devices having applications registered to receive those notifications. Each device establishes an accredited and encrypted IP connection with the service and receives notifications over this persistent connection. Providers connect with APNs through a persistent and secure channel while monitoring incoming data intended for their client applications. When new data for an application arrives, the provider prepares and sends a notification through the channel to APNs, which pushes the notification to the target device..
I suggest reading the documentation for more information and how to use and configure. It's all there.
Push Notifications
I created an infographic to explain the workflow of push notifications. Hope this is helpful.
Device does not keep polling the server for the push notifications.
To keep it simple, consider an iPhone is connected to internet. On connecting to internet iPhone establishes connection to Apple Push Notifications server this connection is open connection which means data can be thrown to iPhone from server the moment data arrives to server.
Apple does not use HTTP protocol for Push notifications but if you understand HTTP Protocol its almost a similar methodology.
http://en.wikipedia.org/wiki/Push_technology#HTTP_server_push
There is a really nice exaplanation of push notifications in this article.
In iOS, apps can’t do a lot in the background. Apps are only allowed to do limited set of activities so battery life is conserved.
But what if something interesting happens and you wish to let the user know about this, even if they’re not currently using your app?
We are trying to send a notification to ~500,000 iOS devices. We have currently set the batch size to 200 and are noticing that Apple refuses our connection after 300k messages or so. We suspect that Apple interprets our connection/tear-downs to be a DOS attack. What is a good batch size for us to use? Also, any tips on sending notifications for such a large number of devices?
Your push notification server must maintain a persistent connection to Apple's socket stream push server without disconnecting too often.
I recommend writing your push server using Node.js, it was designed for this stuff.
However there are a few things that can also cause Apple to disconnect your push server.
With Push Notification, there are two types of certificates - development and production.
An app signed with a development certificate will generate a development push token whereas a an app signed with a production certificate will generate a different production push token even on the same device.
Your server must make sure it does not send a development token to a production socket stream connection to Apple's push server.
Mixing the token and environment will cause Apple's push server to disconnect your push server.
How you separate your push token is something that you need to build into your server.
Hope that helps.
I implemented push notification in my app.
It is working fine.
Now the problem is even after i deleted my app from device it is getting the push notifications.
So is there any way to unregister the app from push notification when it is deleted from the device.
Hoping for your help.
Thanks in advance.
In Apple push notification there is something called - Feedback Service. So when a user deletes an app, the service provider should ideally stop sending notifications to that device. But Apple does not notify the service that "this device is not using your app, dont send notifications". So instead you need to poll for this info.
Every day you might need to hit Apple Notification servers asking it to give you device Ids who have deleted your app. Once you get them you mark them in your DB as deleted thereby not sending any more notifications. Hope this is what you wanted.
From Apple Documentation -
... Apple Push Notification Service includes a feedback
service that APNs continually updates with a per-application list of
devices for which there were failed-delivery attempts. The devices are
identified by device tokens encoded in binary format. Providers should
periodically query the feedback service to get the list of device
tokens for their applications, each of which is identified by its
topic. Then, after verifying that the application hasn’t recently been
re-registered on the identified devices, a provider should stop
sending notifications to these devices.
Access to the feedback service takes place through a binary interface
similar to that used for sending push notifications. You access the
production feedback service via feedback.push.apple.com, port 2196;
you access the sandbox feedback service via
feedback.sandbox.push.apple.com, port 2196. As with the binary
interface for push notifications, you must use TLS (or SSL) to
establish a secured communications channel. The SSL certificate
required for these connections is the same one that is provisioned for
sending notifications. To establish a trusted provider identity, you
should present this certificate to APNs at connection time using
peer-to-peer authentication.
Be sure to checkout - Issues with Feedback Service
Having not seen this answer so far, there is a small note in the Apple "Troubleshooting Push Notifications" document.
In short, if you delete the last push enabled app, the persistent connection from the device to Apples push server is broken before the server is told that the app has been deleted.
Solution: keep at least one push enabled app on your device.
There is the explanation from the document:
Issues with Using the Feedback Service
If you remove your app from your device or computer and then send a push notification to it, you would expect to have the device token rejected, and the invalidated device token should appear on the feedback service. However, if this was the last push-enabled app on the device or computer, it will not show up in the feedback service. This is because deleting the last app tears down the persistent connection to the push service before the notice of the deletion can be sent.
You can work around this by leaving at least one push-enabled app on the device or computer in order to keep the persistent connection up. To keep the persistent connection to the production environment up, just install any free push-enabled app from the App Store and you should then be able to delete your app and see it appear in the feedback service.
Recall that each push environment has its own persistent connection. So to keep the persistent connection to the sandbox environment up, install another development push-enabled app."