awesome ios xcode swift

ios - awesome - ¿Cómo distribuir Swift Library sin exponer el código fuente?



ios awesome (2)

Creo que todo el enfoque es incorrecto. No puede hacer algo que (aún) no sea posible por la tecnología que está tratando de usar.

Justificación: Swift es un lenguaje nuevo, actualmente en Beta, y por lo tanto está cambiando. Como lo veo, este hecho significa que no solo no puede enviar bibliotecas estáticas, sino que los desarrolladores (reales) no usarán bibliotecas estáticas de terceros. ¿Cuál es el uso real de una biblioteca que puede no funcionar en la próxima versión del compilador? El problema se agrava si desea utilizar más de una biblioteca, ¡ya que pueden no ser compatibles! Por lo tanto, incluso si pudiera enviar bibliotecas estáticas, no serían realmente útiles para el entorno de producción. ¿Entonces cuál es el punto?

Sugerencia: escriba sus bibliotecas estáticas en Objective-C (o C o lo que sea "no beta"). Los desarrolladores que necesitan bibliotecas de terceros (por ejemplo, las suyas) no deben esperar que se escriban en Swift hasta que Swift esté estable. No usas materiales experimentales para construir puentes reales, ¿verdad? Usas bien probados, predecibles.

Lo primero que intenté es crear una biblioteca estática, pero luego descubrí que aún no es compatible. Notas de la versión de Apple Xcode Beta 4:

Xcode no admite la creación de bibliotecas estáticas que incluyan el código Swift. (17181019)

Esperaba que Apple pudiera agregar esto en la próxima versión Beta o en la versión GA, pero leí lo siguiente en su blog :

Si bien la compatibilidad con el tiempo de ejecución de su aplicación está asegurada, el lenguaje Swift continuará evolucionando y la interfaz binaria también cambiará. Para estar seguros, todos los componentes de su aplicación deben construirse con la misma versión de Xcode y el compilador Swift para garantizar que funcionen juntos.

Esto significa que los marcos deben gestionarse con cuidado. Por ejemplo, si su proyecto usa marcos para compartir código con una extensión incrustada, querrá construir los marcos, la aplicación y las extensiones juntas. Sería peligroso confiar en marcos binarios que usen Swift, especialmente de terceros . Como Swift cambia, esos marcos serán incompatibles con el resto de tu aplicación. Cuando la interfaz binaria se estabilice en un año o dos, el tiempo de ejecución de Swift se convertirá en parte del sistema operativo host y esta limitación ya no existirá.

La noticia es realmente alarmante para mí, una persona que escribe componentes para que otros desarrolladores utilicen e incluyan en sus aplicaciones. ¿Esto significa que tengo que distribuir el código fuente o esperar dos años? ¿Hay alguna otra forma de distribuir la biblioteca sin exponer el código (política de la empresa)?

Actualizar:

¿Es la ofuscación de código Swift una opción en este punto?


Swift es beta ahora, e incluso para 1.0 Apple ha dejado bastante claro que buscan un conjunto de características restringidas, es mejor hacer un pequeño número de cosas bien que intentar hacerlo todo.

Así que por ahora, no hay forma de distribuir bibliotecas estáticas binarias. Presumiblemente eso cambiará en algún momento después de Swift 1.0. Por ahora, puedes:

  • Distribuir fuente
  • Envíe un marco binario (en lugar de una biblioteca) si está de acuerdo con que el ABI sea frágil
  • Utilice ObjC para el código de la biblioteca

También puede combinar enfoques: por ejemplo, implemente los detalles críticos (secretos) de su biblioteca en ObjC, y envíe la fuente Swift que lo envuelve en una API Swift agradable.

El ofuscar código escrito en un idioma que está sujeto a cambios puede parecer una receta para una pesadilla de mantenimiento.