Swift 3 @objc inference deprecated: qué hacer en Swift 4

¿Por qué Swift 3 @objc inference está quedando en el pasado?

Si alguna vez actualizó un proyecto de Swift 3 a Swift 4, seguramente se encontró con la aterradora advertencia del compilador:

The use of Swift 3 @objc inference in Swift 4 mode is deprecated. \nPlease address this deprecated @objc inference warning, \nor disable the warning by setting the "Swift 3 @objc Inference" \nbuild setting to "Default" for the "Swift 4" target.

Este mensaje no es una simple formalidad. Detrás hay un cambio importante en la filosofía del lenguaje. En Swift 3, el compilador decidía por sí mismo qué métodos y propiedades debían ser visibles para Objective-C. Esto era conveniente, pero creaba problemas ocultos: el tamaño del binario aumentaba y el rendimiento disminuía. Swift 4 decidió acabar con esta "adivinanza" y transfirió el control al desarrollador.

En este artículo, analizaremos qué es @objc inference, por qué se decidió deprecated, cómo corregir la advertencia y qué mejores prácticas usar en proyectos modernos. ¡Allá vamos!

¿Qué es @objc inference y cómo funcionaba en Swift 3?

En Swift 3, existía una conversión implícita a @objc. Esto significaba que si una clase heredaba de NSObject o usaba un protocolo @objc, el compilador automáticamente hacía visibles todos sus métodos para Objective-C. Este mecanismo se llamaba @objc inference (inferencia implícita).

Ejemplo en Swift 3:

class MyViewController: UIViewController {\n    func buttonTapped() {\n        print("Button tapped")\n    }\n}

En Swift 3, el método buttonTapped() se volvía automáticamente @objc. Podía pasarse a #selector o usarse como target para UIControl. ¿Conveniente? Sí. Pero el precio era una inflación injustificada del binario y la pérdida de optimizaciones.

¿Por qué Apple decidió eliminar la inferencia automática?

Hay varias razones, y todas se centran en la eficiencia y el control:

\n
• Tamaño de la aplicación. Cada método marcado como @objc genera un envoltorio adicional para el runtime de Objective-C. En proyectos grandes, esto podía agregar megabytes de código innecesario.
\n
• Rendimiento. Swift es un lenguaje de tipado estático con potentes optimizaciones. Cuando un método se vuelve @objc, el compilador pierde la capacidad de aplicar varias optimizaciones (por ejemplo, la inserción en línea).
\n
• Explicititud. Swift 4 tomó un rumbo hacia la explicititud. El desarrollador debe decidir por sí mismo qué debe estar disponible desde Objective-C. Esto simplifica la comprensión del código y reduce errores inesperados.
\n
• Futuro de Swift. Apple se está alejando gradualmente de la dependencia de Objective-C. Cuantos menos puentes implícitos haya, más rápido podrá Swift convertirse en un lenguaje completamente independiente.
\n

¿Cómo se ve la advertencia en la práctica?

Supongamos que tiene un proyecto escrito en Swift 3. Cambia la configuración "Swift Language Version" a Swift 4.0 y obtiene decenas (o incluso cientos) de estas advertencias:

class LegacyViewController: UIViewController {\n    // Advertencia: The use of Swift 3 @objc inference in Swift 4 mode is deprecated\n    func legacyAction() {\n        // ...\n    }\n\n    @objc func explicitAction() {\n        // Este método ya está marcado con @objc — todo bien\n    }\n}

El compilador se queja de legacyAction(), ya que no está marcado con @objc, pero antes el compilador lo hacía automáticamente. Ahora se necesita una solución.

Tres formas de corregir la advertencia

Tiene tres opciones de acción. Elija la que mejor se adapte a su proyecto.