[iOS] Add Translate API support to Engine - #189878

Using abs() on floating-point values (CGFloat) will cause an implicit conversion to int, truncating the fractional part. This can lead to precision loss and layout bugs for the popover bounds. Use fabs() instead.

Since makeTranslateHostingController is only called internally within TranslateViewController, it should be marked private and the @objc attribute should be removed to improve encapsulation and avoid unnecessary Objective-C runtime exposure.

Modifying the UIKit view hierarchy (removing the hosting controller's view and parent-child relationship) synchronously inside the onDismiss closure (which is triggered by the SwiftUI binding's set block during a view update) can cause undefined behavior or crashes. It is safer to dispatch this to the main queue asynchronously.

Cramming the get and set closures with control flow on a single line is hard to read and violates standard Swift formatting guidelines. Formatting it with proper line breaks improves readability.

        isPresented: Binding(
          get: { true },
          set: { shown in
            if !shown {
              onDismiss?()
            }
          }
        ),

Use the standard uppercase iOS instead of lowercase ios in the @available check for consistency with the rest of the codebase.

      if (@available(iOS 17.4, *)) {

I probably worth extracting a local:

FlutterTextInputView* plugin = (FlutterTextInputView*)_textInputPlugin.textInputView;
// ... stuff ...

We should wrap the content of this method in an if (@available(iOS 17.4, *)) which it looks like you've done elsewhere, otherwise we risk runtime crashes.

That kind of raises the question -- does the framework need to know whether this worked or not? This method doesn't have a return so on iOS < 17.4 you won't be able to tell. Depending on how this is implemented in the framework, you could also have guards in the plugin message handler return FlutterMethodNotImplemented... or some other signal. But probably depends a lot on how the framework wires things up.

This covers the happy path. It might be worth adding a test for the unhappy path where iOS 17.4 isn't available.

Since the class is TranslateViewController, we should name the file TranslateViewController.swift.

This should be:

@objc(FlutterTranslateViewController)

for consistency with the other framework classes.

This seems like a pretty generic name. Maybe TranslateContentView or TranslatePresentationView?

This shouldn't have a leading underscore since that's used for ivars.

Here and a few other places: I could be wrong, but you shouldn't need a FlutterTextPosition*, the default UITextPosition* should be all that's necessary and doesn't ened a cast. UIKit APIs don't care about the underlying type; they use our own code to manipulate these.

What if we extracted a helper (CGRect)popoverBoundsForCurrentSelection and have showShareViewController, showLookUpViewController, and showTranslateViewControllerForTerm all call it?

Thinking about it, you probably don't need to dedupe out the other (existing) code in the other methods this PR if you want to keep it focused on translate, but you could create the helper and use it your new method in this patch and then go back to clean up the others in a followup patch.