What if we just wanted to share a little bit of code?
What if we where extremely lazy and didn’t want to learn about XCode 4 workspaces?
What if we didn’t want to create and maintain static libraries?
What if we wanted a solution that’s not even scalable, but does the trick while we bide our time?
And finally, what if we had a bunch of similar products based on a budding ‘framework’. Then we might decide to be evil, and dump all of our products in the same XCode project. Yay.
I decided to have a try. Until I hire another programmer, every day of my life is a Sunday. I found that cloning targets is easy, and just a little fiddling will take us from cloning targets to cloning apps and mutating them into something new.
Creating new targets isn’t hard, but then we have all these files we want to add to the new target. That should be easy as pie, but it’s not.
You can try this on a Saturday too, unless you’re working overtime.
1. Duplicating targets
(right click on an existing target, select ‘duplicate’ and follow the signposts).
If two products (an existing one and a new one we’re about to make) are rather similar, duplicating targets may be the fastest way to setup the new product. It doesn’t duplicate any code or resource. Initially both targets use exactly the same stuff. To ‘fork’ a new product, we then duplicate the resources that ‘aren’t the same’.
The big advantage of this approach is that all existing resources are added to the target right away. So this approach is easy if somebody bothers defining a ‘product template’ that contain little / no product specific stuff.
But first and foremost…
We don’t want the same info.plist, right?
Correct. If we use the same info.plist, we can still have two different products on the desktop, but we won’t have different products in-store. A lot of the meta-data distinguishing a ‘product’ (something users can eventually download) from another is the metadata in the plist.
The fastest way I found to actually clone the plist file is to do it from the desktop (sigh) and adjust the Info.plist File setting in Build settings.
Why my ‘target names’ don’t update in the build selection drop-down? Why do I still see an entry there after deleting a target?
At this point I had created, deleted and renamed several targets. My ‘build selection drop-down’ ignored whatever name change or deletion I carried out.
After a few minutes of deep anxiety, I realized that the build thingy doesn’t directly relate to targets. At the bottom of the drop-down thing XCode 4 shows 3 options: Edit Scheme, Add Scheme, Manage Schemes.
- After deleting targets, delete the associated schemes (go to ‘manage schemes’).
- After renaming targets, delete all schemes (go to ‘manage schemes’) then press the top right button (‘auto create schemes now’).
2. Setting up a new target
Setting up a new target and adding resources to it is the slower, meaner way to (loosely speaking) ‘clone an existing product’:
- Go to File > New > New Target.
- Choose Window-based application (or whatever you please)
- Select a product name and fill in the company id.
- Leave ‘include Unit Tests’ checked (no need to be THAT evil)
- Press finish.
The sad point here is that no existing files are included in the new target (other than the boiler plate generated by the wizard) and XCode 4 doesn’t provide much of a nice, quick and easy way to add all these files we want to share across targets. We can select several files at once and edit their target setting in the file inspector, but we can only do this for files that belong to the same group.
3. to share or not to share…
There are several types of resources we might want to share across products:
- Code
- Frameworks
- XIB files
- Data files
- Image files
- …
If you use the ‘target clone’ method, at some point you definitely want to introduce these classes that make your app what it is (a new app! with some resources and code borrowed from the old one). Then comes the ‘forking’ question:
- Do the targets use the same MainWindow.xib?
- Do they use the same app delegate
- …
If the two targets use a different xib as entry point, it’s easy to fork (because the xib is listed in the info.plist, and surely the info.plist is forked).
Otherwise, the quick and dirty way is to use homonyms. So we may have two ‘MyAppDelegate’ classes (same name, different folder); and we associate one with each target. IMHO this is really evil, but it’s like chocolate. A tiny bit won’t hurt.
You could also check PrEV’s Demystifying app startup article. Knowing more about app startup can help us resolve certain questions pedantically.
I also found a post about renaming projects. I kinda managed it before, but maybe the post is useful.
Conclusion
Maintaining several apps in the same XCode project is possible. It doesn’t mean it’s a good idea. Learning how to do it is a moderately fun way to learn about targets in XCode.
Comments