However I would like to point out one perhaps historical oddity (although any time I use that phrase I expect to be proven wrong): while the class of idea that does not require custom fabrication of hardware has gotten larger (i.e. more ideas do not require hardware), which might suggest that hardware and OSes and platforms and such have been commoditized, this commoditization is not happening. I feel like that tension — more people wanting to create software only products, but at the same time, not having a sane, stable base upon which to build — is at the center of a lot of what mobile developers are experiencing.

To sustain your life for the long run, you have to tune out all the junk and ask yourself what really makes you happy.

http://www.griffincaprio.com/blog/2011/03/the-secret-of-entrepreneur-zen-ness.html

In any case, getting wind of the build locations as long as you choose to store them inside the build folder in each project isn’t rocket science. It’s ./build/$buildconfiguration[-$deviceplatformtarget]. Where the location is when you store them in the derived data location, I don’t know, but Xcode 4 is AppleScriptable and you can go ask a workspace document for its current product directory. Also, the Internet! http://stackoverflow.com/questions/6098315/xcode4-reliably-detect-the-deriveddata-directory-of-a-project-workspace

The way I solve screen real estate, besides having a bigger screen, is to make use of tabs to set up nice working conditions; one for IB work (inspector visible, navigator hidden), one for source editing (navigator hidden, assistant split) etc. I tried opening up an iPad storyboard document and even a 17” screen starts looking pretty titchy, so this problem probably won’t go away over time. At least you can zoom out there.

The problem schemes are trying to solve is best described by Chris Espinosa in one of them Xcode 4 talks: he talks about how the Xcode 3 target/arch/platform/device/everything picker controls every single axis in the build matrix, but how only some of those combinations make sense. The idea behind a scheme is simply to have one for every combination that makes sense.

Because you can build (or test) multiple targets per scheme, that “combination” doesn’t have to limit itself to one each per target. You don’t have to add phony targets to “build all”, just make a new scheme. (A good unorthodox example is xscreensaver, which has one target per screensaver; it could now have one scheme for the core code, one for the tester application and one for “build every screensaver”.)

No argument on Core Data. I’m not using it yet, but everything I’ve seen on the subject agrees with you.

But that said:

Your scripting all sounds really doable with Xcode 4. (And I do NOT mean driven from Xcode, but rather driven from the shell.) I used to have a script that updates version numbers and built all the combinations I need, for instance. Xcode 4 does have the hooks to copy the files I need from the build folder to a more reasonable place, which your script could pick up on. I haven’t done this yet because I rarely add want to keep builds, and I’ve been copying files manually around for this since Xcode 3.2. The hooks to do this automatically are actually new in 4.0.

Configurations and schemes are something I had problems with for a long time. Here’s how I came to understand it now: Schemes describe a group of common things you want to do. You can’t add or remove things, but you can change how each of the things works. Configurations are how the executables for these actions are built. If you wanted to, you could create a Debug and Release scheme. The Debug scheme could use the Debug configuration for everything. The Release scheme could use the Release configuration for everything. You could switch between the schemes just as easily as you could switch between configurations in Xcode 3.3. This would essentially give you Xcode 3.3 behaviour in Xcode 4.0. Using schemes well is much better than the old way.

Even though you are stuck cooperating with people using Xcode 3.3, and I think you could write scripts that would handle both Xcode 3.3 and 4.0 at once. Add a post build script to your Xcode project to copy the builds and symbols from where they’re generated to within your source tree. Not the intermediaries, just the stuff you’re actually interested in. Modify your script to pick up the files from there instead of the Xcode 3.3 locations.

When you want to move forward, ask questions and get answers. The most important thing to realize is this: There are answers.

Also, you rightly point out that HgHub might want to do things differently from GitHub (doing everything the same being bad). How would each difference in how Bitbucket does things not be this, and therefore not disqualify Bitbucket from being “HgHub”?