¿Swift es mejor para la programación de iOS en comparación con Objective-C u otros lenguajes?

Escribí mucho C ++, que Java, que Scala antes de sumergirme en Objective-C.

Y siempre se sintió como un paso … hacia atrás. Simplemente se siente anticuado. El código se ve más feo. Se necesita un poco de tiempo para comprenderlo rápidamente, en comparación con otros idiomas.

Pero Apple ha invertido AÑOS de tiempo de desarrollo en sus Foundation SDKS (tanto para iOS como para OS X). Y los marcos en sí mismos son bastante buenos. Y lo más importante: son estables y funcionan. Aunque todos fueron escritos en este tipo de lenguaje extraño no estándar que nadie más en el mundo usa. Excepto Apple.

Han agregado mucho al lenguaje para simplificarlo (¡ARC es un gran problema!). Pero todavía se siente torpe.

Cambiar a otro idioma “estándar” no funcionaría. Porque cualquier otro idioma requeriría que hicieran malos compromisos (tanto con claridad como con rendimiento) para utilizar los SDK existentes en iOS y OSX.

Entonces, un nuevo lenguaje tenía mucho sentido, y creo que en realidad dará como resultado un software MÁS estable a medida que avanzamos. Pero dado que el código puede interoperar directamente con objetos Objective-C, aún conserva su inversión en sus SDKS y Frameworks existentes.

Swift utiliza la “inferencia de tipos” que puede permitir una lógica mucho más fácil de leer, sin comprometer el rendimiento que se obtiene de un lenguaje de tipo seguro.

¡El código rápido no tiene encabezados! (Como Java). No más listas desagradables de “importaciones” en la parte superior de su archivo. Ahora solo importa “módulos” y generalmente solo necesita unos pocos. Por lo tanto, menos archivos para mirar. ¡Menos archivos para escribir!

Presenta los opcionales, que le ayudan a evitar los problemas y errores de puntero “nulo” que sucederían en Objective-C (ya que es legal en Objective-C ejecutar operaciones en un puntero nulo). En swift: cuando lee el código, queda claro si es “legal” que el puntero sea nulo o no. (Piense en ello como una afirmación explícita que verifica que el puntero NO es nulo cuando requiere que no lo sea).

Hay varios otros pequeños cambios sutiles que deberían dar como resultado un código más estable (mi favorito es el requisito de usar “{}” después de una instrucción if, evita TANTOS ERRORES).

Aparentemente, el código rápido debería permitirle escribir código que se ejecute MÁS RÁPIDO que Objective-C. Pero si el 90% de lo que está haciendo en su aplicación rápida está invocando objetos Objective-C, dudo que notemos algún cambio.

¡Pero las aplicaciones que fallan menos! ¡Y son más fáciles de leer! Hurra.

Estoy escribiendo una aplicación en Swift después de trabajar previamente en Objective C.

Actualmente hay cierta fricción en el uso de Swift.
El idioma está cambiando un poco. Algunas cosas tienen bordes ásperos.
Las herramientas están un poco rotas. La depuración es más difícil. Falta la refactorización, etc.

Pero … lo estoy disfrutando.

Estoy cometiendo menos errores tontos debido a la sintaxis más directa. Los encabezados y el código repetitivo que es inevitable en Objective-C fue una fuente de frustración.

La sintaxis de languange más simple significa que no siempre estoy cortando y pegando. Realmente puedo recordar cómo escribir un interruptor o una declaración de clase sin referirme de nuevo.

El lenguaje en sí hace que algunas abstracciones sean más fáciles de expresar. A menudo descubrí que algunas ideas no encajaban naturalmente en el Objetivo C. Tuve que luchar un poco. En Objective-C siempre hubo una tensión entre el uso de estructuras de lenguaje C frente a las verdaderas clases de Cocoa, y esa tensión desaparece en Swift.

A algunas personas no les gustan los opcionales Swift. Usted está obligado a manejar explícitamente los casos en que los objetos son nulos. Eso requiere un pensamiento adicional, pero probablemente sea algo bueno. Una fuente de errores desaparece.

Me parece que el código que escribo funciona por primera vez. Esto fue bastante raro con Objective-C.

Estoy pensando en describir esto en un blog de Quora. Si alguien lo encontrara interesante.

Ayer mismo exclamé a mi amigo.

Swift no está listo para el horario estelar.

Esto, después de quedar atrapado con un cambio de código aparentemente simple que necesito hacer en mi juego que por alguna razón impía bloquea Xcode en una bruma de “Indexación …”. Ha estado atascado de esa manera durante días. Ponga el cambio, se atasca. Llevarlo a cabo. Se construye y se ejecuta.

Ha hecho que mi experiencia con iOS sea un callejón sin salida, por ahora. Tengo dudas de que lo mismo sería cierto si estuviera usando el Objetivo C.

Pero dicho esto, Swift se siente como una suave almohada musical. En comparación con la almohada espinosa espinosa y puntiaguda del Objetivo C.

Para ser justos, diría que un buen programador ios debería ser competente en AMBOS rapidez y objetivo-C.

Muchos marcos todavía se escriben en Objective-C hoy en día y muchas compañías todavía tienen una o varias aplicaciones que usan principalmente obj-C o que están completamente escritas en obj-C, por lo tanto, si desea poder depurar, agregue nuevas características etc. DEBE tener un buen conocimiento de obj-C aunque sea un programador rápido.

Además, actualmente hay algunas desventajas sobre swift, principalmente las fiestas de migración (weeeee) gracias a swift 3.

Si bien Swift está comenzando a ser más estable, aún puede encontrar algunos problemas importantes en el camino, probablemente es por eso que algunas compañías como google se adhieren a obj-C y no se moverán a Swift mientras Apple no mate a Obj-C.

Las otras soluciones podrían estar usando cordova o reaccionar nativo. Cordova es excelente si necesita construir rápidamente un mvp multiplataforma, pero personalmente no lo usaré en producción.
Sin embargo, React Native parece ser una buena solución, pero en mi opinión, tendrá dificultades para encontrar programadores competentes para su tiempo si sigue este camino, que podría cambiar tan bien para echarle un buen vistazo.