I'm trying to create a new pod (Cocoapod) for an iOS library and have followed the tutorial instructions at https://guides.cocoapods.org/making/using-pod-lib-create. I currently don't have a remote repo, but have a local project with git history. After running the pod lib create command (running Cocoapods v.0.37.2), and opening up the resultant project, it looks similar to the example pictured on the above tutorial link:
My questions are:
As I don't have my project hosted remotely (i.e., Github), and referencing the image above, should I use the Example for MyLib part for my remote repo, obviously adding anything else to it that I would need? If so, how should I include my library that I want to make into a pod? I noticed that the example project was initialized as a git repo. Edit: I did see on http://nshipster.com/cocoapods/ that invoking pod try will use the created example project, so I'm guessing I should use the created example project for my remote repo if I want that feature?
Or should I configure my pre-existing MyLib project with the newly created podspec file, etc, and push that to my remote repo, following the instructions at https://guides.cocoapods.org/making/making-a-cocoapod.html?
Under "Making a Demo Application" on the pod lib create tutorial link it's stated:
"The template will generate an Xcode project for your library. This means you don't have to go through creating a new project in Xcode.
If you want to have an example project for pod try MyLib or need to have your library's tests run inside an application ( interaction tests, custom fonts, etc ) then you should say yes. A good metric is "Should this Pod include a screenshot?"; if so, then you should have a demo."
Thanks!
After doing more research and trying a few things out, I ended up going with my first option: using the example project created by the pod lib create command. From consulting numerous sources and tutorials, I found this one to be the most accurate and helpful in this process (at least at the time of this being written): "Your First CocoaPod".
Specifically, the line:
Add the Demo/Pods folder, which includes all the pods installed from pod install, to .gitignore.
addressed one of my concerns about what to do with the Pods folder. After that, I was able to push my example project to my remote repo, and then ultimately to publish my pod. In summary, it appears I could have either used the pod lib create command to create my example project, or generated a podspec file manually to be used with my pre-existing library that contained a sample project.
Related
My iOS project includes some private pods. I have gone through the steps on my local machine (as well as team members) to use private pods outlined here.
How do I add the same process for VS App Center to update and retrieve the repo?
Currently, I get this in the build output:
[command]/usr/local/bin/pod install --repo-update
Updating local specs repositories
Cloning spec repo fooBar from git#github.com:fooBar/Podspec.git
[!] Unable to add a source with url git#github.fooBar/Podspec.git named fooBar.
You can try adding it manually in ~/.cocoapods/repos or via pod repo add.
[error]/usr/local/bin/pod failed with return code: 1
[error]The 'pod' command failed with error: /usr/local/bin/pod failed with return code: 1
Recently I was trying the same and it looks like it's impossible to achieve what you want in way you want.
TL;DR:
Use Carthage for your private dependencies and GIT LFS to store compiled dependency frameworks.
I've used GIT LFS to store Carthage/Build directory (that's actually all you need to compile your app).
I'm still using Cocoapods in my project to maintain public dependencies (somehow it's required in my project).
Why this way?
Because I've found this in AppCenter's docs:
Is your app fairly simple, without many customizations, and is the build pretty straightforward?
In App Center, if your app follows the usual standard layout on the respective platform and does not rely on a lot of external build steps, App Center finds the app automatically in your repository and builds it right away.
(see: Choose the right service for app builds)
So I realised that I really should use the simplest way to build the app on AppCenter. Hope that helps, even thought the answer came after such a long time :)
I am using some framework which are integrated with pods . So I want to ask is this good approach to sync these framework on gitHub . For example . In my iOS project I have integrated GoogleMap framework, Should I sync this on Github or i should some reference . I am asking this because When i commit this framework it give me memory issues.
I'd say there's no "best approach" about what should be ignored concerning your pods dependencies.
One would say that it's better to ignore the pods directory to keep your git repository light, but for someone else would say that your pods dependencies are part and parcel of your app, it won't build without it, so you must commit it.
First I chose to include all my pods in my git repo, but I quickly noted that it could be very annoying, given that each time you update one of your dependencies it blows yp your updated commit files list. Now I just include my Podfile and Podfile.lock files and ignore the Pods repository. Just make sure to run pod install each time you pull from the repo.
The main benefit of including all your Pods is to have your project "ready to build", without the need to have CocoaPods installed on your computer to build it first.
For more details, see this related question :
What goes into your .gitignore if you're using CocoaPods?
I'm having my own cocoapod which is wrapper to C++ library, so it can't be used without having per-architect shared library. I'd prefer to add *.a in the project that is using this cocoapod so cocoapod obviously fails at linking while linting. How can i push podspec to my private repo skipping lint?
When I need to do that I perform the following steps:
Open the CocoaPods script file with a text editor:
❯ atom /Library/Ruby/Gems/2.0.0/gems/cocoapods-trunk-1.2.0/lib/pod/command/trunk/push.rb
Comment the validating line:
Try to publish the pod again.
Don't forget to undo the change. If the project maintainers do not add a flag for this, they have their reasons.
Since no answers were done I assume it's impossible or it's not a good practice. So I've created common repo directories structures in repo, copied PodSpec file and committed/pushed it. After that I was able to use it just like it was pushed using pod repo push ...
I have an Swift project that utilizes two libraries: the SQLite and SwiftCSV project. They can be found on: https://github.com/stephencelis/SQLite.swift and https://github.com/naoty/SwiftCSV respectively. I followed the instructions on each respective Github README to incorporate the projects into my project which works fine, but when I push my project to Github and I have another teammate of mine clone the project, the SwiftCSV and SQLite projects turn up empty so my teammate has to re-add them into his project. I have been trying to google different responses but maybe I am looking for the wrong keywords. Any ideas on how to fix this?
You should (and may be) adding the above projects to your repo as submodules (if not, read up on them).
If you used submodules, they are not automatically checked out when you clone a repository. You can, however, use clone's --recursive flag to ensure submodules are checked out when someone first clones your project:
git clone --recursive git#github.com:your/project.git
If the project has already been cloned, one can check out the submodules by running the following incantation from within their project directory:
git submodule update --init
Note: Xcode is usually smart about letting you check out submodules from within Xcode itself. Check the Source Control menu and see if SQLite.swift or SwiftCSV show up under Working Copies.
If you merely downloaded the projects and dragged them into your Xcode project (rather than use submodules, as instructed above), they'll likely be referencing directories outside of your project. Make sure you move them to your project's directory before dragging them into your Xcode project. If you don't, the projects will appear red/unavailable on subsequent clones.
usually, xcodeproj is in gitignore, please remove it from .gitignore file
In Xcode 5 I am developing a universal iOS app - on three different Mac OS machines (on which I happen to have different usernames too - "admin", "alex", etc.)
My project uses the SDWebImage library through CocoaPods and I plan to add few more later.
I would like to keep my project in a Git-repository on GitHub or BitBucket.
I'm confused: which files of my project should I check in into the git repository.
Especially I wonder about 2 groups of files:
The CocoaPods-related (currently I've only checked in the Podfile and Podfile.lock, but there are also Pods.xconfig and Pods, etc.)
And the Xcode-related (should I check in the Workspace Settings? What to do with User Data - admin - ...?)
Here is the screenshot of the commit dialog:
When I run git clean -n -d in my project dir, I see the following:
Would remove Podfile.lock
Would remove Words.xcodeproj/xcuserdata/
Would remove Words.xcworkspace/
And my Podfile contains the following:
platform :ios, '6.0'
pod 'SDWebImage'
UPDATE:
I use a .gitignore containing xcuserdata, but for some reason still see the User Data files in the commit dialog:
This is a bit of a matter of taste and requirements for your projects. There are two schools:
Never check in generated code. Put your xcworkspace, Podfile.lock and Pods folder in .gitignore and never commit them. Instruct developers on your code base to run pod install directly after checkout. This is my preferred choice, and should work fine as long as your pod dependencies point to a specific version or a range of compatible versions.
Check the workspace, lock file and Pods directory into Git with the rest of your code. This is a guarantee that all developers on the project are using the exact same code when they build. Even if your third party dependency removes their code from the Internet, your project is still buildable. However, you now have a lot of source code that is unrelated to your own, version controlled together with your own.
As an aside: you should probably always put "xcuserdata" in your gitignore, maybe even your system-wide git ignore, because other users of your code are probably not interested in your personal Xcode settings.