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.
Related
Thanks for spending time reading my question.
I've been working as an iOS developer for more than 2 years and today I still feel shame because I don't know how to deal with frameworks. I've build some projects using my own frameworks, but I've never understood exactly what's the best practice doing this.
Lets see the following example:
Project -> FrameworkA -> AFNetworking - Charts - FMDB - more
So, I have a big FrameworkA with mostly all the app behavior and then a small project referencing this FrameworkA and customizing just icons, texts and images. I use to manage dependencies with CocoaPods and I would like to use it with FrameworkA. By this I could reference external libraries easily, but it seems it doesn't work for frameworks, only for projects. So, my questions is: how can I add AFNetworking, Charts, FMDB, etc to my FrameworkA and then reference the framework form my project?
I appreciate if you can give me some idea using CocoaPods or any other dependency manager. I don't like the old way by doing this manually.
I hope my case is clear.
Thanks!
It sounds like you are asking how to embed external frameworks such as AFNetworking into a framework you are developing, and then use that framework in your app.
This is what's known as embedded frameworks where one framework is stored within another. Generally speaking it's not a great idea and should be avoided because it can cause version clash issues.
The way I'd recommend doing this is to use CocoaPods or Carthage to link the external frameworks (AFNetworking, etc) into your framework project. But do to try to embedded them.
Then in your app project, again use CocoaPods or Carthage to link in your framework (you won't need to link the external ones unless you are directly using them in the app code). Then add the necessary build steps to copy both your framework file and all the external framework files to the finished app's framework directory.
I have seen various libraries on GitHub that look useful, but only list CocoaPods as an install method. I'm not sure I want to be dependent on CocoaPods, because I'm wary of Apple breaking it in some future OS X/Xcode update. Is there a way to get these libraries into my Xcode project without using CocoaPods?
Role of CocoaPods is to automate and simplify the process, but you don't need to use CocoaPods if you don't want to.
In case of "manual installation", usually it would be:
download the project from GitHub
add the files to Xcode
import headers
But there is no universal recipe for every project, it may slightly differ from case to case, but usually it boils down to previously mentioned.
The best way if you don't want to use CocoaPods is to read the project documentation, and study examples if there are any.
Of course there is. Basically you need to download the library project, drag the project into your own project, do some library dependency setup and you're done.
For details, check out https://github.com/Alamofire/Alamofire for manually adding a Swift library. And https://github.com/jverkoey/ObjQREncoder for manually adding a Objective-C library to your project.
The only way to install things without Cocoapods is to just drag the source code of other projects into your class. For example, most Github projects can be installed via Cocoapods, or you can just drag the relevant source code into your projects. You don't need to drag in all of the project resources, all you need is usually class files
I'm completely new to iOS development and coming from an Android background. I was starting to look at what alternatives are out there for dependency management in iOS and found out that CocoaPods seems to be the most prevalent option.
After reading a lot of links about this topic I'm kinda at a loss and wondering what is the usual way dependencies are handled in iOS.
I have two questions:
1) What would the equivalent of using gradle to generate library (.aar) projects be in iOS? If there's any equivalent option. From what I've seen one can wrap static libraries and headers into frameworks and these can be used in other apps, is this the standard way to do it?
2) If (1) is correct, does CocoaPods offer a mechanism to add frameworks as dependencies?
I don't have a Android background but from what I understand of .aar files CocoaPods does something very similar. CocoaPods uses .podspec files (described here) to generate static libraries (and soon dynamic frameworks which are new in iOS 8) that are then linked into your project.
A podspec can define source files, assets, libraries, or frameworks that a source vendors for linking into your application. So yes it does support adding frameworks as dependencies, although until iOS 8 frameworks were not supported at all on iOS.
As far as the 'standard' way to do it, I think that's based on opinion. There are a few general ways to include dependencies you can choose from.
Drag files, frameworks, and whatever else you need into your project manually. Updating these is more difficult and that also means you have to configure your .xcodeproj depending on what features that library needs (such as ARC)
Drag a provided .xcodeproj into your project, and link the relevant target from the given project. This can be nice if the library provides a project that can build a framework or static library, in this case you'd pull in that library but their project would handle custom compiler flags.
Do either of the above while including them as git submodules. Assuming nothing massive changes in the project this helps a lot with updating your dependencies.
Use CocoaPods. CocoaPods will handle all the custom linking and updates based on semantic versioning (usually).
Use Carthage. Carthage is an in- between CocoaPods and the .xcodeproj solution. It will download code based on semantic versions defined by git tags, then you drag the generated frameworks into your project.
All of these options have pros and cons and the decision normally comes down to how you feel about the control you have over the inclusion of the library, and how automated you want it to be.
I do not have android nor iOS background however I've been developing a CI tool for both platforms and here are the answers
As You mentioned this a framework and pods (libraries) from cocoapods are distributed that way. For instance, have a look at Apphance. When spec is clicked it's visible that this library will be accessible as a Apphance-Production.framework.
You add pods to Podfile and download them with pod install command. This command will made classes from Apphance accessible from the code. Some people do commit downloaded pods, other not (it's like adding jars or aars to source control).
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.
I am working together with some friends on a iOS project.
We are using CocoaPods for integrating third-party code (Facebook-iOS-SDK, ..) and sync the whole Xcode workspace (including the Pods Project) with Git and bitbucket.
Everything works perfect and we are very happy with this setup.
The only problem is, that we have to build a second application and the two apps will share a lot of common code.
Does it make sense to just add a second target to the workspace or is it better to create a private pod?
Other possibilities? We want't to keep things as simple as possible...