NSXPCConnection or XPCKit - cocoa

There are two choices (or at least I know two) for implementing XPC client and service for Mac. NSXPCConnection which is introduced in 10.8 and XPCKit. What should I use to implement helper app that resides in menu bar and uses XPC to read data from the main app.
The main difference I see is that XPCKit will work in 10.7 Lion while NSXPCConnection is available only in 10.8 Mountain Lion. What else should I take into consideration when choosing between them. I'd be grateful for the responses from the developers who used both.
P.S. My app still works in 10.7, however from my previous experience it's not a problem to require the latest version of OS X in 2-3 months after release.

Finally I decided to use NSXPCConnection.
It is provided by Apple, so, less chances to have problems with updates.
Since the release of Mountain Lion and NSXPCConnection it seems that XPCKit is not supported any more.
I've tried both and for me personally NSXPCConnection seems to be a better solution

Related

Can my Mac OS X App use Storyboards in 10.10 and later, but not in 10.6 through 10.9?

I am working on a consulting gig in which my client got a prototype for his App to work on Mac OS X 10.10 (Yosemite) by using a storyboard. However the App crashes on 10.9.x and earlier, because the APIs required to use storyboards in Cocoa desktop applications were not yet available.
At present the application is not very complex, so I could satisfy his immediate requirement by revising his application so as not to use storyboards at all, I would instead implement his UI "The Old-Fashioned Way", without using storyboards at all.
I'm not real sure what is the best course of action. If I implement what I just said, he will eventually find his UI deprecated by Apple. If I use a storyboard for 10.10 and later, but not on 10.9 and earlier then there could be twice as much work for my client to develop this code.
Note that, as a consultant, I could stand to gain by increasing my client's workload. I don't want to do that as I regard it as unethical to take advantage of my clients by writing bad code. I really want to do right by this fellow.
Right. Storyboards are only available in MacOS X from 10.10 (Yosemite) onward. Support for storyboards is feature of the Cocoa framework, so the fact that it doesn't exist on versions <= 10.9 means code using storyboards won't work.
I'm not real sure what is the best course of action.
I think the most reasonable solution is to explain the situation to your client and let him decide. It's going to be a long time before .xib-based code goes away, if it ever happens, so sticking to .xib files for now is not necessarily a bad choice. On the other hand, your client might prefer to have the most forward looking app you can build, and he may not care all that much about supporting older OS versions. (Several sources indicate that as of early 2015, about half of all Macs are running Yosemite.) You'll serve your client best by giving him the information he needs to make a decision and then writing the app in accordance with his wishes.

Developing app for 10.8+ but using 10.9 SDK

Mavericks is coming out and for developers that's always a busy time with all these new features and APIs to know about and use. For me, I think it is the perfect time to ask a question that has been bugging me for a very long time.
Here's the thing, in context: I am developing an app that I want to be able to run on 10.8 (so the target system is 10.8+). Right now I am using the 10.8 SDK. However, with the release of 10.9 comes some pretty sweet APIs that I would like to use in my app. I use them in my code, but then, of course, I have to compile my app against the 10.9 SDK. If I do that, can I still run the app on 10.8?
Or, in a more general way, if I compile my app against one SDK, can I still run it on a 'lower' Mac OS? If yes, can you explain how does it work under the hood (what is the compiler doing)? This is a mistery for me.
Generally speaking, Xcode disassociates the issue of the SDK and the Deployment Target of the app.
The SDK is determined by Base SDK, and the deployment target is determined by OS X Deployment Target. These both show up in the Build Settings tab for each target in Xcode.
When programming with different SDK and Target, you are responsible for making sure that you don't call methods or functions on an OS that doesn't have them. This is often facilitated by weak linking (in the case of new frameworks) and/or using -respondsToSelector: in the case of new methods on existing classes and frameworks.
In Xcode, under build settings, there is an option for target OS where you can pick 10.8. 10.8 applications are generally compatible with 10.9 so the compiled application will work with both OSs.
Don't expect the new Apis to work when running on a lower version. It doesn't work that way.

Mac system application extension

I'm trying to modify the functionality of mission control which belongs to dock.app and I'm wondering what the preferred method of doing so would be. I've looked into using the simpler method of defaults but that won't give me enough control. I'm curious if people use something like Application Enhancer by Unsanity to execute custom code for these purposes.
Application Enhancer is effectively a dead project at this point -- while the current version does advertise support for Lion, Mountain Lion is slated for release within the next month, and it is unlikely that they will ever support it (as neither the Unsanity site nor their Twitter account has not been updated at all since last November). I would recommend strongly against using it for new products.
Under previous releases of OS X, SIMBL and PlugSuit have been popular, but neither one is available on Lion. The options seem to be more limited now; however, Rentzch's mach_star (mach_override / mach_inject) code seems to still be working.

Xcode 4 & Mac OSX 10.3?

I'm new at programming on the Mac. I've got me a brand new copy of XCode 4.0. I've got people asking me what versions of MacOSX we'll be able to support but I'm not sure what to tell them.
I see options for selecting an "SDK" and other options for selecting a target version. It seems the lowest I can go is 10.4 though -- even though we'd like to support 10.3, if possible without a lot of pain.
My question is, could anyone give me a quick rundown of how sdk versions and target versions fit into this? As I'm coding, what kind of things do I need to watch out for to make sure I can still support the smallest version of MacOSX? Likewise, how do I figure the G4/G5 (PowerPC) versions of MacOSX into all this? For example, on Windows, if I write an app in c#, I know that all I need to do is make sure an appropriate version of .net framework is installed, regardless of the OS. Does something similar hold true for the MacOSX?
Thanks in advance.
I believe Apple has dropped PowerPC support completely, including Rosetta, in Mac OS X so 10.3 is out of the question.
If you want to support PowerPC, see this related question. It looks like a lot of work.
How can we restore ppc/ppc64 as well as full 10.4/10.5 SDK support to Xcode 4?
With the analogy to the .NET Framework, there isn't anything like that for Mac OS X built-in.
It is true for Mac OS X. If your program targets 10.3 SDK, it will be able to run on 10.3 or greater. I.e. the Base SDK project setting specifies minimum target OS version.
However, supporting 10.3 IS a lot of pain. Even 10.4 is not that easy, for example Objective-C 2.0 (most important, #property, garbage collection) is only available with 10.5 SDK or above.
The common solution in existing projects is to keep an old version of software available for 10.1-10.4 users, while the new versions will require 10.5 or greater (and also usually are Intel-only).
If you're starting a new project, you will probably want to distribute it via Mac AppStore, which only works on 10.6+, which means you can safely pick 10.6 SDK as the lowest target version.
Apple is way more harsh about upgrades than Microsoft. Mac users don't walk around with 10-years old systems on their laptops. The only reasons I can think of to still use 10.3 are using 10-year old mac, not having Internet connection and not knowing what “to update a software” means. So, I wouldn't care even about 10.4, not to say 10.3.

Which version of OS X should my program target?

We're building an application for OS X, and we can't rely on our users all having upgraded to Snow Leopard, or whatever the latest version is. We want to make sure that as many people as possible can use our app, but we also don't want to throw away some improvements that were made in OS X version if only 1% of users are stuck using earlier versions.
Is there anywhere I can find information on the proportions of people that are using each version of the OS? Or is there some "common wisdom" on the issue that real mac developers know?
We don't need any superfancy graphics or 3d animation stuff, just plain old windowing APIs - but we've already run into one problem where "NSStreamDelegate" isn't supported prior to snow leopard.
Thanks!
Web stats from Quantcast, late February 2010.
North American stats, but might serve as a guideline.
Version %
10.6 27.3
10.5 52.1
10.4 17.2
Other 3.4
Omnigroup also provide some useful insight into updates to their installed base. You can click through to see breakdowns by major and minor versions on their site. For July 2010 they have:
Version %
10.6 53.3
10.5 21.0
10.4 25.6
Other 0.1
I think I'm one of the last holdouts with a still-functioning Powerbook G4. Its upgrade path ends with Tiger. On behalf of all those who won't get rid of computers that still work fine (if a bit slow by modern standards), please target 10.4 !
Of course by objective standards, you probably want to target 10.5. It adds nice programmability improvements, and really, I don't know a single person still using 10.4 other than me.
As for NSStreamDelegate, it has been available as an informal protocol (i.e. a category of NSObject) since 10.3. It is just that Apple decided to make it into a formal protocol, since Objective-C 2 has an #optional methods.
So, it's not that you're using new functionality only available on 10.6.

Resources