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?
Related
I've got a project I'm working on which uses VOIP notifications to "wake up" apps that have been put into background/terminated. These notifications are sent periodically, and everything seemed to work fine until recent iOS updates.
It appears that after a certain amount of time in which the app has been in the background (happens to some users after 5 minutes, others after 20), the devices no longer process any code after receiving the voip notifications.
I've read a bit in apple dev forums and some other devs are running into similar issues, all speculate if its related to the new iOS updates (10.3.1/10.3.2).
Has anyone else run into this issue, and if so, have you been able to solve it?
Thanks!
This is the new normal on latest iOS versions.
You should begin to use push notifications.
Here is a guide from Apple.
What ended up seeming to be the fix was updating to a newer version of socketio library.
You can try debugging your app in background or in kill state ( terminated state ), so you can get to know that payload from pushkit comes or not or possibly some crash at iOS code end.
Debug pushkit notification in terminated state
Put debug pointer on delegate methods
Go to edit scheme
Select run option then Launch -> Wait for executable to be launched
Send push kit payload from back end
Once you get payload on device
it will automatically invoke and debug pointer will invoke at delegate methods.
Refer
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....
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.
I have an application, it uses APNS, so I have code that subscribes to notifications, and everything works fine. But every time I reinstall app, and run it with xcode, I get allow push notification dialog. Every time.
I found hundreds questions about how to achieve this dialog again, but none - how to stop achieving them. I need help!
It's seems known IOS9 bug, here is a link for developer forum and still no response from apple and no solution:
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.