My app needs to run on 10.4 or later. If I launch it on 10.3 it just fails to launch or crashes.
How do you tactfully enforce minimum system requirements? Can you customize the message it shows?
Add a key to your applications Info.plist, specifying LSMinimumSystemVersion as 10.4.X for whatever X you need as a minor version. For more, see Apple's documentation.
I have not used either of these techniques/advice, just passing along the information I have gathered.
You might try something like the SystemVersionCheck “shim” executable to provide a working OS version check for versions that do not honor LSMinimumSystemVersion (e.g. 10.3).
The pre-compiled executable is PPC-only. You might need to rebuild it to support PPC and Intel machines so that it works with 10.3, but also so that 10.6 users are not prompted to needlessly install Rosetta. I found a blog entry that has a hint on how to setup the PPC build to target 10.3 and the Intel build to target 10.4u (it was written about 10.5 and Xcode 3.0 though—do the latest versions of Xcode even include the 10.3 SDK?).
If you experience a crash after adding the LSMinimumSystemVersion key to your app's plist manually, then this is due to the Finder not recognizing the changed state of the app properly. Either restart the Finder (e.g. log out) or duplicate the app in the Finder. The copy will then behave correctly.
Related
I just installed the latest version of Xcode (10.1) on MacOS 10.14 (Mojave).
I can build my application and it runs fine on my Mac or similar system.
However, I want to share this application with someone using MacOS 10.11 (El Capitan) and it fails to launch, asking for a minimum requirement of MacOS 10.13 (High Sierra).
My application is only very simple, can't I compile it to be compatible with older MacOS ?
After some research, I did download MacOSX10.11.sdk
(from https://github.com/phracker/MacOSX-SDKs/releases/).
I did decompress it, and drag it into:
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs
(This folder originally contains only "MacOSX.sdk" and a link pointing to it, named "MacOSX10.14.sdk")
I also noticed the value of the string "MinimumSDKVersion" from the file /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Info.plist is equal to "10.11", which sounds good in my case.
I read on some forums adding additional SDK versions into Xcode is not supported. And by the way, I cannot see any menu from Xcode to specify my target build (neither in Xcode Preferences, nor in the project settings (see picture below).
Where can I tell Xcode to use, let's say "MacOSX10.11.sdk" over "MacOSX10.14.sdk"?
And, is there a better way?
Or, do I have to install an old version of MacOS on a different partition, with an old version of Xcode (which would be a pain)?
I am not sure if this still works on Mojave, but there is a project called XcodeLegacy which is created specifically with this intention in mind:
https://github.com/devernay/xcodelegacy
Regarding the menu, you can find it at: Xcode -> Select File -> Project/Workspace Setting
Open Workspace Settings
Works on Xcode 13, I'm a bit late to the party but just had the very same question.
here is my dev/project settings:
Deployment Target - 10.6
SDK: 10.9
Architecture: Universal 32/64.
Now when I archive and try to run it on ML 10.8 (other machine not my dev machine); It crashes and gives me "Classic environment is o longer supported" error.
I have not tested it yet on 10.6 though but what is the best way to keep my app running fine on all of them 10.6+ ?
Also I am using ASIHTTP and setting it to "-fno-objc-arc" in build-phases.
Please help.
I have set my project's Deployment Target to 10.6 to support older machines.
The Classic environment is no longer supported shouldn't be occurring based on the information your provide, as that refers to code written for OS 9, not OS X. However, based off of my own experience (this question), besides setting the deployment target to 10.6, you must also turn off base internationalization and auto layout for your NIBs. Good luck!
I have an application in the Mac App Store. I'm trying to support users going back to Snow Leopard but this is becoming increasingly difficult.
Recently I've hit a roadblock due to the iTunesLibrary.framework, this framework must be linked to the main executable and yet doing so will always trigger a crash on load when running in Snow Leopard.
To workaround this problem, I want to compile a version of my app that doesn't use features and frameworks from newer versions of OSX. The problem is, how can I launch the compatibility build automatically?
I'm considering trying to make the main executable point to a shell script, but I don't really like that idea. I've also thought of the main executable being a helper that simply launches the full app and then exits. I expect this would work, but I worry about it getting approved by Apple. Finally, I'm wondering if the app bundle format itself can support this kind of setup, maybe via an advanced used of CFBundleExecutable that I'm unaware of.
Has anyone been down this road, what would you suggest?
Try weak linking the frameworks, more information about Weak Linking and Apple Frameworks here. Then also check in your code for the OS version or - (BOOL)respondsToSelector:(SEL)aSelector of any NSObject to determine what you can call and what not.
To have Snow Leopard as Base SDK you'll need an old Xcode and will have troubles submitting to Mac App Store.
after reading the apple SDK guide
https://developer.apple.com/library/mac/#documentation/developertools/conceptual/cross_development/Overview/overview.html
I'm still confused of how to make the mac app backward compatible & how to test them properly
I have an app, I run it and tested it on Mountain Lion 10.8 without any problem, however I want to make this app backward compatible so that other users can run it on a mac 10.6 - 10.7 machine.
I have an apple developer id and I can download the old versions of 10.7 and 10.6, but the problem is, I have a 2011 macbook air which is currently running 10.8, and that's the only apple machine that I have. Can I test the 10.7 and 10.6 by using vmware or parallels?
in my project settings, I set the target deployment to 10.6 (as I want 10.6 users to run my app), but should I set my SDK to 10.8 or 10.7? if I set the SDK to 10.8 but having the target deployment set to 10.6, if I fix all the xcode warnings will it run successfully on 10.6??
from the SDK drop down, I can only set to 10.8 or 10.7, but 10.6 is missing, how do I fix that?
thanks in advance
I develop on a 10.8 box and support back to 10.5. Just a couple of months ago we dropped 10.4 PPC support, and I'm still cleaning out some of the 10.2-specific code. This may get a little rant-y, but I've been doing old versions for a long time. I have some opinions on the matter.
No matter what Apple says in their docs, if you want to support 10.6, then build with the 10.6 SDK. Do not rely on distribution target.
I have had this discussion with the Xcode engineers, and while they hold to Apple's party line that you should always build with the latest SDK, they also acknowledge that it's generally insane to do so. If you build against the 10.8 SDK and mark your deployment target at 10.6, you will get no warnings for using methods that do not exist on 10.6. The only way you will discover that you've used a nonexistent method is that it might give you strange bugs when run on 10.6. That's insane.
Remember, OS X doesn't crash when you send an unknown selector. It just aborts the current runloop. So the bugs are even harder to track down then on iOS, where it crashes the app.
Sure, you can do weak linking. Talk about dangerous.... Yes, there are a few times this is useful, but the compiler gives you no warning if you don't do it correctly. If I'm going to do weak linking like this, I go the other way, linking against the old SDK and copying the new function's prototype into my implementation. That way I have documentation of every function I think I'm going to weak-link.
Download the old SDKs and symlink them into your Xcode distribution.
Guard them jealously. Apple will try to delete them every time you upgrade Xcode. Make your own copies and stick them in /SDKs or somewhere else away from Xcode. I provide a script called fix-xcode to manage the symlinks automatically. Am I bitter at Apple for their relentless insistance on deleting my old SDKs? Yes, I am.
You can run 10.6 Server in a VM legally. You can run 10.7+ Desktop in a VM legally. These are good ways to test your code.
Or you can do what I do and have a small pile of old MacBooks each with two or three partitions on them that you reboot all the time.
Now that 10.7 comes from App Store, it's a little harder to make VMs. My strong recommendation is to snapshot your image immediately after install, and make a clean backup copy of it. You'll want to be able to clone that image from time to time when you need to get back to a "raw" machine.
Get in the habit of squirreling away SDKs as they come out. 10.8 will be old some day. You might as well make a copy now while it's easy.
Whether you support individual dot-releases or not, it can be very helpful to keep around the upgrade packages for individual dot releases. When you encounter customers running non-current releases, it's nice to be able to check whether an "unreproducible" bug in fact is easily reproducible on their specific version. Whether this is worth it or not depends heavily on your product and customers. It was a life-saver for me when 10.4.11 made major changes to WebKit during a dot release...
Invest in a small NAS or a big external USB drive (though I've had trouble with those failing when used extensively, so I prefer a RAID). You'll need the space. You want to hold onto lots of VMs and lots of SDKs and sometimes even old versions of Xcode.
Adding to Rob Napier's great in-depth answer:
To use an old SDK, put the SDK (or a symlink) to it here:
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs
With XCode 7.3 or later, you need you to open this file and change "MinimumSDKVersion" (otherwise XCode will refuse to use the old SDK):
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Info.plist
You can install multiple versions of Mac OS on a single machine, booting between each.
The SDK should be the latest (10.8).
See 2.
One alternative to 1 that I've considered (I am in the same boat) is to create a Snow Leopard Hackintosh using an old PC and just installing Lion and Mountain Lion on my MBP.
You need to do these settings :
1.Set the Base SDK to Current version of Mac (ex. 10.7)
2.Set the Deployment SDK to older version (ex.1.4)
I've been building a basic Cocoa application with Core Data and Interface Builder, and no extra coding, frameworks, or header files. I sent it to someone to test on their machine (a last-gen G5 iMac), and they got a message saying that their machine couldn't run it. I discovered the switch to compile for PPC, so I built a PPC version of the application to try out, and that produced the following error message:
You cannot use this version of Application on this version of Mac OS X.
I'm running Xcode 3.2.1, Interface Builder 3.2.1, and OS 10.6.2. The conversation with my tester was a bit confusing; at first it sounded like she only had Tiger on her machine, saying Leopard was incompatible (I corrected and said that Leopard should be, it's Snow Leopard that isn't), and then by the end of the conversation she was about certain that her machine was running Leopard, but had already shut it off by then. So I'm not sure which version of OS X is on the offending iMac, but it's the latest version of either 10.4.11 or 10.5.8 (the tester is in a remote location, so I can't verify personally at the moment).
What can I tweak to try and improve compatibility on my tester's machine?
If they're seeing that message, it's most likely because your app has the LSMinimumSystemVersion key (Minimum system version) set in the Info.plist. You should take this key out or set it to the actual the minimum OS X version you support.
Once you do this, you may well run into the next problem. (Probably a dynamic linker error as a result of using a framework or API that didn't yet exist on 10.4 or 10.5.)
The main problem here is that you're sending it out to a system where you haven't actually tried it. If you plan to support 10.4, 10.5, or both, I highly recommend that you find a spare hard drive, partition it up, and install 10.4.11 and 10.5.8. There are many issues that will crop up on older OS's and if you haven't tried it yourself, it's unlikely it will work smoothly on the first try.