Bug 44326 - WKWatchConnectivityRefreshBackgroundTask is not being triggered
Summary: WKWatchConnectivityRefreshBackgroundTask is not being triggered
Alias: None
Product: iOS
Classification: Xamarin
Component: Xamarin.iOS.dll ()
Version: XI 9.99 (iOS 10 previews)
Hardware: Macintosh Mac OS
: --- normal
Target Milestone: Untriaged
Assignee: Bugzilla
Depends on:
Reported: 2016-09-14 20:08 UTC by ulrike_axen
Modified: 2016-11-07 13:23 UTC (History)
3 users (show)

Is this bug a regression?: ---
Last known good build:

Test app that prints console statement if HandleBackgroundTasks is called (287.81 KB, application/zip)
2016-09-14 20:08 UTC, ulrike_axen

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.

Please create a new report on Developer Community or GitHub with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:

Description ulrike_axen 2016-09-14 20:08:32 UTC
Created attachment 17487 [details]
Test app that prints console statement if HandleBackgroundTasks is called

According to Apple's documentation, a WKWatchConnectivityRefreshBackgroundTask should be delivered when the watch app is backgrounded, and iPhone app sends a WCSession UpdateApplicationContext. I tried this in my very simple test app, in the simulator, with the watch app on the Dock and not in the foreground. As far as I can see (from my Console WriteLine statements), I am not receiving the background task. I will upload my very simple app, slightly modified to try to get background tasks.

Maybe I am missing a fundamental piece?

My current set-up:
=== Xamarin Studio Enterprise ===

Version 6.1 (build 5441)
Installation UUID: 0ca42116-8f54-4ad6-bd25-aa90f20c571f
	Mono 4.6.0 (mono-4.6.0-branch/746756c) (64-bit)
	GTK+ 2.24.23 (Raleigh theme)

	Package version: 406000245

=== NuGet ===


=== Xamarin.Profiler ===

Location: /Applications/Xamarin Profiler.app/Contents/MacOS/Xamarin Profiler

=== Apple Developer Tools ===

Xcode 8.0 (11246)
Build 8A218a

=== Xamarin.iOS ===

Version: (Xamarin Enterprise)
Hash: 6c3fee4
Branch: xcode8
Build date: 2016-09-09 13:01:32-0400

=== Xamarin.Android ===

Version: (Xamarin Enterprise)
Android SDK: /Users/axenu/Library/Developer/Xamarin/android-sdk-mac_x86
	Supported Android versions:
		2.3    (API level 10)
		4.0.3  (API level 15)
		4.3    (API level 18)
		4.4    (API level 19)
		4.4.87 (API level 20)
		5.0    (API level 21)
		5.1    (API level 22)
		6.0    (API level 23)

SDK Tools Version: 25.1.1
SDK Platform Tools Version: 23.1
SDK Build Tools Version: 23.0.3

Java SDK: /usr
java version "1.8.0_74"
Java(TM) SE Runtime Environment (build 1.8.0_74-b02)
Java HotSpot(TM) 64-Bit Server VM (build 25.74-b02, mixed mode)

Android Designer EPL code available here:

=== Xamarin Android Player ===

Not Installed

=== Xamarin.Mac ===

Version: (Xamarin Enterprise)

=== Build Information ===

Release ID: 601005441
Git revision: 68292d1ab289911c815ddc715dd7cc29a9752f9f
Build date: 2016-09-09 04:43:23-04
Xamarin addins: ed25d008672663eeb9db55f1ccecb3c24d2fd3b2
Build lane: monodevelop-lion-cycle8

=== Operating System ===

Mac OS X 10.11.6
Darwin ulrikes-mbp-2.ms.starkey.com 15.6.0 Darwin Kernel Version 15.6.0
    Mon Aug 29 20:21:34 PDT 2016
    root:xnu-3248.60.11~1/RELEASE_X86_64 x86_64
Comment 1 Rolf Bjarne Kvinge [MSFT] 2016-09-15 05:44:28 UTC
(In reply to ulrike_axen from comment #0)

> I tried this in my very simple test app, in the simulator

I believe this doesn't work in the simulator, you have to try it on device.

A quick google shows the same thing happens in Xcode: https://forums.developer.apple.com/thread/52088 (comment at Aug 23, 2016 5:52 PM from JimmyCricket)

Can you try on device and see if that works for you?
Comment 2 ulrike_axen 2016-09-15 12:39:22 UTC
Yeah, I started on the device, finally moved to the simulator. It doesn't work on either.
Comment 3 ulrike_axen 2016-09-15 12:40:40 UTC
@Rolf: yeah I saw that forum post too. Since there was no response at all from Apple, wasn't sure where the problem was.
Comment 4 ulrike_axen 2016-09-15 12:49:04 UTC
@Rolf: One other thing, from something I read somewhere or a video (I did a lot of reading yesterday...) I think it _is_ supposed to work in the simulator (once it actually works). The reason being, you have a limited budget for background updates on the actual device, so they recommend testing it in the simulator where that limit doesn't exist.

It's weird that Apple has the feature in their documentation and talked about it at WWDC, but it's completely broken? At any rate, I guess I'll start monitoring that Radar too, thanks.
Comment 5 ulrike_axen 2016-10-13 16:27:23 UTC
An observation (an Apple bug?). I was able to get background updates to work. The problem was that in my iPhone app, I was checking if WCSession is "reachable" -- which is supposed to indicate that the watch app is active and available. In that case I was sending a message instead of "UpdateApplicationContext". Problem was, "session.Reachable" was _always_ returning true, even when the watch app was backgrounded, so I was never sending UpdateApplicationContext even in the background, so the WatchConnectivity background task associated with UpdateApplicationContext was never getting called.
Once I disabled the logic around "session.Reachable", and always use UpdateApplicationContext, it worked. I'm not sure if there is an Apple bug, or Apple documentation bug around this.
Comment 6 Rolf Bjarne Kvinge [MSFT] 2016-11-07 13:23:32 UTC
Thanks for letting us know!

I'm closing this then.