Sharing classes between Xcode projects - ios

A while ago I developed an iOS application using Xcode that and created a bunch of classes that work together to communicate with a RESTful API. Now I'm creating a second app, totally separate but communicates with the same API. I want to reuse these classes, what is the best way to approach this? Should I be do the via some Version control system? Or should I use an Xcode workspace?
Thanks in advance for any help.

I prefer to create separate Git repository for selected files, and embed this repository as submodule in both projects (old and new one)

In similar situation I done it using XCode Workspace and Static Library.
I added the common classes to a Static Library project and added that to the XCode Workspace.
In my second project I added that Static Library Project.
I have two options there:
Adding that Static Library project to the new project workspace
Adding the static library (.a) project to the new project
I chose the first option because, I can add the other common files to that Static Library and also modify the existing files if needed.

As Midhun and yourself mentioned, the best way to do it us by making a workspace and adding your projects to that.
Your shared code can go into a new project that's basically empty and dragged/linked from there into any projects in your workspace.
Changes made to that code from any project will also update the shared code base, which I think is what your ultimate goal was.

Related

How to access one project classes from other project While using multiple project with one Workspace

I am using two different project within one workspace. I have one base(Say Unity-iPhone) project and i drag and drop another iOS project (Say InnerApp). Each file and folder are visible in base project as attached screenshot. I have also added the dependency in build phase of base project, and set the other linker flag and header search path.
Now I want to access the InnerApp classes and storyboard file in base project.
Now My problem is that, I want to launch the Inner App Main.storyboard into base project. But InnerApp classes are not accessible into base project.
Please guide me. Thanks.
You can follow some great step-by-step instructions on how to add static library dependencies while using multiple projects.
Use below urls -
Include one project into another one
Include static libraries into another one

How to create an Xcode project that is not an app but is visible in other projects?

I want to create a project with a handful of categories that add useful functionality to UIKit.
I want to keep this as a separate project so that it can be source-controlled separately (and eventually hosted on github, and downloadable as a dependency via cocoa pods...but let's skip this for now.)
But all the Xcode 6.1 project templates imply an app inside. When I select an empty project it complains about missing base SDK. But this cannot be set without a target present. It is quite confusing. I don't need a target. Do I?
The project should be just a shell for a number of categories + a accompanying summary header file.
I want to be able to drag this project as a subproject to any other proper app project, import the summary header file and expose those categories to the main project.
Any advice?
You need a target. Every source file that should be compiled must be a part of a target.
You could reference each source file from the target(s) in your app's Xcode projects, but that'd be tedious as you'd have to add to every project manually when you add source to your shared repository.
Either create an embedded framework project or a static library. Unless you are really going to share code between an app and an app's extension, go with the static library. It is a lot easier to manage.
Create a project that has a static library target, add the files to that static library.
Then create a workspace that has your static library project and your app(s) project(s) in it. Modify the app targets to link against the static library.

How to share utility class among iOS projects?

Should I create iOS 8 new feature called Frameworks / Extensions to share a simple Utility class used among more projects?
How do you share common application logic? I thought I will just drag a swift textfile in projects without checking Copy items if needed checkmark. Am I doing right?
I found here a promising tutorial with fancy inbuilt animation: http://www.raywenderlich.com/65964/create-a-framework-for-ios
And this youtube video tutorial is useful too: https://www.youtube.com/watch?v=86cPaa3FrRg
You can surely do that about have a common file in a folder and imported in several projects but that doesn't look like a good approach.
What if you start to make breaking changes over time? Some projects can work and others not,
What was the last version that worked for each project?. As is shared changes happens to all project without fine grain control
Would anybody that work in a team with you be able to compile the project? How you share with other people those not copied files necessaries to run the project.
So my answer would be to use a new repo for the shared code and make a framework from it and share the frameworks across projects tracking the version. Or if you prefer use git submodules or git subtree.
Finally, Cocoapods with the new use_frameworks! feature in the 0.36 version solve all these problems for swift (as they did before for Objective-C) making possible do to your our public or private frameworks in swift as you could share static libraries before.

How to import/link shared xCode project (and be able to edit shared project from any client)?

I don't want to compile shared project to any kind of library. I just want to use existing classes like they would integral part of client project.
I want to edit/develop/improve the shared project from any client project that use it.
I've ran trough google, but couldn't find the simpliest/more convenient approach.
More simple:
I want drag and drop shared code project, and be able to edit it anywhere. How?
There are two options: Use a static library, or include the source files directly in your project.
If you don't want to use a static library (which IMHO is the preferred method for iOS and integrates well with Xcode), you could just add references to the shared classes either as file references or as a folder reference.
Either way, the build toolchain will link everything together into one Mach-O binary, which is the only way to deliver code for the iOS.

Xcode: Handling intra project dependencies

Let's suppose that I want to create an Xcode static library.
I use the Xcode provided template for this kind of project "Cocoa Touch Static Library", i want this library in a separate project because:
I want be able to keep this project under git version control
I want to be able to import this static library under other project as a git submodule
Now let's suppose that this library depend on third-part library such as ASIHTTPRequest.
Maybe in my main project (the one that import my static library) i will also depend on the same library. What's the best way to handle this multi-dependecy?
PLUS: Now suppose that i want to create a second static library (this one is more specific for some kind of task and i don't want to mix this code with the code of the previous mentioned static library) but this second static library depend on the after mentioned static library. Again what the best way to handle this
Your question is not super clear, Luca, but let me see if I can help you out a bit.
In one of my own projects, I have a number of embedded (or "sub") projects which get built as libraries included in the main project. So if one file in the sub project changes, both the sub project and the main project pick up the changes.
With Xcode 3, it was a snap to simply drag and import one project into another project and if you have Xcode 3 installed, I highly recommend using Xcode 3 to embed one project into another.
Xcode 4 does handle projects already embedded within another project (like what you might have created using Xcode 3), but the ability to actually do the work on it's own is not fully implemented or baked yet (in other words: it does not work well or at all). Here's another question somebody else asked with more information that might help you.
Also, I noticed this other related question.
Does this information help you out?

Resources