I often use pods in my Obj-C and Swift projects and quite often need to tweak a pod for my use-cases. I noted recently that my edits were having no effect, that the original bits were being used, and there were many times I was stumped at a situation that I thought my editing corrected, only to realize the compiled bits did not include my latest brilliant hack.
Then I discovered that simply cleaning the build folder (shift-cmd-K) will reset everything and the next build incorporates my edits. I now do this as a matter of regular business with each pod edit, but wondered if there was a simpler way to set a pod to be included in each rebuild.
Editing pods is not ideal, simply because all your changes will be removed after the next pod update.
The best way here would be to fork the pod, modify it and use your own version instead.
Related
When I set path for my development pod, I cant commit podfile - it will break pod install for other devs. So I keep podfile in another change list and its really annoying. Is there a better way to develop pod?
I found this: link, it suggest to change to path every time I want to update something in my pod. But it's even worth than uncommited podfile.
You can use relative paths for development pods.
You can ask your co-developers to always use the same folder hierarchy between your current project (with the podfile) and the others developments projects/pods (with the podspec).
You can also use Repo to automatically do it for you (could be useful when a new guy comes, and/or if you have plenty of different development pods). It will install different projects/(development)pods according to the hierarchy set in its manifest. You can check this related answer if needed.
I want to know, is it possible to build Pods only once? Because building them each time without any changes takes too much time.
Is there any solution for building Pods only once and reducing build time with it?
Xcode should be caching some build information in derived data after the first build. However, other than that, there's not much to be done. I would suggest a faster computer or less dependencies :)
If this is a real pain in the neck and you don't mind getting rid of cocoa pods, you can alway import the compiled frameworks manually. That would pretty much get rid of any build lag from your pods, but you'd also have a hard time keeping the pods up to date.
You could try precompiling Pods with https://github.com/leavez/cocoapods-binary as described here https://guides.cocoapods.org/plugins/pre-compiling-dependencies.html
You append binary => true in your podfile to the pods you want to precompile, which switches them to compile frameworks.
plugin 'cocoapods-binary'
use_frameworks!
target "HP" do
pod "ExpectoPatronum", :binary => true
end
But I find XCode does a pretty good job of caching what's needed.
I have an Xcode workspace that uses CocoaPods to include several third-party frameworks. I would like to edit a line of source code within one of these dependencies. However, when I do so, Xcode warns me that the file is locked and that any changes I make may not be saved. So my question is: will my changes to the source code be discarded when I run a pod install/update? If not, is there any other scenario, possibly unrelated to CocoaPods, that would discard my changes? And finally, is there any good way that I can edit the source code without running into such problems?
Thanks in advance.
You can not make changes in Original Pod file. If you want to add some more features then you have to fork that particular repo.
Follow steps to do so :
Find library you want to use on Git.
Fork library.
Update Podfile which refer to your forked version.
Suppose I want to fork GPUImage Library. Then point your fork in Podfile as given.
pod 'GPUImage', :git => 'https://github.com/UserName/GPUImage.git'
Make your changes.
Commit/push your changes to your forked repo.
Submit a pull request to the original author of Library.
If pull request is accepted and the pod is updated, revert back your Podfile to use the public pod.
You can create Category (Objective C) or Extension (Swift) to extend or add some features to existing class.
You can do this simple. Just modify the pods src code. Switch to another brach and switch back. Xcode would rebuild pods with your modified code.
If you want go back, you should remove the pod in Podfile, execute pod install.Then add pod back, execute pod install.
This solution is just for debug.
For permament, you should take #technerd 's answer
In fact there is another way in which you can modify the library as per your custom needs and get future updates from the library, all while still maintaining it via cocoapods
I have written article/tutorial explaining the same.
https://medium.com/#mihirpmehta/how-to-modify-cocoapods-library-within-pods-647d2bf7e1cb
So I am working on an old Xcode project that was developed by a separate developer and am having build errors when running on my Mac due to Cocoapods. The first error is "The sandbox is not in sync with the Podfile.lock”, which I can fix by removing the various Cocoapods files and the old xcworkspace from the project and running pod install in the terminal to create all of this again. The new issue is that some of the classes cannot find the header files from the podfile's listed frameworks.
My theory is because this is an old project and the old developer didn't put version caps on some of the frameworks in the podfile, is that the project is trying to use old methods / classes that are deprecated in the newest updated frameworks. However I am not sure how to get around this as I tried putting version caps on those frameworks in the podfile without any success.
There are two paths:
You investigate each framework, estimate the approximate pod version that could have been used at the time project was active, and use particular version of each pod (you can find info on configuring pod version here
This solution won't work in 90% of cases, however, as iOS is evolving really fast and old frameworks are most probably outdated and not compatible with latest changes.
You investigate each framework and understand what actually changed. You look at headers that each pod has, understand what actually changed and implement changes in your code.
You start with headers, making sure that you include the right ones, and then start migrating code to the newest versions.
Big projects usually have migration guides.
There are no other options. As soon as any project becomes dependant on external code, it's up to developers to ensure that it's up-to-date.
I have returned to a fairly large project that uses RestKit and many other libraries.
The existing target builds and archives fine. Xcode 6.4, SDK iOS 8.4, target iOS 7.0.
I did this:
Duplicated the existing target.
Added some pre-processor macros and a different product name
Expected the new target to build and archive successfully.
Now the build fails with:
(null): Library not found for -lPods-AFNetworking
NOTES:
I have compared the raw target details and they are identical apart from the few changes I noted above.
I don't really want to run pod install on the project. Why? Because I'm afraid, yes. And because I don't want to spend much time - I just need to make a variant build and then move on to something else. A pod install after a period away could cause unwanted breakage.
I have had this problem before on the very same project, and yes I am cursing the former me for not making better notes at the time, but the former me says that he was fatigued and pissed off with it at the time and couldn't bear another minute, and knew it would come back to bite the later me in the arse.
So now before I bang my head against this again, I am hoping a kind and generous soul reading this will share a golden path of light that leads up and away from the pain directly to the promised land of a clean build.