Xcode support gem

Not sure if this is a stupid Ideas but I was wondering if we should split out the default build settings and plist bindings into a seperate `xcode-support` gem for Xcodeproj ?

Why?

Right now if you want to work with the latest Xcode you have to have the latest Xcodeproj, this causes problems.

My tool Xcake uses Xcodeproj to generate Project files, if you use an older version of Cocoapods then the Xcodeproj is also an older version this means two things:
- I’ve had to write code to ensure certain build settings are included for example the optimization levels for swift. Without this the project file created optimises swift for debug configurations, since this was only added in Xcodeproj 1.1
- The project file ends up being in XML due to the bindings to Xcode not working. Again I’ve had to work around this by using another gem to convert it.

The only way around this is to upgrade my CocoaPods version to 1.0 and thus uses the new Xcodeproj however I can’t do this just yet due to all the changes I need to absorb which has forced me to add these workarounds into Xcake directly. Also this wouldn’t help as the build settings I needed are still in master for Xcodeproj, which I’m nervous about using in production.

Having a seperate gem which could have the latest recommended Xcode build settings and the latest bindings for the latest xcode would be awesome. Not only could other Ruby based tools share these. But if I have a project that needs an older version of CocoaPods and Xcodeproj then I could use the latest build settings and have my project still written out in the Plist format even if Xcodeproj itself was written against an older version of Xcode.

This puts less work on me as a user and a tool writer - I can use the most up to date Xcode support by simply upgrading the `xcode-supprot` without having to upgrade my entire toolchain. Xcodeproj is then mainly focused on writing the project file itself and this other gem is focused on the actual default xcode build settings and integration of xcode API (aka the Plist writing).

What do you guys think ?

Start by reviewing Xcodeproj’s existing default build settings, plist bindings, and project-file writing behavior, along with the version-compatibility concerns described in the issue. The proposal needs maintainer agreement on the gem boundary and compatibility goals before implementation; done would mean a separate xcode-support gem meeting those agreed goals.

Written by the indexing model from the issue text.