I have a project A. This produces a product that's working and already submitted to the app store etc. Now, I'd like to create a new project, let's call it project B, and I want B to be based on A. Obviously B will add more UI and behavior on top of A.
After doing some research, the only option seems to be using cross-project referencing, because I'd like to reuse Project A's XIBs, images etc in Project B. Am I correct in assuming that cross-project referencing should work in that scenario?
Well I'm having some serious problems in getting this thing working. I'd like to achieve project level reuse. In Java or in .NET this wouldn't even be a consideration, the technology allows that. Because iPhone doesn't support frameworks, I think the developers are pushed towards more primitive approaches like code duplication.
So, how can I tackle this problem. How can I create my Project B, based on Project A (including XIBs, images, etc)?
Thanks,
If A and B are so similar perhaps you could consider simply creating a new build target; this would give you a single project with target A and target B. Both targets would have access to any of the resources in the project.
If you have a fair bit of shared code then you can create a static library; iOS doesn't support dynamic linking to user-generated libraries, but it supports static linking just fine. This would make the cross-project dependencies useful, because you could have project B reference library A from project A and build it as a dependency.
I did this same thing at one point:
I copied and pasted the entire app and then had two separate apps that I could work on individually.
Contrary to popular opinion, it is possible to create iOS frameworks.
Maybe you could use a scm tool like Git or Piston (http://piston.rubyforge.org) and 'clone' the code. Do something like:
#add original project to git
cd /your/base/project/code
git init
git add . #Stages all files to check-in index
git commit -m 'Your commit message here'
Then
#clone the original project into a new one
cd /your/new/project/directory
git clone /your/base/project/code
git checkout -b aNewWorkingBranchName #create a new working branch to modify
#modify code to your <3's content, use git pull/push/merge/rebase/diff as required to track/update original project
This should let you develop the 'new' project independently, while allowing you to pull in changes when required. Piston allows 'vendor' branching against both Git or Subversion repositories, tying your new code to a particular remote revision. Have a look at its documentation.
Related
Im not an expert at git, but I have a iOS project that has code that I would like to reuse. I will be switching out images and a little data to make each application different. I know you can do this with the targets approach but I wanted to keep everything seperate and out of the original xcode project. So my question is, do I create a branch for each new project, and if so what is the correct terminology or command to grab bug updates from the original code base into my new branch from the main branch? The new branch will never commit back to the master branch also.
I strongly suggest you make different repository for each project, not different branch.
If you have one repository for several projects and for each project different branch, very soon you'll have a mess in your repo.
Also, if you fix a bug on part of code which you want to reuse, you'll need to merge the fix with all branches which use that code.
So, I think the better and much cleaner approach would be to create different repositories for each project, and code which you want to reuse you can add as a git submodule.
So, you'll have repository for your iPhone project then submodule for your shared library, Restkit, and so on...
You will want to review the git branching section of the online reference at GIT-SCM. At a high level you will want to look at merging the various branches. Xcode 5/5.0.1 helps you immensely by using the menu Source Control > Working Copy > Project Name > New, Switch, or Select Merge Into/From Options...
I am trying to release a custom view that utilizes WEPopoverController as well as UIButton+Glossy but I don't know how I should add their code to my git repository. Should I submodule it?
Here is the UIView if anyone is interested:
Of course you could add them as submodules so it boils down to more of a personal opinion.
In my opinion submodules are overused. I would use it only to in a case where I want to break a specific project into smaller projects. So let's say I have a large project but a specific part of it can be usefull by itself. In that case I could create a submodule so people that is only intersted in that part can fork/clone it.
In your case where you are only using it in your app the best way is probably to copy the files into your repo, not using submodules. In that case It may be a good idea to add them to a vendor folder just to make it clear that it's part of a separate project you are using here.
Let's say that in the future the project gets updated and breaks the API or cause other problems. You better have a static version of the file you have tested with your application than leaving it open for anyone to update the submodule to a version of those libraries that might be not supported by your application.
I have a library containing a few classes. Now I want to split up this library into two separate libraries. What is the correct/best way to handle this in combination with source control?
My initial thought is to create a new repository for each new project and in the initial commit mention that it was split of from a now unmaintained project.
While I only have a few commits so far, an issue with this method is that the history of the project is lost.
It depends on which version control you are using. For instance, in git you can use filter-branch to do the trick.
You can make a copy of the original repository, then use git filter-branch to keep the history of the part you are interested in and dropping everything else.
$ git filter-branch --subdirectory-filter mydir1
$ git gc --aggressive
$ git prune
Beware this is destructive. You will see a considerable reduction of the repository size, only having the history of mydir1 and removing all those unreachable objects.
Then, repeat the same for other libraries/subdirectories. In that way, you will keep only the history that belongs to each part/library/directory.
If you are using a different version control system, then you have to figure out the equivalent way to do it.
The rule of thumb I follow depends on whether you will be developing and/or deploying the libraries independently. If you are separating the libraries simply for code organization and the code is deployed as a single solution, then there is no need or benefit to creating separate repositories.
On the other hand, if you will be versioning and releasing the libraries independently, then having the code in separate repositories helps this. So, for instance, if you are separating the code because some of it belongs in a share framework, then put the framework code in its own repository. This will allow you to maintain, build and release the framework separate from any applications that are built using the framework.
HTH
you can create a new repository but also you can create new projects under the same repository and delete the old one in time. actually, that's up to you. if you see the previous project as test level or pre-alpha stage, you may want to create a new repository. but other than that, using the same repository is very likely for this situation.
The situation:
I have a basic app with some central functionality.
My clients (potentially many dozens) all want their own customized apps in the app store.
The problem
If I have dozens of apps in the app store and I want to change some of the core functionality, I would have to update each file in the corresponding project, compile, go through iTunes Connect, upload etc. Every small change could potentially take days of mindless work.
The question
Is there a way I can use a versioning system like git to administer the parts of my code with the core functionality separately, so that all projects are updated automatically when I commit a change to the core files?
Is there any other way to make this process easier to manage?
Typically if you have some core functionality that you need to reuse in iOS you'll either create a static library that you can include in your other projects or (if the core functionality includes things like assets which can't be included in a static library) you'll have a sub-project. In both cases, though, you'll want to make sure each of your app projects has a target dependency with your core functionality project so it is always rebuilt with the latest changes.
Create a MundiCoreFramework xcode project that has all your core functionality and which compiles without having to reference client-specific code
Create a git repo for this core framework project
In each of your app projects that use this core functionality, add the MundiCoreFramework as a git submodule and add it as a subproject to the app project.
Whenever you update the core framework you can issues git sumodule update for each app and recompile.
I'm not real familiar with the Xcode "target" structure, so that may in fact be a better approach. But you can definitely use git for this.
Probably you want a "master" branch where all the universal stuff lives, then a branch for each "customized" version of the app.
When there are changes in the master, you'll merge those changes through each of the custom branches. Then from each branch, you'll build a product to submit to the store.
In each branch, you'll separately set the app id, whatever art and text changes are needed from one version to the next, whatever key setup is appropriate to this version, etc. All those settings can stay local to the custom version branch.
This is a perfectly valid workflow in git. It's not how most people use it, but that's because most people are headed to ONE production product, not many.
Another option might be using git submodules to organize common code, and then have each individual project simply add your common code as a submodule.
You can use Target to customize the app for each client, this would mean that you could keep one code base and have multiple apps with the same code base.
This will not solve the updating the app in the appstore part, which you would still have to do by hand as var as I'm aware of.
I've found a really good tutorial on "Easy, Modular Code Sharing Across iPhone Apps: Static Libraries and Cross-Project References"
Now I need to understand if my approach can work.
Suppose I have my "main" project with all the assets I need (View Controllers, Delegates, etc.).
Now I create a new project and simply add a reference to every file I need from the first project; of course I DON'T select the "copy if needed" option.
In this way do I build a new project with all the assets from my main project?
If I change the code in the main project, this change will be reflected to all the referencig projects?
Is this an easier way to share code between projects?
Thanks.
Since I keep all my code under version control, the way I do it is to have modular code as Git repositories. That way, to add common code, or chunks of functionality to my project I just need to add these as submodules.
The advantages of this are:
Common code is kept in one place, versioned and backed up.
Having small repositories for code that does just one thing encourages writing modular code with minimal dependencies.
Submodules are added to a repository at a particular revision. So, if you change your common codebase, these changes are not automatically applied to the clones - you have to explicitly pull in changes. That way, if you accidentally change something that could break one of your projects, it won't appear suddenly.
If you set up your submodules properly, you can make changes to the common code from within one of your projects that can be pushed to all other repositories. That way you can work locally.
Your entire project is in a repository, without references to other projects, so you can move them, save them, archive and restore them without worrying about where the references point to.