`BTConfiguration.canMakeApplePayPayments` and `applePaySupportedNetworks `are inaccessible (internal) in v6

[Smertowing]

Braintree SDK Version

6.39.0

Environment

Both

Xcode Version

16.4

OS Version & Device

No response

Integration type

Prebuilt Binaries / Other

Development Processor

Both

Describe the bug

While migrating our app from an older Objective-C implementation to v6 of the SDK with Swift, I discovered that BTConfiguration.canMakeApplePayPayments is now internal. This prevents us from checking whether Apple Pay is configured and available for the current merchant account and device.

A potential workaround using Apple's native PKPaymentAuthorizationViewController.canMakePayments(usingNetworks:) directly is also blocked because the required BTConfiguration.applePaySupportedNetworks property is also internal. This is a regression from Objective-C versions where these properties were public.

We were using this property to determine if the user's Apple Pay method is supported by Braintree for our merchant account, and we want to avoid hardcoding payment networks on the client side. This leads to two main questions:

1. Was this an intentional API change in v6? I noticed canMakeApplePayPayments does not appear to be used anywhere within the SDK itself, which led me to wonder if its removal from the public API was an oversight.

2. Is it safe to use a local patch? As a temporary workaround, I'm considering forking the repository and changing the protection level of canMakeApplePayPayments to public. Are there any potential risks or side effects we should be aware of with this approach?

To reproduce

Steps to reproduce the behavior:

• Integrate Braintree iOS SDK v6.x into a Swift project.
• Attempt to access configuration.canMakeApplePayPayments.
• The compiler will produce the error: 'canMakeApplePayPayments' is inaccessible due to 'internal' protection level.

Example Code:

import Braintree

// ...

let braintreeApiClient = BTApplePayClient(apiClient:)

braintreeApiClient.fetchOrReturnRemoteConfiguration { (configuration, error) in
    guard let configuration = configuration, error == nil else {
        // Handle error
        return
    }

    // 🛑 This line fails to compile in v6
    let isApplePayAvailable = configuration.canMakeApplePayPayments
    
    // We use this value to decide whether we have an Apple Pay option available or not, and render the UI accordingly
}

Expected behavior

I expect BTConfiguration.canMakeApplePayPayments to be a public property, just as it was in the Objective-C versions. This would provide a simple, reliable way to determine if the Apple Pay payment option should be displayed in the UI.

Screenshots

No response

[jaxdesmarais]

Hello @Smertowing -

Was this an intentional API change in v6? I noticed canMakeApplePayPayments does not appear to be used anywhere within the SDK itself, which led me to wonder if its removal from the public API was an oversight.

Thanks for using the SDK and reaching out about this use case. It was intentional to move as much as our internal logic as possible to no longer being public in v6. That said, I do think the use case you described is reasonable to allow merchants to check the eligibility before displaying the Apple Pay button (we do something very similar with Google Pay on our Android SDK).

While we cannot commit to an exact date, we can create an internal ticket to add this functionality to the BTApplePayClient to check for eligibility using the internal networks. Additionally thanks for pointing out that we aren't even using canMakeApplePayPayments - we will plan to clean this up as well. We will update you here once we have a PR up for this change.

Is it safe to use a local patch? As a temporary workaround, I'm considering forking the repository and changing the protection level of canMakeApplePayPayments to public. Are there any potential risks or side effects we should be aware of with this approach?

This should be okay as a temporary stop gap until we release this change. Please note though we do not test our SDK with modified forks. Ensure you are doing comprehensive testing to ensure there are no other unintended changes made with the fork.