I am developing several libraries that I plan on utilizing in a series of Mac and iOS apps. I want input on what the best tool is to share the code between projects. The two options I am considering are frameworks and Git submodules.
Here is the relevant information:
1. I am personally developing all of the libraries. I don't work on a team.
2. These libraries will provide code relating to UI and cloud service integration.
3. Once the libraries are written, I don't plan on updating them often unless they break.
It seems that Git submodules provide better control for managing which versions of an app reference which versions of a library. However, frameworks might be easier to integrate into an Xcode project.
Frameworks are mostly useful to protect your sources. If it's for your own company, the impact is limited. It can help to make things more clear etc, but doesn't bring any advantage over just using a subproject for example.
In any case I would use git submodules because it's the clean way to do things.
Framework is a way to distribute same code to third party clients while Submodules is a way to manage GIT repos, so not a lot of intersection there.
But, in my experience Framework are much cleaner than submodules because then there is a single source of truth for any N clients while submodules is something you need to copy to every new repo creating code duplication
Related
Scenario. A team has 5 developers and all developers are working independantly on 4 different projects. iOS / OS X. A library has been created which encompasses multiple subclasses, categories and so on for reuse. Each member in this team needs to be able to use this library for each project. The library itself has it's own git repo. When someone makes a change to the library it is handled the same way a standard project is handled and a merge is completed.
Problem I see with this approach...
1. This doesn't seem like common practice for a proper Xcode / Git workflow and I feel a framework or similar would be a better tactic.
2. Although this is great for sharing I can also see this as an issue since one issue with the library will break all existing projects.
3. Adding classes to this library requires each project to be updated to include the new headers.
4. Directory structure can differ on each machine therefore a simple clone of a repo will not work as expected without folder modification.
What is the best way to handle your own library of classes in a Xcode / team environment of multiple users?
If you must have a single library for all this - you can go two ways:
Nobody changes the library, the library is as it is and everyone just pulls it down and then makes changes in their code to make-up for the shortcomings they find in the library.
Everyone changes the library, but the project has A master branch, a stage branch, and a branch for every single project associated with it. Devs change and update their respective project branch, and another person (perhaps one of the project devs maintains the flow from the multipe dev to the single stage to the single master branch). With this approach, it requires much more management but you can slowly improve the main library without potentially breaking other projects as everyone has their own specific know-to-work version of the library in a branch specific to their project, only re-syncing with the master when safe.
I am looking for the best way to share a "common" Xcode project amongst multiple developers on multiple apps. One developer will be working on the "common" Xcode project, while another developer will be working on a project that will use the source from the common code Xcode project.
Where I am stuck is how to set this up with both Xcode and Git so that when the developer of the common code library makes a change, the developer that uses that library will not have delete and re-add the Xcode project, or lose their work.
I have looked at some documentation with Git submodules, but there is a lot of debate around the topic and its usefulness. Are we better off just having one Repository with ALL the code for all the projects in it, that way everyone checks-in/out of the same place?
Thanks for the advice and pointers!
There is no "best-way" in software development. There are always a number of solutions to any problem. The trick is working out which solution best fits you. Int his case there are a number of factors to consider - how your developers like to work, what sort of experience and back grounds they have, how you want to manage the code, etc.
I think there are a few solutions you need to consider. Pick one and try it out, but don't be afraid to change if you find it doesn't work or hack it around to suite your needs.
One repo. Not usually considered the best solution because it restricts the ability to reuse code on other projects. In XCode you tend to end up with numerous build targets and highly complex builds. This can become un-manageable quite quickly. Also tends to make versioning difficult and can break things quite fast.
Multiple repos and static libraries. There are a number of variations on this. The repos can be managed by Git independently or you can employ submodules. I would seriously consider breaking code out into projects that build static libraries. Using XCode workspaces you can have a number of projects open at the same time and arrange them as either siblings or nested child projects. This depends greatly on what and how you want to build them. Using Git submodules has the advantage that the submodules are effectively versioned which means that make changes to a static library project is not going to break everything that is using. The downside of using Git submodules is that they (IMHO) are not the most user friendly part of Git and take some getting used to. A good Git client is most useful in this. Sourcetree is free, but (again IMHO) Tower is easier to use and handles submodules better than Sourcetree.
Using Cocoapods. Cocoapods is like using Maven or Ant for Xcode. It an makes things quick and easy to get running and automatically handles dependencies. However it also messes with the XCode project files, often requires manual intervention, adds additional compilations that you may not require and depending on how you setup your builds, can get in the way. Figuring out how to control the way it plays with your project files can also take some time. A lot of people like Cocoapods because it's initially easy to use and doesn't require the technical knowledge that Git Submodules require. Personally I'm not sure that bringing Java dependency management ideas into Xcode is a good idea in the long run.
The way we share common projects/libraries is through the use of private Cocoapods. Its not pure git, but cocoapods do use git. You can read the official documentation on how to set up a private podspec repo : http://guides.cocoapods.org/making/private-cocoapods.html
There are also loads of possibly simpler explanations on how to set up a private podspec repo like this one
The scenario is as follows. I am working at a company that started out with one iOS application. Now, the company is interested in creating a second iOS application, that shares much of the same code base. The original application was not written with the intention of being reusable, as it was not known at the time that a second similar application would be created. In future, there may be even more similar applications that build on the existing code base.
We are trying to determine the "best" option with respect to how we maintain the source code going forward. So some of the options we're contemplating include single repository with shared library, one repository for shared library and one repository that contains all of the iOS applications, one repository for shared library and one repository per iOS application, etc etc. There's also the question of whether to use git submodules or not if using multiple repositories etcetera.
Currently, the two applications + library are all in one git repository. One of the advantages of this is that a developer can checkout a commit of the single repository and expect the product to build, without having to worry about updating multiple repositories. Basically, the developer doesn't have to be concerned with multiple repositories needing to move in lockstep with one another or requiring some specific combination of repositories commits for a build to work. The developer also doesn't have to worry about cases where another developer may have remembered to commit one repository, but not the other.
Here are some more things I've considered:
Submodules
I've used submodules before, but am no expert. My understanding is that the "super" repository containing a submodule also stores a reference to a specific commit of the submodule. This partly deals with ensuring that multiple repositories (i.e. application + library) would move in lockstep, though I'm guessing there are still issues with needing to manually pull changes from the sub module. Also, issues with a submodule commit not being available to pull if a developer happens to forget to push its changes and it is referred to by the super repository.
One nice aspect of submodules is that it creates a stronger semantic separation between the library and the applications which happen to use the library. Whether this is useful in practice, I'm not sure.
Single repository
As previously stated, this is what we're currently doing. Two applications + shared library code all in one repository. The greatest concern has been around the relatively non-existent ability to isolate changes between project one and two and the library. E.g. someone makes changes to both some library code and some application code in a single commit. Then, another developer just wants the changes in the library code.
One nice aspect of single repository is that everything moves in lockstep - nobody has to worry about keeping multiple repository versions matched. If using XCode workspaces, refactorings are even possible across the two applications.
Branching
Another option is to use some kind of branching model, either in a single or multiple repositories, to manage the code.
Ultimately, we're just trying to figure out a good model going forward for managing two or more iOS applications plus shared library code. Whether this be achieved via multiple repositories, submodules, branching models, or something else. Any general suggestions on the pros and cons of the various options?
Use submodules. You don't need to be an expert because they are really easy to use. Especially when combined with a GUI like SourceTree. I had the exact same scenario as you and that is what I did. SourceTree will even warn you if you are trying to commit a repo that has uncommited changes in a submodule.
A single repository is ludicrous. That would mean that every time someone new wanted to download a project, they would have to download them all.
Branching is going to turn out to be too complicated with making bug fixes that apply to all relevant branches.
The structure I have for my current project is:
Project repo (For the project I am personally working on)
-Project base repo (For shared code between team members)
--Utilities repo (For code that is reusable in any project)
Cocoapods, they make managing related code between applications simple.
We had a similar base for a suite of apps and initially it was a huge pain to manage but once you get custom cocoapods running you will never look back. You should check out this for a starting guide on managing your own cocoapods.
It's free, it's powerful and you will wonder why you never used them sooner.
xcode project under version control. multiple developers work on it. when adding 3rd party frameworks i prefere to keep them outside the git repo.
so whats the best practice when it comes to adding a framework (i.e. facebookSDK) to the project?
currently frameworks are "referenced". this way i have a relative path pointing outside my git repo in project.pbxproj...fail.
pretty confident that the answer is straight forward/simple and actually easy to find in the web, but it seems like i'm asking google the wrong questions...
thx.
AFAIK, there are basically two ways to be absolutely sure that a given commit uses a known version of a framework.
Commit the built framework into your repository. This is the common approach.
Use submodules to reference a repository that houses builds of the framework. You'll probably have to create and maintain such a repository yourself.
Option 2 has the benefit of keeping your repository small, but is more hassle, particularly since submodules are something of a pain to work with.
I have an app that I've been using to develop some ideas that now seem to belong into a reusable framework (a lib). The whole thing is in a local git repo. I've lots of classes that belong to a lib and a some other classes that use them and present views for testing.
I want to move out the test code and leave a library and a separate app for testing. Have you done this? Do you have stumbled into something specific? Any advise?
Of course I could just move everything piecewise into different projects but I'd like to evolve the thing so I don't lose my GIT history and everything is seamless..
If you are going to develop libraries, use submodules or subtrees. Subtrees is a contribution project to git. Submodules come with it out of the box. Check http://progit.org/book for more info on submodules.