eskimo

If the user cancels out of the captive network web sheet, the system will disassociate from Wi-Fi.Share and Enjoy — Quinn The Eskimo! Apple Developer Relations, Developer Technical Support, Core OS/Hardware let myEmail = eskimo + 1 + @apple.com

Did you get the auto ACK that includes the questionnaire?Share and Enjoy — Quinn The Eskimo! Apple Developer Relations, Developer Technical Support, Core OS/Hardware let myEmail = eskimo + 1 + @apple.com

Regardless of whether this is a known bug or not, I recommend that you file your own bug about this. Make sure to include the logging information described by the Wi-Fi Logs page.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

You should be able to get simple challenge handling working in this way but I doubt you'll be able to handle all the interesting cases. The problem is that the NSURLProtocol mechanism assumes the original NSURLConnection authentication challenge model, and at least three major revisions to the model have been applied since then.Which makes me wonder why you're stubbing at this level rather than stubbing the NSURLSession API itself. That seems like a much more direct solution to this problem.Share and Enjoy — Quinn The Eskimo! Apple Developer Relations, Developer Technical Support, Core OS/Hardware let myEmail = eskimo + 1 + @apple.com

How do I deal with this when the application enters in the background or the iDevice goes to sleep mode?Well, you can put the accept call in a separate thread or use a GCD event source to run a non-blocking accept setup, but none of those will help you if the app gets suspended. IMPORTANT I'm using the terms from Technote 2277 Networking and Multitasking here; you should read that before going further.To successfully listen for incoming connections you have to prevent your app from being suspended. That's not a problem if your app is in the foreground. However, if it moves to the background—possibly because the user has screen locked the device—your app will typically become eligible for suspension and, if it gets suspended, there's no way to wake it up when a new connection arrives.This gives you a number of options:prevent suspensiondon't listen when you might be suspendedrethink your overall approachThe last point is critical: iOS is not really meant to support third-party server processes, so things go a

Weird.I usually tackle problems like this by simplifying things:rip out chunks of potentially worrisome code until things start to work, orwrite a simple test app and add code to that until you can replicate the problemIt's safe to assume that UDP works on iOS, so this bug is very likely to be in your code, or in how your code is using CFSocket.Share and Enjoy — Quinn The Eskimo! Apple Developer Relations, Developer Technical Support, Core OS/Hardware let myEmail = eskimo + 1 + @apple.com

For this to work over WWAN you have to use some sort of centralised server; doing this peer-to-peer over WWAN is virtually impossible.Once you start thinking about centralised servers, you have two options:build your ownuse someone else'sThe first option gives you more flexibility; the second gets you out of the business of running servers, which is generally a good thing.Are both copies of the app being used by the same user? If so, you might able to do this using iCloud, either through the file system or via CloudKit. If not, you have to think seriously about security, because you want to make sure that the data doesn't get seen by people it shouldn't be seen by, faked, or otherwise corrupted in some malicious way.Share and Enjoy — Quinn The Eskimo! Apple Developer Relations, Developer Technical Support, Core OS/Hardware let myEmail = eskimo + 1 + @apple.com

In general problems like this are bugworthy. If it were causing problems for your app I'd be happy to dig deeper but, given that your app is working fine, I recommend you file a bug and move on.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

There are a number of examples showing NSXPC but I'm trying to use the xpc.h interface.Why? In my experience the C XPC API is substantially more work than NSXPCConnection, so I recommend you use the latter unless you have a hard requirement that forces you to use the former.Share and Enjoy — Quinn The Eskimo! Apple Developer Relations, Developer Technical Support, Core OS/Hardware let myEmail = eskimo + 1 + @apple.com

I would like to know if there is a way to prioritize pre-login launchd agents?No there is not.I would likle to ensure a higher priority for my HelperTool.I don't understand this. Priority with regards to what?btw A lot of folks who ask this question end up wanting to run synchronously with respect to other parts of the login sequence, in which case the technique described in TN2228 Running At Login is the way to go.Share and Enjoy — Quinn The Eskimo! Apple Developer Relations, Developer Technical Support, Core OS/Hardware let myEmail = eskimo + 1 + @apple.com

You're right that XPC applies a lot of constraints here. I suspect your best option is an XPC service to broker these requests. Have the app pass work to the service and then have the launched helpers connect to the service to request the details of that work. Once things are connected up the app and the helpers should be able to communicate directly via an XPC endpoint.Share and Enjoy — Quinn The Eskimo! Apple Developer Relations, Developer Technical Support, Core OS/Hardware let myEmail = eskimo + 1 + @apple.com

Our analysis is that the security context of the tokend prevents any possible architecture that would allow to prompt for a GUI. We’d like to confirm that statement from Apple.If you want a formal response to this, you should open a DTS tech support incident.Share and Enjoy — Quinn The Eskimo! Apple Developer Relations, Developer Technical Support, Core OS/Hardware let myEmail = eskimo + 1 + @apple.com

If you haven't already done so, you should file a bug about this issue. 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

They are. You can see this in the Darwin open source code for these routines.However, if you're trying to generate a small number of cryptographically sound random numbers—for a symmetric cypher IV, for example—I generally recommend SecRandom.Share and Enjoy — Quinn The Eskimo! Apple Developer Relations, Developer Technical Support, Core OS/Hardware let myEmail = eskimo + 1 + @apple.com

I suspect that you have both Swift and Security framework issues here. I'm going to focus on the Security framework side of things first, because that's the most significant.What type of key are you trying to generate? You're creating a key from random bytes, which implies that you're trying to deal with a symmetric key. If so, I recommend SecKeyGenerateSymmetric, which is likely to easier to use that the lower-level SecItemAdd (the problem with the latter being that you have to get all of the key's myriad attributes right before things will work correctly). Share and Enjoy — Quinn The Eskimo! Apple Developer Relations, Developer Technical Support, Core OS/Hardware let myEmail = eskimo + 1 + @apple.com