# Análise Técnica — Arquitetura Skip (PediFoods)

## Entendimento confirmado

O projeto usa **Skip com fonte principal em Swift/SwiftUI** e geração/transpilação para Android.

Diretriz operacional validada:

1. **iOS é a plataforma prioritária** de desenvolvimento e validação.
2. **Android entra depois**, com adaptações isoladas por compilação condicional.
3. Toda alteração deve preservar comportamento de iOS e evitar regressão cross-platform.

## Como o projeto está estruturado

1. Código compartilhado principal: `Sources/PediFoods/*` (Swift/SwiftUI).
2. Entry point iOS: `Darwin/Sources/Main.swift`.
3. Entry point Android: `Android/app/src/main/kotlin/Main.kt`.
4. Configuração Skip: `Sources/PediFoods/Skip/skip.yml` (`mode: native`).
5. Build/transpilação Android via plugin Skip (`skipstone`) no target Swift Package.

## Evidências no código (padrão já em uso)

1. Uso extensivo de condicionais:
   - `#if os(iOS)`
   - `#if os(Android)`
   - `#if canImport(UIKit)`
2. Dependência iOS-only no `Package.swift`:
   - `LCEssentials` com `condition: .when(platforms: [.iOS])`
3. Exemplo claro de adaptação segura:
   - `ContentView.swift`: `SnackbarCenter` com implementação distinta para Android e iOS.

## Regra prática para próximas tarefas

1. Implementar primeiro para iOS.
2. Validar iOS (build/execução/comportamento).
3. Só depois adaptar Android, sempre em bloco condicional separado.
4. Nunca alterar caminho iOS por causa de ajuste Android.
5. Em mudanças de UI de inicialização (ex.: splash), tratar iOS e Android em fluxos independentes.

## Nota específica para Splash

Estado atual identificado:

1. iOS com Launch Screen gerado automaticamente (`INFOPLIST_KEY_UILaunchScreen_Generation = YES`).
2. Android sem implementação custom de splash dedicada no `res/values` + tema de launch.

Implicação:

1. Mudança de splash para iOS pode ser feita sem tocar Android.
2. Quando Android for tratado, deve entrar em camada própria (tema/recursos Android), sem impactar o fluxo iOS.

Autor: Daniel Arantes Loverde