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.
Related
I'm writing up a slideshow on keeping Xcode versions up to date.
It's not difficult to find out when Xcode versions BEGIN support, but not when Apple officially ENDS support.
Maybe the correct answer is "when the next version comes out," but the Xcode version tends to continue working for quite some time after the next variant comes out, and I know some folks that insist on using the old variant until the wheels fall off.
Eventually, the old version will no longer work on the current OS, and we need to hold back the OS to continue running the Xcode variant.
I need to find that point. I call it "The eBay Threshold." That's when we can no longer run the defined variant of Xcode on a new Mac, and need to buy old used Macs to run it.
As you might guess, this is a point of frustration for me. I hates ISO9001, as practiced by some outfits...
Thanks!
As you note, Apple stops supporting a version when the next version comes out. "When will it stop working" cannot have a definitive source because there is no firm definition of "working" in the absence of regression testing, and Apple does not regression test old versions of Xcode against new OS X releases.
The requirements are of course contradictory (which I expect you know). It makes some sense to demand near-total reproducibility. In that case, you must never upgrade the OS beyond the point release that existed when the next version of Xcode came out. Upgrading the OS beyond that means running Xcode in an untested mode, using "well, it seems to run" as your only criteria. At the very least, you would need to regression test your own software.
Obviously VMs are the best way to achieve this for a build infrastructure. The VMs need to be very carefully protected from outside traffic since they cannot receive even security updates without breaking their reproducibility.
Of course few develop Mac software this way. (This answer only makes sense for Mac development, and even then assumes that you are not submitting to the App Store. MAS and iOS development must keep up with the latest version of Xcode by Apple policy.)
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.
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
Starting with the next version of Mac OS X, Java will no longer be included in the system and I don't want to force my customers to install it themselves. So I would like to do what I do on Windows - bundle it with my app. It also gives me some hope that it could get included in the Mac App Store.
Where can I download a Mac OS X JRE that I could include with my application? Or can I just copy the one that's installed on my Mac?
Update (4/15/2013):
As Thorbjørn helpfully pointed out, Oracle now has a solution for this. See http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/packagingAppsForMac.html. However, I'm keeping the original content for "historical purposes", and because it was a fun research project.
Previous version (with edits):
This is a great question. I was going to respond that you are simply ahead of your time -- as you pointed out, Java is not going to be removed until the Lion release. However, this article makes it clear that using Java today is not allowed:
Apps that use deprecated or optionally installed technologies (e.g., Java, [PowerPC code requiring] Rosetta) will be rejected.
At the same time, no one has announced a redistributable JRE for Mac OS X yet. I think your best bet, bearing in mind that you are forging new ground, is to check out the Mac OS X Port wiki page of the OpenJDK project. It does describe how to compile your own JDK, but it does not clearly state whether or not the resulting JDK can be "bundled" cleanly or not. I think you will have to try it and see :-(.
Also, it's not clear if the OpenJDK licensing allows this at all (IANAL). Hopefully someone else has already figured this out with regard to Linux/Windows, although of course the rules may be different for the Apple contributions.
Hope this helps. If nothing else, it's a starting point.
EDIT: I am going to throw out one additional suggestion. We now know that Mono apps can be packaged for the App Store. Furthermore, IKVM.NET is a complete implementation of Java that runs on top of Mono. You could try, in theory, to put these two pieces together and get a Java app, bundled for the App Store, that does not in fact require a JRE!
If you try this, I would love to hear how it works out :-).
EDIT 2: Unfortunately, the App Store and the GPL do not appear to be compatible (see http://www.zdnet.com/blog/open-source/no-gpl-apps-for-apples-app-store/8046). The OpenJDK license isn't exactly the same as the GPL, but it's pretty close (again, IANAL). Therefore, Mono & IKVM.NET may be your best bet. Good luck!
In the same web search that I found this question, I've found the these instructions from the OpenJDK project. Not having tried them myself, I cannot comment on how well they work.
Meanwhile, another, very detailled article was published by Marco Dinacci which also goes into signing and sandboxing.
Apple has joined the Sun/Oracle OpenJDK open source project last month, so Java on Apple is alive and kicking.
Just tell the user to download and install the OpenJDK JRE for Mac OSX (when it becomes available, right now it´s just source code).
And no. you cannot include "the folder that is in your mac" without permission as it is copyrighted code from Apple.
Finally, packaging a "private JRE" is a very bad practice, it will make your app bloated, andif the user ends up running several Java apps, he will end up running multiple Java VMs simultaneously which is a terrible waste of system resources.
My company is in the process of rewriting our software from scratch, and I'm the one who is going to be doing most of the work in rewriting the Mac client (The core of our software is Windows based, and the Mac client communicates with it through a webservice).
This isn't a real heavy app, mainly does some background work tracking stuff and a UI component for the user to enter information.
I'm trying to decide how hard I should argue for dropping support for 10.4 and going with pure 10.5+/Obj-C 2.0 code.
My main motivations for this are:
It would be easier to code, I could use all the features of Obj-C 2.0 such as synthesized properties and fast enumeration.
It would give me access to several classes, and methods in existing classes, that don't exist in 10.4 (Just in mocking up a UI I've come across NSPathControl and NSTreeNode, both of which I would otherwise be very happy to use.
Preparing for the conversion to 64 bit coming in Snow Leopard. It seems like most of the techniques for preparing for the move to 64 bit (NSInteger, etc) are only available in 10.5+, and it would not be possible to use these if writing for 10.4.
The downside would of course be that we'd no longer be supporting an operating system that was only a year out of date.
My boss is himself supportive of this move, but of course has our customers to consider and doesn't want to cause any more issues for them than are justified. The director of support would like to support 10.4. I suspect the other execs will be marginally against it at first, just due to the not being able to support some customers thing. Everybody would be open to persuasion by a good argument from either side.
I'm trying to talk to some of the support people and get an idea of how many of our customers are actually still using 10.4, but I don't have that data yet.
Some kind of hybrid solution might be possible, such as rewriting parts of the old client to use the new webservice, or writing the client in 10.5 and backporting it to 10.4 if enough people made a fuss, but quite frankly those sound like they're likely to be even more trouble than giving up the 10.5 features and writing the code in 10.4 to begin with.
So I guess my questions are as follows:
Given the information above, do you think making a case for the adoption of 10.5+ only is the right thing to do? Do you have any suggestions as to how this might be presented positively to the rest of the company?
I don't know as much about the coming 64 bit transition as I'd like. Does anybody have any good references on what will be different, and do you think that supporting only 10.5+ would make this transition easier for us?
If it were I doing the update, I would target 10.5, especially since 10.6 is just around the corner and 10.5 did come out with a lot of great, new things (especially Objective-c 2.0). However, I think you really need to answer this question based on what you think your target customer group will be using. If they are slow to adopt new technology, it may be that you have to support 10.4 or risk losing a portion of your customer base.
On the other hand, you can actually target 10.4 and write using the 10.5 SDK. That way you can take advantage of all the preparations for 64-bit added to the SDK. You just have to ensure that you don't use any classes or features of the frameworks that didn't exist in 10.4. You can also do weak linking to the 10.5 frameworks and programatically decide whether you can use a new feature or not (while this is a bit of extra work up front, you can easily phase 10.4 support out of your code in the future and take full advantage of 10.5 improvements for users that actually are running 10.5).
There are a lot of blogs and write-ups about doing the cross-platform stuff out on the web. The other thing to keep in mind is that if you do target 10.4 make sure you have a 10.4 machine available to do a lot of testing (especially if you compile from the 10.5 SDK to take advantage of the 64-bit ready features). Also check the docks for any feature you may want to use from the 10.5 SDK. Many features were actually available in 10.4 but undocumented and the new documentation usually states which features you can safely use when deploying to 10.4
Do you need 64-bit? Unless your application is very CPU-intensive, it won't make any difference.
Tiger can run 64-bit applications, but without GUI. If you need 64-bit, you can create 64-bit CLI executable that does heavy lifting and provide 32-bit font-end for it (using NSTask and NSPipe).
You can also have separate .nib files for Leopard and Tiger:
-(id)init
{
BOOL tiger = floor(NSAppKitVersionNumber) <= NSAppKitVersionNumber10_4;
NSString nibname = (tiger ? #"WindowTiger" : #"WindowLeopard");
if (self = [super initWithWindowNibName:nibname])
…
You really need to find out what your customers are using, and the support person is probably best positioned to know, or the product manager. That said there's nothing wrong with making the technical arguments clear now even if 90%+ of your user base were pre-Leopard; that way the issues will be known (and hopefully understood) so you'll have more support as the environment does change.
I never wrote production code in Objective-C and its hard to keep up, but as far as i am aware NSInteger and friends are in 10.4, it's just that Cocoa isn't 64 bit in 10.4 whereas in 10.5 most of it is (so no more need for seperate 64bit worker process under a 32bit UI).
I don't know what your product is, or who your customers are, but from my experience, Mac users are early adopters (relatively speaking) I've never used an OS X version longer than two weeks before the next upgrade was out, and in my circle I am a late adopter. Ofcourse I'm not just a business Mac user and that may well make a big difference.
What makes 64bits a requirement in your code? There's not much of a reason to not compile a universal binary holding as many architectures as you wish you could have one binary run on G4, G5, IA32 and IA64 no problem, and have it be native on all of them. If you're just doing 64bits because you can there's no reason (that I can imagine) not to keep supporting 32bits, but if you want stuff like CoreAnimation you don't have much choice.
I don't think it's wrong to demand 10.5 for new development, but it wouldn't make much business sense to force a whole new OS on customers just to keep using your existing product. So if you can, stay compatible, maybe backport your new features/patches for a time. There is a good reason for forking in version control and this might be it.
edit-
Since I posted this I learned that I was wrong and NSInteger did not exist before 10.5. I think I assumed too much having used similar types (like NSDecimal) earlier.