I want to do a little bit geofence advertising but I want people to receive my notifications regardless of weather they have my app or not.
so just with their location on, they are gonna be able to receive the advertising.
is this even possible? if yes, can anyone tell me how?
Not possible.
You cannot get user-location unless user installs your app which has permission to access to user-location.
You cannot send push notifications, unless user installs your app which has permission to receive push notification.
Related
Is it possible to query for push authorisations by sending a silent push and have that reported back to my server?
I'm assuming silent push does not require push permissions.
Kind of, yes. If you send a silent push notification and your app has not been forced killed, then it could send back an update back to some of your servers saying that it got the notification.
Nevertheless, if the user manually quits the app, then those notifications are thrown away by the operating system, so you are not able to tell.
Also, you could simply call isRegisteredForRemoteNotifications on your application to check if the device is registered or not.
Update
To be more clearly: It doesn't matter if anything is turned on or off, you can never ever rely on the delivery of a message. The operating system may just delay the delivery, or skip it at all, and you'll never know. At least, not on the server side. Your app truely can check (once it is running again)
what kind of notifications it received (it just has to do some bookkeeping), and then ask the server if everything it has is also everything the server send sometime - but this logic has to be implemented by you.
Silent push notifications don't require push notifications permissions, but they can still be disabled by turning off "background app refresh":
Is Silent Remote Notifications possible if user has disabled push for the app?
Doing background networking requests of any kind while another app is running is a battery intensive thing to do. Many sites tell users to disable background app refresh for apps that use a lot of power. Using this feature unnecessarily could draw attention to your app and have your users disable this permission:
https://www.businessinsider.com/how-to-make-iphone-last-longer-battery-life-tip-2019-7?r=US&IR=T#:~:text=Turn%20off%20Background%20App%20Refresh.&text=That%20way%20the%20next%20time,%22%20and%20select%20%22Off.%22
You could simply check for push notification permissions on the launch of your app and record it there instead. Using silent push notifications to track the users settings is quite an odd thing to do. With everyone interested in what apps are tracking these days, and apple going out of their way to inform users of whats being tracked, doing this might get your app some bad press if it's discovered. I wouldn't install an app doing something like this, as I would be thinking "what else are they going to track while my app is off"
My problem is: I just can't make silent notifications work when a user has force-quit(swiped away) the app!
I guess the following is a fact: A silent push (with content-available:1) will NOT trigger application(_:didReceiveRemoteNotification:fetchCompletionHandler:) nor any other method (it will NOT launch the app) if the application was force-quit (swiped away) by the user! Can anyone prove this wrong?
I have made sure I've enabled Background Mode: Remote Notifications.
But what if non-silent notifications don't work for me? I need silent ones, I need to be able to run some checks before I show it! What If I want to check if the right user is logged on to my application after I receive a notification from remote server? (since I can't guarantee that when he logged out he successfully let the server know about it, so I assume the server doesn't know for sure)
What would be the right approach to take in my situation?
There are many questions about similar things, but not many people involved, I wonder why? I don't believe that I have such a rare case. Maybe my basic approach to solving this kind of problem is wrong? It doesn't seem to be a problem on Android platform at all!
I am using FCM as central point of sending out notifications, so if you say that PushKit can solve my problems, too bad that FCM doesn't support VoIP certificates. But, I wonder, can PushKit really solve this? Or Apple just designed it this way that when a user force-quit an app, it means that this app must shut up altogether with its ability to push remote notifications?!
I don't consider this a duplicate of Firebase silent notification does not start up a closed iOS app because what I am asking here is what would be the solution if you want to check if the user to whom the notification is addressed for corresponds to the user logged in to the application? It can be considered duplicate if it turns out that there is absolutely no solution for this on iOS platform.
You ask:
Or [has] Apple just designed it this way that when a user force-quit an app, it means that this app must shut up altogether with its ability to push remote notifications?
Yes, this is how it is designed. App Programming Guide for iOS: Understanding When Your App Gets Launched into the Background says:
In most cases, the system does not relaunch apps after they are force quit by the user. One exception is location apps, which in iOS 8 and later are relaunched after being force quit by the user. In other cases, though, the user must launch the app explicitly or reboot the device before the app can be launched automatically into the background by the system. When password protection is enabled on the device, the system does not launch an app in the background before the user first unlocks the device.
Is not possible. when the app is in background or suspended modes, you will have 30 sec to do some stuff. But if user kill app manually func didReceiveRemoteNotification will never called.
Upd:
When an iOS device receives a silent notification, the system wakes your app in the background and calls the application(_:didReceiveRemoteNotification:fetchCompletionHandler:) method of its app delegate. Your app has 30 seconds of wall-clock time to perform any tasks and call the provided completion handler. For more information, see Handling Notifications and Notification-Related Actions.
In my settings tabbar:
I have a feature specific switch which can be turned OFF or ON based on API response.
From website only admin is authorized to turn ON/OFF.
I can make /user API call everytime on settings tap to check the current settings for the user but there are couple of disadvantage like if user is already on setting then it will not update the UI and calling api everytime on settings tap doesn't sounds a perfect solution.
I think better solution is to send a silent push notification which i can use to make the API call to update the settings UI whenever needed.
But if user has disabled the push notification will I still receive silent push ? What is the recommended approach to handle such situations ?
Short answer, yes
The exciting new opportunity for app developers in iOS 8 is that Apple will now deliver “silent” pushes even if the user has opted out of notifications. Also, “silent push” is no longer just for Newsstand apps. Every app can take advantage of this ability to refresh content in the background, creating the most up-to-date, responsive experience possible, the moment the user opens the app.
Although...
Users still have the ability to switch off your app’s ability to process a “silent push” by means of the “Background App Refresh” control. Even though Apple Push Notification service (APNs) will deliver a push marked “content-available” to your phone, the OS will not wake up your app to receive it, effectively dropping it on the floor. However, opting out of “Background App Refresh” is a lesser-known capability not directly associated with Notifications. You don’t access this preference in your Notifications Settings--it’s located under General > Background App Refresh screen.
Keep this in mind when building your application.
Source:
https://www.urbanairship.com/blog/watch-list-ios-8-opt-in-changes
This matrix might help. At left hand side, it shows if "didReceiveRemoteNotification: " method will get called or not. Other two columns is related to setting app. Settings -> YourApp. If yourApp supports Notifications and background app refresh. Look into matrix to check when you app will receive silent push.
Other answers are good. But they are not official answers.
The official answer is in What's New in Notifications WWDC 2015 video:
Silent notifications are enabled by default. The user does not need to
approve your -- does not give permission to your app to use them, and
you can just start using them without asking the user for permission.
But silent notifications are the mechanism behind background app
refresh. At any point you know that the user can go in settings and
disable them. So you can't depend on them always being available. You
don't know if the user the turn them off, and you are not getting a
notification anymore. This also means that silent notifications are
delivered with the best effort. That means that when the notification
arrives on the user's device, the system is going to make some
choices.
For more see this image and this answer
User has an iOS app in his device and he walks into a physical store. I would like to identify that user programmatically within the app and throw him push notifications like Welcome message and based on his usage history or his level, send him coupons etc., on entering the store. He has to receive these messages automatically. In what all ways this is possible? And most important thing is that this needs to work in all states of the app (foreground, background, not running, suspended). Appreciate any quick inputs here.
Since you tagged your question with iBeacon, here's a summary of what's possible with that technology. In general, you can do what you want, but there are some caveats.
If you install an iBeacon in the store and make the app look for that iBeacon using [locationManager startMonitoringForRegion: iBeaconRegion], your app will get a callback whenever that beacon is first seen. In this callback, you can make it send a local notification to the user (or by making a web service call, you can make it send a push notification to the user). This can happen in all of the app states you mention, using this definition of these app states.
The situations where this will not work is if:
The phone is turned off
Bluetooth is turned off
The app has never been launched since installation
The user has stopped the app from the task manager and has not restarted it since then
The user has denied the app permission to access your location
The callback to your app will happen as soon as the iBeacon is detected by the phone. This may be as far as 150 feet from the iBeacon if it is detected quickly. It is also possible that detection will be delayed by a few minutes until iOS enters its next Bluetooth LE scan cycle. Once the callback takes place, local notifications can take place immediately. Push notifications will probably have a delay of several minutes more.
The message you send to the user will show up on the lock screen, and if the user gestures to it, you can launch a specific part of the app.
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.