Xamarin

 

1. 개요
2. 세부사항
2.1. Xamarin.Android
2.2. Xamarin.iOS
2.3. Xamarin.Mac
2.4. Xamarin.Forms
2.5. Xamarin Test Cloud
2.6. Xamarin Insights
2.7. Xamarin.Essentials
3. 경쟁상대
4. 외부 링크


1. 개요

C\#과 .NET Framework를 리눅스에서도 쓸 수 있게 해주는 Mono 프로젝트에서 시작된 프레임워크이나 현재 Xamarin은 리눅스를 공식 지원하고 있지 않다. 한국어로는 자마린이라고 읽고 쓰면 어지간하면 뜻이 통한다. 실제 발음은 즈애마ㄹ린에 가까운 편.
안드로이드가 리눅스를 기반으로 세계를 지배하고 윈도우폰이 죽을 쑤자 마소에서는 이에 대응하여 .NET Framework와 C\#으로 안드로이드와 아이폰을 개발하고자 하는 시도 차원에서 Xamarin이 등장하였다.
안드로이드와 iOS의 API가 준비되어 있기 때문에 크로스 플랫폼 축에 약간 넣을수 있는 정도다. 한번 작성한 폼과 로직이 안드로이드와 아이폰에서 유사하게 작동하고 동시에 유지보수가 가능하다.
Mono를 주도해온 멕시코계 냇 프리드먼과 미구엘 데 이카사(CTO)가 설립하였으며 2016년 2월 24일 마이크로소프트가 인수, 2016년 3월 31일 소스를 공개하였다.
2020년 하반기에 따로 분리되어 있던 .NET 플랫폼들이 하나로 합쳐지는 과정의 초석인 .NET 5가 2020년 하반기에 출시한 후 얼마 지나지 않아 이후 버전인 .NET 6 출시에 맞춰 Xamarin 프레임워크에 변화가 있을 것이라고 예고되었다. # 현재 이 프로젝트는 .NET MAUI('''M'''ulti platform '''A'''pp '''UI''')라고 발표되었으며 인기없는 자마린을 리브랜딩한 정도로 볼 수 있다.

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 는 출시당시에는 개발자들의 호응을 얻었으며 Cross-Platform 개발이 이루어졌다. MS의 WPF와 C#과 XAML를 사용한다는 공통점은 있으나 WPF와 Xamain/MAUI의 widget및 라이브러리 사용에 있어 세부적인 차이점이 있어 거의 다른 프래임워크라 할수 있어 학습량이 증가한다는 단점이있다.
new Label() 하면 Android iOS WPF UWP macOS Tizen 으로 모두 번역해준다. 다양한 nuget 패키지들과 함께 이용하면 90% 이상의 코드를 공유할 수 있으며 10%이하의 OS 별 코드를 작성하여 여러 OS 용 네이티브 앱 개발이 가능하다. WPF 와 마찬가지로 Code 스타일과 Xaml (재믈) 스타일이 있다. 장단점이 있으며 개발환경/취향에 따라 선택하면 된다.
그러나, 위의 이야기는 양쪽 플랫폼을 자유롭게 다룰 인력이 없는 개발사에 해당하고, iOS/Android 개발 인력과 기획자가 갖춰져있는 팀의 경우 아직까지는 기존의 네이티브로 하는 것이 빠를 수 있다. 게임의 경우 기존 네이티브에서 제공되는 UI를 사용하는 경우가 거의 없고, 아예 해당 게임에 맞는 UI 를 바닥부터 개발하는것이 대부분이기에 유니티 같은 Cross-Platform 개발이 유리하지만, 게임 외의 앱들은 네이티브에서 제공하는 UI를 사용해야 하기에 오히려 작업이 늘어나는 경우도 있다.
예를들어, 버튼 하나에 이미지를 입히는 작업만 보더라도, 이벤트 처리 코드는 공유하지만 이벤트 처리는 대부분 서버연동이나 페이지 전환이기 때문에 애초에 몇 줄 절약되지도 않으며, 반면에 안드로이드의 해당 버튼을 포함하고 있는 페이지의 layout 파일 작업, 해당 버튼의 상태별 이미지를 보여줄 selector 파일 작업, iOS 의 해당 버튼의 상태별 이미지 제어 코드작업을 해야하는데, 이렇게 작업하고도 기존의 네이티브 UI의 세부적인 설정을 100% 구현하지 못하는 부분들이 있으며, 버튼 하나 하나 마다 이렇게 C# style, Android style, iOS style 을 왔다갔다 하면서 작업해야한다.
그리고 네이티브 SDK의 기본이라 할 수 있는 WYSIWYG 방식의 개발도 사실상 불가능하다.
뿐만아니라, 앱의 크기에 있어서도 기존의 네이티브로 만들면 몇 KB로 끝나는 HelloWorld 정도만 구현해도 소중한 iPhone 용량을 60MB 나 차지해버리며, 프로젝트를 완성하면 수백MB 를 차지하는데... 기존 방식으로는 몇십MB 로 끝날 내용이다. 결국 게임도 아닌 앱이 게임처럼 메모리 문제로 다운되는 답없는 상황으로 이어지기 쉽다.[1]
결정적으로 레퍼런스가 너무나도 부족하다. 당장 '버튼 이미지 세팅하고 크기 바꾸는 법'을 찾아보면 깨닫게 된다. 국내 도서는 전무하며, 공식 홈페이지 자료는 애플이나 구글의 공식 자료에 비해 너무나도 부실하기에 구글같은 수준의 레퍼런스를 기대하고 개발하다간... Stack Overflow에조차도 제대로 된 설명이 없어서, 오류가 하나 생길 때마다 Xamarin 개발진과 영어로 소통을 해가며 개발하는 개척자의 기분을 느낄 수 있으므로 회사의 프로젝트에 도입을 하기 전에 충분한 연구가 필요하다. 책이 한두개 나오고 최적화가 어느 정도 될 때까지 기다리자. [2]
위 반론은 리모릭스 개발 이야기 와 상통하는 이야기로 Xamarin.Android 와 Xamarin.iOS 를 사용하여 5만건이상의 (2017.2 기준) 다운로드를 기록한 성공적인 앱을 만든 노하우와 시행착오가 들어있는 글이다. 하지만 Xamarin.Forms 를 적극 도입하지 않았기에 자마린의 장점을 극대화했다고 할수없다.(개발시작시점에 XF가 없었던것으로 보임) 또한 기존 axml 과 storyboard 같은 UI 구성지식이 없어야 오히려 XF 를 적극 도입하게 되며 약간의 custom renderer 코드만 추가하면 못만들 UI 가 없다. new StackLayout().to 라고 치면 각종 애니메이션 관련 메소드들이 나온다.
apk와 ipa의 기본용량은 10~20MB이며 곧 나올 XF 2.4와 2.5[3] 에서 안드로이드 관련 최적화가 더욱 이루어질 예정이다. 구글에서 영문검색으로 자료를 찾으면 대부분의 문제들이 이미 논의되어 있다.
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[4] 이 추가되었고 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를 구현해주기 때문에 시스템적 변경이나[5] 퍼포먼스 문제에서 자유롭다는걸[6] 강점으로 밀어주고 있으며 이때문인지 자마린 쪽에서 플러터의 렌더링 렌진인 스키아를 자마린 환경에서 쓰게 해주는 SkiaSharp가 나오기도 했다. 2020년9월현재 Xamarin/MAUI는 Flutter를 비롯하여 react native에도 밀리고 ionic에도 밀려 크로스플랫폼 프래림워크 시장에서 시장점유율이 바닥을 기고 있는 상태이다.
  • React Native

4. 외부 링크

공식홈페이지
오픈소스
한글 MSDN
Weekly Xamarin
국내 커뮤니티 네이버 카페
국내 커뮤니티 페이스북 공개그룹

[1] 물론 이문제는 자마린 뿐만 아니라 플러터등의 다른 크로스 플랫폼 개발 프레임워크에 다 해당되는 문제다. 같은 크로스플랫폼 개발 프레임워크끼리 비교하면 바이트코드가 조금이라도 더 작은 자마린이 좀더 작게 나오는 경우가 많다. 물론 큰 차이는 아니다.[2] 물론 이건 국내 한정이고 실제로는 자마린이 크로스플랫폼 프레임워크중 일찍 나온 편에 속하기 때문에 다른 개발 플랫폼 비해 많다고 평가된다. [3] 출시되었다.[4] css의 flexbox와 유사하다.[5] 자마린 네이티브나 자마린 폼즈는 해당 플랫폼에 맞춰서 네이티브 코드로 바꿔주는 식으로 구현되기 때문에 시스템적으로 UI관련 구성요소가 바뀔경우 같이 바뀌는 경우가 보고되는 경우가 있었다.[6] 퍼포먼스적인 면에서 거의 비슷하긴 하지만 플러터쪽이 헤비한 UI환경에서 더욱 강한 모습을 보여준다고 평가된다#

분류