Apple pulseira sem ecrã: o que muda no HealthKit para devs

Quando li a notícia no Sapo.pt sobre a Apple estar a desenvolver uma pulseira sem ecrã para desafiar a Whoop, a primeira coisa que pensei não foi “mais um wearable”. Foi: finalmente estão a tratar sensores de saúde como infraestrutura, não como gadget. E isso muda tudo para quem constrói software em cima desse ecossistema.

Ainda em fase de protótipo, longe de lançamento (só a partir de 2028, segundo a Bloomberg), o projeto tem assinatura do Tim Cook e do Eddy Cue, com engenharia dos Vision Pro a dar suporte. Isso me diz que o foco não é UI — é pipeline de dados.

O que a Apple está realmente a construir (e por que interessa a devs)

Segundo o Sapo.pt, a pulseira é fina, em tecido, com um módulo de computação encaixado sobre o pulso. Sensores de frequência cardíaca e outros parâmetros de saúde. Sem ecrã, sem toque, sem feedback visual direto no dispositivo.

Na minha leitura técnica, isso significa três coisas:

• O processador está otimizado para coleta contínua, não para renderização. Mais parecido com um chipset de sensor hub do que com um SoC de smartwatch. Pensa no Apple Watch Series 10 em modo always-on display, mas sem o display.
• A interface vai migrar 100% para o companion app (iPhone, iPad, Mac). Toda a complexidade de UX que normalmente vive no pulso vai para uma tela com mais espaço, mais contexto, mais poder de processamento.
• O pipeline de dados vai ficar mais gordo. Whoop e Oura já provaram que dá para coletar sinais úteis 24/7 com bateria de 4–5 dias. Apple tem vantagem no chip, no stack de sensores e no HealthKit.

O detalhe mais interessante, e que pouca gente comenta, é a engenharia vinda do Vision Pro. Quem já trabalhou com spatial computing sabe que aquela equipa domina fusão sensorial (IMU + optical + depth) com baixíssimo consumo. É a mesma mentalidade que precisa uma pulseira sem ecrã: extrair máximo sinal, mínimo ruído, mínimo watts.

Comparação honesta: Apple pulseira vs. Whoop vs. Oura vs. Apple Watch

O ponto crítico aqui é a API. A Whoop cobra caro e restringe acesso. A Oura é mais aberta, mas cobra subscription. Se a Apple entra nesse segmento com HealthKit maduro, gratuito e já integrado em milhares de apps, o jogo muda para qualquer dev que esteja a construir produtos de saúde digital.

O detalhe do modelo de assinatura que a Apple vai (ou não) usar

A Whoop vende hardware barato e prende o utilizador numa assinatura mensal. A Apple historicamente não joga assim — vende hardware caro e deixa serviços opcionais. Espero que sigam o modelo Oura: paga o dispositivo, funcionalidades básicas grátis, premium opcional. Isso seria devastador para a Whoop porque elimina a fricção de assinatura.

Mas atenção: também pode dar errado. Se a Apple exigir Apple One ou Fitness+ para destravar métricas avançadas, vira mais uma desculpa para empurrar subscription. Vamos ver.

Na Prática: como integrar dados de uma pulseira assim no seu app iOS

Imagine que você está a construir um app de coaching de sono e quer ler dados de frequência cardíaca e HRV em tempo real. Com HealthKit já consegue fazer isso. Quando a pulseira da Apple chegar ao mercado, o mesmo código deve funcionar — o HealthKit abstrai o hardware.

Setup mínimo em Swift:

import HealthKit

class HealthDataService {
    private let store = HKHealthStore()
    
    func requestAuthorization() async throws {
        let readTypes: Set<HKObjectType> = [
            HKObjectType.quantityType(forIdentifier: .heartRate)!,
            HKObjectType.quantityType(forIdentifier: .heartRateVariabilitySDNN)!,
            HKObjectType.quantityType(forIdentifier: .oxygenSaturation)!,
            HKObjectType.categoryType(forIdentifier: .sleepAnalysis)!
        ]
        
        try await store.requestAuthorization(
            toShare: [],
            read: readTypes
        )
    }
    
    func streamHeartRate() -> AsyncStream<Double> {
        AsyncStream { continuation in
            let predicate = HKQuery.predicateForSamples(
                withStart: Date(),
                end: nil,
                options: .strictStartDate
            )
            
            let query = HKAnchoredObjectQuery(
                type: HKObjectType.quantityType(forIdentifier: .heartRate)!,
                predicate: predicate,
                anchor: nil,
                limit: HKObjectQueryNoLimit
            ) { _, samples, _, _, _ in
                guard let samples = samples as? [HKQuantitySample] else { return }
                for sample in samples {
                    let bpm = sample.quantity.doubleValue(for: .count().unitDivided(by: .minute()))
                    continuation.yield(bpm)
                }
            }
            
            query.updateHandler = { _, samples, _, _, _ in
                guard let samples = samples as? [HKQuantitySample] else { return }
                for sample in samples {
                    let bpm = sample.quantity.doubleValue(for: .count().unitDivided(by: .minute()))
                    continuation.yield(bpm)
                }
            }
            
            store.execute(query)
            
            continuation.onTermination = { _ in
                self.store.stop(query)
            }
        }
    }
}

Esse padrão é o que eu uso em produção para clientes que fazem telemetria cardíaca. O detalhe que ninguém te conta: o updateHandler entrega amostras em streaming, mas o background delivery precisa de configuração adicional no Info.plist (UIBackgroundModes com processing e fetch) senão o app morre em background.

Pipeline sugerido para um produto de health tech

1. Coleta: HealthKit + anchor query no dispositivo.
2. Persistência local: Core Data ou SQLite com partição por dia. Nada de guardar tudo na memória.
3. Sincronização: CloudKit se for só Apple, ou seu backend com retry exponencial.
4. Processamento: HRV e features de sono calculam-se no servidor, não no device. RR intervals são leves, mas FFT e análise de tendências pesam.
5. Visualização: Swift Charts (iOS 16+) já dá conta do recado sem bibliotecas externas.

Erros Comuns: o que devs erram em apps de saúde

Trabalho há anos com clientes que constroem apps nestas categorias. Os erros repetem-se:

• Pedir todas as permissões no primeiro launch. O utilizador fecha o app. Peça progressivamente, contextualizado. HRV primeiro, sono depois, oxigenação só quando justifica.
• Ignorar a granularidade dos timestamps. HealthKit devolve samples com startDate e endDate. Muita gente só usa o start e perde intervalos. Para HRV é fatal.
• Calcular métricas no device sem fallback. Se o utilizador desligar o Bluetooth ou o sensor falhar, seu app explode. Sempre tenha um caminho de degradação.
• Não lidar com fusos horários. Dados de sono atravessam noites. Confundir UTC com local gera gráficos de dormir às 3 da tarde. Use HKCalendarDaySeparator.
• Subir tudo para a cloud por padrão. Saúde é a categoria mais sensível. LGPD/GDPR obrigam a consentimento granular e, em muitos casos, processamento on-device.

O “porquê” por trás da decisão da Apple

O Apple Watch saturou. Vendas em queda, mercado de smartwatch a perder força, utilizadores que não precisam de notificações no pulso a migrarem para Whoop e Oura. A Apple está a fazer o que faz melhor: abrir uma categoria nova em vez de brigar pela mesma.

Do ponto de vista de plataforma, isso é ouro. Mais dados no HealthKit significa:

• Apps de saúde mais ricos sem precisar de hardware proprietário.
• Médicos e investigadores com datasets longitudinais maiores.
• Novas oportunidades para modelos de ML on-device que correlacionam sono, atividade, stress e marcadores metabólicos.

Para nós, devs, significa que o próximo grande mercado de apps não é mais um app novo — é uma camada de inteligência por cima de dados que a Apple, Whoop, Oura e Garmin vão continuar a gerar.

FAQ — Perguntas que um dev faz sobre esse rumor

1. Vou poder aceder aos dados da pulseira via API?

Quase certamente sim, através do HealthKit. A Apple nunca fechou esse ecossistema para developers. Quem teve apps rejeitados foi por uso indevido dos dados, não por restrição técnica.

2. Quando posso começar a desenvolver para esse hardware?

Provavelmente só em 2027 ou 2028, com announcements a partir de 2026–2027. Mas a base de código que escreve hoje contra HealthKit já vai funcionar sem mudanças.

3. A Apple vai matar o Apple Watch?

Não. Coexistem. Apple Watch é para quem quer interação no pulso; pulseira sem ecrã é para quem quer coleta contínua sem distração. São produtos diferentes para personas diferentes.

4. Vale a pena migrar de Whoop API para HealthKit agora?

Se o seu produto depende de HRV noturno e métricas de recovery, aguarde. Quem usa HealthKit hoje depende de Apple Watch ou de terceiros (Garmin, Polar via bridges). A nova pulseira fecha essa lacuna.

5. Quem vai sair a perder com isso?

Whoop, sem dúvida. O modelo de assinatura só se sustenta enquanto não houver alternativa integrada. Quando a Apple entrar com hardware premium e sem assinatura obrigatória, a Whoop perde o seu principal argumento de venda.

Gostou? Me segue no GitHub e deixa um comentário se quiser que eu aprofunde algum ponto — pipeline de HealthKit, integração com Oura API, ou como montar um backend GDPR-compliant para dados de saúde.