Barra de ferramentas adaptativa no SwiftUI para iOS 27

A medida que nossos aplicativos se tornam redimensionáveis e aparecem em mais contextos e lugares, o espaço disponível para suas barras de ferramentas pode mudar significativamente. O SwiftUI adapta uma barra de ferramentas ao seu ambiente atual, mas até agora tínhamos pouco controle sobre quais ações permaneciam visíveis quando o espaço se tornava limitado e quais eram movidas para overflow.

No iOS 27, novas APIs de barra de ferramentas permitem que descrevamos essas decisões com mais precisão. Podemos atribuir prioridades de visibilidade às ações, colocar comandos secundários diretamente em overflow, prender um item importante na borda final e controlar como uma barra de ferramentas minimiza enquanto as pessoas rodam.

Quando não há espaço suficiente para exibir todos os itens da barra de ferramentas, o SwiftUI pode mover alguns deles para um menu overflow. Por padrão, todos os itens têm a mesma prioridade de visibilidade automática, então o sistema não tem informações sobre quais ações são mais importantes para nosso aplicativo.

Por exemplo, uma vista detalhada de paleta pode fornecer ações para duplicar e favoritar uma paleta, copiar seu nome e cores, e compartilhar:

Mantendo comandos secundários em overflow
Alguns comandos não precisam aparecer diretamente na barra de ferramentas, mesmo quando há espaço suficiente para eles. Em nosso exemplo, as três ações de cópia são úteis, mas são secundárias às ações para trabalhar com a paleta em si. Podemos colocá-las em um ToolbarOverflowMenu:
PaletteOverviewView(palette: palette)
    .toolbar {
        ToolbarItem {
            DuplicatePaletteButton(palette: palette)
        }

        ToolbarOverflowMenu {
            CopyPaletteNameButton(palette: palette)
            CopySwiftUIColorsButton(palette: palette)
            CopyHexValuesButton(palette: palette)
        }

        ToolbarItem {
            FavoritePaletteButton(palette: palette)
        }
        .visibilityPriority(.high)

        ToolbarItem {
            ShareLink(item: palette.title)
        }
    }
Diferente do conteúdo da barra de ferramentas com prioridade de visibilidade baixa, os comandos dentro de ToolbarOverflowMenu não aparecem na barra quando mais espaço se torna disponível. Eles sempre permanecem no menu overflow, dando aos comandos visíveis uma disposição mais estável à medida que a largura disponível muda.
Também podemos adicionar o mesmo tipo de menu separadamente do principal toolbar modificador usando toolbarOverflowMenu(content:):
PaletteOverviewView(palette: palette)
    .toolbar {

    }
    .toolbarOverflowMenu {
        CopyPaletteNameButton(palette: palette)
        CopySwiftUIColorsButton(palette: palette)
        CopyHexValuesButton(palette: palette)
    }
As duas formas produzem o mesmo menu overflow. A forma de ToolbarOverflowMenu é conveniente quando queremos descrever todo o conteúdo da barra de ferramentas juntos, enquanto o modificador é útil quando os comandos secundários são adicionados de outra parte da hierarquia de visualização.
Fixando uma ação no lado trailing
Uma alta prioridade de visibilidade informa o SwiftUI quais ações devem ser movidas para overflow por último, mas ainda permite que o sistema tome a decisão final. Quando uma ação deve ocupar a posição trailing, podemos em vez disso colocá-la no topBarPinnedTrailing:
ToolbarItem(placement: .topBarPinnedTrailing) {
    ShareLink(item: palette.title)
}
O item fixado permanece no lado trailing à medida que a barra de ferramentas fica mais estreita, enquanto outros itens podem ser movidos para overflow ao seu redor. Isso torna o posicionamento adequado para uma ação que deve permanecer tanto visível quanto estável espacialmente. É um compromisso maior do que atribuir uma prioridade de visibilidade alta, então deve ser reservado para uma ação que realmente precisa dessa posição.
Os itens fixados ainda podem ser movidos para overflow enquanto a pesquisa está ativa se não houver espaço suficiente para eles ao lado da interface de pesquisa.
Barras de ferramentas também podem se adaptar conforme as pessoas navegam por conteúdo rolável. O modificador toolbarMinimizationBehavior(_:for:) nos permite controlar quando uma barra de ferramentas minimiza em resposta ao rolar:
PaletteOverviewView(palette: palette)
    .toolbarMinimizationBehavior(
        .onScrollDown,
        for: .navigationBar
    )
Nos podemos usar onScrollDown para minimizar a barra de navegação ao rolar para baixo, onScrollUp para minimizá-la na direção oposta e never para prevenir a minimização. Com automatic, o SwiftUI escolhe um comportamento adequado para o contexto atual.
Por padrão, a área segura ajusta-se conforme a barra de navegação minimiza, permitindo que o conteúdo se mova para o espaço deixado por trás. Podemos manter a área segura do conteúdo inalterada com toolbarMinimizationSafeAreaAdjustment(_:for:):
.toolbarMinimizationBehavior(
    .onScrollDown,
    for: .navigationBar
)
.toolbarMinimizationSafeAreaAdjustment(
    .disabled,
    for: .navigationBar
)
Desabilitar a ajuste é útil quando o conteúdo se estende abaixo da barra de navegação e deve permanecer no lugar conforme a barra minimiza. Para conteúdo que deve refluir para o espaço recém-disponível, podemos manter o valor padrão automatic ou usar explicitamente enabled.
Também podemos alterar quando a barra minimizada retorna. Normalmente ela restaura quando a pessoa inverte a direção de rolagem. O modificador toolbarMinimizationRestoration(_:for:) pode adiar a restauração até que o conteúdo alcance a borda de rolagem:
.toolbarMinimizationRestoration(
    .atScrollEdge,
    for: .navigationBar
)
O iOS 27 inclui algumas adições menores que facilitam a configuração do conteúdo da barra de ferramentas.
Nos podemos remover o espaçamento padrão ao redor de um item cujo conteúdo deve estender-se até suas bordas com contentMarginsRemoved(_:):
ToolbarItem {
    PalettePreview(palette: palette)
}
.contentMarginsRemoved()
A barra de status agora é representada por ToolbarPlacement.statusBar, então sua visibilidade pode ser controlada através da mesma API de barra de ferramentas que outras barras:
.toolbarVisibility(.hidden, for: .statusBar)
Isso substitui o modificador mais antigo statusBarHidden(_:) no iOS 27.
ForEach agora conforma-se com ToolbarContent, o que significa que podemos gerar itens de barra diretamente a partir de uma coleção:
.toolbar {
    ForEach(quickActions) { action in
        ToolbarItem {
            Button(action.title, systemImage: action.systemImage) {
                action.perform()
            }
        }
    }
}
EmptyView também conforma-se com ToolbarContent, então um construtor de conteúdo da barra pode usá-lo para representar uma ramificação explicitamente vazia.
Quando construído com o SDK do iOS 27, a conformidade de ForEach retrocede para o iOS 16. A conformidade de EmptyView e as outras APIs discutidas neste post exigem o iOS 27.
Juntas, essas APIs nos permitem expressar como o conteúdo da barra de ferramentas deve responder conforme a quantidade de espaço disponível e a interface circundante mudam. Isso dá ao SwiftUI as informações necessárias para adaptar nossas barras de ferramentas em janelas redimensionáveis sem que seja necessário projetarmos uma barra de ferramentas separada para cada largura possível.
Se você está procurando construir uma base sólida no SwiftUI, meu livro SwiftUI Fundamentals mergulha profundamente nos princípios e APIs fundamentais do framework para ajudá-lo a entender como ele funciona por trás das cortinas e como usá-lo efetivamente em seus projetos. E meu novo livro The SwiftUI Way ajuda você a adotar padrões recomendados, evitar armadilhas comuns e usar as ferramentas nativas do SwiftUI de forma adequada para trabalhar com o framework em vez de contra ele.
Para mais recursos sobre Swift e SwiftUI, confira meus outros livros e kits de livros bundles.