It's what you don't know that can hurt you
One of the "one step forward, two steps back" part of converting to Xcode is discovering where the assumptions are different.
I understand how CodeWarrior works; I've been using it for 10+ years. Xcode may look (superficially) similar, but deep down, it is radically different.
Here's an example: A default CodeWarrior project contains two targets, named "
See what I mean?
If you're a CodeWarrior user, you're probably thinking "What is he smoking? Of course you do!". But with Xcode, that's not the case. You "deploy" it first. One of the steps in deploying involves running "/usr/bin/strip" on the executable, which removes debugging information that the linker put there. This is a good thing, because this makes your executables _much_ smaller.
[ Thanks to Chris E. for setting me straight on this. ]
Next up - side by side comparison of binaries.
posted by Marshall @ 10:28 AM
2 Comments:
Rather than running /usr/bin/strip directly, just turn on 'Strip Debug Symbols From Binary Files' (aka COPY_PHASE_STRIP) in the Deployment target. Then you can release the deployment build directly.
Go into the Deployment style (project icon -> Get Info -> Styles -> Deployment) and change it there. It's in the collection 'General' -> 'Deployment'.
I believe the templates normally set this up for you automatically. Not sure why yours didn't... did you start with an empty project? Maybe Xcode's default settings for a blank project are a little bit too blank.
Anyway, keep at it. I know it seems frustrating because I've been there too -- one day you're fluent in your work, the next day you're struggling to use the basic tool for your job. It'll come.
My only advice is this: just like any tool, the best user experience comes when you use it exactly in the way its designers intended. Don't try to use it like CodeWarrior: use it like Xcode. Once you grok its capabilities and the best way to use it, Xcode is really flexible. No, it's not perfect, but it's really not bad either. And Apple seems to be committed to carrying it forward and improving it.
Re universal binaries: what I've heard from others is that it really roughly doubles your executable size.
As for how that will affect you personally, it depends on your app. Most apps have a lot of resources these days which mitigates the effect -- you're only duplicating the app code, not the resources.
If your executable takes up 90% of your app bundle then you'll see your app grow by 90%. If you're iMovie and you have a 2MB executable with 50MB of resources, then your executable takes up 3% of the space and you'll see your app grow by 3%. In practice I have seen several developers claim numbers in about the ballpark of 20%, but that number is heavily dependent on the number of resources you have. So that 'average' doesn't necessarily tell you anything about your specific case.
Cocoa apps will grow less because they use an application framework built into the system and thus have smaller binaries. PowerPlant apps start out larger in the first place, and thus grow more, because they generally build a full app framework right into the executable.
Post a Comment
<< Home