eskimo

Am I doing something wrong here or should this be reported as a bug?You should file a bug about this. Even if this were a problem with your code—which I don't think it is—you shouldn't hear about it via a crash in the release build (-:Please post your bug number, just for the record.Share and Enjoy — Quinn The Eskimo! Apple Developer Relations, Developer Technical Support, Core OS/Hardware let myEmail = eskimo + 1 + @apple.com

Thanks Eskimo!Just filed a bug: 21896079

If the watch is nearby the paired iPhone, but the iPhone has WIFI off and so is using 3G/4G ... Will the Watch connects to a 'known Wi-Fi' network by itself, or will it use the 3G/4G connection on the iPhone?I was curious about this myself so I asked NSURLSession engineering about it. The current situation is that, if the iPhone is available, the Watch will always ask it to do the transfer.The usual caveats apply here: this is an implementation detail that may change in the future.Share and Enjoy — Quinn The Eskimo! Apple Developer Relations, Developer Technical Support, Core OS/Hardware let myEmail = eskimo + 1 + @apple.com

Thanks Eskimo for the clarification. However I need to know if my suggested workflow is the best for maximum security purpose. Could you please answer my two points in the first post? Thanks again.

What OS versions have you tried this on?Do you have iCloud Keychain turned on?Testing on the device or the simulator?Ultimately the -removeCredential:xxx call results in a call to SecItemDelete. You could set a symbolic breakpoint on that to see a) whether it's called, and b) whether the parameters look reasonable.Share and Enjoy — Quinn The Eskimo! Apple Developer Relations, Developer Technical Support, Core OS/Hardware let myEmail = eskimo + 1 + @apple.com

Can you reproduce this on the current iOS 9 beta?Share and Enjoy — Quinn The Eskimo! Apple Developer Relations, Developer Technical Support, Core OS/Hardware let myEmail = eskimo + 1 + @apple.com

(Which is what led me down the path of entitlements, etc.)Indeed. However, it's not possible for third-party apps to get the entitlement described in that log message, so that's a complete red herring.There seems to be a problem with CWWiFiClient where it requires that the app have a specific entitlement (com.apple.wifi.events) even though entitlements are only meaningful in Mac App Store (and hence sandboxed) apps.This has been noticed by another developer, who filed a bug about it. Alas, that bug seems to have been misinterpreted, so I've filed my own bug about it. That bug hasn't yet come back to me, so I presume that it still applies.As to workarounds, your best option is to use the CWXxxDidChangeNotification notifications. While these are formally deprecated, they do still work and they're your only way forward until the above-mentioned bug is fixed.Share and Enjoy — Quinn The Eskimo! Apple Developer Relations, Developer Technical Support, Core OS/Hardware let myEmail = eskimo + 1 + @ap

Here is some pseudo code that describes the use case where we need NSURLConnection.sendSynchronousRequest:I think you need to work on your example here. The problem is that you're adding serialisation here where you don't need it, and that undermines your argument because you're saying that synchronous requests are cool because they let me do things really inefficiently )-:Consider the two account case:fetch account Afetch products A1 through Anfetch account Bfetch products B1 through BmWhy does step 3 have to wait for step 2 to finish? By itself that's not a huge problem, but the fact that it puts all of step 4, which presumably represents a lot of work, behind step 2 is likely to be a problem.The issue here is latency. By taking a synchronous approach you're introducing unnecessary serialisation which means that the network latency is unnecessarily delaying the overall task.A better approach to this would be:send request for account Awhen you get account A, send request for product A1 and account Bwhen you

Can you elaborate on your comment However, watchOS 2.0 will sync the keychain between those two devices, so you can still use a shared credential in the keychain. Are you refering to iCloud keychain, SharedWebCredential or something else?I don't know what underlying mechanism is used.Share and Enjoy — Quinn The Eskimo! Apple Developer Relations, Developer Technical Support, Core OS/Hardware let myEmail = eskimo + 1 + @apple.com

Indeed. Sorry about the bum steer. Try sending it a SIGABRT from Terminal. $ killall -ABRT TextEditShare and Enjoy — Quinn The Eskimo! Apple Developer Relations, Developer Technical Support, Core OS/Hardware let myEmail = eskimo + 1 + @apple.com

Hi eskimo,Still does not work properly!I changed the language on iPhone (7.1.2) from English to Portuguese and continue to give en!Help.JFontes

Mr. Quinn (The Eskimo!),Thanks for your rapid response! I truly appreciated it. However, your solution still does not help me.For my use case, I don't care whatsoever about speed. Speed is completely irrelevant in this case. What I need is a syncronous solution because I have network calls that depend on the results of previous network calls. This can go 3 layers deep in my case. Knowing that, do you have any other ideas?

You're right that this is a challenge. It's one I've dealt with myself but, alas, I have not had time to publish my code as sample code.Task state info can't be maintained by the URLSession object because it is created anew when the app delegate receives 'handleEventsForBackgroundURLSession'.Nor can I store state in the Session Task as an associated object because the Task is also new in the sense that when notified the Task has completed, it is not the same object the app created.While the task object is re-created, much of the data in that object is the same as in the previous object. The data items of interest include:the URL itself (via task.originalRequest.URL)the task identifier (via task.taskIdentifier)You can use these to match the task object to your persistent private state.Another much-less-obvious option is to store a custom property on the request via +[NSURLProtocol setProperty:forKey:inRequest:]. I used this to associate a UUID with the task, and I used that UUID as the key to match against my

I changed the language on iPhone (7.1.2) from English to Portuguese and continue to give en!What continues to give en? The last post I made describes two mechanisms, so I need know which one you're actually testing.Share and Enjoy — Quinn The Eskimo! Apple Developer Relations, Developer Technical Support, Core OS/Hardware let myEmail = eskimo + 1 + @apple.com

For my use case, I don't care whatsoever about speed. Speed is completely irrelevant in this case.Interesting. How many requests are you making in total? Do you have some inside knowledge that these requests are going to be done on a low-latency network?Having spent much of my career working at the wrong end of a high-latency network, I'm very aware of how bad latency issues can be. For example, MPW's source code control system, Projector, was built on top of a network file system, and thus behaved abysmally over a high-latency link. You could be waiting until the end of time to check out a project. Things were much better when we switched to CVS.Knowing that, do you have any other ideas?I'm happy to come back to this later but I'd really like to nail down the performance issue first.Share and Enjoy — Quinn The Eskimo! Apple Developer Relations, Developer Technical Support, Core OS/Hardware let myEmail = eskimo + 1 + @apple.com