Unclear documentation on dSYM issue

[grigorye]

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...

[leavez]

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.

[grigorye]

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”?

[leavez]

Just a temporary issue that haven't been handled. 😂

[Akshay-1Mg]

How I can maintain pre-compiled pods for bev build and static/(pods with source) for release builds simultaneously ??
@leavez @hardworker