Flutter: Código Push / Hot Update / actualizaciones fuera de banda

cc @floitschG

ver también
https://groups.google.com/forum/#!msg/flutter -dev / YwzItp1pxJo / 7bFGDLvxBAAJ
Estaría muy emocionado por esto.

Creo que esto sería bastante importante porque podría ser una de las únicas características verdaderamente distintivas de react native y, desafortunadamente, algunas empresas podrían considerar esto como un factor decisivo.

Casos de uso

• errores críticos, especialmente en iOS, especialmente para VIP o situaciones urgentes, urgentes, críticas para el negocio y / o usuarios que no pueden usar la aplicación por alguna razón.
• Pruebas de funciones más dinámicas que los lanzamientos por etapas
• este sería un buen toque prepararse para Fuschia y / o Chromebooks. podría haber escenarios en los que flutter esté "compitiendo" con las aplicaciones web, no solo con las soluciones pwas / Kotlin / Swift / React / Xamarin / other-junkier-hybrid

En la batalla épica que es Flutter vs React Native, la inserción de código es una herramienta increíble (:
Como desarrollador RN, no puedo enfatizar lo suficiente la importancia de esta característica. Muchos pasarán Flutter solo por la ausencia de empujones calientes. Una vez que se acostumbre a corregir rápidamente errores e impulsar nuevas funciones, no podrá volver atrás.

compilar en la ruta de JavaScript disminuirá las ventajas de Dart, ¿verdad?
Encontré una aplicación nativa que solía poder tener la recarga de código usando Rollout.io pero fue bloqueada por Apple: https://news.ycombinator.com/item?id=13817557
Al observar este patrón, parece que flutter no tendrá una función de inserción de código perfecta como la que vemos en react native.
Me encantaría obtener más información sobre las posibilidades de esta función de los mantenedores principales (:

compilar en la ruta de JavaScript disminuirá las ventajas de Dart, ¿verdad?

¿De qué ventajas hablas?

Codepush es muy necesario. Me encanta ver la posibilidad de lanzamiento de actualizaciones por aire en Flutter.

acabamos de tener un caso de uso en vivo con una aplicación de producción en el que recibimos muchas críticas negativas para una función que parecía ser un caso ligeramente marginal (relacionado con denegar el permiso de ubicación en un caso de uso que no todas las cuentas de prueba tenían) pero que en realidad no lo era t.

una función de codepush podría impulsar soluciones críticas para los usuarios de inmediato en lugar de esperar a que se actualicen; por alguna razón, parece que los usuarios tardan en actualizar a veces :(

No hay soporte de inserción de código caliente es un NO PASA :-(

Parece que JavascriptCore ya no es necesario para el código interpretado: https://www.theregister.co.uk/2017/06/07/apple_relaxes_developer_rules/?page=2

Si el ecosistema IOS es un obstáculo, ¿por qué no implementarlo en Android solo por ahora? Algo mejor que nada y es un punto de partida.

Muy apreciado por el equipo para implementar esta función lo antes posible.

Hemos construido algunos prototipos básicos aquí, pero realmente no tenemos nada que compartir en este momento. Hacer esto realmente bien requerirá algo de trabajo en la cadena de herramientas del compilador de Dart. Espero que pasen muchos meses antes de que tengamos mucho que compartir aquí. Actualmente, el equipo se centra en la estabilización de 1.0.

Dicho todo esto, te escuchamos. :) Esta es claramente una característica que muchas personas valoran y estamos interesados ​​en proporcionar una funcionalidad como esta eventualmente.

El soporte de "Code Push" para Flutter podría ser el último clavo en el ataúd con respecto a React Native.

Con todo mi amor por RN y la comunidad de RN, siendo el cambio de juego que es, no es rival para Flutter.
Flutter simplemente lo clava en cualquier aspecto (herramientas, rendimiento, lenguaje ...).

Después de 1.0 hits y la comunidad crece un poco más + Soporte de Code Push = No veo ninguna razón para comenzar un nuevo proyecto móvil con nada más que Flutter.

¿Algún progreso en "Code Push"?

¿Qué tan factible sería tener un .so completo reemplazado dinámicamente? Toda la cadena de herramientas del compilador, la alteración del código, etc., no deberían dirigirse a un caso extremo en el que las personas pueden beneficiarse o no, dado que siempre habrá tickets en la parte superior de la lista de prioridades.

Creo que debería haber espacio para "descargar" el archivo .so completo, por lo que la compilación desde el dart hasta el código de la máquina puede ser exactamente la misma. A un componente pequeño pero completamente independiente se le podrían asignar las siguientes "características viables mínimas": descargue .so y reemplace el que se envió originalmente con él, y reinicie la aplicación con la intención de inicio principal.

Responsabilidades adicionales: descargar activos, verificar firmas y demás. Actualice los motores flutter / dart / skia y otras cosas.

Me parece que viola las pautas de iOS, pero realmente no soy fanático de nada interpretado de todos modos, o de iOS en general. Y prefiero tenerlo en Android que no tenerlo en absoluto, solo porque es genial.

Al menos la parte de descarga parece factible ahora que tenemos algunos trabajos aislados permitidos en segundo plano, pero sería interesante ver cómo intercambiar el .so original con el descargado. Tal vez un código .so o java adicional podría hacer esa parte, pero estará en la carpeta del código, no estoy seguro de que la aplicación en sí pueda modificarlo, por lo que probablemente necesitaría algunos ajustes para que el motor de aleteo cargue todos los .so de la aplicación desde el interior. ¿datos?

Empezando a renovar la aplicación de mi empresa usando flutter. Sin embargo, nuestra principal demanda es tener una función de actualización en caliente, ya que todavía estamos en fase beta y seguimos probando nuevas interfaces de usuario y funciones rápidamente. Viviría para tener esta característica.

¿Alguna actualización?
(Apuesto a que la función ya está lista y será una sorpresa cuando llegue la 1.0)
😁

voto a favor

Solo hay una razón para evitar que usemos Flutter: código push

Si ustedes no pueden admitir Code Push, ¿hay alguna manera de hacer un analizador para generar desde algunos diccionarios (como json, xml ...) a Flutter Widget? ¿Es esto imposible o una buena idea?

Esto suena un poco prometedor. Configuración remota de Firebase al widget si es necesario.
Aunque conseguir que las empresas tengan una idea de lo que quieren también ayuda :)

El viernes 12 de octubre de 2018 a las 3:45 a. M. Hưng Lương Đỗ Minh [email protected]
escribió:

Si no pueden admitir Code Push, ¿hay alguna manera de hacer un analizador para
generar desde algunos diccionarios (como json, xml ...) a Flutter Widget? Es
esto imposible o una buena idea?

-
Estás recibiendo esto porque comentaste.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/flutter/flutter/issues/14330#issuecomment-429251785 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AC4TYe9qDMi4bt2U5qyyAnJisN3ys_Z5ks5ukFavgaJpZM4RxUZi
.

Creo que al menos la UI / View escrita en Dart se puede descargar a través de la red desde el servidor.
Para inspirarse, vea cómo lo está haciendo Qt Quick Framework.

QtDD12 - Sirviendo aplicaciones QML a través de la red - Jeremy Laine:

• Video
• Diapositivas

¡Espere que pueda incluirse en la próxima versión 1.0!

Muchos de nuestros clientes utilizarán nuestra aplicación Flutter en un dispositivo de quiosco detrás de estrictos cortafuegos que evitarían los mecanismos de actualización de aplicaciones de Google Store. Estos clientes no incluirán en la lista blanca Play Store. En última instancia, tendremos cientos de dispositivos de hardware con la aplicación Flutter, ¡y tener una forma de enviar actualizaciones a la aplicación mientras nos adherimos a las restricciones de firewall del cliente sería increíble!

@eseidelGoogle : ha pasado un tiempo desde que ustedes proporcionaron algunas actualizaciones aquí.

¿Todavía están trabajando en esto? Como van las cosas

El progreso continúa. No hay actualizaciones para compartir en este momento.

Se nos ocurrieron tres términos claros para lo que la gente ha estado agregando a este error el día de hoy:

• "Parches dinámicos": la capacidad de actualizar el código de Dart de una aplicación en el campo descargando un parche (de algún tipo) y proporcionándolo a la máquina virtual de Dart. Esto requeriría una recarga de la aplicación para que surta efecto.
• "Carga dinámica de extensiones": la capacidad de descargar algún código de Dart que no estaba escrito cuando la aplicación se publicó por primera vez, lo que agrega una nueva función a la aplicación. Esto se puede hacer sobre la marcha. Es posible que requiera que la aplicación principal sea más grande, ya que no podemos saber de antemano qué se necesita para cada extensión futura.
• "Entrega de aplicaciones modular": la capacidad de empaquetar una sola aplicación en varios archivos separados al compilarla y descargarlos de forma independiente según sea necesario.

Probablemente deberíamos dividir este problema en tres errores que podamos rastrear por separado.

¿Es esto realmente factible para iOS? Aparte de la posibilidad de que Apple prohíba esto al igual que lo hizo con rollout.io , el javascript tendría que ejecutarse sin ningún tipo de JIT (no escribir en páginas ejecutables en iOS). Además, las diferentes características de GC del núcleo de Javascript mientras Flutter crea toneladas de objetos de corta duración podrían no ser un buen augurio.

Lo que Apple permite o no permite actualmente (o en el futuro) está totalmente separado de las implementaciones técnicas. Flutter se ejecuta en muchos lugares además de iOS. Obviamente, nos gustaría diseñar siempre tecnologías que puedan funcionar en iOS (como creo que podrían hacerlo muchas posibles soluciones de "inserción de código"), pero iOS no es la única consideración. ¿Espero que ayude?

Realmente triste no ver Code Push lanzado en 1.0. Como otros, esta es la razón principal por la que no puedo usarlo en proyectos que requieren la capacidad de parchear sin esperar a las tiendas de aplicaciones.
Aprecio que sea un gran esfuerzo llegar allí, mucha suerte.

Solo hay una razón para evitar que usemos Flutter: código push

Me gustaría dejar mis comentarios solo para mostrar mi interés en este tema.
Mi empresa desarrolla una aplicación para varios clientes solo para Android para administrar los equipos de mantenimiento. En 2018 lanzamos aproximadamente 100 actualizaciones, ninguna de las cuales ha solicitado una nueva versión a través de Google Play, ya que la mayoría son pequeños ajustes y personalizaciones que requiere cada cliente, que son impredecibles de antemano.
Reescribir esta aplicación en Flutter sería un sueño, pero aparte de los costos de reescritura, desperdiciar dinero para esperar a que se publique una solución o personalizaciones a través de GPlay sería una pesadilla.

Espero lograr lo antes posible.

Otro punto: si el equipo de Flutter proporciona oficialmente la solución de hot-fix, creo que Apple puede rechazar todas las aplicaciones creadas por Flutter en algún momento, porque el hot-fix rompe la Guía de revisión de la AppStore definitivamente, los desarrolladores pueden omitir la revisión de la AppStore y modificar su aplicación, no es seguro para los usuarios.

Actualmente, Apple rechaza todas las aplicaciones con JsPatch, que era la solución de hotfix más popular en China. JsPatch se basa en el tiempo de ejecución de JsCore y OC.

Me gustaría crear aplicaciones Flutter sin la función de corrección rápida, en lugar de que Apple pueda rechazar aplicaciones en el futuro.

@MaxZeng Es bueno saber acerca de JsPatch. Pero por ahora, parece que se permiten parches en caliente. Hay muchas aplicaciones React Native en la tienda de Apple y todas usan parches en caliente a través de CodePush.

Si solo es compatible con iOS / Android, como este ejemplo:
MyFlutterApplication pide permiso / quiere actualizar su aplicación
Registros de cambios: agregar gatitos y perros (v1.0)
Permitir | No permitir

después de revisar las pautas para ambas partes.

@MaxZeng Es bueno saber acerca de JsPatch. Pero por ahora, parece que se permiten parches en caliente. Hay muchas aplicaciones React Native en la tienda de Apple y todas usan parches en caliente a través de CodePush.

Sí, ReactNative es una excepción al código push por ahora, pero no significa que Apple lo admita oficialmente. La aplicación de nuestra empresa ha sido rechazada por AppStore más de 3 veces recientemente debido a un marco similar a RN, y tenemos que reescribir estas funciones por OC / H5, es una pesadilla para los desarrolladores.

React Native sigue siendo un marco SEGURO para Apple, porque finalmente se procesa sobre UIKit, pero Flutter es completamente diferente:
1 、 En primer lugar, rompe los ecosistemas de desarrolladores de Apple, pasa por alto el marco UIKit y está FUERA del control de Apple, por ejemplo, habrá más y más aplicaciones de estilo MD en AppStore, y esto puede ir en contra de la Guía de interfaz humana de Apple. Apple es una empresa famosa por su gran diseño.
2 、 En segundo lugar, si Flutter admite oficialmente la recarga en caliente, Apple puede usar este motivo para rechazar las aplicaciones Flutter directamente.

Desde mi perspectiva, Flutter debería seguir la Guía de revisión de la AppStore en lugar de romperla, esto es importante para un marco móvil multiplataforma, no debería romper el ecosistema de Apple porque podemos hacerlo. Si Apple rechaza a Flutter, la ventaja clave de Flutter desaparecerá.

El CodePush no es una técnica difícil o misteriosa, Apple puede implementarlo fácilmente (especialmente basado en OC), la única razón por la que Apples no lo permite es que no es seguro para los usuarios finales, y esto daña la AppStore / Google Play por completo. Es un desastre si muchas aplicaciones pueden cambiar su funcionalidad en cualquier momento y en cualquier lugar, y es difícil rastrear y limitar estas acciones dañinas después de que se permite la publicación de la aplicación.

CodePush no es solo una técnica, es una parte importante de los ecosistemas móviles. Creo que el equipo de Flutter no debería proporcionar tal técnica oficialmente, aunque algunos desarrolladores pueden implementarla de forma privada, esto está bien porque no se usará de manera salvaje.

@MaxZeng Es bueno saber acerca de JsPatch. Pero por ahora, parece que se permiten parches en caliente. Hay muchas aplicaciones React Native en la tienda de Apple y todas usan parches en caliente a través de CodePush.

Sí, ReactNative es una excepción al código push por ahora, pero no significa que Apple lo admita oficialmente. La aplicación de nuestra empresa ha sido rechazada por AppStore más de 3 veces recientemente debido a un marco similar a RN, y tenemos que reescribir estas funciones por OC / H5, es una pesadilla para los desarrolladores.

React Native sigue siendo un marco _SAFE_ para Apple, porque finalmente se procesa sobre UIKit, pero Flutter es completamente diferente:
1 、 En primer lugar, rompe los ecosistemas de desarrolladores de Apple, pasa por alto el marco UIKit y está FUERA del control de Apple, por ejemplo, habrá más y más aplicaciones de estilo MD en AppStore, y esto puede ir en contra de la Guía de interfaz humana de Apple. Apple es una empresa famosa por su gran diseño.
2 、 En segundo lugar, si Flutter admite oficialmente la recarga en caliente, Apple puede usar este motivo para rechazar las aplicaciones Flutter directamente.

Desde mi perspectiva, Flutter debería seguir la Guía de revisión de la AppStore en lugar de romperla, esto es importante para un marco móvil multiplataforma, no debería romper el ecosistema de Apple porque podemos hacerlo. Si Apple rechaza a Flutter, la ventaja clave de Flutter desaparecerá.

El CodePush no es una técnica difícil o misteriosa, Apple puede implementarlo fácilmente (especialmente basado en OC), la única razón por la que Apples no lo permite es que no es seguro para los usuarios finales, y esto daña la AppStore / Google Play por completo. Es un desastre si muchas aplicaciones pueden cambiar su funcionalidad en cualquier momento y en cualquier lugar, y es difícil rastrear y limitar estas acciones dañinas después de que se permite la publicación de la aplicación.

CodePush no es solo una técnica, es una parte importante de los ecosistemas móviles. Creo que el equipo de Flutter no debería proporcionar tal técnica oficialmente, aunque algunos desarrolladores pueden implementarla de forma privada, esto está bien porque no se usará de manera salvaje.

Punto muy interesante y que suena razonable en algunos aspectos, pero también tiene algunos errores.

1. Flutter también es compatible con Cupertino de Apple , MD no es el único elegido.
2. Es posible que conozca la Unidad en el área de juegos, el sistema de renderizado de Flutter funciona de manera similar en algunos aspectos.
3. De hecho, y por ahora, el uso de la web (JS) puede implementar CodePush y omitir la revisión de AppStore para modificar su aplicación. Entonces, ¿por qué rechazar a Flutter (dardo) y soltar a JS?

Entonces, ¿por qué rechazar a Flutter (dardo) y soltar a JS?

JS se ejecuta en una caja de arena y, por lo tanto, es seguro. (como todas las páginas web cargadas en Safari)

Dart se compila en código binario y no está limitado por este tipo de caja de arena.

Soy desarrollador de Android desde hace muchos años. Creo que Code push no es tan importante.
Si sin Code Push, ¿no puedes desarrollar? Si es así, es una tontería.
Flutter es un marco para dispositivos móviles, por lo que primero debes aprender más sobre el desarrollo de dispositivos móviles.
Sin la inserción de código, puede utilizar la actualización completa.
Como dice el anuncio: cruce el puente cuando llegue.
Como desarrollador, creo que es más importante utilizar diferentes formas de resolver el mismo problema.

Flutter no es React Native, no puedes usar la experiencia de React Native (u otro marco) para ver Flutter. Son cosas diferentes.

@MaxZeng Quizás flutter pueda habilitar la actualización en caliente exclusivamente para Android.

Sin una actualización en caliente como RN, ¡no nos mudaremos a Flutter! ¡Los marcos deberían facilitar la vida de un desarrollador!

Las flores que esperaba se han ido.

@MaxZeng Quizás flutter pueda habilitar la actualización en caliente exclusivamente para Android.

1 、 En realidad, también dañará los ecosistemas de Google Play Store, hará que el equipo de Android sea difícil de controlar los comportamientos de la aplicación.
2 、 CodePush no es necesario para la mayoría de las aplicaciones, esta tecnología será utilizada maliciosamente por algunos desarrolladores.
3 、 Podría causar un gran "Ataque de hombre en el medio" si los desarrolladores no cifran los parches correctamente, los piratas informáticos malignos pueden modificar el código enviado para secuestrar las aplicaciones Flutter.

Solo quiero decir que el hotfix es una función de importación para la mayoría de las empresas chinas. más del 70% de los dispositivos Android chinos no son compatibles con Google Play

@ act64 comprobar https://github.com/flutter/flutter/wiki/Roadmap

@ act64 comprobar https://github.com/flutter/flutter/wiki/Roadmap

La hoja de ruta decía hotfix en Android. Espero que iOS sea compatible pronto.

Sin embargo, @taibaiyinxing Flutter no puede proporcionar funciones no permitidas por Apples App-store.

Sin embargo, @taibaiyinxing Flutter no puede proporcionar funciones no permitidas por Apples App-store.

@zoechi Usamos una aplicación empresarial y no necesitamos subirla a la tienda de aplicaciones.

Parcheo dinámico en Android, que permite implementar actualizaciones de código en aplicaciones Flutter que se ejecutan en Android directamente desde un servidor.
🎉

https://github.com/flutter/flutter/wiki/Roadmap

Parece que no hay ningún plan para admitir CODE PUSH en IOS este año.

https://github.com/flutter/flutter/wiki/Roadmap

"La lista aquí no debe verse ni como exhaustiva ni como una promesa de que completaremos todo este trabajo". :)

El trabajo de inserción de código aún se encuentra en los primeros días de pruebas. Aún no se ha determinado en qué plataformas implementaremos o no implementaremos ese trabajo en 2019. Después de todo, solo es febrero. ¡10 meses es mucho tiempo!

Actualmente, los ingenieros se centran en desarrollar la tecnología central para admitir los 3 casos de uso de @Hixie descritos en: https://github.com/flutter/flutter/issues/14330#issuecomment -442274897
Espero que comencemos a hacer algunas pruebas limitadas de al menos uno de esos casos de uso en los próximos meses.

Debido a que nuestra tecnología de desarrollo de aleteo no es muy madura, la APLICACIÓN se actualiza con frecuencia y muchas son actualizaciones urgentes. Y nuestra aplicación no planea cargar una tienda de aplicaciones. Entonces esta característica es muy importante. Esto puede mejorar la velocidad de iteración de la APLICACIÓN. De lo contrario, la fragmentación de APP hace que nuestra api se retrase.

Como creo que todos estamos de acuerdo, el motivo de este problema es que entregar cualquier aplicación móvil a los usuarios finales a través de los jardines amurallados administrados por Google y Apple (las tiendas), es un gran inconveniente para los desarrolladores de aplicaciones (sin mencionar mal servicio a los usuarios finales de aplicaciones buenas / innovadoras), siendo Apple el más inconveniente (días para Apple en lugar de horas para Google).

Como punto lateral, una posible solución podría ser si las tiendas proporcionaran una ruta para actualizaciones instantáneas para desarrolladores 'confiables' (como un servicio de vía rápida). Luego, Google y Apple podrían hacer una auditoría en tiempo real (automatizada, ... ¿como con AI ?? ... con retroceso automático post-facto según sea necesario) de la aplicación. Pero esto parece poco probable por un montón de razones técnicas y de otro tipo. Por supuesto, ambas tiendas tienen una vía rápida para los probadores beta.

Entonces ... mientras espera las funciones de este número, una forma de aliviar los inconvenientes que implica la entrega de cualquier aplicación móvil a los usuarios finales es automatizar los pasos.

Para ver un ejemplo de una herramienta que hace este tipo de automatización para Flutter, consulte:
https://github.com/mmcc007/fledge
Para el registro, incluye documentación para muchos de los pasos de configuración únicos involucrados que no se pueden automatizar fácilmente:
https://mmcc007.github.io/fledge/

@charliezzo Con esta herramienta, o herramientas similares, se puede entregar una aplicación Flutter (y actualizaciones, etc.) a los probadores beta de Android e iOS en cuestión de minutos.

También tiene un flujo de trabajo para automatizar la entrega a los usuarios finales a través de las tiendas (horas + para Google, días + para Apple 😂👍).

@ mmcc007
Oh gracias. pero digo que no quiero enviar mi aplicación a Google Play ni a la tienda de aplicaciones.
necesito vender mi aplicación de otra manera.
y no necesito Google Play ni la tienda de aplicaciones para actualizar mi aplicación.
Solo quiero actualizar mi aplicación cuando los usuarios la instalen y la inicien.
y, flutter es un marco de 60FPS o superior, puede hacer un juego en línea, no queremos tener un pequeño parche de Google Play y la tienda de aplicaciones.
usted sabe que cada parche en un poco de tiempo por google play y la tienda de aplicaciones son lentos y difíciles.
de hecho, sabes que no podemos usar Google Play en China. y la tienda de aplicaciones es muy lenta.
Hay muchas tiendas de aplicaciones como Google Play en China. No tenemos tiempo para actualizar todas las tiendas de aplicaciones.

Code Push debería ser una característica principal en Flutter. Ponlo encima.

Podemos hacerlo reemplazando todos los archivos en la app_flutters en Android

hola, ¿puedes darme tu correo electrónico para una mayor discusión? nuestro equipo también encontró esta solución, pero solo puede funcionar cuando la aplicación debe ser eliminada y reiniciar la aplicación。tks @LNeway

hola, ¿puede darme su correo electrónico para una mayor discusión? Nuestro equipo también encontró esta solución, pero solo puede funcionar cuando la aplicación debe ser eliminada y reiniciar la aplicación. tks @LNeway
@KinsomyJS
También ejecuté una demostración para verificar la viabilidad. Jajaja ~

Comparta con un breve fragmento o una publicación de blog o comente aquí o cc [email protected] en el correo electrónico ...

@LNeway @KinsomyJS ¿
Gracias

Sin embargo, @taibaiyinxing Flutter no puede proporcionar funciones no permitidas por Apples App-store.

@zoechi ¿Estás diciendo que tú y / o el equipo de Flutter tienen un análisis que concluye que una técnica de codepush factible por Flutter es fundamentalmente diferente a una de React-native y está prohibida, y por lo tanto, debido a Apple, es posible que nunca llegue al iPhone?

Si se agrega esta función, ¿admitirá la versión beta 1.0.0?

@dahabdev

Por lo que vale, desde mi experiencia con Ionic, creo que el "código push" está sobrevalorado, y espero que el equipo de Flutter no pase demasiado tiempo trabajando en él mientras todavía faltan muchas otras características básicas y esenciales.

Cuando desarrollé UAVForecast, usé Ionic, atraído por la función de "implementación iónica" que ofrecía actualizar todo el contenido de la aplicación de forma remota. En aquel entonces (esto fue en 2014), los tiempos de revisión de la App Store de Apple eran del orden de 2 semanas. Quería iterar rápidamente, moverme rápido y romper cosas, como dicen.

Al principio, el "despliegue iónico" fue genial, pero pronto noté algunos problemas importantes. Causó confusión a mis usuarios ("la aplicación dice que se ha actualizado, entonces, ¿por qué hay otra actualización pendiente en Play Store / App Store?"); a veces rompía la aplicación, por ejemplo, cuando un complemento de Cordova cambiaba silenciosamente los metadatos de la aplicación (por ejemplo, los permisos), pero no se actualizaba con un código activo; rastrear los números de versión era complicado y no estaban sincronizados con lo que había enviado a las tiendas; me daba pereza las pruebas, ya que siempre podía "desplegarme iónicamente" yo mismo para eliminar los errores; ya veces terminé empujando errores peores, que podrían haber sido detectados por los equipos de revisión de aplicaciones si les hubiera dado la oportunidad de mirar.

Aproximadamente un año después del lanzamiento de la primera versión, los tiempos de revisión de la App Store habían mejorado significativamente. Hoy, solo quedan unos pocos días y, por supuesto, en la Play Store de Google puede ser tan solo unas pocas horas. Dados todos los problemas que había tenido, decidí eliminar la funcionalidad de "implementación iónica" de mi aplicación, y con varios millones de descargas detrás de mí, no he mirado hacia atrás.

Si bien me gusta Ionic y realmente aprecio todo lo que su desarrollador, Drifty, ha hecho (¡gracias!), Yo diría que Drifty cometió el error de invertir demasiado tiempo en funciones brillantes como la inserción de código que atrae a los usuarios, y no el tiempo suficiente para obtener bien los tornillos y tuercas del marco para evitar problemas que acaben por ahuyentarlos. Ahora, en su cuarta versión, Ionic se ha reescrito tantas veces de formas incompatibles con versiones anteriores que dejé de intentar mantenerme al día; la última versión todavía tiene varios problemas graves pendientes que me impiden actualizar, y ahora estoy reescribiendo toda mi aplicación en Aleteo.

La experiencia hasta ahora ha sido excelente y me estoy divirtiendo mucho, pero todavía hay algunas lagunas y omisiones importantes en Flutter, especialmente en los complementos. Por ejemplo: no hay integración de campos de texto con el autocompletado de contraseñas, el complemento de Google Maps es básico (y hay errores de representación de marcos relacionados), el WebView nativo no admite file: // URL para cargar activos, la barra de pestañas no admite fondos transparentes o degradados, las celdas de la tabla no admiten colspan, ThemeData no es extensible con colores específicos de la aplicación para usar con la animación, la única biblioteca DateTime totalmente consciente de la zona horaria carece de muchas características importantes de momento y momento-zona horaria, hay Tantos enfoques para la administración del estado es confuso para los recién llegados, tienes que "limpiar" con frecuencia para evitar excepciones extrañas, el intercambio en caliente a menudo no funciona como debería, y podría continuar ...

Clasificaría _todos_ estos como más importantes que "código push", especialmente si se corre el riesgo de que Apple rechace las aplicaciones Flutter, si requiere cambios importantes en el marco del compilador que eventualmente podrían dificultar las optimizaciones que mejoran el rendimiento de la aplicación (tomaría un Mejora del rendimiento del 5% con respecto a la "inserción de código" cualquier día), o toma tiempo para completar la función del marco.

Por otro lado, puedo ver que algunos desarrolladores pueden realmente necesitarlo en algunas situaciones, especialmente si están operando fuera de las tiendas, así que puedo entender el entusiasmo aquí.

@matthewlloyd ¡ muchos puntos geniales!

Si ustedes no pueden admitir Code Push, ¿hay alguna manera de hacer un analizador para generar desde algunos diccionarios (como json, xml ...) a Flutter Widget? ¿Es esto imposible o una buena idea?

--¿Alguien tiene una opinión sobre este?
https://pub.dartlang.org/packages/dynamic_widget
parece prometedor, aunque no aborda el miedo al "error crítico".

Esa es la parte loca es que la inserción de código es el elefante en la sala, eso es profundamente un problema de negocio / proceso y técnico, y un lado tiende a ignorar al otro ...

no hay integración de campo de texto con el autocompletado de contraseñas, el complemento de Google Maps es básico (y hay errores de representación del marco relacionados), el WebView nativo no admite archivos: // URL para cargar activos, la barra de pestañas no admite transparencia o fondos degradados, las celdas de la tabla no admiten colspan, ThemeData no es extensible con colores específicos de la aplicación para usar con la animación, la única biblioteca DateTime totalmente consciente de la zona horaria carece de muchas características importantes de momento y momento-zona horaria, hay muchos enfoques para la administración estatal, es confuso para los recién llegados, tienes que "limpiar" con frecuencia para evitar excepciones extrañas, el intercambio en caliente a menudo no funciona como debería, y podría continuar ...

Con suerte, todos estos ya tienen un problema de Github: D

Esto estaba anteriormente en nuestra hoja de ruta para 2019. Después de investigar esto con mayor detalle, hemos decidido no continuar con este trabajo por ahora.

Fueron varios los factores que nos llevaron a tomar esta decisión:

• Para cumplir con nuestra comprensión de las políticas de la tienda en Android e iOS, cualquier solución se limitaría al código JIT en Android y al código interpretado en iOS. No estamos seguros de que las características de rendimiento de una solución de este tipo en iOS alcancen la calidad que exigimos de nuestro producto. (En otras palabras, "sería demasiado lento").

• Existen serios problemas de seguridad. Dado que estos parches esencialmente permitirían la ejecución de código arbitrario, serían vectores de malware extremadamente atractivos. Podríamos mitigar esto requiriendo que los parches se firmen con la misma clave que el paquete original, pero esto es propenso a errores y cualquier error tendría serias consecuencias. Este es, fundamentalmente, el mismo problema que ha plagado a las plataformas que permiten la ejecución de código de fuentes de terceros. Este problema podría mitigarse mediante la integración con un mecanismo de actualización de la plataforma, pero esto anula el propósito de un mecanismo de parcheo fuera de banda.

• Actualmente no existe una solución de alojamiento de código abierto lista para usar para parchear aplicaciones, por lo que tendríamos que depender de que las personas configuren sus servidores web en consecuencia, o tendríamos que crear integraciones para servicios propietarios de terceros, o bien tendría que crear nuestra propia solución a medida. Hospedar parches es un espacio en el que no estamos ansiosos por ingresar. Hacer que las personas configuren su propio servidor los deja expuestos a cometer errores con implicaciones potencialmente graves, como se explicó en el punto anterior sobre seguridad. Depender de los servicios de terceros pone a Flutter en una posición incómoda de tener que elegir a los ganadores y nos expone al riesgo de que esos proyectos mismos realicen cambios en las políticas que afectarían esta función.

Preferimos dedicar nuestro esfuerzo de ingeniería a otros problemas por ahora. Esperamos seguir experimentando en este espacio y probablemente nos volvamos a tomar en serio esto en el futuro (por ejemplo, probablemente necesitemos una solución de actualización para aplicaciones de escritorio), pero probablemente no este año.

Si bien entiendo la razón por la que se eliminó esta función, sigue siendo decepcionante. Play Store y App Store son consideraciones importantes, pero no todas las aplicaciones se distribuyen de esta manera. Para nuestro caso de uso, proporcionamos al cliente tanto el dispositivo como la aplicación preinstalados. Tener un mecanismo para enviar actualizaciones dinámicamente al usuario es una característica muy importante, ya que no queremos pasar por las tiendas. Esta característica hubiera sido invaluable. Espero que se vuelva a visitar en el futuro como mencionaste.

Gracias por comunicar de manera transparente la racionalidad del equipo.

@eseidelGoogle ¿El código JavaScript compilado de Dart podrá usar Skia para representar páginas?

Esto es bastante decepcionante.

Con respecto a todos los problemas de seguridad y cumplimiento de la tienda que mencionaste, pueden ser válidos y legítimos, pero al final del día hay un ejemplo de tecnología de "actualizaciones en caliente" que ya está funcionando: código push.

React Native + el servicio de inserción de código funciona y ha demostrado su eficacia en el mundo real. Está probado en batalla. No parece haber ningún problema con las tiendas de aplicaciones con respecto a las actualizaciones indirectas. Parece que todo el mundo está "bien" con eso. Así que creo que la solución de Flutter también podría permitirse.

Con respecto a los problemas de rendimiento, podría ser una buena idea dejar que el desarrollador elija trabajar en el modo de "bajo rendimiento" pero habilite las actualizaciones en vivo.

¡Buen movimiento! Prefiero dedicar el esfuerzo de ingeniería a optimizar Flutter que a agregar una función de inserción de código que puede complicar demasiado y dañar el ecosistema.

Actualmente tengo mi primera aplicación, desarrollada en Flutter, en la prueba beta abierta y he distribuido unos 10 paquetes de aplicaciones con correcciones. Pero debería estar libre de errores en su mayoría cuando lo publique en producción.

Así que no sé si alguna vez necesitaré esta función, pero encontré este paquete de publicación OTA Update que parece estar funcionando bien con una puntuación de 89, que solo se ve disminuida por su popularidad. ¿Ese paquete es seguro? Parece estar descargando APK de una URL y descomprimiéndolo de forma nativa y activando la intención de instalación de APK en Android.

Aquellos que necesiten absolutamente esta función pueden probar ese paquete.

Pero puedo ver por qué el equipo de Flutter no está demasiado entusiasmado con esto, porque, tomemos el paquete anterior por si acaso. Parece que se está descargando desde una URL. Y un sitio web siempre es más amigable para los piratas informáticos que las aplicaciones nativas. Hay demasiados problemas de seguridad a partir de ahora. Simplemente hace que una aplicación Flutter sea tan vulnerable como un sitio web que es un estricto no-no.

Tenía una máquina de 2 GB de RAM cuando comencé, tratando de desarrollar una aplicación para Android como siempre quise, pero mi máquina no estaba a la altura. Probé PhoneGap, Cordova, algún marco Intel, React-Native, y ninguno de ellos siquiera comenzó a ejecutarse. Flutter fue el único con el que comencé y con su hermosa interfaz de usuario y herramientas de desarrollo, está muy por delante de sus contemporáneos incluso sin esta función.

¿Cualquier actualización?

El flujo de trabajo de lanzamiento de la aplicación nunca volverá a ser el mismo después de la forma en que react-native nos echó a perder con Code Push. Es una verdadera lástima que Flutter no lo apoye. Flutter se está perfilando muy bien y podría haber sido un competidor de React Native si optaran por admitir esta función. Pobre de mí...

@Hixie Está bien, entonces un cambio técnico / de ingeniería fundamental tiene demasiados inconvenientes por ahora, eso tiene sentido para mí.

Sin embargo, ¿cómo se siente al ayudar a los desarrolladores de flutter a esa preocupación comercial a corto y mediano plazo con algunos enfoques alternativos que obtienen algo de documentación / discusión? Quizás incluso videos, aunque quizás no sea una solución 'respaldada' u oficial, pero algo de atención.

p.ej

• Configuración en tiempo real de Firebase
• Json-> widgets basados ​​en el servidor (por ejemplo, https://github.com/dengyin2000/dynamic_widget/blob/master/WIDGETS.md o simlar, todavía no apruebo el complemento exacto, pero la idea)
• o quizás algo más, quizás funciones en la nube para usuarios avanzados ...
• obviamente, no estoy sugiriendo que tome un montón de esfuerzo de ingeniería para un caso de uso 'grande', sino una especie de alternativa hola-mundo-código-push-push que aborda la mayor parte de la necesidad sin un 'arreglemos / cambiemos cada cosa 'tipo arquitectura.

mi premisa es que "nosotros" podemos satisfacer el 70-90% de la preocupación por codepush sin un cambio fundamental de arquitectura para flutter; ¿Qué piensa alguien de esto?

El enfoque de código como interfaz de usuario de Flutter podría incluso hacer esto más fácil de lo que lo haría para los desarrolladores de Android ...

He visto personalmente al menos dos compañías que eligieron a los otros chicos en lugar de Flutter solo por esta razón, y muchas otras han hablado de manera similar.

Quizás la conversación podría irse
"Usuario: ¿Se está saltando la compatibilidad con codepush?"
"Equipo de Flutter: Sí, por ahora, por estas razones, (como lo hizo), pero además, podría probar A o B para algunos casos de uso"

Perdón por el comentario largo

@neiljaywarner Quizás valga la pena echarle un vistazo a LUA. Hice una prueba de concepto el año pasado mediante la cual los scripts de LUA podrían usarse para crear / ajustar la funcionalidad de una aplicación Flutter.

@neiljaywarner Estoy a favor de ese tipo de enfoque, pero esa es una preocupación ortogonal de lo que cubre este error.

Aunque entiendo las razones detrás de renunciar a esta función, sigue siendo decepcionante. Play Store y App Store son consideraciones importantes, pero no todas las aplicaciones se distribuyen de esta manera. Para nuestros casos de uso, proporcionamos a los clientes dispositivos y aplicaciones preinstalados. Tener un mecanismo para enviar actualizaciones dinámicamente a los usuarios es una característica muy importante porque no queremos pasar por la tienda. Esta característica es muy valiosa. Espero volver a examinarlo como mencionaste en el futuro.

Gracias por comunicar la racionalidad del equipo de forma transparente.

estoy de acuerdo

La funcionalidad de inserción de código significa más aplicaciones, más clientes, más desarrolladores, más pruebas, más corrección de errores, menos problemas

Para el MVP de una startup o las aplicaciones en crecimiento, las actualizaciones o la corrección de errores son cruciales, mientras que el rendimiento es una preocupación menor la mayor parte del tiempo. Esto causará pros y contras del ecosistema Flutter. El declive de la adopción, las nuevas empresas y el desarrollador personal son importantes para el crecimiento de la comunidad en las primeras etapas. Las ventajas podrían ser las aplicaciones de calidad y los equipos que se cambiarían a Flutter y que apuntan a un mayor rendimiento.

@maplerichie , De acuerdo, la razón por la que me encanta flutter es la experiencia del desarrollador, el rendimiento y la multiplataforma para todos los dispositivos. No me importa si no se implementará el empuje de código (tal vez), es por el bien de la reputación y la popularidad del ecosistema. Ahora sé por qué la inserción de código parece demasiado lenta cuando se usan aplicaciones de Windows (inicio lento, retraso de entrada y animación retrasada) aquí

necesitamos mucho esta función
Necesito una actualización en caliente

Como otros mencionaron anteriormente, es posible que las grandes empresas y los grandes equipos de desarrollo no necesiten actualizaciones en caliente. Pero piense en una pequeña puesta en marcha, un par de desarrolladores que trabajan en una aplicación móvil, entregando funciones a la producción con ciclos de lanzamiento rápidos. No hay tiempo para pruebas y ciclos de control de calidad. Cree una nueva característica, vea si funciona y a los usuarios les gusta, reemplácela o corríjala. No podríamos llegar a donde estamos sin actualizaciones calientes. Es un verdadero cambio de juego para el desarrollo móvil.

@yaronlevi Soy una "pequeña startup", incluso menos de un par de desarrolladores trabajando en una aplicación móvil, soy solo yo, y entrego a producción con ciclos de lanzamiento rápidos. Con Google Play Store ofreciendo actualizaciones que demoran solo unas horas, y Apple App Store revisando actualizaciones casi siempre en menos de 24 horas en mi experiencia en estos días, yo definitivamente no necesito la inserción de código. Si Flutter tuviera código push, tomaría medidas activamente para asegurarme de que esté deshabilitado en mi aplicación.

Actualmente soy el único desarrollador de una aplicación móvil (y el back-end correspondiente) para una pequeña empresa. Realmente amo Flutter, pero tengo que explicar constantemente a un cliente que no entiende la necesidad de pruebas unitarias o pruebas de automatización por qué lleva tanto tiempo implementar funcionalidades que se pueden describir en 10 palabras. Estoy un poco preocupado por tener que lanzar algo a medio hacer y no poder impulsar rápidamente las correcciones de errores críticos. Lo haré sin él por ahora, pero definitivamente sería bueno tener la inserción de código. Sin embargo, entiendo los desafíos técnicos y las preocupaciones de seguridad y, al final, apoyo un enfoque precavido.

bueno, gracias de todos modos.
Supongo que tenemos que resolverlo por nosotros mismos.

realmente decepcionante :)

El SDK de Flutter para web pronto se fusionará con el SDK para dispositivos móviles. Una solución es utilizar un WebView móvil para cargar el código de flutter. 😁

@matthewlloyd hola, es necesario admitir la actualización en caliente, el punto no es por el momento de revisar. El usuario debe estar vinculado a la AppStore y descargar la aplicación nuevamente.

Tal vez ayudar
https://github.com/dengyin2000/dynamic_widget
https://github.com/neohelden/Flutter-AdaptiveCards

Realmente no veo mucho problema urgente con no tener código push. Casi todos los usuarios tienen la actualización automática en su tienda de aplicaciones. Sin embargo, sería bueno proporcionar una solución alternativa para distribuir actualizaciones sin una App Store.

MXFlutter usa JavaScript para implementar las capacidades de renderizado de Flutter, admite la sintaxis de Flutter y admite la inserción de código y la actualización en caliente.
https://github.com/TGIF-iMatrix/MXFlutter

@ TGIF-iMatrix ¿sabe si esta solución cumple con la política de distribución de Store?

@truongsinh
Es seguro ya que es una distribución js-> analizador nativo-> enfoque de composición de widgets.

consideraremos usar flutter si es compatible con la inserción de código

@ TGIF-iMatrix Es muy probable que esto no sea aprobado por Apple, ya que la exención para las actualizaciones de Javascript Core ha sido eliminada de los Acuerdos de la App Store, y muchos usuarios de CodePush han sido advertidos / denegados debido a esa característica.

Tal vez deberíamos reformular la pregunta, "renderizado dictado por el servidor" frente a "inserción de código". El "renderizado dictado por el servidor" se trata solo de una interfaz de usuario / diseño / tema diferente, mientras que la inserción de código también implica cambios en la lógica, permisos, complementos, etc.

Tal vez, sin embargo, en ese punto, puede usar un complemento para hacer eso, por lo que esto frustra el propósito de este problema.

¿Alguien probó tinker-lib con flutter, que es de tencent github repo y tuvo éxito? archivo de artefacto jar

Espero tener una solución lo antes posible.

Con respecto a las implicaciones de rendimiento de la implementación de inserción de código, ¿sería de alguna ayuda compilar el código de Dart en WebAssembly? Esto puede permitir la implementación de la compilación JIT en iOS dentro del entorno limitado de JavaScript.

necesitamos una iteración rápida y un desarrollo ágil.
si no hay una actualización en caliente, flutter siempre es un hermano menor para reaccionar nativo.

La actualización en caliente es muy importante para nosotros, si flutter admite la actualización en caliente, usaremos flutter para sustituir a react native.

Había planeado la mejor manera posible para la inserción de código, pero debido a limitaciones de tiempo, solo puedo comenzar este proyecto a partir de noviembre de la semana pasada o de diciembre, no modifico ningún código de motor o código de marco ni ningún código de Java como tinker lib, por lo que no viola cualquier término de la tienda, la aplicación de salida también es aot, por lo que no hay regresión de rendimiento, trato de que sea una implementación tan fácil para que cualquiera pueda agregar a su aplicación, según mi investigación sobre la base de código, el equipo de flutter se hace intencionalmente imposible para hacer que el código empuje i Probé todas las posibilidades con la implementación actual y concluí que las únicas formas posibles es hacer modificaciones al motor o preparar una solución sin modificar el motor, opté por la segunda opción y planifiqué todos los requisitos necesarios para el proyecto. Espero que el proyecto tenga éxito. Mientras tanto, si el equipo de flutter vuelve a evaluar el problema, todos estamos contentos con la implementación incorporada.

La actualización en caliente siempre será necesaria！

esto es imprescindible, una funcionalidad crucial

Había planeado la mejor manera posible para la inserción de código, pero debido a limitaciones de tiempo, solo puedo comenzar este proyecto a partir de noviembre de la semana pasada o de diciembre, no modifico ningún código de motor o código de marco ni ningún código de Java como tinker lib, por lo que no viola cualquier término de la tienda, la aplicación de salida también es aot, por lo que no hay regresión de rendimiento, trato de que sea una implementación tan fácil para que cualquiera pueda agregar a su aplicación, según mi investigación sobre la base de código, el equipo de flutter se hace intencionalmente imposible para hacer que el código empuje i Probé todas las posibilidades con la implementación actual y concluí que las únicas formas posibles es hacer modificaciones al motor o preparar una solución sin modificar el motor, opté por la segunda opción y planifiqué todos los requisitos necesarios para el proyecto. Espero que el proyecto tenga éxito. Mientras tanto, si el equipo de flutter vuelve a evaluar el problema, todos estamos contentos con la implementación incorporada.

Había planeado la mejor manera posible para la inserción de código, pero debido a limitaciones de tiempo, solo puedo comenzar este proyecto a partir de noviembre de la semana pasada o de diciembre, no modifico ningún código de motor o código de marco ni ningún código de Java como tinker lib, por lo que no viola cualquier término de la tienda, la aplicación de salida también es aot, por lo que no hay regresión de rendimiento, trato de que sea una implementación tan fácil para que cualquiera pueda agregar a su aplicación, según mi investigación sobre la base de código, el equipo de flutter se hace intencionalmente imposible para hacer que el código empuje i Probé todas las posibilidades con la implementación actual y concluí que las únicas formas posibles es hacer modificaciones al motor o preparar una solución sin modificar el motor, opté por la segunda opción y planifiqué todos los requisitos necesarios para el proyecto. Espero que el proyecto tenga éxito. Mientras tanto, si el equipo de flutter vuelve a evaluar el problema, todos estamos contentos con la implementación incorporada.

Hola @canewsin
También intenté hacer lo mismo sin modificar el motor de aleteo. Descubrí que en el modo AOT, el motor busca los archivos .so en la ruta de la biblioteca nativa de Android, modificando / agregando un archivo allí después de que la compilación de la aplicación esté restringida por JVM. Por lo tanto, la carga de archivos .so descargados por aire no se pudo agregar a la ruta de la biblioteca nativa.

Esperando más información tuya. 😀

Creo que no es necesario actualizar tanto el código de dardos como el código nativo.
¡Solo el código de dardos está bien!

Oye, necesito esto ahora. Goodle ha estrictado su política de revisión. Nuestra aplicación tarda 2 semanas en actualizarse ahora ... Nuestra metodología lean se va a la mierda con esto.

@NEELANSHSETHI ¿puedes publicar el plan aquí? Podemos empezar a implementarlo

@almeynman Por favor, manténganos actualizados sobre su progreso :)

@HerrNiklasRaab No he comenzado con esto todavía, ya que no tengo una

Esa es la razón principal por la que no hemos migrado de react-native a flutter. :(

😔

ReactNative está muy por delante de Flutter debido a esta función y he tenido muchos proyectos en los que la elección del entorno (RN o Flutter) se decodificó en comparación con la función de código push. Esperando noticias: /

Hola a todos es noviembre ya como dije comencé mi trabajo va bien. Va a ser un proyecto privado, así que cobraré una clave de licencia para usarlo. Entonces no va a ser gratis, ya que no tengo ninguna fuente de ingresos, tengo que hacerlo de esta manera, si está interesado, crearé un repositorio de seguimiento sobre el trabajo, sígalo para actualizaciones. Una vez que haya creado el repositorio de la línea de tiempo, les informaré.

@eseidelGoogle
Caso de negocio:
Tenemos una aplicación de rastreo de autobuses en tabletas, pero el cliente actualiza 1 vez al mes porque la tableta usa datos de Internet no wifi.
Con Code Push, podremos actualizar sin consumir demasiado los datos del cliente.

Teníamos la aplicación cordova con soporte para código push. Cuando se trató de modernizar la aplicación por error, pensamos que flutter agregaría soporte de inserción de código "de todos modos", así que hemos desarrollado nuestra aplicación usando flutter. Pero la vida sin código push ha sido totalmente terrible durante el último año para nosotros. Así que finalmente (y felizmente) estamos en el proceso de (re) reescribir la aplicación en react-native para que nuestro código devuelva el soporte.

Code Push, por eso estoy aprendiendo React-Native ahora.

Si estás interesado en mi implementación
siga el informe de progreso aquí
https://github.com/canewsin/flutter-code-push-timeline
por favor lea todos mis comentarios antes de continuar.

Code Push, es por eso que seguiré con React-Native.

No publiques publicaciones no constructivas, +1, "Necesitamos esto", "Estamos usando X en su lugar", etc., ya que no es constructivo y no contribuye a la discusión.

Tendrá un impacto mucho mejor si hace clic en el botón Me gusta (👍) en la primera publicación, sin que todos los que hayan publicado en esta discusión sean notificados al respecto (hasta donde yo sé, algunos miembros del equipo de flutter se silenciarán hilos grandes, por lo que publicar aquí tiene menos efecto que un pulgar hacia arriba).

También quiero recordarles a todos los suscriptores aquí que github tiene un botón unsubscribe en la parte superior derecha del hilo.

Además, el equipo de Flutter prioriza los problemas en función de la cantidad de pulgares hacia arriba, por lo que obtener ese contador alto puede ser un gran problema. Eso y simplemente hacer clic en "suscribirse" es suficiente.

El proyecto de inserción de código que asumí va bien, pero quiero algunos ejemplos de los requisitos de inserción de código, por lo que si se completa la inserción de código, ¿cómo lo usa, publique su requisito único como un nuevo problema en este repositorio https://github.com/ canewsin / flutter-code-push-timeline para que el desarrollo esté en el camino correcto.
las limitaciones que encontré hasta ahora son:
no podemos acceder a la plataforma nativa, pero esto se puede hacer a través de la funcionalidad ffi.
El código codepush se ejecuta en una caja de arena por algunos problemas de seguridad, por lo que no se puede dañar el dispositivo.

Hola a todos es noviembre ya como dije comencé mi trabajo va bien. Va a ser un proyecto privado, así que cobraré una clave de licencia para usarlo. Entonces no va a ser gratis, ya que no tengo ninguna fuente de ingresos, tengo que hacerlo de esta manera, si está interesado, crearé un repositorio de seguimiento sobre el trabajo, sígalo para actualizaciones. Una vez que haya creado el repositorio de la línea de tiempo, les informaré.

¡Muy interesante!
Hola, ¿tienes algunos ejemplos todavía? ¿Y cómo manejas la sección de iOS? ya que Apple es muy estricto en esta área. Gracias

Hola a todos es noviembre ya como dije comencé mi trabajo va bien. Va a ser un proyecto privado, así que cobraré una clave de licencia para usarlo. Entonces no va a ser gratis, ya que no tengo ninguna fuente de ingresos, tengo que hacerlo de esta manera, si está interesado, crearé un repositorio de seguimiento sobre el trabajo, sígalo para actualizaciones. Una vez que haya creado el repositorio de la línea de tiempo, les informaré.

¡Muy interesante!
Hola, ¿tienes algunos ejemplos todavía? ¿Y cómo manejas la sección de iOS? ya que Apple es muy estricto en esta área. Gracias

Actualmente trabajando con el lado de Android, aunque el lado de ios es tonto, similar a la versión de espacio aislado de las aplicaciones js reactivas, el código se ejecutará en el espacio aislado sin acceder a las apis de la plataforma, por lo que puede que no sea el problema cuando esté listo para el lado de ios.

Hola @eseidelGoogle
¿Alguna actualización? ¿Línea de tiempo?

Hola @eseidelGoogle
¿Alguna actualización? ¿Es diciembre una característica que se lanzará en 2019?

Le pregunté a un tema de la AMA sobre este tema. Puede tener información útil.
https://www.reddit.com/r/FlutterDev/comments/d51o4w/were_the_flutter_team_at_google_ask_us_anything/f0ium5w?utm_source=share&utm_medium=web2x

@Hixie leí tu artículo en Reddit
https://www.reddit.com/r/FlutterDev/comments/d51o4w/were_the_flutter_team_at_google_ask_us_anything/f0ium5w/?utm_source=share&utm_medium=web2

Me pregunto si las actualizaciones de la aplicación Flutter serán de tamaño pequeño si las publico como abb "Android App Bundle" en Google Play o es solo para código nativo.

Esta es una característica importante para las compilaciones empresariales (aplicaciones que se distribuyen fuera de las tiendas, por ejemplo, a través de portales web).

Es una característica muy necesaria. ¿Por qué no podemos tenerlo oficialmente? ¿Qué le impide ofrecer esta función?

¿Es esto en la hoja de ruta de 2020?

No

2020 y sigo esperando

Lea esto antes de publicar a continuación.

Aquí hay un breve resumen si no desea desplazarse hacia arriba para comprender:

Como se señaló en este comentario , los tres grandes desafíos son:

• Lo que se empuja
• ¿Es seguro para los usuarios?
• Desde donde es empujado

El primero, _lo_ que se empuja, es donde radica el mayor problema. Las pautas de revisión de Apple no permiten ningún tipo de inserción de código . Sí, la terminología utilizada _también incluye código javascript push._ Apple aparentemente no ha tomado medidas en su contra, y puede haber muchas razones para ello, pero cualquier razón publicada aquí sería pura especulación.

Las propias pautas de Play Store de Google

Flutter, al menos en modo de lanzamiento, está compilado , e incluso si no lo fue, no es javascript , por lo tanto, no se puede interpretar en iOS sin romper el requisito "no JIT", o ser muy lento.

El segundo, si es _seguro_ para los usuarios, es prácticamente todo el fundamento detrás de la lógica de las tiendas para no permitir la descarga de código dinámico y no verificado. Permitir que cualquiera descargue cualquier cosa desde cualquier lugar y _sólo ejecutarlo_ pone a los usuarios en riesgo. Incluso dentro de una caja de arena, donde se destacan los privilegios especiales de JavascriptCore en torno a la inserción de código, todavía no es seguro.

La inserción de código le permite omitir el proceso de verificación de las tiendas, lo que significa que el código h sin verificar se ejecuta en los dispositivos de los usuarios, lo que significa que es posible tergiversar la aplicación original o incluso agregar características dañinas como el desvío de datos o exploits que el proceso de verificación lo habría atrapado .

Puedes tener las mejores intenciones del mundo, siempre habrá alguien que te apuñale por la espalda.

Por ahora, en Android, si no está utilizando Play Store para distribuir, puede simplemente crear un descargador que buscará un apk y le pedirá al usuario que lo instale. En iOS, bueno, efectivamente no puede descargar sin un montón de dolor, y los dispositivos JB no se preocupan por las restricciones de la tienda de aplicaciones.

Ahora bien, ¿es posible implementarlo para otras plataformas que no sean iOS o Android? ¡Seguro! Pero Desktop aún no está en Beta (además, también puede hacer su propio autoactualizador en el escritorio), y Web, bueno, simplemente actualice la página.

Ahora, si quieres que el equipo eche un vistazo, ve a la primera publicación y agrega un 👍.

Si tu comentario no cae en la siguiente lista, por favor, reconsiderar la publicación de la misma.

• Preguntar si está en la hoja de ruta
• "No está allí" (y variaciones, como el comentario anterior a este)
• "Estamos usando framework X porque no hay código push"
• "Framework X es mejor porque empuja el código"
• "Necesitamos empujar el código"
• "¿Actualizaciones?"
• Argumentos para la inserción de código que son
  
  
  
  • Aplicaciones empresariales / de carga lateral
  
  
  • Parches de emergencia
  
  
  • Añadiendo características
  
  
• Argumentos en contra de la inserción de código que son
  
  
  
  • Las duraciones de las reseñas de Play / App Store son más cortas ahora
  
  
  • La tienda de juegos / aplicaciones para pájaros
  
  
  • No lo necesitas
  
  

Este problema ya está cargada con suficientes comentarios como es, así que por favor no agregue comentarios que no aportan nada a la conversación. Si el equipo tiene algo que decir, lo publicarán aquí, ya que esta publicación tiene casi 100 participantes en este momento y más de 500 pulgares, no es posible ignorarla.

Para ser honesto, no creo que esto deba ser tu preocupación. Un desarrollador utilizará la función bajo su propio riesgo. Si Apple decide repentinamente prohibir todas las aplicaciones usando código push, entonces su aplicación tendrá que usar un enfoque diferente. Pero esto no está sucediendo con JavaScript. No sucedió durante años, ¿por qué debería sucederle a Flutter? Ni siquiera pueden comprobarlo. La gente solicita esta función porque es útil. Puede escribir pequeños módulos y actualizarlos dinámicamente. Es un cambio de juego. Puede corregir un error en un módulo sobre la marcha. Además, Apple realmente no puede verificar lo que está haciendo una aplicación, no tiene los recursos. Sería imposible, espero que te des cuenta. Además, ¿cuál es el punto? Puedo escribir código oscuro e insertar una puerta trasera en una aplicación, que se activa cuando proporciono un JSON específico como resultado de una llamada REST. ¿Cómo podrá Apple verificarlo? No puede. No hay nada que Apple o Android puedan hacer para detener eso. La gente necesita esta función y usted debería implementarla. Lo que hacemos con él, es asunto nuestro, no tuyo. Usted mismo dijo que esta función tiene más de 500 pulgares hacia arriba y más de 100 participantes. Tal vez sea hora de implementarlo según la solicitud de la comunidad.

@dedalozzo ¡ Grandes argumentos frescos!

No soy parte del equipo de flutter, así que no me dirijan a mí para solicitar implementaciones.

Aún así, es cierto que Apple y Google podrían no tener los recursos para detectar eso (el equipo de protección de juego está activo todo el tiempo, pueden detectar comportamientos peligrosos automáticamente), pero implementarlo "a sus espaldas" ahora le da a Apple una razón real. para aplicar una prohibición total a Flutter, ya que básicamente _ viene con_ herramientas que van explícitamente en contra de sus políticas.

También puede enmarcarlo como parte de una pregunta ética (¿Debería implementar algo que agregue riesgos adicionales a una aplicación y vaya en contra de las políticas de la tienda, en nombre del progreso?) O como una pregunta de programación (¿Debería trabajar en algo que tiene una cláusula masiva de " Si usas esto, es probable que te expulsen de la aplicación / Play Store ", que los usuarios probablemente querrán evitar y desviar recursos de otras tareas con un impacto seguro y garantizado).

No solo eso, sino que violar accidentalmente la política de Play Store / estar relacionado con alguien que infringe la política de Play Store básicamente significa que su cuenta sea baneada, por lo que sería jugar con fuego, haciendo que los usuarios _aún menos probabilidades de usar la función_.

Además, como se indicó anteriormente, la distribución fuera de Play Store te permite enviar APK actualizados.

Lo siento, pensé que eras uno del equipo de Flutter.

Lo que dices en tu último comentario es cierto. De hecho, Apple y Google parecen tolerar la inserción de código, incluso está en el límite y contra las reglas.

Pero mientras su aplicación no cause ningún daño, no creo que se molesten en verificar si realmente está presionando el código. Podrían hacerlo, si alguien informa un comportamiento extraño. Pero en ese momento, tomarán medidas contra el desarrollador de esa aplicación, no contra todas las aplicaciones que usan código push.

Es un trabajo en progreso, pero permite la inserción de código https://github.com/chgibb/hydro-sdk

@chgibb Espera ... ¿eso permite la inserción de código pero también cambia todo de Dart a Typecript?

¿Hay alguna forma de separar esas dos cosas? ¿Obtener codepush mientras escribes Dart como de costumbre?

@SpajicM eso solo funciona _porque_ no está usando Dart, en su lugar, probablemente usa un motor JS, como JavascriptCore, que es propiedad de Apple, y parecen mirar para otro lado cuando se usa con código push.

Olvídese de eso, utiliza el código de bytes Lua, que va en contra de la política de la tienda en todos los sentidos.

@miyoyo, ¿por
@SpajicM es puramente aditivo. Las piezas mecanografiadas se pueden incrustar en una aplicación Dart más grande. Tan pequeños como fragmentos individuales de texto o pantallas enteras.

La política de la tienda prohíbe insertar cualquier tipo de código compilado, de los cuales parecen ser archivos .hc , ya que están compilados con código de bytes lua (tal vez con extensiones, no lo he verificado).

El caso de uso específico de enviar código _compilado_ a las aplicaciones está explícitamente en contra de la política de Play Store , y el elemento "no se proporciona código fuente" que _podría_ pasar javascript como, en CodePush, no se aplicaría, incumpliendo las pautas de Apple .

No estoy diciendo que el concepto sea malo, de hecho, ¡es un gran trabajo! Es solo que descargar el código de bytes a través de Internet va explícitamente en contra de la política de la tienda en ambos casos.

¿Cómo funcionan todos estos juegos móviles con sus actualizaciones en el juego? ¿Solo envían / ​​descargan activos?

@miyoyo de la https://play.google.com/about/privacy-security-deception/malicious-behavior/
...This restriction does not apply to code that runs in a virtual machine and has limited access to Android APIs...
Los archivos .hc Hydro-SDK son códigos de bytes Lua 5.2 puros sin extensiones ni características especiales. Se ejecutan en un intérprete sin funcionalidad para la autmutación o la generación de código. Nada de dart:io está expuesto a ellos. Sin embargo, no hay nada que impida que un incrustador exponga la clase dart:io de File , o exponga PlatformChannel s, por ejemplo.

La sección 2.5.2 de Apple es un poco más ambigua con respecto al significado de la palabra "ejecutar", así como en cuanto al cambio de características o funcionalidad.

https://developer.apple.com/app-store/review/guidelines/#2.5.2

...
2.5.2 Apps should be self-contained in their bundles, and may not read or write data outside the designated container area, nor may they download, install, or execute code which introduces or changes features or functionality of the app, 
...

@chgibb De acuerdo, diría que eso podría pasar a Android, aunque aún espero un rechazo en la App Store. (Por no decir la reducción en el rendimiento máximo, pero ese es probablemente un detalle en los teléfonos de gama alta)

Las actualizaciones de juegos de @kuhnroyal Mobile usan Dynamic Asset Delivery para cosas no ejecutables , estos generalmente son de seguimiento rápido porque requieren menos verificación, APK Expansion Files que le permite realizar actualizaciones parciales, pero aún están sujetos a ciclos regulares de actualización de la tienda y actualizaciones regulares de APK .

Hablé con el cliente: titular que esto ya no es una prioridad para ellos.

Puede utilizar Localizely para actualizaciones inalámbricas de textos / traducciones: https://localizely.com/flutter-over-the-air

Por el amor de los demás, cree esta función o guíenos sobre cómo hacerlo. gracias .

Amigos, por favor, es la tercera vez que se publica esto, pero no envíen comentarios a menos que tengan algo que agregar .

Consulte esta publicación para obtener más detalles y para aprobar la primera publicación.

Los mensajes no tienen más impacto, ya que estoy bastante seguro de que la mayoría del equipo aquí ha desactivado las notificaciones para esta publicación, mantengamos el ruido bajo _ a menos que tengas algo que agregar_.

mientras tanto, ¿alguna alternativa para la inserción de código?

mientras tanto, ¿alguna alternativa para la inserción de código?

Basado en mi experiencia, no hay alternativa.

@samerdernaika @mfenej aunque no estaba del todo listo para la producción, este proyecto se inició con la inserción de código como un objetivo explícito https://github.com/chgibb/hydro-sdk

@miyoyo

El primero, _lo_ que se empuja, es donde radica el mayor problema. Las pautas de revisión de Apple no permiten ningún tipo de inserción de código . Sí, la terminología utilizada _también incluye la inserción de código javascript. Apple aparentemente no ha tomado medidas en su contra, y puede haber muchas razones para eso, pero cualquier razón publicada aquí sería pura especulación.

Eso no es cierto. Por favor, verifique dos veces y no difunda información errónea.

La sección 3.3.2 del acuerdo de licencia para desarrolladores de Apple establece:

3.3.2 Salvo lo establecido en el siguiente párrafo, una Aplicación no puede descargar ni instalar código ejecutable. El código interpretado se puede descargar a una Aplicación, pero solo siempre que dicho código: (a) no cambie el propósito principal de la Aplicación al proporcionar características o funcionalidades que sean inconsistentes con el propósito previsto y anunciado de la Aplicación tal como se envió a la Aplicación. Store, (b) no crea una tienda o escaparate para otro código o aplicaciones, y (c) no omite la firma, la zona de pruebas u otras características de seguridad del sistema operativo.

Ellos interpretaron muy específicamente permiso de código como JS para ser descargado, siempre y cuando no cambie el propósito principal de la aplicación. Ha sido así durante más de 5 años, IIRC y nunca escuché de nadie que haya sido detenido por usar codepush de una manera normal y responsable.

Eche un vistazo a la sección de AppCenter sobre codepush y cumplimiento de las pautas de la tienda. AppCenter codepush (respaldado por Microsoft) es utilizado por muchas aplicaciones sin problemas de cumplimiento de la tienda. https://github.com/microsoft/react-native-code-push#store -guideline-compliance

El gran bloqueador de codepush que veo es que puede que no valga la pena la compensación de rendimiento de verse obligado a usar compilar a js o interpretar Dart en iOS en lugar de precompilarlo. Dado que Flutter está apuntando al navegador, sin embargo, sospecho que compilar en js perf sería lo suficientemente bueno, pero tal vez aún no sea una compensación de rendimiento aceptable para el equipo de Flutter.

Quizás aparezca una solución de terceros (como AppCenter para React Native) y llene este vacío. ¡CodePush es muy útil!

Hmm, una búsqueda rápida en Google revela muchos ejemplos de aplicaciones de rechazo de Apple que incluyen la capacidad de inserción de código, consulte, por ejemplo,

https://github.com/microsoft/react-native-code-push/issues/1297

Dado que los tiempos de revisión de la App Store ahora casi siempre se miden en horas y no en días, no entiendo por qué alguien se arriesgaría. Si la inserción de código está integrada en el motor Flutter, Apple podría decidir prohibir todas las aplicaciones de Flutter.

@matthewlloyd , tienes toda la razón en que los tiempos de revisión han bajado. ¡Yo mismo envié una aplicación (propietaria) a la App Store esta mañana y la aprobé al final del día de hoy! Pero eso es _recientemente_. Nosotros, como editores de aplicaciones móviles, todavía estamos en deuda con los caprichos / capacidad de los equipos de revisión para revisar nuestras presentaciones.

Una actualización que llega a las manos de su usuario no viaja a la velocidad de la revisión de la aplicación. El tiempo entre el "lanzamiento del desarrollador", el "procesamiento de la tienda de aplicaciones", la propagación a los servidores del mercado de usuarios, etc. también puede llevar bastante tiempo. He visto que estas últimas etapas demoran más de 24 horas en casos extremos.

Hablando personalmente, mi pasión por el empuje de código es tomar posesión de la cadena de suministro de entrega de actualizaciones tal como está. Sin mencionar los obstáculos bastante grandes que implica intentar automatizar el proceso actual en una configuración de CD coherente, dado el lamentable estado de las herramientas xcode CLI.

Creo que menos de 24 horas en la gran mayoría de los casos es suficiente para casi todo el mundo. Si necesita obtener una actualización a través del proceso de revisión de Apple más rápido que eso, por ejemplo, para una corrección de error urgente, puede solicitar una revisión acelerada. Lo hice en una ocasión, y la revisión de la aplicación se completó literalmente 10 minutos después de que hice la solicitud.

Tomar posesión de la cadena de suministro de entrega es algo que uno hace bajo su propio riesgo ...

Directrices de la App Store de Apple, sección 2.5.2 (https://developer.apple.com/app-store/review/guidelines/#software-requirements):

"2.5.2 Las aplicaciones deben ser independientes en sus paquetes y no pueden leer ni escribir datos fuera del área de contenedor designada, ni pueden descargar, instalar o ejecutar código que introduzca o cambie características o funcionalidad de la aplicación , incluidas otras aplicaciones. Las aplicaciones educativas diseñadas para enseñar, desarrollar o permitir que los estudiantes prueben el código ejecutable pueden, en circunstancias limitadas, descargar código siempre que dicho código no se utilice para otros fines. Dichas aplicaciones deben hacer que el código fuente proporcionado por la Aplicación sea completamente visible y editable por el usuario ".

Requisitos del programa para desarrolladores de Apple, sección 3.3.2:

3.3.2 Excepto como se establece en el siguiente párrafo, una Aplicación no puede descargar ni instalar código ejecutable.

@AndrewMorsillo No importa lo que haya en cada directriz y no importa cuánta información se presente, lo mejor que podemos encontrar es "Tal vez esté permitido, no estamos seguros de que no sea una ofensa bannable, en realidad puede ser que no estemos seguros". .

Cualquiera que sea el caso, Flutter no ejecuta ningún dardo interpretado en iOS en este momento, agregarlo sería un obstáculo para el rendimiento, y como usted mismo ha mencionado, además de mis publicaciones anteriores y la publicación de @matthewlloyd , apenas está en el mejor de los casos. permitido en algunos casos, en general es un área muy muy gris y, en el peor de los casos, simplemente está prohibido.

Por lo que puedo decir, no vale la pena cambiar todo eso por omitir un ciclo de revisión de 24 horas y escribir pruebas. (Podría entender cuándo fue una semana, y eso suele ser solo del lado de iOS, que es efectivamente el mayor punto de discusión aquí)

Ni siquiera se trata solo del proceso de revisión, también se trata de usuarios que se atascan en versiones antiguas de la aplicación porque pueden haber desactivado la actualización automática.

Claro, puede implementar la verificación mínima de la versión usted mismo, pero luego nuevamente deben pasar por Play Store y, lamentablemente, la gente es vaga. Con la inserción de código, podría actualizar rápidamente la aplicación en cada ejecución (espero) y permitir que el usuario ingrese sin problemas.

@miyoyo No sé por qué sientes la necesidad de responder a cada comentario o idea que se presenta aquí. La gente quiere esto. Ustedes le dijeron a la gente que votara a favor del problema y nosotros lo votamos hasta la cima. Esto nunca se resolverá a menos que alguien lo piense activamente y lo presione.

Hay otra forma de solucionar esto. Había visto muchas aplicaciones hacerlo. Aplicación si está disponible
de la fecha, aparece un mensaje, ya sea que lo cierre o actualice la aplicación. que todos.

El viernes 7 de agosto de 2020 a las 07:38, SpajicM [email protected] escribió:

Ni siquiera se trata solo del proceso de revisión, también se trata de los usuarios que obtienen
atascado en versiones antiguas de la aplicación porque es posible que hayan apagado el
actualización automática.

Claro, puede implementar la versión mínima verifique usted mismo, pero luego
De nuevo tengo que pasar por Play Store y, lamentablemente, la gente es vaga. Con
push de código, podría actualizar rápidamente la aplicación en cada ejecución (espero) y
Permitir al usuario entrar sin problemas.

@miyoyo https://github.com/miyoyo No sé por qué estás sintiendo la
necesidad de responder a cada comentario o idea que se presente aquí.
La gente quiere esto. Le dijiste a la gente que votara a favor del problema y nosotros votamos a favor
todo el camino hasta la cima. Esto nunca se resolverá a menos que alguien
piensa activamente en ello y lo empuja.

-
Estás recibiendo esto porque estás suscrito a este hilo.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/flutter/flutter/issues/14330#issuecomment-670242698 ,
o darse de baja
https://github.com/notifications/unsubscribe-auth/ADS5AJFUU2V6MHQIP7AMZKLR7M5HPANCNFSM4EOFIZRA
.

Hay otra forma de solucionar esto. Había visto muchas aplicaciones hacerlo. La aplicación si está desactualizada, aparece un mensaje emergente, ya sea que la cierre o actualice la aplicación. que todos.

Probablemente la peor forma de UX ...: /

@SpajicM

Ni siquiera se trata solo del proceso de revisión, también se trata de usuarios que se atascan en versiones antiguas de la aplicación porque pueden haber desactivado la actualización automática.

Claro, puede implementar la verificación mínima de la versión usted mismo, pero luego nuevamente deben pasar por Play Store y, lamentablemente, la gente es vaga. Con la inserción de código, podría actualizar rápidamente la aplicación en cada ejecución (espero) y permitir que el usuario ingrese sin problemas.

En cuanto a UX, ¿no es esta una mala forma de manejar las actualizaciones? Si alguien deshabilita manualmente las actualizaciones automáticas, ¿por qué Flutter debería anular eso? Es discutible si alguna aplicación debería tener ese poder, pero ciertamente no todo el marco.

Creo que centralizar el proceso de actualización a través de las tiendas de aplicaciones es mejor para UX, ya que pueden administrar todas las actualizaciones a través de la tienda. UX a expensas del tiempo del desarrollador es algo así como la esencia del desarrollo de aplicaciones. Y si necesita una solución inmediata (por ejemplo, para una vulnerabilidad), puede obtener una actualización acelerada o negarse a permitir que el usuario use la aplicación hasta que se actualice. Por supuesto, esta última no es una gran opción, y la primera es molesta, pero eso se debe a que Apple y Google están poniendo a los usuarios primero y tiene poco que ver con Flutter en sí.

@chgibb

Hablando personalmente, mi pasión por el empuje de código es tomar posesión de la cadena de suministro de entrega de actualizaciones tal como está.

Este es el problema con este hilo: tratar de hacer lo que Apple y Google advierten enérgicamente no es una buena idea si va a utilizar sus tiendas de aplicaciones. Como dijo @miyoyo , es un área gris en el mejor de los casos, que no se ajusta exactamente a un marco utilizado por Google y otras empresas / personas.

Finalmente https://github.com/flutter/code-push

Realmente es https://github.com/microsoft/react-native-code-push

Bueno, Flutter todavía no puede actualizar tu código, pero en realidad ese enlace hablaba de imágenes y me recordó que Firebase Remote Config es una cosa. El inconveniente es que debe adelantarse a los bits de código que podrían necesitar cambios y esperar esos cambios en su aplicación, pero una vez hecho esto, debería ser bastante rápido implementar nuevos cambios sin la tienda de aplicaciones (similar a lo que hace React Native Code Push con sus imágenes)

@ardyfeb Las personas como tú le dan a la comunidad de

Hay otra forma de resolver eso
sin usar aleteo web

Hay otra forma de solucionar esto. Había visto muchas aplicaciones hacerlo. La aplicación si está desactualizada, aparece un mensaje emergente, ya sea que la cierre o actualice la aplicación. que todos.
...
El viernes 7 de agosto de 2020 a las 07:38, SpajicM @ . * > escribió: No se trata solo del proceso de revisión, también se trata de usuarios que se quedan atascados en versiones antiguas de la aplicación porque podrían haber desactivado la actualización automática. Claro, puede implementar la verificación mínima de la versión usted mismo, pero luego nuevamente deben pasar por Play Store y, lamentablemente, la gente es vaga. Con la inserción de código, podría actualizar rápidamente la aplicación en cada ejecución (espero) y permitir que el usuario ingrese sin problemas. @miyoyo https://github.com/miyoyo No sé por qué sientes la necesidad de responder a cada comentario o idea que se presenta aquí. La gente quiere esto. Ustedes le dijeron a la gente que votara a favor del problema y nosotros lo votamos hasta la cima. Esto nunca se resolverá a menos que alguien lo piense activamente y lo presione. - Estás recibiendo esto porque estás suscrito a este hilo. Responda a este correo electrónico directamente, véalo en GitHub < https://github.com/notifications/unsubscribe-auth/ADS5AJFUU2V6MHQIP7AMZKLR7M5HPANCNFSM4EOFIZRA .

Eso suena genial ... si está creando aplicaciones bancarias.

Si alguien necesita actualizaciones inalámbricas solo para las traducciones de la aplicación, aquí hay una aplicación de Flutter de muestra: https://github.com/localizely/flutter-ota-sample-app

¿Parece que las pautas de Apple son diferentes de lo que solían ser?

Esto sigue siendo el mismo

2.5.2 Las aplicaciones deben ser independientes en sus paquetes y no pueden leer ni escribir datos fuera del área de contenedor designada, ni pueden descargar, instalar o ejecutar código que introduzca o cambie características o funcionalidad de la aplicación, incluidas otras aplicaciones. . Las aplicaciones educativas diseñadas para enseñar, desarrollar o permitir que los estudiantes prueben el código ejecutable pueden, en circunstancias limitadas, descargar código siempre que dicho código no se utilice para otros fines. Dichas aplicaciones deben hacer que el código fuente proporcionado por la Aplicación sea completamente visible y editable por el usuario.

Sin embargo, no puedo encontrar ninguna otra referencia al código interpretado o ejecutable.

¿Es posible que los detalles sobre el ecosistema de Apple de la publicación original ya no sean ciertos dado que ya no parecen decir nada específicamente sobre lenguajes interpretados o compilados?