We are designing a system that based on particular events on the server creates geofences for particular device. It is expected that the client (device) will be in sync with the server data, question is how?
Initial (most optimal) idea was to send a silent push to the device to notify it about new data, and trigger data pull. Knowing that this solution will work for Android OS devices, we though the problem can be solved in similar fashion on iOS. Unfortunately, my iOS dev told me that silent push are not reliable on iOS, and presented following discussion: Silent push notifications only delivered if device is charging and/or app is foreground.
Therefore, my question is how to keep the (geofence) data on the iOS devices in sync with server side?
We can pull, say every say 5 minutes, this solution is extremely inefficient, for most of the devices new geofences are changed rarely if at all, but our ‘power users’ need to have geofences updated very often.
We could push with some kind of silent push mechanism, but it has to be reliable.
Maybe some kind of persistent connection (tcp or better udp) but that seems like battery draining solution. Besides not reliable, the server would have to keep track of changing IPs which is not even possible on many cellular networks.
WebSocket. Also battery draining solution, that is not intended for background sync. Overkill for devices that really have the data updated rarely (like once a month).
Some commercial solution (PubNub or Pusher), but we would definitely prefer in house solution.
Are there any other solutions that are used in such cases? Maybe our approach with silent push is not right, but there is other build in Apple solution for such use case?
There's a fantastic service called Simperium with an iOS SDK that can help keep your info in Sync. I heard about them because I started using SimpleNote, a free note-taking tool that uses the sync service. They were acquired by Automattic, which runs Wordpress so the whole deal should be decently stable.
Hope this helps!
You can run your syncing operations in the applicationDidEnterBackground: method within AppDelegate. That's the solution I've always used as long as the syncing operation doesn't take too long.
Here you can also query your database for data changes instead of pushing a trigger to the device, which could get hairy with push notifications and aren't really their intended use. If changes in the data are found (or some boolean flag is checked) then initiate a data pull.
I'm not sure how much data you are working with but having a REST query every 5 mins is the way I'd go. Perhaps you can even switch it to a query each time you start up the app would be good enough?
We have an app where the user data needs to be sync'd with the back end server - each time we start the app it queries the backend server to see if there are any updates. We md5hash the data from the server and then we can just check our hash against the latest data - if it doesn't "match" then we pull the new data set.
In general, iOS doesn't really allow you to do multi-tasking the way you can do on android. Now, if you aren't releasing to the app store - and only using this as an in-house app you can get a little funky with things and run in a background mode.
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 been investigating iOS background fetch for our enterprise applications. According to articles like this, there are limitations like having 30 seconds to download before the app is terminated and the may be (unconfirmed) a penalty where after 3 timeouts, an app gets banned from background sync. Also if the user kills the app, fetches stop happening -noted here.
The goal is to be able to retrieve data from our servers periodically when app is suspended/not running but sometimes the transfers can take minutes due to long running SQL. I don't want to implement sending periodic notifications to all users.
Before I go down the path of developing for the iOS background sync, I needed to do some due diligence and research alternatives to iOS's background sync and didn't find anything.
Has anyone seen or developed an alternative to iOS's background sync or dealt with this issue for their enterprise apps?
As an enterprise app there's nothing extra you can do except that you can use whatever background modes you want (audio, location, voip etc,) without needing to have a legitimate reason to do so.
Where this might assist is:
you could make use of a significant location change (as opposed to a regular location change) notification to run your app in the background. The problem with this is it of course depends on the user of your app to move around. However, assuming everybody in your workforce commutes to/from work with their iPhone then you would have two opportunities each day for the app to run in the background. A app run due to a location change can be made to execute in the background for more than 30 seconds.
voip pushes: Unlike a regular push notification, a voip push will launch the app even if the user has force terminated it. To make use of this functionality is only a tiny bit more effort than using regular push, you don't have to do anything regarding making or receiving an actual voip call, you just need the voip capability and voip certificates instead of normal push certificates.
The comment in that link is not correct regarding force quitting and background fetch - a user force quitting an app does not make it ineligible to run for a background fetch, I have force quit my own app that uses background fetch but it will still be started by the OS, however what will happen is that the frequency when the app is run will decrease lots, and if the user never runs the app again then the OS will stop launching it.
A user force quitting an app will prevent other things from happening, such as it running in the background in response to a silent push notification for example (unless its a voip push).
Also the 30 seconds in not related to download times, NSURLConnection would stop after 30 seconds, NSURLSession is designed to continue to download on your app's behalf. But if you are downloading and then applying lengthy SQL processing it would be an issue. But minutes of processing time seems excessive, are you sure its all optimized?
The goal is to be able to retrieve data from our servers periodically when app is suspended/not running
The only reliable way to achieve such a behaviour is implementing a User-facing Remote (Push) Notifications framework on backend & apps.
You can append 4kB (or 5 for VOIP) worth of data in the push JSON payload, eliminating need for a network fetch request if implemented in a handshake mechanism.
You can evaluate usage on Silent Remote Notifications to augment content updation & fetch small amounts of content opportunistically, though it has the same as Background App Refresh.
You can definitely improve the API that can take minutes due to long running SQL
And remember you need to have the app updated only when the user actually fires it up. Evaluate implementing a catchy & smooth fetching content screen that transitions into the actual screens once all data is fetched.
Im quite new to iOS programming and now want to implement a periodic background synchronization to synchronize my server data with client data. What I want to achieve is comparable with Androids SyncAdapter where you can define a time interval (for example each 30 minutes) and the system will trigger the defined task automatically in the background.
Until now I could not find such mechanism for Swift 3.0 so I need to ask if somone has experience or some hints for me how I can achieve this.
What I want to do sounds quite simple:
When the app starts for the first time the app should setup a sync manager which automatically triggers a background task every 30 minutes. The background task is responsible to synchronize server and client data (using Alamofire).
How can I do that?
There is an iOS feature called BackgroundFetch, which you can set up for
regularly downloads and processes small amounts of content from the network
You can setup a minimumBackgroundFetchInterval.
In contrast to the mentioned Android feature, this interval is not guaranteed though.
The OS does some heuristic in a blackbox. It rewards you for using a "reasonable" (to the OS) CPU time/ power consumption and also for being used often by the user. On the other hand you get punished for draining the battery or (even worse) never being used/opened by the user.
See: Apple Sample and Apple Docs
Update: Since iOS13, BackgroundFetchis deprecated.
There is a similar, new API named BGTask, BGAppRefreshTask is the equivalent to deprecated BackgroundFetch.
See Apple Docs
Alternatively, depending on your needs, you can post a Silent (push) Notification whenever the users data changes on server side. A silent push wakes up your app without notifying the user, so you can fetch data and maybe inform the user by scheduling a local notification.
See: Apple Documentation
You can't. Apple doesn't allow 3rd party apps to have regular background time like that. You'll need to come up with another approach like implementing a silent push notification from your server when new content is available.
As #ekscrypto points out in their comment, you can use Background fetch to load small amounts of data when the system decides to fetch it. However, you don't have any control over when that fetching takes place. Search on "Fetching Small Amounts of Content Opportunistically" in the Xcode help system for more information.
I am writing an app and using CloudKit. The app stores its data in the public database. I’ve created a local cache so that my app can function even if the network isn’t available. I’m using CKSubscriptions and the resulting push notifications to keep changes from the cloud in sync. All of this is working well.
Now, if a user has multiple devices and is running my app on all those devices, then I can no longer mark notifications as “read” (using CKMarkNotificationsReadOperation) since I won’t know when all the devices have processed them. This is particularly true if one of the devices is offline when a change happens. If I do mark them as read, then when the other devices check for new notifications (using CKFetchNotificationChangesOperation) they will not see them and their local cache will be out of date.
My current solution is to just leave all notifications in an “unread” state and rely on the CKServerChangeToken in CKFetchNotificationChangesOperation so that each device only grabs the notifications that have occurred since that device last checked. This works well.
But, it seems to me that since I’m not marking any notifications as “read” they will simply continue to pile up on the server. Maybe this isn’t a big deal, but they will take up space and I have no good way to get rid of them. Over time, this seems as if it could be a problem.
Has anyone used subscriptions/notifications in a similar way and come up with a different approach? Also, any feedback on my approach would be welcomed.
The server will delete the old notifications, regardless of the read status.
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.