I had two separate CocoaPods, they're named like this,
4.3.1-test
4.3.1-testBeta
Then I created a third one and named it,
4.3.1-testX
When users users write the podfile like this:
pod 'Podname', '~>4.3.1-test'
It ends up downloading '4.3.1-testX'
Why is this happening? Is it because I pushed '4.3.1-testX' after '4.3.1-test'?
How to solve this? Please help!
Just found the answer to my own question,
The optimistic operator (~>) does not care about the string in the version name (x.y.z-string).
Therefore, even if the strings are different, it will download the most recently pushed pod.
Related
I'm currently working on a iOS (Swift) app for which I installed a few Frameworks via Cocoapods.
I have been facing a few issues with one of the frameworks and decided to tweak its code manually to run some tests and see if I could make things work.
I ended up figuring out a way to achieve what I wanted but I had to add a couple files in that framework as well as modify a few others.
This is the first time I do this and I'm almost certain this is no the best way to do things but I wanted to get some advices on how I can maintain that framework (that is behaving the way I want) in the future?
If I run "pod install" again, I suppose the framework and my changes will be overridden...
Any advice would be really appreciated.
Find the source repo (probably on GitHub) and fork it to your own account. Check out that repo and make your changes.
Optionally I would recommend making your adjustments to the code reusable so others can also use your tweaked version (make it configurable so they can turn the additional functionality on or off) and then submit a pull request back to the original repo.
If you don't want to do that you can point your Podfile directly to your customised repo using the following format:
pod 'Alamofire', :git => 'https://github.com/Alamofire/Alamofire.git'
Or you could look at creating your own CocoaPod (either by publishing to CocoaPods public specs repo or creating your own specs repo).
This post is in regards to two Cocoapods of which I am the owner of:
https://cocoapods.org/?q=id.me (There's only one cocoapod that shows up and I can't link to it because it's broken)
https://cocoapods.org/?q=idmeweb (There's only one cocoapods that shows up and I can't link to it because it's broken).
I need the first CocoaPod (which has already been deprecated), ID.me WebVerify to be completely removed as it's podspec points to a personal repo of mine, http://github.com/artsabintsev/Harpy/. The actual location it should have pointed to no longer exists, and my previous employer, ID.me, has asked me have it removed.
I need the second CocoaPod, https://cocoapods.org/pods/IDmeWebVerify, to work. Apparently, clicking on the link does nothing. My previous employer, ID.me, has asked me to figure out how to get it fixed.
Thank you for any and all assistance.
There are pod trunk x commands to deprecate and delete if you have admin access to them.
I am trying to use Firebase for notifications. And I followed all the steps to install the cocoapods and write the code and get the certificates.And yes I am using xcworkspace to run the program.
Now I am getting this error when I try to run the program. I have exhausted all the suggested solutions on Stack Overflow, from deleting the derived data to restarting xcode and even checking that the $1 has single quotes instead of double quotes as suggested by another answer.
My project name has an 'apostrophe' in its name. So I think that might be the problem. If yes, how do I solve it?
Also when we look closely at the error in the path, we can see that it says tabber.WhatsPoppin.app without the apostrophe. So I think that may be a possible cause of the problem. How do i change the path/rename the file if that is the problem?
There may be something else which might be cause the error. Feel free to suggest anything. I really need the help.
The fix is to get rid of the apostrophe in the directory name for your project. You can keep the apostrophe in the display name of the app, but everywhere else you should get rid of it.
I have a project which is almost completed in swift 2.2, Now I want to update the code to swift 2.2 to swift 3.0.I am using the Cocoapods for thrid party library integration and need following suggestions:
Should I go ahead update the libraries used first by running pod update? If any lib has not updated to support swift 3 what should i do?
Should I go ahead to update code to swift 3 manually or follow the XCode8 suggestions?
If I directly go for XCode8 suggestions then XCode8 starts giving suggestions to update library source code also.I am searching for the good way to handle all this. Thanks.
There is not a "best" way — as every project is potentially different in how easily it can be converted to an updated version of the language it's written in.
It would be recommended to:
Save a backup copy of the project before attempting to convert/migrate anything.
Follow the Xcode recommendations for updating the code.
Update the dependencies such as Cocoa Pods.
Fix any unresolved issues that might not have worked during the conversion.
Have patience, as often the conversion is not a one-click process.
If some of your libraries haven't been updated to Swift 3.0 then that's no problem, as you can tell the compiler to compiler only that library with the old compiler.
My suggestion, (and indeed how I updated my own projects), is to run the automatic migration wizard. (Editor>Code Syntax>Upgrade to latest Swift syntax). Then you should run pod update making sure to remove any version specifiers in your podfile.
Once you have done both of these things you can open your project and be greeted with a lot of compiler errors, the bigger your project the more you will have; unfortunately this is somewhat unavoidable because the built in migration tool sucks.
Now it is going to be a case of trudging through and fixing these errors, most of them will probably be something really simple like dropping AnyObject for Any, but a few may trip you up.
Now as I mentioned, if a library hasn't yet been updated for Swift 3.0 you can open your Pods project settings and select the library in question. Under build settings you'll find a key called Use legacy Swift syntax. Set this to true and rebuild. This forces the compiler to use the old compiler for this pod only.
I hope this in depth explanation is of help.
I Found some strategy migrating to Swift 3
I migrated directly to Swift 3.0. I use CocoaPods, so I migrated my dependencies first. This means following the steps above for each open source library (or private pod).
So far, the only dependencies I have for this project are my own libraries, which made this quite easy since I control all of the code. However, if you have third-party dependencies, then I would recommend opening an issue on the project to discuss migration plans with the current maintainers. I expect most popular projects are doing something similar to what I described above. For example, AlamoFire has a swift2.3 and swift3.0 branch. If needed, you can fork and migrate third-party libraries yourself — then submit a pull request or use your fork until the maintainers offer a solution. However, you should definitely reach out to project maintainers before submitting a pull request for migration.
Until Xcode 8 is final, you’ll need to point your pods to these new branches:
pod 'MyLibrary', :git => 'https://github.com/username/MyLibrary.git', :branch => 'swift3.0'
This tells CocoaPods to fetch the latest on the swift3.0 branch, instead of the latest published version.
Once your dependencies and Podfile are updated, you can run pod update to bring in the Swift 3.0 versions of each library. Then you can migrate your main app. I suggest commiting all of this migration in a single commit — update all dependencies, migrate your app, then commit — to keep your history clean.
Bugs
Xcode’s migration tool is not perfect.It would sometimes fail to migrate test targets, or only partially migrate app and framework targets. When this happens, you can attempt to run the tool again, but it’s probably best to make changes manually. Here are some of the specific issues that I saw:
Some expressions inside of XCTAssert*() did not migrate.
Some expressions inside closures did not migrate.
Sometimes waitForExpectations(timeout:) did not migrate.
Migrating NSIndexPath to IndexPath when used in certain contexts often resulted in derpy things like (indexPath as! NSIndexPath).section.
Enums with associated NSDate values migrated to case myCase(Foundation.Date) instead of case myCase(Date).
Sometimes optional protocol methods did not migrate, which can produce hard-to-find bugs.
Ref Links :
http://www.jessesquires.com/migrating-to-swift-3/
https://swift.org/migration-guide/
Just finished resolving my errors after converting to Swift 3 only to get this error when trying to compile. I have attached a screenshot for clarity, it does not look like the system is looking for a .app file or .sh file. Really don't know too much about the Pods, so any help would be greatly appreciated!
Seem to have found a solution. My project name had a space in the middle of two words, very bad practice I know. Not entirely sure what caused this error, though one could possibly conclude that since the problem originated in the Pods framework, it could be related to Cocoapods, rather than migration to Swift 3.
I traced the problem to the Pods framework for my project after searching extensively for solutions to this problem.
Fixed the double quotes to single quotes on the line highlighted, and the project built instantly. Hope this helps anyone else having a similar issue!
• Just restart your system..... It Looks crazy but my problem solved.
Swift4/5 Xcode10 Same Issue...
After upgrade cocoapods, reset pods, clean the build folder...., all these tries, it still fails... until I found this post.
However, there's no space in my project name, but do have a special characrter <'> in it. I decided to give it a try to see if it is the source of issues. After following along the instructions in how-do-i-completely-rename-an-xcode-projec, the project builds successfully, finally.
So just a note: avoid using space or other special characters in the project name, that may cause some unexpected errors