I'm writing a project that uses a range of 3rd party iOS libraries (e.g. TWStatus, BSKeyChain), some of which I've modified (up to 10% custom code), but wouldn't be suitable for the original GitHub project.
I thought about future updates from the library authors, and came across CocoaPods today, which looks to be a good dependency manager in the same vein as Bundle or Vundle (for Vim).
I'm curious whether it's possible for my custom code to co-exist with future changes by the library authors using CocoaPods??
CoocaPods by default pulls in a library as source, along with instructions to build that library. (There are some exceptions for close-sourced libs). So this makes it easy to debug issues and test changes out within the context of your project.
Having decided on a change, you should do one of the following:
Submit the change back to the master library. You'll get the benefit of easily being able to upgrade to new versions that include all of the testing provided by the wider community. The easiest way to to do this is to fork the library, apply the change, and send a pull request
If your changes aren't really of benefit to other users of the library, you can just fork the library, without submitting the change back up to master. If the license permits you can maintain a private fork, and still resolve it from CocoaPods. To do this:
Podfile:
#As long as the pod-spec is published at the root of the git repo, this works.
pod 'MyFantasticLib', :git => 'https://github.com/dogue/Doguetastic.git'
#. . and you can use this lib while you're waiting for your pull req. to be approved.
You could also consider setting up a private spec repo.
The first option is usually the best.
So, to be clear.
You've made changes to a dependency
You also want to keep those dependencies up to date.
--
Seems to me this would be a pain. You'd need to merge the new stuff into your own version for every update, for every pod/dependency.
However, if you've made changes... do you really need to? Consider using the adapter or façade pattern to write a wrapper around them, and then you can update them as much as you like (assuming their interface doesn't change).
Just some thoughts
Related
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
I want to know which files created by CocoaPods in a given iOS project should be checked into version control. What makes most sense to include and ignore? Should I just add the Podfile? Or should I add the entire pods directory?
This is an ongoing debate even with the CocoaPods core team. https://github.com/CocoaPods/guides.cocoapods.org/issues/3
At some point someone felt that it should be ignored enough to get it into Github's gitignore template for Objective-C.
Some good points were brought up in the linked debate above about longevity of the project where if you check in your pods directory in the future other developers should always be able to build the source regardless of the state of CocoaPods or the specs repository without any dependency on the command line too. But I could see you having this same issues with Git submodules since the remote repositories could be deleted in the future as well. I think this comes down to your preference. Personally I don't like having updates to external dependencies directly in my source control history.
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.
I'm attempting to use some 3rd party libraries in my iOS app, as recommended by the SoundCloud API. I followed their tutorial, running git submodule add on each of the required dependencies.
However, when compiling, I had to make some tiny tweaks to the dependency projects in order to get them to link correctly - purely in the project settings.
I have never used submodules before, but from what I've heard, the parent repo tracks a particular commit of the submodule, right? If I want to include the little tweaks to the project files of the 3rd party libraries, so that a team member can pull it from origin, does that mean I will have to fork each of the dependencies first and commit each of the little project settings, just so that they can be included in the main repo? Or can I make "local" changes to the 3rd party libraries, and then push the main repo to origin?
This is quite frustrating, since I'm not actually changing the 3rd party libraries per se, it's purely a setting I've had to change so that they work correctly with my specific project. Is there a way I can include tweaks in the main repo without forking each library in their entirety?!
Thanks!!
You will have to put your modifications somewhere so that others can get them. This gives you two options, both of which start with the word "fork".
Fork the repo and maintain it.
Fork the repo and then make your changes so that everyone could benefit from them (eg, make the option you had to change into done sort of configuration parameter), then send a pull request back to the original. After it gets accepted, you can get rid of your fork, and others in your situation won't need to do this dance.
I have an app, it's currently in the app store.
I have an idea for another app, that would share a lot of the same structure as my published app. They're both photo manipulation apps, so the codebase for importing, sharing, saving, rotating, etc. would all be shared between the two. The type of photo manipulation would be different, though.
My thinking is, when I update app #1, I want those changes in app #2, and vice versa.
What is the best way to achieve two apps from one codebase?
Strategies I've contemplated,
One project file, two targets. That way the codebase for both apps will always be up to date, though the project file/directory will be a little messy, to be sure.
Branch the app in git, frequently merge changes between the two branches for the classes used by both.
I'm open to other ideas, too.
I've found people discussing this, but mostly in relation to minor changes... i.e. one app with a few different brandings / data files. My two apps will be reasonably distinct, so I don't think those techniques necessarily apply.
Create a static library with your common photo manipulation or other shared functions, and rework the existing project to add the library as a dependency and use the library's headers folder in the User Header Search Path. Then you can essentially clone your old project and start modifying straight away with access to all of the shared library functions.
Two targets of the same project seems applicable to your situation, though. If you've got a large amount of overlap then you just basically need to write a second UI / workflow for that, right? If yes, using two targets makes a lot of sense.
I suggest split your existing app into TWO parts. Separate out all the common portions as a generic DLL/class library, and use the dll in both your existing and new project.
As the first project development progresses, use the latest version of the dll in your newer project, using appropriate deploy scripts. This way your new project can even be in a seperate codebase
I would suggest you take a look at using git submodules in both your apps. This have worked perfectly for us when sharing code in multiple apps. Basicly we use a structure where we in each Xcode project have a "Components/" folder where we keep submodules.
App A can have the submodules like this:
Components/SomeAmazingPhotoManipulationStuff
Components/MaybeSomeUsefullFoundationThingsYouUseOften
App B might only use:
Components/MaybeSomeUsefullFoundationThingsYouUseOften
The idea here is that you can update your submodule projects seperately and just go into each App where it is used and update submodule to the latest version of the component, successfully sharing stuff between apps without losing version control. It will also scale well to many projects.
And ofcourse you can branch your submodules and have App A use one branch and App B another, if you do some specific stuff or very experimental stuff in one app only or whatever scenario you might think of.
Ever since we started using git submodules like this we have not looked back or even considered any other solution.