Re: Weak link
Re: Weak link
- Subject: Re: Weak link
- From: Laurence Harris <email@hidden>
- Date: Thu, 25 Oct 2007 16:18:23 -0400
On Oct 25, 2007, at 6:59 AM, Markus Hitter wrote:
Am 25.10.2007 um 06:58 schrieb Laurence Harris:
On Oct 24, 2007, at 3:42 PM, Chen Wang wrote:
Which SDK version are you compiling against?
Hi Greg, the project is built against to MacOSX10.2.8.sdk.
May I ask why?
A few reasons I could imagine:
- 10.2 has all the features needed.
If 10.2 offers all the functionality you need and you can test
against 10.2, 10.3, 10.4, and 10.5, then supporting all of those is a
noble and reasonable thing to do. It's pretty rare, however, for none
of the latter three of these versions of Mac OS X to offer anything
one could use to improve the look, feel, and usability of an
application.
- Making a single user happy by simply choosing another SDK is
worth the one-minute-effort.
If you're writing this product for one user, I'd agree. But
supporting 10.2 in addition to later versions of the OS requires more
than just changing an SDK. That user isn't going to be happy just
because he can launch your application in 10.2. It will need to work
and do so reliably, and it would be foolish to assume that will
happen just because it will launch in 10.2 and runs correctly in
10.4. The reverse is true as well. You should never assume that
because your application is free of problems in one version of Mac OS
X that it will be free of problems in a future major release.
- If a feature doesn't work as one thinks, this triggers some
people to investigate/learn the feature instead of dropping it.
If a feature doesn't work correctly in 10.2 but has been fixed in a
later release of Mac OS X (especially if it was fixed in 10.3), I
think there are better uses for one's time at this point than
investigating workarounds only needed in 10.2, and sometimes there
aren't any workarounds. For example, Carbon introduced drawers and
composited windows in 10.2. Drawers have to be composited, and
DataBrowser wasn't compatible with composited windows until 10.3.
Upshot? There's no way to use a DataBrowser in a drawer in 10.2.
There are also situations where a single API or a setting in IB in
one version of the OS replaces pages of code needed in previous
versions. For example, layouts specified in IB aren't supported until
10.3, and layout information let's you specify what happens to the
contents of a window when it's resized. Doing this manually in 10.2
requires a fair bit of code that's not needed in 10.3+.
Every application is different, of course, and the simpler an
application is the less likely this situation is to arise, but given
how much changes in each major release of Mac OS X, it wouldn't be
hard to find such a situation after two or more major releases.
- You can recommend, test and support 10.4+ but allow for 10.2
anyways. See above.
I don't really know what you mean by "allow for 10.2," but any
definition that doesn't involve testing in and supporting 10.2 seems
inconsistent with professional development practices. Based on my
experiences supporting 10.1 and later, I would even go so far as to
call it foolish. If you allow an application to launch in 10.2 and it
has significant 10.2-specific issues, how does that benefit anyone?
And if you don't test it in 10.2, how can you know it won't have
significant issues? Users will be frustrated and you will look bad
for releasing something that doesn't work correctly and isn't
supported. And frankly, if your application doesn't use anything
introduced after 10.2, it's very likely that you're missing an
opportunity to make your application more appealing to users of later
versions of Mac OS X, and those are the users more likely to be
buying software.
Just my $0.02.
Larry
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden