Skip to main content

iOS Design System Review: Dark Mode & Accessibility Analysis

Date: 2026-02-12 Reviewer: UX/UI Design Specialist Context: Baby tracking app optimized for 3 AM use by sleep-deprived parents

Executive Summary​

This review evaluates the iOS design system specification for Baby Basics against Apple HIG best practices, competitor research, accessibility standards, and dark mode design principles. Overall, the design system is well-architected with strong foundational decisions. However, there are 7 specific areas requiring attention or adjustment before implementation.

Key Findings:

  • ✅ Near-black (not pure black) background is the correct choice
  • ✅ Semantic color token architecture is sound
  • ⚠️ Indigo/purple is acceptable but not optimal for this use case
  • ⚠️ Dark mode shadows need refinement (use elevation instead)
  • ⚠️ .caption2 for "Suggested" label is too small for 3 AM use
  • ⚠️ Color-blind accessibility has gaps
  • ⚠️ Missing key iOS dark mode patterns (vibrancy, materials)

Question 1: Is Indigo/Purple a Good Primary Color for a Baby App?​

Research Findings​

Color Psychology for Caregiving: According to color psychology research, purple and indigo are soothing colors that promote rest and relaxation, making them suitable for baby-related applications. Color Psychology: Calming Colors To Paint Your Baby's Nursery confirms that "blue, green, and purple are soothing colors that promote rest and relaxation."

Baby blue specifically is "often linked to tranquility, trust, and reliability" and "promotes a peaceful environment while helping reduce anxiety and stress." The Psychology of Baby Clothing Colors

2026 Design Trends: The 2026 interior color trend report notes that "muted pastels speak to calm and emotional comfort, while futuristic lavender mirrors our blended physical-digital lives," suggesting softer purple and indigo tones align with modern design directions. Interior Color Trends 2026

Competitor Analysis: Popular baby tracking apps use varied color approaches:

  • Huckleberry: Uses "brightly colored, easy-to-tap categories" but specific palette not disclosed
  • Glow Baby: Described as having "pretty design" similar to other Glow products
  • Industry trend: Most baby apps lean toward pastels, soft blues, and pinks rather than purple/indigo

Assessment​

Verdict: ACCEPTABLE but NOT OPTIMAL

Pros:

  • Purple/indigo conveys calm, trust, and relaxation
  • Distinctive from competitor pink/blue stereotypes
  • Aligns with 2026 design trends (muted lavender)

Cons:

  • Less common in baby app category (may feel unexpected)
  • Softer blues or teals might be more intuitive for "sleep/calm" context
  • Purple has weaker association with "baby" compared to pastels

Recommendation​

Keep indigo/purple BUT:

  1. Use very muted, desaturated indigo in dark mode (not vibrant purple)
  2. Test with target users (new parents) for gut reaction
  3. Consider a fallback option: Soft teal or slate blue as alternative primary
  4. Ensure the indigo feels "sophisticated and calming" not "playful and bright"

Action Item: During Theme.swift implementation, present 2-3 indigo palette options (ranging from blue-indigo to purple-indigo) and ask for user approval before committing.

Question 2: Near-Black vs Pure Black for Dark Mode Background​

Research Findings​

Battery Impact: Pure black (#000000) saves the most power on OLED displays because pixels are turned off. However, the difference between pure black and near-black is minimal. Research shows dark gray (#121212) consumes only 1.2mW more than pure black, representing a 0.3% increase in power consumption. No, "AMOLED Black" Does NOT Save More Battery Than Dark Gray

Contrast and Readability: Pure black creates harsh contrast with white text, which can cause eye strain. Very dark gray (#121212-#1E1E1E) provides:

  • Most of the battery benefit (99.7% efficient vs pure black)
  • Better readability and comfort (reduced harsh contrast)
  • Reduced halo effect for users with astigmatism

The UX research consensus: "Stick to a contrast ratio of at least 4.5:1 for regular text and 3:1 for larger text, and go for dark grays or muted tones instead of using pure black for backgrounds." Dark Mode vs Light Mode: Complete UX Guide

Apple's Approach: Apple uses near-black, not pure black, in system dark mode. The system background color is approximately #1C1C1E (RGB 28, 28, 30), not pure black.

Assessment​

Verdict: NEAR-BLACK IS THE RIGHT CALL ✅

The spec's decision to use "near-black, not pure black" is correct and well-reasoned:

  • Preserves 99%+ of OLED battery savings
  • Significantly improves readability and reduces eye strain
  • Aligns with Apple's own dark mode implementation
  • Better accommodates users with astigmatism

Recommendation​

Specific hex values for implementation:

  • bbBackground (dark): #1C1C1E or #121212 (Apple's system or Material Design standard)
  • bbText (dark): #F5F5F7 or #E1E1E1 (off-white, not pure white)

Do NOT use:

  • #000000 for background (too harsh)
  • #FFFFFF for text (too stark)

Rationale: At 3 AM with 20% brightness, near-black + off-white provides optimal readability without glare or harsh contrast.

Question 3: Shadows on Dashboard Cards in Dark Mode​

Research Findings​

Dark Mode Shadow Best Practices: Traditional shadows (dark shadows on dark backgrounds) are ineffective in dark mode because they blend into the background. According to design research:

"In light-mode designs, shadows are commonly used to add depth, but in dark mode, traditional shadows can be ineffective and even visually jarring because dark shadows can easily blend into the dark background." How to Design Accessible Dark Mode Interfaces

Elevation Alternatives: The recommended approach is elevation through lighter surfaces:

"Instead of relying on shadows, a better solution for showing elevation in dark mode is to use a lighter shade of the background colour, which creates the desired sense of depth without compromising the overall design aesthetic." Mastering Elevation in Dark Mode

iOS Best Practices: Apple's guidance for dark mode elevation:

  • Use lighter surface colors for elevated elements (not shadows)
  • Apply subtle borders to define boundaries
  • Use blur/vibrancy materials for system-level elevation

Assessment​

Verdict: CURRENT SHADOW APPROACH NEEDS REFINEMENT ⚠️

The spec defines:

// Light mode: subtle shadow
.shadow(color: .black.opacity(0.08), radius: 4, x: 0, y: 2)

// Dark mode: darker shadow
.shadow(color: .black.opacity(0.3), radius: 4, x: 0, y: 2)

Problems:

  • Dark shadows on dark backgrounds have very low visibility
  • .black.opacity(0.3) shadow will barely show on near-black background
  • Does not follow Apple's elevation-through-lightness pattern

Recommendation​

Revised approach for dashboard cards:

// BBCardStyle ViewModifier
struct BBCardStyle: ViewModifier {
    @Environment(\.colorScheme) var colorScheme

    func body(content: Content) -> some View {
        content
            .background(Color.bbSurface)
            .cornerRadius(12)
            .overlay(
                RoundedRectangle(cornerRadius: 12)
                    .strokeBorder(
                        colorScheme == .dark
                            ? Color.white.opacity(0.08)
                            : Color.clear,
                        lineWidth: 0.5
                    )
            )
            .shadow(
                color: colorScheme == .dark
                    ? Color.clear
                    : Color.black.opacity(0.08),
                radius: 4, x: 0, y: 2
            )
    }
}

Rationale:

  • Light mode: Keep existing shadow (works well)
  • Dark mode: Replace shadow with subtle light border (0.5pt, white at 8% opacity)
  • Elevation is achieved by bbSurface being lighter than bbBackground (not by shadow)

Color palette adjustment needed:

  • bbBackground (dark): #1C1C1E (near-black)
  • bbSurface (dark): #2C2C2E or #3C3C3E (noticeably lighter gray)
  • This creates inherent elevation through lightness difference

Alternative (Material Design approach): Use elevation levels with progressive lightness:

  • Level 0 (background): #121212
  • Level 1 (cards): #1E1E1E (+8% white overlay)
  • Level 2 (active cards): #2C2C2C (+12% white overlay)

Question 4: Indigo Primary Contrast at 20% Brightness​

Contrast Requirements​

WCAG AA Standards:

  • Normal text on background: 4.5:1 minimum
  • Large text (18pt+): 3:1 minimum
  • UI components: 3:1 minimum

Testing Conditions: The spec correctly requires testing at 20% screen brightness (realistic 3 AM scenario).

Assessment​

Verdict: REQUIRES VERIFICATION DURING IMPLEMENTATION ⚠️

Risk factors:

  • Indigo/purple has lower luminance than blue or green
  • At 20% brightness, muted indigo may approach grayscale
  • Insufficient contrast between indigo buttons and near-black background

Example concern:

  • bbBackground (dark): #1C1C1E (luminance ≈ 0.02)
  • Muted indigo (dark): #6366F1 → at 20% brightness, appears darker
  • May not achieve 3:1 contrast for buttons

Recommendation​

During Theme.swift implementation:

  1. Use contrast checker tool (e.g., WebAIM, Stark, Color Oracle)
  2. Test these pairings:
    • bbPrimary (dark) on bbBackground (dark) → must be ≥3:1
    • bbPrimary (dark) on bbSurface (dark) → must be ≥3:1
    • bbText (dark) on bbPrimary (dark) → must be ≥4.5:1 (for button labels)
  3. Physical device test at 20% brightness in dark room
  4. Include contrast ratios in PR description (as spec requires)

Fallback strategy: If muted indigo fails contrast at 20% brightness:

  • Option A: Increase luminance of dark mode indigo (lighter, more saturated)
  • Option B: Add subtle light border to .borderedProminent buttons
  • Option C: Switch to higher-luminance color (teal, cyan, soft blue)

Critical: Do NOT ship without verifying 3:1 contrast for primary UI elements.

Question 5: Is .caption2 Too Small for "Suggested" Label at 3 AM?​

Research Findings​

Caption2 Size: According to iOS typography research, .caption2 has a built-in minimum size of 11pt to ensure readability. A product designer's guide to Dynamic Type in iOS

"The Caption 2 text style includes a built-in minimum size of 11 points to make sure the text remains readable even at smaller preferences."

Apple's Minimum: Apple's accessibility guidelines state: "Legible fonts with a minimum 11 pt in size" for iOS apps. Accessibility | Text Size and Weight

Dynamic Type Behavior: .caption2 scales from 11pt (base) up to larger sizes when users enable accessibility text sizes, but never goes below 11pt.

Assessment​

Verdict: TOO SMALL FOR THIS CONTEXT ⚠️

Concerns:

  • 11pt is Apple's absolute minimum for readability
  • "Suggested" label is critical wayfinding information (not decorative)
  • At 3 AM with 20% brightness, 11pt may strain tired eyes
  • Parent may be holding baby while reading (non-ideal viewing angle)

Context matters:

  • Timestamps and secondary metadata → .caption2 acceptable (non-critical)
  • Action guidance ("Suggested") → should be more prominent

Recommendation​

Change .caption2 to .caption (12pt minimum) for "Suggested" label:

// Current (spec line 186)
.caption2.weight(.semibold)  // 11pt minimum

// Revised
.caption.weight(.semibold)   // 12pt minimum

Rationale:

  • Increases base size from 11pt → 12pt (9% larger)
  • Maintains visual hierarchy (still smaller than button label)
  • Improves legibility at low brightness
  • Aligns with "Optimized for 3 AM" design principle

Additional improvement: Add .opacity(0.9) to "Suggested" label to soften it slightly, preventing visual competition with the button label itself.

Updated spec text (lines 185-188):

### "Suggested" Label
- Positioned directly above the suggested button
- `.caption.weight(.semibold)`, `bbPrimary` color, `.opacity(0.9)`
- Non-suggested buttons have an invisible placeholder to maintain vertical alignment
- `accessibilityHidden(true)` on the label (information conveyed via button's accessibility label instead)

Question 6: Missing iOS Dark Mode Patterns (Vibrancy, Materials, Blur)​

Research Findings​

Apple's Material System: iOS provides UIVisualEffectView with blur and vibrancy effects designed specifically for dark mode. According to Apple's documentation:

"UIBlurEffect adds a blur over the content underneath the visual effect view, while UIVibrancyEffect makes the content under the visual effect view more prominent." How to add blur and vibrancy using UIVisualEffectView

Material Types (iOS 13+):

  • Primary, secondary, tertiary, quaternary vibrancy levels
  • Blur styles: .light, .dark, .systemMaterial, .systemThinMaterial, etc.
  • Adaptive to light/dark mode automatically

Premium App Examples:

  • Things 3: Uses materials for toolbar backgrounds, modal overlays
  • Overcast: Black theme with subtle vibrancy for controls
  • Bear: Translucent sidebars with vibrancy effects

Things 3.8 for iOS Debuts New Dark Mode

Assessment​

Verdict: MISSING OPPORTUNITY FOR PREMIUM FEEL ⚠️

The current spec does NOT mention:

  • Vibrancy effects
  • Material blur backgrounds
  • Translucent layers

Where materials could enhance the design:

  1. Sheets/modals: Replace bbSurface background with .ultraThinMaterial or .thinMaterial
  2. Floating feedback banners: Use .systemMaterial for subtle translucency
  3. Toolbar overlays: Apply vibrancy to "Today" header when scrolling

Recommendation​

Add new section to spec: "Materials and Vibrancy (iOS 13+)"

## Materials and Vibrancy

For elevated UI elements, use Apple's adaptive materials to create depth and premium polish.

### When to Use Materials
- **Sheet backgrounds**: `.presentationBackground(.ultraThinMaterial)` instead of solid `bbSurface`
- **BBFeedbackBanner**: `.background(.thinMaterial)` with tinted overlay for warning/error states
- **Floating headers** (future): `.background(.regularMaterial)` for scrolled toolbar

### Implementation
```swift
// Sheet with material background
.sheet(isPresented: $showSheet) {
    LogFeedingSheet()
        .presentationBackground(.ultraThinMaterial)
}

// Feedback banner with tinted material
struct BBFeedbackBanner: View {
    let style: FeedbackStyle

    var body: some View {
        HStack { /* content */ }
            .background(
                ZStack {
                    Material.thin
                    style.tintColor.opacity(0.15)
                }
            )
    }
}

Accessibility​

  • Materials automatically adapt to light/dark mode and Increase Contrast settings
  • Prefer materials over manual color overlays for better system integration

**Why this matters:**
- Materials create **spatial hierarchy** more effectively than flat colors
- Automatically respect **Reduce Transparency** accessibility setting
- Provide **premium, system-native feel** (vs custom gradients/overlays)
- Work seamlessly across **light/dark/high-contrast** modes

**Scope:**
- **MVP**: Apply to sheets and feedback banners only
- **Post-MVP**: Explore vibrancy for text labels over materials

---

## Question 7: Color-Blind Accessibility (Indigo + Green + Amber + Red)

### Research Findings

**Types of Color Blindness:**
- **Protanopia** (red-blind): Cannot perceive red light; confuses purple with blue
- **Deuteranopia** (green-blind): Cannot perceive green light; confuses green/yellow and blue/purple
- **Tritanopia** (blue-blind): Cannot perceive blue light; confuses blue with green

[Types of Colour Blindness - Colour Blind Awareness](https://www.colourblindawareness.org/colour-blindness/types-of-colour-blindness/)

**Common Confusions:**
> "People with both protanopia and deuteranopia will confuse some blues with some purples... and commonly confuse red/brown/green/yellow." [WebAIM: Visual Disabilities - Color-blindness](https://webaim.org/articles/visual/colorblind)

**Accessibility Best Practices:**
From gaming accessibility research:
> "Deuteranopia mode uses colors like squad: purple, team: indigo, and enemy: orange, while protanopia mode uses squad: gray, team: purple, and enemy: green." [Colorblind accessibility in video games](https://www.gamersexperience.com/colorblind-accessibility-in-video-games-is-the-industry-heading-in-the-right-direction/)

### Assessment

**Verdict: PARTIAL GAPS, REQUIRES NON-COLOR REDUNDANCY** ⚠️

**Current palette (semantic colors):**
- `bbPrimary`: Indigo/purple
- `bbSuccess`: Green
- `bbWarning`: Amber
- `bbDanger`: Red

**Problems:**

1. **Purple/Indigo + Blue confusion** (protanopia/deuteranopia):
   - If you later add blue accent colors, they may be indistinguishable from purple primary
   - Mitigation: Spec uses **only one hue family** (indigo), no secondary blues ✅

2. **Green/Amber/Red confusion** (deuteranopia):
   - Green (success) and amber (warning) may appear similar
   - Red (danger) may be hard to distinguish from amber
   - **Critical:** These are used for feedback toasts (warning vs error)

3. **Over-reliance on color alone:**
   - "Suggested" button uses `.borderedProminent` (filled) vs `.bordered` (outlined) — **GOOD** (shape difference)
   - But color is still primary differentiator

### Recommendation

**Ensure non-color redundancy for all semantic colors:**

#### 1. Feedback Banners (Warning vs Error)
**Problem:** `bbWarning` and `bbDanger` may be indistinguishable for color-blind users.

**Solution:** Add **iconography redundancy**:

```swift
struct BBFeedbackBanner: View {
    enum Style {
        case undo, warning, error

        var icon: String {
            switch self {
            case .undo: return "checkmark.circle.fill"
            case .warning: return "exclamationmark.triangle.fill"
            case .error: return "xmark.octagon.fill"
            }
        }
    }
}

Layout:

┌─────────────────────────────────────┐
│ ⚠️ Couldn't save · Will retry       │  ← Warning (amber + triangle icon)
└─────────────────────────────────────┘

┌─────────────────────────────────────┐
│ ⛔ Failed to save · Tap to retry    │  ← Error (red + octagon icon)
└─────────────────────────────────────┘

Rationale: Icon shape conveys severity independent of color.

2. Success/Danger Button States​

If you use green "Save" buttons or red "Delete" buttons in future:

  • Always pair color with text label (e.g., "Delete" not just red X)
  • Use role: .destructive for system-rendered red buttons (includes icon)

3. Dashboard Cards (Future: Color-Coded Categories)​

If you later color-code event types (e.g., feeding = blue, diaper = yellow):

  • Do NOT rely on color alone
  • Use SF Symbol icons as primary differentiator (already in spec ✅)
  • Color is secondary enhancement, not primary signal

4. Testing Protocol​

Add to spec under "Accessibility" section:

### Color Blindness Testing
- Use **Color Oracle** (free simulator for macOS) to test protanopia, deuteranopia, tritanopia
- All semantic color uses must have **non-color redundancy**:
  - Icons with distinct shapes (not just color swaps)
  - Text labels (not color-only indicators)
  - Patterns/borders (e.g., dashed vs solid)
- Test critical paths: Viewing feedback toasts, identifying suggested options, reading form errors

Specific fix needed in spec: Update BBFeedbackBanner section (lines 238-255) to require icons for warning and error states.

Summary of Required Changes to Spec​

Immediate Changes (Before Implementation)​

  1. Line 185-188 (Suggested Label Size)

    • Change .caption2 → .caption
    • Add .opacity(0.9) for visual softening

  2. Lines 113-118 (Card Shadow/Elevation)

    • Replace dark mode shadow with subtle light border approach
    • Update color guidance: bbSurface must be noticeably lighter than bbBackground in dark mode

  3. Lines 238-255 (BBFeedbackBanner)

    • Add icon property to all three styles (undo, warning, error)
    • Specify SF Symbol icons for each state

  4. New Section: Materials and Vibrancy

    • Add after "Animations" section (line 223)
    • Document .presentationBackground(.ultraThinMaterial) for sheets
    • Document .thinMaterial for feedback banners

  5. Lines 60-66 (Contrast Requirements)

    • Add explicit warning about indigo contrast at 20% brightness
    • Require physical device testing, not just color picker values

  6. New Section: Color Blindness Testing

    • Add under "Accessibility" heading
    • Specify Color Oracle testing protocol
    • Require icon redundancy for all semantic colors

Discussion Points (Before Implementation)​

  1. Primary Color Final Decision:

    • Present 2-3 indigo palette options (blue-indigo, neutral-indigo, purple-indigo)
    • Include contrast ratios and 20% brightness screenshots
    • Allow user to choose final hue

  2. Material Adoption Scope:

    • Confirm which components should use materials (sheets, banners, etc.)
    • Balance premium feel vs performance (materials add rendering cost)

Conclusion​

The iOS design system is fundamentally sound with strong decisions around semantic tokens, typography, and accessibility. The seven areas identified require refinement, not redesign:

  • Keep: Near-black background, semantic color architecture, Dynamic Type, button hierarchy
  • Refine: Shadow → elevation, caption2 → caption, add icons to feedback banners
  • Add: Materials/vibrancy, color blindness testing protocol
  • Verify: Indigo contrast at 20% brightness before shipping

With these adjustments, the design system will deliver a premium, accessible, dark-mode-first experience optimized for 3 AM use.

Sources​

Apple HIG & iOS Design​

Dark Mode Best Practices​

OLED & Battery​

Color Psychology & Baby Apps​

iOS Apps (Things 3, Overcast, Bear)​

Typography & Dynamic Type​

Materials & Vibrancy​

Color Blindness & Accessibility​