I have an iPhone app, and I'm taking a few features of the app and creating a new app.
What's the appropriate way to build two apps from a common code base?
One more option nobody seems to have mentioned yet - you can create a new target in the original project file. I do this for "free" and "paid" versions of the same app, but it'd be useful for any two apps that share most of the same code.
I got this from an Xcode expert:
Xcode has two affordances to do the right thing here:
1) For files outside your project tree that your project requires, set up a source tree. Xcode > Preferences > Source Trees, define a symbolic path (e.g. EXTRA_SOURCES) with the actual path on your disk to where they're checked out. Then when you add those files to your project, add them Relative to Source Tree to that source tree.
(N.B. Quit and restart Xcode after defining the source tree in Prefs.)
2) In Xcode 3.2, define the Project Roots to include the Source Tree. Project > Edit Project Settings > General tab, "Configure Roots & SCM" button. Add the source tree to the Project Roots and set up its repository, which can be a separate repository from your main project files.
That's it. You have one file tree, from one repository, but many projects can share it, and if you perform an SCM operation on the source in one project it's reflected in others.
Ideally you would be able to make a dynamically linked shared library (or "framework" in Apple parlance) from the common code, but the iPhone platform does not support this. In addition to the approaches already suggested here, you can link against your own static libraries.
Building static libraries with the iPhone SDK
Easy, Modular Code Sharing Across iPhone Apps: Static Libraries and Cross-Project References
Keep the common code in a common repository. Then you can easily use it in as many projects as you want.
Related
Together with my team I'm developing multiple native plugins based on Trigger.io. Since the recent changes I'm not completely sure on the workflow and cannot find anything about it in the documentation either. Some questions that arise:
1) Should one set of inspector projects be used for all the plugins or should each plugin has its own set?
2) Which parts of the inspector projects should be maintained via version control, which should remain local? (fyi: we use SVN)
3) (Android) When using one inspector project for each plugin, whats the best way to import them all as Java projects in Eclipse? Note: each inspector project has 3 sub projects which have the same name across different plugins, so they'd have to renamed? Assuming I have 5 plugins in development, that'd mean that I have to import 15 Java projects into Eclipse. Is this really how it's meant to be?
The most effective way to develop plugins is still something we're working on, how things are right now is probably not as good as it could be (especially for developing multiple plugins), but as things are right now:
1) Each plugin should have its own set of inspector projects.
2) The majority of what the Toolkit puts in the plugins folder is probably best in version control. Things you can safely ignore are the .trigger folder and any bin, gen, or build folders in the inspector projects. If you are trying to keep less files in version control the things you definitely need are the assets/src folder in the ForgeInspector, and any of your own source in ForgeModule, the rest of the inspector project should be regenerated by the Toolkit.
3) I'd recommend using an eclipse workspace per plugin, as the Toolkit regenerates a lot of the code when you update the inspector I don't think it is currently possible to rename the projects.
I thought I'd include a quick overview of what the 3 projects are and why there are 3:
ForgeCore - This is the pre-build core library for Trigger.io apps, its used by both ForgeInspector and ForgeModule so it needs to be a separate project that can be referenced by both
ForgeInspector - This is meant to replicate as closely as possible how your plugin will actually be used, so is basically a stripped down Trigger.io app, its separate to ForgeModule so that you can see what code is in your plugin and what code needs to be put into build_steps.json so it will also be applied to a real Trigger.io app at build time.
ForgeModule - This contains your plugin code
I'm developing an iPhone app that can edit images. Ultimately, I want to have a small version that allows the user to simply edit their images, and a large version that allows social networking of the images. Then I'd like to develop a version of each for the iPad.
Being that this is my first foray into commercial mobile development, I'm confused about how to organize all these versions in Xcode. Obviously, there will be file reuse shared between each version. I guess my question is, how do I go about organizing these separate projects in the most efficient way so that they share files and so when I edit a particular file that is shared, the changes are made to each version of the application? Is there some kind of construct to follow in XCode?
Are there any links or literature on how to go about doing this? (was not sure the correct term to search for it).
Remember: If you find yourself repeating/duplicating something, suspect that you're doing it wrong.
Your Xcode project will have 4 targets in this scenario. The basic target layout for this setup looks like this:
A Static Library (for your shared source files)
A Resource Bundle (for your shared resources)
App-Full (Universal)
App-Lite (Universal)
The apps link to the shared static library, and copy the resource bundle.
Naturally, apps will have sources/libraries/dependencies which differ -- those go in the app target (or some other dependency).
Given your background: Plan on it taking a good amount of time (initially and as you go) and patience to figure out how these dependencies should be composed, used, and maintained.
I would suggest keeping the "lite" and "full" projects separate but within the same workspace. That way you can keep the shared files in one project and simply use a shared reference to them in the other. All changes made to the shared files from either project will affect both.
As far as iPhone/iPad versions, I would also suggest that you keep these apps completely separate but within the same workspace (so that they can share code) as well. If you look around about the suggestions for managing both apps in a single project (aka, universal app), the only real benefit is that customers can buy one app and can download it on either device and some may get upset if that isn't available to them. If your app is free, don't worry about it.
Lastly, a caveat about workspaces, you need to uniquely name your files across all projects. For example if you're working with a project that uses a MainViewController.h subclass and another project that uses a MainViewController.h subclass, you could assign or edit the wrong one by accident regardless of what project you're in, so be wary. If using unique file names is a problem, you can bypass using workspaces by simply creating an empty project to dump all of your shared code into and then add references to your standalone apps from there.
If you choose to keep various copies of your project for different functionality, it will be eventually confusing, as there are places when XCode offers you one thing instead of another. One such place is - when you open a project from location X, it will also show you your copy from location Y since you opened it last time. As a result, you are likely to commit more mistakes. Organizer is one more such place where you can make mistakes.
XCode is self-contained enough to maintain both iPhone and iPad versions. You will have two separate storyboards which can be made part of one project if you chose universal as the type of app.
As for various features, you shouldn't be maintaining separate copies of your project. Instead, recommended way is to keep all features within single project, and have app logic provide access to various features.
XCode keeps version of your build under Targets section when you click project. To maintain multiple versions through your dev cycle, use source code repository (git or svn).
How do I reference another project which has code I wish to leverage in XCode 4. In particular I'm trying to make use of the NSDate extensions from here.
Some notes:
I was assuming I should probably reference rather than trying build a framework
I tried copying the existing "Hello World" xcode project file across into my project, however this didn't seem to work
Do I need to create a new "Target" based on "coco touch static library" option?
Then would I need to Edit the current Product Scheme so that when I build the new target would build
What do I need to do on my project side exactly - should going Add Files, and choosing the extensions Xcode Project File be enough?
thanks
I was assuming I should probably reference rather than trying build a framework
yes, reference and link with it, unless you need only a bit of it. at this stage, separating the bits you want may be an advanced topic (depends on the lib's layout/depends as well). you should prefer to reference and link because it will normally minimize your maintenance time, especially if you use it in multiple projects.
I tried copying the existing "Hello World" xcode project file across into my project, however this didn't seem to work
you don't create a project, you add the library's xcode project to your app or library, set the lib as a dependency, add the library to your search paths if needed, then link with the library.
Do I need to create a new "Target" based on "coco touch static library" option?
no
Then would I need to Edit the current Product Scheme so that when I build the new target would build
no. you configure it as a dependency. you may need to alter the lib's build settings if there is a major conflict, which the linker or compiler would point out.
What do I need to do on my project side exactly - should going Add Files, and choosing the extensions Xcode Project File be enough?
start with the process outlined above.
There is no reason to bring in an actually project. Either you can bring in the source files themselves and you could even use the same exact files instead of copying them if you want. However, if you have more than just a few files, and you don't think you will be changing the code much, then creating a static library would probably be the best option.
I have 2 projects and I want to use in the first project, a class (i.e. view controller) of the second. Instead of importing all the files of the second project in the first one, is there a way to link it like a framework or library?
I tried the following unsuccessfully:
Dragged-dropped SecondProject.xcodeproj and checked SecondProject.app as a target
Added it as a dependency project in the first project dependencies
Pointed to the header files by adding in the "Header Search Paths" a path pointing to the second project which I copied in a subfolder of the first project.
When I include "SecondProjectViewController.h" I get no errors but when I try to instantiate it I get the "OBJ C referenced from" error.
Any help is deeply needed and appreciated! =)
F.
As an experienced developer I would suggest not sharing code this way across projects. The simple reason is that changes in one project will then directly effect other projects, often rendering them un-compilable. For example, if you share a controller class and decide to implement a change with a new import, then any project that uses that class will be broken until you open then in xcode and ensure that the imported class is available.
A better method is to compile your first project as a static library or framework. I'd also recommend ensuring that it is version some way. For example, in my projects I create static frameworks and store them in a directory called "v0.0.1", "v0.0.2" etc.
The framework can then be dragged and dropped into a second project to use it. The second project then refers to it via the directory path. The advantage of doing this is that if I then change the first project, the second one if not effected by the changes until I choose to update the frameworks path.
Sharing files between projects will work for small cases, that being 2 or 4 projects, but once you have more than that it rapidly becomes un-manageable.
You have only a few steps to go:
4) in First project, click the disclosure triangle in the Groups and Files section for the Second Project reference. this will display the targets of Second Project.
5) Drag the target reference (e.g., static library) from Second Project to the target in First Project's link phase.
That should clear up all the linker errors for the symbols which exist in Second Project's library. Of course, you'll have to remove those sources (based in second Second) which are compiled and linked from First.
Managing static libraries for huge codebases is dead easy this way (although I prefer the build up to the minute (as well as several build variants), and don't reference archived binaries as Derek does). Learning to minimize changes which break builds takes time to learn. dynamic libraries are a bit different - depending on their distribution, you may want to version (as Derek outlined). It's good to share, but you should put the shared exported symbols in a library, which is a dependency of both apps. Just be careful not to add too much unnecessary objc symbols to the library - objc symbols and their references cannot be stripped from the final executable and they will cause runtime collisions if they appear in two images (dylib, app, static lib) within the same process.
You can add the view controller's files to your 1st project regardless of where they are on disk -- the project will make a reference to their location.
I've build a static library working nice in a Cocoa Touch environment. Now I'd like to compile it also for Cocoa.. Can I have a single XCode project with different sdk targets? Is there some resource out there able to give hints about best the practices in this (and other) sense?
This last two months I have been working on exactly this task ( cross compiling static library for iPhone/Android/Mac OS/Linux/Windows...
It is certainly possible, a nice way, is adding an external xcode project as a target to your first xcode project. So you create a new "Active Configuration" for Mac OS X, iPhone and other platforms that you want to support.
Here, you can find a good tutorial about how to use a secondary Xcode project as a target of your main project to build a static library. It's a cool way because if you debug for example you still have all the symbols of the library, etc.
It can be done but it requires some manual tweaking of the build.
Start with the Xcode Build System Guide.
As an informal way of accomplishing this, you can create two separate projects and add references for exact same set of library source files to each project. Set one project to compile for Cocoa-Touch and the other for Cocoa. If both projects reference the same files, changes made in one project will be automatically reflected in the other. (If you have both projects open, Xcode will complain that the file has been changed by another app but otherwise it won't notice.)
I have a utility class that I continually dump new methods in. I add it to every project and just park methods as I need it. The new methods show up in old projects because the source files are shared across all the projects.