On Jun 11, 2008, at 1:06 PM, Sherm Pendley wrote:
1. The more users can run your app, the more potential customers
you have.
2. The more users can run your app, the fewer e-mails you get
asking "why
can't I run this app?"
I fail to see the relevance of these points. Obviously, my goal is to
reach the maximum number of users; if it were otherwise I wouldn't be
discussing the means by which I reach them.
It's quite simple - there are still a bunch of users out there running
Panther, so if I target Panther, I can reach those users. If I target
Tiger or Leopard, I don't. Thus, I can reach more users by targeting
Panther - at least for the time being, until I decide that their
numbers are small enough that they become no longer sufficiently
numerous to make it worth the effort of supporting Panther (which,
truth be told, may happen fairly soon as I'm getting weary of all the
hacks I have to use to support 10.3.x).
3. Relying on deprecated methods can cause an instant headache if
Apple ever
decides to remove those methods (or if they eventually start
requiring you
to compile for 64-bit or something).
If I had suggested using deprecated methods *forever*, you might have
a point. But I didn't suggest that. I only use deprecated methods if I
need to support an OS version for which they're not deprecated. That's
precisely the point of deprecation; it gives developers time to
transition away from the deprecated methods, instead of requiring us
to do so immediately.
In practice, I have yet to have had a problem with this - by the time
a deprecated method is actually removed, the OS version for which I
needed it has always fallen "off the radar" for other reasons (Cocoa
Bindings, Core Data, etc.) anyway. Obviously, there are no guarantees
of this, but in eight years of Mac OS X programming I've never been
bitten by an exception.
This is Apple we're talking about - they like to keep you on your
toes. All the deprecated stuff has already been removed from the 64-
bit headers - all it takes is for Apple to release an OS that either
requires all apps to be 64-bit or requires 64-bit to take advantage of
whatever new feature you've just gotta have in Cocoa, or whatever.
Apple is known for axing things suddenly and without warning (hi 64-
bit Carbon developers!), so it's best to be prepared.
4. Sometimes a method gets deprecated because its replacement has
better
performance or has some other advantage that can make your app
better if you
use it.
If the advantage is significant, I simply bump up the OS version
requirement.
Sometimes the advantage is significant, but not so much that the app
isn't still usable without it. I would rather leave it out for the
users of the old OS version so they can still use the app, but that
doesn't mean the users on a more recent OS version should miss out on
the advantages you could offer with the new feature.
5. Sometimes a new method allows me to add a cool new feature that
wasn't
possible on older OS versions without a lot of work, but this
feature isn't
so important that the app isn't useful without it. In this case, I
can just
implement the feature on the current OS, and it gracefully degrades
on older
OS versions (maybe a menu item is greyed out or something).
How is that a meaningful difference? If an OS feature is
mission-critical, the app will be useless regardless of how it
communicates the fact of its uselessness to the user.
The whole point is that sometimes the feature *isn't* mission-
critical, but still really nice to have, although the app is still
usable without it.
Besides, if my app requires 10.4, I'll make that abundantly clear on
its download page. I don't think there's anything graceful about
making someone download an app and try to run it before telling them
that they can't.
I don't think you're understanding what I'm saying. What I mean by
"gracefully degrade" is that the app STILL DOES RUN on the older OS
version, but just without that one feature. Perhaps the menu item to
choose that feature is greyed out, perhaps it works but relies on an
older implementation. Whatever; the app still runs.
If you require a later OS version, of course you mention that on the
web page. It's not much consolation to the user who can't run your
app, though.
Of course, this is for when an existing class gets some new methods
that I
like or something. I of course wouldn't use something huge like
CoreData and
then try to target 10.3, as that would just be silly.
Such huge additions are actually the reason I arrived at my position.
They tend to be the main drivers of my adoption of newer SDKs and OS
versions, to the point where I've simply stopped worrying about minor
additions and deprecated methods. By the time a deprecated method such
as -cString actually disappears, I will have long since switched to a
newer SDK for other reasons anyway, and updated my code to suit that
SDK.
Yeah, the thing is, I've got existing code that doesn't use those huge
additions because it was originally written for an older OS, so it's
not married to those huge new additions. Therefore, I don't have to
drop old versions until it becomes too much of a headache to keep
supporting them (too many hacks to have to apply to get it to work,
too many weak-links and workarounds, too difficult to find beta
testers still using the old system).
Can we end this discussion, please? It's horribly off topic.
Charles
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
