Add Swift Package Manager support

[ChrisPearce]

It would be very helpful if Swift Package Manager was supported by including a Package.swift file.

[pascalfriedrich]

Is there a timetable when the support will be added?

[jboisjo]

We need this badly as well :(

[glatour]

I can't wait to have the library moved to the swift package manager!!!

[mitchdenny]

Any update on plans for supporting Swift Package Manager. We are taking a dependency on this library and would like to support folks using Swift PM.

[kincade-dev]

Please add this!

[oldalton]

We could use some community help with this one :) I did some experimentation and it seems difficult to get it working considering we're heavily using prefix files and nested folders. Would appreciate any references of a successful example of SPM for Objective-C library without refactoring project structure too much, or examples of getting header search working with nested folders. Feel free to directly contribute as well.

[VladIacobIonut]

@oldalton Hi, I think Realm could be a good example of a library which is available via SPM and is written in Obj-C also. I hope it helps.

[kbartyzel]

Any update on this? This is critical

[nidegen]

@oldalton nested folders should not be a problem, but what do you mean with prefix files?

Edit: I see, the .pch. I may have a look at it

[nidegen]

@brandwe @rohitnarula7176 I would put that on top of your list, makes life much easier for many;)

[oldalton]

@nidegen, thanks for providing your input. Can you give more details about getting Swift package manager to work with nested folders? The only way I got it to work is to declare all paths separately which is very difficult to maintain as well as symlinking public headers (see some experimentation here: https://github.com/AzureAD/microsoft-authentication-library-common-for-objc/compare/dev...oldalton/swift_package_manager_support?expand=1). For CocoaPods we just use wildcards to resolve nested folders, but there doesn't seem to be the same way for Swift package manager.

If you have some ideas how to make SPM support a little bit more maintainable, or you would like to contribute a PR from your side, your help/advice would be appreciated :)

[nidegen]

Yes I started a fork but declaring all nested paths. I think that is the only way currently.

• Is that a no-go? Do the paths change that often?
  -Reorganize the nested folders is not an option?

[KyLeggiero]

Thanks, @nidegen! In my experience, that's acceptable - just add another item to the release checklist to make sure these are in-sync

[oldalton]

@nidegen, I think even after adding all paths I still couldn't make it to work (as you can see in my branch). If you can get it to work for MSAL, we'd welcome a PR in our main repository such as other people could also benefit from it :)

[nidegen]

@oldalton yea I saw your branch. Quite some changes. Lets see!

[KyLeggiero]

Any progress on this? I'm about to integrate MSAL into our codebase and would love to do that as a Swift package!

[oldalton]

@BenLeggiero, we're still looking forward for an external help/contribution on this one! We've tried a few more options, but seems that SPM doesn't work very well with submodules either.

[KyLeggiero]

Thanks for the update, @oldalton. I might try my hand at it sometime later. Sad to hear SPM and Git Submodules aren't friends; hopefully that changes soon.

[bsiegel]

A quick update - Apple announced during WWDC this year that SwiftPM will now support binary framework packages, providing a way forward for projects that use native code, ObjC, or use structures that are not conducive to shipping as a native source-based SwiftPM package, to onboard to SwiftPM.

This means that in order to support SwiftPM, the MSAL team should only need to compile the library into an .xcframework, and provide a Package.swift metadata file in the repo for SwiftPM. Once that's done people will be able to consume the dependency via SwiftPM. The project is already structured to compile into a framework so it shouldn't require changes to the project structure. However the MSAL team doesn't distribute pre-compiled copies today (the releases are only project sources), so they would need to begin building it into frameworks (and then combining those into a meta xcframework) as part of the release process.

[mitchdenny]

Following on what @bsiegel mentioned. I did some experiments building the various .framework files using xcodebuild and then creating the xcframework file. It all works fine with the code base as it stands at the moment. All that would be required is the addition of a Package.swift file to the repository that points to the location of that binary framework.

My suggestion would be that you add the steps to produce the .framework files and the .xcframework files to your build process and so when you tag your repository you upload the associated .xcframework. The Package.swift file would be updated prior to creating the tag so that it contains a pointer to the location of the .xcframework file in GitHub releases. At which point I think it should all just work.

Note that to actually consume the packages folks will need Xcode 12, but to produce them I think that there is everything that is required already in Xcode 11.

[danielelkington]

This is working now - I think this issue can be closed.

[ameyapat]

Using MSAL as a swift package dependency is available in release 1.1.14. To use it as a package dependency please follow : https://github.com/AzureAD/microsoft-authentication-library-for-objc#using-swift-packages

Please let us know if there are any issues regarding this and thanks for your patience!

[zntfdr]

@ameyapat (and the rest of the MSAL team) thank you for adding SPM support! 👏🏻

Everything works great while debugging, however after archiving the export ipa now fails with the following error:

error: exportArchive: IPA processing failed

Error Domain=IDEFoundationErrorDomain Code=1 "IPA processing failed" UserInfo={NSLocalizedDescription=IPA processing failed}

The only change I did is removing the MSAL pod and add the dependency via SPM following the linked guide:
https://github.com/AzureAD/microsoft-authentication-library-for-objc#using-swift-packages

Do you have any leads on this? Thank you in advance 🙏🏻

[ChrisPearce]

Thanks for adding SPM support.

I can compile successfully but I'm encountering the following error when submitting the package to the App Store:
2021-01-26T03:06:24.0949520Z [03:06:24]: WARNING ITMS-90806: "CFBundleIdentifier collision. Each bundle must have a unique bundle identifier. The bundle identifier 'com.microsoft.MSAL' is used in the bundles '[Payload/MyApp.app/Frameworks/MSAL.framework, Payload/MyApp.app/PlugIns/MSAL.framework]'"

[ameyapat]

@ChrisPearce Looks like a SPM bug where frameworks get copied under Frameworks and Plugins when building as per : https://forums.swift.org/t/swift-package-binary-framework-issue/41922/3. I guess for now the workaround is to have a script to remove the framework when building : https://forums.swift.org/t/swift-package-binary-framework-issue/41922/3

[ameyapat]

@zntfdr What do the distribution logs say when IPA processing fails? Maybe the .app has MSAL.framework embedded at multiple locations causing this issue. Could you try the same workaround as I mentioned in above comment : https://forums.swift.org/t/swift-package-binary-framework-issue/41922/3

[zntfdr]

@ameyapat Thank you! Adding the script phase works! 🎉

For other people with this issue, here's the complete script phase that needs to be added:

Explanation:

1. add the following script to cleanup extra frameworks from your app plugins

#!/bin/bash

COUNTER=0
while [ $COUNTER -lt "${SCRIPT_INPUT_FILE_COUNT}" ]; do
    tmp="SCRIPT_INPUT_FILE_$COUNTER"
    FILE=${!tmp}

    echo "Removing $FILE"
    rm -rf "$FILE"
    let COUNTER=COUNTER+1
done

2. check For install builds only to run this script only when archiving (I know, the name is 🤷🏻‍♂️), this script is not needed when debugging
3. add $(BUILT_PRODUCTS_DIR)/$(PLUGINS_FOLDER_PATH)/MSAL.framework in the script phase Inputs, this is the framework that will be removed when the script is run.

This is a known SPM bug, it's even mentioned in the Xcode 12.4 release notes:

This is a temporary workaround that should be removed once fixed in Xcode (fingers crossed for Xcode 12.5 🤞🏻)

[cassianodialpad]

I'm facing a different issue here. It works fine running on simulator, but then I get the error below when trying to run on device. I have a workspace with a framework as an umbrella for SPM dependencies, and it works fine with all other dependencies I have. I was using MSAL with carthage before, and no issues. This happens only when adding MSAL to my SPM dependencies.
I do not have any references to MSAL on my app's project, it's all encapsulated inside my umbrella framework.

Worth noting that it looks like all other dependencies are static libraries embedded to my framework, but MSAL is being copied as a dynamic framework to my framework's Frameworks folder. I tried to delete it as per the workaround mentioned on Xcode 12.4 release notes, but no luck.

dyld: Library not loaded: @rpath/MSAL.framework/MSAL
  Referenced from: /private/var/containers/Bundle/Application/58E5E538-CD2D-45E2-970B-A8883EB56CFC/Dialpad.app/Frameworks/SDPCore.framework/SDPCore
  Reason: no suitable image found.  Did find:
	/private/var/containers/Bundle/Application/58E5E538-CD2D-45E2-970B-A8883EB56CFC/Dialpad.app/Frameworks/SDPCore.framework/Frameworks/MSAL.framework/MSAL: code signature in (/private/var/containers/Bundle/Application/58E5E538-CD2D-45E2-970B-A8883EB56CFC/Dialpad.app/Frameworks/SDPCore.framework/Frameworks/MSAL.framework/MSAL) not valid for use in process using Library Validation: mapped file has no cdhash, completely unsigned? Code has to be at least ad-hoc signed.

[guidedways]

I'm facing a different issue altogether - it does not seem to work for a macOS app. I see a CodeSign Failed build time error:

CodeSign /Users/MyUser/Library/Developer/Xcode/DerivedData/MyApp-dfxaoncuargnurehqwjntcnqwbzd/Build/Products/Debug/MyApp.app (in target 'MyApp' from project 'MyApp')
    cd /Users/MyUser/Development/git/MyApps/calendar
    export CODESIGN_ALLOCATE\=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/codesign_allocate
    
Signing Identity:     "Apple Development: XXXXXXX"
Provisioning Profile: "Mac Team Provisioning Profile: com.MyApp.myApp"
                      (XXXXXXX)

    /usr/bin/codesign --force --sign 90EA95F14F419C329E568F32D3F68026EFC61BB1 --entitlements /Users/MyUser/Library/Developer/Xcode/DerivedData/MyApp-dfxaoncuargnurehqwjntcnqwbzd/Build/Intermediates.noindex/MyApp.build/Debug/MyApp\ Trial.build/MyApp.app.xcent --timestamp\=none /Users/MyUser/Library/Developer/Xcode/DerivedData/MyApp-dfxaoncuargnurehqwjntcnqwbzd/Build/Products/Debug/MyApp.app

/Users/MyUser/Library/Developer/Xcode/DerivedData/MyApp-dfxaoncuargnurehqwjntcnqwbzd/Build/Products/Debug/MyApp.app: code object is not signed at all
In subcomponent: /Users/MyUser/Library/Developer/Xcode/DerivedData/MyApp-dfxaoncuargnurehqwjntcnqwbzd/Build/Products/Debug/MyApp.app/Contents/Frameworks/MSAL.framework
Command CodeSign failed with a nonzero exit code

I also strangely see a Current folder (which should really be a symbolic link) in the MSAL.framework folder:

[ameyapat]

@guidedways Your issue might be related to this SPM issue. I would suggest the following : In your project's target -> Build Phases

• Add Copy Files phase with destination as Frameworks
• After that add Run script phase with rm -rf "${CODESIGNING_FOLDER_PATH}/Contents/Frameworks/MSAL.framework" (Similar to this suggestion )

[ameyapat]

@cassianodialpad Not totally sure but your issue might be related to this SPM bug : https://bugs.swift.org/browse/SR-13366

[guidedways]

@ameyapat That worked when I tried building the project, but fails when I try running the app under the debugger with the same error. I've give up for now as this seems far more painful than simply adding a direct dependency to Xcode.

[cassianodialpad]

@cassianodialpad Not totally sure but your issue might be related to this SPM bug : https://bugs.swift.org/browse/SR-13366

@ameyapat Yes, probably... I was able to work around it by codesigning my internal umbrella framework and then moving MSAL to my app's Frameworks folder with this build post action:

mv "${TARGET_BUILD_DIR}/${PRODUCT_NAME}.app/Frameworks/Umbrella.framework/Frameworks/MSAL.framework" "${TARGET_BUILD_DIR}/${PRODUCT_NAME}.app/Frameworks/MSAL.framework"

[ameyapat]

Closing this issue. Will highlight some of these workaround in README. If there are any issues related to MSAL swift package dependency, please open a new issue. Thanks!

[guidedways]

@ameyapat We're still seeing issues trying to make this work for a mac app - the workaround does not help.

[ameyapat]

@guidedways The issue seems to be caused because of swift package manager bug and not related to MSAL. The workaround provided had worked with our sample app when I tried it. Can you open a separate issue providing more details about the issue that you are facing?

[mthielemann]

I also strangely see a Current folder (which should really be a symbolic link) in the MSAL.framework folder:

I see the exact same issue. Could make it work by doing this in a Run Script build phase:

rm -rf "${CODESIGNING_FOLDER_PATH}/Contents/Frameworks/MSAL.framework/"{Headers,Modules,MSAL,Resources}
rm -rf "${CODESIGNING_FOLDER_PATH}/Contents/Frameworks/MSAL.framework/Versions/Current"
rm -rf "${CODESIGNING_FOLDER_PATH}/Contents/Frameworks/MSAL.framework/Versions/A/"{Headers,Modules}
cd "${CODESIGNING_FOLDER_PATH}/Contents/Frameworks/MSAL.framework/Versions"
ln -s "A" "Current"
cd "${CODESIGNING_FOLDER_PATH}/Contents/Frameworks/MSAL.framework/"
ln -s "Versions/Current/Resources" "."
ln -s "Versions/Current/MSAL" "."

[lrun-cmck]

Is there any fix for the following issue ? MyApp has MyAppBusiness framework embedded (Embed & Sign) which has a reference to MSAL using SPM. Thanks a lot !

dyld: Library not loaded: @rpath/MSAL.framework/MSAL
  Referenced from: /private/var/containers/Bundle/Application/F786A873-7DC4-45CF-AFE2-2F3C3FD17BD3/MyApp.app/Frameworks/MyAppBusiness.framework/MyAppBusiness
  Reason: no suitable image found.  Did find:
	/private/var/containers/Bundle/Application/F786A873-7DC4-45CF-AFE2-2F3C3FD17BD3/MyApp.app/Frameworks/MyAppBusiness.framework/Frameworks/MSAL.framework/MSAL: code signature in (/private/var/containers/Bundle/Application/F786A873-7DC4-45CF-AFE2-2F3C3FD17BD3/MyApp.app/Frameworks/MyAppBusiness.framework/Frameworks/MSAL.framework/MSAL) not valid for use in process using Library Validation: mapped file has no cdhash, completely unsigned? Code has to be at least ad-hoc signed.
dyld: launch, loading dependent libraries
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

[ameyapat]

@lrun-cmck This seems like an issue with SPM. There seems to be discussion on it.Have you tried the workaround?

[lrun-cmck]

@ameyapat https://pspdfkit.com/guides/ios/10.2/knowledge-base/library-not-found-swiftpm/ for v10.2 worked. Thanks !

[guidedways]

@ameyapat https://pspdfkit.com/guides/ios/10.2/knowledge-base/library-not-found-swiftpm/ for v10.2 worked. Thanks !

Did not work for me.

[WouterStraver]

I'm currently facing the exact same issues as @guidedways. It works fine on iOS but it does not work with MacOS. Even with the workarounds mentioned above.

[guidedways]

I'm currently facing the exact same issues as @guidedways. It works fine on iOS but it does not work with MacOS. Even with the workarounds mentioned above.

I've given up, downloaded the project and using it directly as a reference since we don't use Cocoapods anymore.

[phil1995]

Is it possible that you also publish an App-Extension-Safe target like you did for CocoaPods?
Because currently when including it in an app extension the following warning appears:
ld: warning: linking against a dylib which is not safe for use in application extensions: /Library/Developer/Xcode/DerivedData/XXX/Build/Products/Debug-iphonesimulator/MSAL.framework/MSAL

[schlingding]

Did Xcode 13 break the workaround here? After having this fix for almost a year we're back to this error.

Command CodeSign failed with a nonzero exit code

We also get the warning

Couldn't resolve framework symlink for '/Users/user/Library/Developer/Xcode/DerivedData/ExampleApp/SourcePackages/artifacts/MSAL/MSAL.xcframework/macos-arm64_x86_64/MSAL.framework/Versions/Current': readlink(/Users/user/Library/Developer/Xcode/DerivedData/ExampleApp/SourcePackages/artifacts/MSAL/MSAL.xcframework/macos-arm64_x86_64/MSAL.framework/Versions/Current): Invalid argument (22)

[guidedways]

Just a remark - recently Google added SPM support to Firebase. If they can get firebase to play ball with SPM with zero tinkering, why can't MSAL?

[schlingding]

This may be due to the use of binaryTarget

[ferantivero]

@guidedways after following the workaround in here with SPM + Xcode 13.2.1 + Swift 5.5 I've just been able to get a Build Succeeded but it is sort of unstable :)

First time you attempt to build, you will get the CodeSign error that ends up with a Build Failed as you/others and I were experiencing, but then if you go for a second attempt "without cleaning the build folder" you get it successfully built.

👀 @ameyapat some observations on top of the provided workaround, but please note this is just SPM-based and not for CocoaPods:

1. The order of the added Build Phases won't affect this behavior
2. The Copy File Phase doesn't seem to be required at all. Not sure if some extra details are required despite Destination: Frameworks
3. Marking ✅ Use discovery dependency file from the Run Script Phase seems to be delivering consistent Successful Builds "even after cleaning the build folder". Xcode will display an extra non-zero exit error though, yet the macOS application manage to get up & running.