I have a iOS framework for which I don't have the source and the authors have not provided a podspec for it. I'm already using CocoaPods for multiple other libs and would love to keep this one along with them.
Is it possible to create a podspec file that will simply reuse the existing framework binary?
I have:
xxx.embeddedframework/
xxx.framework
Resources/
yyyy.momd
I know all the details like what system frameworks it depends on.
I suspect vendored_frameworks may be an answer, but I'm not sure how to write one. For example, s.source is mandatory parameter and I don't have any source files so pod spec lint fails.
Related
I have a script/tool that I would like to include in my cocoapod to be used as a code generator utility. I'd just like it to be available to the user in the distribution as something like:
Pods/MyPod/my_script.sh for command line use or integration into pre-compile phase hook. Obviously this should not be deployed with the compiled application, it would only be of use at build time.
If I include the file in the Assets dir:
s.resources = 'MyPod/Assets/**/*'
then it will end up deployed in the framework with the application (right?).
Alternately I can include it in the Classes folder and I think that does what I want because it is ignored, but it feels like a hack.
Furthermore neither of the above solutions is helpful when referencing the pod during development time (e.g. with a :path = ../) because when in that mode the Classes and Assets folder don't seem to be copied or linked into the local Pods folder at all. This makes it somewhat harder to test.
Is there any sanctioned way to include arbitrary files in a Cocoapod distribution?
I am using Carthage dependency manager in my iOS project.
I have the Carthage/build folder in my repository to always have ready to go built frameworks when checking out the repo.
I am wondering what the bcsymbolmap files in the build folder are for. Quite a few of them are created with every carthage update.
Do I need to keep these files? Should I have them in my repository?
No, you don't need those files. If you set up Carthage properly, binary, .dsym and .bcsymbolmap files will be copied on build phase. When you archive the build for distributing using App Store, all needed files will be included in archive and after you upload the build to App Store you will be able to upload dsyms files anytime (to be able to decode your crash reports). If fact you don't need to store .dsyms and .bcsymbolmap files in your repository.
There is a good article explaining what is happening when the framework is being build (and what in fact Carthage scripts do) https://instabug.com/blog/ios-binary-framework/. Also it explains what for .bcsymbolmaps files used for - so Apple servers can rebuild your code using Bitcode and then you can desymbolicate your crash reports.
So, you don't need to keep those files. No need to store them in repository. The other reason not to store content of Build folder is that anyway your project can fail build with it on another machine with different environment. If you want to build your project with the same versions of dependencies - use Carthage bootstrap command instead of update.
P.S.
Also you can investigate what copy-frameworks command do:
https://github.com/Carthage/Carthage/blob/fc0166b4827736bac2c804fc928797f1a742c455/Source/carthage/CopyFrameworks.swift
If you use carthage build without the specification of a project, all
.bcsymbolmaps should be deleted, but if you use e.g. carthage build Alamofire it should just delete the corresponding .bcsymbolmap
From the discussion of a github issue. Looks like you do not need those files, since the default behaviour is to delete them when building a new build.
In general, you should not commit files generated during a local build into your repository, since builds can be device specific, and everyone cloning into or pulling from your repository should be able to perform a build themselves.
Bitcode Symbol Map(BCSymbolMap)
.bcsymbolmap is a textual file with debug information and which is generated for decoding stack trace. Solves same issues as .dSYM[About] but on more low level for and when Bitcode[About] is generated
It looks like:
BCSymbolMap Version: 2.0
__swift_FORCE_LOAD_$_swiftCompatibility50
__swift_FORCE_LOAD_$_swiftCompatibility51
__swift_FORCE_LOAD_$_swiftCompatibilityDynamicReplacements
_$sSo26SCNetworkReachabilityFlagsVMa
_$sSo24SCNetworkReachabilityRefaMa
...
Do I need to keep these files? Should I have them in my repository?
They are optional
I am building a cocoapod and wanted to add a dependency for Alamofire because my pod will be making some requests.
After trying to integrate my cocoapod (with the Alamofire dependency) into our main app, I got a version conflict because we are also using Alamofire in our app, but a different version.
Seeing this error, it made us wonder.. why havn't we seen a version conflict message like this one before? We have a handful of third-party cocoapods installed. After inspecting a few of our third-party pod spec files, we found that none of them have dependencies defined.
Is this common practice when releasing cocoapods, to have no dependencies?
(..asked by a Node.js developer)
Remember Alamofire now is on version 4.0(there is even a branch for swift 3), so, if you updated your pods, it automatically installed the new version, if this what you want take a look to the migration guide.
Other case, you have to specify the version you wanna wortk with in your pod file
I have recently been working with Cocoapods on my own projects, and would like to incorporate a couple of pods into a project at work. The problem is that our code consists of close to 20 projects stored inside a large workspace, sorted into folders. The structure of the projects is
Workspace
Apps (Folder)
Project 1
Project 2
etc...
Modules
More Projects
etc
Base Components
Even More Projects
etc
I am unsure how to write a podfile that would link a pod (RETableView in this case) against an app without disturbing the existing structure of the workspace? Is this even possible? If it isn't possible to incorporate cocoapods without changing the existing workspace, is it possible to set up cocoapods to compile pods as standalone libraries that I could incorporate into our project?
With CocoaPods 1.x you can use :integrate_targets => false in your Podfile like this:
install! :integrate_targets => false
You can find the documentation for this here
Previously (for older CocoaPods versions):
After creating your Podfile use pod install --no-integrate documented here. This will create the Pods project that you can then include in your workspace. Please make sure everything in your project is checked into your version control system first just in case anything goes wrong.
We are working on many projects having common basic functionality, so we decided to put the common functionality in a framework and use it as git submodule, All well and good.
Now, I want to control Pods from framework as well, so I tried to put the Podfile into framework.
As Podfile and .xcodeproj are not in same directory, so to link the xcodeproj I tried to put
xcodeproj '../XYZ.xcodeproj'
As XYZ is different for every project, so want to use something like this.
xcodeproj '../*.xcodeproj'
Is there any way I can do it?
BTW it may be possible if I create a Private Pod and then use the Pods as dependencies of it, But in my case above solution will be handy.