# Swift for Android - 안드로이드에서 Swift로 완전한 네이티브 앱 개발

> Clean Markdown view of GeekNews topic #25557. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=25557](https://news.hada.io/topic?id=25557)
- GeekNews Markdown: [https://news.hada.io/topic/25557.md](https://news.hada.io/topic/25557.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2026-01-05T00:32:50+09:00
- Updated: 2026-01-05T00:32:50+09:00
- Original source: [docs.swifdroid.com](https://docs.swifdroid.com/app/)
- Points: 3
- Comments: 1

## Topic Body

- **Swift만으로 Android 네이티브 앱을 개발**할 수 있는 프레임워크로, UI부터 매니페스트, 라이프사이클까지 단일 언어로 구성  
- XML, Java, Kotlin을 전혀 사용하지 않고 **선언형 UI 방식**으로 Android UI를 구성하는 구조 제공  
- 웹 래퍼나 트랜스파일러가 아닌 **순수 네이티브 Android 프레임워크**로 동작함  
- **SwiftUI와 유사한 선언형 문법**을 통해 UI를 정의할 수 있으며, 복잡한 JNI 계층을 완전히 숨김  
- Android Manifest와 Gradle 설정까지 **Swift 코드로 직접 정의**하는 통합 개발 경험 제공  
- Swift 개발자가 Android로 확장하기 위한 **새로운 네이티브 대안**이며, Swift 기반 크로스플랫폼 개발의 **새로운 가능성을 여는 전환점**  
  
---  
### Droid 개요  
- Droid는 Swift 언어만 사용해 **Android 네이티브 애플리케이션을 개발**할 수 있도록 설계된 프레임워크임  
- UI, 앱 설정, 라이프사이클, 매니페스트를 **하나의 언어와 코드베이스**에서 관리하도록 구성됨  
- Android 개발 시 필수로 여겨지던 XML, Java, Kotlin 의존성을 제거  
- AndroidX, Flexbox, Material Design 등 **안드로이드 네이티브 구성요소**를 포함  
- SwiftUI와 유사한 **선언형 문법**을 제공해 UI 정의를 단순화  
- JNI 계층을 완전히 숨기고, **고수준 API**로 접근 가능  
  
### 설계 목표와 특징  
- **Pure Swift** 기반으로 UI, 매니페스트, 앱 구성 전반을 Swift로 작성함  
- 선언형 UI를 채택해 **가독성과 조합성**을 중시  
- XML을 전혀 사용하지 않는 **No XML** 개발 방식 유지  
- 웹 기반 접근이나 코드 변환이 아닌 **Native Android 실행 모델** 채택  
- UI, 매니페스트, Gradle 의존성을 한 곳에서 정의하는 통합 구조 제공  
  
### 선언형 UI 구성 방식  
- Swift 친화적인 API를 사용해 Android UI를 선언적으로 구성  
- ConstraintLayout, VStack, TextView, MaterialButton 등 **Android 위젯을 Swift 코드로 표현**  
- 레이아웃 제약, 클릭 이벤트, 스타일 설정을 코드에서 직접 정의  
  
### Swift로 작성하는 Android Manifest  
- Android Manifest 자체를 Swift 코드로 선언  
- 앱 아이콘, 테마, 액티비티, 프래그먼트 설정을 코드 레벨에서 관리  
- 라이프사이클 이벤트 처리와 설정 로직을 **하나의 Swift 파일에서 통합**  
  
### 문서와 개발 환경  
- 공식 문서가 제공되며 **지속적으로 확장 중**  
- Android 전체 기능이 모두 문서화되지는 않았지만, 기존 가이드는 정제된 형태로 제공됨  
- Swift Stream IDE를 통해 **즉시 개발 시작 가능**  
  
### 지원 범위  
- Classic Android 위젯 지원  
- AndroidX 라이브러리 지원  
- Material Design 컴포넌트 지원  
- Flexbox 레이아웃 지원  
  
### 프로젝트 상태  
- 프로젝트는 **활발히 개발 중**이며 빠르게 진화하고 있음  
- API는 확장 가능성을 열어두고 개선 중이지만 핵심 비전은 유지됨  
- 피드백과 참여를 적극적으로 권장

## Comments



### Comment 48661

- Author: neo
- Created: 2026-01-05T00:32:50+09:00
- Points: 1

###### [Hacker News 의견들](https://news.ycombinator.com/item?id=46483023) 
- Swift Stream IDE v1.17.0를 공개했음. 이제 **Swift만으로 완전한 Android 앱 개발**이 가능해짐  
  XML, Java, Kotlin을 전혀 건드리지 않아도 됨. 내부적으로는 내가 만든 **SwifDroid 프레임워크**가 Android 생명주기, Activity, Fragment, UI 위젯(Material, Flexbox 등)을 처리하고 Gradle 의존성도 자동 관리함  
  Swift 코드를 컴파일해 Android Studio에서 바로 실행 가능한 프로젝트를 생성함. 툴과 프레임워크 모두 **MIT 오픈소스 라이선스**로 공개함
  - 흥미로움. Swift 개발자에게 필요한 Android 경험과, Android/Kotlin 개발자에게 필요한 Swift 경험의 **교차점**이 궁금함  
    XML, Java, Kotlin을 안 건드린다고 했는데, Android 경험이 전혀 없는 Swift 개발자도 성공적으로 앱을 만들 수 있는지 궁금함  
    또, 현재와 내년 기준으로 Kotlin이나 Flutter 앱 중 몇 퍼센트 정도를 Swift로 작성할 수 있을지도 알고 싶음
  - Swift의 강점 중 하나는 **C/C++ 라이브러리와의 상호운용성**임. 보통 SwiftPM이나 Bazel 의존성으로 제공되는데, SwiftPM 의존성은 어떻게 처리하는지 궁금함
  - Java/Kotlin 코드를 Swift로 **바인딩**하는 방식이 궁금함  
    우리는 비슷한 일을 Swift 대신 Rust로 시도 중임
  - 축하함. 나도 Swift로 개발 환경을 통합하려고 생각 중이었는데, 정말 멋진 작업임

- 이런 시도는 결국 **JNI를 거쳐야** 하기 때문에, API의 80%가 Java로만 노출된다는 점에서 한계가 있음  
  이런 프로젝트는 항상 흥미롭지만, 결국 **누수된 추상화(leaky abstraction)** 문제에 부딪히게 됨  
  마찬가지로 iOS에서는 Objective-C를 알아야 하고, Windows에서는 .NET/COM을 알아야 하는 것처럼 말임
  - 요즘은 Apple 생태계에서도 Swift와 Objective-C를 **둘 다 다뤄야** 성공할 수 있음  
    Unity 쪽 경험으로 보면, C#에서 C로의 마샬링은 부드럽지만 Swift는 훨씬 손이 많이 감  
    새로운 프레임워크마다 따로 대응해야 하는 현실임

- 플랫폼 간 공통 언어(Swift나 Kotlin)를 쓰는 건 겉보기엔 좋아 보이지만, 실제로는 기대만큼 효율적이지 않다고 생각함  
  결국 **두 개의 코드베이스**를 유지하게 되고, 차이점과 우회로가 많아져서 그냥 각자 언어를 즐기며 쓰는 게 낫다고 봄  
  대부분의 개발자는 여러 언어를 배우며 커리어를 쌓고, 전환도 어렵지 않음. 개인적인 의견이지만 프로젝트 자체는 훌륭하다고 생각함
  - 그래도 이런 시도 덕분에 한 플랫폼에 익숙한 엔지니어가 다른 플랫폼에서도 일할 수 있게 됨  
    나도 예전에 Java로 Android 네이티브 앱을 만들려고 몇 달 공부했지만 즐겁지 않아 포기했음  
    **완전한 네이티브 개발**을 선호하는 편이고, 수십 년간 크로스플랫폼 프레임워크를 써봤지만 큰 성공을 거둔 적은 없음  
    언어 전환에는 항상 **맥락 전환 비용**이 따름. Swift와 PHP를 오가며 개발할 때마다 문법 실수를 자주 함  
    언어는 금방 배워도, SDK·표준 라이브러리·프레임워크는 숙련까지 **오랜 시간**이 걸림
  - 이런 프레임워크들은 단순한 기능 개발은 빠르지만, **플랫폼 특화 기능**을 쓰려 하면 오히려 방해가 됨  
    특히 요즘은 AI 도구 덕분에 단순 작업 속도가 이미 빨라져서, 전체 개발 시간 절감 효과가 크지 않음  
    앱이 사실상 웹앱 수준이라면 몰라도, 그렇지 않다면 추천하지 않음
  - Kotlin과 Swift는 매우 비슷하고, 차이가 있는 부분은 오히려 **추상화하지 않는 게 낫다고** 생각함  
    Swift가 언어적으로는 더 낫다고 보지만, KMP가 더 오래되고 안정적이라 실제로는 그쪽을 쓸 듯함
  - 여러 언어를 아는 건 오히려 **자유로움**을 줌  
    하지만 특정 대기업 생태계에 더 종속되는 건 꺼려짐  
    게다가 Swift는 개인적으로 **불편한 언어**라, 굳이 다른 플랫폼에서도 쓰고 싶지는 않음

- [Skip](https://skip.tools/)과 비교하면 어떤지 궁금함  
  이 프로젝트는 iOS SwiftUI 코드를 Android로 옮기는 게 아니라, **Android 전용 Swift 개발**에 초점을 둔 듯함  
  그게 더 나은 앱 품질로 이어질 수 있을지, 실제 사례가 있는지 알고 싶음

- Android Studio나 IntelliJ를 안 써도 된다는 점만으로도 **큰 개선**이라고 생각함. 멋진 일임
  - Android를 피하려고 Xcode를 쓰는 건, **염산을 만지는 것과 비슷한 선택** 같음
  - Gradle도 피할 수 있는지 궁금함. 그 **의존성 관리 악몽**을 건너뛰는지 알고 싶음

- 쿠키 동의창이 **유럽 법규에 부합하지 않는** 느낌임

- 왜 모바일 개발은 PC보다 이렇게 **불편한지** 모르겠음  
  왜 모바일에서 어셈블리로 Hello World 하나 만드는 것도 이렇게 어려운지 궁금함
  - 만들 수는 있음. 하지만 PC에서 어셈블리로 Hello World 만드는 것만큼 **고통스러운 일**이라 아무도 하지 않음

- Android 개발을 한동안 쉬었는데, 요즘 상황을 정리해보면  
  예전엔 iOS는 Swift, Android는 Java였고  
  지금은 Java 대신 **Kotlin**, 그리고 **Flutter**나 **React Native** 같은 크로스플랫폼 프레임워크가 생겼음  
  Swift on Android는 이런 것처럼 또 다른 **추상화 레이어**인지, 아니면 네이티브에 가까운지 궁금함  
  결국 가장 빠른 건 **네이티브 코드** 아닌가?
  - React Native는 웹뷰 기반이 아님. JSX를 **SwiftUI/Kotlin UI 코드로 변환**하는 네이티브 번역 계층임  
    개인적으로는 Flutter를 선호함. 많은 Android 네이티브 개발자들도 Flutter가 **Android 개발의 미래**일 수 있다고 말함  
    관련 토론은 [이 Reddit 스레드](https://old.reddit.com/r/androiddev/comments/1np26m4/do_other_android_devs_feel_this_way_about_flutter/) 참고

- 이 프로젝트는 SwiftCrossUI나 Skip과는 다른 접근임  
  SwiftCrossUI와 Skip은 SwiftUI를 그대로 여러 플랫폼에서 돌리지만,  
  SwifDroid는 **Android 전용 UI를 Swift로 작성**하는 것임  
  Android의 View 시스템과 API를 직접 사용하면서, Java/Kotlin/XML 없이 완전한 Android 앱을 Swift로 만드는 게 목표임  
  즉, “한 번 작성해 어디서나 실행”이 아니라, **Android 네이티브 경험을 Swift로 구현**하는 방향임

- Swift에서 **HTTP 요청과 JSON 파싱을 관용적으로** 처리하는 방법이 궁금함
