eskimo

You should read the SDK Compatibility Guide. It explains the overall process here. The guide focuses on Objective-C but most of the techniques shown there have Swift analogues.Also, if you're using Swift 2 you should definitely read up on its new availability features. These are introduced by the Xcode Release Notes and covered in depth by the latest The Swift Programming LanguageShare and Enjoy — Quinn The Eskimo! Apple Developer Relations, Developer Technical Support, Core OS/Hardware let myEmail = eskimo + 1 + @apple.com

Eskimo & POM, thanks for your responses --Yes, the driver is correctly signed (unless something in this process I don't know about has changed since Yosemite). Messing around with kextutil got a working away of loading the module, but I'm not sure why the way we've been doing it is failing:Previously (from a daemon running as root): /sbin/kextload -b com.contentwatch.ghoti.NARCPacketInterceptorManually running this on El Capitan results in the following error:com.contentwatch.ghoti.NARCPacketInterceptor failed to load - (libkern/kext) not found; check the system/kernel logs for errors or try kextutil(8).(System log says essentailly the same thing: It cannot find com.contentwatch.ghoti.NARCPacketInterceptor)However, both kextutil and kextload using the path of /Library/Extensions/NARCPacketInterceptor.kext work. The output of kextstat with the module loaded shows the identifier that was being used with -b above: 107 0 0xffffff7f821f3000 0x9000 0x9000 com.contentwatch.ghoti.NARCPacketInterceptor (1

But, are you saying that if I add IN ONLY ONE TIME 200 NSURLSessionUploadTask instances in the same NSURLSession configured with a background session configuration, iOS will propertly handle all of them?Yes. The NSURLSession background download system will happily deal with a few hundred requests. It serialises them internally, so only a few of those requests hit the 'wire' at any time.If yes, is there any limit in term of number of tasks?There is no hard limit but I generally recommend that you avoid pushing things too far. IMO hundreds of requests are fine, thousands of requests are pushing things, tens of thousands of requests would be silly.I generally recommend that, if you have to deal with thousands of individual items, you zip them up and transfer them as one resumable transfer. There are, however, some gotcha there:o Doing this sort of thing requires sophisticated server-side support.o NSURLSession background sessions automatically handle resumable downloads (if the server supports it). That's not tr

The system is definitely capable of handling simplified and traditional Chinese. Try re-creating this issue in a small test project to see if the problem is specific to your app or specific to how your adding localisation. Specifically:Create a small test project with a base localisation of English.Add Chinese (Simplified) and Chinese (Traditional) to it.Fill out those localisations.Run your app in both languages.Note In step 3, you don't actually have to fill out the localisations correctly. Just add some dummy values so that you can tell which localisation you got.If this test app works then you know that there's something weird going on with your main app. OTOH, if this test app doesn't work then either your localisation process has problems or there's something weird happening in the system.Share and Enjoy — Quinn The Eskimo! Apple Developer Relations, Developer Technical Support, Core OS/Hardware let myEmail = eskimo + 1 + @apple.com

I would prefer to target 10.6 (yes, I know it is old), possibly 10.8 as the latest in order to support as many systems as I can.You really don't want to do this. Getting a KEXT to build and run all the way back to 10.6 is a pain even if you ignore the debugger issues. Specifically:There's a code signing inflection point at OS X 10.9. OS X 10.9 requires signed KEXTs and OS X 10.8 won't load KEXTs that are signed. WWDC 2013 Session 707 What's New in Kext Development has the details.There's a 64-bit inflection point somewhere around OS X 10.8. Mac OS X 10.6 runs on 32-bit hardware, so you have to build a universal KEXT. In addition, OS X 10.7, even though it only runs on 64-bit CPUs, still has machines running K32, so you need the universal KEXT there too. I think we went K64-only with OS X 10.8, but it might have been later.The K64 transition is covered by WWDC 2009 Session 501 Managing Kernel Extensions and 502 Creating I/O Kit Drivers for Multiple Architectures and OS Versions. I'm not sure if our WWDC video

It's heavily implied by the design. It's obviously safe for your main thread code to access the shared credential store and CFNetwork has a number of secondary threads that also access that same store.Share and Enjoy — Quinn The Eskimo! Apple Developer Relations, Developer Technical Support, Core OS/Hardware let myEmail = eskimo + 1 + @apple.com

The proxy settings specified in a mobileconfig file doesn't seem to recognized by iOS 9.Does this work the way you expect on older versions of iOS? If so, that's a clear regression and I recommend that you file a bug report about it.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

Is it possible to do so ?It is not possible to do this with our high-level APIs. Why do you need this? I presume you have a good reason, in which case I recommend that you put that reason into a bug report requesting that NSURLSession support this.With low-level APIs you can force a particular TCP connection to run over a particular interface, which allows this sort of thing. It's kinda ugly those, not least because you have to build your own HTTP implementation on top of the TCP connection you're using.I posted about this extensively on the old DevForums:https://devforums.apple.com/message/954984#954984https://devforums.apple.com/message/651340#651340https://devforums.apple.com/message/169959#169959https://devforums.apple.com/message/158195#158195Share and Enjoy — Quinn The Eskimo! Apple Developer Relations, Developer Technical Support, Core OS/Hardware let myEmail = eskimo + 1 + @apple.com

There are strict limits on the amount and type of information I can share here. I will say that:Keychain engineering is well aware of how important this issue is.The primary problem has been reproducing the failure here at Apple.We're now able to do that (largely thanks to the work you guys have put in filing and following up on your bug reports).Share and Enjoy — Quinn The Eskimo! Apple Developer Relations, Developer Technical Support, Core OS/Hardware let myEmail = eskimo + 1 + @apple.com

The server would send a certificate in a .pem or .der format continaing the public key.Yes. DER format would be easier because you can pass the data directly to SecCertificateCreateWithData. My app would use the SecKey functions as shown in this document to save the key sent in that certificate to the keychainYou could do this but it's not required; you can get the public key from the certificate, even when it's not in the keychain, using SecTrustCopyPublicKey. I described how to do this in this post on the old DevForums. Note that putting a certificate or public key in the keychain is possible but rarely necessary and, in situations where it's optional, there's no benefit to it. The keychain is about storing secrets, and public keys aren't secret.I'd sign my data using the public key I stored in the keychain.Huh? When you sign data you're supposed to use the private key; that's the only way things make sense (the signature proves that someone with access to the private key signed the data).Share and Enjoy —

Basically, our app opens terminal and runs a script that automatically types in the credentials of whatever network device you want to configure.This is not compatible with sandboxing. Consider the script your posted later on; if you can tell Terminal to SSH to a particular server, you could tell Terminal to rm -rf ~, and that's obviously nonsensical for a sandboxed app.There's no clear way forward here. AFAICT your options are:distribute outside of the Mac App Storeput the terminal emulation code within your app — That's a lot of work.file a bug requesting that Terminal support a scripting access group for setting up Telnet and SSH connections — If you do this, please post your bug number, just for the record.implement your scripting with NSUserScriptTask — Be aware that App Review has strict rules on how folks can use NSUserScriptTask and a single-purpose app that uses NSUserScriptTask simply to bypass a sandbox restriction is unlikely to be well received.These options aren't mutually exclusive, so you coul

Then it's what POM said. From a security perspective the only difference between a group container and your app's standard container is that multiple apps from the same team can access the group container. So, as long as you trust yourself (-: the group container raises no additional security concerns.Actually, the above is a little too glib. The attack surface of your app's standard container is just your app. The attack surface of a group container is all apps that you ship that can access that container. That's likely to be larger, and thus there is a difference in the security.Whether that's a significant difference is something for you to decide.Share and Enjoy — Quinn The Eskimo! Apple Developer Relations, Developer Technical Support, Core OS/Hardware let myEmail = eskimo + 1 + @apple.com

First, I've moved your post to Xcode > Getting Started because Xcode > Objective-C is for discussing the language itself rather than how to program with the language.You wrote:It is loading it but when i click on it nothing happen.That's not much to go on. Have you tried setting a breakpoint in the code and stepping through it? That'll tell you, at a minimum, whether your code is running.Share and Enjoy — Quinn The Eskimo! Apple Developer Relations, Developer Technical Support, Core OS/Hardware let myEmail = eskimo + 1 + @apple.com

You'd have to get really low-level. The most common Swift constructs for this sort of thing (String, Array<UInt8>) are value types but the underlying storage typically comes from a heap block that you don't have access to. OTOH, there's nothing stopping you from calling low-level memory allocators in Swift, at which point you could scrub the memory before freeing it. The problem with doing this is that it's not practical. Let's say you need to ask the user for a password; how are you going to do that? Most folks would use a text field with the secure (secureTextEntry) flag set. How does that field return its value? Via an NSString. Can you reliably scrub that memory? No. The same sort of logic applies to network I/O, file I/O, the keychain, and everything else you might want to do with your security-sensitive data.Share and Enjoy — Quinn The Eskimo! Apple Developer Relations, Developer Technical Support, Core OS/Hardware let myEmail = eskimo + 1 + @apple.com

Ok I posted a bug report requesting access, the bug number is 21876609. Thank you for all your help so far, Eskimo and POM. I really hope we can get this worked out because the Mac App Store is our biggest market to sell the app.