Elegir un proveedor de desarrollo en Objective-C en VENTANILLA Perú decide si su legacy Apple se mantendrá y modernizará con criterio —sostenido en Objective-C, migrando gradualmente a Swift cuando convenga—, o un proyecto que reescribe todo de golpe, descuida el legacy, o usa Objective-C para lo nuevo donde tocaba Swift. Estas cinco preguntas funcionan como un marco de due diligence. Para cada una verá por qué importa, qué responde un proveedor sólido, qué es una señal de alarma y una prueba concreta. Al final, una tabla comparativa y una prueba de validación accionable.

1. ¿Tiene talento real en Objective-C (para el legacy)?

El criterio es la base. Importa porque mantener legacy Objective-C requiere experiencia real, y —como la comunidad se mueve a Swift— ese talento es más escaso; un proveedor sin él no puede sostener su legacy. La capa de consecuencia: sin talento real, el legacy crítico queda en riesgo. Buena respuesta: tienen experiencia real y demostrable en Objective-C y en el ecosistema Apple. Señal de alarma: hablan de Objective-C sin acreditar experiencia. Prueba concreta: pregúnteles por su experiencia real manteniendo sistemas Objective-C en producción.

2. ¿Aconseja Swift para lo nuevo y Objective-C para el legacy?

El criterio importa. Importa porque para lo nuevo se prefiere Swift y Objective-C es para el legacy, y un proveedor que usa Objective-C para nuevo desarrollo (o que no entiende el reparto) decide mal. La capa de consecuencia: nuevo desarrollo en Objective-C es ir contra la dirección de Apple. Buena respuesta: recomiendan Swift para lo nuevo y Objective-C para mantener el legacy. Señal de alarma: proponen Objective-C para una app totalmente nueva. Prueba concreta: pregúnteles qué lenguaje usarían para una nueva app Apple, y por qué.

3. ¿Plantea una migración gradual (no reescribir todo de golpe)?

La estrategia importa. Importa porque reescribir todo el legacy de golpe es enorme y arriesgado, y un proveedor que lo propone (en vez de migrar gradualmente vía interoperabilidad) asume un riesgo innecesario. La capa de consecuencia: una reescritura total mal planteada puede salir carísima o fracasar. Buena respuesta: mantienen el legacy y migran gradualmente a Swift, aprovechando la interoperabilidad. Señal de alarma: proponen reescribir todo de golpe sin justificación. Prueba concreta: pregúnteles cómo modernizarían su legacy Objective-C hacia Swift.

4. ¿Aprovecha la interoperabilidad Objective-C/Swift?

La interoperabilidad importa. Importa porque Objective-C y Swift conviven sobre el ecosistema Apple, y un proveedor que no lo aprovecha pierde la vía natural para modernizar. La capa de consecuencia: ignorar la interoperabilidad obliga a falsos dilemas (todo o nada). Buena respuesta: hacen convivir Objective-C y Swift, escribiendo lo nuevo en Swift sobre el legacy. Señal de alarma: tratan Objective-C y Swift como mundos incompatibles. Prueba concreta: pregúnteles cómo harían convivir su código Objective-C con Swift nuevo.

5. ¿Es honesto sobre el papel de legacy de Objective-C?

La honestidad importa. Importa porque Objective-C es de nicho legacy (no de futuro), y un proveedor que lo presenta como “igual de vigente que Swift” para todo no aconseja en su interés. La capa de consecuencia: ignorar su papel de legacy lleva a malas decisiones de largo plazo. Buena respuesta: reconocen que Objective-C es para el legacy y Swift el futuro, con honestidad. Señal de alarma: presentan Objective-C como opción de futuro para lo nuevo. Prueba concreta: pregúnteles cuál es el papel de Objective-C hoy y hacia dónde va el desarrollo Apple.