feat: SPM migration for all packages + support simulator

[pumano]

@fbernaly I found that fork https://github.com/mdata-group/google-mlkit-swiftpm fix simulator problem, but some things linked twice results to Error (Xcode): 115 duplicate symbols

There are 115 duplicate symbols because MLKitCommon gets linked multiple times. google_mlkit_commons depends on MLKitBarcodeScanning (which includes MLKitCommon), and other packages like barcode_scanning also depend on MLKitBarcodeScanning directly — causing MLKitCommon to be linked twice.

duplicate symbol 'MLKITx_strings::CleanStringLineEndings(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>> const&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>*, bool)' in: duplicate symbol 'MLKITx_strings::ShellEscape(MLKITx_absl::string_view)' in: duplicate symbol 'MLKITx_strings::EightBase32DigitsToFiveBytes(char const*, unsigned char*)' in: duplicate symbol 'MLKITx_absl::WebSafeBase64Unescape(char const*, long, char*, long)' in: duplicate symbol 'MLKITx_strings::ByteStringToAscii(MLKITx_absl::string_view, long, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>*)' in: duplicate symbol 'MLKITx_absl::base_internal::delete_hooks_' in: duplicate symbol 'MLKITx_absl::base_internal::MallocHook::AddNewHook(void (*)(MLKITx_tcmalloc::MallocHook::NewInfo const&))' in: duplicate symbol 'MLKITx_absl::base_internal::MallocHook::AddMremapHook(void (*)(void const*, void const*, unsigned long, unsigned long, int, void const*))' in: duplicate symbol 'MLKITx_strings::TenHexDigitsToEightBas…

Could you check it? Maybe you can fix it

[fbernaly]

@pumano : did you test running the example app and makeing sure the detection works? If yes then list the ones you have tested on an actual device.

[pumano]

@fbernaly I push second commit and looks like I fix it! app launched successfully!! Check it out plz. I don't have real iphone device right now, can't test. If you can help with it - will be good

[fbernaly]

@pumano : not only launching the app but testing each of the features, with these migration work I have seen a lot of runtime errors that do not happen with cocoapods, that is why I have not released this SPM migration until all the features run with no runtime crashes

[pumano]

OK I will try to find real device tomorrow and debug it

[pumano]

@bensonarafat did you want to help with testing?

[fbernaly]

@pumano : please assist with testing

[MrJohnDev]

@pumano did you find iPhone?

[vicajilau]

Before anyone spends more time hunting for a physical device, I think there's a blocker here that device testing wouldn't surface, because it compiles green and the app launches fine.

digital_ink_recognition and entity_extraction are silently stubbed out

google-mlkit-swiftpm (both arrrrny and the mdata-group fork this PR switches to) exposes 17 library products:

MLKitBarcodeScanning, MLKitFaceDetection, MLKitImageLabeling, MLKitImageLabelingCustom,
MLKitLanguageID, MLKitObjectDetection, MLKitObjectDetectionCustom, MLKitPoseDetection,
MLKitPoseDetectionAccurate, MLKitSegmentationSelfie, MLKitSmartReply, MLKitTextRecognition,
MLKitTextRecognitionChinese, MLKitTextRecognitionDevanagari, MLKitTextRecognitionJapanese,
MLKitTextRecognitionKorean, MLKitTranslate

MLKitDigitalInkRecognition and MLKitEntityExtraction are not among them. On feature/spm, both plugins' Package.swift therefore depend only on google_mlkit_commons, and the Swift sources are wrapped in #if canImport(...):

#if canImport(MLKitDigitalInkRecognition)
    import MLKitCommon
    import MLKitDigitalInkRecognition
#endif

Since the framework is never linked, canImport is always false and the real implementation never compiles. What ships is the #else branch:

let unimplemented = FlutterError(
    code: "UNIMPLEMENTED",
    message: "MLKitDigitalInkRecognition is not available via Swift Package Manager on iOS",
    details: nil
)

entity_extraction has the identical structure.

This is a functional regression. On develop both plugins work on iOS today:

# google_mlkit_digital_ink_recognition.podspec
s.dependency 'GoogleMLKit/DigitalInkRecognition', '~> 9.0.0'

# google_mlkit_entity_extraction.podspec
s.dependency 'GoogleMLKit/EntityExtraction', '~> 9.0.0'

After the migration they return UNIMPLEMENTED at runtime. It builds clean and the example app launches, so this passes exactly the smoke test that's currently being asked for — it only fails when a user taps the feature.

(face_mesh_detection is stubbed the same way, but there's no regression there: its GoogleMLKit/FaceMeshDetection dependency is already commented out on develop.)

This is a decision, not a bug

Worth settling before more testing effort goes in, since it changes what "done" means:

1. Merge as-is — accept shipping 2 plugins broken on iOS. Would need a breaking-change note and a README warning on both, not a silent UNIMPLEMENTED.
2. Block until the mirror adds both binary targets. It already vendors 51 binaryTargets, so adding two more is mechanical — but it puts two published plugins on a third-party unofficial mirror's release cadence.
3. Hybrid — keep only these two (plus commons, which they depend on) on CocoaPods and migrate the rest to SPM. Flutter supports plugins declaring both, and it's the only option that ships zero regressions.

I'd lean towards 3, with 2 as the follow-up once the mirror catches up.

Separately, on the test matrix

The reason this is worth resolving first: testing all 22 packages is being treated as a bigger job than it is. It collapses to ~11.

• 8 packages have no native ML Kit dependency at all (the 6 GenAI ones, document_scanner, subject_segmentation) — they only link Flutter. Nothing to verify beyond the app building.
• 3 are the stubbed ones above — nothing to test until the question above is answered.
• 11 actually link ML Kit, and they share one failure mode (does the static lib load and detect), which any single one of them proves. On top of that, text_recognition is the only package shipping resource bundles (the five *OCRResources.bundle), so it's the only one needing a separate check that resources get copied into the app bundle.

That's one pass through the example app, not an open-ended campaign. Happy to run it on a device once the digital ink / entity extraction question is settled — no point testing a matrix that's about to change.

One more thing worth flagging

feature/spm deletes every .podspec. That breaks any app that hasn't enabled SwiftPM, including anyone on a Flutter version below 3.44. Keeping the podspecs alongside Package.swift costs nothing and is what the Flutter plugin migration guide recommends — the two coexist, and CocoaPods stays the fallback.