I have an existing xCode project for an iPhone application which is in the App Store. The project contains many view controllers/view XIB files/images/etc. I wish to create another project which behaves in the same exact way containing the same controllers/views/images/etc except i wish to change small things such as the bundle identifier or changing a value of a preproc. defined variable.
I do not want to duplicate the existing project. if i need to make changes to 1 i will need to make the same changes to all others(what if i had 500+ projects? nightmare!)
What do you advise when creating such a new project?
Should i recreate the source of the existing project into a more easily distributed/shareable project so that it can be used in multiple projects? How would i go about doing this?
What kinds of files cannot be shared while creating a codebase like this(which files need to be created or be hand coded for every new project)?
I have a similar scenario and how I handle it is as follows:
1) the core code of the app is kept in a "application_name-base" folder
2) different clients/apps are in their "application_name-client_name" folder
3) in the "base" folder the core source code is all kept.
4) the project file is in the client folder and includes the references from the base folder without using copy.
5) files that need to be unique to the a specific client's project are in the client folder. Usually images using the same name. or .h/.m files that need to be unique to the individual project. (e.g. logo.large.png) Also allows for you to not include .h/.m files on a project by project basis.
6) any centralized update in the "base" folder code will be reflected in the "client" projects on their next build.
Keeps code central but allows for different code per client without leading to confusion.
Related
I want to add a sqlite database in my app and all tutorials says to add the files to the Resources folder. The issue is that i don't have a Resources folder in xCode 4. So is the a replacement for the folder? (I only need reed rights.)
Dragging your sqlite database file into the project navigation tree of your Xcode project should be enough to have it copied into your application in the build stage. It does not matter if your files are grouped under a common 'Resources' group or not.
That said, you can create groups by right clicking on the project navigation tree and selecting 'New Group'. It is common to have most application resources (sqlite dbs, images, etc) grouped together as a way to keep them organized and separate from source code, but it's not a requirement whatsoever.
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 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 run into a bit of a dilemma.
I'm considering making a lite version of my app that will be for free but will run on iAds. The Lite version will therefore have different .xib files because I have to make room for those iAds.
So what's better, should I just make some more .xib files in my project and then somehow programmatically load them. Or should I just create a completely new project (copy & paste
my old directory) and create the lite version?
Definitely don't fork it. You will regret it big time down the road as you'll have to merge virtually every commit across projects. (And XIB files can't be merged...)
I don't even know if you necessarily need to create additional XIB files. You could probably just conditionally resize/hide the necessary views in code. But even if you have to create additional XIB files, it doesn't compare to the pain you'll go through from forking.
Just create a different target within the same project. You can include different combinations of xib and source files within each target, and use some #ifdef's in your source code to limit features or functionality in the Lite version of the target by using a preprocessor define in the Lite target Build settings.
I have two apps which share a lot of source, so I want to put them into one Xcode project and use Targets to build them seperately. Some of the source files have the same name in both projects (for example, MapViewController.h and MapViewController.m). I thought as an intermediate step, I'd just put the whole classes folder into the merged project (with a different folder name) and use Targets to specify which classes folder to use, then later I'd properly merge what I could into common source files.
The problem I found is that I can't include .h files in a Target (the option is greyed out). Do I need to use the same interface file for both Targets and have two versions of the implementation files. Is there a better way to do this? Thanks.
If your going to have two apps with similar naming conventions, with shared code... I'd recommend using the following approach.
Create 3 Xcode projects.
Project 1: Core Code (shared code,
resources)
Project 2: App 1 (import Project 1
and create a dependency on it)
Project 3: App 2 (import Project 1
and create a dependency on it)
Now, every time you change Project 1, both your other projects will be affected.
I've created a project the way you want to right now... And in the long run i've greatly regretted it.