¿Cómo distribuir la biblioteca Swift sin exponer el código fuente?

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

Xcode no es compatible con la creación de bibliotecas estáticas que incluyen el código Swift. (17181019)

Tenía la esperanza de que Apple pueda agregar esto en la próxima versión de Beta o la versión de GA, pero leí lo siguiente en su blog :

Si bien se garantiza la compatibilidad con la ejecución de la aplicación, el lenguaje Swift seguirá evolucionando y la interfaz binaria también cambiará. Para estar seguro, todos los componentes de su aplicación deben buildse con la misma versión de Xcode y el comstackdor Swift para garantizar que funcionen juntos.

Esto significa que los frameworks deben gestionarse con cuidado. Por ejemplo, si su proyecto usa frameworks para compartir código con una extensión incorporada, querrá crear juntos los frameworks, la aplicación y las extensiones. Sería peligroso confiar en frameworks binarys que usan Swift, especialmente de terceros . Como Swift cambia, esos frameworks serán incompatibles con el rest de su aplicación. Cuando la interfaz binaria se estabilice en uno o dos años, el time de ejecución Swift pasará a formar parte del SO host y esta limitación ya no existirá.

Las noticias son realmente alarmantes para mí, una persona que escribe componentes para que otros desarrolladores los 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:

¿La ofuscación del código Swift es una opción en este momento?

Swift es beta ahora, e incluso para 1.0 Apple ha sido bastante claro que está detrás de un set de características restringidas: es mejor hacer un pequeño número de cosas que intentar 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 binary (en lugar de una biblioteca) si está de acuerdo con que el ABI sea frágil
  • Use ObjC para el código de biblioteca

También puedes combinar enfoques: por ejemplo, implementa los detalles críticos (secretos) de tu biblioteca en ObjC y envía la fuente Swift que lo envuelve en una buena API Swift.

El código ofuscador escrito en un lenguaje que está muy sujeto a cambios suena como una receta para una pesadilla de mantenimiento.

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

Justificación: Swift es un lenguaje nuevo, actualmente en Beta y, por lo tanto, cambiante. Según lo veo, este hecho no solo significa que no puede enviar bibliotecas estáticas, sino que los desarrolladores (reales) no utilizará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 comstackdor? ¡El problema se agranda si quieres usar más de una biblioteca, porque pueden no ser compatibles! Por lo tanto, incluso si pudiera enviar bibliotecas estáticas, no sería realmente útil 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, el suyo) no deben esperar que se escriban en Swift hasta que Swift esté estable. No utilizas materiales experimentales para build puentes reales, ¿verdad? Usas los probados y pnetworkingecibles.