DEV Community: Rafael Leandro

Gerenciando versões iOS automaticamente sem ferramentas externas

Rafael Leandro — Mon, 18 Nov 2024 15:31:30 +0000

TL;DR:

Vai, apressadinho: agvtool --help

Capítulo 1: Um longo esperado reencontro

Estava num pré-feriadão, tranquilo e feliz até precisar fazer uma release do SDK que mantenho no trabalho e o Fastlane estava quebrando o .xcodeproj.
Esse script recebia uma versão por parâmetro mas eu queria deixar isso totalmente automatizado no CI, aproveitei esse momento para começar a saga de reescrever tudo e resolver tanto o projeto corrompido, como automatizar o incremento da versão.

Capítulo 2: O Confronto com os Orcs

Utilizar Fastlane no meu contexto implica em gerenciar a versão do Ruby e do Fastlane, então novos desenvolvedores ou qualquer um do time que vá rodar o projeto precisariam configurar isso também, incluindo a máquina do CI.
Como eu preciso apenas fazer o archive e enviar o SDK, não é necessário o Fastlane, a solução escolhida foi fazer tudo em shell script mesmo.

Capítulo 3: A Chegada em Mordor

One script to rule them all

Dividi em 3 etapas:
1 - Descobrir a versão do projeto
2 - Fazer o incremento da versão, seguindo a lógica das versões anteriores
3 - Definir a versão no projeto

Aqui o primeiro passo é descobrir qual a versão atual do projeto e para isso usei o agvtool
Para pegar a versão do projeto utilizo o what-marketing-version e para pegar o build number what-version.
agvtool what-marketing-version

Em shell:

agv_output=$(agvtool what-marketing-version)
current_version=$(echo "$agv_output" | grep 'Found CFBundleShortVersionString' | head -n 1 | sed -E 's/.*of "([0-9]+\.[0-9]+\.[0-9]+)".*/\1/')
echo "$current_version"

Com o número da versão só fiz uma lógica para incrementar de acordo com o que meu projeto segue. Incrementa o patch até 9, depois passa para o minor até 9 e depois incrementa o major.

increment_version() {
    local version="$1"

    # Divide into (major, minor, patch)
    IFS='.' read -r major minor patch <<< "$version"

    # Increment the patch number, considering the limit of 9 
    if [ "$patch" -lt 9 ]; then
        ((patch++))
    else
        # If patch reaches 9, reset it to 0 and increment the minor number
        patch=0
        if [ "$minor" -lt 9 ]; then
            ((minor++))
        else
            # If minor reaches 9, reset it to 0 and increment the major number
            minor=0
            if [ "$major" -lt 9 ]; then
                ((major++))
            fi
        fi
    fi

    echo "$major.$minor.$patch"
}

E finalmente, para atualizar a versão:

version=$(get_version)
new_version=$(increment_version $version)
agvtool new-marketing-version $new_version

A importância de conhecer sobre UX como desenvolvedor e meu desespero na farmácia

Rafael Leandro — Sat, 04 May 2024 02:04:27 +0000

Introdução

Quando atuei na Involves, tive a oportunidade de trabalhar com o ~~Fábio~~ Eric Martins e pude conhecer sobre UX mais de perto, opinar (até demais às vezes), trabalhar pela primeira vez na construção de um design system do zero, experimentações e o conhecimento mais importante como desenvolvedor: Heurísticas de usabilidade. A experiência que tive na Involves, com o time de design trabalhando ao lado e não sendo um processo à parte, foi fundamental. Parei de ver o design como algo estético e comecei a vê-lo como algo funcional. Eu não estava desenvolvendo apenas uma interface bonita, estava fazendo um produto que passava segurança ao usuário, que entregava performance, que era, na medida do possível, intuitivo e que qualquer um podia utilizar sem um manual.
Pois bem, num belo fim de semana fui ao shopping e precisei pagar a minha conta na farmácia e o app do banco simplesmente não exibia nem o campo de senha e nem o botão para logar. Passado o desespero e medo de não conseguir pagar a conta, parei para entender o que estava acontecendo: Minha conexão estava ruim, o app estava demorando a se comunicar com o backend mas não tinha informação nenhuma sobre isso, fez um loading, entrou na tela de login e só exibia o campo de CPF. Então me lembrei das heurísticas de Nielsen e como essa situação poderia ter sido projetada.

Heurísticas de Nielsen

Jakob Nielsen e Rolf Molich propuseram 10 heurísticas que devem ser levadas em consideração no desenvolvimento de interfaces. Seria como regras gerais para reduzir a carga cognitiva do usuário para que a jornada dele seja mais leve e aprimorada. As 10 heurísticas de Nielsen são:

Visibilidade do status do sistema;
Correspondência entre o sistema e o mundo real;
Liberdade e controle do usuário;
Consistência e padrões;
Prevenção de erros;
Reconhecer ao invés de lembrar;
Flexibilidade e eficiência;
Estética e design minimalista;
Auxiliar usuários a reconhecer, diagnosticar e recuperar erros;
Ajuda e documentação.

O problema

O app bloqueia print, o mais próximo que consegui simular:

Com base nas heurísticas de Nielsen, temos aqui alguns problemas:

Visibilidade de estado do sistema
O sistema deve manter o usuário informado sobre o que está acontecendo, com feedback dentro de um tempo razoável. Por exemplo: Meu microfone, quando toco nele para mutar/desmutar ele fica aceso ou apagado, informando o estado. No caso do aplicativo, na abertura da tela o app apresenta um carregamento que deveria ser mantido até que realmente fosse concluído. Outro ponto foi o preenchimento do CPF, não houve qualquer feedback informando se eu tinha inserido um valor válido ou não, a impressão que tive foi que o CPF estava inválido e não liberou o campo de senha por isso.

Reconhecimento ao invés de memorização
Ao esconder elementos em determinados contextos, o usuário é forçado a lembrar de mais informações, teria que lembrar onde o campo ou botão foi parar, como fazer para exibi-lo novamente. Essa abordagem gera mais dificuldade do que benefício para segurança. É importante para o usuário saber que a opção existe e por que não está disponível naquele momento, por exemplo: Os campos de senha e login poderiam estar visíveis com o botão de login numa cor diferente indicando que está desabilitado e um texto próximo informando do problema de conexão.

Prevenção de erros
Todo esse cenário poderia ser evitado pensando na heurística de prevenção de erros. Melhor do que informar que o usuário cometeu um erro é impedir que ele cometa o erro.
Nesse caso, já que o carregamento não tinha sido concluído, a tela de loading não deveria desaparecer, liberando a alteração do CPF. Fazendo isso, o sistema permite que o usuário cometa um deslize, por exemplo, acabe digitando o CPF errado, desmarque o campo que mantém o CPF salvo e não tenha o CPF no momento. Prevenir erros é crítico para uma boa experiência e usabilidade.

E eu, como desenvolvedor, o que tenho a ver com isso?

Primeiramente, é importante que desenvolvedores e designers falem a mesma linguagem e tenham um entendimento comum do problema e da solução proposta. Conhecer as heurísticas, do ponto de vista de um desenvolvedor, ajuda a tomar decisões durante o desenvolvimento (conhecer os estados de tela também me ajudou muito). Entender que o design não é apenas estética garante que o time de desenvolvimento entregue um produto melhor, pensado no usuário.

Agradecimentos <3

Obrigado Ericão pelo trabalho em conjunto durante o tempo na Involves e por revisar esse texto.
Obrigado a minha digníssima Deborah por fazer o Pix me salvando na farmácia e por revisar o texto.

Como criar um emulador de jogos

Rafael Leandro — Wed, 31 Jan 2024 16:33:26 +0000

Introdução

Tem TL;DR nesse post não apressadinho(a), mas tu pode pular para o tópico "Arquitetura".

Quando eu era criança me lembro de achar em um dos computadores do laboratório de informática um emulador de GBA e uma ROM do Pokémon Yellow. Me lembro de ter feito uma cópia e levado pra casa, onde joguei por muitas horas.

Sempre fui uma criança curiosa, que gostava de saber como as coisas funcionam. Isso foi muito incentivado pelo meu avô, que me dava uma chave de fenda e alguns eletrônicos para desmontar. Essa curiosidade foi evoluindo depois que ele me deu meu primeiro computador, como o sistema operacional funciona? Como o emulador roda um jogo de um console? Eu consigo fazer um igual?

O tempo passou, aprendi a desenvolver, aprendi como muitas dessas coisas funcionam e hoje resolvi compartilhar um pouco das minhas anotações de como um emulador funciona.

CHIP-8

O escolhido foi o CHIP-8, uma linguagem de interpretação criada nos anos 70 por Joseph Weisbecker. Foi utilizado para desenvolver jogos simples e ferramentas educacionais, hoje é conhecido por ser fácil de implementar e é frequentemente usado como uma introdução à emulação de sistemas mais complexos.

Arquitetura

As informações de arquiteturas são muito importantes, os valores serão utilizados no código!

Memória

Tem um total de 4.096 bytes (ou 4KB), mas desse total, os primeiros 512 bytes são reservados para o sistema.

Registradores

Registradores são pequenas unidades de armazenamento dentro da CPU. São utilizados para realizar operações aritméticas, armazenar endereções e etc.
Essa é uma parte importante do que será desenvolvido.

Os tipos de registradores encontrados no CHIP-8:

Registradores de uso Geral (V0 a VF): a. Possui 16 registradores de uso geral, numerados de V0 a VF. b. Cada registrador é 1 byte (8 bits) e pode armazenar valores de 0 a 255.
Registrador de uso de memória (I):
1. O registrador I é um registrador de 16 bits utilizado para armazenar endereços de memória.
Registrador do ponteiro de programa (PC):
1. É um registrador de 16 bits que armazena o endereço da próxima instrução que vai ser executada.
Registrador de ponto de retorno (Stack e SP):
1. O CHIP-8 possui uma pilha para armazenar o endereço de retorno durante chamadas de blocos (sub-rotinas)
2. O registrador SP registra a posição atual na pilha
Registradores de estado (VF):
1. É utilizado como registrador de flags
2. Algumas instruções modificam esse registrador para indicar condições especificas, como carry em operações de adição. Esses registradores são cruciais para a implementação do emulador, eles que fornecem a capacidade de armazenar e manipular dados, controlar os fluxos de execução e interagir com a memória, algumas coisas ficam mais claras com a implementação dó código.

Instruções

As instruções são operações que a CPU, no caso o CHIP-8, consegue executar. Cada instrução é uma ação específica que a CPU deve realizar. Deixei pra apresentar a lista um pouco mais a frente, pra evitar sustos ainda nos conceitos.

Ciclo de máquina

O ciclo pode ser resumido em poucos passos:

Lê a instrução no endereço apontado pelo PC
Decodifica a instrução para determinar qual operação deve ser executada.
Executa a operação.
Atualiza o PC para apontar para a próxima instrução.
Volta para o passo 1 e repete o ciclo até o termino do programa.

Desenvolvendo o emulador

Vou utilizar Swift, simplesmente porque é a linguagem que mais uso no dia-a-dia e tem uma leitura muito simples. Já desenvolvi o emulador em C++ mas a leitura pode ser um pouco mais complexa pra quem não conhece a linguagem. Aqui não vou falar sobre padrões de projeto, nem definir arquitetura do software, tudo vai ser feito pensando apenas na facilidade de leitura. Escolha a linguagem e adapta tudo pra ela :)

Agora sabendo da arquitetura é preciso implementar os registradores, emular a memória, decodificar as instruções e implementar o ciclo de máquina.

Primeiro os registradores. Criei uma classe com as variáveis para armazenar os registradores e uma função para incrementar o PC.



class Registers {
    // Registradores de Uso Geral (V0 a VF)
    var V: [UInt8] = [UInt8](repeating: 0, count: 16)

    // Registrador de Endereço de Memória (I)
    var I: UInt16 = 0

    // Registrador do Contador de Programa (PC)
    var PC: UInt16 = 0x200  // Valor inicial por convenção

    // Registrador do Ponteiro da Pilha (SP)
    var SP: UInt8 = 0

    // Método para incrementar o Contador de Programa
    func incrementPC() {
        PC += 2 // O valor aqui é 2 porque as instruções são de 2 bytes
    }
}

Implementação da memória



import Foundation

class Memory { 
    // Tamanho da memória do CHIP-8 (4KB)
    static let memorySize: Int = 4096

    // Memória do CHIP-8
    private var memory: [UInt8]

    init() {
        memory = [UInt8](repeating: 0, count: Chip8Memory.memorySize)
    }
}

Decodificando as instruções

Essa é a parte mais importante e trabalhosa de se fazer, decodificar e implementar as instruções é a parte central do emulador.

O CHIP-8 possui um conjunto de 35 instruções, aqui uma tabela com as instruções e sua representação

Código	Instrução	Descrição
00E0	CLS	Clear the display.
00EE	RET	Return from a subroutine.
1nnn	JP addr	Jump to location nnn.
2nnn	CALL addr	Call subroutine at nnn.
3xkk	SE Vx, byte	Skip next instruction if Vx == kk.
4xkk	SNE Vx, byte	Skip next instruction if Vx != kk.
5xy0	SE Vx, Vy	Skip next instruction if Vx == Vy.
6xkk	LD Vx, byte	Set Vx = kk.
7xkk	ADD Vx, byte	Set Vx = Vx + kk.
8xy0	LD Vx, Vy	Set Vx = Vy.
8xy1	OR Vx, Vy	Set Vx = Vx OR Vy.
8xy2	AND Vx, Vy	Set Vx = Vx AND Vy.
8xy3	XOR Vx, Vy	Set Vx = Vx XOR Vy.
8xy4	ADD Vx, Vy	Set Vx = Vx + Vy, set VF = carry.
8xy5	SUB Vx, Vy	Set Vx = Vx - Vy, set VF = NOT borrow.
8xy6	SHR Vx {, Vy}	Set Vx = Vx SHR 1.
8xy7	SUBN Vx, Vy	Set Vx = Vy - Vx, set VF = NOT borrow.
8xyE	SHL Vx {, Vy}	Set Vx = Vx SHL 1.
9xy0	SNE Vx, Vy	Skip next instruction if Vx != Vy.
Annn	LD I, addr	Set I = nnn.
Bnnn	JP V0, addr	Jump to location V0 + nnn.
Cxkk	RND Vx, byte	Set Vx = random byte AND kk.
Dxyn	DRW Vx, Vy, nibble	Display nibble-byte sprite at memory location I at (Vx, Vy), set VF = collision.
Ex9E	SKP Vx	Skip next instruction if key with the value of Vx is pressed.
ExA1	SKNP Vx	Skip next instruction if key with the value of Vx is not pressed.
Fx07	LD Vx, DT	Set Vx = delay timer value.
Fx0A	LD Vx, K	Wait for a key press, store the value of the key in Vx.
Fx15	LD DT, Vx	Set delay timer = Vx.
Fx18	LD ST, Vx	Set sound timer = Vx.
Fx1E	ADD I, Vx	Set I = I + Vx.
Fx29	LD F, Vx	Set I = location of sprite for digit Vx.
Fx33	LD B, Vx	Store BCD representation of Vx in memory locations I, I+1, and I+2.
Fx55	LD [I], Vx	Store registers V0 through Vx in memory starting at location I.
Fx65	LD Vx, [I]	Read registers V0 through Vx from memory starting at location I.
Fx75	LD R, Vx	Store V0 through Vx in the RPL user flags.

Implementei uma classe que vai ficar responsável por isso



class Instructions {

    let registers: Registers

    init(registers: Registers) {
        self.registers = registers
    }

    func executeInstruction(withOffset offset: UInt16) {
        let opcodeType = (opcode & 0xF000) >> 12
    }
}

(opcode & 0xF000): Realiza uma operação bitwise AND entre opcode e a máscara 0xF000.
Operações bitwise são utilizados quando precisamos realizar operações em nível de bits. O operador & (AND) compara dois valores utilizando suas representações binárias, cada bit é comparado e retorna 1 quando os bits forem iguais, caso contrário retorna 0.

>> 12: Desloca para a direita 12 posições, movendo o resultado para as posições mais baixas , sendo os bits menos significativos do resultado (LSB).

Com esse valor, é possível saber qual o tipo de instrução deve ser executada.



switch opcodeType {
    case 0x0:
            if opcode == 0x00E0 {
        // CLS - Clear the display
      }
    default:
            break
}

Na tabela de instruções 00E0 representa a instrução para limpar a tela, então aqui deve se implementar a chamada para esse método.

E para cada uma das instruções deve ser feito isso. Como o código ficaria muito grande e esse texto já está maior do que eu esperava, o link para o repositório do Github com o projeto vai está disponível (assim espero) no fim do artigo.

Ciclo de máquina

Fiz uma classe responsável por centralizar tudo, a inicialização da memória, dos registradores e das instruções. Essa classe também vai controlar o ciclo de máquina, que como visto anteriormente: Lê e decodifica a instrução, executa a operação e atualiza o PC.



class Chip8Cpu {
    var registers: Registers
    var instructionDecoder: Instructions
    var memory: Memory

    class Chip8Cpu {
    var registers: Registers
    var instructionDecoder: Instructions
    var memory: Memory

    func runCycle() {
        let opcode = registers.pc
        instructionDecoder.executeInstruction(registers: &registers, opcode: opcode)
        registers.incrementPC()
    }
}

Renderização gráfica

E por fim, a parte mais especifica de cada plataforma. Na primeira versão que fiz, desenvolvendo em C++ foquei em desenvolver algo multiplataforma, então usei o GLUT para a parte gráfica. Mas aqui o objetivo é explicar o funcionamento, então

A tela do CHIP-8 é uma matriz de 64x32 pixels, esse pixel pode estar ligado ou desligado. Na implementação caso o pixel esteja desligado tem a cor preta, se estiver ligado tem a cor branca.



func renderScreen() {
        for row in 0..<32 {
            for col in 0..<64 {
                let pixelValue = registers.screen[col, row]
                print(pixelValue == 1 ? "[*]" : "[ ]", terminator: "")
            }
            print()
        }
    }

Essa função exibe [*] quando desligado e [ ] ligado. Aqui deve ser implementada a view na plataforma escolhida.

Agora já é possível testar o que foi feito, basta apenas carregar a rom na memória, passando a URL do arquivo:



let romData = try Data(contentsOf: url)
let romBytes = [UInt8](romData)
registers.memory.replace(subrange: 512..<(512 + rom.count), collection: romBytes)

Por convenção a rom é carregada a partir do byte 512.
O resultado é a tela abaixo:

O CHIP8 possui também um conjunto fixo de sprites que representam os números em hexadecimal.



struct Font {
    static let FontSet: [UInt8] = [
        0xF0, 0x90, 0x90, 0x90, 0xF0, // 0
        0x20, 0x60, 0x20, 0x20, 0x70, // 1
        0xF0, 0x10, 0xF0, 0x80, 0xF0, // 2
        0xF0, 0x10, 0xF0, 0x10, 0xF0, // 3
        0x90, 0x90, 0xF0, 0x10, 0x10, // 4
        0xF0, 0x80, 0xF0, 0x10, 0xF0, // 5
        0xF0, 0x80, 0xF0, 0x90, 0xF0, // 6
        0xF0, 0x10, 0x20, 0x40, 0x40, // 7
        0xF0, 0x90, 0xF0, 0x90, 0xF0, // 8
        0xF0, 0x90, 0xF0, 0x10, 0xF0, // 9
        0xF0, 0x90, 0xF0, 0x90, 0x90, // A
        0xE0, 0x90, 0xE0, 0x90, 0xE0, // B
        0xF0, 0x80, 0x80, 0x80, 0xF0, // C
        0xE0, 0x90, 0x90, 0x90, 0xE0, // D
        0xF0, 0x80, 0xF0, 0x80, 0xF0, // E
        0xF0, 0x80, 0xF0, 0x80, 0x80  // F
    ]
}

Antes do carregamento da ROM é só adicionar as fontes na memória



registers.memory.replace(subrange:0..<Font.FontSet.count, collection: Font.FontSet)

E agora as fontes são carregadas:

Para mapear os controles basta implementar as instruções no offset 0xE e com isso temos um emulador CHIP-8 com o funcionamento básico.

Evitando conflitos no Xcode

Rafael Leandro — Fri, 15 Oct 2021 00:32:13 +0000

Introdução

O objetivo desse texto é mostrar como resolvi alguns problemas no meu time utilizando o Tuist para gerar projetos e workspaces do Xcode e que com isso nós evitamos conflitos na hora do merge, resolvemos problemas para gerenciar dependências e também podemos padronizar configurações dos projetos e abrir individualmente o projeto que vai ser alterado (modo foco).

Instalação

A instalação é muito simples, basta executar o comando no terminal:
curl -Ls https://install.tuist.io | bash

Criando um projeto novo

Se for um novo projeto a utilização do Tuist é super simples.
Basta criar uma pasta e executar o tuist init

mkdir MyApp
cd MyApp
tuist init --platform ios

O comando init irá gerar os arquivos base, Info.plist, AppDelegate.swift, arquivos de teste e o Project.swift que contém as configurações do projeto.

Migrando um projeto existente

A migração no meu caso foi tranquila porque o projeto é simples e tenho um Workspace com vários projetos que dependem do Core e uma única dependência externa em um Target de teste.

Comecei migrando o Core, porque precisava definir a dependência dele nos outros projetos, resolvi todas as outras dependências e por último configurei o Workspace.
Na pasta de cada projeto criei o arquivo Project.swift, no diretório raíz o Workspace.swifte a pasta Tuist com o arquivo Dependencies.swift

Configurações do projeto

O Project.swift contém a configuração do projeto. É nesse arquivo onde são definidos nome, organização, targets, schemas, entre outras coisas.

Comecei fazendo o import do framework ProjectDescription esse arquivo deve inicializar uma variável do tipo Project que pode ter qualquer nome, mas a recomendação da documentação é nomear como project mesmo.

Um project precisa obrigatoriamente dos parâmetros: name e targets que é um array do tipo Target.

No Target é especificado o nome, plataforma, tipo do produto, bundle e os arquivos de código.

let target = Target(name: "App",
                    platform: .iOS,
                    product: .app,
                    bundleId: "com.rafa.example",
                    infoPlist: "Info.plist",
                    sources: "Sources/**",
                    dependencies: [])

let project = Project(
    name: "MyProject",
    targets: [target]
)

Dependências externas

A integração com dependências externas ainda está em alpha, como é avisado na documentação

No momento que estou escrevendo esse texto a integração com Cocoapods ainda não é suportada.

Cada projeto pode ter suas dependências configuradas individualmente, basta criar a pasta Tuist com o arquivo Dependencies.swift dentro dela.
No meu caso, fiz isso na pasta raiz do projeto porque tenho uma única dependência externa.

import ProjectDescription

let dependencies = Dependencies(
    carthage: [
        .github(path: "Alamofire/Alamofire", requirement: .exact("5.0.4")),
    ],
    swiftPackageManager: [
        .remote(url: "https://github.com/Alamofire/Alamofire", requirement: .upToNextMajor(from: "5.0.0")),
    ],
    platforms: [.iOS]
)

Feito isso baixe as dependências rodando
tuist dependencies fetch. Uma pasta chamada Dependencies será criada e o código será baixado nela.

De volta ao Project.swift é necessário registrar no Target a dependência baixada.

let target = Target(name: "App",
                    platform: .iOS,
                    product: .app,
                    bundleId: "com.rafa.example",
                    infoPlist: "Info.plist",
                    sources: "Sources/**",
                    dependencies: [
                .external(name: "Alamofire"),
            ])

Configurações do Workspace

Por padrão o tuist generate cria um Workspace com o mesmo nome do projeto e já inclui as dependências.
No meu caso os projetos estão num monorepo, então preciso configurar um Workspace e adicionar todos os projetos nele.

import ProjectDescription

let workspace = Workspace(
    name: "ProjectWorkspace",
    projects: [
        "Project1",
        "Project2",
        "Project3"
    ],
    schemes: []
)

Por padrão os schemas são gerados automaticamente, mas podem ser personalizados para configurar as ações de cada um.

Gerando os arquivos

A configuração é essa, dependendo do tamanho do projeto pode ser um pouco cansativa mas os ganhos são compensatórios.

Depois de tudo configurado, é só rodar o tuist dependencies fetch para baixar as dependências e depois tuist generate para gerar os projetos/workspaces.

Testei outras ferramentas mas resolvi adotar o Tuist por utilizar Swift e não Yaml, possibilidade de fazer cache dos módulos, cache dos testes, screenshot de dependências e por considerar a adoção fácil no projeto em que trabalho.
Finalizei implementando o xcdiff evitando que o .xcodeproj fosse alterado manualmente.

E é isso! :)

Links úteis

Tuist.io
Tuist docs
xcdiff

Swift além do iOS e do macOS - Parte 1

Rafael Leandro — Thu, 15 Jul 2021 14:26:41 +0000

Eu trabalho com desenvolvimento iOS e não costumo fazer nada no backend, o que é um problema em projetos pessoais. Não quis investir tempo estudando JS e seus frameworks (não tenho nem espaço pro cache do npm) e comecei a procurar uma solução mais prática, foi aí que encontrei o Vapor.

Instalação

🍎 A instalação do Vapor é feita através do homebrew

$ brew install vapor

Para ter certeza que a instalação foi feita corretamente:

$ vapor

E essa deve ser a saída:

Usage: vapor <command>

Vapor Toolbox (Server-side Swift web framework)

Commands:
       build Builds an app in the console.
       clean Cleans temporary files.
      heroku Commands for working with Heroku
         new Generates a new app.
         run Runs an app from the console.
             Equivalent to `swift run --enable-test-discovery Run`.
  supervisor Commands for working with Supervisord
       xcode Opens an app in Xcode.

Use `vapor <command> [--help,-h]` for more information on a command.
Error: Missing command

🐧 No Linux é necessário que o Swift 5.2 (ou superior) esteja instalado.
A instalação é feita compilando o toolchain.

git clone https://github.com/vapor/toolbox.git
cd toolbox
git checkout <versao>
make install

Hello, Vapor.

Criando um novo projeto:

vapor new first-project -n
cd first-project

A flag -n responde não automaticamente para todas as perguntas feitas depois de clonar o template.

Rodando o primeiro projeto:
🍎 no macOS

vapor xcode

🐧 no Linux

swift run

Se tudo ocorrer bem, a saída no console deve ser essa:

[ INFO ] Server starting on http://127.0.0.1:8080

E pra testar, basta abrir o endereço no navegador.