XCFramework and apple silicon support

[mstfy]

Hello. We import Adjust manually as framework to our project. We do this because we don't want to rebuild it everytime for clean build. As you know it's been over 1 year since apple silicon macs come out. It would be super helpful to add xcframework artifact with m1 simulator support in it to your release artifacts.

[uerceg]

Hi @mstfy

We will start to ship our SDK releases as xcframeworks as well pretty soon. It's actually task we are currently working on internally and should be completed soon. Will keep you posted.

[mstfy]

Oh that's great to hear. Will you support m1 simulator too?

[uerceg]

Yep, there's gonna be support for M1 as well.

[shaurya-ObjC]

@uerceg Any expected dates for same? Some kind of approx ETA?

[nirgin]

@uerceg will this include BUILD_LIBRARY_FOR_DISTRIBUTION? we are currently blocked on upgrading our toolchain while waiting for your SDK to enable this.
Is there a timeline update?

[shaurya-ObjC]

Hi Team,

@uerceg
Thank you for adding ability to build SDKs as xcframeworks.
https://github.com/adjust/ios_sdk/releases/tag/v4.31.0

However, when I am trying to use the same, I am getting below kind of error. Can you please help?
'ADJEvent' is not a member type of class 'Adjust.Adjust'
I am using your Adjust pod into one of my podA and then I am generating xcframework of podA. After consuming podA into my project I am receiving below error. Please let me know how I can resolve this issue.

Thanks

[genadyb]

Hello @shaurya-ObjC.
Thank you for the input.

Could you please share your podA podspec details?

Regards.

[shaurya-ObjC]

@genadyb This is how something it look like.

Pod::Spec.new do |s|
s.name              = "PodA"
s.version           = "0.0.1-beta1+local"
s.summary           = "PodA Module for iOS"
s.homepage          = "https://github.PodACompany.com/Pods.git"
s.author            = "PodACompany"
s.platform          = :ios, "13.0"

s.swift_version     = '5.0'
s.static_framework = true

# Source Location
s.source            = { :git => "https://github.PodACompany.com/Pods.git", :branch => "develop" }

# Contents
#Start Framework Dependencies
s.dependency 'Adjust', '~> 4.19'
#End Framework Dependencies

s.frameworks = 'Foundation', 'UIKit', 'StoreKit', 'Photos', 'CoreGraphics', 'MapKit', 'WatchConnectivity', 'WebKit', 'Security'
s.libraries = 'c++', 'z'

#Local podspecs start
s.source_files = 'PodA/PodA/**/*.{swift,h,m}'
s.resource_bundle = {'PodABundle' => 'PodA/PodABundle/**/*.{storyboard,xib,json,html,xcassets,strings}'}
#Local podspecs end

#Remote podspecs template start
#s.source_files = "#{s.name}.xcframework/ios-arm64/*.framework/Headers/*.h"
#s.resources = "#{s.name}.xcframework/ios-arm64/*.framework/PodABundle.bundle"
#s.vendored_frameworks = "#{s.name}.xcframework"
#s.preserve_paths = "*"
 
#Remote podspecs template end

s.pod_target_xcconfig = {
  'BITCODE_GENERATION_MODE' => 'bitcode',
  'BUILD_LIBRARY_FOR_DISTRIBUTION' => 'YES'
}
end

[genadyb]

@shaurya-ObjC
Thank you.
Small question - is there any reason you are not using the latest Adjust SDK version - 4.31.0?

[shaurya-ObjC]

@genadyb
AFAIK it should automatically take the latest one, i.e 4.31.0, as I am using optimistic operator. Also, I am mentioning the Adjust SDK version i.e 4.31.0 from my main project

From Cocoapods Versioning https://guides.cocoapods.org/using/the-podfile.html

In addition to the logic operators CocoaPods has an optimistic operator ~>:

'~> 0.1.2' Version 0.1.2 and the versions up to 0.2, not including 0.2 and higher
'~> 0.1' Version 0.1 and the versions up to 1.0, not including 1.0 and higher
'~> 0' Version 0 and the versions up to 1.0, not including 1.0 and higher

[shaurya-ObjC]

@genadyb If I am not wrong, this issue will come for pods, where we are exposing Adjust object i.e public/open using PodA and if we are not exposing objects then this issue may not come at all.

[uerceg]

Hey @shaurya-ObjC,

Can you maybe try the workaround suggested in related issue opened in Swift repo. Referring specifically to this paragraph from Workarounds section:

If that isn't possible, you may be able to work around this bug by adding the special compiler flags -Xfrontend -module-interface-preserve-types-as-written to OTHER_SWIFT_FLAGS. This solution is not 100% reliable; in particular, you may have to manually implement conformances to protocols like Hashable to get them to print correctly. It is also something your module's clients may need to adopt if their interfaces refer to types from the affected module.

and let us know if that maybe helped with error you're facing?

[shaurya-ObjC]

@uerceg @genadyb

Today after adding the above flag, still we are receiving error while consuming the PodA.
Error comes only when we consume that PodA, it never comes while generating XCFramework with or without flag.
Error - 'ADJEvent' is not a member type of class 'Adjust.Adjust'

Please see the attached screenshot where we are receiving the error. SwiftInterface generated for PodA

[uerceg]

@shaurya-ObjC Thanks for the feedback. 👍

App you are trying to add your generated xcframework - is it Swift app? If it's a Swift app (seems so from the screenshot), would it be possible just to create an example project in Obj-C and to let us know if usage of xcframework there is showing the same error or not?

[shaurya-ObjC]

@uerceg @genadyb
My app is combination of both Swift+Objective-C. However, I tried the generated XCFramework in my SwiftProject, same error.
Above error comes in .swiftInterface file generate by apple.
You must need to do import PodA to receive the above error.

Please see the screenshot.

[uerceg]

Thank you for additional details.

I think that reason for this issue is exactly what is being described in above mentioned issue. tl;dr of the issue is pretty much the fact that our pod is named exactly the same as our main class (Adjust) in the SDK which Swift currently dislikes in your setup.

I see 3 potential solutions to this issue:

1. Adjust class to be renamed so that it doesn't match the pod name.
2. Pod to be renamed so that it doesn't match the Adjust class name.
3. Try to alter way how you are making your library to depend on Adjust.

We have discussed internally about this issue and indeed, even though pretty convoluted, we think that the use case of yours makes sense. So beyond doubt, the cleanest solution would be to proceed with solution 1. However, that means that we need to introduce the breaking changes for all the existing users and this is something we will not do (for now) just because of this use case. We are working on next iOS SDK major update (v5) which we are aiming to complete by EOY and already among everything that new major version will contain, we have also added this change where Adjust class will be renamed to ADJAdjust (or something similar) so that we make it not match the pod name.

Solution 2 is far from clean and nice and something we are also not willing to proceed with because we would effectively need to create new pod in CocoaPods repository solely for this purpose. And purpose of it will be defeated once next major SDK release is published.

Scenario 3 is something which you might consider as a temporary solution if this is road acceptable for you to take. I would expect that if you remove dependency to Adjust pod, but (I know it's not the nicest, but it is a solution) instead you simply add our SDK to your library as source code, that this problem should not be happening. That might be one approach. Another approach would be for you to effectively perform solution 2 on your own and ship our SDK as your own pod which would not be named Adjust and then you would hopefully not face the issue anymore. Downside is that you'd need to maintain this on your own all the time and make sure that you're keeping that pod in sync with our Adjust pod.

To me personally considering adding Adjust SDK dependency directly from source files to your library sounds like best way to go, but like said - I am not sure what are your other business requirements / constrains and whether this is something you are able to consider or not.

[mstfy]

Hello @uerceg . Since you've added xcframework support do you plan to include xcframework artifacts to releases?

[uerceg]

Hey @mstfy,

As of next release. :)