Pular para o conteúdo principal

Como Desenvolvemos Software para Cada Plataforma

Por que um .exe não roda no Linux

Cada sistema operacional define seu próprio formato de executável — a estrutura binária que diz ao kernel como carregar o programa na memória, onde fica o código, onde ficam os dados, e quais bibliotecas ele precisa. São três formatos incompatíveis entre si:

SOFormato de executávelExtensão típica
WindowsPE (Portable Executable).exe, .dll
Linux / AndroidELF (Executable and Linkable Format)sem extensão, .so
macOS / iOSMach-O.app (pacote), .dylib

Um .exe compilado para Windows contém instruções de máquina x86/x64 empacotadas no formato PE — o kernel Linux simplesmente não sabe interpretar esse cabeçalho, mesmo que a CPU seja a mesma. É por isso que rodar software Windows no Linux exige uma camada de tradução como o Wine, e não apenas "copiar o arquivo".


SDKs e ferramentas nativas por plataforma

PlataformaIDE/Toolchain principalLinguagens nativasAPI/Framework do SO
WindowsVisual Studio, MSVCC++, C#, RustWin32 API, .NET, WinRT/UWP
LinuxGCC/Clang, qualquer editorC, C++, Rust, PythonPOSIX, GTK, Qt
macOSXcodeSwift, Objective-CCocoa (AppKit)
AndroidAndroid StudioKotlin, Java, C/C++ (via NDK)Android SDK
iOSXcodeSwift, Objective-CUIKit / SwiftUI

Escrever um app "nativo" significa usar diretamente essas APIs — o resultado tem o melhor desempenho e a integração mais fiel com o sistema (notificações, atalhos, aparência), mas o código não roda em nenhuma outra plataforma sem reescrita.


Compilação nativa vs. execução gerenciada (managed)

  • Nativo: o compilador (GCC, Clang, MSVC) traduz o código-fonte diretamente para instruções da CPU alvo, embaladas no formato de executável do SO. Roda sem camada intermediária — mais rápido, mas precisa ser recompilado para cada combinação de SO + arquitetura de CPU.
  • Gerenciado (managed): o compilador gera um bytecode intermediário, independente de CPU, que roda dentro de uma máquina virtual (JVM para Java, ART para Android/Kotlin, CLR para C#/.NET). A promessa histórica do Java — "escreva uma vez, rode em qualquer lugar" — vem exatamente daqui: o mesmo .class roda em qualquer SO que tenha uma JVM instalada.

Frameworks multiplataforma (cross-platform)

Reescrever o mesmo app 5 vezes (uma por SO) é caro. Por isso existem frameworks que compartilham código entre plataformas, com diferentes trade-offs entre desempenho e reaproveitamento:

FrameworkComo funcionaReaproveitamentoDesempenho
ElectronEmpacota um navegador Chromium + Node.js; a interface é HTML/CSS/JSAltíssimo (desktop)Baixo (consome muita RAM)
Qt / GTKBiblioteca de UI nativa em C++, compilada para cada SOAlto (código C++ comum)Alto (nativo de verdade)
FlutterMotor gráfico próprio (Skia) desenha a UI pixel a pixel, mesmo código Dart para todas as plataformasMuito altoAlto
React NativeLógica em JavaScript, mas a UI é traduzida para componentes nativos reais do SOAltoMédio-alto
.NET MAUI / Kotlin MultiplatformCompartilha lógica de negócio; UI pode ser nativa por plataformaMédio-altoAlto
Não existe "o melhor" — existe o trade-off certo para o projeto

Um app bancário que precisa de máxima confiança de UI tende a ir nativo (Swift + Kotlin separados). Um app interno de produtividade, onde velocidade de entrega importa mais que desempenho máximo, se beneficia de Flutter/React Native/Electron.


Distribuição: como o software chega ao usuário

SOFormato de instalador tradicionalLoja oficialInstalação fora da loja
Windows.exe, .msiMicrosoft StoreSim, livre
Linux.deb, .rpm, ou formatos universais Flatpak/Snap/AppImageDepende da distro (repositórios)Sim, livre
macOS.dmg, .pkgMac App StoreSim, mas exige assinatura/notarização (Gatekeeper)
Android.apk diretoPlay StoreSim (com aviso de segurança)
iOSApp StoreNão, salvo exceções regionais recentes

Quanto mais uma plataforma restringe a instalação a uma loja única (iOS, e cada vez mais macOS), mais o fabricante consegue revisar o software antes que chegue ao usuário — trocando liberdade do desenvolvedor por uma camada extra de curadoria e segurança.


Próximo: Drivers e Bibliotecas

Todo esse software — nativo ou gerenciado — eventualmente precisa falar com o hardware de verdade. É aí que entram drivers e bibliotecas compartilhadas.

➡️ Drivers e Bibliotecas →