The vendor binary you cannot commit, and the SDK version nobody can negotiate

The expensive part is the resolver gap. CocoaPods resolves pods and SPM resolves packages, and neither reads the other's graph, so when a vendor pod and a pub.dev plugin both depend on the same underlying SDK, there is nothing that can negotiate a version between them ^[6]. The advice that circulates, according to the dev.to write-up, is to wrap the binary in a pod, which in practice means turning SPM off for the entire app ^[7]. That is an architecture decision arriving dressed as an integration ticket, and it has a clock on it: CocoaPods trunk goes permanently read-only on 2026-12-02 ^[8].

Take the SPM route instead and gitignoring the binary is not enough on its own, because a `.binaryTarget(path:)` aimed at a file that is absent fails the resolve of the whole package graph rather than just that one target ^[5]. The manifest is a Swift program that SwiftPM executes, so it can check whether the `.xcframework` is on disk and declare the target only when it is, adding a compile flag such as `ACME_ADS_SDK` so calling code has something to branch on ^[15].

Then the mechanism that makes the fix worse than the problem. SwiftPM caches manifest evaluation keyed on manifest content, not on filesystem state, so the "is the binary present" answer is frozen at first evaluation and dropping the binary in afterwards does not flip it ^[12]. Clearing Flutter's ephemeral directory does not help, because Xcode's cloned `SourcePackages` and SwiftPM's global manifest cache still hold the old answer, which is three separate caches to invalidate ^[13][18]. The author reports three consecutive green builds with no SDK linked and nothing in any log to say so ^[14].

Android refuses earlier and louder. `implementation(files("libs/AcmeSDK.aar"))` inside a library module makes `bundleDebugAar` fail, because AGP will not publish an AAR whose local dependency classes would be silently dropped ^[9], and Flutter plugin authors meet it the first time anyone runs `flutter build aar` for add-to-app [c9b]. A bare `.aar` also carries no transitive dependency metadata, so every runtime dependency is declared and version-managed by hand, and a missing one is a `ClassNotFoundException` at call time rather than a build error ^[10]. Turn on minification and R8 strips whatever the vendor loads reflectively by name, visible only in release builds ^[11].

Count the documented failure modes and the split is even. The graph resolve failure, the AGP bundle error, and the deployment target mismatch at link time all stop a build ^[5][9][16]. The undeclared transitive dependency, the stripped reflective class, and the cached manifest that decided the SDK was absent all pass a build and fail where the build log cannot see them ^{[10][11][14][19]}. The generator the author published, binary-sdk-bridge, emits the SPM package and the Gradle module with the binary kept out of version control ^[17], but nothing in that removes the second group. Anyone taking the conditional-manifest route still owes themselves a check that the binary actually linked, because the build system has already been given permission to say yes when it did not.