application:handleEventsForBackgroundURLSession:completionHandler: doesn't run when the uploads are finished in the background. When all the upload/download tasks are completed in the background then iOS should wake up the app and call the above method. But it doesn't.
I have tested this by terminating the app from 'xcode stop' button and also terminated from an exception.
I have followed Background Transfer consideration.
I have tested this on Apple developer guide: Background example and it is not working.
I have also tested this on AppCoda: Background example and it is not working
Both of the examples which are given in 2 and 3 points are not working on iOS 9.0 and xCode 7.0. Before upgrading to iOS9.0, I had tested this on iOS7.0 and xcode 5.0 where it ran perfectly.
I am assuming that it would work on the real device.
What am I missing here? Can anybody confirm whether handleEventsForBackgroundURLSession works in iOS9.0 simulator or am I doing anything wrong? Since it doesn't work for the examples given in 2 and 3 so I guess maybe I am testing it wrong.
#ZayinKrige answered this in a comment:
background download events don't fire on a simulator. You can only test this on a real device
And to expand a bit, here's a guide for testing background session code:
https://forums.developer.apple.com/message/42353#42353
In my case, the cause of this was that I was using uploadTask(withStreamedRequest:...), which is not compatible with background URL sessions. I switched to use uploadTask(with:request, fromFile:...) instead and everything started working.
Related
i'm trying to get the new BackgroundTask framework to work in my app. I'm testing on a real device running iOS 13.4.
Everything works as expected (minimal setup, like is described here: https://developer.apple.com/documentation/backgroundtasks/bgtaskscheduler )
Unfortunately the task gets only called if the app is still in the background. If applicationWillTerminate() is called (e.g. when the user closes the app from the multitasking manager), the task will not get executed.
I have not found anything on this topic in the docs. Also i think this behaviour was different with the now deprecated Background Modes (see also: iOS - Background Services when app is terminated )
Can anyone clarify/confirm/correct on this?
Thanks in advance!
I tried to use the iOS 13 background tasks, with the Apple Example:
https://developer.apple.com/documentation/backgroundtasks/refreshing_and_maintaining_your_app_using_background_tasks
But the application works perfectly fine if i use in debug mode(Using the below apple commands provided)
https://developer.apple.com/documentation/backgroundtasks/starting_and_terminating_tasks_during_development
On a release mode(with out console commands) not even once triggered the background tasks, i tried
Connecting the application to Xcode with breakpoints.
Giving a local notification when background tasks trigger.
Using Userdefaults to keep count of number of Event Triggers.
None of them gave me an answer, Tried for whole day.
So wanted to understand, if any one has used iOS 13 background tasks, could please help me guide what im missing.
Thanks.
I have a new problem I never met before.
I didn't change my app code since Friday, and I have different behavior.
When my app execute a sendMessage, it doesn't works immediately. The message is sent only when the app come back in front.
I use a lot of sendMessage and it worked perfectly since I started my app, several weeks ago.
For information, I just updated my Watch to Watch OS 2.2 this weekend.
Note I have this problem only with my watch, it works fine on the simulator.
I just finished first apple watch connectivity app following this tutorial:
I received the message from sendMessage() immediately. I hope it helps.
It seems really abnormal behavior very, I developed several apps with message passing, never encounter your own abnormal. It is not that you are sending very large messages or've set some particular condition?
There are previous topics about waking up an application from the background with BLE advertisement (e.g. How to wake up iOS app with bluetooth signal (BLE), Android / iOS - BLE - wake up a terminated application when a BLE device connects).
However my question is not about that since we had this feature working fine up to iOS 9.2 included.
Coming iOS 9.3 the feature doesn't work as it used to work before, it seems that the terminated by user swiping off the application is not woken up. Nothing changed on the BLE advertisement originator.
After a recheck of various parameters and reading of Apple documentation, nothing springs to our minds. Neither Apple documentation mention any change, unless we missed something.
Have other people notice this issue? Are you aware of a solution?
We wrote to Apple and we are pending on an answer but maybe somebody here has the correct tip.
Many thanks in advance for the attention.
UPDATE: After more testing, it seems that only when the user swipes the application out the wake up doesn't work like it used to in iOS 9.2
Initial testing were more manual and gave us the impression that there was an underlying issue. However not sure why this change took place without any notification from Apple. - Above text was amended based on the update -
UPDATE 2: This issue is not present anymore in iOS 10.
It turns out after a reply from Apple that this is a (new) intended behaviour.
didEnterRegion/didExitRegion events stopped working from the background after update to 9.3
I have an app that has been working almost perfectly for the last 6 months, and after the update these events are no longer getting called. I started this app over last year when I heard about iOS9 coming out, and when I couldn't get the old one working, I started a new one using Swift instead.
After some time and a LOT of driving in and out of my Region, I got the app to work more reliably than it ever had before. I have several devices using the app, and when all of them updated to iOS9.3/9.3.1, the app stopped calling didEnterRegion/didExitRegion events completely.
I have a ticket open with Apple, but I am getting a lot of push back about the service, and that 9.3 didn't change background location at all.
My devices use AT&T of Verizon, we have tried wi-fi assist on and off, I even wiped a system, formatted the HD, installed El Capitan, and XCode 7.3, and it's hasn't helped.
I also found an issue with the Devices Tool, and when you download the Container, and open package, the Documents folder is empty. I'm not getting a warm fuzzy feeling for Apple right now, and I am sure someone is feeling my MEGA MIND WEDGIE at this moment.
Help....
I'm writing a WatchKit app which needs to make a query to our Parse server. Because this is a network call, I follow the following procedure:
I make a call from WatchKit to the iOS app using openParentApplication:reply:
Inside of handleWatchKitExtensionRequest:userInfo:reply:, I start a background task with a UIBackgroundTaskIdentifier to ensure the iOS app isn't terminated immediately
I set up my PFQuery and call findObjectsInBackgroundWithBlock:
In the block I pass to the PFQuery, I reply the relevant information to the watch
I wrote this app maybe a month ago before the Apple Watch was out, and it ran just fine in the Watch simulator. Yesterday I received my Apple Watch and I was able to get the app running on the watch, but it doesn't quite work - I managed to figure out that when the iOS app is actively running in the foreground on the iPhone, then everything is great; but if the app is not active (e.g. backgrounded or terminated), then findObjectsInBackgroundWithBlock: never actually calls the block, and execution seems to just stop.
Does anyone have any ideas of what might be going on? My initial thought was that the iOS app is getting suspended/killed before it can complete the query, but I was pretty sure the background task would prevent that.
PS. If anyone stumbles upon this question because they were looking for how to get a WatchKit app running on an actual watch, I found this post extremely helpful in getting it working.
Turned out that I had several problems related to openParentApplication:reply:, and they all seem to have been resolved by using the technique from this post:
http://www.fiveminutewatchkit.com/blog/2015/3/11/one-weird-trick-to-fix-openparentapplicationreply
I had started a background task for my own app, but I didn't use the "bogus workaround" background task described in this post, because it wasn't necessary for me in the simulator. On the watch, though, it apparently was.