Alamofire Swift HTTP: De Biblioteca Essencial a Conveniencia Opcional

Respondi uma pergunta no Stack Overflow em Portugues sobre fazer requisicoes HTTP com Alamofire em Swift. Recebeu 5 votos — uma tarefa fundamental que todo desenvolvedor iOS precisava mas que a plataforma tornava surpreendentemente dificil na epoca.

Alamofire era a resposta porque as APIs nativas de rede eram dolorosas. Mas o Swift e o URLSession evoluiram tanto que o calculo mudou completamente.

O Problema de 2016: NSURLSession Era Verboso e Cheio de Callbacks

Fazer uma simples requisicao GET com NSURLSession no Swift 2 ficava assim:

// 2016: NSURLSession — rede verbosa baseada em callbacks
let url = NSURL(string: "https://api.example.com/users")!
let task = NSURLSession.sharedSession().dataTaskWithURL(url) {
    data, response, error in

    guard error == nil else {
        print("Erro: \(error!)")
        return
    }
    guard let data = data else {
        print("Sem dados")
        return
    }

    do {
        let json = try NSJSONSerialization.JSONObjectWithData(data, options: [])
        dispatch_async(dispatch_get_main_queue()) {
            // Atualizar UI aqui
        }
    } catch {
        print("Erro de JSON: \(error)")
    }
}
task.resume()

E muito codigo para “buscar JSON de uma URL.” A API do NSURLSession exigia verificacao manual de erros em cada etapa, parsing manual de JSON e dispatch manual de volta para a main thread. E voce tinha que lembrar do task.resume() — esquecer era um bug silencioso classico.

Alamofire simplificava tudo isso:

// 2016: Alamofire — API limpa e encadeavel
Alamofire.request(.GET, "https://api.example.com/users")
    .responseJSON { response in
        if let json = response.result.value {
            // Usar json
        }
    }

Tres linhas ao inves de quinze. Nao e a toa que todo mundo usava.

O Que Tornava Doloroso

A historia de networking no Swift inicial tinha varios problemas:

1. APIs Objective-C com prefixo NS — NSURL, NSURLSession, NSJSONSerialization pareciam estranhos em Swift. A API foi projetada para Objective-C e fazia uma ponte desajeitada
2. Sem Codable — Parsing de JSON significava trabalhar com AnyObject e fazer cast de tudo manualmente. Type safety, o maior trunfo do Swift, nao se aplicava a respostas de rede
3. Piramide de callbacks — Encadear requisicoes significava aninhar callbacks dentro de callbacks. Tratamento de erros em cada nivel era repetitivo e facil de esquecer
4. Gerenciamento de threads — Callbacks do URLSession rodavam em threads de background. Atualizar UI exigia dispatch_async(dispatch_get_main_queue()) toda santa vez

Alamofire nao era so uma conveniencia — era praticamente um requisito para escrever codigo de rede que fosse facil de manter.

A Abordagem de 2026: URLSession com async/await

async/await Nativo

O modelo de concorrencia do Swift mudou tudo:

// 2026: URLSession async/await — limpo e type-safe
struct User: Codable {
    let id: Int
    let name: String
    let email: String
}

func fetchUsers() async throws -> [User] {
    let url = URL(string: "https://api.example.com/users")!
    let (data, response) = try await URLSession.shared.data(from: url)

    guard let httpResponse = response as? HTTPURLResponse,
          httpResponse.statusCode == 200 else {
        throw NetworkError.badResponse
    }

    return try JSONDecoder().decode([User].self, from: data)
}

Uma funcao. Fluxo linear. Codable cuida do mapeamento JSON-para-struct. try await substitui callbacks aninhados. O compilador garante o tratamento de erros.

Concorrencia Estruturada

// 2026: Requisicoes paralelas com TaskGroup
func fetchDashboard() async throws -> Dashboard {
    async let users = fetchUsers()
    async let posts = fetchPosts()
    async let stats = fetchStats()

    return Dashboard(
        users: try await users,
        posts: try await posts,
        stats: try await stats
    )
}

Tres requisicoes paralelas, aguardadas juntas, com cancelamento automatico se alguma falhar. Tenta fazer isso de forma limpa com callbacks do Alamofire em 2016.

O Que Mudou

A plataforma fechou a lacuna. URLSession ganhou suporte a async/await, Codable eliminou parsing manual de JSON, e concorrencia estruturada tornou requisicoes paralelas triviais. Alamofire ainda existe e ainda agrega valor para casos avancados — politicas de retry, interceptadores de requisicao, certificate pinning — mas para requisicoes HTTP diretas, a stack nativa agora e limpa o suficiente para usar diretamente.

Aquela resposta no Stack Overflow direcionava desenvolvedores ao Alamofire porque era genuinamente a melhor escolha na epoca. A licao e que bibliotecas de terceiros frequentemente servem como pressao sobre os times de plataforma para melhorar suas APIs — e quando melhoram, a biblioteca se torna opcional.