1. 개요
C#과 .NET Framework를 리눅스에서도 쓸 수 있게 해주는 Mono 프로젝트에서 시작된 프레임워크이다.기본적인 구상은 .NET Framework와 C#으로 안드로이드와 아이폰을 개발하고자 하는 시도이며 이에 따라 .Net을 오픈 소스화 한 Mono의 제작자들이 Monodroid와 Monotouch 라는 라이브러리가 만들어졌으며 이후 이 프로젝트가 제작자가 속한 Xamarin이란 회사의 관리하에 Xamarin으로 이름이 변경된 후 MS가 인수하면서 지금의 자마린이 되었다[1]
안드로이드와 iOS의 API가 준비되어 있기 때문에 크로스플랫폼 축에 약간 넣을 수 있는 정도다. 한번 작성한 폼과 로직이 안드로이드와 아이폰에서 유사하게 작동하고 동시에 유지 보수가 가능하다.
Mono를 주도해 온 멕시코계 냇 프리드먼과 미겔 데이카사(CTO)가 설립하였으며 2016년 2월 24일 마이크로소프트가 인수, 2016년 3월 31일 소스를 공개하였다. 다만 이 이후에도 자마린은 모노에 베이스하고 있던 관계로 계속해서 업데이트 중이던 .NET Framework에 못 따라가는 모습을 보여줬고 따라서 다른 후발 주자에 밀리는 이유가 되었다.
2020년 하반기에 따로 분리되어 있던 .NET 플랫폼들이 하나로 합쳐지는 과정의 초석인 .NET 5가 2020년 하반기에 출시한 후 얼마 지나지 않아 이후 버전인 .NET 6 출시에 맞춰 Xamarin 프레임워크에 변화가 있을 것이라고 예고되었다. # 현재 이 프로젝트는 .NET MAUI(_M_ulti platform _A_pp _UI_)라고 발표되었으며, 결국 React Native와 Flutter등에 밀려 2024년 5월 1일부로 지원 종료되었다.
MAUI와 자마린이 같다고 오해하는 사람들도 있는데 MAUI가 자마린에 기반하고 있는 것 자체는 사실이지만 내부적인 구조가 거의 바뀌었기 때문에[2] 기존과는 취급법이 달라졌으며 프로젝트 하나로 모든 플랫폼을 관리할 수 있는 기능과[3] 핫 리로드가 지원되는 등 편의성 또한 증대되었다.
2. 세부사항
2.1. Xamarin.Android
Mono for Android에서 개명되었다. 안드로이드의 API를 C# 스타일의 API로 바꾸어 구현하였다.이후 2021년 11월에 공식 릴리스 예정인 .NET 6에 .NET for Android란 명칭으로 바뀌어 포함될 예정이다.
2.2. Xamarin.iOS
MonoTouch에서 개명되었다. iOS의 API를 C# 스타일의 API로 바꾸어 구현하였다.이후 2021년 11월에 공식 릴리스 예정인 .NET 6에 .NET for iOS란 명칭으로 바뀌어 포함될 예정이다.
2.3. Xamarin.Mac
MacOS 서포트 버전. 해외에선 이를 이용한 유료 앱도 출시되어 있다.2.4. Xamarin.Forms
2014년 뒤늦게 출시된 Xamarin.Forms는 출시 당시에는 개발자들의 호응을 얻었으며 크로스플랫폼 개발이 이루어졌다. MS의 WPF와 C#과 XAML를 사용한다는 공통점은 있으나 WPF와 Xamain/MAUI의 widget 및 라이브러리 사용에 있어 세부적인 차이점이 있어 거의 다른 프레임워크라 할 수 있어 학습량이 증가한다는 단점이 있다.new Label() 하면 Android iOS
그러나, 위의 이야기는 양쪽 플랫폼을 자유롭게 다룰 인력이 없는 개발사에 해당하고, iOS/Android 개발 인력과 기획자가 갖춰져 있는 팀의 경우 아직까지는 기존의 네이티브로 하는 것이 빠를 수 있다. 게임의 경우 기존 네이티브에서 제공되는 UI를 사용하는 경우가 거의 없고, 아예 해당 게임에 맞는 UI 를 바닥부터 개발하는 것이 대부분이기에 유니티 같은 크로스플랫폼 개발이 유리하지만, 게임 외의 앱들은 네이티브에서 제공하는 UI를 사용해야 하기에 오히려 작업이 늘어나는 경우도 있다.
예를 들어, 버튼 하나에 이미지를 입히는 작업만 보더라도, 이벤트 처리 코드는 공유하지만 이벤트 처리는 대부분 서버 연동이나 페이지 전환이기 때문에 애초에 몇 줄 절약되지도 않으며, 반면에 안드로이드의 해당 버튼을 포함하고 있는 페이지의 layout 파일 작업, 해당 버튼의 상태별 이미지를 보여줄 selector 파일 작업, iOS 의 해당 버튼의 상태별 이미지 제어 코드 작업을 해야 하는데, 이렇게 작업하고도 기존의 네이티브 UI의 세부적인 설정을 100% 구현하지 못하는 부분들이 있으며, 버튼 하나하나마다 이렇게 C# style, Android style, iOS style을 왔다 갔다 하면서 작업해야 한다.
예를 들어, 버튼 하나에 이미지를 입히는 작업만 보더라도, 이벤트 처리 코드는 공유하지만 이벤트 처리는 대부분 서버 연동이나 페이지 전환이기 때문에 애초에 몇 줄 절약되지도 않으며, 반면에 안드로이드의 해당 버튼을 포함하고 있는 페이지의 layout 파일 작업, 해당 버튼의 상태별 이미지를 보여줄 selector 파일 작업, iOS 의 해당 버튼의 상태별 이미지 제어 코드 작업을 해야 하는데, 이렇게 작업하고도 기존의 네이티브 UI의 세부적인 설정을 100% 구현하지 못하는 부분들이 있으며, 버튼 하나하나마다 이렇게 C# style, Android style, iOS style을 왔다 갔다 하면서 작업해야 한다.
그리고 네이티브 SDK의 기본이라 할 수 있는 WYSIWYG 방식의 개발도 사실상 불가능하다. 뿐만 아니라, 앱의 크기에 있어서도 기존의 네이티브로 만들면 몇 KB로 끝나는 HelloWorld 정도만 구현해도 소중한 iPhone 용량을 60 MB나 차지해 버리며, 프로젝트를 완성하면 수백 MB를 차지하는데... 기존 방식으로는 몇십 MB로 끝날 내용이다. 결국 게임도 아닌 앱이 게임처럼 메모리 문제로 다운되는 답 없는 상황으로 이어지기 쉽다.[4]
결정적으로 레퍼런스가 너무나도 부족하다. 당장 '버튼 이미지 세팅하고 크기 바꾸는 법'을 찾아보면 깨닫게 된다. 국내 도서는 전무하며, 공식 홈페이지 자료는 애플이나 구글의 공식 자료에 비해 너무나도 부실하기에 구글 같은 수준의 레퍼런스를 기대하고 개발하다간.... Stack Overflow에조차도 제대로 된 설명이 없어서, 오류가 하나 생길 때마다 Xamarin 개발진과 영어로 소통을 해가며 개발하는 개척자의 기분을 느낄 수 있으므로 회사의 프로젝트에 도입을 하기 전에 충분한 연구가 필요하다. 책이 한두 개 나오고 최적화가 어느 정도 될 때까지 기다리자. [5]
위 반론은 리모릭스 개발 이야기와 상통하는 이야기로 Xamarin.Android와 Xamarin.iOS를 사용하여 5만 건 이상의(2017.2 기준) 다운로드를 기록한 성공적인 앱을 만든 노하우와 시행착오가 들어있는 글이다. 하지만 Xamarin.Forms를 적극 도입하지 않았기에 자마린의 장점을 극대화했다고 할 수 없다(개발 시작 시점에 XF가 없었던 것으로 보임). 또한 기존 axml과 storyboard 같은 UI 구성 지식이 없어야 오히려 XF를 적극 도입하게 되며 약간의 custom renderer 코드만 추가하면 못 만들 UI 가 없다. new StackLayout().to라고 치면 각종 애니메이션 관련 메소드들이 나온다.
apk와 ipa의 기본 용량은 10~20 MB이며 곧 나올 XF 2.4와 2.5[6]에서 안드로이드 관련 최적화가 더욱 이루어질 예정이다. 구글에서 영문 검색으로 자료를 찾으면 대부분의 문제들이 이미 논의되어 있다.
Xamarin Forms는 개발진 측에서도 플랫폼 의존도가 적고 커스텀 UI의 중요도가 적은 곳에 적합하며(이름부터가 폼 형식에 적합하다는 의미를 갖고 있다.) 반대로 플랫폼 고유 API 지향적이며 디자인된 UI를 중시하는 경우(사이트에 그림으로 예시하는 것들은 것은 미디어 플레이어, 게임, 지도 앱)에는 Xamarin Native(Android, iOS)를 권장하고 있다. Xamarin Forms는 UI 레이아웃과 페이지 로직의 코드까지 하나로 공유하기 때문에 다중 플랫폼 개발에 있어서 각각 모두 따로 코딩해야 하는 네이티브에 비해 확실하고 분명한 강점이 있으나 그만큼의 제약과 오버헤드되는 단점들과의 타협이 필요하다. 특히 안드로이드 쪽은 앞에서도 언급된 메모리 이슈 및 기본으로 생성되는 'Welcome to Xamarin Forms!'마저도 실행하는 데 네이티브에 비해 기기에 따라 2~3초 정도씩 더 소요되며 아직은 구현이 덜 되거나 버그성 API들도 있다. 제약이 되는 부분들은 인터페이스 작성한 뒤 DependencyService를 통해 플랫폼별로 구현하고 커스텀 UI도 Custom Renderer 써서 플랫폼별로 구현하면 네이티브와 다를 게 없다지만 그럴거면 그냥 네이티브로 작성하는 것에 비해 메리트가 크게 상쇄되니....... 다만 적은 인력으로 빠른 시간 안에 멀티플랫폼 개발을 해야 하는 경우 충분히 고려해 볼 만한 가치가 있으며 개발진 측에서도 포럼을 통해 최적화에 힘쓰고 있다고 하니 앞으로를 기대해 보도록 하자.
Xamarin.Forms 3.0이 출시되었다(2018.5).
FlexLayout[7] 이 추가되었고 CSS까지 지원한다. WPF도 공식 지원 한다.
.NET 5가 2020년 하반기에 출시된 후 앞으로의 로드맵이 공개되었는데 Xamarin.Forms를 기반으로 하는 .NET MAUI로 점차 이전된다고 한다.
다만, 이전 작업이 이루어지고 .NET MAUI 공식 릴리스 이후에도 계속 지원을 하며 2022년 하반기까지 업데이트가 예정되어 있다고 한다.
.NET 공식 블로그 - .NET MAUI
Xamarin.Forms Roadmap
2.5. Xamarin Test Cloud
앱 동작 순서를 입력해 놓으면 2000여개의 실기기에서 자동으로 테스트해 주고 로깅해 준다(유료).2.6. Xamarin Insights
앱 내부에서 일어나는 크래시나 기타 정보를 서버로 전달하여 로깅해 준다. HockeyApp과 통합되었다.2.7. Xamarin.Essentials
모든 기종에서 공유하는 하드웨어적 접근 사항에 대한 API, 폰의 센서나 기본 기능을 활용하는 분야에 대해서 통합된 경험을 제공한다.3. 경쟁상대
- Flutter(프레임워크) - 구글이 밀어주는 프레임워크. 네이티브 변환 없이 별도의 렌더링 엔진으로 UI를 구현해주기 때문에 시스템적 변경이나[8] 퍼포먼스 문제에서 자유롭다는걸[9] 강점으로 밀어주고 있으며 이때문인지 자마린 쪽에서 플러터의 렌더링 렌진인 스키아를 자마린 환경에서 쓰게 해주는 SkiaSharp가 나오기도 했다.
- React Native
4. 외부 링크
공식홈페이지오픈소스
한글 MSDN
Weekly Xamarin
국내 커뮤니티 네이버 카페
국내 커뮤니티 페이스북 공개그룹
[1] 여담으로 Mono와 자마린을 만든 미겔 데이카사는 자마린이 인수되면서 MS의 직원이 되었고 .NET 재단에서 있으면서 .NET의 오픈 소스화에 가장 많은 영향을 준 인물로 평가받는다.[2] 가장 큰 변화는 렌더링 구조의 변화로 기존에 각 플랫폼별 다른 라이브러리를 사용하는 구조였지만 MAUI부터는 공통 라이브러리를 사용한다.[3] 자마린은 iOS, 안드로이드별로 따로따로 프로젝트를 만들어서 관리해야 되지만 MAUI는 프로젝트 하나에서 모든 플랫폼을 대상으로 개발할 수 있다.[4] 물론 이 문제는 자마린뿐만 아니라 플러터 등의 다른 크로스플랫폼 개발 프레임워크에 다 해당되는 문제다. 같은 크로스플랫폼 개발 프레임워크끼리 비교하면 바이트코드가 조금이라도 더 작은 자마린이 좀 더 작게 나오는 경우가 많다. 물론 큰 차이는 아니다.[5] 물론 이건 국내 한정이고 실제로는 자마린이 크로스플랫폼 프레임워크 중 일찍 나온 편에 속하기 때문에 다른 개발 플랫폼에 비해 많다고 평가된다.[6] 출시되었다.[7] css의 flexbox와 유사하다.[8] 자마린 네이티브나 자마린 폼즈는 해당 플랫폼에 맞춰서 네이티브 코드로 바꿔주는 식으로 구현되기 때문에 시스템적으로 UI관련 구성요소가 바뀔경우 같이 바뀌는 경우가 보고되는 경우가 있었다.[9] 퍼포먼스적인 면에서 거의 비슷하긴 하지만 플러터쪽이 헤비한 UI환경에서 더욱 강한 모습을 보여준다고 평가된다#