Xamarin.iOS + .PCL 로 두달간 삽질했다

.Forms  쓰면 하나의 비즈니스 로직으로 두 플랫폼에서 UI가 뙇! 이라는 것에 좀 끌린적도 있지만, 

애초에 복잡한 부분은 UI, UX 이고, rendering 공부하고 짜주는것도 ㅈㄴ 일이라는거 알아서 그냥 .iOS + .PCL 조합으로 갔다. 나중에  .Droid 추가할려고.

그나마 저 조합으로  간 덕분에, 코딩하다 막히는거 있으면 바로바로 iOS native 레퍼런스들 바로바로 참고해서 해결할 수 있었고, 와 씨발 진짜 대박이다 이거, C# 존나 쉽고 좋은데 앞으로 objC swift 쓸일은 없겠구만 하고 혼자 산삼 발견한마냥 좋아했던게 지난 두달이었다


처음은 좋았다 처음은. 어느거나 늘 그렇듯 


개고생은 얼마전부터 시작되었다. 이제 슬슬 앱 완성단계가 한 30%쯤 된거 같고, 이것저것 좀 이쁜 iOS  UI library 를 쓰고 싶었는데, 서드파티 라이브러리는 당연하게도 네이티브용으로만 만들어진다. 그래서 와 존나 이쁘다 저거 쓰고싶다 이러면서 군침 흘리다가


objective c binding 이라는걸 알게 되고, 이거 한 일주일동안 레퍼런스 문서 존나 읽고 개고생하면서 그나마 좀 할만했던 라이브러리 하나 바인딩하는데 성공했다. TOCropViewController 라고, 당연히 바인딩만 시키는거니 성능도 네이티브랑 똑같음 와 개좋다 이러면서 일주일간의 개고생을 혼자 치하함


그리고 다음 고생이 시작됐는데, 그담엔 오디오 라이브러리를 좀 써보고 싶어서, EZAudio 를 바인딩하려고 고생하기 시작했다. 바로 전에 일주일간 고생한게 있어서 그런지 이거 일단 바인딩 밑작업은 어느정도 했고 이제 손으로 하나하나 자동생성된 코드 수정하는 파트였는데


한 부분에서 막혔다. 근데 존나 심각한 문제다. objC를 c#으로 바인딩되는 작업은 btouch 라는 툴로 돌아가는데, EZAudio 에서 쓰는 float** 타입을 btouch 에서 지원을 안한다 카더라. 그냥 좀 많이 쓰이는 놈들만 만들어놨다고. ㅅㅂ. 저 float** 타입이 버퍼로 쓰이는 놈이라 수정하기도 존나 귀찮을뿐더러, 이런 문제가 나중에 또 나타나지 말라는 보장이 없었다. 아 일단 또 생각나는게, c 에서 typedef 에 해당하는게 c#에는 없어가지고, 변형으로 클래스 만들고 private value 잡은다음에 operator overloading 시켜야 하는데, 성능면에서 당연히 손해가 존나 클거같더라.


또 하나 문제는, iOS에서 고속 연산을 위해서 만들어놓은 accelerate framework 가 있는데, xamarin.iOS에선 이걸 일부만 포팅 해놨다. 이런 문제들이 하나하나 발견될때마다, 아 씨발 네이티브 쓰면 이런 고민 할 필요 없는데 이런 생각 들면서, 처음에 좋았던 그 모든게 지금은 회의적으로 바뀌게 되었다.


그리고 결정적으로, 앱을 개발해보니 대부분의 어려운 파트들이 로직 보다는 UX,UI 컨트롤에서 생긴는데, 실제 자마린 크로스 플랫폼이 해결해주는건 쉬운 비즈니스 로직 쪽이다. 즉 쉽게 말해서, 그냥 적당하게 View 몇개 넣고 이미지 몇개 넣고 이런 수준에서 만드는건 자마린이 훨씬 쉬울 수 있는데, 여기서 실제 상용화 할 정도의 효과 주고 디테일한 부분을 건드리기 시작하면 그때부터 자마린이 해준것만 쓸 수 있고 나머지는 손가락 빨면서 구경해야한다는건데, 이게 과연 얼마나 심해질지 계속 불안해져갔다.


내가 이걸 처음 시작할때 몰라서 지금껏 개고생 했는데, 결국 결론은 네이티브가 답이라는걸 깨닫기까지 두달이 걸렸다. 나중에 앱 만들어서 유지보수 할때도, 니가 직접 할게 아니면, 자마린을 수준급으로 쓰는 개발자를 찾아야하는데 이것도 존나 힘든 일이라는건 불보듯 뻔했다.


그래서 난 오늘부로 자마린 접고 스위프트 공부 시작한다. 크로스 플랫폼의 헛된 꿈을 쫒지 말고 그냥 네이티브 공부해라. 제일 속 편한거같다.