SwiftUI Após 7 Anos

Artigo original ↗ Discussão no Hacker News ↗

Sete anos após sua estreia, o framework SwiftUI da Apple é visto por muitos desenvolvedores como poderoso para interfaces declarativas simples, mas pouco confiável e insuficiente para apps complexos e sensíveis a desempenho, especialmente em comparação com UIKit/AppKit e padrões mais antigos de Cocoa. Os comentaristas destacam gerenciamento de estado opaco, fragilidade de layout, APIs ausentes ou instáveis e forte acoplamento a recursos em evolução da linguagem Swift como problemas centrais, enquanto uma minoria relata boas experiências nas versões mais recentes do SO e argumenta que ele é “bom o suficiente” se você aceitar seus trade-offs. O debate se amplia para preocupações sobre a direção de software da Apple, o custo das mudanças quebrando compatibilidade a cada ano e se alternativas como Flutter, Kotlin Multiplatform ou até stacks clássicas baseadas em Objective‑C agora oferecem um caminho mais sustentável.

A proposta de valor e a realidade do SwiftUI

  • Muitos veem o SwiftUI como ótimo para UIs simples, de “superfície”: listas, formulários, CRUD básico, ferramentas administrativas simples e efeitos visuais (blur, masks, views com suporte de Metal).
  • Para apps complexos (listas pesadas, layouts personalizados, navegação complexa, windowing sofisticado no macOS, animações precisas), as pessoas relatam problemas de desempenho, fragilidade de layout e muitos “escape hatches” para baixo até UIKit/AppKit.
  • Vários o chamam de “armadilha para iniciantes”: demos fáceis, trabalho real difícil. Bugs e comportamento estranho costumam surgir tarde em projetos maiores.

Estado, UI declarativa e arquitetura

  • Grande debate sobre declarativo‑reativo versus imperativo:
    • Defensores: estado como fonte da verdade e views declarativas reduzem bugs de lógica de atualização e facilitam os casos comuns.
    • Críticos: a reatividade do SwiftUI é opaca; o timing das atualizações de view é difícil de entender; @State/@Binding/@Observable e ferramentas como GeometryReader são vistos como “caixas‑pretas” propensas a armadilhas.
  • Um longo subthread revisita o MVC clássico: alguns argumentam que um MVC “adequado” já resolve a maioria dos problemas de sincronização de estado sem maquinaria reativa pesada; outros dizem que o próprio MVC tem problemas práticos (tempestades de eventos, batching de atualizações, desempenho de layout).

APIs, estabilidade e ferramentas

  • Reclamações frequentes sobre:
    • Trocas frequentes de API (por exemplo, APIs de navegação em evolução, sistemas de estado), condicionais por versão de SO e diferenças de comportamento entre versões do iOS.
    • Documentação fraca ou espalhada; dependência de vídeos da WWDC e blogs de terceiros.
    • Suporte fraco a depuração e profiling (inspeção da hierarquia de views, entendimento de re-renders), embora alguns mencionem suporte mais novo no Instruments.
  • Alguns argumentam que o SwiftUI é “muito bom” do iOS 26–27 em diante, se você puder abandonar suporte a versões antigas do SO; outros dizem que mesmo as versões atuais ainda apresentam engasgos e pesado uso de CPU em apps reais.

Swift, UIKit/AppKit e a cultura da Apple

  • Forte nostalgia por Objective‑C + Cocoa/AppKit/UIKit: vistos como elegantes, poderosos e mais adequados para apps nativos complexos; o Swift é visto por alguns como complicado demais e com apelo limitado fora das plataformas da Apple.
  • Outros dizem que o Swift é uma grande melhoria e agora sua principal linguagem em tudo; veem AppKit/UIKit como verbosos e datados.
  • Vários culpam a liderança e decisões orientadas por KPIs por lançar Swift/SwiftUI “pela metade” por uma década, em contraste com a era anterior do NeXT/Cocoa.

Alternativas e discussão cross-platform

  • Flutter, Kotlin Multiplatform + Compose, Qt, React Native, WPF, MAUI, HTML/CSS/JS são todos discutidos como alternativas, cada um com trade-offs diferentes.
  • Alguns agora preferem UIKit + assistentes de IA em vez de SwiftUI, argumentando que a IA corrói a vantagem do SwiftUI em “layout fácil”.
  • Consenso: não existe uma única “forma certa”; a escolha da ferramenta depende da complexidade do app, das plataformas-alvo e da tolerância aos quirks do SwiftUI.