[image_picker_ios] PR 4/5 Migrate the view provider, PHPicker save operation, and image utilities to Swift - #13394

Using registeredTypeIdentifiers.first to load the video representation can be problematic if the first identifier is an image (e.g., for Live Photos or assets with multiple representations). It is safer to explicitly find the first identifier that conforms to the movie type.

    let typeIdentifier = result.itemProvider.registeredTypeIdentifiers.first { identifier in
      UTType(identifier)?.conforms(to: .movie) ?? false
    } ?? UTType.movie.identifier
    result.itemProvider.loadFileRepresentation(forTypeIdentifier: typeIdentifier) {

processVideo only runs after the item has failed the image check and matched UTType.movie. This uses registeredTypeIdentifiers.first, which is the Swift form of the Objective-C firstObject. Live Photos take the image branch before this method runs, so I'm leaving the identifier selection as ported

Casting gifMetaProperties[kCGImagePropertyGIFDictionary] directly to NSMutableDictionary using as? NSMutableDictionary will fail for immutable dictionaries (which is what metaData usually contains). This prevents setting the loop count to 0. Creating a mutable copy of the dictionary resolves this issue.

Done. ImageIO's nested GIF dictionary is immutable, so as? NSMutableDictionary was nil and the loop count was never written. The dictionary is copied, the loop count is set to 0, and that copy is written back. The GIF save tests expect that loop count

The sendCallResult methods can be invoked from background threads (e.g., when retrieving full metadata via requestImageDataAndOrientation). Invoking Flutter's result callback on a background thread violates Flutter's threading model and can cause crashes or undefined behavior. Wrapping the bodies of both sendCallResult methods in DispatchQueue.main.async ensures thread safety.

  func sendCallResult(withSavedPathList pathList: [String?]?) {
    DispatchQueue.main.async {
      guard let callContext = self.callContext else {
        return
      }

      if let pathList, pathList.contains(where: { $0 == nil }) {
        callContext.result(
          nil,
          FlutterError(
            code: "create_error",
            message: "pathList's items should not be null",
            details: nil))
      } else {
        let paths = pathList?.compactMap { $0 } ?? []
        callContext.result(paths, nil)
      }
      self.callContext = nil
    }
  }

  func sendCallResult(with error: FlutterError) {
    DispatchQueue.main.async {
      guard let callContext = self.callContext else {
        return
      }
      callContext.result(nil, error)
      self.callContext = nil
    }
  }

This method is unchanged from the Swift plugin already on main. This PR only renamed the utility calls around it. The unit tests rely on sendCallResult invoking the callback synchronously on the calling thread. Wrapping it in DispatchQueue.main.async would change that for every picker result, so I'm not doing it in this migration

This sounds like an issue. When you run it, is it on main thread? If not, can you add a TODO in the comment?

The picker delegate and the PHPicker completion operation run on the main queue. requestImageDataAndOrientation's result handler is documented to run on an arbitrary queue, and that path calls sendCallResult when full metadata is requested. I added a TODO there. I left the callback synchronous so the unit tests can still read it on the calling thread

Using objc_sync_enter(self) / objc_sync_exit(self) is unnecessary and unidiomatic in Swift here. Since showCamera is always called on the main thread, synchronization is redundant.

This is the port of the Objective-C @synchronized(self) around isBeingPresented. The permission callback already hops to the main queue before calling showCamera, and I'm keeping the same lock the previous implementation had

Force-unwrapping imageToScale! after checking for nil is unidiomatic in Swift. Using guard let is safer and cleaner.

Done. drawScaledImage now uses guard let and returns nil when the image is nil or either dimension is zero, matching the Objective-C check

Calling drawScaledImage(nil, ...) when image or cgImage is nil is redundant because drawScaledImage always returns nil when its first argument is nil. Returning nil directly is cleaner and more efficient.

Done. A missing image or cgImage returns nil directly

just double check - if both are nil, should the test pass or fail? is nil metadata expected or unexpected?

Nil is unexpected. Both fixtures have ProfileName sRGB IEC61966-2.1, but nil == nil used to pass. The test now requires the original profile name and still checks that the saved file has the same name. I made the same change for the PNG assertion below

You can delete this since image picker is ios 15+:

Removed. The package deployment target is iOS 15, so @available(iOS 14, *) on FakePickerItem is redundant

this is getting a bit long, can you typealias it and provide with parameter name for readability

Done. The handler is now ImageDataHandler, with names for the image data, UTI, orientation, and info dictionary

> 0

Done. drawScaledImage now returns nil unless width > 0 and height > 0

I know this is just migration, but is there any documentation or source for these values?

These are the first bytes of the file signatures, carried over from the Objective-C constants. JPEG's SOI marker is 0xFFD8, PNG's signature starts with 0x89, and GIF's header starts with ASCII G (0x47). I added that above the constants

is this log also from objc? should this be reported to dart side?

Yes, this is the same NSLog from FLTImagePickerMetaDataUtil. It is not reported to Dart. For a non-JPEG type the image is still returned, PNG data as-is and other types as JPEG, and the caller saves that and returns the path. I would not add a new Dart error in this migration unless you want that behavior change

Let's leave it but add a TODO then. This kind of error should be surfaced to developers so they can handle it.

Done. I left the NSLog and added a TODO

This sounds like an issue. When you run it, is it on main thread? If not, can you add a TODO in the comment?

Can you remove This stays an NSLog, matching FLTImagePickerMetaDataUtil, and the image is still returned. - after migration, this class is gone, and the comment would be confusing

Done. Removed that sentence