In our Apple MDM solution I would like to implement a rate limit, setting a limit on how many devices can interact with the server at any time.
Just like an iOS device responds with a NotNow when it is not able to service a request, I was thinking about responding with a 429 (Too Many Requests).
How would a device act upon receiving this? Would it try again a little later or would it just give up and wait for a new request?
a) You can try and see what will happen
b) Generally speaking, device behavior is unreliable (documentation doesn't specify how a device will behave in this case, so it can change from version to version)
c) Why do you have this problem at all? A device only attempts to receive a command when you send a push notification. So, instead of limiting who can get a command, just limit push notifications which you are sending.
Related
App that I am working on is offering a VPN connection, that can run even when the app is not running at all. This service is paid, but also I would like to offer a free trial limited by session length and maximum data transfered.
The problem I've encoutered, is with monitoring the data trasnfered when the app is in background or not runing at all. So far the best solution I've came up with, would be to periodically run small task that checks if the user is still within the data limit and if not, the VPN will be disconnected and notification shown to the user.
Will silent notification get priority every time it will be required? According to this quote from developer.apple.com, they are low-priority which isn't what I need, but I was unable to find anything else.
Silent notifications are not meant as a way to keep your app awake in the background, nor are they meant for high priority updates. APNs treats silent notifications as low priority and may throttle their delivery altogether if the total number becomes excessive. The actual limits are dynamic and can change based on conditions, but try not to send more than a few notifications per hour.
How can this be done reliably? Is there any other way?
If this is a personal VPN connection (i.e. you're just providing a config to the standard system) and you're not in the flow, then this isn't possible. There is intentionally no "I want my program to run all the time" solution. Even if you come up with one, Apple will probably shut you down.
If you're writing an MDM/supervised VPN connection (i.e. you're providing a ...Flow object of your own), then you're already running all the time and you can just control it as you want. I'm assuming you have the former or you wouldn't be asking.
I believe you're doing this backwards. Monitor the session length on the server, and disconnect there. When you disconnect, send a push notification, which can display a message directly without having to open the app. That is both robust and the intended solution.
Periodically posting a silent notification to wake yourself up will definitely not work because Apple specifically does not want you to do that and they explicitly break it (as they note "silent notifications are not meant as a way to keep your app awake in the background"). It's bad for battery life. This is intended to be solved on your sever, on on the user's device.
I have a service that allows user to enter the type of events they like, and whenever a new event that fits those criteria is available in my database, I want them to get a notification.
I have been looking around at the best way to handle it and I have found two possible solutions, but I'm not very clear with which one I should use and how.
First, a solution that looked great was the didReceiveRemoteNotification method and the usage of remote silent notifications to tell the app that new content was available. But my questions remains: how can I send this remote notification to the user if I don't know which criteria he has. I mean, how can I send this notification using PHP? I'm a bit lost here.
So I found another possible solution that does look a lot like a hack (iPhone - Backgrounding to poll for events), to be able to make your app execute a method every XX minutes while it is in background. This would be way more battery consuming and I'm not even sure it would be accepted by Apple, but at least it is clear as to how it works: the app downloads data from a link with the parameters that fit the special criteria, and if there is new data, it sends a notification.
How could I combine both these methods?
EDIT
I think the main issue on my side is that I don't understand how I could check a certain PHP file whenever new data is added into mysql and make sure that it fits the criteria of the user and then send the notification. That is the part that I don't understand in the backend PHP usage.
Your flow should be like this -
Mobile -> BackendServer(PHP) -> APNS server -> Notifications->Back on device.
User will submit her/his criteria to server then server will process on that and send request to APNS server.
The APNS server will send remote notification on her/his device based on criteria requested.
For a project I need many clients to subscribe to different hardware devices. In this setup the clients are iOS - Devices. The hardware is something like a raspberry pi but i don't think this matters. This hardware devices send a signal if it measures some kind of information. This is a rare event and possibly could never happen.
Purpose of the app is to warn the user when some kind of event appears in a location he is interested to.
I planed to implement this using the MQTT protocol.
That is where my problem is. To work with MQTT the app needs to send PINGREQ every few minutes even when the app is in background. Also the app needs to receive its subscriptions and handle them immediately.
This is what I planned to do:
Set the "UIBackgroundModes" key in Info.plist to "voip".
Mark the socket as voip socket to wake the app when it receives something
Set the keepAliveTimer:callback: and send the PINGREQ
.. as described here
My questions are: Will Apple allow this? My app is not an VoIP app. If no, are there any alternatives to this approach?
If Apple policies doesn't allow your to put your MQTT client App running in the background, then the solution should be to implement an additional push service.
A push service subscribes to your MQTT broker and sends push notifications to your mobile devices, so that either they have the MQTT client App running or not they will get the events.
Yes!
There is a chance that apple can reject your application when you are using VOIP(even though your app is not a VOIP Kind of application) to keep application alive!
I'm using Location services which is a proper solution to keep application alive in background mode.
Ask permissions to use location services even when the app in background mode & after getting the allow call back,set your location manager's desired accuracy to worst,distance filter to 99999(means your app will be notified if the user travels more than 99999 Meters from last location update call back)
By altering the desired Accuracy and distance filters you can save the user's battery consumption,otherwise your app will consumes lot of energy
That was one proper way which makes your application to run in background for more than 2 days continuously (Already using in our projects).
HTH! Have fun in coding :)
I understand the basic concept of having a provider talk to Apple's Push Notification Server which then pushes the notification to the phone. Usually, the provider is an app server running on some machine somewhere completely separate from the app.
However, we don't currently have a separate server, and don't yet need one as everything is currently handled in-app. So, is there any way we can use the app itself as the provider to send a notification to Apple's server and thus to another phone?
Basic concept: we have a game and when a user completes 70% of the level, we'd like to notify his competitors that he's close to finishing the game (or that he has finished at 100%).
If it's possible, are there any security concerns with this approach?
P.S. The app already knows who the competitors are because it displays them in a UITableView.
Technically it's possible. If you include the push certificate with your app, and you have a way to send the device token of each device to all other devices that may need to push to that device, you can push a notification directly from one device to another.
However, in practice, that would require opening and closing many connections to the APNS servers frequently (you'll need a connection for each device, and every time a device loses network connection - which may happen often - you'll have to re-open that connection), which will probably cause Apple to block your app from connecting to their APNS server (since they would interpret it a DDoS attack).
Therefore you should use a server.
For future visitors to this question: we wound up ditching Amazon SNS since we spent nearly 8 hours and couldn't get it working the way we wanted. Instead, we setup Parse Push in rough 15 minutes with exactly what we wanted to do, so I would definitely recommend giving it a look.
Within my iPhone application I periodically make calls to a webservice, providing the endpoint with a list of numeric IDs. The webservice then returns information relating to the IDs it receives.
This is all well and good. However, I would like to be able to provide functionality whereby the user will receive a local/push notification when these changes occur, regardless of whether the application is open or not.
I'm just looking for guidance on my options in this scenario. As I see it, there are two main approaches: calculate any data changes on my webserver and send a push notification to all devices, or query the webservice from the device itself.
The second option seems ideal, as not all devices will need each push notification, but I'm unsure as to whether this is possible with the current state of iOS' multitasking APIs. Any advice would be appreciated.
Bad news: it's not possible. Apps can only run in the background for a short period of time after the user has exited unless it fits into a small number of categories (GPS, VoIP, etc).
Web services, unfortunately, do not count. So this would have to be performed on the server side and with push notifications.