eskimo

I have created a helper app that does this processing and I have gotten everything to work except when I am updating the code in the helper tool I have to install the tool again.Last I checked, SMJobBless supports upgrading the tool from one version to the next. ISTR a caveat in there somewhere—I think that it requires authentication again, even though it shouldn't in that case—but the basic process should work. So, does your newer tool have a newer version?Share and Enjoy — Quinn The Eskimo! Apple Developer Relations, Developer Technical Support, Core OS/Hardware let myEmail = eskimo + 1 + @apple.com

Which platform (iOS or OS X)?If it's OS X:Is this talking to iCloud Keychain (via the 'synchronizable' flag)?Is your app sandboxed?Is your app building for the Mac App Store?The reason I ask is that iOS and OS X have radically different keychain implementations, except when it comes iCloud Keychain, where the OS X implementation is very similar to the iOS one. So, the first step of investigating any mystery keychain problem is to figure out which implementation you're talking to.Share and Enjoy — Quinn The Eskimo! Apple Developer Relations, Developer Technical Support, Core OS/Hardware let myEmail = eskimo + 1 + @apple.com

I'm not sure I fully understand your question but I believe that the following will help: A keychains group is to the standard keychain as an app group container is to the standard app container.That is, the only difference between group vs standard, security-wise, is that multiple apps from the your team have access to the group.Share and Enjoy — Quinn The Eskimo! Apple Developer Relations, Developer Technical Support, Core OS/Hardware let myEmail = eskimo + 1 + @apple.com

Possibly, but if Gatekeeper was unhappy with your app it should say so, not just cause the app to hang at launch.You can check what code signing and Gatekeeper think of your app with the following commands.$ codesign -vvv --deep /Applications/iTunes.app $ spctl --assess --raw /Applications/iTunes.appNote On 10.11 and later, also pass --strict to codesign. Share and Enjoy — Quinn The Eskimo! Apple Developer Relations, Developer Technical Support, Core OS/Hardware let myEmail = eskimo + 1 + @apple.com

These are part of AppKit, so you'll find them in a category in the NSAttributedStringKitAdditions category in <AppKit/NSAttributedString.h>. AFAICT they are not available on iOS.Share and Enjoy — Quinn The Eskimo! Apple Developer Relations, Developer Technical Support, Core OS/Hardware let myEmail = eskimo + 1 + @apple.com

iOS has no supported way to examine the ARP cache.Share and Enjoy — Quinn The Eskimo! Apple Developer Relations, Developer Technical Support, Core OS/Hardware let myEmail = eskimo + 1 + @apple.com

Mr. Quinn (The Eskimo!),I want to try your idea, it looks very promising. Thank you for taking the time, I really appreciate it, and your help!As far as my situation, I think that there may be other similar rate limited, or synchronous situations out there with other developers that are just like mine. Where a simple synchronous solution is needed. I think a wrapper (to get it off the main UI thread) around serial synchronous requests is a viable use case people are going to still need. You may not know the entire universe of use cases. In that case, it would be better to leave useful things that work, and let the SDK developers decide if they need it or not.To me it still makes no sense from my perspective as a SDK developer, why you would depricate something that is 1 line, works, has been tested, and has been around for 6+ years for something that is 33 lines, and doesn't have 6 years of testing behind it. Not every situation is going to be an async high speed network server. As you can see in my

something that is 1 line, works, has been tested, and has been around for 6+ years for something that is 33 linesYour line count comparison is not valid because you're comparing the call site in one case with the implementation in the other. Presumably you have more call sites than implementations (-:To make a valid comparison you'd have to know how many lines make up +sendSynchronousRequest:xxx. That's kinda hard to work out due to layering issues but I got to 274 lines before I gave up. Alas, this isn't open source so I can't show you my workings.I should also point out that we didn't just deprecate +sendSynchronousRequest:xxx, we deprecated all of NSURLConnection. There are very good reasons to do this, regardless of the state of our +sendSynchronousRequest:xxx. The real question is, when we introduced NSURLSession, why didn't we introduce a synchronous convenience method. And that's the subject of the rest of this post. Notably, even within the NSURLConnection world, +sendSynchronousRequest:xxx was effect

Is there a standard way of checking if the help tool is needing an update?What I do is send my helper tool a message asking for its version number. If the request fails, you know the tools not installed; if it works, you et back the version and can move on from there.EvenBetterAuthorizationSample shows the basics of this.Share and Enjoy — Quinn The Eskimo! Apple Developer Relations, Developer Technical Support, Core OS/Hardware let myEmail = eskimo + 1 + @apple.com

In this case the location reference tells TextEdit where to put the doc relative to other open docs. To create a new document and save it to a specific location, you can do this.set destFile to (POSIX path of (path to desktop) & Test Format.rtf) as POSIX file tell application TextEdit set newDoc to make new document save newDoc in destFile end tellShare and Enjoy — Quinn The Eskimo! Apple Developer Relations, Developer Technical Support, Core OS/Hardware let myEmail = eskimo + 1 + @apple.com

Hi eskimo,Thank you for your help.Now I have everything ok.JFontes

My recommendation here is that you first try out the basic process on a test app before trying to debug your main app. That way you'll have a concrete example of something that works, which is great in situations, like this, where you're exploring new territory.To create such a test app, do this:Create a new project from the Single View Application template.In Main.storyboard, add a label to the main view controller and change the text to English.In the project editor, in the Localizations slice, click the 'add' button and add Spanish (es) as a localisation.In the resulting sheet, leave both Main.storyboard and LaunchScreen.xib checked and click Finish.Main.storyboard should now have two localisations, Base and Spanish, where Spanish is just a strings file. Edit that strings file and change the label text to Spanish.Run the app in the simulator. The label should show English.Stop the app.In the simulator, in Settings > General > Language & Region > iPhone Language, select Spanish and confirm that

The App I'm developping is only for internal use in our Company and the server is also running in our private network. As a consequence we don't plan to get a certificate issued by a trusted CA.Ah, that's a different story. In situations like this you should create a CA for your company, if you don't already have one, and have the server's certificate issued by a CA. You can then install the company CA's root certificate on the device as a system-trusted root (typically via MDM). Once you do that, ATS will trust your company CA's issued certificates, just like it trusts certificate's issued by any other CA whose root is installed on, or built in to, the system.I tested this approach on a device here in my office, using a CA I maintain for my own personal server, and it worked just fine.if I use an NSExceptionDomains the following it doesn't work, what is wrong?…192.168.XXX.YYYI presume that the Info.plist doesn't contain XXX and YYY literally, but rather it has the actual numbers of your IP address.Regardless

Can I write the shell script …iOS does not have a shell.Share and Enjoy — Quinn The Eskimo! Apple Developer Relations, Developer Technical Support, Core OS/Hardware let myEmail = eskimo + 1 + @apple.com

There is no good way to download 10,000 to 20,000 individual resources. Specifically:Background sessions were designed for a relatively small number of large items and you will not get acceptable result if you feed a background session this many items. If you submit them all at once, nsurlsessiond will choke; if you batch, the resume rate limiter will ruin your day.Foreground sessions are rated for this sort of work, but downloading this many resources will take too long to reasonably do in a foreground session.You really really really need to batch up this work on the server side. If you don't have control over the server, my recommendation is that you create your own server that can act as your proxy: that is, you tell this server what resources you need, it fetches them, zips them up into an archive which you download.Share and Enjoy — Quinn The Eskimo! Apple Developer Relations, Developer Technical Support, Core OS/Hardware let myEmail = eskimo + 1 + @apple.com