So, the tact I'm going to take with my customers who inquire/complain is
the
straightforward one: my development environment won't be ready until later
in the year to build universals.  Why? Because Apple didn't even let them
know such a change was imminent until June(?) 2005, and substantial
changes
are necessary "under the hood". If they make a fuss, I'll just remind them
that Apple probably worked on xCode for a long time (years? I have no
idea)
before making the Intel announcement.  So, it's just not reasonable to
expect products built in environments other than xCode to be ready yet.
And
if they say I should be using xCode, I'll tell them another painful truth:
if I wasn't using RB, there simply wouldn't be a Mac version.

Work has been done on an Intel version of Xcode (i.e. OpenStep) since before
it was called Xcode or owned by Apple. This Intel transition goes back to
NeXT shipping NextStep for x86 around the time Apple was working on moving
to PPC.

While it seems popular to blame RS for this, I have to say Apple deserves
the blame. They should have let development tool vendors know all along that
a future transition to x86 was possible. They always knew this, they've been
building and testing OS X (and Xcode) internally for x86 with every release.
Metrowerks wouldn't have sold off their x86 compilers, effectively killing
that product for the Mac, and RB would have been ready a long time ago, had
this been widely known. I'm sure there are plenty of PPC assembler and
AltiVec developers who are more than a bit ticked over this as well. How
would you like to spend a few months optimizing your code for PPC, only to
find out it's worthless? (I almost did on one project.)

While I'm not worried too much about waiting for UB this year, the merging
of API and developer tools in both the Microsoft and Apple lines makes me
nervous. At least with Microsoft there will be some big names screaming
anti-competition if they close off their API's to 3rd parties or make late
announcements. Not so sure about Apple. Apple needs to announce runtime
changes far in advance of implementing them, so that other tools (what few
are left) can be ready, not play the PR game while developers make unsafe
assumptions about the future of the Mac OS runtime.

Daniel L. Taylor
Taylor Design
Computer Consulting & Software Development
[EMAIL PROTECTED]
www.taylor-design.com


_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Reply via email to