Many thanks for your reply, Niels. What you say makes
a lot of sense, but unfortunately right now I have to
make my purchase decisions based on what I'm going to
make from my program and on how much money I have in
the bank, and as my app will be freeware/shareware and
I'm not a professional programmer, there's no way I
can justify the price of the Select membership or
Transition kit at the moment. That's why I said it was
frustrating but that I'm not complaining - the free
tools and level of support is incredible (and no doubt
the reason for so many good shareware apps on the
Mac), but it is always obviously a cause for concern
when there is a major change coming that you can't
justify testing out.
> Then ask yourself if
> you can afford to have your app not be native while
> you transition
> the code. I certainly wouldn't recommend releasing
a
> Universal
> Binary that hadn't been tested on an Intel Mac.
This is a very good point that I had overlooked. My
best option when the Intel machines come out is indeed
probably to let my app run on Rosetta for a while
until I can test and fix it where necessary on Intel.
Thanks again,
Keith
-------------------------
FROM : Niels Meersschaert
DATE : Wed Jun 08 23:10:23 2005
Keith,
I appreciate your frustration about Core Data, but
it's not as though
the code you spent time working on doesn't work under
Tiger. It's
just that now, there is an easier way to do it that
minimizes your
code base. Unless you want to target only Tiger,
there is no need to
throw that code out & replace it with Core Data.
Apple has generally been good about maintaining
backwards
compatibility between OS X releases. In all
likelihood, your app
should run fine, as you plan to use Cocoa APIs. The
real issue
between Intel & PPC is in endianness, so byte ordering
becomes
important going thru the transition. Unfortunately,
you can't test
that issue without an Intel Mac. The question you
need to ask
yourself is how much of your target audience will be
using the Intel
Macs before you buy one & migrate your code. Then ask
yourself if
you can afford to have your app not be native while
you transition
the code. I certainly wouldn't recommend releasing a
Universal
Binary that hadn't been tested on an Intel Mac.
I tend to determine purchases based on how I value my
time. I'm at
the beginning of a development cycle, but the app I'm
working on will
be CPU & graphics intensive, so it's better to be
native. $999 buys
me the ability to cross-develop before official Intel
macs ship. The
coding decisions I make now will be checked on both
PPC & Intel. I
can save a lot of time if I make a coding assumption
based on PPC
that doesn't work on Intel, since I can notice the
problem while I'm
developing, instead of completing the app & noticing
the problem when
the actual machines ship. While I may not have that
problem, the
$999 buys me peace of mind & a full year's head-start
on porting.
In your case, the Core Data functionality duplicated
much of the code
you spent weeks working on. $500 for a select
membership would have
gotten you early access to Tiger & thus could have
saved you weeks of
work if you wanted to use Core Data & Tiger as minimum
specs. Your
concern about possibly needing to change hundreds of
lines of code a
year or two down the year is a valid one,
unfortunately, it depends
on how you code your app as to what migration
headaches you may
have. Ultimately, you need to decide for yourself how
much you value
your time in determining if the transition kit would
be a better bet
than waiting till the Intel Macs come out. It may be
worth
considering your experience with Core Data in deciding
that.
Good luck,
Niels
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/email@hidden
This email sent to email@hidden
