Currently I have an iPhone app that is just one large project. It has hundreds of code files. I have one folder called "Helper" that includes all of my classes that I have created. I'm going to be making a second app that also needs to use the exact same code that is in the "Helper" folder.
What is the proper way to share that "Helper" code between two projects/apps? Should I put it in its own project file and then add both the main app + "Helper" to a common workspace? I'm not interested in making static libraries or anything... I just want the code segregated somehow.
I've already tried making a second "blank" project file and dragging the code into it, but when I try to build Xcode just thinks I am missing header files now... for some reason it's not seeing the code in the other project.
It would be ideal if there were a clean distinction between the shared code and the code unique to your current app. If there isn't yet, try to make sure everything that will be shared is not dependent on anything from the code unique to the project.
One way you could accomplish this is by using a Git Repo and then making the shared code its own repo project. Then, in the repo for both projects, include the helper code as a submodule.
I've worked with projects that use submodules, though I haven't set up the submodule aspect myself as of yet. The benefit here is that any changes you make to "helper" can be pulled into the both projects, so the changes are synchronized.
If you aren't familiar with Git yet, I recommend getting familiar. Setting up a Git repo on your computer, even if you aren't collaborating with others, is pretty useful. XCode currently offers the option of setting up a repo when you create your project. If you haven't done that, or aren't sure though, you can still create a repo after the fact.
I use source tree to manage my repositories. Creating a repo is pretty straightforward and easy from there SourceTree. However, you can use GitHub's own desktop client, or any other client if you wish - depending on how you set up your project.
Some information about setting up a submodule in git: Setting up a submodule
So, to recap:
Make sure your "helper" code can stand on its own
Put the helper code into its own repo
Include the helper repo as a submodule to any project you want the code in.
Hope that helps!
It sounds to me the situation you have described is exactly what a framework is designed to solve. What you would likely end up doing is creating another project with all of your shared code within it and creating a framework which your applications could link against.
I would suggest reading Apple's Framework Programming Guide. From the introduction to the guide:
Mac OS X makes extensive use of frameworks to distribute shared code and resources, such as the interfaces to the system itself. You can create frameworks of your own to provide shared code and resources to one or more of your company’s applications. You can also create frameworks containing class libraries or add-on modules with the intention of distributing them to other developers.
You can put the shared code in a separate folder and then add it to the both projects.
But don't forget to add the path of the folder to the User Header Search Paths in Build Settings > Search Paths.
I'm not interested in making static libraries or anything...
Yet, for iOS, a static library target is exactly what you'd use.
No workspace required, just a separate Xcode project with that shared static library, which both apps reference.
Related
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).
Situation:
I need several swf/exe output files compiled in FlashDevelop from several projects. More than 60% of ActionScript 3.0 source is common for all project, rest are project-specific. How can I organize that in FlashDevelop? I want to have "one-click-to-build all" setting without duplicating common codebase (so when I need to fix something I do not need to copy-paste solution into several files).
All sources are under develeopment and will change very often.
A straightforward solution is to make an external classpath, for instance:
c:\dev\shared_src\
c:\dev\project1\
c:\dev\project2\
Then configure each project:
Project Properties > Classpath
Add Classpath > select '../shared_src'
PS: of course you should keep everything under source control.
Using svn:externals you could structure your repository in such a way that the commom parts are stored just once in the source control system, so changes made can be synchronised with just a single commit and update cycle.
For example, imagine that you have ^/ProjectA and ^/ProjectB, each of with require ^/Common as a sub directory.
Using svn:externals, pull ^/Common into both projects.
The exact nature of doing this will depend on the version of svn you use, and any client you use (such as TortoiseSvn). Refer to the relevant edition of the svn book for specifics.
The ease of implementing this will depend quite a lot on how separate the common code currently is in your application; and pulling in directories as directories is much more practical than trying to pull them into an existing directory; and unfortunately wildcards for filepaths are not supported.
However, based on your description of your aim; this is the most straight-forward solution I can imagine.
Hope this helps.
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 an iPhone/iPad app that I want to port to MacOSX. Most of my objective C classes should work just fine as long as they do not contain UIKit stuff. Obviously the interface will be different.
What is the best way to do this in Xcode? Start a completely new project? Add a new target? How can I keep the different platforms in sync? Should I just use git with multiple branches?
I've had difficulty setting up a unified project with different targets for the two OS types, so I generally split this into two projects that share source files.
For an application that will be targeted Mac and iOS, I tend to create one directory for the application. I place the two projects within this, and set up one directory for shared source files, one for iOS-specific stuff, and a third for Mac-specific stuff. This way, you might have different projects, but shared files will update between them as they are changed. The only time you manually have to sync the two is when a new shared file is added to the application and must be added to both projects independently.
You should be able to restructure your existing project to support this without much trouble.
You can also simply add the files from one project as references to the other one. Simply drag them from the source project (where the actual files reside) into the other project. The dialog will ask you whether you want to copy the files. Choose no. This will make the second project point to the files in the first project. Edits go into both projects.
Be careful with this, though, as there are a few differences between APIs in iOS and MacOS, even if they are called the same.
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.