When interacting with other applications on the Mac, AppleScript is the main option to use. Writing AppleScript to run within an application can be pretty annoying, and there’s no syntax checking unless you write it in AppleScript Editor first and then bring over the code. A good solution is using the ScriptingBridge framework, which will provide you with a class interface to interact directly with a target application. Of course your target application must support Applescript, just as if you were writing the script manually.
If you’ve ever needed to have an object with multiple delegates you may have created an array and then added each of your delegates to it. This does work but there’s a simpler way which is much easier to implement. Using the NSNotificationCenter you can have objects subscribe to the events/messages they want to know about and get called whenever that ‘event’ takes place. The Cocoa framework uses this as well, and let’s you subscribe to things such as an app entering the background, changing orientations, when it’s running out of memory and when the keyboard is presented or dismissed.
As of June 1st this year all newly submitted apps and versions on the Mac Appstore require sandboxing. Sandboxing means that each app is run inside it’s own quarantined space to make sure the app doesn’t do anything malicious. For a lot of apps this will be sufficient, but for apps that let you do really special stuff this is the thing that kills them.
In OS X Lion Apple introduced the concept of document versions, the ability to go back in time on documents and view or restore a version from the past. With this they introduced a “Lock” on documents that hadn’t been changed in over a week or so and requires you to unlock the document or duplicate it and save it elsewhere.
In this tutorials I’ll show you the basics of taking screenshots on a range of devices including computers and tablets/smartphones. I’ll also show you some extra little tricks for taking a screenshot of only the content you want captured. Tutorial covers Windows, Mac, iOS and Androids.
When developing on the Mac and using custom frameworks in your application, when you compile the frameworks are copied into your applications bundle then linked at runtime. These frameworks will most likely be bundled up with their headers. Some of the frameworks you include may not be things you want to make public to the world, which you are essentially doing by including the headers with the framework.
In Xcode the build settings screen can be pretty daunting for some people, especially when you start iOS/Mac development. Knowing which settings to pick can be tricky, but I still see a lot of people that do this individually for each of their projects, which makes it easy to miss crucial build parameters you don’t want to distribute your app without. Using a .xcconfig file is extremely useful for solving this problem, it is a type of file for determining build parameters, meaning you can have this file sitting in one spot and have each of your projects referencing it. If you need to make a build setting change to all your projects, you can just add it to this one file and the next time you compile each of the projects the change will be taken into account.