Lmst

I'm an unhappy happy camper. Finally have Microsoft OneDrive uploads working in my app. But the MSAL.framework I embed (but make optional) crashes the app on launch on iOS 12:

DYLD, Symbol not found: ___chkstk_darwin

The crash also mentions the framework was built for iOS 13. Which is correct. So it'd be nice if it just ignored it. 😄

Anyone know if there's a trick to avoid loading of newer frameworks? I have access to the source code so I can get creative.

#UIKit #XCFramework #iOSDev #Xcode

XCFrameworkをSPM経由で導入する方法
https://qiita.com/uhooi/items/92b3a5829f6c73281b7f?utm_campaign=popular_items&utm_medium=feed&utm_source=popular_items

#qiita #Swift #SwiftPackageManager #SPM #SwiftPM #xcframework

I'm pleased to announce that v2.2.0 of the BEMCheckBox has been released! This release builds an xcframework instead of a lipo binary. More details can be found in the release notes:

https://github.com/saturdaymp/BEMCheckBox/releases/tag/v2.2.0

I was made aware of the change from lipo to xcframework when trying to add v2.1.0 of the BEMCheckBox to a .NET 8 version of the XPlugins.iOS.BEMCheckBox project.

BEMCheckBox makes it easy to create beautiful, highly customizable, animated checkboxes for iOS. You can learn more about the project here:

https://github.com/saturdaymp/BEMCheckBox

Truth be told, I’m not very familiar with Xcode/Swift development, so if anyone notices any issues, please let me know by opening an issue or a pull request. Especially if the XCFramework file is not working for you.

Thank you Boris-Em for creating BEMCheckBox. Myself, and likely lots of other people, really appreciate it.

#saturdaymp #bemcheckbox #ios #swift #xcode #xcframework

🧙‍♂️✨Welcome to the magical world where #Haskell and #Swift somehow "talk," all wrapped up in a shiny #XCFramework package!📦🔧 Follow this riveting tale of dependency hell, where tech wizards tackle marshalling and the foreign function interface—because who needs simple, right? 😂🌀
https://alt-romes.github.io/posts/2025-07-05-packaging-a-haskell-library-as-a-swift-binary-xcframework.html #DependencyHell #TechWizards #HackerNews #ngated

Automatically Packaging a Haskell Library as a Swift Binary XCFramework

https://alt-romes.github.io/posts/2025-07-05-packaging-a-haskell-library-as-a-swift-binary-xcframework.html

#HackerNews #Haskell #Swift #XCFramework #Programming #Automation

During WWDC 2023, Apple presented a number of developer-impacting privacy updates. One of the updates, introducing the concept of a privacy manifest, has a direct impact on the work I’ve been doing making the CRDT library Automerge available on Apple platforms. The two relevant sessions from WWDC 2023:

Get Started with Privacy Manifests (video) (notes)
Verify app dependencies with digital signatures (video) (notes)

During the sessions, the presenter shared that somewhere in the coming year (2024) Apple would start requiring privacy manifests in signed XCFrameworks. There was little concrete detail available then, and I’ve been waiting since for more information on how to comply. I expected documentation at least, and was hoping for an update in Xcode – specifically the xcodebuild command – to add an option that accepted a path to a manifest and included it appropriately. So far, nothing from Apple on that front.

About a week ago I decided to use a DTS ticket to get assistance on how to (properly) add privacy manifest to an XCFramework (and filed feedback: FB13626419). I hope that something is planned to make this easier, or at the minimum document a process, since it now appears to be an active requirement for new apps presented to the App Store. I highly doubt we’ll see anything between now and WWDC at this point. With any luck, we’ll see something this June (WWDC 24).

I have a hypothesis that, with the updates to enable signed binary dependencies, there could be “something coming” about a software bill-of-materials manifest. My over-active imagination thinks there are hints of that correlated with what swift is recording in Package.resolved, and seeming to start to take advantage of within the proposed new approach to swift testing. It would make a lot of sense to support better verification and clear knowledge of what you’re including in your apps, or depending on for your libraries (and extremely useful metadata for testing validation).

In the meantime, if you’re Creating an XCFramework and trying to figure out how to comply with Apple’s requests for embedded privacy manifests, hopefully this article helps you get there. As I mentioned at the top of this post, this is based on my open source work in Automerge-swift. I’m including the library and XCFramework (and show it off) in a demo application. I just finished working through the process of getting the archives validated and pushed to App Store Connect (with macOS and iOS deliverables). To be very clear, the person I worked with at DTS was both critical and super-helpful. Without this information I would have been wandering blindly for months trying to get this sorted. All credit to them for the assistance.

The gist of what needs to be done lines up with Apple’s general platform conventions for placing resources into bundles (detailed at Placing Content in a Bundle). The resource in this case is the file PrivacyInfo.xcprivacy, and the general pattern plays out as:

iOS and iOS simulator: place the resource at the root for that platform
macOS and Mac Catalyst: place the resource in a directory structure /Versions/A/Resources/

The additional quirk in this case is that with an XCFramework created from platform-specific static libraries, you also need to put that directory structure underneath the directory that is the platform signifier. (An example is shown below, illustrating this. I know it’s not super clear; I don’t either know, or have, the words to correctly describe these layers in the a directory structure.)

I do this with a bash script that copies the privacy manifest into the place relevant for each platform target. In the case of automerge-swift, we compile to support iOS, the iOS simulators (on x86 and arm architectures), macOS (on x86 and arm architectures), and Mac Catalyst (on x86 and arm architectures).

Once the files are copied into place, I code sign the bundle:

codesign --timestamp -v --sign "...my developer id..." ${FRAMEWORK_NAME}.xcframework

After which, compress it down using ditto, and compute the SHA256 checksum. That checksum is used to create a validation hash for a URL reference in a Package.swift. (If you want to see the scripts, have at – they’re on GitHub. The scripts are split at the end – one for CI that doesn’t sign, and one for release that does.)

Seeing the layout of the relevant files in an XCFramework was the most helpful piece for me to assemble this together, so let me share the directory structure of my XCFramework. The example below, called automergeFFI.xcframework, hopefully shows you the details without flooding you in extraneous files; it skips the header or code signature specific files:

automergeFFI.xcframework/
  Info.plist
  _CodeSignature/

  macos-arm64_x86_64/Headers
  macos-arm64_x86_64/libuniffi_automerge.a
    Versions/A/Resources/
      PrivacyInfo.xcprivacy

  ios-arm64_x86_64-simulator
  ios-arm64_x86_64-simulator/Headers
  ios-arm64_x86_64-simulator/libuniffi_automerge.a
  ios-arm64_x86_64-simulator/PrivacyInfo.xcprivacy

  ios-arm64_x86_64-maccatalyst
  ios-arm64_x86_64-maccatalyst/
    Versions/A/Resources/
      PrivacyInfo.xcprivacy
  ios-arm64_x86_64-maccatalyst/Headers
  ios-arm64_x86_64-maccatalyst/libuniffi_automerge.a

  ios-arm64
  ios-arm64/Headers
  ios-arm64/libuniffi_automerge.a
  ios-arm64/PrivacyInfo.xcprivacy

With this in place, signed and embedded as a normal dependency through Xcode, both the iOS demo app and the macOS demo app passed the pre-flight validation and moved on through to TestFlight.

https://rhonabwy.com/2024/02/18/embedding-a-privacy-manifest-into-an-xcframework/

#swift #xcframework #xcode

@younata If you find a solution let me know because I’ve been looking for one too for the exact same reason. In my naïveté I thought build external target would be the way, and that’s how the documentation for it read to me, but it also runs after the xcframework exists checks and not before.

#Xcode15 #xcframework

Finally, one step closer: This only happens with binary targets/XCFramework. 🤨

#Swift #SPM #XCFramework #iOS

I'm #programming for desktop and mobile using #flutter but with #golang doing the heavy lifting. How? Like this: flutter calls a library in #dartlang that uses #ffi to call some #clang which acts as a bridge to call a library in an #xcframework which contains a set of platform and architecture dependent libraries written in go and compiled as a static libraries with an exposed c interface so that the ffi magic can work.

#XCFramework

Client Info