swift – iOS: Runtime error when testing customized Framework with Third-party CocoaPod dependency (ARCore)

Our (largely Android-backgrounded:)) staff is growing associate iOS Swift Framework (SDK) with some Third-party dependencies inside.

Framework itself has a number of Third-party Swift Packages, and so they’re working like a allure both throughout compile time or whereas testing on gadget/simulator, whereas being embedded inside a easy check “associate” app. No normal issues right here.

However there’s one important Third-party lib which doesn’t have risk of embedding by way of SPM: ARCore Augmented Faces.

It suits our wants completely, however, sadly, remains to be obtainable solely by way of CocoaPods. Our objective is to embed it inside Framework binary solely, with out the necessity to reference to it in associate apps straight.

So we’re at present caught with utilizing widespread workspace and a couple of initiatives (check app and framework itself) inside it, additionally with CocoaPods base construction on prime workspace degree:

The Podfile right here at present appears like this, impressed by the construction talked about right here https://stackoverflow.com/a/42480097/6405022:

# platform :ios, '11.0'

workspace 'Untitled.xcworkspace'

abstract_target 'CommonPods' do
    pod 'ARCore/AugmentedFaces', '~> 1.30.0'

    goal 'TestApp' do
        venture 'TestApp/TestApp.xcodeproj'
    finish

    goal 'Framework' do
        venture 'Framework/Framework.xcodeproj'
    finish

finish

With that mentioned, associate check app builds simply tremendous.

The issue which we’re going through occurs proper after associate app launch and is all the time supported by crash:

…
Numerous comparable duplication warnings like beneath comes right here
…

objc[58698]: Class GARPseudonymousID is carried out in each
/non-public/var/containers/Bundle/Utility/21A274AC-31B1-4AE6-9E3F-1BF720C9B221/TestApp.app/Frameworks/Framework.framework/Framework
(0x103d9e0d8) and
/non-public/var/containers/Bundle/Utility/21A274AC-31B1-4AE6-9E3F-1BF720C9B221/TestApp.app/TestApp
(0x10131e440). One of many two shall be used. Which one is undefined.
objc[58698]: Class GARPseudonymousIDStore is carried out in each
/non-public/var/containers/Bundle/Utility/21A274AC-31B1-4AE6-9E3F-1BF720C9B221/TestApp.app/Frameworks/Framework.framework/Framework
(0x103d9e128) and
/non-public/var/containers/Bundle/Utility/21A274AC-31B1-4AE6-9E3F-1BF720C9B221/TestApp.app/TestApp
(0x10131e490). One of many two shall be used. Which one is undefined.
F0621 20:33:23.600151 1 registration.h:175] Operate with identify
CallbackPacketCalculator already registered.

*** Examine failure stack hint: *** dyld4 config: DYLD_LIBRARY_PATH=/usr/lib/system/introspection
DYLD_INSERT_LIBRARIES=/Developer/usr/lib/libBacktraceRecording.dylib:/Developer/usr/lib/libMainThreadChecker.dylib:/Developer/Library/PrivateFrameworks/DTDDISupport.framework/libViewDebuggerSupport.dylib:/usr/lib/libMTLCapture.dylib
dyld4 config: DYLD_LIBRARY_PATH=/usr/lib/system/introspection
DYLD_INSERT_LIBRARIES=/Developer/usr/lib/libBacktraceRecording.dylib:/Developer/usr/lib/libMainThreadChecker.dylib:/Developer/Library/PrivateFrameworks/DTDDISupport.framework/libViewDebuggerSupport.dylib:/usr/lib/libMTLCapture.dylib

What we already know:

• It occurs in runtime and solely when including ARCore by way of CocoaPods and setting pod ‘ARCore/AugmentedFaces’ each for TestApp and Framework targets.
• It does not make any distinction if we’re attempting to reference Framework API in associate app code (by way of import Framework and/or calling its API strategies) or not, however:
• When setting pod ‘ARCore/AugmentedFaces’ for TestApp solely, it can’t be accessed inside Framework Swift code in compile time.
• When setting pod ‘ARCore/AugmentedFaces’ for Framework solely, we get No Such Module: ARCore error by way of Swift linter proper on import Framework line (primarily the place the place associate app has an entry to our framework, f.e. in AppDelegate or else).
• Class N is carried out in each... warning references solely to ARCore-related lessons.
• ARCore (clearly) works completely tremendous when being added as pod to any easy iOS app venture w/o customized modules together with it.
• Eradicating ARCore pod and references to it utterly allow us to manually check the remainder of Framework performance w/o issues.

We’re not nonetheless 100% positive if class/methodology duplication points trigger the crash downside, however we’re largely positive it occurs when attempting to have an ARCore pod contained in the each Framework goal and app goal (or in summary goal on prime degree). In any case, eliminating the pod in any separate module causes issues talked about in higher thesises (with present method).

Any ideas or workaround (perhaps solely besides deriving Third celebration supply code:)) shall be a lot appreciated!