OK, so here's my situation :
I've got Xcode 5.1.1 on a 10.9 (Mavericks) machine
I want to build my app so that it runs on 10.6 and later
SDKs installed : 10.6, 10.8, 10.9
What do I have to do to make sure it'll show up as "10.6 and later" compatible in the app store?
I managed to get it to compile fine with Base SDK set to either 10.8 or 10.9, and Deployment Target set to 10.6. Will that suffice?
P.S. I've tried compiling with Base SDK set to 10.6, as well, but there are so many errors to be fixed, that it'd be better if I could avoid it.
So any ideas?
Yes; using 10.9 SDK with the deployment target of 10.6 will work fine.
You may find you have conditional code-paths which must be determined at runtime, perhaps based on respondsToSelector, which will require some #pragmas in order to compile successfully.
The Deployment Target defines the minimum OS version that your app requires at run time.
The Base SDK defines the level of API features that are available at compile time.
Therefore you can use 10.9 as Base SDK when building apps that can run on 10.6 and upwards.
You just have to make sure to avoid code paths that use 10.7/10.8/10.9 APIs when your app runs on a 10.6 machine.
As trojanfoe already pointed out, you can use respondsToSelector: to check if a certain class/method is available.
Another way is to use NSAppKitVersionNumber:
if (floor(NSAppKitVersionNumber) <= NSAppKitVersionNumber10_8)
The NSAppKitVersionNumber constants for the latest SDK can be found in the AppKit Release Notes.
Further details can be found in Apple's SDK Compatibility Guide.
Related
I have an old mac OS application developed in Mojave with the deployment target 10.12. Now how to update mac OS application to support Catalina? Or is the application automatically supports all future mac OS versions?
When developing for macOS (or any other Apple platform, for that matter), there are two key concepts to take into account when thinking about compatibility:
The SDK version: this is the SDK you're compiling against and it is usually determined by the Xcode version you're using to build your project.
The Deployment Target: this is the lowest OS version you want to support.
Normally, if you have followed the best practice in implementing your code and all of your dependencies have done the same, updating an app for a new macOS version requires only to download the latest Xcode on the latest macOS, build it and run your smoke tests (manually or through automated tests).
There may be things that have been deprecated in the meantime and Xcode will report them as warnings while building. You may read more about deprecated APIs in the macOS 10.15 release notes.
Keep in mind that you don't actually have to rebuild your app every time a new macOS version comes out. Even though it is better to test it at least once and dedicate time to explore and make use of new APIs, apps built on the previous version of macOS will, most of the times, run flawlessly on the next version (and maybe even further). This obviously depends on the app complexity, so your mileage may vary.
I have created a cocoa application which used the base SDK OS X 10.10. Some APIs which only exists in 10.10 are called. So it doesn't run correctly in the system which version is lower than 10.10.
So, i wan't to know is there any way can make my application run correctly in OS X 10.9 except rewrite it use lower SDK.? If not, What is the value of these new API. because i can't use it. If i used it application can't work in lower system.
Thanks!
You should use 10.10 as your Base SDK, and set your deployment platform to 10.9. You can then use respondsToSelector: and NSClassFromString to know if the class/method you're trying to use is available on the current OS, and degrade gracefully (for example, only make a feature available if you're running on the latest OS).
No, you'd have to rewrite it to use API calls which are available in 10.9.
The point of adding new calls to the API is because eventually everyone will have a device running the newer software - especially with Apple products - and then you'll be able to use it. Also, some people don't mind not being able to run on an older device. If they never added anything to the API then we would still be using the same things from 20 years ago.
If you think this is bad then try writing software for Android. The majority of devices are still running old API versions.
Essentially the answer is NO. You can't make an app which is built using the latest API's for 10.10 run in 10.9.
What the value of using the latest API's is depends on what you want to achieve. If you want to take advantage of the latest Apple technologies like iCloud Drive and CloudKit then you need 10.10. However, if your project doesn't need the these technologies then it may be worth making your app using a lower SDK.
It's worth noting that OS X 10.10 is free so you probably won't be alienating anyone by using the latest SDK. It's a different story for iOS where usually only the latest few iPhone and iPad models can be upgraded (e.g. iOS 8 from iPhone 4S and upwards).
Hope this helps.
I have MacOS-X - 10.7 and Xcode - 4.6.2 and made a Mac application. The client side machine is also MacOS-X - 10.7. But in my mac application there was a small error with NSNumberFormatter which when I was changing, Xcode was crashing. So I edited the code in latest Xcode and OSX. And then I made the binary of it and run in MacOS-x - 10.7, its working fine. But the source code is no more opening in Xcode - 4.6.2. Its asking for the latest version of Xcode. My question is will the binary will work fine in older version of OS-X even if it is developed in latest Xcode?
The version of OS X which your application will run on is dictated by the OS X Deployment Target in the project settings. If that is set to support 10.7, then it doesn't matter which version of OS X you built it on: the built application will work on 10.7 and later.
This setting will also set the minimum allowed OS in the Info.plist, so people trying to run the build on earlier OSes will see an alert instead of the app just crashing.
More information on setting the deployment target and building for different OS versions with SDKs is available in the Apple documentation:
https://developer.apple.com/library/mac/documentation/DeveloperTools/Conceptual/cross_development/Configuring/configuring.html
When I create a new OS X application project, I noticed many target options those confuse me quite a lot:
(1) The top-left setting of Xcode window:
(2) The "Base SDK":
(3) "Deployment Target":
(4) Architectures:
Here comes my questions:
For (2) and (3), I think it was clearer to understand. These are what I comprehend:
(2) This identifies what I develop with.
(3) This identifies what OS version my application will be used on.
Please tell me whether I am right...
But I could not understand (1). I just know that if I select 32-bit here, I could not use ARC.
Neither with (4), what are they? Are they represent the bit-width of the CPU? What was the difference between (1) and (4)?
I'll explain your items out of order.
The Base SDK
This defines the largest set of APIs you can use. You can use anything that existed as of the version number identified here. For example, if you use the 10.8 SDK, you can use -[NSColor CGColor] (introduced in 10.8), but not -[NSData base64EncodedDataWithOptions:] (first public in 10.9).
(Of course, you can also use anything older than that version.)
Accordingly, the SDK version is also known as the “max[imum] allowed” version in the Availability macros.
The SDK version also sometimes becomes important when Apple changes the behavior of an API. When they do that, they sometimes keep the old behavior around for applications linked with older SDKs. This is called an “on-or-after check”, as in “checks whether you're on 10.8 [SDK] or later”. (The concept and term pre-date Xcode having SDKs for each OS version. It used to just go by whatever OS you were running Xcode and building on.)
The Deployment Target
This is the minimum OS version you require. If something was removed in a prior version (rare, but it happens), you can't use it.
This tends to affect link-time and run-time things more than compile-time things. For example, ARC won't work if your deployment target is 10.5 or earlier.
Accordingly, the Deployment Target is also known as the “min[imum] required” version in the Availability macros.
The Info.plist can also specify a minimum OS version. Nowadays, this is set by default and it's set by macro expansion to the Deployment Target.
The Architectures build setting
Different CPUs have different architectures. Essentially, they fit into broad categories, such as:
PowerPC 32-bit (ppc)
PowerPC 64-bit (ppc64)
Intel 32-bit (i386)
Intel 64-bit (x86_64)
ARM 32-bit
ARM 64-bit
(PowerPC architectures aren't supported anymore. You can add them to the Architectures list, as ppc and ppc64, but Xcode will just ignore them.)
Macs nowadays have Intel processors. Almost all Intel Macs have 64-bit processors. You only need to worry about 32-bit Intel if you want to support Macs all the way back to 2006. That's probably more hassle than it's worth.
iOS devices run ARM processors, and most are still 32-bit. The A7 (iPhone 5S, iPad Air, iPad Mini with Retina Display) is 64-bit. But, if you run on an iOS Simulator, it's running on your Mac (it's a Simulator, not an emulator), so it'll target an Intel architecture (formerly always i386, but probably can now be x86_64 if needed).
The “top-left setting of Xcode window”
This is the build scheme and run destination. (Yes, it's two separate things in one pop-up menu. Actually, it's two separate pop-up menus in one control. Try it.)
“My Mac 64-bit” is the run destination. You'll be running the 64-bit version of your app on your Mac, not in an iOS Simulator or on an iOS device. Your choice for a Mac app is merely which architecture you want to run, and they should behave the same (this is, obviously, something you sometimes need to test).
iOS apps have more choices here. Some apps are iPhone-only, some are iPad-only, some are universal, and some may be set to build for both 32-bit and 64-bit architectures. You'll have a Simulator offered for each combination of form factor and architecture (e.g., iPhone Simulator 64-bit) you can run on. You'll also have the option to run your app on any iOS device that's connected and enabled for development (you get this prompt when you plug in the device in Xcode's sight).
TL;DR
Deployment Target is the lowest OS version your app will run on.
Base SDK is the highest OS version you can use stuff from. If it didn't exist yet, it doesn't exist at all for you.
Architectures are the set of hardware your app will run on.
Run Destination is the hardware you're going to run it on from within Xcode.
Just like with most OSes these days you can develop either a 32bit or a 64bit application. The "bitness" refers mostly to how memory addresses are structured (either using 32bit allowing so at most 4GB to address or 64bit (computation left as an exercise to the reader)). However the choosen architecture usually has more implications (like the missing ARC support for 32bit apps) but also how wide CPU registers are, how much memory a structure uses in RAM etc.
OS X also supports socalled fat binaryies that is, a bundle containing both 32bit and 64bit variants of your application. This is however only needed if you normally prefer to run 64bit code, but want your app also to run on OS versions that only support 32bit.
In XCode you can define for what architecture to build your project, either 32bit only, 64bit only or a fat bundle. In the project settings you can set what is allowed and in the top bar in XCode you can quickly switch between the allowed architectures (your questions 1 and 4).
The base SDK determines what you want to use to compile your application. If you select for instance 10.7 you cannot use new APIs that were introduced in 10.8 or 10.9 (which might perfectly be ok if you want your application to run on earlier OS versions only). However if you want to dynamically use new features if they are availble you'd select the latest OS as base SDK and check in code what OS you are running on and only use new features if they are available. It is totally ok to compile an application with access to new features and run it on older systems if you don't use the new APIs there (they are late-bound and hence only crash when you access them the first time and they are not available).
The deployment target determines the minimum OS version your application needs to run properly. This is a runtime check done when the application is started. The OS will refuse to start an application that is made for a later version.
I wrote a Cocoa app on my Mac which is 10.6.6. I sent it to a friend who has 10.5.7 and they got this error:
Cannot open this app with this version of OSX
How can I make my app retrocompatible with minimum 10.4 Tiger ?
Set the Mac OS X Deployment Target in your Target build settings to OS X 10.4. And make sure to not use any 10.5 or 10.6-only APIs without checking for their availability first.
For 10.5 you can set the deployment target to 10.5 and make sure you only use APIs available in 10.5 (you should get warnings for 10.6 only APIs).
For 10.4, you'll probably need to install the 10.4 SDK from the Xcode install and use that SDK. If you have any properties declared, you'll also have to change them to getter/setter pairs and manually implement the getter/setters for synthesized properties.
If at all possible, you should avoid having to support 10.4 because the runtime predates Objective-C 2.0.