Added Swift Package Manager support.

[rokgregoric]

This works out of the box .. I just had to add Package.swift and create a release with the correct format x.x.x

[blainesolomon]

Can you guys add this? @afh

[gorbat-o]

I am looking for this update too! :) thanks

[Lizard381]

Am also looking for this update!

[mpdifran]

Was just about to open a PR for this, looking forward to getting it in!

[callo90]

Any updates about this?

[afh]

Thanks for adding this PR @rokgregoric and everyone else for the interest in it.

We've been watching the Swift issues related to binary target codesigning (see SR-13343 and SR-13345), both of which are still marked as open. We would like to see these issues resolved officially before merging this PR as there have been mixed reports about this issue on the Swift forum.

Have people on this issue been able to upload and validate (possibly even distribute) an application archive with iTunes Connect that integrates LinkKit.xcframework via SPM?

[gorbat-o]

Hey Guys.

I can't create an issue or anything. But It would be nice if there was an integration with SwiftUI. Since the version 2.0 of the SDK, we are not able to easily handle the VC created by Plaid. Now we have to use a Handler that doesn't handle SwiftUI. Unless i missed something.

Thanks!! :)

[callo90]

Thanks for adding this PR @rokgregoric and everyone else for the interest in it.

We've been watching the Swift issues related to binary target codesigning (see SR-13343 and SR-13345), both of which are still marked as open. We would like to see these issues resolved officially before merging this PR as there have been mixed reports about this issue on the Swift forum.

Have people on this issue been able to upload and validate (possibly even distribute) an application archive with iTunes Connect that integrates LinkKit.xcframework via SPM?

I'm about to do that, I'll let you know.

[wkiefer]

Hey Guys.

I can't create an issue or anything. But It would be nice if there was an integration with SwiftUI. Since the version 2.0 of the SDK, we are not able to easily handle the VC created by Plaid. Now we have to use a Handler that doesn't handle SwiftUI. Unless i missed something.

Thanks!! :)

Thanks for mentioning this! I've filed an internal task to update our SwiftUI example to use our 2.0 SDK.

[afh]

Did not mean to close this issue, apologies for the hiccup.

[gorbat-o]

Hey Guys. I can't create an issue or anything. But It would be nice if there was an integration with SwiftUI. Since the version 2.0 of the SDK, we are not able to easily handle the VC created by Plaid. Now we have to use a Handler that doesn't handle SwiftUI. Unless i missed something. Thanks!! :)

Thanks for mentioning this! I've filed an internal task to update our SwiftUI example to use our 2.0 SDK.

Thank you so much! I appreciate it greatly! Right now I am using a hack to present it.

It looks like this

struct PlaidView: UIViewControllerRepresentable {
    public typealias UIViewControllerType = UIViewController

    var handler: Handler?

    init(withHandler handler: Handler) {
        self.handler = handler
    }

    public func makeUIViewController(context: UIViewControllerRepresentableContext<PlaidView>) -> UIViewController {
        let viewController = UIViewController()
        viewController.view.backgroundColor = .clear
        let presentationMethod = PresentationMethod.viewController(viewController)
        DispatchQueue.main.asyncAfter(deadline: .now() + 0.2, execute: {
            handler?.open(presentUsing: presentationMethod)
        })
        return viewController
    }

    public func updateUIViewController(_ uiViewController: UIViewController, context: UIViewControllerRepresentableContext<PlaidView>) {
        //
    }
}

There are two issues here.

• I have to present a blank page first before being able to open the PlaidVC.
• and then delay the PlaidVC by a little to let the first view to load.

It is really hacky but it gets me where i need at the moment. Didn't have time to research deeper. Thanks again!

[mpdifran]

Love to see the active conversation here. Can we enable issues on this repo so we can keep track of things like SwiftUI support in their own issues instead of this one PR?

[Lizard381]

@afh We were able to integrate LinkKit in and get it signed but it was definitely a bandaid solution. We have a modular app, and the signing did not work when we added it through a separate framework, but it did work when we added it to the main framework instead. It's a bandaid because it implicitly depends on the main framework being compiled and having its dependencies resolved before any of the other frameworks in our app.

[banane]

Have people on this issue been able to upload and validate (possibly even distribute) an application archive with iTunes Connect that integrates LinkKit.xcframework via SPM?

We're trying to use the xcframework to no avail - get 90125 and 90208. Excited to see SPM here!

[afh]

Thanks @Lizard381 for your report. We'd like to avoid bandaid solutions or requiring custom Build Phases to re-sign.

[afh]

Thank you @banane for chiming in. Can you provide a bit more information, please? I assume 90125 and 90208 are error codes, maybe you could provide the logs for compile and linking stage and some information about your environment?

% sw_vers
% xcode-select --print-path
% xcodebuild -version
% swift --version
% clang --version

[afh]

The error message for the errors mentioned by @banane is:

ERROR ITMS-90125: "The Binary is invalid. The encryption info in the LC_ENCRYPTION_INFO load command is either missing or invalid, or the binary is already encrypted. This binary does not seem to have been built with Apple's Linker."

ERROR ITMS-90208: "Invalid Bundle. The bundle does not support the minimum OS Version specified in the Info.plist"

[banane]

sry @afh the errors were with the usual cocoapods - not with this SPM. I'm going to try this SPM today and see if I get a better result. We filed a ticket with you (via Homebase- Jordan) to hopefully get some help on those release errors from Itunes transport.

[callo90]

Thanks for adding this PR @rokgregoric and everyone else for the interest in it. We've been watching the Swift issues related to binary target codesigning (see SR-13343 and SR-13345), both of which are still marked as open. We would like to see these issues resolved officially before merging this PR as there have been mixed reports about this issue on the Swift forum. Have people on this issue been able to upload and validate (possibly even distribute) an application archive with iTunes Connect that integrates LinkKit.xcframework via SPM?

I'm about to do that, I'll let you know.

With SPM the framework installs correctly and runs correctly but for archive is not working.

Getting this error exportArchive: IPA processing failed something is missing.

[rogerluan]

Hey guys, sorry I'm late for the party 😄

At @zillyinc we added this simple Package.swift to our fork: https://github.com/zillyinc/plaid-link-ios/blob/spm/Package.swift Then integrated it to our project using Xcode's built-in SPM integration.

However, after it archived correctly and exported correctly, it failed App Store Connect's binary validation with the following errors: ERROR ITMS-90680 and ERROR ITMS-90685.

The solution is not pretty, but works flawlessly:

Click to expand the code snippet

```bash #!/bin/bash # When adding a Swift Binary Package to an Xcode project that also have an extension, the binary package will be copied both to the Plugins folder and the Frameworks folder. # This was happening to our LinkKit (aka Plaid) framework, and will likely happen to other binary dependencies as well. # When new dependencies face this problem, simply add them to the "Input Files" below, renaming only the "xxxx.framework" suffix. # For more info, see: https://forums.swift.org/t/swift-package-binary-framework-issue/41922 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 ```

Note that this issue is present not only for LinkKit, but (apparently all) other .xcframework SPMs, as you can see in the screenshot.

Hope this helps everyone out there! I'd love to see this PR merged. We've been using Plaid with SPM for a few weeks now.

[banane]

We are still unable to upload our binary (using Cocoapods not SPM) The build instruction is still building LinkKit as a simulator build, not a device build.

It archives correctly on my local environment, but not on our remote CircleCI Ci environment. Great! My computer is now the release machine ;)

% sw_vers - ProductName: Mac OS X ProductVersion: 10.15.4 BuildVersion: 19E266 % xcode-select --print-path - /Applications/Xcode-11.5.GM.Seed.app/Contents/Developer % xcodebuild -version Xcode 11.5 Build version 11E608c % swift --version Apple Swift version 5.2.4 (swiftlang-1103.0.32.9 clang-1103.0.32.53) Target: x86_64-apple-darwin19.4.0 % clang --version 11.0.3 (clang-1103.0.32.62)

@afh if there's some other place to file an issue, I can do that. I saw some relevant SO posts re: the opposite- that simulator was hard to build, but haven't seen much re: the device build being a problem.

[zachrnolan]

@wkiefer any updates on the SwiftUI example for Plaid 2.0?

[ericlewis]

@zachrnolan this may interest you: https://gist.github.com/ericlewis/d296b8ad0c6d12f91ca6dd130baf0137

[afh]

Apologies @zachrnolan for not following up on this sooner, and thank you @ericlewis for contributing the gist.

An example for SwiftUI was added with ViewController+SwiftUI.swift and LinkKitSwiftUISupport.swift in 75fcdc0

[PaulRiviera]

@afh while those examples are helpful it still assumes the app is using the UIKit App Delegate life cycle, are there any examples showing how to implement PlaidLink 2.0 with the SwiftUI App life cycle?

[afh]

@PaulRiviera regrettably there is not currently.

Yet I've been able to get an admittedly very basic MWE up and running by using Xcode's default project template with SwiftUI Interface and SwiftUI App Life Cycle, adding LinkKitSwiftUISupport.swift to the project, changing the *App.swift as follows, and replacing <#LINK_TOKEN#> with an actual link token retrieved from /link/token/create:

import LinkKit
import SwiftUI

@main
struct SwiftUILifeCycleExampleApp: App {
    var linkConfiguration: LinkController.LinkConfigurationType {
        .linkToken(
            LinkTokenConfiguration(
                token: "<#LINK_TOKEN#>",
                onSuccess: { (success) in
                    print(success)
                })
        )
    }
    var body: some Scene {
        WindowGroup {
            LinkController(configuration: linkConfiguration)
        }
    }
}

Is this helpful for you? I'd appreciate your feedback if this is headed in the right direction for you, so we could consider this as a SwiftUI App Life Cycle example.

[ericlewis]

@afh @PaulRiviera btw, there are ways to hook into the lifecycle of an App type in SwiftUI via @UIApplicationDelegateAdaptor

example:

import SwiftUI

@main
struct MyApp: App {
    @UIApplicationDelegateAdaptor(AppDelegate.self) var appDelegate

    var body: some Scene {
        WindowGroup {
            ContentView()
        }
    }
}

class AppDelegate: NSObject, UIApplicationDelegate {
    func application(
        _ application: UIApplication,
        didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]? = nil
    ) -> Bool {
        // Do things
        return true
    }
}

[afh]

Thanks @ericlewis!

@PaulRiviera are the last two comments with examples helpful for you?

[joshuakcockrell]

@afh I'm actively trying to get Plaid working in SwiftUI. I can confirm your example works in a pure SwiftUI app.

[afh]

Thanks for the feedback @joshuakcockrell. Anything specific that you needed to change or do to make it work?

[ericlewis]

@joshuakcockrell I'd also be happy to help you if need be, we have it working fine

[sschizas]

Any update on this one?

[rolandobermudez]

Hello, is there any plans to support swift packages in Plaid?

[romero-ios]

Would love to see this get merged

[joshuadavid8]

merge

[gregiOS]

Any merge date?

[netspencer]

What's currently holding this back from being merged?

[rogerluan]

At this point? Plaid engineering team caring about their customers, that's what's holding them back 🙄

[jacobhzen]

We're looking to use SPM (and not cocoa pods).

Any possibility we can get this merged @afh ?

[afh]

Thanks for the continued interest, @netspencer, @rogerluan, @jacobhzen.

The open Swift issues related to binary target codesigning (see SR-13343 and SR-13345) and reports on the Swift forum this can still occur with Xcode 13 are holding this back from being merged.

We much prefer to offer an integration via SPM that works out of the box without a "bandaid solution" or requiring any additional steps.

Who here is integrating LinkKit using SPM and has successfully distributed their application via ASC without any additional steps and without running into any issues related to codesigning, the use of binaryTarget, or XCFramework? Please chime in, we'd love to hear from you!

[rogerluan]

@afh appreciate your input, but at least for our team, it's more beneficial to have a working solution (whether or not it requires some extra one-off steps), than to have no SPM solution at all 🤷 that would be up to the SDK user to decide - it's not like CocoaPods support would be removed or so.

As I said in my message above (the one that highlights how to workaround the ASC invalid binary validation), this is the case for all .xcframeworks out there - so, needless to say that we've added that workaround for several SPMs out there. It sucks, but no biggie IMO. A fix from Apple will be very much welcome, but until then, this isn't stopping us from moving away from CocoaPods. 😊

[jacobhzen]

Agreed, Plaid is the only dependency in our app without an SPM solution (even if it requires an extra step or two). We would prefer to not integrate cocoapods.

[rolandobermudez]

Here I am in the same situation, our app only cocoapods dependency is Plaid, we would like to move it to SPM as well.

[rokgregoric]

For anyone that needs SPM support .. you can use https://github.com/opendoor-labs/odhb-plaid-link-ios -> branch main:

[rokgregoric]

Closed -> please refer to: https://github.com/plaid/plaid-link-ios/pull/15

[rogerluan]

@rokgregoric you reckon there's no code difference between this PR and the new PR right? 🤔

[rokgregoric]

@rogerluan yes! just PR is directed to a different branch, master instead of main-v2

[afh]

@rogerluan Do you happen to have a radar or other ticket for the binary validation issue by any chance? Would be good to have for future reference and documentation once support from SPM is added to LinkKit.

[rogerluan]

@afh nope, sorry!