I am building several different video poker apps. One app is the Jacks or Better version of video poker. Others include Deuces Wild, Royal Aces, 10's or Better, etc. I've already built a Royal Aces version and now I want to make a 10's or Better version. Should I be using my Royal Aces project and setting different targets for the other poker versions? Since I will be reusing 95% of of the code, I want a simple way of doing this.
If I should be using a different target for each type of Video Poker app, I'm assuming each target can have it's own: Bundle ID, App Name, etc. This way I can archive each video poker target separately and upload each as a separate binary.
Am I correctly understanding how I can use different targets? Is this the correct way and most efficient way of accomplishing my task?
First note that Apple does tend to frown on having many versions of what appears to be basically the same app, and they may start rejecting your apps after awhile (which can be very frustrating once you've started down that route). You may have much smoother sailing if you bundle your game differences into data (rather than code), and sell them as in-app purchases rather than individual apps (or focus on ad revenue instead, and use the number of games as a differentiator rather than for sales revenue).
That said, it's your app, so let's get back to the question.
Multiple targets is fine, and fairly convenient for this kind of setup. Some things you'll want to do, though:
- First, I strongly recommend a shared xcconfig file so that you don't have to duplicate build settings between your projects. See:
- How can I use .xcconfig files in Xcode 4?
- http://respectthecode.tumblr.com/post/16167385557/xcode-4-and-xcconfig-files
- I have an older (and somewhat dated) tutorial: http://robnapier.net/blog/build-system-1-build-panel-360
- You may want to build your shared code into a static library and link that against the app-specific code. That will save you a lot of compile time when you build all the packages, particularly if there are many of them.
- I would think a lot about testability of your core early on. Testing every version of the game every time you make a change is a royal pain. Automated testing of shared code is a huge win.
I had a requirement for this,
Here is what I came up with.
Have all the logic in static library and all common resources in bundle including storyboard.
Then make your targets depends upon those targets.
Here is
how I did it
http://www.madnikblog.com/blog/2013/09/19/organize-xcode-project-with-multiple-targets/
