On Apr 2, 2006, at 5:33 PM, Phil Faber wrote: On 29 Mar 2006, at 22:14, Clark Cox wrote: Because that's the way it's supposed to work. If you want to target an old version of the OS, you use the SDK that corresponds to that version. If you use the 10.4 SDK, you are telling Xcode, "I only care about running my app on versions of the OS greater than or equal to 10.4".
So if a project CAN successfully compile under 10.2.8 SDK (which presumably means it will usually successfully run in 10.2.8 and above), is it always better to do this so that your program can run on more users' machines? Or is there a downside to doing this?
You can always pretend to go 100% back into the past, but if you limit yourself to only using 10.2 features you are giving up on a lot of available features.
Many times there are new features in the various APIs that can be selectively adopted to add glitz and glamour to your application on newer releases, while preserving functionality on older releases. Sure, you may not be as likely to selectively adopt major architectural shifts like bindings or CoreData, but other features that spring to mind, along with likely backup plans for older system compatibility:
10.3+ Use NSShadow to add depth to UI elements. 10.2 - Use less flashy shadow-free UI elements.
10.3+ Use kqueues to offer instantaneous reflection of file system changes to users. 10.2 - Use less desirable polling techniques or check for file system changes in response to user actions.
10.4+ Use CoreImage to provide a huge number of built in image processing features to users. 10.3 - Use a few built-in image processing features.
10.4+ Use Quartz Composer to do flashy transition animations. 10.3 - Use home-grown or more boring system animations.
The list goes on. You can be safe by adopting a "10.2 only" SDK, but you do so at the expense of adopting all the whiz-bang technologies that have been added to the system since then.
Daniel
|