카테고리 보관물: Mobile

Objective-C는 Swift의 친구가 될 수 있을까?

이제는 Swift도 꽤나 익숙하게 들리는 언어가 되었습니다. 저에게만 그런가요?
아마도 Swift를 배우고 있거나 실제로 사용하는 분들도 꽤 계실거로 생각됩니다. 저도 아직까지는 Objective-C가 훨씬 편하고 익숙하지만, 그래도 Swift를 아예 무시할 수는 없겠죠. 언제 애플이 Objective-C를 팽할지 모르니까요… 또르르..
Apple_Swift_Logo

Swift 로고
[출처 : Wikipedia – http://en.wikipedia.org/wiki/File:Apple_Swift_Logo.png ]

 

지난번 글에서는 너무 Swift를 부정적으로만 표현한 것 아닌가 싶기도 하고, 지금은 좀 더 Swift의 많은 면을 볼 수 있어서 지난번과는 조금은 다른 관점(?)으로 글을 쓸 것 같아요. 더 좋은 쪽으로!?

요즘에는 왠만하면 프로젝트 내에서 신규 클래스는 Swift로 작성하려고 노력중입니다. 이렇게 Objective-C랑 짬뽕혼합하여 사용하다보니, 그리 나쁘지만은 않더라구요. Objective-C의 장점과 Swift의 장점을 모두 취할 수 있으니까요.유후

Swift와 Objective-C를 한 프로젝트에서 함께 활용할 수 있는 방법은 애플에서 도큐먼트에 친절히 적어두었어요. 참고하세요.

하.지.만. 언제나 그렇듯 위험은 곳곳에 숨어있습니다. 두 언어의 차이점에서 비롯된 이점도 있지만 문제점도 분명히 드러납니다. 좋은점이 있으면 좋지 못한 점도 있기 마련. 좋은 점과 좋지 못한 점, 둘 중 뭐를 먼저 알고 싶으세요? 아마도 좋지 못한 점이 먼저 나오는게 좋을 것 같아요 ㅎㅎ 사실 좋지 않은 점이라기 보다는 그냥 제가 삽질한 것들이라… 후우… 그냥… 뭐랄까.. 넋두리… 네… 그렇습니다. 여러분들은 겪지 않으시길 바라면서! 하핳

제가 겪었던 빅삽질 들을 소개합니다!

b0036170_2231044

오예, 역시 프로그래밍은 삽질이 제맛이지

두 언어에는 서로 가지지 못한 것들이 존재합니다. 같은 듯 다른 듯 비슷한 기능들도 많은데요, 그 중 하나 카테고리(category)익스텐션(extension)이 되겠습니다.
Objective-C에서 저는 카테고리를 굉장히 즐겨쓰는 편입니다. 확장의 용이성과 간편함 때문인데요, 그에 대적할 기능이 스위프트에서는 익스텐션이라 말할 수 있겠습니다. 이에 관련된 에피소드를 소개합니다.
기존 프로젝트에서 저는 NSDictionary의 카테고리로 customMethod라는 메소드를 생성해 줬어요. 그런데 스위프트에서 코딩을 해주다가 저도모르게 NSDictionary의 익스텐션으로 customMethod라는 녀석을 만들어줬지 뭐예요? 서로 다른 이름의 기능이지만, 실제사용은 거의 똑같은 두 녀석. 결과는 어떻게 되었을까요?

13784314429c0c5517edf2134

결과는 카테고리의 승리였어요.

스크린샷 2015-03-11 오후 6.14.52

같은 이름으로 메소드를 호출해 주었을 때, 카테고리의 메소드가 호출이 되더라구요.  왜 그런가 곰곰이 찾아보고 고민해 봤는데, 아무래도 기능의 특성상 그런 것은 아닐까 조심스레 추측해 봅니다. 카테고리는 기존 클래스에 정의되어있는 메소드를 오버라이드 할 수 있습니다. 하지만 스위프트의 익스텐션은 그것이 불가능 하지요. 그렇기 때문에 런타임에서 유연하게 동작하는 특성과 오버라이딩이 가능한 특성 때문에 카테고리 메소드가 우위로 호출되는 것 같습니다. 그것도 모르고 저는 왜 자꾸 다른 결과물이 나오는지 갑갑해서 잠시 이성을 잃었답니다. 여튼, 이런 다르면서도 비슷한 기능들을 사용할 때, 주의해야겠어요.

또 한가지는 튜플(tuple)이었는데요, Objective-C에서는 튜플이라는 자료형이 존재하지 않지요. 다른 언어에도 있지만 Objective-C에서는 사용할 수 없던 녀석인데, Swift에서는 더 쉽게 사용할 수 있어서 몇몇 메소드에 적용을 해 봤어요. 그런데 그 메소드를 Objective-C 코드에서 사용해야 할 일이 생긴거예요. 하.지.만. Objective-C에서는 튜플 자료형을 사용하는 메소드에 접근할 수 없어요. 정확히 말하자면 튜플을 사용할 수 없어요(위의 애플 도큐먼트에서 확인 가능합니다). 그래서 Objective-C 메소드로 전달해줄 추가메소드를 작성해 주어야 했지요.

예를들어 위와같은 Swift 클래스에 두 클래스 함수가 구현되어 있을 때, Objective-C에서 commonMethod는 자유롭게 호출할 수 있지만, tupleMethod는 찾을수 없다며 에러를 뱉어냅니다.

스크린샷 2015-03-11 오후 6.29.58

하지만 주의할 점들만 빼면 좋은점들이 훨씬 많지요! 좀 더 유연하게 자신만의 스타일로 코딩을 할 수 있는 스위프트 덕분에 Objective-C에서 복잡하게 구현해야 했던 것들을 좀 더 쉽게 만들어 낼 수 있습니다. 예를들어 연산자 재정의나 제네릭 기능 같은 경우 Objective-C에서 어렵게 구현해야 했던 것들을 좀 더 간편한 방법으로 구현할 수 있는 길이 열리는데요, 이를 Objective-C에서 직접 접근하지 못하는 경우가 있다 하더라도, Swift에서 먼저 처리를 하고 특정 메소드를 통해 리턴해주는 방식으로 구현한다면 두 언어의 장점을 모두 흡수 할 수 있는 아주 멋진 프로젝트가 될 것입니다.

지난 번과 너무나 대조된 글이라서 좀 이상하지요? 예.. Swift는 계속 발전하고 있고, 우리가 만들어 가는 꼼수도 점점 늘어나고 있기 때문일 거예요 ㅎㅎ

결론
Objective-C는 Swift의 친구이자 멋진 동료가 될 수 있습니다! 100% Objective-C, 100% Swift 코드가 아닌 적절히 융합된, 서로의 장점을 가져다 쓸 수 있는 지금과 같은 체제를 계속 유지해 나갈 수 있으면 좋겠습니다. 애플이 Objective-C를 놓지 않고, Swift는 점점 발전시켜 주었으면 하는 바람입니다 🙂
 

Jo SeongGyu

2014/12/29

Apple_Swift_LogoSwift 로고
[출처 : Wikipedia – http://en.wikipedia.org/wiki/File:Apple_Swift_Logo.png ]

그렇습니다. Swift는 정말이지 뜻밖의 출현이었습니다.

무제

iOS 8과 더불어 새로운 기기가 발표될 거라고 생각했던 올 여름, 당황스럽게도 Swift 라는 아주 생소한 언어가 발표되었습니다. 힘차게 하강비행하는 듯한 칼새의 모습을 형상화한 로고가 나오는 순간, ‘저건 뭐지?’ 싶었는데, 새로운 언어라는 말에 저는 충격과 공포에 잠시 정신을 잃었던 것 같습니다. 이내 정신을 차렸지만 그 충격과 공포는 쉽사리 사라지지 않았습니다. ‘프로그래밍 언어라는 것이 뚝딱 만들어져 나올 수 없는데, 어떻게 저렇게 새로운 언어를 비밀리에 개발해서 내놓은거지?’ 등등 별별 생각이 다 들었어요. 어쨌거나 저쨌거나 언어에 종속될 수 밖에 없는 클라이언트 개발자는 눈물을 머금고 새로운 언어에 다가서 봤습니다.

첫 만남

Swift와의 첫만남은 ‘이게 뭐야’였어요. 스크립트 언어도 아닌 것이, 그렇다고 기존에 쓰던 Objective-C를 닮은 것도 아닌, 자바 비스무리한 새로운 변태같은 언어의 느낌. 딱 이런 느낌이었어요. 처음에는 당연히 Xcode 베타버전이라 크래쉬도 많이 나고, 불안정한 요소도 많았구요. 지금과는 문법도 조금씩 다른것들이 있었습니다. 여튼, 새로운 언어와의 첫만남은 한 마디로 ‘별로’ 였어요.

더 좋아진

Swift는 새로 출시된 언어답게 조금 더 발전된 기능들로 무장을 하고있습니다. 애플에서는 Swift의 특징을 Safe, Power, Modern으로 꼽았는데요, 새로나온 언어인 만큼 Modern함은 충분히 갖추고 있구요, Optional이라는 기능을 통해 Safe를 충족시키려 노력한 것을 볼 수 있습니다. 그러나 아직은 Power에 대한 의문은 남아있습니다. 기존 Objective-C 보다 성능면에서 대체적으로 떨어지기 때문인데요, 이 부분은 차후에 어떻게 개선되어 나갈지 지켜봐야 겠습니다.

그러나 더 발전해야할

물론 새로운 언어에서 좋아진 점들이 많지만, 아직은 부족한 부분들도 남아있습니다. 캡슐화가 아직 완벽히 지원되지 않고 있기 때문에 반(Half) 객체지향 언어라는 느낌이 강합니다. 애플에서는 앞으로 캡슐화를 할 수 있는 방안을 마련하도록 하겠다고 하였으나 이는 추후 지켜봐야 할 숙제라고 생각합니다. 또한 아직은 Swift를 완벽히 서포트 해주지 못하고 있는 Xcode도 발전에 조금 더 시간이 필요할 것 같습니다. 정식 배포버전이 베타버전에서 발전하여 문법도 조금씩 바뀌고, 불편한 점들을 개선한 것을 보면 위의 문제들은 시간이 해결해 줄 것이라고 생각합니다.

그래서..?

개인적으로 지극히 주관적인 입장으로 Swift는 2014년 말, 현 시점에서 아직까지 큰 프로젝트에 적용하기는 부담스럽다는 느낌입니다. Objective-C와 한 프로젝트 내에서 혼용하여 쓸 수 있다지만, 저는 그다지 그 연결에 흡족하지 못한 상태입니다. 그래서 현업 프로젝트에는 아직 적용하지 못하고 있어요. 그렇지만 iOS 또는 Mac OS 어플리케이션을 개발하는 사람이라면 꼭 배워두어야 할 것 같다는 생각입니다. 언젠가는 많은 발전을 통해 Swift가 대세가 될 날이 올 것 같기도 하거든요. 개인적으로는 생각보다 굉장히 파격적이고, 강력한 언어라고 생각합니다. 기본적으로 다른 언어 몇 가지를 익숙하게 다룰 줄 아는 프로그래머라면 Swift를 이해하는 첫 걸음은 Optional과 기존 Objective-C에서와는 조금 확장된 nil 이라는 개념이라고 생각하는데요, 여기(http://goo.gl/8VD1Rf)에 좋은 설명이 있어서 링크를 남겨둡니다. Optional과 nil 이라는 개념만 잘 이해해 두어도 Swift를 1/3은 정복했다고 생각합니다.

 

글을 끝까지 읽어주셔서 감사합니다. 아마 대부분 이 글을 읽으신 분들의 표정은 이러실거 같아요. 그래서 어쨌다고? 뭐라는겨?
스크린샷 2014-06-24 오후 6.51.15
사실 Swift의 실제 사용 후기에 대해 이것저것 말해보려고 했습니다만, 아마도 이정도로 충족하지 못하실거라 생각해요. 궁금한 점에 대해서 덧글 주시면 성심성의껏 답변드리도록 하겠습니다!

 

 

참고서적

Objective-C 개발자를 위한 Swift – 김근영 저
기존 Apple 어플리케이션 개발자들을 대상으로 썼지만, 다른 언어를 알고있는 프로그래머라면 충분히 이해하기 쉽게 설명된 Swift 기본 언어 책입니다.

만들면서 배우는 Swift: 스위프트로 시작하는 iOS 개발 – 야곰 저

기존 프로그래머가 아니더라도 아주 간단하게 Swift의 굵직한 특징들을 살펴볼 수 있고 간단한 iOS 앱을 따라 만들어 볼 수 있습니다.

 

[알림] 이 글은 이음소시어스와 그 개발팀의 견해와 일치하지 않을 수 있으며 지극히 주관적인 글임을 알립니다.

왜 개발가이드라인을 읽어봐야 할까요

오늘은 우리가 놓쳐온 사소한 것들에 대해 이야기 해보려합니다.

우리 개발자들은 급변하는 개발환경 속에서 살아가고 있습니다. 하루가 멀다하고 변화되는 지옥같은 개발환경에서 변화를 따라잡기란 참으로 힘겹기 그지없습니다. 항상 그렇듯 우리는 가장 중요하지만 가장 사소한 것들을 놓치며 살아갑니다. 내 가족의 소중함, 내 옆자리의 동료, 매일같이 맛있는 밥을 해주는 식당 아주머니의 손길…  우리가 개발을 하면서 수도 없이 들여다보는 개발문서, 그러나 너무나 사소해 보여서 그냥 지나쳐 버리는 개발문서의 핵심들…! 무엇이 있을까요?

헬게이트를 열어봅시다

제가 한 번 들여다 보겠습니다.

# 처음 만나는 프레임워크

‘안녕, 코코아 프레임워크! 반가워. 앞으로 잘해보자’

설렘 반 두려움 반으로 마주한 새로운 프레임워크. 그 친구에 대해 알아보기 위해서 가장 먼저 할 일은 아마도 개발도큐먼트를 읽어보는 일이겠지요? 마치 RC카를 조작하기 전에 설명서를 먼저 보는 것 처럼 말이죠. 그런데 우리는 RC카를 빨리 몰아보고 싶은 나머지 설명서의 앞, 뒤 다 잘라먹고 ‘차량 조종법’만 읽고 조종을 시작합니다. 그 상태로 막상 조작을 하다보니 좀 더 안전하게 운전하려면 어떻게 해야하는지, 연료는 무엇을 넣어줘야 좋은지, 부품은 무엇무엇으로 이루어져 있는지… 도무지 알지 못합니다. 하지만 일단 굴러가니까 좋아합니다. 이건 마치 도로교통법과 차량 기본 정비법은 까마득히 모르고 운전만 할 줄 아는 난폭운전자와 다를바가 없습니다. 개발세계에서 우리는 이런 난폭운전자가 될 수는 없습니다.

너무나 교과서 같은 이야기지만 개발문서는 그 어느 한 글자라도 생각없이 쓰여지지 않았다는 것을 한 번 생각해 보아야 합니다. 여러분께서 라이브러리를 개발하여 개발문서를 작성한다고 생각해 봅시다. 그 얼마나 귀찮고 힘든 일인지… 상상해 보셨나요? 그런데 그 개발문서에 시간들이고 공들여서 쓰잘데기 없는 이야기들을 쓴다구요? 당치 않습니다 ㅎㅎ 시간이 없다면 개발문서에 강조되어있는 헤드라인이라도 쭈욱 훑어보는 습관을 들이는 것은 어떨까요?

 

# 아… 이런 삽질이…!

위에 RC카를 예로 들었을 때, ‘조작법만 먼저 본다’고 예시를 들었던 것은 API Reference를 이야기 했던 것입니다. 도큐먼트에는 많은 목차들이 있지만 그 분량의 98% 이상은 API Reference겠죠? 하지만 제가 강조하고 싶은 것은 나머지 2%의 내용들입니다. 그 나머지 2%를 잘 숙지하지 않아서 생기는 일들은 너무나도 많아 다 이야기하기 어렵지만 몇 가지 사례를 제시해 보고자 합니다.

난 아직 2% 부족해

난 아직 2% 부족해

  • 어…? 뷰가 동작하지 않아!

개발자 모모씨는 아이폰 앱을 만들기 위해서 한창 코딩중입니다.

‘눈누난나~ 역시 난 천재야! 냐하하. 실행해볼까? 어..! 이게 왜 동작이 이상하지? 왜 먹통이 된거야!!’

애플의 코코아 프레임워크를 위한 코딩 가이드라인을 살펴보면 ‘메소드 이름 짓기‘라는 챕터가 있습니다. 그 곳을 살펴보면 Private Methods 라는 섹션이 있는데, 한 번 훑어보면

  • Names of most private methods in the Cocoa frameworks have an underscore prefix (for example, _fooData ) to mark them as private. From this fact follow two recommendations.
  • Don’t use the underscore character as a prefix for your private methods. Apple reserves this convention.

왜 제대로 된 동작을 하지 않았는지 감이 오시나요? 애플은 코코아 프레임워크에 숨겨진 Private Method 앞에 항상 언더바( _ )를 붙인다고 하는군요. 그런데 모모씨는 한 번도 이런 문서를 쳐다도 본 적이 없죠. 결국 모모씨는 3일 간의 삽질을 뒤로하고 자포자기하는 심정으로 주변 iOS 개발 고수님께 코드를 보여줍니다. 결론은요? 3분도 채 되지 않아 고쳤죠 🙂 저 메소드가 기존 프레임워크의 Private Method를 오버라이드 해 버린 것이었습니다.

p.s. 예를 들기 위하여 작성한 코드일 뿐, 실제 위의 코드로 오동작하지는 않습니다.

 

  • 아니… 왜 리젝된거지?

모모씨는 뼈저린 아픔을 뒤로하고 계속 앱 개발을 진행합니다. 물론, 가이드 문서를 다시 읽어봤을 턱이 없죠 ^^ 그래도 문제가 하나 해결되었으니 가뿐한 기분으로 계속 개발을 진행해 나갑니다. 모모씨가 개발하고 있는 앱은 추억의 똥피하기 게임. 하하 드디어 완성했습니다! 앱스토어에 올려야죠? 당당히 애플에 리뷰신청을 합니다. 드디어 리뷰 결과가 나왔군요!

추억의 똥피하기 게임

추억의 똥피하기 게임

당신의 앱은 부적절 컨텐츠로 반려되었습니다. 앱스토어 리뷰 가이드라인 16을 참고하세요.

아니 이게 무슨말이지? 모모씨는 너무나 황당합니다. 대체 뭐길래 이게 안된다는거야! 버그도 없고 동작도 잘 한단말야!

앱스토어 리뷰 가이드라인을 살펴보러 가봤습니다.

16. Objectionable content

16.1 Apps that present excessively objectionable or crude content will be rejected

16.2 Apps that are primarily designed to upset or disgust users will be rejected

하… 이번에도 가이드라인을 제대로 숙지하지 못해 빅삽질을 하게 되었군요. 애플은 일부 사용자들이라도 불쾌감을 느낄 수 있는 앱은 허용하지 않는다는군요. 프로젝트를 아예 폐기해야 할지도 모르는 상황입니다..! 결국 모모씨는 똥피하기의 컨셉을 버리고 빗방울 피하기 게임으로 컨셉 자체를 변경하게 됩니다.

아아... 가슴이 아파..

아아… 가슴이 아파..

  • 실제 예시를 몇가지 더 소개합니다
  1. Private Method 및 Private Variable을 자신도 모르는 사이에 재정의 해버려서 원인을 알아내는데 수 일이 걸린 경우
  2. 앱 내에 사진 업로드를 포함한 성 상담 익명 게시판을 만들었지만 가이드라인에 위배된다며 반려되어 서비스 기획부터 다시 해야 했던 경우
  3. IAP(In-App Purchase) 아이템의 성격이 애플의 가이드라인에 맞지 않아 과금 정책을 변경해야 했던 경우
  4. 앱스토어에 게재되는 스크린샷에 안드로이드 이미지가 일부 포함되어 있어서 반려된 경우
  5. 프레임워크에 맞게 재정의된 자료형을 사용하지 않아 아키텍쳐에 따라 상이한 결과 및 메모리 접근 오류가 발생하여 일일히 수정해 주어야 했던 경우(64bit 프로세서 전환 때 멘붕 겪으신 분들이 종종 있죠)
  6. 가이드라인에 제시된 프레임워크 구조를 모두 파악하지 못한 채 프로젝트를 진행하여 후임자가 구조를 모두 변경하여야 하는 경우
  7. 더 좋은 퍼포먼스를 지원할 수 있는 번들 리소스를 알지 못해 이미지 및 사운드 리소스를 모두 교체해야 하는 경우

 

등등등…

# 마치며

간단한 예시를 통해 개발문서의 가이드라인을 숙지하지 않아 발생하는 불상사를 알아봤습니다. 물론 위의 예는 아주 극히 일부분이고, 어쩌면 애플 프레임워크 위에만 해당하는 문제일 수 있습니다. 하지만, 실제 현업에서 지켜본 결과 저런 일들은 비일비재하게 일어나고 있으며 그 원인은 가장 기본을 놓쳤기 때문입니다. 개발에 걸리는 몇 십, 몇 백 시간을 저 가이드라인 하나를 놓쳐서 몽땅 말아먹는 경우도 생길 수 있다는 이야기입니다.

무시하기 쉬운 프레임워크(or 라이브러리) 제공자들의 한 마디 한 마디를 놓치지 말자구요~

다른 의견 또는 실제 사례가 있으면 덧글로 남겨주세요 🙂 기다릴게요~!

Xcode Bots 적용

테스트는 프로젝트에서 빠질수 없는 부분입니다. 테스트를 위해 변경된 앱을 설치해야 합니다. 설치 방법에는 여러가지가 있습니다. 여러가지 방법 중 Hey 프로젝트에서 적용한 방법을 공유하려고 합니다.

Hey?

Hey는 글로벌 버전 소셜데이팅 서비스입니다. 매일 오전 10시 3명의 이성의 프로필을 확인하고 서로 호감이 있으면 채팅을 할 수 있습니다.

Hey_Timeline Hey_Profile Hey_Chat

테스트 버전 배포

앱스토어에 업로드가 아니라 테스트를 위해 사내에 배포할때 어떤 방법을 사용하시나요?
이음에서는 두가지 방법을 이용했습니다.

  1. 디바이스를 연결하고 Xcode에서 직접 실행해서 앱를 설치해준다.
  2. Adhoc을 이용하여 사내 메일로 공유한다.

1번 방법은 작업중에 설치해줘야 할 경우 방해를 받게 됩니다. 그리고 테스트 디바이스로 등록되지 않은 디바이스때문에 Provisioning을 새로 생성해야 하는 문제가 발생합니다. Debug/Release로 빌드했는지 확인해야 합니다.

adhoc adhoc2 adhoc3

2번 방법은 1번 보다 더 효과적입니다. 한번 메일을 공유하면 앱을 설치해주느라 방해받지 않아도 됩니다. 하지만 불편한 배포과정이 남아 있습니다. Archive -> Distribute -> Adhoc 이런 방법으로 Adhoc버전으로 바이너리를 만듭니다. 그리고 생성된 ipa, plist 파일을 미리 입력한 url에 맞게 서버에 업로드합니다. 여기까지가 끝이지만…. 제대로 올렸는지 확인하기 위해 직접 다운로드해봐야 합니다.

두가지 방법 다 만족스럽지 못합니다.

그래서 새로운 기능인 Bots에 관심이 생겨서 직접 적용해 보았습니다.

Bots ?

Xcode BotsXcode5에 새로 추가된 기능입니다. Bots은 Xcode만을 위한 CI입니다. Bots은 간편하게 설정할 수 있습니다. XCTest를 사용할 경우 실제 등록된 디바이스에서 테스트를 실행하고 결과를 리포트해주는 기능도 있습니다.

bot_viewer-summary_2x 지속적인 통합을 위한 Bot

Bots 설치방법

http://meetkei.com/?p=3196

프로젝트 적용

HeyRelease Bot 생성

createHeyReleaseBot1

Hey Scheme 의 Bot을 생성합니다.

createHeyReleaseBot2

일일 빌드를 위해 매일 오후 5시에 빌드되도록 일정을 설정합니다.

createHeyReleaseBot3

빌드 성공시 프로젝트원 모두 메일을 받을 수 있도록 설정합니다.
실패시 개발자들만 메일을 받도록 설정합니다.
Create Bot 클릭하면 바로 통합이 진행됩니다.

HeyReleaseBuildError HeyReleaseBuildSuccess

통합 결과에 맞게 실패, 성공 메일을 받습니다.
디바이스에서 성공 메일을 확인한 후 제품 다운로드를 클릭하면 설치가 진행됩니다.

이제 통합을 매일 하는 일만 남았습니다!

문제 발생

통합메일에서 다운로드받은 앱을 실행해보니 서비스중인 서버(RealServer)로 접속하고 있었습니다. 테스트를 위해서 RealServer와 테스트 서버(TestServer) 모두 테스트가 가능해야 합니다. 이대로면 TestServer에서 테스트하기 위해서는 기존 방법을 이용해야 합니다.

RealServer로 접속하는 이유

Bot은 통합과정에서 Release build를 하게 됩니다. Build Settings 와 Server Host를 결정하는 Macro때문에 HeyRelease는 RealServer로만 접속됩니다.

HeyRelease_preprocessor

Build Settings > Preprocessor Macros 의 설정을 보면 Debug 에서 DEBUG=1 이 존재합니다. Release 에는 DEBUG가 존재하지 않습니다.

Header 에 적용한 Macro입니다. DEBUG가 존재하면 TestServer로 아니면 RealServer로 API_HOST가 정해집니다. 통합 중에는 Release 로 빌드가 되므로 API_HOST는 TestServer가 됩니다.

그럼 테스트 서버로 연결하려면?
Release에서도 DEBUG를 설정하면 됩니다.

그럼 RealServer, TestServer 를 모두 테스트하고 싶으면?
음…..

Hey에 적용한 방법

여러가지 방법을 생각해본 결과 제가 선택한 방법은 Target을 하나 더 생성하는 것입니다. HeyRelease는 RealServer로 HeyDebug는 TestServer로 접속하도록 하였습니다. Bot을  2개 생성해서 필요할때 둘중 하나를 배포합니다.

  1. 현재 Target을 복사해여 새로운 Target을 만듭니다.
  2. Preprocessor Macros 를 설정합니다.
  3. HeyDebug 이름으로 Bot을 생성합니다.

HeyDebug_preprocessor

createHeyDebugBot1 createHeyDebugBot2 createHeyDebugBot3

단점

  • build settings이 변경되면 두개의 Target 에 적용해야 함
  • 파일 생성 및 추가시 두개의 Target 을 지정해야 함

targets

언급한 단점이 있지만 Bots을 빠르게 적용할 수 있는 방법입니다. 개선된 방법은 조금 더 고려해 볼 예정입니다.

Bots Error

처음 Bots을 사용하면 많은 오류들과 만나게 됩니다. 몇가지 오류 해결 방법을 정리하였습니다.

Provisioning Profile 관련 오류

ProvisioningProfileError

iOS Team Provisioning Profile 을 사용하면 문제가 해결됩니다.

GeneralIdentity

그래도 해결되지 않는 경우 Target > General > Identity 에 위와 같이 Provisioning Profile 오류로 인한  Fix Issue버튼이 표시되는 경우가 있습니다. 이 버튼을 클릭하고 수정된 상태에서 통합을 진행해 보세요.

Reason: XCSCredentialSSHKey: private key is missing from the credential

http://stackoverflow.com/questions/5525436/xcode-could-not-find-a-valid-private-certificate-valid-key-pair-for-this-profile

xcode bots User interaction is not allowed.

  • Open the Keychain Access
  • Right click on the private key
  • Select “Get Info”
  • Select “Access Control” tab
  • Click “Allow all applications to access this item”
  • Click “Save Changes”
  • Enter your password

http://stackoverflow.com/questions/577750/running-xcodebuild-from-a-forked-terminal

Bots 오류 모음

  • Repositories that require an SSH key to access
  • Code Signing and Provisioning Profiles
  • Submodules
  • I made a mistake and now I can’t fix the repository from Xcode!

http://ikennd.ac/blog/2013/10/xcode-bots-common-problems-and-workarounds/

Profile