So, I am trying to use the oppertunity when my Watchkit complication calls requestUpdateDidBegin() to use sendMessage() to wake my iOS app and cause it to calculate complication data and use transferCurrentComplicationUserInfo() to update the complication. I call sendMessage() from the extension delegate. I am experiencing mixed luck with this actually reaching the iOS app. Even with my iPhone next to the watch the performance varies. One time I built my app to my phone and it successfully delivered over 30 updates to my complication through sendMessage() and transferCurrentComplicationUserInfo(), over the course of two days. I then uninstalled the app from the watch using the watch app, and then reinstalled it from the watch app (So absolutly no code or build changes) and it stopped working! I suspect there is clearly some bugs and unreliability with calling sendMessage(). Is anyone else finding this, is there any workarounds? How can I wake my iPhone app from when the complication controller calls requestUpdateDidBegin()?
I don't believe there is any guarantee you can wake the iPhone from the watch. If you need to update with data from the phone, you are better to schedule the updates on the iPhone app and then push the updated data from the phone. You'll probably need to enable a background mode on the iPhone app for this to work (location services, background data transfer, depending on your data type.)
(As posted here https://forums.developer.apple.com/thread/26934)
Related
I'm building a Flutter app and need to call a function every day (to schedule some notifications). I came across the flutter_background_fetch package, which seems to be a perfect solution for Android, since the main limitation of the minimum 15 minute interval is not a problem.
However, I am supremely confused about how well the package works for iOS. According to the README, "When your app is terminated, iOS no longer fires events". However, I've also seen posts on Stackoverflow that claim that iOS Background App Refresh periodically relaunches your app to run background fetches (and posts that say it is unreliable or doesn't work at all).
So does flutter_background_fetch work on iOS when the app is terminated (eg. double tap home and swipe up)?
Edit: Also exploring flutter_workmanager, which seems promising.
There is no perfect Dart solution for iOS to schedule background task as android when app terminate, in android we can use Alarm Manager
But you can try native side implementation with BGTaskScheduler
https://github.com/fluttercommunity/flutter_workmanager
I need to notify the user about new features of my app as soon as the app update finishes and the app is not in the foreground (i.e., it is terminated or is in the background). How do I achieve this? This scenario will happen if the app was already installed and auto-updates were on.
I achieved this on Android using MY_PACKAGE_REPLACED broadcast receiver. I've read about NSNotificationName in NSNotificationCenter in iOS but couldn't find an equivalent to MY_PACKAGE_REPLACED.
You cannot do this with iOS without the app running in the background Period. Even if your app is running in the background after Appstore updates the app, your app gets killed and you don't have control over it until the user launches it for the first time.
Maybe you could try sending a silent push notification to the app to see if it responds and try to get the current app version.
I have a Timer which plays AVAudio at a specific time while the screen is locked (app in foreground when locked and plist setting 'Application does not run in background' set to YES).
When I run my code while my iPhone is connected to Xcode it works as desired, playing audio while locked even when the iPhone has been locked for hours.
Now if I disconnect my iPhone and just open the app by tapping the icon the audio won't be played if it's set for more than a minute.
Is there a difference that causes this problem? If I would publish my App to the AppStore which behaviour would my users get?
That 'Application does not run in background' flag is a very old flag that means your app does not support multitasking and should be terminated when the user presses the home button. There's no good reason I can think of to set that flag on a newly developed application. Unless you understand exactly what it's for and are positive that setting it to yes is the correct thing to do, don't do that.
(That flag was added when iOS 4 was released, to allow apps that could not handle multi-tasking to request the old terminate-on-home-button behavior from iOS 3. Given that we're now 6 major iOS releases from iOS 4, it seems outdated.)
So remove that flag. It probably doesn't have any impact on your question, but remove it or set it to no in any case.
If you want to run a timer while the phone is locked and play sounds at designated times then you will probably need to set your app up as a background sound player, and ask for more background time when you get a message that you are going to the background.
That being said it's likely that Apple will reject your app. Running a timer from the background means that the processor on the phone has to run at full speed all the time, which will DRAMATICALLY reduce battery life.
Apple only allows a very small subset of apps to run in the background, and then only under specific circumstances (like a background sound playing app when the user is actively listening to music, or a navigation app that is actively tracking the user's location and notifying them when it's time to make a turn to follow directions.)
Should be no different. If you'd like to feel what do your users' feel then you can publish it to TestFlight which is the best app beta test environment. Find some testers or try it yourself.
The directions should be to verify the playing logic and the sound file relationship which link to the connection.
I'm developing a medical alert and record keeping app for iOS for a client. The app needs to be able to open itself at specific times based on a schedule that is set remotely.
I've searched around for how this can be done, and I keep running into other apps that let you schedule app launch times, but this needs to be a self contained solution.
I'd rather not JailBreak the iOS device to make it work, and I've come across articles that say iOS 9+ now has this capacity, but no instructions on how to make it come about.
Any clues, tutorials, or other information on how to accomplish this?
You can use "silent" push notifications (with "content-available") on iOS 7+ to launch the app when the push notification is received on the device. You will get a chance to process the notification, and the app will be launched if it's not already running.
However, it still won't work if the user has force killed the app.
Also, iOS will not launch your app if it feels you've gone over the daily processing time or data quota.
I'm trying to get data from url with background fetch. My func tries to get data and if there is a new data, it sends local notification. Background fetch works after about 10 - 20 minutes when i minimize the app. But when i kill the app (double click home button and close app) it doesn't work. I waited about 1 hour but it didn't work. I am using background service in android and it is working successfully. Is there any way to get data from url and send local notification when app is closed? I am using Xcode 6 and swift 1.2
The Background Fetching will NOT happen in your app after the user has killed it in the multitasking UI. This is by design.
Take a look at Apple's documentation that mentions:
Apps that support background execution may be relaunched by the system
to handle incoming events. If an app is terminated for any reason
other than the user force quitting it, the system launches the app...
and
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.
As you noticed in the documentation, there's only 1 exception when the app will be relaunched if it was force killed: by using location services. Unfortunately this does not apply to you.
Also, you cannot detect if the app was force killed by the user. Check this StackOverflow answer.
The Background Fetching will NOT Update in your app after the user has killed app from background. it is not Possible