Unclear documentation on dSYM issue
grigorye opened this issue · comments
It would be great if the following:
dSYM files is missing for dynamic frameworks using this plugin. Walkaround: Don't use this plugin for a release build. Add a if condition with ENV around plugin 'cocoapods-binary'
would have a real receipt in terms of Podfile. Still can't figure it out, sorry...
In your podfile
if not ENV['DISABLE_POD_BINARY'] == 'true'
plugin 'cocoapods-binary'
end
Before doing a release build. In the command line:
export DISABLE_POD_BINARY=true
pod install
Then the plugin will not be used for this pod install.
Got it, thank you very much! Is there a way to avoid pod install when switching between release and debug? We store pods in git, and would like to avoid pod install unless there’s a change in pod configuration. I wonder if there’s a workaround... Like using two Pods directories or two integration workspaces, or something like that... if there were no changes to the client app xcodeproj that would be probably easily achievable, but I recall seeing some differences in there after enabling cocoapods-binary - that’s probably a problem by itself, i.e. on pod install on switching between debug/release, the client app xcodeproj would be changed too.
Btw, is this whole thing (dSYM) a temporary issue or “by design”?
Just a temporary issue that haven't been handled. 😂
How I can maintain pre-compiled pods for bev build and static/(pods with source) for release builds simultaneously ??
@leavez @hardworker