Flutter: Code Push / Hot Update / atualizações fora de banda

cc @floitschG

Veja também
https://groups.google.com/forum/#!msg/flutter -dev / YwzItp1pxJo / 7bFGDLvxBAAJ
Eu ficaria extremamente animado com isso.

Eu acho que isso seria bastante importante porque pode ser uma das únicas características verdadeiramente distintivas do react nativo e, infelizmente, algumas empresas podem considerá-lo um obstáculo.

Casos de uso

• bugs críticos, especialmente no iOS, especialmente para VIPs ou situações urgentes, urgentes, críticas para os negócios e / ou usuários que não podem usar o aplicativo por algum motivo.
• Mais testes dinâmicos de recursos do que lançamentos graduais
• isso seria um belo toque de preparação para Fuschia e / ou Chromebooks. pode haver cenários em que o flutter está "competindo" com aplicativos da web, não apenas com soluções pwas / Kotlin / Swift / React / Xamarin / outro-junkier-híbrido

Na batalha épica que é Flutter vs React Native, o push de código é uma ferramenta incrível (:
Como um RN dev, não posso enfatizar o suficiente a importância desse recurso. Muitos vão passar Flutter só porque a ausência de impulsos quentes. Depois de se acostumar a consertar bugs rapidamente e lançar novos recursos, você não pode voltar atrás.

compilar para o caminho do javascript diminuirá as vantagens do dardo, certo?
Eu encontrei um aplicativo nativo que costumava ser capaz de recarregar o código usando Rollout.io, mas foi bloqueado pela Apple: https://news.ycombinator.com/item?id=13817557
olhando para esse padrão, parece que o flutter não terá um recurso de push de código contínuo, como o que vemos no react native.
adoraria obter mais informações sobre as possibilidades de recursos dos principais mantenedores (:

compilar para o caminho do javascript diminuirá as vantagens do dardo, certo?

De que vantagens você está falando?

Codepush é muito necessário. Adoro ver a possibilidade de atualização over-the-air no Flutter.

acabamos de ter um caso de uso ativo com um aplicativo de produção em que recebíamos muitas críticas negativas para um recurso que parecia um pouco extremo (relacionado à negação da permissão de localização em um caso de uso que nem todas as contas de teste tinham), mas na verdade não era. t.

um recurso codepush pode enviar correções críticas para os usuários imediatamente, em vez de esperar que eles atualizem; por algum motivo, parece que os usuários às vezes demoram a atualizar :(

Nenhum suporte de push de código quente é um NO GO :-(

Parece que o JavascriptCore não é mais necessário para o código interpretado: https://www.theregister.co.uk/2017/06/07/apple_relaxes_developer_rules/?page=2

Se o ecossistema IOS é um obstáculo, por que não implementar no Android apenas por enquanto? Algo melhor do que nada e é um ponto de partida.

Muito apreciado pela equipe para implementar este recurso o mais rápido possível.

Construímos alguns protótipos básicos aqui, mas não temos nada realmente para compartilhar no momento. Para fazer isso realmente bem, será necessário algum trabalho na cadeia de ferramentas do compilador do Dart. Eu esperaria muitos meses antes de termos muito a compartilhar aqui. A equipe está atualmente focada na estabilização para 1.0.

Tudo isso dito, nós ouvimos você. :) Este é claramente um recurso que muitas pessoas valorizam e estamos interessados ​​em fornecer funcionalidades como esta eventualmente.

O suporte "Code Push" para Flutter pode ser o último prego no caixão em relação ao React Native.

Com todo o meu amor pelo RN e pela comunidade RN, sendo um divisor de águas, não é páreo para o Flutter.
O Flutter acerta em qualquer aspecto (ferramentas, desempenho, linguagem ...).

Após o 1.0 atingir e a comunidade crescer um pouco mais + Suporte a Code Push = Não vejo razão para iniciar um novo projeto móvel com algo diferente do Flutter.

algum progresso em "Code Push" ??

Quão viável seria ter um .assim substituído dinamicamente? Todo o conjunto de ferramentas do compilador, código agitado, etc., não deve ser direcionado para um caso indiscutivelmente extremo do qual as pessoas podem ou não se beneficiar, visto que sempre haverá tickets no topo da lista de prioridades.

Acho que deve haver espaço para "sideload" de todo o arquivo .so, de modo que a compilação do dardo para o código de máquina ainda possa ser exatamente a mesma. Um componente pequeno, mas completamente independente, pode receber os seguintes "recursos mínimos viáveis": baixe .so e substitua o componente originalmente enviado com ele e reinicie o aplicativo com a intenção de inicialização principal.

Responsabilidades extras: baixar recursos, verificar assinaturas e tudo o mais. Atualize os motores de vibração / dardo / skia e quais não.

Parece-me que isso viola as diretrizes do iOS, mas eu realmente não sou fã de nada interpretado de qualquer maneira, ou do iOS em geral. E eu prefiro ter no Android do que não ter de jeito nenhum, só porque é legal.

Pelo menos a parte de download parece factível agora que temos algum trabalho isolado sendo permitido em segundo plano, mas seria interessante ver como trocar o .so original pelo baixado. Talvez um código extra .so ou java pudesse fazer essa parte, mas ficará na pasta de código, não tenho certeza se o próprio aplicativo pode modificá-lo, então provavelmente seriam necessários alguns ajustes para que o mecanismo de vibração carregue todos os aplicativos .so de interno dados?

Começando a renovar meu aplicativo de empresas usando flutter. No entanto, nossa principal demanda é ter um recurso de atualização dinâmica, já que ainda estamos em beta e continuamos testando novas interfaces de usuário e recursos rapidamente. Iria viver para ter esse recurso.

Alguma atualização?
(Aposto que o recurso já está pronto e virá como uma surpresa quando 1.0 chegar)
😁

voto positivo

Há apenas um motivo para nos impedir de usar o Flutter: push de código

Se vocês não podem suportar Code Push, existe uma maneira de fazer um Parser para gerar a partir de alguns dicionários (como json, xml ...) para Flutter Widget? Isso é impossível ou uma boa ideia?

Isso parece um pouco promissor. Configuração remota do Firebase para widget, se necessário.
Embora fazer com que as empresas tenham uma ideia do que desejam também ajude :)

Na sexta-feira, 12 de outubro de 2018, 03h45 Hưng Lương Đỗ Minh [email protected]
escreveu:

Se vocês não podem suportar Code Push, há uma maneira de fazer um Parser para
gerar de alguns dicionários (como json, xml ...) para Flutter Widget? É
isso é impossível ou uma boa ideia?

-
Você está recebendo isto porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/flutter/flutter/issues/14330#issuecomment-429251785 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AC4TYe9qDMi4bt2U5qyyAnJisN3ys_Z5ks5ukFavgaJpZM4RxUZi
.

Acho que pelo menos a UI / View escrita em Dart pode ser baixada através da rede do servidor.
Para se inspirar, veja como o Qt Quick framework está fazendo isso.

QtDD12 - Servindo aplicativos QML na rede - Jeremy Laine:

• Vídeo
• Slides

espere que ele possa ser incluído na próxima versão 1.0!

Muitos de nossos clientes usarão nosso aplicativo Flutter em um dispositivo de quiosque protegido por firewalls rígidos que impediriam os mecanismos de atualização de aplicativos da Google Store. Esses clientes não colocarão a Play Store na lista de permissões. No final das contas, teremos centenas de dispositivos de hardware com o aplicativo Flutter, e seria incrível ter uma maneira de enviar atualizações para o aplicativo ao mesmo tempo que aderimos às restrições de firewall do cliente!

@eseidelGoogle - já faz um tempo que vocês forneceram algumas atualizações aqui.

Vocês ainda estão trabalhando nisso? Como vão as coisas?

O progresso continua. Nenhuma atualização para compartilhar no momento.

Chegamos a três termos claros para o que as pessoas têm considerado esse bug hoje:

• "Patching dinâmico": a capacidade de atualizar o código Dart de um aplicativo em campo, baixando um patch (de tipos) e fornecendo-o à VM Dart. Isso exigiria uma recarga do aplicativo para ter efeito.
• "Carregamento de extensão dinâmica": a capacidade de baixar algum código Dart que não foi escrito quando o aplicativo foi publicado pela primeira vez, o que adiciona um novo recurso ao aplicativo. Isso pode ser feito na hora. Pode exigir que o aplicativo principal seja maior, pois não podemos saber com antecedência o que é necessário para cada extensão futura.
• "Entrega de aplicativo modular": a capacidade de empacotar um único aplicativo em vários arquivos separados ao compilá-lo e baixá-los independentemente, conforme necessário.

Provavelmente devemos dividir esse problema em três bugs que podemos rastrear separadamente.

Isso é realmente viável para iOS? Além da possibilidade de a Apple banir isso, assim como fez com rollout.io , o javascript teria que ser executado sem qualquer tipo de JIT (sem gravação em páginas executáveis ​​no iOS). Além disso, as diferentes características de GC do núcleo Javascript enquanto o Flutter cria toneladas de objetos de curta duração podem não ser um bom presságio.

O que a Apple permite / não permite atualmente (ou no futuro) é totalmente separado das implementações técnicas. O Flutter é executado em muitos lugares além do iOS. Obviamente, gostaríamos de sempre projetar tecnologias que possam funcionar no iOS (como acredito que muitas soluções de "push de código" possíveis), mas o iOS não é a única consideração. Espero que ajude?

É muito triste não ver o Code Push lançado na versão 1.0. Como outros, este é o principal motivo pelo qual não posso usá-lo em projetos que requerem a capacidade de corrigir sem esperar pelas lojas de aplicativos.
Agradeço que seja um trabalho pesado chegar lá, boa sorte.

Há apenas um motivo para nos impedir de usar o Flutter: push de código

Gostaria de deixar meu feedback apenas para mostrar meu interesse neste tópico.
Minha empresa desenvolve um aplicativo multi-cliente somente para Android para gerenciar equipes de manutenção. Em 2018, lançamos cerca de 100 atualizações, nenhuma das quais solicitou uma nova versão por meio do Google Play, pois a maioria delas são pequenos ajustes e personalizações que cada cliente exige, que são imprevisíveis de antemão.
Reescrever este aplicativo no Flutter seria um sonho, mas tirando os custos de reescrita, desperdiçar dinheiro para esperar por uma correção ou personalizações a serem publicadas através do GPlay seria um pesadelo.

Espero conseguir o mais rápido possível

Outro ponto: se a equipe do Flutter fornecer a solução hot-fix oficialmente, acho que a Apple pode rejeitar todos os aplicativos desenvolvidos pelo Flutter em algum momento, porque o hot-fix quebra a Diretriz de revisão da AppStore definitivamente, os desenvolvedores podem ignorar a revisão da AppStore e modificar seus aplicativo, não é seguro para os usuários.

Atualmente, a Apple rejeita todos os aplicativos com JsPatch, que era a solução hot fix mais popular na China. JsPatch é construído em cima do tempo de execução JsCore e OC.

Eu gostaria de construir Apps Flutter sem a função de hot-fix, em vez de Apps rejeitados pela Apple no futuro.

@MaxZeng Bom saber sobre o JsPatch. Mas, por enquanto, parece que o hot patching é permitido. Existem muitos aplicativos React Native na loja da Apple e todos eles usam hot patching via CodePush.

Se houver suporte apenas para iOS / Android, como este exemplo:
MyFlutterApplication pede permissão / deseja atualizar seu aplicativo
Changelogs: adicionar gatinhos e cachorros (v1.0)
Permitir | Não permitir

após revisar as diretrizes para ambas as partes.

@MaxZeng Bom saber sobre o JsPatch. Mas, por enquanto, parece que o hot patching é permitido. Existem muitos aplicativos React Native na loja da Apple e todos eles usam hot patching via CodePush.

Sim, o ReactNative é uma exceção ao push de código por enquanto, mas não significa que a Apple o suporte oficialmente. O App da nossa empresa foi rejeitado pela AppStore mais de 3 vezes recentemente devido ao framework RN like, e temos que reescrever essas funções por OC / H5, é um pesadelo para os desenvolvedores.

React Native ainda é uma estrutura SAFE para a Apple, porque finalmente é renderizado em cima do UIKit, mas Flutter é completamente diferente:
1 、 Em primeiro lugar, ele quebra os ecossistemas de desenvolvedor da Apple, ignora a estrutura UIKit e está FORA do controle da Apple, por exemplo, haverá mais e mais aplicativos estilo MD na AppStore, e isso pode ser contra a Diretriz de Interface Humana da Apple. A Apple é uma empresa famosa por seu excelente design.
2 、 Em segundo lugar, se o hot-reload for suportado oficialmente pelo Flutter, a Apple pode usar esse motivo para rejeitar os aplicativos Flutter diretamente.

Do meu ponto de vista, o Flutter deve seguir a Diretriz de revisão da AppStore em vez de quebrá-la, isso é importante para uma estrutura móvel de plataforma cruzada, você não deve quebrar o ecossistema da Apple porque nós podemos fazer isso. Se a Apple rejeitar o Flutter, a principal vantagem do Flutter desaparecerá.

O CodePush não é uma técnica difícil ou misteriosa, a Apple pode implementá-lo facilmente (especialmente com base em OC), a única razão pela qual a Apple o desaprova é que ele não é seguro para os usuários finais, e isso danifica completamente a AppStore / Google Play. É um desastre se muitos aplicativos podem alterar sua funcionalidade a qualquer hora e em qualquer lugar, e é difícil rastrear e limitar essas ações prejudiciais após o aplicativo ter permissão para publicar.

CodePush não é apenas uma técnica, é uma parte importante dos ecossistemas móveis. Acho que a equipe do Flutter não deve fornecer tal técnica oficialmente, embora possa ser implementada por alguns desenvolvedores de forma privada, isso está OK porque não será usado descontroladamente.

@MaxZeng Bom saber sobre o JsPatch. Mas, por enquanto, parece que o hot patching é permitido. Existem muitos aplicativos React Native na loja da Apple e todos eles usam hot patching via CodePush.

Sim, o ReactNative é uma exceção ao push de código por enquanto, mas não significa que a Apple o suporte oficialmente. O App da nossa empresa foi rejeitado pela AppStore mais de 3 vezes recentemente devido ao framework RN like, e temos que reescrever essas funções por OC / H5, é um pesadelo para os desenvolvedores.

React Native ainda é uma estrutura _SAFE_ para a Apple, porque é renderizado no topo do UIKit, finalmente, mas Flutter é completamente diferente:
1 、 Em primeiro lugar, ele quebra os ecossistemas de desenvolvedor da Apple, ignora a estrutura UIKit e está FORA do controle da Apple, por exemplo, haverá mais e mais aplicativos estilo MD na AppStore, e isso pode ser contra a Diretriz de Interface Humana da Apple. A Apple é uma empresa famosa por seu excelente design.
2 、 Em segundo lugar, se o hot-reload for suportado oficialmente pelo Flutter, a Apple pode usar esse motivo para rejeitar os aplicativos Flutter diretamente.

Do meu ponto de vista, o Flutter deve seguir a Diretriz de revisão da AppStore em vez de quebrá-la, isso é importante para uma estrutura móvel de plataforma cruzada, você não deve quebrar o ecossistema da Apple porque nós podemos fazer isso. Se a Apple rejeitar o Flutter, a principal vantagem do Flutter desaparecerá.

O CodePush não é uma técnica difícil ou misteriosa, a Apple pode implementá-lo facilmente (especialmente com base em OC), a única razão pela qual a Apple o desaprova é que ele não é seguro para os usuários finais, e isso danifica completamente a AppStore / Google Play. É um desastre se muitos aplicativos podem alterar sua funcionalidade a qualquer hora e em qualquer lugar, e é difícil rastrear e limitar essas ações prejudiciais após o aplicativo ter permissão para publicar.

CodePush não é apenas uma técnica, é uma parte importante dos ecossistemas móveis. Acho que a equipe do Flutter não deve fornecer tal técnica oficialmente, embora possa ser implementada por alguns desenvolvedores de forma privada, isso está OK porque não será usado descontroladamente.

Ponto muito interessante e parece razoável em alguns aspectos, mas também tem alguns erros.

1. Flutter também suporta Cupertino da Apple , MD não é o único escolhido.
2. Você deve conhecer o Unity na área de jogos, o sistema de renderização do Flutter funciona de maneira semelhante em alguns aspectos.
3. Na verdade, por enquanto, usar a web (JS) pode implementar o CodePush e ignorar a revisão da AppStore para modificar seu aplicativo. Então, por que rejeitar Flutter (dardo) e liberar JS.

Então, por que rejeitar Flutter (dardo) e liberar JS.

JS é executado em uma sandbox e, portanto, é seguro. (como todas as páginas da web carregadas no Safari)

O Dart compila em código binário e não é restringido por tal sandbox.

Eu sou um desenvolvedor Android há muitos anos. Acho que o envio de código não é tão importante.
Sem o Code Push, você não consegue desenvolver? Nesse caso, isso é muito tolo.
Flutter é uma estrutura para dispositivos móveis, portanto, primeiro você deve aprender mais sobre o desenvolvimento de dispositivos móveis.
Sem o envio de código, você pode usar a atualização completa.
Como diz o anúncio: atravesse a ponte quando chegar a hora.
Como desenvolvedor, acho mais importante usar maneiras diferentes para resolver o mesmo problema.

Flutter não é React Native, você não pode usar a experiência do React Native (ou outra estrutura) para ver o Flutter. Eles são coisas diferentes.

@MaxZeng Talvez o flutter possa habilitar a atualização

Sem atualizações quentes como o RN, não mudaremos para o Flutter! Frameworks devem tornar a vida do desenvolvedor mais fácil !!

As flores que eu esperava sumiram.

@MaxZeng Talvez o flutter possa habilitar a atualização

1 、 Na verdade, isso danificará os ecossistemas da Google Play Store também, tornará a equipe Android difícil de controlar os comportamentos do aplicativo.
2 、 CodePush não é necessário para a maioria dos aplicativos, esta tecnologia será usada de forma maliciosa por alguns desenvolvedores.
3 、 Se os desenvolvedores não criptografarem os patches corretamente, isso pode causar um grande “ataque man in the middle”; hackers malignos podem modificar o código enviado para sequestrar os aplicativos Flutter.

Só quero dizer que o hotfix é um recurso de importação para a maioria das empresas chinesas. mais de 70% dos dispositivos Android chineses não são compatíveis com o Google Play

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

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

O roteiro dizia hotfix no Android. Esperamos que o iOS seja compatível em breve.

No entanto, @taibaiyinxing Flutter não pode fornecer recursos que não são permitidos pela App-store da Apple.

No entanto, @taibaiyinxing Flutter não pode fornecer recursos que não são permitidos pela App-store da Apple.

@zoechi Usamos aplicativo corporativo e não precisamos fazer upload para a app-store.

Patching dinâmico no Android, permitindo que atualizações de código sejam implantadas em aplicativos Flutter em execução no Android diretamente de servidores.
🎉

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

Parece que não há planos para oferecer suporte ao CODE PUSH no IOS neste ano.

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

"A lista aqui não deve ser vista como exaustiva, nem uma promessa de que terminaremos todo esse trabalho." :)

O trabalho de envio de código ainda está nos primeiros dias de testes. Ainda não foi determinado em quais plataformas iremos ou não implantaremos que funcionem em 2019. Afinal, é apenas fevereiro. 10 meses é muito tempo!

Atualmente, os engenheiros estão focados em desenvolver a tecnologia principal para dar suporte aos 3 casos de uso @Hixie descritos em: https://github.com/flutter/flutter/issues/14330#issuecomment -442274897
Espero começar a fazer alguns testes limitados de pelo menos um desses casos de uso nos próximos meses.

Como nossa tecnologia de desenvolvimento de vibração não é muito desenvolvida, o APP é atualizado com frequência e muitas são atualizações urgentes. E nosso aplicativo não planeja fazer upload de uma loja de aplicativos. Portanto, esse recurso é muito importante. Isso pode melhorar a velocidade de iteração do APP. Caso contrário, a fragmentação do APP faz com que nossa API seja atrasada.

Como acho que todos podemos concordar, o motivador desse problema é que entregar qualquer aplicativo móvel aos usuários finais por meio de jardins murados gerenciados pelo Google e pela Apple (as lojas) é um grande inconveniente para os desenvolvedores de aplicativos (para não mencionar serviço ruim para usuários finais de aplicativos bons / inovadores), sendo a Apple o mais inconveniente (dias para a Apple em oposição a horas para o Google).

Como um ponto lateral, uma possível solução poderia ser se as lojas forneceram um caminho para atualizações instantâneas para desenvolvedores 'confiáveis' (como um serviço fast-track). O Google e a Apple poderiam então fazer uma auditoria em tempo real (automatizada, ... como com AI ?? ... com reversão automática post-facto, se necessário) do aplicativo. Mas isso parece improvável por uma série de razões técnicas e outras. Ambas as lojas têm, é claro, um atalho para testadores beta.

Então ... enquanto espera pelos recursos desta edição, uma maneira de aliviar a inconveniência envolvida na entrega de qualquer aplicativo móvel aos usuários finais é automatizar as etapas.

Para ver um exemplo de ferramenta que faz esse tipo de automação para Flutter, consulte:
https://github.com/mmcc007/fledge
Para registro, inclui documentação para muitas das etapas de configuração únicas envolvidas que não podem ser facilmente automatizadas:
https://mmcc007.github.io/fledge/

@charliezzo Usando esta ferramenta, ou ferramentas semelhantes, um aplicativo Flutter (e atualizações, etc.) pode ser entregue aos testadores beta do Android e iOS em minutos.

Também possui um workflow para automatizar a entrega aos usuários finais via lojas (horas + para Google, dias + para Apple 😂👍).

@ mmcc007
oh, obrigada. mas eu digo que não quero enviar meu aplicativo para o Google Play e app store.
preciso vender meu aplicativo de outra maneira.
e eu não preciso do Google Play e da App Store para atualizar meu aplicativo.
Eu só quero atualizar meu aplicativo sozinho quando os usuários o instalarem e iniciarem.
e flutter é um framework de 60FPS ou superior, ele pode fazer jogos online, não queremos ter um pequeno patch do Google Play e da App Store.
você sabe que cada patch em pouco tempo pelo google play e app store é lento e difícil.
Na verdade, você sabe que não podemos usar o Google Play na China. e a app store é muito lenta.
há muitas lojas de aplicativos como o Google Play na China. Não temos tempo para enviar atualizações para todas as lojas de aplicativos.

O Code Push deve ser um recurso primário no Flutter. Coloque em cima.

Podemos fazer isso substituindo todos os arquivos em app_flutters no Android

oi, você pode me dar seu e-mail para uma discussão mais aprofundada, nossa equipe também encontrou essa solução, mas ela pode funcionar apenas quando o aplicativo deve ser encerrado e reiniciar o app。tks @LNeway

oi você pode me dar seu e-mail para uma discussão mais aprofundada, nossa equipe também encontrou essa solução, mas ela pode funcionar apenas quando o aplicativo deve ser encerrado e reiniciado o aplicativo. tks @LNeway
@KinsomyJS
Também fiz uma demonstração para verificar a viabilidade. Hahaha ~

Compartilhe com um breve trecho ou postagem no blog ou comente aqui ou cc [email protected] no e-mail ...

@LNeway @KinsomyJS Algum de vocês pode dar mais detalhes, por favor?
Obrigado

No entanto, @taibaiyinxing Flutter não pode fornecer recursos que não são permitidos pela App-store da Apple.

@zoechi Você está dizendo que você e / ou a equipe do Flutter tem uma análise que conclui que uma técnica de codepush viável pelo Flutter é fundamentalmente diferente daquela do React-native e é proibida - e, portanto, devido à Apple, pode nunca vir para o iPhone?

Se este recurso for adicionado, será compatível com a versão beta 1.0.0?

@dahabdev

Pelo que vale a pena, pela minha experiência com o Ionic, acredito que o "push de código" é superestimado e espero que a equipe do Flutter não gaste muito tempo trabalhando nisso enquanto ainda faltam tantos outros recursos básicos e essenciais.

Na época em que desenvolvi o UAVForecast, usei o Ionic, atraído pelo recurso de "implantação iônica", que se oferecia para atualizar todo o conteúdo do aplicativo remotamente. Naquela época (isso foi em 2014), os tempos de análise da App Store da Apple eram da ordem de 2 semanas. Eu queria iterar rapidamente, agir rápido e quebrar coisas, como dizem.

No início, o "desdobramento iônico" foi ótimo, mas logo percebi alguns problemas importantes. Isso causou confusão para meus usuários ("o aplicativo diz que se atualizou sozinho, então por que há outra atualização pendente na Play Store / App Store?"); às vezes quebrava o aplicativo, por exemplo, quando os metadados do aplicativo (por exemplo, permissões) eram silenciosamente alterados por um plug-in do Cordova, mas não eram atualizados por um push de código ativo; rastrear números de versão era complicado e eles ficariam fora de sincronia com o que eu havia enviado às lojas; isso me deixou preguiçoso quanto aos testes, já que eu sempre poderia "implantar iônico" sozinho fora dos bugs; e às vezes acabava empurrando bugs piores, que poderiam ter sido detectados pelas equipes de revisão de aplicativos se eu lhes tivesse dado a chance de olhar.

Cerca de um ano depois de lançar a primeira versão, os tempos de análise da App Store melhoraram significativamente. Hoje, é reduzido para apenas alguns dias e, claro, na Play Store do Google, pode durar apenas algumas horas. Devido a todos os problemas que tive, decidi remover a funcionalidade de "implantação iônica" do meu aplicativo e, com vários milhões de downloads já atrás de mim, não olhei para trás.

Embora eu goste do Ionic e realmente aprecie tudo o que seu desenvolvedor, o Drifty, fez (obrigado!), Eu diria que o Drifty cometeu o erro de investir muito tempo em recursos brilhantes, como push de código, que atraem usuários, e não há tempo suficiente para obter as porcas e parafusos da estrutura certa para evitar problemas que acabam por afugentá-los. Agora em sua quarta versão, o Ionic foi reescrito tantas vezes de maneiras incompatíveis com versões anteriores que parei de tentar mantê-lo - a versão mais recente ainda tem vários problemas sérios pendentes que me impedem de atualizar, e agora estou reescrevendo todo o meu aplicativo em Flutter.

A experiência até agora tem sido excelente e estou me divertindo muito, mas ainda existem algumas lacunas e omissões importantes no Flutter, especialmente nos plug-ins. Por exemplo: não há integração de campo de texto com preenchimento automático de senha, o plug-in do Google Maps é simples (e há bugs de renderização de estrutura relacionados), o WebView nativo não oferece suporte a file: // URLs para carregar ativos, a barra de guias não suporta transparência ou fundos gradientes, células da tabela não suportam colspan, ThemeData não é extensível com cores específicas do aplicativo para usar com animação, a única biblioteca DateTime totalmente ciente do fuso horário carece de muitos recursos importantes de momento e fuso-horário. tantas abordagens de gerenciamento de estado que é confuso para os novatos, você tem que "limpar" com frequência para evitar exceções estranhas, o hot-swap geralmente não funciona como deveria, e eu poderia continuar ...

Eu classificaria _todos_ como mais importantes do que "push de código", especialmente se isso arriscar a Apple rejeitar aplicativos Flutter, se isso exigir grandes mudanças na estrutura do compilador que poderia eventualmente tornar as otimizações que melhoram o desempenho do aplicativo mais difíceis (eu levaria um 5% de melhoria de desempenho em relação ao "push de código" em qualquer dia) ou leva tempo para concluir o recurso da estrutura.

Por outro lado, posso ver que alguns desenvolvedores podem realmente precisar dele em algumas situações, especialmente se estiverem operando fora das lojas, então posso entender o entusiasmo aqui.

@matthewlloyd muitos pontos excelentes!

Se vocês não podem suportar Code Push, existe uma maneira de fazer um Parser para gerar a partir de alguns dicionários (como json, xml ...) para Flutter Widget? Isso é impossível ou uma boa ideia?

- Alguém tem uma opinião sobre este?
https://pub.dartlang.org/packages/dynamic_widget
parece promissor, embora não resolva o medo do 'bug crítico'.

Essa é a parte maluca é que o push de código é o elefante na sala, que é profundamente um problema de negócios / processo e técnico, e um lado tende a ignorar o outro ...

não há integração de campo de texto com preenchimento automático de senha, o plug-in do Google Maps é barebones (e há bugs de renderização de estrutura relacionados), o WebView nativo não oferece suporte a file: // URLs para carregar ativos, a barra de guias não oferece suporte a transparência ou fundos gradientes, células de tabela não suportam colspan, ThemeData não é extensível com cores específicas do aplicativo para usar com animação, a única biblioteca DateTime totalmente ciente do fuso horário carece de muitos recursos importantes de momento e fuso-horário, há tantas abordagens para o gerenciamento de estados é confuso para os recém-chegados, você tem que "limpar" com frequência para evitar exceções estranhas, o hot-swap geralmente não funciona como deveria, e eu poderia continuar ...

Esperançosamente, todos eles já têm o problema do Github: D

Isso estava anteriormente em nosso roteiro para 2019. Depois de investigar isso com mais detalhes, decidimos não continuar com este trabalho por enquanto.

Vários fatores nos levaram a esta decisão:

• Para cumprir nosso entendimento das políticas da loja no Android e iOS, qualquer solução seria limitada ao código JIT no Android e código interpretado no iOS. Não temos certeza de que as características de desempenho de tal solução no iOS atingiriam a qualidade que exigimos de nosso produto. (Em outras palavras, "seria muito lento".)

• Existem algumas preocupações graves de segurança. Como esses patches permitiriam essencialmente a execução de código arbitrário, eles seriam vetores de malware extremamente atraentes. Poderíamos atenuar isso exigindo que os patches sejam assinados com a mesma chave do pacote original, mas isso está sujeito a erros e qualquer erro teria consequências graves. Este é, fundamentalmente, o mesmo problema que tem atormentado plataformas que permitem a execução de código de fontes de terceiros. Esse problema poderia ser atenuado integrando-se a um mecanismo de atualização de plataforma, mas isso anula o propósito de um mecanismo de patch fora de banda.

• Atualmente, não existe uma solução de hospedagem de código aberto pronta para usar para aplicar patches, então teríamos que contar com pessoas configurando seus servidores Web de acordo, ou teríamos que criar integrações para serviços de terceiros proprietários, ou nós teria que criar nossa própria solução sob medida. Hospedar patches é um espaço em que não estamos ansiosos por entrar. Ter pessoas configurando seus próprios servidores as deixa abertas para cometer erros com implicações potencialmente sérias, conforme explicado no ponto anterior sobre segurança. Depender de serviços de terceiros coloca o Flutter em uma posição incômoda de ter que escolher vencedores e nos expõe ao risco de os próprios projetos fazerem alterações nas políticas que afetariam esse recurso.

Preferimos gastar nosso esforço de engenharia em outras questões por enquanto. Esperamos continuar experimentando neste espaço e provavelmente levaremos isso a sério novamente no futuro (por exemplo, provavelmente precisaremos de uma solução de atualização para aplicativos de desktop), mas provavelmente não este ano.

Embora eu entenda a razão por trás do cancelamento desse recurso, ainda assim é decepcionante. A Play Store e a App Store são considerações importantes, mas nem todo aplicativo é distribuído dessa forma. Para nosso caso de uso, fornecemos ao cliente o dispositivo e o aplicativo pré-instalado. Ter um mecanismo para enviar atualizações dinamicamente para o usuário é um recurso muito importante, pois não queremos passar pelas lojas. Esse recurso teria sido inestimável. Espero que seja revisitado no futuro, como você mencionou.

Obrigado por comunicar com transparência o racional da equipe.

@eseidelGoogle O código JavaScript compilado do Dart poderá usar o Skia para renderizar páginas?

Isso é bastante decepcionante.

Com relação a todos os problemas de segurança e conformidade da loja que você mencionou, eles podem ser válidos e legítimos, mas no final do dia há um exemplo de tecnologia de "atualizações importantes" que já está funcionando: push de código.

React Native + o serviço de push de código funciona e se provou no mundo real. É testado em batalha. Parece não haver problema com as lojas de aplicativos em relação às atualizações indiretas. Parece que todo mundo está "ok" com isso. Então, acho que a solução de Flutter também poderia ser permitida.

Com relação aos problemas de desempenho, pode ser uma boa ideia deixar o desenvolvedor escolher trabalhar no modo de "baixo desempenho", mas habilitar atualizações ao vivo.

Uma boa jogada! Prefiro que o esforço de engenharia seja gasto na otimização do Flutter do que na adição de um recurso de envio de código que pode complicar demais e prejudicar o ecossistema

No momento, estou tendo meu primeiro aplicativo, desenvolvido em Flutter, no teste beta aberto e empurrei cerca de 10 pacotes de aplicativos com correções. Mas ele deve estar quase sem erros quando eu o lançar para produção.

Portanto, não sei se algum dia vou precisar desse recurso, mas encontrei este pacote de atualização OTA de pub que parece estar indo bem com 89 pontos, o que só é prejudicado por sua popularidade. Esse pacote é seguro? Parece que ele está baixando o APK de um URL, descompactando-o nativamente e acionando a intenção de instalação do APK no Android.

Aqueles que absolutamente precisam desse recurso podem experimentar esse pacote.

Mas eu posso ver porque a equipe do Flutter não está muito animada com isso, porque vamos pegar o pacote acima no caso. Parece estar baixando de um URL. E um site é sempre mais amigável para hackers do que aplicativos nativos. Existem muitas questões de segurança a partir de agora. Isso apenas torna um aplicativo Flutter tão vulnerável quanto um site que é estritamente proibido.

Eu tinha uma máquina de 2 GB de RAM quando comecei, tentando desenvolver um aplicativo Android como sempre quis, mas minha máquina não estava à altura da tarefa. Tentei PhoneGap, Cordova, alguns frameworks Intel, React-Native, e nenhum deles começou a rodar. O Flutter foi o único com quem eu realmente comecei e com sua bela interface do usuário e ferramentas de desenvolvimento, está quilômetros à frente de seus contemporâneos, mesmo sem esse recurso.

Qualquer atualização?

O fluxo de trabalho de lançamento de aplicativos nunca mais será o mesmo depois que a forma como o reagente nativo nos estragou com o Code Push. É uma pena que Flutter não o suporte. Flutter está se moldando muito bem e poderia ter sido um concorrente do React Native se eles optassem por oferecer suporte a esse recurso. Ai de mim ...

@Hixie OK, então uma mudança fundamental de engenharia / técnica tem muitas desvantagens por enquanto - isso faz sentido para mim.

No entanto - como você se sente em ajudar os desenvolvedores a agitar essa preocupação de negócios no curto e médio prazo com algumas abordagens alternativas que geram alguma documentação / discussão - talvez até vídeos, embora talvez não seja uma solução oficial ou 'endossada', mas um pouco de atenção.

por exemplo

• Configuração em tempo real do Firebase
• Servidor baseado em json-> widgets (por exemplo, https://github.com/dengyin2000/dynamic_widget/blob/master/WIDGETS.md ou semelhante, eu não endosso o plugin exato ainda, mas a ideia)
• ou talvez outra coisa, talvez funções de nuvem para usuários avançados ...
• obviamente, não estou sugerindo que você faça um monte de esforço de engenharia para um caso de uso 'grande', mas uma alternativa de envio de código de hello-world que atende a maior parte da necessidade sem um 'vamos consertar / mudar cada coisa 'tipo de arquitetura.

minha premissa é que "nós" podemos atender 70-90% da preocupação com codepush sem uma mudança fundamental de arquitetura para flutter; o que alguém pensa disso?

A abordagem code-as-ui do Flutter pode até tornar isso mais fácil do que para os desenvolvedores do Android ....

Eu vi pessoalmente pelo menos duas empresas que escolheram os outros caras ao invés de flutter apenas por esse motivo, e muitas outras falaram de forma semelhante.

Talvez a conversa pudesse ir
"Usuário: Você está pulando o suporte do codepush"
"Equipe do Flutter: Sim, por enquanto, por esses motivos, (como você fez), mas, além disso, você pode tentar A ou B para alguns casos de uso"

Desculpe pelo longo comentário

@neiljaywarner Talvez valha a pena dar uma olhada em LUA - eu fiz uma prova de conceito no ano passado em que os scripts LUA poderiam ser usados ​​para criar / ajustar a funcionalidade de um aplicativo Flutter.

@neiljaywarner Sou totalmente a favor desse tipo de abordagem, mas essa é uma preocupação ortogonal do que o que esse bug está cobrindo.

Embora eu compreenda as razões por trás desse recurso, ainda assim é decepcionante. A Play Store e a App Store são considerações importantes, mas nem todo aplicativo é distribuído dessa forma. Para nossos casos de uso, oferecemos aos clientes dispositivos e aplicativos pré-instalados. Ter um mecanismo para enviar atualizações dinamicamente aos usuários é um recurso muito importante porque não queremos passar pela loja. Este recurso é muito valioso. Espero reexaminá-lo como você mencionou no futuro.

Obrigado por comunicar a racionalidade da equipe de forma transparente.

eu concordo

funcionalidade code-push significa mais aplicativos, mais clientes, mais desenvolvedores, mais testes, mais correção de bugs, menos problemas

Para o MVP de uma startup ou aplicativos em crescimento, as atualizações ou correção de bugs são cruciais, enquanto o desempenho é menos preocupante na maioria das vezes. Isso causará prós e contras ao ecossistema Flutter. O declínio da adoção, startups e desenvolvedor pessoal são importantes para o crescimento da comunidade em estágio inicial. As vantagens podem ser os apps e equipes de qualidade que mudariam para o Flutter, que buscam maior desempenho?

@maplerichie , Concordo, o motivo pelo qual adoro flutter é a Experiência do desenvolvedor, o desempenho e a plataforma cruzada para todos os dispositivos. Não me importo se o code-push não for implementado (talvez), é pelo bem da reputação e popularidade do ecossistema. Agora eu sei por que o push de código parece muito lento ao usar aplicativos do Windows. (Inicialização lenta, atraso de entrada e animação lenta) aqui

Precisamos muito dessa função
Precisa de uma atualização quente

Como outros mencionados anteriormente, grandes empresas e grandes equipes de desenvolvimento podem não precisar de atualizações importantes. Mas pense em uma pequena startup, um par de desenvolvedores trabalhando em um aplicativo móvel, fornecendo recursos para produção com ciclos de lançamento rápidos. Não há tempo para testes e ciclos de controle de qualidade. Crie um novo recurso, veja se funciona e os usuários gostam, substitua ou corrija. Não poderíamos chegar onde estamos sem atualizações quentes. É uma verdadeira virada de jogo para o desenvolvimento móvel.

@yaronlevi Sou uma "pequena startup", ainda menos do que alguns desenvolvedores trabalhando em um aplicativo móvel, sou só eu, e entrego para produção com ciclos de lançamento rápidos. Com a Google Play Store oferecendo atualizações que levam apenas algumas horas, e a Apple App Store revisando atualizações quase sempre menos de 24 horas na minha experiência hoje em dia, eu definitivamente não preciso de push de código. Se o Flutter tivesse push de código, eu tomaria medidas ativamente para ter certeza de que ele foi desabilitado em meu aplicativo.

Atualmente, sou o único desenvolvedor de um aplicativo móvel (e o back-end correspondente) para uma pequena empresa. Eu realmente amo o Flutter, mas tenho que explicar constantemente para um cliente que não entende a necessidade de testes de unidade ou testes de automação por que leva tanto tempo para implementar funcionalidades que podem ser descritas em 10 palavras. Estou um pouco preocupado em ter que lançar algo pela metade e não ser capaz de enviar correções críticas de bugs rapidamente. Vou fazer sem por agora, mas o push de código definitivamente seria bom ter. No entanto, eu entendo os desafios técnicos e as preocupações com a segurança e, no final, apoio uma abordagem cautelosa.

bem, obrigado de qualquer maneira.
Acho que precisamos descobrir por nós mesmos.

realmente decepcionante :)

O Flutter para o SDK da web em breve será mesclado com o SDK do celular. Uma solução alternativa é usar um WebView móvel para carregar o código de flutter. 😁

@matthewlloyd oi cara, é necessário dar suporte ao hot update, o ponto não é na hora de revisar. O usuário deve estar vinculado à AppStore e fazer o download do aplicativo novamente.

Talvez ajude
https://github.com/dengyin2000/dynamic_widget
https://github.com/neohelden/Flutter-AdaptiveCards

Eu realmente não vejo um problema urgente em não ter push de código. Quase todos os usuários têm atualização automática em sua loja de aplicativos. No entanto, fornecer uma solução alternativa para distribuir atualizações sem uma App Store seria bom.

MXFlutter usa JavaScript para implementar os recursos de renderização do Flutter, oferece suporte à sintaxe do Flutter e oferece suporte a push de código e atualização automática.
https://github.com/TGIF-iMatrix/MXFlutter

@ TGIF-iMatrix você sabe se esta solução está em conformidade com a política de distribuição da Store?

@truongsinh
É seguro, pois é uma distribuição js-> analisador nativo-> abordagem de composição de widgets.

consideraremos o uso de flutter se ele suportar push de código

@ TGIF-iMatrix É altamente provável que isso não seja aprovado pela Apple, já que a isenção para atualizações do Javascript Core foi retirada dos Contratos da App Store e muitos usuários do CodePush foram avisados ​​/ negados por causa desse recurso.

Talvez devêssemos reformular a questão, "sever-dictated-rendering" vs "code push". "sever-dictated-rendering" refere-se apenas a diferentes UI / layout / theme, enquanto code-push também implica mudança na lógica, permissão, plug-ins, etc.

Talvez, entretanto, nesse ponto, você possa apenas usar um plug-in para fazer isso, então isso vai contra o propósito deste problema.

Alguém tentou tinker-lib com flutter, que é do tencent github repo, e algum sucesso com isso, se alguém interessado, eu possa colaborar com você, tentei fazer push update, mas pequenas modificações são necessárias para carregar o novo código que deve ser feito no flutter. arquivo de artefato jar

Espero ter uma solução o mais rápido possível

Em relação às implicações de desempenho da implementação de push de código, compilar o código Dart para WebAssembly ajudaria? Isso pode permitir a implementação da compilação JIT no iOS dentro da sandbox do JavaScript.

precisamos de iteração rápida e desenvolvimento ágil.
se não houver atualização quente, flutter é sempre um irmão mais novo para reagir nativo.

Hot update é muito importante para nós, se flutter for compatível com hot update, usaremos flutter para substituir o nativo de reação.

Eu havia planejado a melhor maneira possível de envio de código, mas devido a limitações de tempo, só posso iniciar este projeto em novembro da semana passada ou em dezembro, não modifico nenhum código de mecanismo ou código de estrutura ou qualquer código java como tinker lib, portanto não viola quaisquer termos da loja, o aplicativo de saída também é um problema, então nenhuma regressão de desempenho, tento torná-lo tão fácil de implementação para que qualquer um possa plug-in em seu aplicativo, com base em minha pesquisa sobre a equipe de flutter de base de código é intencionalmente impossibilitada de fazer o push de código i tentei todas as possibilidades com a implementação atual e concluí que somente maneiras possíveis é você fazer modificações no motor ou preparar uma solução sem modificar o motor, vou para a 2ª opção e planejei todos os requisitos necessários para o projeto. Espero que o projeto tenha sucesso. Nesse ínterim, se a equipe de flutter reavaliar o problema, todos estaremos felizes com a implementação embutida.

A atualização automática sempre será necessária！

isto é indispensável, uma funcionalidade crucial

Eu havia planejado a melhor maneira possível de envio de código, mas devido a limitações de tempo, só posso iniciar este projeto em novembro da semana passada ou em dezembro, não modifico nenhum código de mecanismo ou código de estrutura ou qualquer código java como tinker lib, portanto não viola quaisquer termos da loja, o aplicativo de saída também é um problema, então nenhuma regressão de desempenho, tento torná-lo tão fácil de implementação para que qualquer um possa plug-in em seu aplicativo, com base em minha pesquisa sobre a equipe de flutter de base de código é intencionalmente impossibilitada de fazer o push de código i tentei todas as possibilidades com a implementação atual e concluí que somente maneiras possíveis é você fazer modificações no motor ou preparar uma solução sem modificar o motor, vou para a 2ª opção e planejei todos os requisitos necessários para o projeto. Espero que o projeto tenha sucesso. Nesse ínterim, se a equipe de flutter reavaliar o problema, todos estaremos felizes com a implementação embutida.

Eu havia planejado a melhor maneira possível de envio de código, mas devido a limitações de tempo, só posso iniciar este projeto em novembro da semana passada ou em dezembro, não modifico nenhum código de mecanismo ou código de estrutura ou qualquer código java como tinker lib, portanto não viola quaisquer termos da loja, o aplicativo de saída também é um problema, então nenhuma regressão de desempenho, tento torná-lo tão fácil de implementação para que qualquer um possa plug-in em seu aplicativo, com base em minha pesquisa sobre a equipe de flutter de base de código é intencionalmente impossibilitada de fazer o push de código i tentei todas as possibilidades com a implementação atual e concluí que somente maneiras possíveis é você fazer modificações no motor ou preparar uma solução sem modificar o motor, vou para a 2ª opção e planejei todos os requisitos necessários para o projeto. Espero que o projeto tenha sucesso. Nesse ínterim, se a equipe de flutter reavaliar o problema, todos estaremos felizes com a implementação embutida.

Olá @canewsin
Também tentei fazer o mesmo não modificando o motor de vibração. Descobri que no modo AOT, o mecanismo procura os arquivos .so no caminho da biblioteca nativa do Android, modificando / adicionando um arquivo lá após a compilação do aplicativo ser restrita pela JVM. Portanto, o carregamento de arquivos .so baixados pelo ar não pode ser adicionado ao caminho lib nativo.

Esperando por mais insights de você. 😀

Acho que não há necessidade de atualizar o código dart e o código nativo.
Apenas o código do dardo está bom!

Ei, estou precisando disso agora. Goodle restringiu sua política de revisão. Nosso aplicativo leva 2 semanas para atualizar agora ... Nossa metodologia enxuta vai para a merda com isso.

@NEELANSHSETHI você pode postar o plano aqui? Podemos começar a implementá-lo

@almeynman Por favor, mantenha-nos atualizados sobre o seu progresso :)

@HerrNiklasRaab Ainda não comecei com isso, pois não tenho uma

Essa é a principal razão pela qual não migramos de reagente nativo para vibração. :(

😔

O ReactNative está muito à frente do Flutter por causa desse recurso e tive muitos projetos em que a escolha do ambiente (RN ou Flutter) foi decodificada em comparação com o recurso push code! Esperando por uma notícia: /

Olá todo o seu novembro já como disse que comecei meu trabalho está indo bem. Vai ser um projeto privado, então cobrarei uma chave de licença para usá-lo. Então não vai ser de graça, já que eu não tenho nenhuma fonte de renda eu tenho que fazer dessa forma, se você tiver interesse eu farei um repositório de follow up sobre o trabalho, siga para atualizações. Depois de criar o repo da linha do tempo, irei informá-los.

@eseidelGoogle
Caso de negócios:
Temos um aplicativo de rastreamento de ônibus em tablets, mas o cliente atualiza 1 vez no mês porque o tablet usa dados de internet e não wi-fi
Com o Code Push, seremos capazes de atualizar sem consumir muito os dados do cliente

Tínhamos o aplicativo Cordova com suporte a push de código. Quando se tratou de modernizar o aplicativo por engano, pensamos que o flutter adicionaria suporte para push de código "de qualquer maneira", então desenvolvemos nosso aplicativo usando o flutter. Mas a vida sem push de código foi totalmente terrível para nós no ano passado. Portanto, estamos finalmente (e felizmente) no processo de (re) reescrever o aplicativo em react-native para ter nosso suporte de push de código.

Code Push, é por isso que estou aprendendo React-Native agora.

Se você está interessado na minha implementação
siga o relatório de progresso aqui
https://github.com/canewsin/flutter-code-push-timeline
por favor, leia todos os meus comentários acima antes de prosseguir.

Code Push, é por isso que continuarei com o React-Native.

Não poste postagens não construtivas, +1, "Precisamos disso", "Estamos usando o X", etc, pois não é construtivo e não contribui para a discussão.

Você terá um impacto muito melhor clicando no botão Polegar para cima (👍) na primeira postagem, sem que todos que já postaram nesta discussão sejam notificados sobre isso (até onde eu sei, alguns membros da equipe de vibração irão silenciar tópicos grandes, então postar aqui tem menos efeito do que um polegar para cima).

Também quero lembrar a todos os inscritos aqui que o github tem um botão unsubscribe no canto superior direito do tópico.

Além disso, a equipe do Flutter prioriza os problemas com base no número de polegares para cima, então aumentar o contador pode ser um grande negócio. Isso e apenas clicar em "inscrever-se" é o suficiente.

O projeto de push de código que assumi está indo bem, mas quero alguns exemplos de requisitos de push de código, então, se o push de código for concluído, como usá-lo, publique seu requisito exclusivo como um novo problema neste repo https://github.com/ canewsin / flutter-code-push-timeline para que o desenvolvimento esteja no caminho certo.
limitações que encontrei até agora são:
não podemos acessar a plataforma nativa, mas isso pode ser feito por meio da funcionalidade ffi.
o código codepush é executado em uma sandbox para algumas questões de segurança, portanto, nenhum dano pode ser feito ao dispositivo.

Olá todo o seu novembro já como disse que comecei meu trabalho está indo bem. Vai ser um projeto privado, então cobrarei uma chave de licença para usá-lo. Então não vai ser de graça, já que eu não tenho nenhuma fonte de renda eu tenho que fazer dessa forma, se você tiver interesse eu farei um repositório de follow up sobre o trabalho, siga para atualizações. Depois de criar o repo da linha do tempo, irei informá-los.

Muito interessante!
Olá, você já tem algum exemplo? E como você lida com a seção iOS? uma vez que a Apple é muito rigorosa nesta área. Obrigado

Olá todo o seu novembro já como disse que comecei meu trabalho está indo bem. Vai ser um projeto privado, então cobrarei uma chave de licença para usá-lo. Então não vai ser de graça, já que eu não tenho nenhuma fonte de renda eu tenho que fazer dessa forma, se você tiver interesse eu farei um repositório de follow up sobre o trabalho, siga para atualizações. Depois de criar o repo da linha do tempo, irei informá-los.

Muito interessante!
Olá, você já tem algum exemplo? E como você lida com a seção iOS? uma vez que a Apple é muito rigorosa nesta área. Obrigado

trabalhando atualmente com o lado Android, embora o lado ios seja burro, semelhante à versão em sandbox de aplicativos js reativos, o código será executado no sandbox sem acessar apis da plataforma, portanto, pode não ser o problema quando estiver pronto para o lado ios.

Olá @eseidelGoogle
Alguma atualização? Linha do tempo?

Olá @eseidelGoogle
Alguma atualização? É dezembro é um recurso que será lançado em 2019?

Eu perguntei a um tópico da AMA sobre este assunto. Pode ter informações úteis.
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 eu li seu artigo no 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

Eu me pergunto se as atualizações do aplicativo Flutter serão pequenas se eu publicar como abb "Android App Bundle" no Google Play ou será apenas para código nativo?

Este é um recurso importante para construções corporativas (aplicativos que são distribuídos fora das lojas, por exemplo, por meio de portais da web)

É um recurso muito necessário. Por que não podemos tê-lo oficialmente? O que o impede de oferecer esse recurso?

isso está no roteiro de 2020?

Não

2020 e ainda esperando

Por favor, leia isso antes de postar abaixo.

Aqui está uma breve recapitulação se você não quiser rolar para cima para entender:

Como foi apontado neste comentário , os três grandes desafios são:

• O que é empurrado
• É seguro para os usuários
• De onde é empurrado

O primeiro, _what_ é empurrado, é onde reside o maior problema. As diretrizes de revisão da Apple proíbem qualquer tipo de push de código . Sim, a terminologia usada _também inclui push de código javascript._ A Apple aparentemente não tomou medidas contra isso e pode haver muitos motivos para isso, mas qualquer motivo postado aqui seria pura especulação.

As próprias diretrizes da loja de jogos do Google

Flutter, pelo menos no modo de lançamento, é compilado e, mesmo que não fosse, não é javascript , portanto, não pode ser interpretado no iOS sem quebrar o requisito "não JIT", ou ser muito lento.

O segundo, é _seguro_ para os usuários, é praticamente todo o raciocínio por trás da lógica das lojas para proibir o download de código dinâmico e não verificado. Permitir que qualquer pessoa baixe qualquer coisa de qualquer lugar e _apenas executá-lo_ coloca os usuários em risco. Mesmo dentro de uma sandbox, onde os privilégios especiais do JavascriptCore em torno do envio de código são destacados, ainda não é seguro.

O push de código permite que você ignore o processo de verificação das lojas, o que significa que o código h não verificado é executado nos dispositivos dos usuários, o que significa que é possível deturpar o aplicativo original ou mesmo adicionar recursos prejudiciais, como desvio de dados ou explorações que o processo de verificação teria travado .

Você pode ter as melhores intenções do mundo, sempre haverá alguém para te apunhalar pelas costas.

Por enquanto, no Android, se você não estiver usando a play store para distribuir, pode apenas criar um downloader que irá buscar um apk e solicitar ao usuário que o instale. No iOS, bem, você efetivamente não pode fazer o sideload sem uma tonelada de dor, e os dispositivos JB não se importam com as restrições da loja de aplicativos.

Agora, é possível implementá-lo para outras plataformas além de iOS ou Android? Certo! Mas o Desktop ainda não está na versão beta (além disso, você também pode fazer sua própria atualização automática no desktop) e, Web, bem, basta atualizar a página.

Agora, se você quiser que a equipe dê uma olhada, vá para o primeiro post e adicione um 👍.

Se o seu comentário cai na lista abaixo, por favor, reconsidere publicá-la.

• Perguntar quando / se está no roteiro
• "Não está lá" (e variações, como o comentário anterior a este)
• "Estamos usando o framework X porque nenhum código push"
• "O Framework X é melhor porque o código push"
• "Precisamos de push de código"
• "Atualizações?"
• Argumentos para push de código que são
  
  
  
  • Aplicativos corporativos / Sideloaded
  
  
  • Remendo de emergência
  
  
  • Adicionando recursos
  
  
• Argumentos contra push de código que são
  
  
  
  • As durações das análises da play / app store estão mais curtas agora
  
  
  • A play / app store forbirds isso
  
  
  • Você não precisa disso
  
  

Este problema já está carregado com comentários suficientes no estado em que se encontram, portanto , não adicione comentários que não acrescentem nada à conversa. Se a equipe tiver algo a dizer, eles postarão aqui, já que esse post tem quase 100 participantes no momento e mais de 500 polegares, não é possível ignorar.

Para ser sincero, não acho que isso deva ser da sua conta. O desenvolvedor usará o recurso por sua própria conta e risco. Se a Apple repentinamente decidir banir todos os aplicativos usando push de código, então seu aplicativo terá que usar uma abordagem diferente. Mas isso não está acontecendo com o JavaScript. Isso não aconteceu por anos, por que deveria acontecer com Flutter? Eles nem podem verificar. As pessoas estão pedindo esse recurso porque é útil. Você pode escrever pequenos módulos e atualizá-los dinamicamente. É uma virada de jogo. Você pode consertar um bug em um módulo na hora. Além disso, a Apple não pode realmente verificar o que um aplicativo está fazendo, pois não possui os recursos. Seria impossível, espero que você perceba. Além disso, qual é o ponto? Posso escrever um código obscuro e inserir um backdoor em um aplicativo, acionado quando forneço um JSON específico como resultado de uma chamada REST. Como a Apple poderá verificar isso? Não pode. Não há nada que a Apple ou o Android possam fazer para impedir isso. As pessoas precisam desse recurso e você deve implementá-lo. O que fazemos com ele é problema nosso, não seu. Você mesmo disse, este recurso tem mais de 500 gostei e mais de 100 participantes. Talvez seja hora de implementá-lo de acordo com a solicitação da comunidade.

@dedalozzo Ótimos argumentos novos!

Não faço parte da equipe de flutter, portanto, não me direcione para solicitar implementações.

Ainda assim, é verdade que a Apple e o Google podem não ter os recursos para detectar isso (a equipe de proteção de jogo está ativa o tempo todo, eles podem detectar comportamentos perigosos automaticamente), mas implementá-lo "pelas costas" agora dá à Apple um motivo real para aplicar uma proibição geral ao Flutter, já que basicamente _ vem com_ ferramentas que vão explicitamente contra suas políticas.

Você também pode enquadrá-lo como parte de uma questão ética (você deve implementar algo que adiciona riscos adicionais a um aplicativo e vai contra as políticas da loja, em nome do progresso?) Ou como uma questão de programação (você deve trabalhar em algo que tenha uma enorme cláusula " Se você usar isso, é provável que seja banido do app / play store ", que os usuários provavelmente vão querer evitar e desviar recursos de outras tarefas com um impacto seguro e garantido?).

Não apenas isso, mas violar acidentalmente a política da Play Store / estar relacionado a alguém que viola a política da Play Store basicamente significa ter sua conta banida, então seria brincar com fogo, tornando os usuários _ainda menos propensos a usar o recurso_.

Além disso, como afirmado acima, a distribuição fora da Play Store permite enviar APKs atualizados.

Sinto muito, pensei que você fosse um da equipe Flutter.

O que você disse em seu último comentário é verdade. Na verdade, o push de código parece ser tolerado pela Apple e pelo Google, mesmo sendo limítrofe e contra as regras.

Mas, contanto que seu aplicativo não cause nenhum dano, acho que eles nem vão se incomodar em verificar se você está realmente empurrando o código. Eles podem, se alguém relatar um comportamento estranho. Mas, nesse ponto, eles tomarão medidas contra o desenvolvedor do aplicativo, não contra os aplicativos inteiros que usam o código push.

É um trabalho em andamento, mas permite push de código https://github.com/chgibb/hydro-sdk

@chgibb Espere ... isso permite o push de código, mas também muda tudo de Dart para Typescript?

Existe uma maneira de separar essas duas coisas? Para obter o codepush ao escrever Dart como de costume?

@SpajicM que só funciona _porque_ não está usando Dart, em vez disso, provavelmente usa um mecanismo JS, como JavascriptCore, que é propriedade da Apple, e eles parecem olhar para o outro lado quando são usados ​​com push de código.

Raspe isso, ele usa o bytecode Lua, que é contra a política de armazenamento em todos os sentidos.

@miyoyo, por que isso é especificamente contra a política da loja?
@SpajicM é puramente aditivo. Peças datilografadas podem ser incorporadas em um aplicativo Dart maior. Tão pequeno quanto pedaços de texto ou telas inteiras.

É proibido pela política da loja enviar qualquer tipo de código compilado, dos quais .hc arquivos parecem ser, já que são bytecode lua compilados (talvez com extensões, não verificados).

O caso de uso específico de enviar código _compilado_ para aplicativos é explicitamente contra a política da Play Store e o elemento "nenhum código-fonte fornecido" que você _pode_ passar javascript, pois, no CodePush, não se aplicaria, violando as diretrizes da Apple .

Não estou dizendo que o conceito seja ruim, na verdade, é um ótimo trabalho! Acontece que baixar o bytecode pela Internet é explicitamente contra a política da loja em ambos os casos.

Como funcionam todos esses jogos para celular com suas atualizações no jogo? Eles apenas enviam / baixam ativos?

@miyoyo da 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...
Os arquivos .hc Hydro-SDK são bytecode Lua 5.2 puro, sem extensões ou recursos especiais. Eles são executados em um intérprete sem funcionalidade para automutação ou geração de código. Nada de dart:io é exposto a eles. Porém, não há nada que impeça um incorporador de expor dart:io da classe File , ou expor PlatformChannel s, por exemplo.

A seção 2.5.2 do Apple é um pouco mais ambígua no que diz respeito ao significado da palavra "executar", bem como na alteração de recursos ou funcionalidade.

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 Ok, eu diria que isso pode passar para o Android, embora eu ainda espere uma rejeição na App Store. (Para não dizer a redução no desempenho de pico, mas isso provavelmente é um detalhe em telefones de última geração)

As atualizações do jogo @kuhnroyal Mobile usam entrega dinâmica de ativos para coisas não executáveis , geralmente rastreadas porque exigem menos verificação, arquivos de expansão de APK que permitem fazer atualizações parciais, mas ainda estão sujeitos a ciclos regulares de atualização de loja e atualizações regulares de APK .

Falei com o cliente: manchete que isso não é mais uma prioridade para eles.

Você pode usar Localizely para atualizações over-the-air de textos / traduções: https://localizely.com/flutter-over-the-air

Para efeito de vibração, crie esse recurso ou nos oriente sobre como fazê-lo. obrigada .

Pessoal, _por favor_, é a terceira vez que isso é postado, mas _Não envie comentários, a menos que você realmente tenha algo a acrescentar_ .

Consulte esta postagem para mais detalhes e para colocar um polegar para cima na primeira postagem.

As mensagens não têm mais impacto, pois tenho certeza que a maioria da equipe aqui desativou as notificações para esta postagem, vamos manter o ruído baixo _a menos que você tenha algo a acrescentar_.

entretanto, alguma alternativa para push de código?

entretanto, alguma alternativa para push de código?

com base na minha experiência, não há alternativa

@samerdernaika @mfenej embora não esteja totalmente pronto para a produção, este projeto foi iniciado com push de código como uma meta explícita https://github.com/chgibb/hydro-sdk

@miyoyo

O primeiro, _what_ é empurrado, é onde reside o maior problema. As diretrizes de revisão da Apple proíbem qualquer tipo de push de código . Sim, a terminologia usada _também inclui push de código javascript. A Apple aparentemente não tomou medidas contra isso, e pode haver muitos motivos para isso, mas quaisquer motivos postados aqui seriam pura especulação.

Isso não é verdade. Por favor, verifique e não divulgue informações incorretas!

A seção 3.3.2 do contrato de licença de desenvolvedor da Apple afirma:

3.3.2 Exceto conforme estabelecido no próximo parágrafo, um Aplicativo não pode baixar ou instalar código executável. O código interpretado pode ser baixado para um Aplicativo, mas apenas enquanto tal código: (a) não alterar o objetivo principal do Aplicativo, fornecendo recursos ou funcionalidade que são inconsistentes com o propósito pretendido e anunciado do Aplicativo conforme submetido ao Aplicativo Loja, (b) não cria uma loja ou vitrine para outro código ou aplicativos e (c) não ignora a assinatura, sandbox ou outros recursos de segurança do sistema operacional.

Eles permitem muito especificamente o download de código interpretado como JS, desde que você não altere o objetivo principal do aplicativo. É assim há mais de 5 anos IIRC e nunca ouvi falar de alguém sendo puxado por usar o codepush de uma maneira normal e responsável.

Dê uma olhada na seção do AppCenter sobre codepush e conformidade com as diretrizes da loja. AppCenter codepush (apoiado pela Microsoft) é usado por muitos aplicativos sem problemas de conformidade da loja. https://github.com/microsoft/react-native-code-push#store -guideline-compliance

O grande bloqueador do codepush que vejo é que pode não valer a pena a compensação de desempenho de ser forçado a usar compilar para js ou Dart interpretado no iOS em vez de pré-compilado. Como o Flutter tem como alvo o navegador, suspeito que o desempenho de compilar para js seja bom o suficiente, mas talvez ainda não seja uma troca de desempenho aceitável para a equipe do Flutter.

Talvez uma solução de terceiros (como AppCenter for React Native) apareça e preencha essa lacuna. CodePush é super útil!

Hmm, uma rápida pesquisa no Google revela muitos exemplos de aplicativos de rejeição da Apple que incluem o recurso de envio de código, consulte, por exemplo

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

Dado que o tempo de análise da App Store agora quase sempre é medido em horas e não em dias, não entendo por que alguém se arriscaria. Se o push de código for integrado ao mecanismo Flutter, a Apple pode decidir banir todos os aplicativos Flutter.

@matthewlloyd, você está absolutamente certo de que o tempo de revisão caiu. Eu mesmo enviei um aplicativo (proprietário) para a App Store esta manhã e o tive aprovado no final do dia de hoje! Mas isso é _recentemente_. Nós, como editores de aplicativos móveis, ainda estamos em dívida com os caprichos / capacidade das equipes de revisão de revisar nossos envios.

Uma atualização que chega às mãos do seu usuário não viaja na velocidade da revisão do aplicativo. O tempo entre o "Lançamento do desenvolvedor", o "Processamento da App Store", a propagação para os servidores do mercado de usuários, etc, também pode levar algum tempo. Já vi esses estágios finais levarem mais de 24 horas em casos extremos.

Falando pessoalmente, minha paixão por push de código é assumir a responsabilidade sobre a cadeia de fornecimento de atualização de onde ela for. Sem mencionar os grandes obstáculos envolvidos na tentativa de automatizar o processo atual em uma configuração de CD coerente, dado o lamentável estado das ferramentas xcode CLI.

Menos de 24 horas na grande maioria dos casos é suficiente para quase todos, eu acho. Se você precisar obter uma atualização por meio do processo de revisão da Apple mais rapidamente do que isso, por exemplo, para uma correção de bug urgente, você pode solicitar uma revisão rápida. Eu fiz isso em uma ocasião, e a revisão do aplicativo foi concluída literalmente 10 minutos depois que fiz a solicitação.

Assumir a propriedade da cadeia de abastecimento de entrega é algo que se faz por sua própria conta e risco ...

Diretrizes da App Store da Apple, seção 2.5.2 (https://developer.apple.com/app-store/review/guidelines/#software-requirements):

"2.5.2 Os aplicativos devem ser autocontidos em seus pacotes e não podem ler ou gravar dados fora da área designada do contêiner, nem podem baixar, instalar ou executar códigos que introduzam ou alterem recursos ou funcionalidades do aplicativo , incluindo outros aplicativos. Os aplicativos educacionais projetados para ensinar, desenvolver ou permitir que os alunos testem o código executável podem, em circunstâncias limitadas, fazer o download do código, desde que tal código não seja usado para outros fins. Esses aplicativos devem tornar o código-fonte fornecido pelo Aplicativo completamente visível e editável pelo usuário. "

Requisitos do programa de desenvolvedor da Apple, seção 3.3.2:

3.3.2 Exceto conforme estabelecido no próximo parágrafo, um Aplicativo não pode baixar ou instalar código executável.

@AndrewMorsillo Não importa o que esteja em cada diretriz e não importa quantas informações sejam apresentadas, o melhor que podemos obter é "Talvez seja permitido, não temos certeza se não é uma ofensa que pode ser banida, na verdade pode ser que não temos certeza" .

Seja qual for o caso, Flutter não executa nenhum dard interpretado no iOS agora, acrescentando que seria um empecilho para o desempenho, e como você mesmo mencionou, além dos meus posts anteriores e do post de @matthewlloyd , está na melhor das hipóteses apenas permitido em alguns casos, em geral é uma área muito cinza e, na pior das hipóteses, é apenas banido.

Pelo que eu posso dizer, trocar tudo isso por contornar um ciclo de revisão de 24 horas e escrever testes não vale a pena. (Eu pude entender quando era uma semana, e isso geralmente apenas no lado do iOS, que é efetivamente o maior ponto de discórdia aqui)

Não se trata apenas do processo de revisão, mas também dos usuários que ficam presos em versões antigas do aplicativo porque podem ter desativado a atualização automática.

Claro, você pode implementar a verificação de versão mínima por conta própria, mas eles precisam acessar a Play Store novamente e as pessoas, infelizmente, são preguiçosas. Com o push de código, ele pode atualizar rapidamente o aplicativo a cada execução (espero) e permitir que o usuário entre com mais facilidade.

@miyoyo Não sei por que você está sentindo a necessidade de responder a cada comentário ou ideia que é apresentado aqui. As pessoas querem isso. Vocês disseram às pessoas para votar a favor da questão, e nós votamos até o topo. Isso nunca será resolvido, a menos que alguém pense ativamente sobre o assunto e o empurre.

Existe outra maneira de resolver isso. Eu tinha visto muitos aplicativos fazerem isso. App se fora
de data, pop up uma mensagem, você fecha-o ou atualiza o aplicativo. isso tudo.

Na sexta-feira, 7 de agosto de 2020 às 07:38, SpajicM [email protected] escreveu:

Não se trata apenas do processo de revisão, mas também dos usuários que obtêm
preso em versões antigas do aplicativo porque eles podem ter desligado o
atualização automática.

Claro, você pode implementar a verificação de versão mínima por conta própria, mas então eles
novamente tenho que passar pela Play Store e as pessoas são, infelizmente, preguiçosas. Com
push de código, ele poderia atualizar rapidamente o aplicativo em cada execução (espero) e
deixe o usuário entrar com mais facilidade.

@miyoyo https://github.com/miyoyo Não sei por que você está sentindo o
necessidade de responder a todos os comentários ou ideias aqui apresentados.
As pessoas querem isso. Vocês disseram às pessoas para votar a favor da questão, e nós votamos
todo o caminho até o topo. Isso nunca será resolvido a menos que alguém
pensa ativamente sobre isso e empurra-o.

-
Você está recebendo isto porque está inscrito neste tópico.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/flutter/flutter/issues/14330#issuecomment-670242698 ,
ou cancelar
https://github.com/notifications/unsubscribe-auth/ADS5AJFUU2V6MHQIP7AMZKLR7M5HPANCNFSM4EOFIZRA
.

Existe outra maneira de resolver isso. Eu tinha visto muitos aplicativos fazerem isso. Se o aplicativo estiver desatualizado, aparecerá uma mensagem pop-up, seja para fechá-lo ou para atualizá-lo. isso tudo.

Provavelmente a pior forma de UX ...: /

@SpajicM

Não se trata apenas do processo de revisão, mas também dos usuários que ficam presos em versões antigas do aplicativo porque podem ter desativado a atualização automática.

Claro, você pode implementar a verificação de versão mínima por conta própria, mas eles precisam acessar a Play Store novamente e as pessoas, infelizmente, são preguiçosas. Com o push de código, ele pode atualizar rapidamente o aplicativo a cada execução (espero) e permitir que o usuário entre com mais facilidade.

Em termos de UX, essa não é uma maneira _má_ de lidar com as atualizações? Se alguém desativa manualmente as atualizações automáticas, por que o Flutter deveria substituir isso? É discutível se algum aplicativo deveria ter esse poder, mas certamente não toda a estrutura.

Acho que centralizar o processo de atualização por meio das lojas de aplicativos é melhor para a experiência do usuário, uma vez que eles podem gerenciar todas as atualizações por meio da loja. UX às custas do tempo do desenvolvedor é meio que a essência do desenvolvimento de aplicativos. E se precisar de uma correção imediata (por exemplo, para uma vulnerabilidade), você pode obter uma atualização rápida ou se recusar a permitir que o usuário use o aplicativo até que ele seja atualizado. Claro que o último não é uma ótima opção, e o primeiro é irritante, mas isso porque a Apple e o Google estão colocando os usuários em primeiro lugar, e tem pouco a ver com o Flutter em si.

@chgibb

Falando pessoalmente, minha paixão por push de código é assumir a responsabilidade sobre a cadeia de fornecimento de atualização de onde ela for.

Este é o tipo de problema com este tópico - tentar fazer o que a Apple e o Google estão alertando fortemente não é uma boa ideia se você for usar as lojas de aplicativos deles. Como @miyoyo disse, é uma área cinzenta na melhor das hipóteses, o que não é exatamente adequado para uma estrutura usada pelo Google e outras empresas / indivíduos.

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

Na verdade, é https://github.com/microsoft/react-native-code-push

Bem, o Flutter ainda não consegue atualizar seu código, mas na verdade aquele link falava sobre imagens e me lembrou que o Firebase Remote config é uma coisa. A desvantagem é que você precisa antecipar quais bits de código podem precisar de alteração e esperar essas alterações em seu aplicativo, mas uma vez que isso seja feito, deve ser muito rápido implementar novas alterações sem a app store (semelhante ao que React Native Code Push faz com suas imagens)

@ardyfeb Pessoas como você dão má reputação à comunidade

Existe outra maneira de resolver isso
sem usar teia flutuante

Existe outra maneira de resolver isso. Eu tinha visto muitos aplicativos fazerem isso. Se o aplicativo estiver desatualizado, aparecerá uma mensagem pop-up, seja para fechá-lo ou para atualizá-lo. isso tudo.
…
Na sexta-feira, 7 de agosto de 2020 às 07:38, SpajicM @ . * > escreveu: Não se trata apenas do processo de revisão, mas também dos usuários que ficam presos em versões antigas do aplicativo porque podem ter desativado a atualização automática. Claro, você pode implementar a verificação de versão mínima por conta própria, mas eles precisam acessar a Play Store novamente e as pessoas, infelizmente, são preguiçosas. Com o push de código, ele pode atualizar rapidamente o aplicativo a cada execução (espero) e permitir que o usuário entre com mais facilidade. @miyoyo https://github.com/miyoyo Não sei por que você está sentindo a necessidade de responder a cada comentário ou ideia que é apresentado aqui. As pessoas querem isso. Vocês disseram às pessoas para votar a favor da questão, e nós votamos até o topo. Isso nunca será resolvido, a menos que alguém pense ativamente sobre o assunto e o empurre. - Você está recebendo isto porque está inscrito neste tópico. Responda a este e-mail diretamente, visualize-o no GitHub < # 14330 (comentário) > ou cancele a inscrição https://github.com/notifications/unsubscribe-auth/ADS5AJFUU2V6MHQIP7AMZKLR7M5HPANCNFSM4EOFIZRA .

Isso parece ótimo ... se você estiver criando aplicativos bancários.

Se alguém precisa de atualizações Over-the-air apenas para traduções de aplicativos, aqui está um exemplo de aplicativo Flutter: https://github.com/localizely/flutter-ota-sample-app

Parece que as diretrizes da apple são diferentes do que costumavam ser?

Isto ainda é o mesmo

2.5.2 Os aplicativos devem ser autocontidos em seus pacotes e não podem ler ou gravar dados fora da área designada do contêiner, nem podem baixar, instalar ou executar códigos que introduzem ou alteram recursos ou funcionalidades do aplicativo, incluindo outros aplicativos . Os aplicativos educacionais projetados para ensinar, desenvolver ou permitir que os alunos testem o código executável podem, em circunstâncias limitadas, fazer o download do código, desde que tal código não seja usado para outros fins. Esses aplicativos devem tornar o código-fonte fornecido pelo Aplicativo completamente visível e editável pelo usuário.

No entanto, não consigo encontrar nenhuma outra referência a código interpretado ou executável.

É possível que os detalhes sobre o ecossistema da maçã da postagem original não sejam mais verdadeiros, visto que eles não parecem mais dizer nada especificamente sobre linguagens interpretadas ou compiladas?