피드로 돌아가기
Why I built a 15MB SwiftUI menu bar app instead of reaching for Electron
Dev.toDev.to
Mobile

RAM 12MB의 기적, Electron 대신 SwiftUI를 선택한 이유

Why I built a 15MB SwiftUI menu bar app instead of reaching for Electron

Silas C2026년 4월 9일3intermediate

Context

다양한 AI 도구 대시보드와 로컬 서비스 상태 확인을 위한 반복적인 컨텍스트 스위칭 발생. 브라우저 탭과 Electron 앱의 과도한 리소스 점유로 인한 시스템 부하 가중. OS 통합감이 낮은 기존 도구들의 사용자 경험 한계.

Technical Solution

  • 리소스 효율 극대화를 위해 Web-based 프레임워크를 배제하고 native framework인 SwiftUI 채택
  • 시스템 상주형 유틸리티 특성에 최적화된 Menu bar integration 설계
  • 복잡한 UI 구성 요소와 분석 차트를 제거하고 서비스 상태 및 쿼터 정보만 제공하는 미니멀리즘 인터페이스 구현
  • 외부 의존성을 최소화하여 바이너리 크기를 줄이고 런타임 안정성을 높인 구조
  • 별도의 푸시 서버 없이 일정 주기마다 상태를 확인하는 Polling 방식의 모니터링 로직 적용
  • macOS 전용 API를 직접 활용하여 Dark mode 및 알림 시스템의 기본 통합 구현

Impact

  • Binary size: ~200MB(Electron) $\rightarrow$ 15MB(SwiftUI)
  • Idle RAM: ~100MB(Electron) $\rightarrow$ ~12MB(SwiftUI)
  • Startup time: 2~4s(Electron) $\rightarrow$ 1s 미만(SwiftUI)

Key Takeaway

범용적인 크로스 플랫폼 지원보다 특정 OS의 Native API를 활용한 제약 조건 설정이 리소스 최적화와 사용자 경험 향상에 결정적인 영향을 미침.


시스템 상주형 유틸리티 설계 시 리소스 점유율이 핵심 지표라면 Electron보다 Native Framework 도입을 우선 검토할 것

원문 읽기