UDP Socket works on Simulator not on Watch

2 out of 3 (sim is computer environment...) says it might be bug in 2.0 - I don't see anything relating to UDP in the 2.0 releases notes, so might be time to file a bug.

Did you try deleting off the device and repeating build/install?

Thanks for the reply. I'm hoping it is a bug. I've tried deleting, rebooting, re-pairing the watch, xcode, the Mac, the iphone over and over. Same result. I'm going to dive into the AsyncUdpSocket class code and trace out exactly where it is failing and then I'm either going to figure out the issue or if not at least have a simpler code example I can use in a bug report.......

Hi epinc, but are you using UDP communication with WatchOS2 ??? If yes have you tried to send message from the watch to a remote system without using the phone as "bridge"? Can you send and receive data with the watch using UDP protocol? Can you help me? I want to send and receive data (UDP message) from the watch to read and write data to a remote domotic system connected to the same wifi network but I don't know if this is possible...

Thank

That is what I am trying to test right now actually, but Beta 3 will not let me launch anything from XCode. Even if I make a simple app with nothing in it, when I try to run from XCode the only thing that happens is that the Watch puts up a spinner and just sits there forever. From reading the other posts on this forum it appears I am not the only one with this issue. I am anxiously awaiting a solution or workaround so I can try different methods of getting UDP to work without an iPhone.

I am also seeing this problem. Took hours just to figure it out because I can't run on the Watch from Xcode. I was however able to deploy an AdHoc build and have it tell me what's going on. Feels like there is a missing API to turn on the Wi-Fi radio perhaps. Or the bug is that sending via UDP does not turn on the radio is my guess. Is there a Radar for this? Works great in Simulator of course.

I tried using OS 2.0 Beta 4 and still have the same issue. I also tried using a different low level method

this still fails saying "operation not permitted"

int sock = socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP);

struct sockaddr_in sa;

char buffer[1024];

size_t fromlen, recsize;

memset(&sa, 0, sizeof(sa));

sa.sin_family = AF_INET;

sa.sin_addr.s_addr = INADDR_ANY;

sa.sin_port = htons(14510);

// bind the socket to our address

if (-1 == bind(sock,(struct sockaddr *)&sa, sizeof(struct sockaddr)))

{

perror("error bind failed");

close(sock);

exit(EXIT_FAILURE);

}

else{

NSLog(@"ok");

}

Yes, I can verify I'm still seeing this same critical bug on B4 as well. Though, I can only run AdHoc builds so debugging is a nightmare and getting it reduced to a simple bit of code like that isn't a point I've reached. I would recommend filing this in Radar ASAP since you have a code sample as this would be a huge showstopper for massive numbers of apps and I fear the few like you and me that notice this immediately will not be loud enough and this could go unfixed until too late because B4 still can't really run from Xcode so most developers probably are only using the Simulator where this works great so we have spent over a month now building code around this working.

If this is actually an intentional bug and Apple is trying to force all apps to use NSURLSession or something unworkable like that, they should say that as it would have a dramatic and obviously very negative impact on the app plans of many developers.

Apple informed me in response to a bug-report that tcp/udp communication will not be supported by watchOS2.

So yes, big show stopper..

I have converted everything to use WatchConnectivity.

Since WatchConnectivity sendMessage has been broken on real devices for many betas now though, I can only test on the Simulator (again). So everything is dependent on the next beta, which is probably a GM candidate, finally having WatchConnectivity working well. It works really well on the Simulator.