Você já reparou que em todas as fotos de iPhones e Macs, o relógio marca 9:41?

Esse é o horário exato em que Steve Jobs apresentou o primeiro iPhone ao mundo, em 2007 .

Os Óculos da Lista de Leitura:

No Safari, o ícone dos óculos escuros que representa a “Lista de Leitura” (reading list) é idêntico ao modelo redondo que Steve Jobs usava como marca registrada

Emojis da Folha e Livro:

Você conseguirá ler o início do famoso texto da campanha “Here’s to the crazy ones”(Aos loucos). Uma homenagem à “Think Different”.

Comandos de Harry Potter na Siri

Chame a Siri e diga: “Lumos” ou “Nox”. A lanterna do iPhone liga ou desliga como se fosse magia.

O ícone do Mapa contém uma representação visual da sede da Apple:

Ao abrir o app Mapas, o ícone mostra um trecho de rodovia que, na verdade, é o caminho que leva ao Apple Park, em Cupertino.

Fontes:
easter-eggs-apple

https://mundobytes.com/pt/Os-melhores-truques-para-iPhone-que-quase-ningu%C3%A9m-usa./

https://t3n.de/news/apple-easter-eggs-versteckt-1674400/?utm_source=rss&utm_medium=newsFeed&utm_campaign=newsFeed

Você conhecia algum ou conhece outros? Eu sou uma pessoa curiosa né, e algumas coisas que descubro gosto de compartilhar.

Do primeiro plano à suspensão

No iOS, os apps passam por um ciclo de vida bem definido, composto por cinco estados fundamentais. Compreender essa jornada não é apenas importante para desenvolvedores: é a chave para criar aplicações inteligentes, que reagem adequadamente quando estão em primeiro plano, minimizadas ou até mesmo suspensas. Vamos explorar cada um desses estados e descobrir como eles influenciam o comportamento do seu app.

Not running (Não iniciado)

Este é o primeiro estado do aplicativo. O app ainda não foi aberto pelo usuário, ou seja, não foi lançado (launched) ou foi interrompido. Ele se encontra no estado ocioso, aguardando até que o usuário toque no ícone para iniciá-lo.

Situação: Você reinicia o seu iPhone. Quando o celular liga, tudo está limpo.

Estado: Todos os aplicativos do sistema estão no estado Not running. Nenhum app está em segundo plano ou ocupando memória. O WhatsApp só entrará em ação quando você tocar no ícone para abri-lo.

Inactive (Inativo)

O segundo estado ocorre quando você está usando um aplicativo e outra ação é sobreposta a ele, sem que o app seja fechado. Por exemplo: ao receber uma ligação ou bloquear a tela do telefone enquanto o aplicativo está em uso.

Situação: Você está assistindo a um vídeo no YouTube ou rolando o feed do Instagram. De repente, seu celular vibra e aparece a tela de “Chamada recebida” do seu operador (aquela tela verde ou vermelha) ocupando toda a tela, mas o vídeo continua rodando o áudio ao fundo ou o app fica “escondido”.

Estado: O Instagram/YouTube está no estado Inactive. Ele ainda está aberto, ainda está na memória, mas não está recebendo toques seus porque a tela de ligação está por cima. Ele está “inativo”, aguardando você atender, recusar ou a ligação terminar para voltar a ser o Active.

Active (Ativo)

Neste estado, o aplicativo está sendo executado em primeiro plano e interage diretamente com o usuário. Um exemplo é o próprio apli

Situação: Você está jogando Free Fire, Subway Surfers ou qualquer outro jogo. Seus dedos deslizam, tocam e fazem movimentos rápidos na tela, e o personagem responde na mesma hora.

Estado: O jogo está Active. Ele tem prioridade máxima do sistema, usando a GPU, processador e tela para entregar uma experiência fluida e sem atrasos.

Background (Em segundo plano)

Aqui, o aplicativo está “minimizado”, assim como uma aba no computador, mas ainda pode executar código “por trás”. Exemplos comuns incluem apps que utilizam geolocalização, como WhatsApp, Waze e Google Maps.

Situação: Você está dirigindo usando o Waze ou Google Maps para chegar a um destino. De repente, você recebe uma mensagem no WhatsApp e abre para responder. O mapa “some” da tela e agora você está no WhatsApp.

Estado: O Waze/Google Maps foi para o estado Background. Mesmo sem estar visível, ele continua executando código: a voz da navigação ainda fala “vire à esquerda em 200 metros” e ele continua atualizando sua localização para não te perder.

Suspended (Suspenso)

O último estado é o suspenso. O aplicativo permanece na memória, mas não é utilizado por um determinado período. Suponha que há três aplicativos abertos: um em primeiro plano e os outros dois em segundo. Esses dois estão ocupando memória, mas sem interações. Em seguida, o iOS analisa esses apps e move um deles para o estado suspenso, com base na ordem em que foram levados para o background.

Situação: Você pediu um iFood, acompanhou o entregador no mapa até o pedido chegar e, depois de receber a comida, minimizou o iFood e foi assistir Netflix.

Estado: O iFood agora está Suspended. Diferente do Background, ele NÃO está mais rastreando o entregador (porque o pedido já acabou). Ele está simplesmente “congelado” na memória, sem consumir CPU ou bateria. Se você abri-lo amanhã, ele ainda pode mostrar a última tela (se não tiver sido removido da RAM), mas não fez nada nas últimas horas.

Fonte: Medium — App States in iOS e Managing your app’s life cycle

Separei aqui os atalhos que mais uso no dia a dia 👇🏾

🧠 Refatoração e organização

⌃ + ⌘ + E → renomeia todas as ocorrências de uma variável/símbolo
⇧ + ⌃ + ⌘ + H → encontra os chamadores de um trecho de código
⌥ + ⌘ + ← / → → recolhe ou expande blocos de código

🐞 Execução e Debug

⌘ + Y → ativa/desativa breakpoints
⌘ + . → interrompe a execução
⌘ + ⇧ + Y → mostra/oculta a área de debug
⌘ + R → build e run
⌘ + \ → adiciona breakpoint na linha atual
⌘ + ⌥ + E → busca no arquivo atual

Produtividade na edição:
⇧ + ⌃ + ↑ → edição em múltiplas linhas
⌥ + ⌘ + [ / ] → move linha ou bloco para cima/baixo
⌘ + [ / ] → ajusta indentação
⌥ + ⌘ + / → gera documentação ///

🪟 Janelas e layout

⌃ + ⇧ + O → escolher destination (device)
⌘ + ⌥ + 0 → mostrar/ocultar utilities
⌘ + 0 → mostrar/ocultar sidebar
⌃ + 0 → escolher scheme

🧭 Navegação

⌘ + 1 → Project Navigator
⌘ + 2 → Source Control
⌘ + 4 → Search
⌘ + 5 → Issues
⌘ + 6 → Tests
⌘ + 7 → Debug
⌘ + 8 → Breakpoints
⌘ + 9 → Reports
⌘ + ⇧ + J → localiza o arquivo atual na sidebar
⌘ + ctrl + ← / → → navega entre abas abertas
⌘ + ⌃ + ← / → → volta ou avança entre arquivos
⌘ + L → vai para uma linha específica
⌘ + ⇧ + O → Open Quickly (arquivo, classe, símbolo…)
⌘ + , → Preferences
⌘ + ⇧ + , → Project Settings

Pequenas otimizações no uso da IDE economizam minutos todos os dias — e no fim do mês isso vira horas.

A praticidade de comprar online, pedir pra entregar em casa e etc… Vieram para nos ajudar e otimizarmos as compras e claro o nosso bolso. Pois comprar online ou as vezes pedir pra entregar em nossa casa, sai sempre mais em conta, certo?

Recentemente fiz uma compra, e me deparei que tinha meu cpf , nome completo e numero de telefone. Logo pensei: pra que tanta informação numa simples encomenda? E a resposta veio, e imaginei no óbvio! Ajudar a pessoa que realizará a entrega. Mas e do meu lado? O que posso fazer para proteger meus dados expostos após o recebimento da encomenda? Comecei a riscar essas informações antes de colocar no lixo e aconselho que faça o mesmo! Através dessa ação, você se protege.

Os Principais motivos

• 🕵️ Evita clonagem de identidade — pessoas com má intenção podem usar seu CPF e nome pra abrir contas ou fazer compras em seu nome.
• 📦 Protege seu endereço — alguém mal-intencionado pode descobrir onde você mora.
• 💳 Previne golpes financeiros — com CPF e telefone, é possível aplicar golpes e simular cadastros falsos.
• 📞 Evita contatos indesejados — seus dados podem parar em listas de spam, ligações e mensagens falsas.
• 🔐 Garante sua privacidade — quanto menos informação pessoal exposta, menor o risco de vazamento.
• 🚫 Impedir fraudes em devoluções — lojas ou terceiros podem tentar usar seus dados em pedidos falsos.
• 📬 Roubo de encomendas — golpistas podem rastrear seus pedidos e interceptar futuras entregas.
• 👤 Criação de perfis falsos — criminosos podem usar seus dados pra criar identidades falsas.
• 💻 Vazamento em bancos de dados ilegais — etiquetas descartadas são fontes de dados para hackers.
• ⚠️ Risco de engenharia social — quanto mais informações alguém tem sobre você, mais fácil te enganar em golpes personalizados.

Nunca jogue fora etiquetas com seu nome, endereço e CPF.

Rasure, corte ou destrua antes de descartar.

Seus dados pessoais são valiosos, e proteger é um ato de autocuidado.

Model-View-ViewModel é um padrão de arquitetura de software amplamente utilizado no desenvolvimento de aplicativos, especialmente em plataformas como iOS e Android. Ele separa os diferentes aspectos de uma aplicação para facilitar a manutenção, escalabilidade e testabilidade do código.

Responsabilidades individuais de cada camada

Model

Representa os dados e a lógica de negócios da aplicação. Ela gerencia a recuperação, manipulação e armazenamento de dados.

• São classes que encapsulam a lógica de negócios e os dados.
• Não referencia diretamente a View ou ViewModel
• Provê eventos de notificação de mudança de estado, através das interfaces
• Geralmente é utilizado, com um repositório: pode ser o Repository Pattern ou serviço

View

Sua responsabilidade é exibir a interface do usuário e interagir diretamente com o usuário.

• É um elemento visual
• O codebehind da view, define comportamentos visuais
• Referencia a ViewModel através da propriedade DataContext. Os controles da View são preenchidos com propriedades ou comando, expostos pela ViewModel

ViewModel

Atua como intermediário entre a View e o Model. Ele transforma os dados do Model em algo que a View pode exibir, além de lidar com a lógica da interface do usuário.

• É uma classe não visual, que expões para a View uma lógica de apresentação.
• É testável, independentemente da View ou Model.
• Coordena as intenções entre a View e o Model.
• Não referencia a View, na verdade não tem nenhum conhecimento sobre a mesma.

Fluxo de Comunicação

View → ViewModel:

• A View envia comandos de interações do usuário para o ViewModel.

ViewModel → Model:

O ViewModel processa os comandos e interage com o Model.

Model → ViewModel

• O Model notifica o ViewModel sobre mudanças nos dados.

ViewModel → View

• O ViewModel notifica a View para atualizar a interface.

Vantagens no uso

1. Separação de Responsabilidades

• Descrição: O MVVM divide claramente o código em três camadas: Model (dados e lógica de negócios), ViewModel (lógica de interface) e View (interface do usuário).
• Impacto: Facilita a organização do projeto, tornando mais simples localizar e corrigir problemas ou implementar novas funcionalidades.

2. Melhoria na Testabilidade

• Descrição: A lógica da aplicação está concentrada no ViewModel, que é independente da View e, portanto, mais fácil de testar com testes unitários.
• Impacto: Permite criar aplicativos mais robustos, com menos bugs e maior confiança nas funcionalidades implementadas.

3. Reutilização de Código

• Descrição: O ViewModel pode ser reutilizado em várias Views, especialmente em casos onde a lógica é a mesma, mas a apresentação visual muda.
• Impacto: Reduz redundâncias e acelera o desenvolvimento ao compartilhar a lógica em diferentes partes da aplicação.

4. Reatividade e Atualizações Automáticas

• Descrição: Frameworks como RxSwift, Combine ou bindings automáticos garantem que mudanças no Model sejam refletidas automaticamente na View por meio do ViewModel.
• Impacto: Melhora a experiência do usuário, garantindo interfaces sempre atualizadas sem necessidade de código adicional para sincronização.

5. Facilidade na Manutenção

• Descrição: Com cada camada focada em uma responsabilidade específica, o código se torna mais fácil de ler, manter e atualizar.
• Impacto: Equipes podem trabalhar em diferentes partes do projeto (Model, ViewModel, View) de forma independente, acelerando o desenvolvimento.

6. Modularidade

• Descrição: O MVVM incentiva a construção de módulos menores e mais independentes.
• Impacto: Torna mais simples implementar novas funcionalidades ou migrar partes do projeto para outras plataformas.

7. Escalabilidade

• Descrição: A arquitetura suporta bem o crescimento do projeto, tanto em número de funcionalidades quanto em complexidade.
• Impacto: Ideal para aplicativos grandes ou com longos ciclos de vida, onde requisitos podem mudar frequentemente.

8. Consistência com Ferramentas Reativas

• Descrição: MVVM integra-se bem com frameworks reativos (RxSwift, Combine), que simplificam o gerenciamento de eventos assíncronos e bindings.
• Impacto: Reduz a necessidade de callbacks e melhora a clareza do fluxo de dados na aplicação.

9. Maior Conformidade com Design Systems

• Descrição: O ViewModel pode implementar facilmente transformações de dados para adequar a View a design systems e guidelines específicas (como Apple Human Interface Guidelines).
• Impacto: Garante uma interface consistente e alinhada com padrões de usabilidade.

10. Desacoplamento entre Camadas

• Descrição: A View não precisa saber como os dados são gerados ou armazenados, e o Model não precisa conhecer os detalhes de apresentação.
• Impacto: Facilita a troca de tecnologias ou bibliotecas em uma camada sem afetar as demais.

Quando o MVVM é Mais Vantajoso:

• Projetos médios ou grandes, com interfaces complexas.
• Aplicativos que demandam atualizações frequentes ou reatividade.
• Equipes que desejam melhorar a testabilidade e manutenibilidade.
• Projetos com múltiplos desenvolvedores, onde divisão clara de responsabilidades é essencial.

Pontos ruins ao usar

1. Curva de Aprendizado

• Descrição: MVVM pode ser difícil de entender e implementar corretamente para desenvolvedores iniciantes, especialmente devido ao uso de frameworks reativos como RxSwift ou Combine.
• Impacto: Demanda tempo para aprender conceitos como data binding, programação reativa e a separação clara entre camadas.

2. Complexidade Adicional

• Descrição: O padrão pode introduzir complexidade desnecessária em projetos pequenos ou simples. Criar um ViewModel separado para cada View pode ser exagerado nesses casos.
• Impacto: Pode levar a mais código boilerplate (repetitivo) e estrutura desnecessária, dificultando a agilidade no desenvolvimento.

3. Dificuldade no Debugging

• Descrição: A separação entre View, ViewModel e Model pode dificultar o rastreamento de bugs, especialmente quando frameworks reativos estão envolvidos.
• Impacto: Erros em streams de dados reativos (como Combine ou RxSwift) podem ser difíceis de identificar, e rastrear a origem de mudanças no estado pode ser confuso.

4. Overhead de Manutenção

• Descrição: Em aplicativos grandes, manter ViewModels atualizados e sincronizados com as mudanças na View e no Model pode se tornar trabalhoso.
• Impacto: Alterações em requisitos podem exigir modificações significativas em várias camadas, tornando o processo mais demorado.

5. Uso Ineficiente de Recursos

• Descrição: ViewModels podem manter referências a objetos ou dados que não são mais necessários.
• Impacto: Isso pode levar a problemas como vazamentos de memória (memory leaks), especialmente se não houver um gerenciamento cuidadoso de ciclos de retenção (retain cycles) em frameworks como RxSwift.

6. Possível Redundância

• Descrição: Às vezes, o ViewModel pode acabar apenas repassando dados do Model para a View sem adicionar muita lógica ou transformação.
• Impacto: Isso cria uma camada adicional que não agrega valor real, tornando o código mais complicado sem benefício claro.

7. Foco Excessivo em Binding

• Descrição: O uso excessivo de data binding pode tornar o código difícil de compreender e manter.
• Impacto: Bugs ou comportamentos inesperados podem ocorrer devido a bindings mal configurados, e o código pode perder clareza.

Quando Evitar o MVVM:

• Projetos pequenos ou com interfaces simples.
• Equipes com pouca experiência no padrão ou em frameworks reativos.
• Aplicações com requisitos de prazo muito curto, onde a simplicidade e a velocidade são mais importantes.

Referências:
https://learn.microsoft.com/pt-br/dotnet/architecture/maui/mvvm

https://www.devmedia.com.br/entendendo-o-pattern-model-view-viewmodel-mvvm/18411

https://www.dio.me/articles/decifrando-a-arquitetura-mvvm-model-view-viewmodel

Eu só me dei conta da importância desse tópico depois que comecei aprofundar meus estudos em Swift. E achei muito interessante!

O controle de acesso restringe o acesso a partes do seu código a partir de código em outros arquivos-fonte e módulos. Esse recurso permite ocultar os detalhes da implementação do seu código e especificar uma interface preferencial por meio da qual esse código pode ser acessado e utilizado.

Você pode atribuir níveis específicos de acesso a tipos individuais (classes, estruturas e enumerações), bem como a propriedades, métodos, inicializadores e subscripts pertencentes a esses tipos. Protocolos podem ser restritos a um determinado contexto, assim como constantes, variáveis e funções globais.

Além de oferecer vários níveis de controle de acesso, Swift reduz a necessidade de especificar explicitamente os níveis de controle de acesso, fornecendo níveis de acesso padrão para cenários típicos. De fato, se você estiver desenvolvendo um aplicativo de único alvo, talvez nem precise especificar níveis de controle de acesso explicitamente.

Os três parágrafos acima, foi copiado da documentação do Swift.

O Swift oferece 5 níveis de acesso diferentes para entidades em seu código e esses níveis são relativos ao arquivo de origem, no qual uma entidade está definida e também em relação ao módulo ao qual o arquivo de origem pertence.

Open e o Public

São parecidos, ambos permitem que as entidades sejam usadas em qualquer arquivo de origem de seu módulo de definição e também em um arquivo de origem de outro módulo que importe o módulo de definição. Você normalmente usa acesso aberto ou público ao especificar a interface pública para uma estrutura.

Intern

Permite que as entidades sejam usadas em qualquer arquivo de origem de seu módulo de definição, mas não em nenhum arquivo de origem fora desse módulo. Você usa normalmente o acesso interno ao definir a estrutura interna de um aplicativo ou de uma estrutura.

Private

Restringe o uso de uma entidade à declaração anexa e às extensões dessa declaração que estão no mesmo arquivo. Use o acesso privado para ocultar os detalhes de implementação de uma funcionalidade específica quando esses detalhes forem usados apenas em uma única declaração.

Fileprivate

Restringe o uso de uma entidade ao seu próprio arquivo de origem de definição. Use o acesso privado ao arquivo para ocultar os detalhes de implementação de uma funcionalidade específica quando esses detalhes forem usados em um arquivo inteiro.

OBS: o Open tem o nível de acesso mais alto (menos restritivo) e o Private tem o nível mais baixo (mais restritivo).

Referências:
https://docs.swift.org/swift-book/LanguageGuide/AccessControl.html

https://www.hackingwithswift.com/read/0/19/access-control

https://www.swiftanytime.com/blog/access-control-in-swift

Escolher uma arquitetura para um projeto iOS depende de diversos fatores, como a complexidade do projeto, a experiência da equipe e as metas de manutenção e escalabilidade. Aqui está um guia para ajudá-la no processo:

1ª Analise as restrições

Data de entrega, regras de negócio e etc. São pontos que devem ser considerados antes de escolher uma arquitetura.

• Prazo curto: O uso de alguma arquiteura de fácil immplementação, como MVC ou uma variação leve de MVVM são aconselhados.
• Necessidade de refatoração futura: Prefira arquiteturas que suportem migração e modularização, como MVVM, MVVM-C e VIPER.

2ª Defina como serão os testes e a % mínima de cobertura de código

As arquiteturas MVVM, MVP, VIPER e MVVM-C facilitam a escrita de teses unitários devido à separação de camadas e responsabilidades:

• VIPER: Permite isolar cada componente (Interactor, Presenter, etc.).
• MVVM: Testes de ViewModel são diretos, especialmente com a ajuda de mocks.

3º Compreenda o escopo

• Projetos simples: poucas telas ou funcionalidades, arquiteturas como MVC ou MVP podem ser suficientes.
• Projetos mais complexos: muitas funcionalidades, modularização é possível considerar: MVP, VIPER ou MVVM-C.

4º Priorize manutenção e escalabilidade

• Separação de responsabilidades: O MVVM e VIPER oferecem maior separação de responsabilidades, tornando o código mais fácil de manter.
• Reutilização de código: A arquitetura MVVM com binders ou VIPER permitem modularizar partes do app, facilitando a reutilização.

5ª Considere ferramentas e frameworks

Hoje em dia é quase impossível não utilizar ferramentas ou frameworks para aprimorar o projeto ou uma feature. Considerar o uso desses dois pontos ajuda definir a arquitetura do projeto e além disso. Veja essas observações:

• MVVM: Combina bem com SwiftUI ou frameworks de binding como Combine/RxSwift.
• VIPER: Ideal para projetos com alto nível de modularização, mas pode introduzir complexidade extra.
• MVP: Útil quando há muita lógica na interface do usuário.

6º Verique a experiência da Equipe

• Se a equipe está mais familiarizada com uma arquitetura específica, isso pode ser um bom ponto de partida. Mas lembre-se de analisar os 5 pontos anteriores.

Prós e Contras das arquiteturas

Dicas para Implementação

• Comece com o básico e evolua: Se o projeto crescer, você pode refatorar para uma arquitetura mais robusta.
• Documente decisões: Explique por que escolheu a arquitetura para alinhar a equipe.
• Prototipe: Teste a arquitetura em uma funcionalidade pequena antes de aplicá-la a todo o projeto.
• Use boas práticas: Independente da arquitetura, siga princípios como SOLID, Adapter, Injeção de Dependência, Clean Swift e Clean Architecture para um código mais limpo.

Referências
https://www.tisdigitech.com/pt/blog/how-to-choose-the-right-mobile-app-architecture/
https://www.linkedin.com/advice/3/what-mobile-app-architecture-should-you-choose-hyl2c?lang=pt&originalSubdomain=pt
https://www.softplan.com.br/tech-writers/escolher-modelo-arquitetural-ideal/

Em fevereiro de 2021, o banco central anunciou o famosíssimo pix, como uma nova forma de movimentar dinheiro em território nacional. Com transferências em até 10 segundos.

Pagamentos via chaves, QRcode ou NFC

É permitido realizar pagamentos em lojas físicas ou digitais e também fazer transferências por meio de uma chave (que é o identificador) que cada pessoa/empresa deve possuir: pode ser chave aleatório, cpf/cnpj, e-mail ou número de telefone e essas transferências acontecem via chave, qrcode ou nfc.

Funcionamento de uma transação

Quando você quer pagar, o banco ao qual você irá fazer esse procedimento usa a sua chave através do rsfn, vai ao dict onde há o registro direto da chave.

Depois vai ao banco central, e busca a informação daquela chave

Após inserir a chave, o valor, ao clicar em realizar PIX, você informa ao banco que quer realizar uma transação (pagamento ou transferência)

Essa solicitação é recebida no banco central, com as suas informações e da conta que irá receber o valor. O banco central manda a notificação para a instituição que irá receber e se a instituição bancária responder “tudo ok, aceito a transação” o PIX é realizado, então gera o comprovante e cai na conta destino.

Tecnologias usadas no PIX

• Foi desenvolvido em java
• As mensagens chegam via http/https
• API usada é do tipo REST
• Criptografia de ponta a ponta
• Kafka para controlar o tráfego e pipelines
• Dict para realizar consultas feitas via http
• Banco de dados relacional, SQL

Fonte: https://www.bcb.gov.br/estabilidadefinanceira/pix

Possibilita os usuários instalarem aplicativos que não estão na App Store e realizar modificações para personalizar a aparência ou até mesmo aprimorar algumas funcionalidades do iPhone.

Não é ilegal

muitas empresas e pessoas vêem ele como ilegal, mas, na verdade, ão infringe nenhuma lei. No ano de 2012, a biblioteca do congresso dos Estados Unidos isentou iPhones com jailbreak do digital milennium copyright act o DMCA. Essa isenção tornou ele legal, mas para o iPad foi em 2025.

Viola os termos de uso estabelecidos pela Apple, ou seja, ela tem o direito de negar suporte e garantia do iPhone que esteja com essa versão modificada instalada.

Vantagens em usar

É possível instalar para chamadas, notificações, modificar ícones, aprimorar o safari, iMessage e também alterar a central de controle. Além disso, permite o usuário ter acesso a uma gama maior de aplicativos.

A maçã tem o controle muito rígido dos aplicativos em sua loja, a cada publicação ou atualização de um aplicativo. Ele sempre é revisado para se certificar que não possuam malware.

Os perigos

Caso o processo de recuperação do iPhone dê errado, o risco desse iPhone funcionar normalmente após é bem pouco. No entanto, o software do iPhone é corrompido e se isso acontecer, é provável que a Apple não consiga ajudar, pois, a garantia foi anulada quando você tentou instalar o jailbreak.

Além disso, se a instalação for bem sucedida, a preocupação será apenas com as atualizações do iOS. Pois, você não baixa diretamente da Apple e sim das pessoas desenvolvedoras do jailbreak e isso é um pouco demorado.

Referência: https://macmagazine.com.br/post/2022/02/20/ainda-vale-a-pena-fazer-jailbreak-no-iphone/

Não há interferências comprovadas

Segundo amaral, professor de engenharia elétrica da universidade presbiteriana mackenzie — upm, esclareceu que já passou o tempo em que uma aeronave poderia ter interferência de sinal nos sistemas de navegação por celulares, pois, quando o avião está no céu, ele geralmente está tão alto que você sai da área de cobertura.

O avião já avançou tanto, que acaba voando um nível cujo, problemas eletromagnéticos causados por um smartphone se torna mínimo e apesar de serem reduzidos, existem riscos causados pelo manuseio. A boeing já publicou um estudo em parceria com a us federal aviation administration (agência reguladora do setor nos EUA), afirmando ser impossível replicar, em laboratório, as supostas alegações de que laptop ou celulares interferiram nos equipamentos de navegação das aeronaves.

O modo avião serve para evitar acidentes

Por ser um objeto fácil de escapar das mãos, ainda é aconselhado utilizar o modo avião durante o voo para evitar que ele machuque uma pessoa. Seja durante uma turbulência ou até mesmo, durante o pouso e a decolagem. Que são situações onde a aceleração e a posição do avião muda de uma forma mais radical.

Se todo mundo estiver respondendo uma mensagem, em uma ligação ou entretido com um aplicativo, a equipe bordo precisaria aguardar até que o passageiro lhe desse atenção para definir qual prato ou bebida deseja na hora da refeição, por exemplo.

Além disso, há o incômodo sonoro ao longo da viagem. a acústica do avião não suportaria 200 pessoas falando simultaneamente.

Possíveis problemas em terra firme

O professor-chefe de aviação da cquniversity da austrália, Doug Drury, afirma que, em trechos de menor altitude, vários passageiros usando o celular simultaneamente podem sobrecarregar as torres de uma rede terrestre de telefonia. Além disso, o sistema de um celular funciona por torres espalhadas de um arranjo, espaçadas a tantos quilômetros, e cada região é chamada de célula (daí vem o nome celular).

O risco não é os passageiros intervirem no avião, e sim no sistema de telefonia das outras pessoas. Contudo, o problema não é nos céus: é na terra. A preocupação é que se essa radiofrequência for sobrecarregada por celulares em áreas próximas a aeroportos, ela poderia interferir na comunicação com os aviões. Porém, Drury afirma que ainda são necessários mais estudos para confirmar essa hipótese.

Referência: https://g1.globo.com/tecnologia/noticia/2023/08/27/modo-aviao-do-celular-por-que-e-preciso-ativar-o-recurso-durante-voos.ghtml