search

SocketMobile / cocoapods-capturesdk

CaptureSDK for iOS
Other
6 stars 0 forks source link

"EXC_BAD_ACCESS" when using different Crypto methods. #7

Closed KevinRondon closed 1 year ago

KevinRondon commented 1 year ago

Hello! I currently have the CaptureSDK and CryptoSwift pods installed, and when I instantiate some Crypto classes, I get the EXC_BAD_ACCESS error, like the following cases:

When I don't use the CaptureSDK, I don't have any problems. I have CaptureSDK version 1.7.5 and CryptoSwift 1.7.1 installed. Any ideas why this conflict might be occurring?

cyrille-socket commented 1 year ago

Hi @KevinRondon

our CaptureSDK is also using CryptoSwift as a dependency to build it. We had a conflict earlier in the SPM (https://github.com/SocketMobile/swift-package-capturesdk/issues/7) but it has been addressed.

We are currently using the version 1.6.0 (SPM).

Out of curiosity, why don't you migrate to Swift Package Manager? It handles way better the dependencies and Cocoapods is really outdated now.

Do you have a sample project where I can test this?

KevinRondon commented 1 year ago

Hi @cyrille-socket

Thank you for the recommendation, I migrated to SMP and it works without a problem. There wasn't any particular reason apart from the fact that I've been using CocoaPods for a long time in the project. I'm closing the issue, thank you.

svenmuennich commented 10 months ago

We are facing a similar issue. We currently use CaptureSDK in v1.7.11 and CryptoSwift in v1.8.0. This gives us console output like the following at runtime:

objc[74294]: Class _TtC11CryptoSwift20AEADChaCha20Poly1305 is implemented in both /Users/svenmunnich/Library/Developer/CoreSimulator/Devices/59A56137-8517-466C-9025-4D99B45EDB9E/data/Containers/Bundle/Application/7130AB43-637D-4C20-B525-E53C38F477D7/WMS.app/Frameworks/CryptoSwift.framework/CryptoSwift (0x10e631b28) and /Users/svenmunnich/Library/Developer/CoreSimulator/Devices/59A56137-8517-466C-9025-4D99B45EDB9E/data/Containers/Bundle/Application/7130AB43-637D-4C20-B525-E53C38F477D7/WMS.app/Frameworks/CaptureSDK.framework/CaptureSDK (0x10c0cbcd8). One of the two will be used. Which one is undefined.

So far we haven't experienced any crashes but are afraid of releasing this in its current form. Unfortunately migrating to SPM is no option for us due to the complexity of our project and its build processes.

To me it looks like CaptureSDK.xcframework vendors CryptoSwift instead of defining it as a dependency in its .podspec. It's hard to tell how a fix for this might look as the sources and build process are not public.

Any chance you can fix this on your end?

svenmuennich commented 9 months ago

@cyrille-socket is there any chance that you can port that fix from the SPM repo to this one?

We have hundreds of customers relying on your hardware and our affected apps still use SKTCapture, which was just deprecated and removed from the CocoaPods specs repo yesterday. So we are now really feeling the pressure to migrate to this pod.

cyrille-socket commented 9 months ago

Hi @svenmuennich

I'm gonna try to do this but we put all our fruits in the basket of SPM because we have to evolve. Cocoapods is end of life now and we will no longer support it at some point.

Our project to build the iOS CaptureSDK is also complex and we have a lot of constraints with some dependencies we use (the few possible though). But if you make the effort of migrating to SPM you will see the benefits right away. Also, SPM and Cocoapods can coexist in a Xcode project.