Skip to main content
Solved

Release pre-built .xcframework: why dSYMs are separated?

  • 29 December 2021
  • 5 replies
  • 762 views

Hello,

We’re using Carthage to consume Purchase.xcframework. It’s possible to download the pre-built xcframework within the release as described here. However, your prebuilt xcframework doesn’t contain dSYMs inside. I downloaded xcframework.zip from GitHub and discovered all the dSYMs outside .xcframework itself, in the separate folder.

 

The RevenueCat official iOS SDK Installation guide suggests to run the carthage update with `--no-use-binaries` option which triggers a local build of xcframework. BTW this also might cause a problem such in my case where I don’t have swiftlint installed and getting this error on build:

```

Adding homebrew bin folder to PATH (/usr/local/bin)

error: SwiftLint not installed in /usr/local/bin, download from https://github.com/realm/SwiftLint

Command PhaseScriptExecution emitted errors but did not return a nonzero exit code to indicate failure

```

 

Question:
Why not to contain dSYMs inside release pre-built `.xcframework`? Thus, we can run just `carthage update --no-use-binaries` and download a pre-built xcframework with dSYMs included. No need to build it locally just to generate dSYMs.

Thank you,

German.

 

PS This is my Carthage usage information:

* `carthage version`: 0.38.0
* `xcodebuild -version`: Xcode 13.2 Build version 13C90
* Are you using `--no-build`? NO
* Are you using `--no-use-binaries`? NO
* Are you using `--use-submodules`? NO
* Are you using `--cache-builds`? NO
* Are you using `--new-resolver`? NO
* Are you using `--use-xcframeworks`? YES

**Cartfile**
```
github "RevenueCat/purchases-ios" == 3.13.1
```

**Actual outcome**
The pre-built xcframework downloaded without dSYMs included

**Expected outcome**
dSYMs should be contained inside xcframeworks directory
 

Hi @GermanVelibekovHouzz!! 👋🏻

Thanks for reporting!! 

I confirmed that the dSYMs weren’t included in the .xcframework folder. 

I made a fix for it, currently in review. Once the fix is merged, I’ll update the .xcframework files in GitHub so you’ll be able to re-run carthage and get them. 

In order to get the dSYMs, though, you should use carthage with --use-xcframeworks and without --no-use-binaries. 

--use-xcframeworks will ensure that xcframeworks are used, and not using --no-use-binaries will ensure that you get the pre-compiled .xcframework which includes the dSYMs. It’ll also mean that you won’t have to have `swiftlint` installed. 

I’ll update the installation instructions when all of that’s wrapped up to reflect this. 

I apologize for the inconvenience. I just tested exporting a new .xcframework from the branch with the fix (fix/xcframework_not_including_dsyms) and it worked correctly, getting the dSYMs. 

Here’s the PR for reference. You can try it yourself by updating the entry in your Cartfile to

 

github "revenuecat/purchases-ios" "fix/xcframework_not_including_dsyms"

 

However, I’ll update the existing 3.13.1 release so you won’t have to do that, after the PR passes review. 

 

I’ll post again in this ticket when that’s done. 

 

Thanks again for reporting! 

Hey @Andy !

Thank you for your reply and work!

I have another problem tho.

As for now, when we run carthage update --no-use-binaries --use-xcframeworks

as mentioned in documentation dSYMs are generated locally. However, when rest of the team debug and try to po an object they encounter the following problem:
 

error: virtual filesystem overlay file '/Users/germanv/Library/Caches/org.carthage.CarthageKit/DerivedData/13.2_13C90/purchases-ios/3.13.1/Build/Intermediates.noindex/Purchases.build/Release-iphonesimulator/Purchases.build/all-product-headers.yaml' not found error: virtual filesystem overlay file '/Users/germanv/Library/Caches/org.carthage.CarthageKit/DerivedData/13.2_13C90/purchases-ios/3.13.1/Build/Intermediates.noindex/Purchases.build/Release-iphonesimulator/Purchases.build/all-product-headers.yaml' not found error: 


couldn't IRGen expression. Please check the above error messages for possible root causes.

There’re possible solutions to this. However, for now we just used the pre-built Purchases.xcframework not containing the dSYMs from the current release.

 

Now, when you added dSYMs to be part of the pre-built xcframework, how do you prevent that issue above? Does running a plugin mentioned in the PR differ from generating dSYMs locally with --no-use-binaries to include dSYMs?

As for the current release, I hope there dSYMs aren’t outside of pre-built xcframework on purpose.

Note: To test if it created the problem above:

  • ​​​Clean Derived Data for your Test project where Purchases.xcframework is integrated with dSYMs included
  • Set breakpoint 
  • po some object in console during a runtime 

Thank you.

@GermanVelibekovHouzz Thanks for the very detailed report. 

I updated the release in GitHub to include the dSYMs, so if you try doing carthage update purchases-ios --use-xcframeworks, you should now get the dSYMs. 

 

As for the couldn't IRGen expression issue, that’s a tough one. I tried it out and was able to reproduce on my machine (as long as I delete derived data every time and restart xcode). 

 

I went into a bit of a rabbit hole, but I did find this easy workaround from steipete’s blog that points to this SO answer. I tried it out and it worked like a charm for me. Could you give it a shot? 
 

If it works for you too, I’ll add it to the docs. I apologize for the inconvenience. XCFrameworks are great, but they’re very tricky to get right from an SDK developer’s perspective. 

Hey @Andy .

I gave it a shot as you asked. Even though Purchases.xcframework now contains dSYMs, which is great, I didn’t get the couldn't IRGen expression error which is also great! 

But can you explain why I didn’t get the error this time? What’s the difference between generating dSYMs locally and getting it as part of the pre-built xcframework?

Here’s the test I performed:

  • carthage update purchases-ios --use-xcframeworks
  • Cleaned DerivedData
  • Cleaned Build Folder
  • Re-opened the project
  • Run
  • po object

Thanks.

 

I’m actually unsure why it worked without further changes this time! Maybe there’s something still cached from when you were doing `--no-use-binaries`?

For my test project, I got the IRGen issue and could only get it to go away by adding a dummy Objective-C file and a bridging header to the project. 

If you get the issue again, give that a shot! 

Reply


Terms & ConditionsCookie settings