I host a PWA website and I am trying to integrate push notifications to my users who may have the website open in a browser tab even if their phones are inactive. You notoriously can't send Push notifications to iPhones without using Apple Push Notifications service (APNs).
Seeing as the point of firebase cloud messaging (FCM) is to outsource the message handlers, I kinda assumed it would support sending push notifications to iPhones somehow via APNs, but the information here suggests you still can't do this from the web.
https://firebase.google.com/docs/cloud-messaging/js/client
Safari and iPhones don't support Push API.
According to this answer: https://stackoverflow.com/a/64576541/2116253
Option #2 may be possible if you know the device ID token, which is apparently very hard to get and perhaps not possible anymore because Apple are trying to make it harder to obtain due to security concerns.
I think the actual sending via APNs from server side is quite easy, the problem comes with the initial setup/registration and actually granting permissions that allow notifications to arrive.
So, in short, I don't mind registering my website with Apple, agreeing to terms and obtaining keys for the purpose of interfacing with APNs, but I don't want to make and distribute a whole native iOS app just to send notifications to devices about my website.
Does anybody know the correct way to achieve this in 2022 ?
Related
I've been researching different options for implementing messaging, specifically sending a message from the server to the client code, in React Native apps. I have found two main options: push notifications and in-app messages.
Push notifications can be implemented with services, such as Firebase and OneSignal, and work well except there is a claim that they are not very reliable and sometimes messages can get lost. The advantage of push notifications is that they work regardless of whether the app is in the foreground or background.
In-app messages can be implemented with event-bus services, such as SignalR (Azure or standalone), AWS SNS or GraphQL subscriptions. These services are pretty reliable, but this approach only works when the app is in the foreground.
However, there appears to be another option which doesn't seem to be as popular as the first two. This option involves running a native background service/process on the mobile device which participates in in-app message exchange similar to the normal in-app messaging. The background service would subscribe to SignalR or SNS or GraphQL and display a local notification on the device when it receives a message.
What are the problems with the last approach and why not prefer it over the hybrid approach (push notifications when app is in background but in-app messages when app is in foreground) which seems to be more commonly used?
Thanks!
The main limit is that mobile devices do not allow applications to keep a long-lived connection open in the background. This limit became more strongly enforced in Android 8 (Oreo) (documented here https://developer.android.com/about/versions/oreo/background#services), and this has always been true on iOS. Exceptions are made for certain VoIP applications, but generally, this rule applies to all apps.
One of the key reasons is battery life. Keeping a connection open takes a small amount of energy and if a user had dozens of apps like this, then it would be a noticeable issue. As a result, both Google and Apple have standardized around having a single connection open to the device that all notifications are delivered through.
For what it's worth, iOS notifications are actually very reliable and consistent. Android is more problematic due to modifications made by various OEMs. (documented here: https://dontkillmyapp.com/)
One workaround is that you could distribute an application outside of the Google Play Store that bypassed this limitation by requesting special permissions, however, it would still be affected by the OEM issues just like FCM is and likely worse.
I am coding a vue.js app using web pushes with Firebase Cloud Messaging and I wondered if it was possible to send a web push to a user and in case the user was offline, to somehow store it for later display when the user opens the app again. Is there a principled approach to this problem, i.e. managing web pushes when the end user is offline?
The reason I am asking this is that, so far, all the web push notifications I've committed to FCM server with tokens of offline clients (i.e. desktop browsers) went into oblivion. To be sure, FCM didn't try pushing the notification again when the clients went back online.
For this reason I am considering coding a self-made dispatcher to manage web push for offline clients, but I need to make sure my efforts are worth it.
updated: I am now able to display notifications sent to an offline client after coming back online using appropriate time_to_live values. However, only the latest notification is displayed. How is there any specific reason why?
FCM's default behavior is exactly like that. From the docs:
If the device is not connected to FCM, the message is stored until a connection is established (again respecting the collapse key rules). When a connection is established, FCM delivers all pending messages to the device.
I'm planning to add push notifications to my web app.
As far as I understand it, to push notifications to my users, I can either use a web push library and deliver the notifications directly, or use a push notification service such as OneSignal, Firebase Cloud Messaging, or Batch.com.
From what I understand, these services offer a one-stop solution to deliver notifications not only as Web Push, but also to iOS and Android apps.
If I'm focusing only on Web Push for now, is there any advantage I should be aware of, to use one of these services over a web push library directly?
Web Push is a standard which is still under development and subject to change. Also browser support is quite limited at the moment (see https://caniuse.com/#feat=push-api).
The advantage is: you have one API to rule all the supporting platforms (including desktop).
Disadvantage is: You have to be aware that not all platforms support the standard.
Using a notification SaaS solution to handle notifications enables you to handle all platforms. Sending out a notification from your backend will be a single call to your notification SaaS service, but you still have to be aware, when you want to have native notifications on Android, iOS and the browser, you will have to handle the integration of those platforms differently in your client apps (see example here using Google Cloud Message integration in an Android App: https://firebase.google.com/docs/cloud-messaging/android/client).
So your decision should be based on which platforms you have to support.
- If you get away with supporting Chrome, Firefox and Edge browsers on non-iOS-Devices (or handle iOS Notifications differently), you can use Web Push.
- Otherwise i would choose a Notification SaaS Solution.
The most important point for me personally when doing your own implementation is that you control everything. This means that your notifications don't fail when AWS loses a region or pricing changes and you can't afford it any more. Not any provider can ban you because of the content you distribute or the complaints from users. You can implement your own logic for showing the notifications on the front-end, like stacking them or having your own segmentation rules (paying users versus free tier, for instance). I'm not even speaking of the custom subscription UI. No weird copyright in your messages.
From what I understand, these services offer a one-stop solution to deliver notifications not only as Web Push, but also to iOS and Android apps.
When you've got the server logic to process the app events and send notifications in place, it shouldn't be really hard to extent it do work with mobile push notifications. The only thing that changes is the way you subscribe devices.
And the last, but not the least - it's fun to develop. This is more of a personal matter, I guess, but I like learning new thing :)
Hope that helps you to make a decision.
you can implement push notification to your website without using third-party libraries. You have required to get subscription token from the client and store this subscription token onto the server (Inside database). After when you want to send a push notification to the user then you have to just call endpoint (endpoint is mentioned in subscription token). That's it.
Due to security risk and managing subscription tokens, developers prefer to use firebase, AWS push notification or onesignal.com services. These services are optional you don't need at all.
Read links introduction to push notification and also the same lab code examples. Later I will update with simple working code for further reference to your question.
It depends on what you want. It‘s not possible to use iOS Safari for Web-Push. For notifications to iOS you have to use a service or build your own app.
I use Pushover for notifying myself from Scripts and Software. That may or may not be a solution depending on how much users you have, how many notifications you send and how willing your users are to use a web app like Pushover (or an app on iOS).
A service will keep notifications going when things change. So it should be less maintenance for you.
If you want to target iOS visitors also, this is not possible, as web push notifications are not supported by iOS.
To circumvent this, you need to use a third party service like Wise Notifications.
The alternative is to build an iOS app and send native push notifications.
I am building mobile apps for iOS and Android using PhoneGap Build. I would like to send push notifications to both types of device using the same server-side process. Is this possible?
Apple's certification process to enable push notifications is painful, much more so than anything available for Android. Do I have to use it?
GCM (Google Cloud Messaging) says it supports both operating systems, but the more I read about it - with respect to Phonegap - the less I see iOS mentioned! And sadly the GCM/Phonegap plugin doesn't support subscribing to a topic, which is a way of sending one message out to all devices in one go via a 'global' topic.
UrbanAirship and PushWhoosh seem to integrate with Phonegap, but I am forced to use their website to create my messages. GCM looks more attractive in this respect, because I can get our own ASP.NET server to talk to GCM via HTTP and thus control messages from our databases.
Main question: Are there any options for a single server-side option which can send push notifications to both iOS and Android via a single Phonegap plugin? (Ideally I would control messages from my own server, where one message can go to all Android/iOS devices in one go, and avoid as many Apple certificates as possible.~)
The idea of using the push notifications is only to have a notification mechanism that will send a notification when there is a new message waiting to download from the backend service: all the notifications are of the same type e.g. "refresh messages from the server" (the same for Android and iOS).
Are there any limits for the Apple/Google push notifications services?
Assuming that my application will handle more that 100k active users (or even 1M or more users) - would there be any problem with the Apple Push Notifications or GCM services?
If using the push notifications for such a service is not a good idea then what is other solution that could be used for mobile chat applications?
Don't forget that on iOS user may forbid sending notifications, so your app won't receive any even in foreground. Thus, you need to implement your own push mechanism.
Need for push notifications
Especially on iOS you don't have a choice but to use their push notifications service APNS. There is no other way to receive notifications immediately because iOS may kill or neglect the TCP connections of your background app.
On Android it seems possible to use your own background TCP connection to avoid having to use push notifications. But you may still consider the use of the push notifications through GCM for the sake of improved battery usage.
Pricing
Neither APNS (iOS) nor GCM (Android) charge you for the service and you are allowed to send an unlimited number of messages.
Limitations and Requirements
Both services will delete message, when there are too many messages accumulated in the queue for an offline device - which makes sense because there is no point in delivering those messages hours later. You have to take that in to account, when writing your app (just do a poll when going back online).
Depending on the app you are writing, there may also be privacy concerns. Even if you encrypt the message itself, at least Apple/Google know when a notification is sent to a certain device, which may be a deal-breaker for certain high-security applications.
You will also need a server that is able to communicate to both APNS and GCM. There are open source solutions for that (e.g. easyApns for iOS and python-gcm for Android), but how easy their integration is depends on your server and the language it is written in.