Distribute as XCFramework

[johankool]

Apple has introduced a new way to distributed binary frameworks XCFramework which (in theory) would make workarounds like the strip-frameworks.sh script unnecessary.

Is this something Mapbox could support?

[julianrex]

This is definitely something we would like to support. Keeping this ticket open and transferring.

[julianrex]

cc @nishant-karajgikar @frederoni

[julianrex]

This is blocked by xcframework support in Carthage.

[KaneCheshire]

This also impacts pure SPM projects because you can't currently even download the built binary to include in a local package

[johankool]

Relevant issues in Carthage: Carthage/Carthage#2881 Carthage/Carthage#2801 Carthage/Carthage#3071

[1ec5]

This is blocked by xcframework support in Carthage.

Upon closer inspection, I don’t think this work is blocked by any of the issues listed in #171 (comment):

• When building the map SDK from source for map SDK development purposes, it should be possible to build an XCFramework regardless of Carthage support for XCFramework, because Mapbox.framework is built completely independently of Carthage.
• When integrating the map SDK into an application project using Carthage, a developer can employ the script in Carthage builds fail at xcrun lipo on Xcode 12 beta (3,4,5...) Carthage/Carthage#3019 (comment) to work around carthage’s missing XCFramework support. Various other Mapbox projects have already adopted this workaround, which will also work after merging the Cartfile-based Carthage support in Distinguish between internal and external Carthage usage #548.

This also impacts pure SPM projects because you can't currently even download the built binary to include in a local package

Yes, #546 tracks SPM support and is blocked by XCFramework support.

[chazapis]

This is blocked by xcframework support in Carthage.

Carthage now supports xcframeworks. I have successfully compiled several packages into xcframeworks by running carthage update --no-use-binaries --use-xcframeworks using a compiled version of carthage from the master branch.

[simonseyer]

Hi. What's the timeline here? I just updated all our dependencies to use xcframeworks with a Carthage master build to fix build errors we experience and unfortunately this is the only dependency that is not available as xcframework and that we also cannot rebuild ourselves.

[ferologics]

^ What he said 😄 I'm trying to get my project running on an M1 mac book but I get:

Couldn't find framework at Carthage/Build/iOS/Mapbox.xcframework

Is anything blocking this? How can the community help move this along?

[fousa]

It would be great to get some kind of timeline. I've got the same problem, I would love to port my app to Mac, but preferably with Catalyst.

Mapbox is really the core of my app and for obvious reason. It's just the best map framework around.

[ferologics]

@nishant-karajgikar @frederoni could you take a look?

[1ec5]

mapbox/mapbox-maps-ios#48 tracks the same issue in MapboxMaps v10.

[mikehardy]

Until this is fixed I believe it blocks people upgrading to cocoapods 1.10+ from downstream projects, which puts the projects in a bind because other libraries have moved to .xcframework distribution specifically to support Apple Silicon / macOS-catalyst-variant, which necessarily requires 1.10+ so downstream projects can't update other libraries until this supports .xcframeworks / cocoapods 1.10+

likely invertase/react-native-notifee#230 (comment)
definitely transistorsoft/react-native-background-fetch#318 (comment)

[ferologics]

@1ec5 @julianrex did PR #2808 introduce binary XCFramework distribution? If so then this issue can be closed.

[noway]

@1ec5 @julianrex did PR #2808 introduce binary XCFramework distribution? If so then this issue can be closed.

This is a PR to mapbox-navigation-ios, mapbox-gl-native-ios still has no XCFramework support

[noway]

Any update on when this would be available? It is not possible to use mapbox on an iOS Simulator on an Apple Silicon mac atm. Resolving this should resolve #558

[mdab121]

Is there any way to unit test modules that include Mapbox SDK in Xcode 12 without XCFramework support? I'm stuck updating an old project with this. Is there a plan to support this?

[isoiphone]

Any updates?
xcframeworks are several years mature now, carthage support exists, M1 silicon Macs are more and more common.

[mikehardy]

I am only subscribed here because in other react-native repos I maintain this issue blows up their ability to use Apple Silicon since it is a transitive dependency, and I heard about it enough I listened here. Maybe this battle-tested xcframework builder will help. We use it for Notifee.app's library (in production, piles of users, no complaints with the built product). Been meaning to write a blog post since most of the libraries for react-native are based on old tutorials but haven't gotten a chance yet 🤷

I won't have time to PR anything but maybe this gives someone a start in case just getting it built was the holdup

Enjoy?

#!/bin/bash
set -eo pipefail

WORKING_DIR=$(pwd)
FRAMEWORK_FOLDER_NAME="YOURPROJECT_XCFramework"
FRAMEWORK_NAME="YOURPROJECTCore"
FRAMEWORK_PATH="${WORKING_DIR}/${FRAMEWORK_FOLDER_NAME}/${FRAMEWORK_NAME}.xcframework"
BUILD_SCHEME="YOURPROJECTCore"
SIMULATOR_ARCHIVE_PATH="${WORKING_DIR}/${FRAMEWORK_FOLDER_NAME}/simulator.xcarchive"
IOS_DEVICE_ARCHIVE_PATH="${WORKING_DIR}/${FRAMEWORK_FOLDER_NAME}/iOS.xcarchive"
CATALYST_ARCHIVE_PATH="${WORKING_DIR}/${FRAMEWORK_FOLDER_NAME}/catalyst.xcarchive"
OUTPUT_FOLDER=${WORKING_DIR}/../packages/react-native/ios/

rm -rf "${WORKING_DIR:?}/${FRAMEWORK_FOLDER_NAME}"
echo "Deleted ${FRAMEWORK_FOLDER_NAME}"
mkdir "${FRAMEWORK_FOLDER_NAME}"
echo "Created ${FRAMEWORK_FOLDER_NAME}"

echo "Archiving for iOS Simulator"
xcodebuild archive -workspace "./${FRAMEWORK_NAME}.xcworkspace" -scheme ${BUILD_SCHEME} -configuration Release \
  -destination="iOS Simulator" -archivePath "${SIMULATOR_ARCHIVE_PATH}" \
  -sdk iphonesimulator SKIP_INSTALL=NO BUILD_LIBRARY_FOR_DISTRIBUTION=YES | xcpretty -k

echo "Archiving for iOS"
xcodebuild archive -workspace "./${FRAMEWORK_NAME}.xcworkspace" -scheme ${BUILD_SCHEME} -configuration Release \
  -destination="iOS" -archivePath "${IOS_DEVICE_ARCHIVE_PATH}" \
  -sdk iphoneos SKIP_INSTALL=NO BUILD_LIBRARY_FOR_DISTRIBUTION=YES | xcpretty -k

# Do not be tempted to use "-sdk macosx" instead of the "destination" argument. It switches you to AppKit from UIKit
# https://developer.apple.com/forums/thread/120542?answerId=374124022#374124022
echo "Archiving for Mac Catalyst"
xcodebuild archive -workspace "./${FRAMEWORK_NAME}.xcworkspace" -scheme ${BUILD_SCHEME} -configuration Release \
  -destination='platform=macOS,arch=x86_64,variant=Mac Catalyst' -archivePath "${CATALYST_ARCHIVE_PATH}" \
  SKIP_INSTALL=NO BUILD_LIBRARY_FOR_DISTRIBUTION=YES | xcpretty -k

echo "Packaging archives into ${FRAMEWORK_NAME}.xcframework bundle"
xcodebuild -create-xcframework \
  -framework "${SIMULATOR_ARCHIVE_PATH}/Products/Library/Frameworks/${FRAMEWORK_NAME}.framework" \
  -framework "${IOS_DEVICE_ARCHIVE_PATH}/Products/Library/Frameworks/${FRAMEWORK_NAME}.framework" \
  -framework "${CATALYST_ARCHIVE_PATH}/Products/Library/Frameworks/${FRAMEWORK_NAME}.framework" \
  -output "${FRAMEWORK_PATH}" | xcpretty

rm -rf "${SIMULATOR_ARCHIVE_PATH}"
rm -rf "${IOS_DEVICE_ARCHIVE_PATH}"
rm -rf "${CATALYST_ARCHIVE_PATH}"

# Catalyst framework directory structure flattening step 1:
# - Copy the framework in a specific way: de-referencing symbolic links on purpose
echo "Installing framework into packages/react-native submodule"
rm -rf "${OUTPUT_FOLDER}/${FRAMEWORK_NAME}.xcframework" && \
  cp -rp "${FRAMEWORK_PATH}" "${OUTPUT_FOLDER}"

# Catalyst framework directory structure flattening step 2:
# - Remove the catalyst framework "Versions" directory structure after symbolic link de-reference
rm -rf "${OUTPUT_FOLDER}/${FRAMEWORK_NAME}.xcframework/ios-arm64_x86_64-maccatalyst/${FRAMEWORK_NAME}.framework/Versions"

echo "Cleaning up intermediate files"
rm -rf "${WORKING_DIR:?}/${FRAMEWORK_FOLDER_NAME}"

[klundberg]

If you look at the read me to this repo, they suggest upgrading to sdk v10 in a different repo from this which does support SPM. I haven't tried it yet but looks like they're in release candidate stage so a final release should be coming any day now.

There's also the maplibre repo on GitHub that can also run in spm if you're ok with a 5.x sdk and don't want to migrate to 10 yet

[NathanWalker]

I really don't want to ping this issue again as there's been plenty enough discussion but is there any way a core member of MapBox team could provide a general expectation on when .xcframework support would be available without manually modifying with scripts/Carthage, etc. Just curious since the release candidate stage was in June so seems like something is close?

[klundberg]

The mapbox v10 sdk in a different repo is SPM compatible which means it's an xcframework. I doubt they'll make this v6 sdk available that way too with v10 almost out.

[NathanWalker]

Ok excellent thanks @klundberg will try that one.

[noway]

react-native-mapbox-gl still uses v6, so ideally we get xcframework support for that too...