v7.0.0 introduces hard dependency on CallKit.framework, causing App Store rejection

[kfujino7]

Description:
SumUpSDK v7.0.0 introduces a hard link to Call​Kit​.framework that was not present in v6.2.2 or earlier.
This causes App Store rejection.

• Mail from Apple Store
  Guideline 5 - Legal
  Issue Description
  Recently, the Chinese Ministry of Industry and Information Technology (MIIT) requested that CallKit functionality be deactivated in all apps available on the China App Store.
  During our review, we found that the app currently includes CallKit functionality and has China listed as an available territory in App Store Connect.

Evidence:

• v7.0.0 binary links against CallKit
  $ otool -L SumUpSDK.xcframework/ios-arm64/SumUpSDK.framework/SumUpSDK | grep CallKit
  /System/Library/Frameworks/CallKit.framework/CallKit (compatibility version 1.0.0, current version 1.0.0)
  /usr/lib/swift/libswiftCallKit.dylib (compatibility version 1.0.0, current version 5.0.0, weak)

• v6.2.2 does NOT link against CallKit
  $ otool -L SumUpSDK.xcframework/ios-arm64/SumUpSDK.framework/SumUpSDK | grep CallKit
  (no output)

Impact:
• Apps integrating SumUpSDK v7.0.0 that do not use calling functionality are being rejected by App Store Review
• The addition of CallKit is not mentioned in the v7.0.0 CHANGELOG

If I exclude China from the countries where the app is distributed, it should pass the review, but I hope I could maximize the reach of the app to our customers, and I don't want to exclude a specific country from distribution just for the sake of one library.

[giulio92]

Hey @kfujino7,

Thanks for your report.

I have looked into this by comparing versions v6.2.2 and v7.0.0 and I can verify a difference in the binary linking.

While CallKit is not explicitly declared as a dependency in the SumUpSDK.podspec or Package.swift for v7.0.0, the framework appears to be linked within the XCFramework binary.

This is the otool log for v7.0.0 showing the current linking status:

$ otool -L sumup-ios-sdk-7.0.0/SumUpSDK.xcframework/ios-arm64/SumUpSDK.framework/SumUpSDK | grep CallKit
/System/Library/Frameworks/CallKit.framework/CallKit (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/swift/libswiftCallKit.dylib (compatibility version 1.0.0, current version 5.0.0, weak)

In contrast, the same command on v6.2.2 produces no output.

I now need to verify this internally before I can proceed with any further action or provide additional updates.

[giulio92]

Hi @kfujino7,

I have investigated this internally with our team.

The CallKit dependency was introduced in v7.0.0 as it is linked via our internal utility modules for device diagnostics.

Regarding the App Store rejection: SumUp does not currently support the Chinese market. As a result, the SDK is not optimized for compliance with specific local regulations such as the MIIT CallKit restriction.

To resolve the App Store rejection, we recommend excluding China from your app's available territories in App Store Connect. Since the SumUp SDK is not intended for use in that region, this is the standard workaround for integrators using our current version.

We have shared your feedback with the team for future consideration regarding framework modularity, but for now, territorial exclusion is the required step to proceed with v7.0.0.

[JulzPolz]

Hi @giulio92,

Thanks for digging into this and confirming where the CallKit dependency comes from.

I get that SumUp doesnt currently support the Chinese market, but thats exactly the problem. Our apps aren't limited to the markets SumUp supports. The SDK is one payment option of several in a product that ships to many territories, China included. So "SumUp doesn't support China" doesn't remove the constraint, it just means an unsupported, unused module is now blocking the whole app from an App Store territory it otherwise qualifies for.

On v7.0.0+ that leaves integrators with 2 options, neither of which is good for SumUp...

1. Pin to a pre-7.0.0 SDK to avoid the CallKit link, giving up offline payments and every fix and security update since, or
2. Remove SumUp entirely.

Both mean actively removing or freezing your SDK just to ship a compliant app. Neither is sustainable.

The good news is this looks very fixable on your side. By your own account the CallKit link comes from an internal diagnostics utility, and from inspecting the binary the only CallKit symbol actually in use is CXCallObserver (passive call detection). There is no CXProvider / CXProviderConfiguration, so no VoIP calling UI, which is what the MIIT restriction actually targets. A dependency that is non-essential, unused in China and purely diagnostic shouldnt be a hard link in the shipped binary. Options that would resolve this for every integrator...

1. Make CallKit a weak/optional link so it can be excluded at integration time,
2. Gate the diagnostics module behind a build flag, or
3. Move it into a separate optional module so the core payment SDK carries no CallKit dependency.

Territorial exclusion is the workaround we will apply for now to get unblocked, but I would ask that this is treated as more than a "future consideration". As more of your integrators go for China releases, every one of them will hit this same wall and be forced to downgrade or drop the SDK. A modularity fix protects your install base and saves your team a recurring support burden.

Could you let me know if decoupling the CallKit dependency can be scheduled, and ideally a target version? Happy to share the otool/strings output from the 7.0.0 and 7.1.2 binaries if useful for the team.

I have attached our bug / issue report below.

---

Summary

The SumUpSDK binary links Apple's CallKit.framework (and libswiftCallKit.dylib) and references CXCallObserver / CXCall. Because CallKit is linked into the prebuilt binary, any app embedding SumUpSDK is rejected from the China App Store under the MIIT directive requiring CallKit to be deactivated in apps distributed in China. This affects host apps that make no use of CallKit themselves and have no way to strip the dependency out of a prebuilt binary framework. Confirmed still present in the latest v7.1.2.

What is blocked by this issue?

Merchants cannot ship any app that integrates SumUpSDK to the China App Store. Apple's App Review rejects the binary outright (see rejection text under "Other Information"), so the entire app (checkout, tipping, all payment flows) is blocked from the China territory, not just SumUp-specific functionality.

Steps to Reproduce

1. Add SumUpSDK (v7.0.0 or v7.1.2) to an iOS app via SPM.
2. Inspect the linked frameworks of the SDK binary:

   otool -L SumUpSDK.xcframework/ios-arm64/SumUpSDK.framework/SumUpSDK | grep -i callkit

   Output:

   /System/Library/Frameworks/CallKit.framework/CallKit (compatibility version 1.0.0, current version 1.0.0)
   /usr/lib/swift/libswiftCallKit.dylib (compatibility version 1.0.0, current version 5.0.0, weak)
   

3. Confirm the CallKit symbols are baked in:

   strings -a SumUpSDK | grep -oE 'CX[A-Za-z]+' | sort -u
   # CXCall, CXCallObserver, CXCallObserverAdapter, CXCallObserverDelegate, ...

4. Submit an app embedding the SDK with China listed as an available territory in App Store Connect.
5. App Review rejects it for active CallKit functionality in China.

Expected Behavior

SumUpSDK should not force a hard link against CallKit.framework, so that apps embedding it remain distributable in China. Ideally the CallKit usage (the CXCallObserver call-detection) should be removed, made a weak/optional link that can be excluded, gated behind a compile/runtime flag, or offered as a China-compliant SDK variant.

Actual Behavior

CallKit.framework is a required load command in the shipped SDK binary, and CXCallObserver is compiled in. There is no supported way for an integrating app to remove this dependency from the prebuilt xcframework, so every host app inherits it and is rejected from the China App Store.

iOS Version(s)

Not iOS-version-specific... the linkage is present in the binary regardless of runtime iOS version. Observed while targeting iOS 16+ (SDK minimum) up to iOS 26.

Impacted Devices

All devices. This is a static-linkage / App Review issue, not a device-runtime issue.

Impacted Readers

All readers, not reader-specific.

Firmware Version(s)

N/A, not firmware-related.

Crash Log

N/A. Not a crash, this is an App Store review rejection.

Dependency Versions

• SumUp SDK: 7.0.0 (in production); also verified against 7.1.2 (latest), CallKit link still present in both
• Swift: 6.3.3 (swiftlang-6.3.3.1.3)
• Xcode: 26.6 (17F113)

Video / Screenshot

N/A

Other Information

Verbatim Apple App Review rejection received:

Issue Description
Recently, the Chinese Ministry of Industry and Information Technology (MIIT) requested that CallKit functionality be deactivated in all apps available on the China App Store.
During our review, we found that the app currently includes CallKit functionality and has China listed as an available territory in App Store Connect.

Next Steps
This app cannot be approved with CallKit functionality active in China. Please make the appropriate changes and resubmit this app for review.
If you have already ensured that CallKit functionality is not active in China, you may reply to this message in App Store Connect to confirm.
Voice over Internet Protocol (VoIP) call functionality continues to be allowed but can no longer take advantage of CallKit's intuitive look and feel. CallKit can continue to be used in apps outside of China.

Additional notes:

• Our own app contains zero CallKit code; the dependency comes entirely from SumUpSDK. Our app binary links no CallKit (otool -L clean) while SumUpSDK.framework does.
• The SDK appears to use only CXCallObserver (call detection, presumably to pause reader activity during a phone call) and not CXProvider / CXProviderConfiguration (i.e. no VoIP calling UI). If so, the CallKit dependency may be non-essential or replaceable, which would make a fix straightforward.
• Since SumUp has no payments product in China, a build/variant without the CallKit link would unblock all affected merchants without any loss of functionality in supported markets.