I work on a team that is an iOS contractor for a larger company. We are helping the large company build a iOS app with Xcode and we use Cocoapods to manage our dependencies in the project. However, the large company has internal Cocoapods that are hosted behind their firewall that we, the contractors, cannot see or touch. This produces many issues for the developers outside the firewall not the least of which is that 'pod update' and 'pod install' both fail with:
Update all pods
Cloning spec repo `xxx-podName` from `https://xxxx.git`
[!] Unable to add a source with url `https://xxxxx.git` named `xxx-podName`.
You can try adding it manually in `~/.cocoapods/repos` or via `pod repo add`.
Because these repos/pods rarely are changed outside of our project we don't usually need to actually pull down new/updated code from them. Still there are many important side-effects from the 'pod' commands that our team would like to be able to accomplish, such as the re-structuring/regeneration of the workspace and project files along with other the auto-magic processes that occur when 'update' or 'install' are run (such as the building of shell scripts).
Is there a 'contactless' way to rebuild or create the correct project/target/workspace structuring for an Xcode project with cocoapods that can succeed even if the machine running the command cannot access the hosted pods?
Related
Cocoapods embed a step in the build phase to check if the Pods folder is in sync with the versions in Podfile.lock. This blocks the developer to work with the stale versions of the Pod with the following error:
error: The sandbox is not in sync with the Podfile.lock. Run 'pod
install' or update your CocoaPods installation.
Carthage has Cartfile.resolved, but how is it used to check if the Carthage Builds are fresh vs stale? Is it something that has to be manually enforced via some script?
Afaik the Carthage guides do not mention this topic at all. Usually you will be informed via failing compilation that a certain framework is not found, e.g. if you switched to a new branch where a new feature is implemented that needs framework XYZ. Then you know you have to run carthage bootstrap.
We have a script that runs so fast that you could even place it into the git hooks so it runs automatically after switching branches. The carthage part just cann the following command:
carthage bootstrap --use-ssh --use-xcframeworks --cache-builds
It makes sure carthage is up to date and it is fast since it uses cached builds. Runs fine for several years now.
I'm trying to build my nativescript app on iOS.
I have brand new MacMini with fresh system and all stuff like xcode, etc.
My app builds without any warnings on android - not checked android build on Mac.
When i try to run my app on emulator i have an error saying:
Analyzing dependencies
[!] There are multiple dependencies with different sources for `Socket.IO-Client-Swift` in `Podfile`:
- Socket.IO-Client-Swift (from `https://github.com/triniwiz/socket.io-client-swift.git`)
- Socket.IO-Client-Swift (~> 12.1.3)
'pod install' command failed.
Tried to remove one of the dependency from pod file but without any luck - it brings back during build.
What should i do?
After updating my dependencies, I also ran into an issue with Cocopods, although, not exactly the same. In my case, running pod repo update from within platforms/ios solved my problem. In short, there had been updates that my local pod spec repo wasn't aware of and it was getting "confused". I'm not sure if this will ultimately solve your specific problem, but it's fairly quick to do and, at least, won't hurt anything.
Good luck!
This may be a more complicated issue than I am portraying, but after building an iOS app and occasionally using GIT, I am not in a challenging position; I have additional developers I am working with, and there is a need to properly use a repository (BitBucket) for further work.
My project is "complicated" for two reasons;
I am using CocoaPods for third-party dependencies.
I use using GPUImage2, which is a separate .xcproject embedded in my project.
Somehow, everything was working fine (I had a master branch and several branches that various developers have been working on). Things have been complicated whenever I find the need to switch branches or merge branches. Issues related to CocoaPods constantly come up, though endless efforts at the command line typically get us through our challenges.
At this point, we are now trying to merge master into a new feature branch, and have hit the end of the line.
My question: Only one actual project file has a merge conflict. Every other file is related to the .xcworkspace or something with CocoaPods. I would think it would be ideal to remove CocoaPods from GIT control altogether, leaving just the Podfile, which developers can install locally.
Does anyone have suggestions on dealing with CocoaPods and GIT with Xcode projects?
I strongly recommend that you do not add your Pods folder to git, only commit the Podfile and Podfile.lock.
You can do the following to remove the folder:
git rm --cached Pods/
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 :)
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.