Re: Why has the Metrowerks sign been taken down?



>>> Apple could stand to improve their good will within the developer community.
>
>> They could indeed. Developer relations (and for that matter, user
>> relations) are not as good as they could be.
>
> At the WWDC Keynote SJ noted there were more developers than in some time,
> like 10 years. I can't recall exactly what he said..

I do, but frankly, so what? There are a lot more people using Windows
than Mac OS X. Obviously big numbers don't mean squat.

> Saying developers don't like Apple doesn't make sense when there are more of
> them...

Indeed, if that's what he'd said it wouldn't make sense, but that isn't
what he said. It's not a matter of "liking" Apple. It's a matter of how
people feel they're being treated. People don't develop Mac software
because they like Apple, they do it because they think there's a market
there worth pursuing and/or because the Mac is the platform they
prefer. This is analogous to the fact that I use CW, but not because I
like MW.

> Sure the number of complaints go up when there are more developers (fact of
> life), but you're not basing these statements on any facts I can find.

Each of us has his own take on this issue, but I for one have been very
frustrated since the introduction of Mac OS X on multiple fronts:

- Documentation: Apple dumped a major new OS on us virtually
undocumented. The state of documentation is getting better as time goes
on, but it is still far from ideal and it used to be all but
non-existent for much of what was new in Mac OS X. (Case in point: Take
a look at Tech Note 2078:

http://developer.apple.com/technotes/tn2002/tn2078.html

This tech note, dated May 2003, didn't exist when I needed the
information it contains. Of course, this should be obvious since I
wrote TN2078.)

Even now, some five years after the introduction of Mac OS X, new
developers still struggle with the documentation. Some basic APIs still
have no documentation, and documentation is spread out over web pages,
PDF files, header files, tech notes, Q&As, and sample code, often
without cross referencing. Inadequate and difficult-to-access
documentation wastes our time and increases our frustration.

- Stability. I started with Mac OS X in 10.1 and I have consistently
found Mac OS X to have more problems than I believe it should have.
(Thank goodness I didn't bother trying to write for the second public
beta, aka Mac OS X 10.0.) Not that I expect perfection, but more often
than I care to remember I've written code to use a technology or
feature I haven't used before, only to find out it didn't work. I've
lost count of all the times someone has posted a question to Apple's
carbon-dev list only to find out that some API or feature just plain
doesn't work. For example, if you read the HIToolbox release notes for
10.3.5, you'll see that there were two Nav Services APIs that were
nothing but stub functions from 10.0 until they were finally written
for 10.3.5 (and this primarily because I had brought them up on the
carbon-dev list). It's obvious to me (and confirmed to me by people
that have been at Apple) that Apple does not adequately test Mac OS X.
How many versions of the Mac OS prior to Mac OS X had eight and nine
bug-fix releases? This has been a huge time sink hole for me and other
developers I know, and it's largely the result of Apple's unwillingness
to hire adequate QA engineering staff. "Write lots of code fast and let
developers tell us when stuff doesn't work" seems to be Apple's policy
since Mac OS X came out, and I don't appreciate it because it has made
me consistently less productive over the past four years, and reduced
productivity translates directly into reduced revenues. Thank you
Apple. Glad iPod sales are going so well.

- Interface Builder. Ugh. A great tool in concept, and it's useable,
but Apple has really dropped the ball with IB. I didn't start using IB
until Panther, but when I did I found lots of consistently reproducible
bugs and odd limitations (for example, it can't import menus from
'MENU' resources). I filed Radar after Radar (well over a dozen)
against the bugs and glaring limitations and Apple never released a
single update for the Panther version of IB. More of my time wasted,
this time because some bean counter at Apple decided IB didn't warrant
the resources needed to address its many issues.

- Tech support. Technical support incidents used to cost $50. Maybe
Apple could see DTS being overwhelmed due to the above problems, but
for whatever reason, technical support incidents now cost $195. Skimp
on documentation, give us more bugs to work around, and quadruple the
costs of getting serious help. Thank you Apple.

- Transitions. I ported to Carbon. I ported to Mac OS X (which is,
sorry to say, not the same thing). I converted to .strings files and
nibs, to FSRefs and Unicode, from Pascal strings to CFStrings. Now I'll
have to switch to Xcode and do whatever is necessary to support Intel
processors. Some of us are tired of transitions. They require time and
resources that more often than not don't translate to readily apparent
improvements in products. For example, I switched from 'STR#' resources
to .strings files. Do you really think my English users (the majority
of my customers) really care?

The biggest single thing I'd like to see Apple do is start respecting
our time by giving us more documentation, an OS that works more
reliably when we write code for it, and well thought out tools that
work reliably. As long as they're too cheap to do those things, then
no, I'm not going to be happy with them.

Larry

.



Relevant Pages

  • Re: Missing Features in Excel 2008!?
    ... Come on now you mean to tell me that MS puts as much money and effort in MacBU as other portions of their company. ... I don't care of it is UNIX, Linux, Mac or even windows/DOS. ... Far from being forced to have "as few a developers as possible", MacBU has spent a significant fraction of the last few years trying to hire more competent Mac developers. ... And of course, if Apple were to fail, ALL Mac software developers will rather quickly shut down. ...
    (microsoft.public.mac.office.excel)
  • Re: Missing Features in Excel 2008!?
    ... is based my *readings* of MacUser MacWorld, and Mac Addict over the years. ... Come on now you mean to tell me that MS puts as much money and effort in MacBU as other portions of their company. ... Far from being forced to have "as few a developers as possible", MacBU has spent a significant fraction of the last few years trying to hire more competent Mac developers. ... And of course, if Apple were to fail, ALL Mac software developers will rather quickly shut down. ...
    (microsoft.public.mac.office.excel)
  • Re: PC vs Mac
    ... That's the Apple approach. ... discourages outside developers and makes it harder to integrate outside ... I wish my PC was as secure and user friendly as my Mac. ... Since I'm committed to supporting both Macs and PCs, ...
    (sci.lang.japan)
  • Re: Why has the Metrowerks sign been taken down?
    ... > web about how apps are already compiling and working with Mac OS X ... > to do it because of the documentation. ... - Large developers like Adobe and Microsoft have direct access to help ... of Apple engineers who contribute to those lists. ...
    (comp.sys.mac.programmer.codewarrior)
  • Re: Mac Mini?
    ... the Macintosh memory could not be upgraded with a simple ... > "Toolbox" documentation. ... > I have watched in amusement and some amazement over the years as Apple ... I can still run semi-modern software on my ancient Mac SE. ...
    (comp.sys.mac.system)

Loading