|
First, XCode's build system can at times, not always, deliver total interference in platform portability. You are using a tool designed to lock-in to the platform. There is little use for XCodes' huge taxonomy, but for XCode. Second, you don't have to worry; you can quite easily port and maintain a cross-platform solution if you treat Xcode as the third-class tool it is: xcodebuild, and its all you need. Use it to build, only. So, for example, a C++ app which carries along its own well maintained source code, can quite easily be 'plugged in' to an XCode app and delivered on the platform. Fortunately, their fancy features are easily glommed .. at least, for now. Anyway .. The Issue, of course, is API and Framework usage. If you avoid the tweaking of things by Apple, and use known standards bravely (i.e. avoid their candy, "use GL for everything"), you can treat Apples' platforms as a build target, and it works. Take for example: games, game engines, etc. But of course, if you take the Apple Way (tm) and get the hooks into you about their IDE, delivering Apple-only/-specific style Apps with their GUi-based development .. and face it, its quite comfortable right now to just do "Apple-mostly" development .. thats a different story. Xcode requires a bit of push and shove, to maintain different build products. Use it (Xcode, specifically, I mean) only to configure the Build product - which after all, is not a bad thing to also do manually alongside the automated build-server directives .. |