#ui7kit

지난 두 달간 UI7Kit1에서 겪은 경험은 특별한 것이었다. 잊지 않기 위해 정리해 본다.

시작

지금까지 (앱 만드는 주제에) 한번도 iOS나 OS X의 미리보기 버전을 설치해 본 적이 없었는데, iOS7은 시뮬레이터로 좀 구경이나 해보려는 마음으로 WWDC 이후 나온 따끈따끈한 Preview1을 설치해 보았다.

몇 GB짜리 xcode5를 다운받고 설치하느라 좁은 SSD 정리만 한참을 했는데2, 기본 앱을 이리저리 구경하고 나서는 그다지 해볼 만한 게 없었다. 시뮬레이터에는 원래 기본 앱이 다 든 것도 아니고, 기본 앱이 iOS의 모든 컨트롤을 쓰고 있는 것도 아니니까. 그래서 그 다음에는 이전에 개발한 앱들이 iOS7에서 어떻게 보이나 하나씩 돌려보기 시작했다. 회사에서 개발 중인 게임들은, status bar가 겹쳐서 나오는 문제를 제외하면 전혀 문제가 없었다. 게임이야 모든 화면을 게임 엔진이 그려주니 그럴법 하다.

그 다음에는 내가 만든 앱을 하나씩 올려보기 시작했다. 그런데 이게 웬걸. 첫 앱부터 말썽을 부리기 시작했다. 범인은 FoundationExtension3이었다. Foundation이나 UIKit의 빠진 기능을 채우자고 만들기 시작한 프로젝트인데, 그 '빠진 기능' 가운데 하나로 넣은 심볼이 iOS7 UIKit에 실제로 들어가 버린 것. FoundationExtension을 잽싸게 패치하자 제대로 빌드가 되기 시작했다.

앱들은 뭐 그냥... 처참했다고 해두자. FoundationExtension에는 UUID 동작을 iOS 버전별로 적당히 골라 호출해 준다거나 하는 구현도 들어 있었는데, 여기서 아이디어가 떠올랐다. iOS7의 UI을 기본으로 이전의 OS에 호환성을 제공하면 이 인기 없는 프로젝트에도 볕이 들 날이 오지 않을까? FoundationExtension에는 UIKit7이라는 타겟과 브랜치가 추가되고 간단한 구현이 들어가기 시작했다.

첫 버전

가장 널리 쓰이는 기능이 첫 목표로 정해졌다. 모든 앱에는 navigation bar는 들어간다. 그리고 최소한 내가 만든 모든 앱에는 table view가 들어간다. 일단 navigation bar와 table view가 들어간 앱을 하나 만들어야겠는데, 빨리 기능을 테스트해보고 싶은 생각에 급한 김에 FoundationExtension 기능 테스트에 쓰던 앱을 그냥 패치하기 시작했다. 지금도 이 버전 기반의 테스트 앱이 아직 쓰이고 있다.

navigaiton bar의 눈에 보이는 부분 구현은 생각보다 쉬웠다. 애플은 iOS5에 navigation controller를 원하는 navigation bar와 toolbar로 생성할 수 있는 API를 추가했다.4 여기서 최소 지원 버전이 iOS5로 정해졌다.5 UINavigationBar를 상속한 UI7NavigationBar를 만들고 UI7NavigationController를 만들어 모든 초기화 함수에서 항상 navigation bar를 교체하도록 오버라이드 했다. 결과는... 일단 안 돌아갔다. Interface Builder를 사용하면 모든 컨트롤은 Interface Builer에 지정된 클래스로 초기화된다. 결국 손으로 UINavigationBar를 찾아 클래스를 바꿔주어야 했다. 기술에 관한 이야기를 좀 장황하게 했는데, 꽤 중요한 부분이다. Interface Builder에서 매번 클래스 이름을 바꾸는 것이 참을 수 없을 정도로 귀찮았기 때문에, 이건 아무리 결과가 잘 나와도 나라면 쓰지 않을 라이브러리였다. 쓰기 더 쉽고 더 간단해야 했기 때문에, UI7Kit은 두 번째 목표를 정했다. "기존의 UIKit을 동적으로 패치해서 귀찮은 작업 없이 UI7Kit이 동작하게 만들 것". Objective-C는 C처럼 보이지만 동적 언어이다. 런타임에 클래스와 메소드를 교체하고 고칠 수 있다. 앱이 UIKit을 불러온 다음 UIKit의 구성요소를 모두 UIKit과 호환되는 UI7Kit으로 바꿔 넣으면 앱이 보기에 UIKit은 UI7Kit과 구분되지 않는다. 앱은 마치 iOS7에서 돌아가는 것 처럼 iOS6에서 돌아갈 수 있다. 이름도 이때 UI7Kit으로 바꿨다. 헤더를 찾을 때(UIKit7)와 각 클래스에 접근할 때(UI7-) 어디 7이 들어가나 몰라 헷갈리는 게 너무 싫었다.

navigation bar와 비교하면, table view는 꽤 고통스러운 작업이었다. 먼저, cell과 section은 table view의 핵심 구성요소이다. cell은 UITableViewCell을 패치하면 된다. 그런데 table view만 고쳐서 section header와 footer를 고칠 방법이 어딜 봐도 없었다.6 section header와 footer는 delegate와 dataSource에서 조금씩 나뉘어 처리된다. 결국 나는 delegate와 data source가 설정되는 순간 이것들을 패치해 iOS7의 동작을 흉내내 보기로 했다. delegate와 data source는 UIKit의 구성요소가 아닌 사용자가 정의하는 부분이기 때문에, 무슨 일이 일어날 지 알 수가 없다. 그저 사용자가 예측을 벗어난 특별히 이상한 일을 하지 않기를 바라기로 했다.7 Objective-C에서 서로 엮인 두 개 이상의 메소드를 동적 패치하는 것은 처음 해 보는 일이었다. 끔찍한 일이었다. 코드는 충분히 장황했고, 예제가 겨우 돌아가는 코드를 만들었다.

겨우 컨트롤 두 개를 붙였는데, 이미 코드의 규모나 형태는 "FoundationExtension의 신기한 기능으로 집어넣는다"에서 많이 벗어나 있었다. FoundationExtension은 "꼭 있어야 할 것 같지만 애플이 빠뜨린 기능의 확장"을 철학으로 삼는데, 여기에 맞지도 않았다. 프로젝트는 분리되어야 했다. 여기서 새로 패키지를 만든 것이 UI7Kit의 첫 버전인 0.0.1이다. 충분히 멋진 기능이고, 누구나 꿈꿀만한 목표라는 생각이 들었다. 밤이 늦었지만 다음 날이 되면 누군가 비슷한 목표의 프로젝트를 만들 것 같은 기분이 들어 기다릴 수가 없었다. 게다가 그 날은 WWDC 이후 이틀이 지난 때였는데, 하루를 더 보내는 것은 그냥 하루라기보다는 내가 보낸 시간의 50%를 허비하는 것처럼 느껴졌다. 눈길을 끌 만한 소개와 자료를 만들기 시작했다. 이 첫 버전은 지금 보면 거의 훌륭한 사기에 가까운 느낌이 드는데, 4천줄 정도의 코드로 상당히 많은 컨트롤을 지원하게 된 지금이나 600줄 정도의 코드에 눈에 보이는 첫 화면을 겨우 처리하는 그 때나 스크린캡처를 본 첫 느낌은 큰 차이가 없기 때문이다.

문제의 스크린캡처. 훌륭해 보인다. 하지만 어떤 버튼을 누르더라도 실망했을 것이다. (이 버전을 보고 10초만에 감탄과 실망을 하는 사람을 직접 보았다)

업로드

프로젝트를 만들자마자 커밋도 하기 전에 구름옥상 위에서 코딩하는 도인8 께서 관심을 보이셨다. (쓰고 있으신지는 잘 모르겠다)

내가 만든 Objective-C 프로젝트는 보통 CocoaPods에 업로드한 이후에 CocoaPods을 통해 쓰는 사람이 생기는 경우가 많았기 때문에, 이번에도 제일 먼저 CocoaPods으로 패키징을 했다.9 제대로 돌아가지 않는 프로젝트를 CocoaPods에 올리는 것은 처음이라, 직접 푸시하지 않고 풀 리퀘스트를 보냈다.10 CocoaPods 풀리퀘스트를 보고 프로젝트를 찾아오는 사람도 조금 있지 않을까 하는 바램도 있었다. 실망스럽게도(?) 풀 리퀘스트는 꽤 빨리 처리되었는데, 의외의 효과를 보게 되었다. CocoaPods는 새 프로젝트를 소개하는 트위터 계정[^CocoapodsTwitter] 을 갖고 있다. 이 CocoaPods 트위터는 생각보다 많이 주목받고 있었고, UI7Kit은 CocoaPods 트위터에서 소개되며 상당히 빠르게 알려지게 된다.11 레딧의 iOSProgramming 서브레딧에도 소개를 올렸는데, 트위터에 비하면 크게 주목받지는 못했다. 몇 시간 뒤에는 github trending repos에 올라갔다.12

이런 주목은 살짝 당황스럽기도 한 것이었는데, 아마 "응당 받아야 할 것 이상을 받고 있다" 같은 느낌이었던 것 같다. (사실 잘 모르겠지만) 이유를 생각해 보자면, 먼저 WWDC 직후인데다 인터넷에는 한참 iOS7에 관한 찬사와 비난이 끝없이 쏟아지고 'Jony Ive redesigns ~'가 한창 인기여서 좋은 의미로든 나쁜 의미로든 iOS7의 UI에 관한 관심이 최고조에 달했을 때였다. 둘째로는 스크린캡처가 내 기대보다도 더 훌륭했다.13 아마 대부분은 프로젝트를 실행해보지 않았을 것이다. 심지어 이미 상당한 구현이 되어 있다는 기사14도 나왔다. 프로젝트의 목표와 스크린샷을 보고 사람들이 어떻게 판단했을지 짐작할 만하다.

이후에는 프로젝트 소개를 위해 해커뉴스15 에 프로젝트를 올리거나, 소개 영상을 만들거나, Cocoa Controls16 에 소개를 올리기도 했다. 먼저 해커뉴스는, 전반적으로 프로젝트 페이지 자체를 홍보하기에 적합한 인상은 아니다. 많은 점수를 받는 링크는 보통 '흥미로운 기사거리'에 적합한 특징을 가진 링크다. 하지만 트위터와 레딧에서의 반응으로 프로젝트 페이지 자체가 적당한 흥미거리가 될지도 모른다고 생각해 일단 시도해 보게 되었다. 지금 생각하면 프로젝트 페이지보다 다른 사람이 쓴 기사를 링크하는 게 나았을지도 모르겠다는 생각이 든다. 이 링크도 어느 정도의 홍보 효과를 거두었지만, 그리 큰 효과는 아니었다.11 해커뉴스 자체보다는, 해커뉴스를 통해 트위터와 해커뉴스를 인용하는 사이트를 중심으로 알려졌다고 보는 것이 더 적당한 해석이라고 생각한다.

소개 영상은 어느 정도 준비가 갖춰진 후에 동적 패치의 간단함에 초점을 맞추어 만들어졌다. "신기하다" 정도의 반응으로 공유되기를 기대했지만, 그렇지 않았다. 유명한 소프트웨어도 아니고, 놀라운 결과가 나타나는 것도 아니고(UI7Kit은 결과보다는 과정의 놀라움이 크다), 꼭 써야해서 볼 필요가 있는 것도 아니다. 하지만 Github 이슈에 접근하지 않는 사용자를 위한 질문 창구의 역할 정도는 한 것 같다. 17

한편 Cocoa controls는 전체적으로 뜻밖의 경험의 연속이었다. 나는 GUI에 관련된, 스크린샷을 보고 써 보고 싶어질 만한 라이브러리는 만들어 본 적이 없었기 때문에, Cocoa controls에 프로젝트를 등록해 본 것은 이번이 처음이었다. Cocoa controls는 살짝 당황스러운 등록 정책을 갖고 있었다. 사이트의 메인 메뉴에 Cocoapods이 있고, 대부분의 컨트롤이 Cocoapods 설치를 기본으로 갖고 있어 막연히 Cocoapods와 비슷하겠거니 생각했지만, 전혀 그렇지 않다.18

내가 처음 UI7Kit을 Cocoa controls에 등록했을 때, 44개의 프로젝트가 큐 되어 있다는 알림이 나타났다. 그리고 이 수는 하루에 일정 수 이상은 줄어들지 않았다. 그래서 거의 비슷한 시기에 등록했음에도 불구하고, Cocoa controls에서 실제로 프로젝트가 노출되기 시작한 것은 상당한 시간이 지난 뒤였다. 한편, 그런 정책 때문에 오랫동안 전면에 노출되어서인지는 몰라도, Cocoa controls에 프로젝트가 노출된 이후의 효과는 상당했다.11 Cocoa controls의 모든 프로젝트는 운영자가 직접 확인 후 승인하는 과정을 거치는 것 같다. UI7Kit이 마음에 들었는지 아니면 정적인 스크린샷이 프로젝트에 대해 불충분한 정보를 준다고 생각했는지는 몰라도, 테스트 앱이 동작하는 비디오도 하나 만들어 주었다.19

더 놀라운 것은 그 다음 주에 일어났다. Cocoa controls에서는 Controls of the week을 선정하고 있었다. 20 사이트 안에서는 접근성이 나쁜 블로그에서 운영되는데도 파급효과는 큰 편이었다. 11 Cocoa controls의 메인은 최근에 올라온 프로젝트에 초점을 맞추거나 등록된 프로젝트를 찾아보기 좋게 되어있다. 그리고 선정된 컨트롤은 Cocoa controls의 트위터를 중심으로 공유된다.

글을 쓰던 중인 최근에는 Bountysource라는 오픈소스를 위한 펀드를 모으는 서비스에도 등록을 해보았다.21 IRC 채널에서 친절한 상담을 받으며 이용 중이며, 끝나는 대로 내용을 추가해 보도록 하겠다.

업로드 - 정리

영어권에서 접근할 수 있는 Objective-C 프로젝트의 주요 공유 경로는 트위터라고 밖에는 생각할 수 없다. 그리고 개발자 커뮤니티에 효과적으로 트윗을 전달할 수단을 갖고 있지 않다면, 효과적인 트윗을 만드는 방법은 Cocoapods나 Cocoa controls라고 생각된다. 나는 아마 앞으로 어떤 Objective-C 라이브러리를 만들더라도 Cocoapods와 Cocoa controls를 최우선으로 고려할 것이다. 해커뉴스에 올렸던 글도 해커뉴스에서는 빠르게 사라졌지만 해커뉴스를 인용하는 트위터를 중심으로 상당한 공유가 이루어졌다.

단, Cocoapods은 간단한 링크와 소개만 트윗하므로 이름과 짧은 소개로 매력적인 프로젝트 소개를 전달할 수 있도록 해야 한다. Cocoa controls는 대기에 가장 오랜 시간을 써야 하므로, 프로젝트가 완성되지 않았더라도 일단 등록하여 대기열에 올려두고 그 전까지 적당한 퀄리티로 만들어 내는 것이 중요하다. 둘 모두 한 프로젝트는 한 번밖에 쓸 수 없는 기회이다. 필요하다면 가능한 최고로 매력적인 시점까지 공유를 연기하는 것도 한 가지 방법일 수 있다.

영상은 눈길을 끄는 영상을 제공하지 못하는 한 큰 쓸모는 없어 보인다. 해커뉴스는 흥미로운 기사를 위한 곳이다. 사람들이 좋아할 만한 기사를 제공하는 것이 중요하다.

영어를 제외한 언어 중에서는 일본어와 중국어로 가장 많은 내용이 공유되었다. 그리고 내가 직접 올린 소개 이외에 번역된 소개가 공유되는 곳도 일본어과 중국어로 된 곳이 대부분이다. 중국어와 일본어를 몰라서 어떤 내용이고 어떤 경로로 알려진 것인지 확인하기는 어려웠다. 하지만 가능하다면 활용할 수 있는 방법을 찾아보는 것도 좋겠다.

안타깝게도 한국어로 된 내용은 거의 보지 못했다.

Cocoapods

Cocoapods은 이래저래 고민거리를 많이 던져주었다. 일단 나 스스로는 master spec 외에도 별도로 private spec을 운영하며 가능한 모든 코드를 Cocoapods으로 패키징하고 있다. Xcode에서 코드가 꾸준히 업데이트 되는 외부 라이브러리를 다룰 방법이 거의 없기 때문이기도 하고, ARC 옵션이나 리소스를 관리하는 가장 쉬운 방법이기 때운이기도 하다.

하지만 많은 사람에게 Cocoapods는 장벽이기도 하다.22 일단 첫 설치가 어렵다. (아마도 아직 Cocoapods를 사용하지 않은 대부분의 사람들은) 한 번도 안 써본 rubygem을 써야하고, rubygem으로 Cocoapods를 설치한 이후에도 master spec을 초기화해야 한다. (이 부분이 왜 필요한 지 설명하는 것도 어렵고 설명하지 않고 헷갈리지 않게 실행하도록 돕기도 어렵다.) Podfile은 템플릿으로 생성되지 않아 문법을 알고 있어야 하며, iOS SDK 버전을 명시하지 않으면 뭘 해야 할지 모를 에러도 발생한다. 이 모든 장벽을 넘어 Cocoapods을 사용 중이던 사람들에게도 문제는 남아있었다. Cocoapods의 이전 버전을 쓰며 다른 프로젝트와 함께 쓰면 문제가 생기는 등 추적하기 어려운 문제도 있었다.

나는 README의 한 절과 두 번째 영상의 대부분을 Cocoapods를 한 번도 쓰지 않은 사용자가 하나씩 따라올 수 있도록 하는데 소비했다. 그런데도 충분히 쉽지 않다. 게다가 사람들은 Cocoapods과 잘 모르는 프로젝트에 이중의 거부감을 가지고 프로젝트를 대하게 된다. 조금만 어려워도 "안 쓰고 말지" 라고 생각하기 쉽다.23 어떻게 이 장벽을 넘을 수 있을지 모르겠다. Cocoapods 없이도 프로젝트에 일단 접근할 수 있도록 따로 패키징을 해야할까? 파일이 하나거나, 아니면 소스코드만 포함해도 된다면 문제가 조금 더 쉬웠을지도 모르겠다. Cocoapods로 된 의존성이 있고, 리소스 파일도 수십 개씩 들고 다녀야 하는 상황에서는 개발에 쓸 시간을 낭비하지 않고 이 문제를 해결할 좋은 방법이 떠오르지 않는다.

진행

UI7Kit은 야간에, 주말에 조금씩 작업되고 있다. Bountysource에 제안을 쓰며 목표를 정리하고 우선순위를 정하고 있는데, 일단은 "인터페이스 빌더에서 아무 컨트롤이나 막 끌어다 놓고 iOS6로 실행하면, iOS7처럼 보이게 해준다"가 UI7Kit 1.0의 주 목표이다.

지금까지는 작업 우선순위를 그냥 내키는 대로 잡았지만, 앞으로는 회피할 수 있는 문제나 크게 문제 없이 넘어갈 수 있는 빠진 구현은 뒤로 미루고 특정 앱에서는 아예 쓸 수 없게 만들만한 큰 문제부터 다루어야겠다고 생각만 하고 있다. 언제나 그렇듯이 이슈가 쌓이면 닫고 싶고, 특히 그게 어떻게 손대야 할 지 막막한 일 대신 라인 단위로 구현할 코드가 떠오르는 쉬운 일이면 더욱 그렇다. 게다가 닫을 사람이 나 밖에 없다는 느낌은 쌓이는 이슈 갯수는 더욱 참고 볼 수 없게 만든다.

UI7Kit을 만들며 뼈저리게 느끼는 것은 시간이 정말, 정말, 정말 부족하다는 것이다. 올해 초에 Rust 패치 몇 개를 만들며 생각보다 진도가 잘 안나가 답답하게 느꼈던 기억이 난다. 나름 익숙한 작업으로 돌아와서도 똑같은 증상을 겪다 보니, 문제가 정말로 시간 부족이라는 것을 깨닫고 있다. UI7Kit을 시작하며 아직 완성되지 않은 덜 만든 것들에 대해서는 미련을 싹 버리고 중지시켰다. 하지만 이미 만든 것에 대한 버그 리포트까지 무시하기는 꽤 어려운 일이다.24 UI7Kit은 UI 복제구현과 Objective-C 동적패치를 한다. 둘 모두 노동집약적인 프로그래밍이다. 다른 작업을 하느라 시간을 뺏기고 나면, 그 주에는 금방 commit 수 그래프가 뚝 떨어지게 된다.25 1.0이 iOS7 출시 이전의 현실적인 목표이길 바란다.

현재 버전이라고 하고 싶은데, 새로 작업한 내용을 아직 스크린샷에 반영하지 못했다.

마무리

사실, 글을 처음 쓰기 시작할 때는 UI7Kit 의 구현에 관한 이야기와 관련된 기술적인 이야기도 함께 다루어볼 요량이었다. 하지만 글이 생각보다 길어져 버린데다 뒤로 갈수록 졸렬해지고 있고, 이 글의 첫 줄을 쓴 지도 이미 4일이 지났고, 글만 쓸 수도 없으니 나머지 이야기는 다음으로 미루어야겠다. 심심할 때마다 짧은 글로 한 편씩 쓸 수 있지 않을까 생각하고 있다. 구현에 관한 이야기는 쉽게 잊지도 않을테고 git log로 쉽게 회상할 수도 있을테니까.

https://github.com/youknowone/UI7Kit UI7Kit은 iPhoneOS의 첫 버전에서부터 크게 변하지 않았던 iOS의 UI가 iOS7에서 갑자기 바뀐 충격(?)을 어느정도 흡수해주는 라이브러리이다. 이전 버전의 iOS 앱들을 iOS7 앱처럼 보이게 만들어 UI를 버전 별로 두 벌 관리하거나, 서로 다른 버전의 OS에서 똑같이 보이게 하기 위해 많은 노력을 들이지 않을 수 있도록 도와준다. ↩︎

XCode4가 만든 derived data 디렉터리가 10GB가 넘어가 있었다. 그 이후로 어제 Preview4를 받느라 다시 한번 지웠는데, 그동안 다시 4GB가 되어 있더라. SSD에 두자니 덩치가 크고 하드로 옮길수도 없고 이거 참...... ↩︎

https://github.com/youknowone/FoundationExtension/ 문제의 커밋은 이것 ↩︎

initWithNavigationBarClass:toolbarClass ↩︎

나중에 알게 된 것인데, iOS5 아래는 지원할래야 할 방법이 없다. UI을 새로 그리기 위한 API의 대부분이 iOS5에서 추가되었다. 한참 아이폰 앱 만들던 때만 해도 iPhoneOS3 호환을 포기할 수 없던 때였기 때문에, iOS SDK에 대한 내 기억은 거의 iPhoneOS3 시절에 머물러 있다. 그래서 모두 UI7Kit을 개발하면서 처음 안 기능인데, 낡은 UI 문제에 관해 어쨌든 애플이 놀고 있진 않았다는 생각이 들었다. "iPhoneOS가 나온 이래 UI가 거의 바뀌지 않았다"라고 했지만, 최근에는 어쨌든 컨트롤을 커스터마이즈하려는 개발자들의 욕구를 어느 정도 들어주는 편이었던 셈. 그리고 iOS7이 나온 이후의 현실적인 iOS 최소버전이 iOS5가 될 것이라는 점을 생각하면, iOS5에서 iOS7과 UI를 맞출 수 있다는 것은 중요한 문제다. iOS6때 UI가 바뀌었다면, 많은 개발사와 개발자들이 iOS4.3 지원이냐 새 UI냐의 갈림길에서 고통받았을테고, 수 많은 외주 개발자들이 iOS4.3 지원과 새 UI 처리를 동시에 요구받으며 이미지와 버튼만으로 '갑'의 디자인을 소화하느라 진땀 뺐을테다. ↩︎

지금 이 문제를 만난다면, section과 관련된 private class를 하나씩 패치해 볼 것 같다. 하지만 두 달 전에는 지금보다 기교가 많이 떨어지는 상태였고, 그런 생각은 전혀 나지 않았다. ↩︎

하지만 결국 지금, UITableView를 해킹하는 또 다른 라이브러리인 Sensible table view와 함께 쓰면 문제를 일으키고 있다. 아직 왜 그런지는 살펴보지 못했다. ↩︎

나는 사실 저장소를 만들고 첫 릴리즈를 하고 나면 "아 내가 이런 멋진 걸 만들다 말았지만 속세의 사람들은 몰라줄테니 스스로 Star로 이 수고를 치하하리로다" 라고 하고 수줍게 Star를 누른다. 하지만 내가 만든 프로젝트 중 가장 인기있는 프로젝트에서 혼자 짝짜꿍할 기회는 도인(@lqez)께 뺏겼다. ↩︎

cocoapods.org Xcode + Objective-C 환경에서 쓰는 라이브러리용 패키지 매니저이다. CocoaPods 없는 Xcode는 MacPorts와 homebrew 없는 OS X가 되니 꼭 써야 한다. OS X를 안 쓰는 사람들을 위해서라면, 데비안에 aptitude가 없고 레드햇에 yum(은 커녕 rpm도)이 없는 그런 느낌이다. ↩︎

CocoaPods는 푸시 권한 정책이 매우 관대한 편이다. 문제 없는 spec을 몇 개 보내면 바로 권한을 준다. 반대로 이야기하면, 푸시 권한은 있지만 뭘 푸시해도 되는지 잘 모르기 때문에 확신이 없으면 풀 리퀘스트를 보내게 된다. 풀 리퀘스트 ↩︎

gitego.com/youknowone/ui7kit 첫 24시간동안은 추적되지 않았다. 그래프에서 주요 포인트로 첫 부분과 변곡점 셋이 있는데, 맨 처음이 CocoaPods 트위터 + iOSProgramming subreddit + github daily trend, 16 June이 hackernews, 15 Jul이 cocoacontrols, 22 Jul이 cocoacontrols의 control of the week이다. gitego 덕분에 프로젝트의 주요 지표로 Star를 사용할 수 있게 되었다. github 프로젝트 페이지의 pv를 확인하거나 저장소를 클론한 수를 추적할 수는 없기 때문이다. ↩︎ ↩︎ ↩︎ ↩︎

이 영광은 집을 사는 날 액자에 걸어 가보로 남기도록 하겠다. 집이 충분히 클 때만... ↩︎

스크린 캡처는 물론 실제로 동작하는 시뮬레이터의 캡처였지만, 그 이상은 아니었다. 심지어 화면에 보이는 테이블 뷰 셀을 눌러 다른 화면으로 들어가면, 뒤로 버튼조차 바뀌지 않았다. 나도 cocoacontrols를 둘러보면 실제로 프로젝트를 실행해 보기 전에 어떤 프로젝트는 괜찮아 보이고 어떤 프로젝트는 그렇지 않아 보인다고 대충 미리 판단을 하고 실제로 그게 필요해지기 전까지는 써 보지 않는다. 그러니까, 결국 대부분은 써 보지 않으므로 프로젝트의 가치는 결국... ↩︎

New Open Source Project Bringing iOS 7 Style To iOS 5 and 6 UIKit Interfaces 괜찮아. 이제 정말로 거의 다 되니깐. ↩︎

Hacker news ↩︎

Cocoa Controls는 OS X나 iOS의 UI 컨트롤을 업로드할 수 있는 사이트이다. 운영자가 직접 리뷰하고 승인한다. Cocoapods와 깊은 관계가 있는 것 같은 인상을 느끼는 사람이 많지만, 컨트롤을 업로드하거나 이용하는 과정 자체는 그렇지 않다. ↩︎

글을 쓰는 현재 영상 2개의 조회수는 합쳐서 550회 정도이다. ↩︎

Cocoapods는 소스코드를 등록하고 의존성 관리를 도구를 이용해 할 수 있도록 돕는다. 올라온 프로젝트가 외부로 공유되는 경로는 트위터 뿐이다. Cocoapods에서는 올라온 풀 리퀘스트를 점검하고 머지하기는 하지만, 프로젝트를 평가하지는 않는다. 한편 Cocoa controls는 개발을 보조하는 툴이라기 보다는 반쯤은 큐레이트에 가깝다. Cocoapods에 등록되어 있을 필요도 없고 소스가 공개되어 있을 필요도 없다. 비록 사용자가 올린 프로젝트만 대상으로 하지만, 마음에 드는 프로젝트를 선정하고 공유하기도 한다. ↩︎

Cocoa controls - UI7Kit Video는 원래 없는 탭인데, 프로젝트가 마음에 들었는지 정적인 스크린샷이 프로젝트를 잘 드러내지 못한다고 생각했는지는 몰라도 영상을 만들어 주었다. 감사합니다. ↩︎

Cocoa contorls blog - UI7Kit 블로그에서는 댓글 등의 활동이 일어나지는 않는다. 하지만 Control of the week은 트위터의 @cocoacontrols 계정에서 공유되고, 이 트윗에 대한 반응은 적지 않다. ↩︎

Bountysource - UI7Kit Bountysource는 gittip 느낌의 오픈소스를 위한 fundraising 서비스이다. 생긴 지 얼마 되지는 않은 것으로 보인다. ↩︎

Cocoapods와 관련된 이슈만 4개였던 것 같다. ↩︎

나는 Objective-C 라이브러리가 Cocoapods으로 배포되거나 최소한 Xcode에서 library target으로 정리되어 있지 않으면 엄청나게 귀찮아지면서 이리 저리 미루다 다른걸 먼저 해보거나 그마저도 없으면 그냥 다른 일을 먼저 찾는다. 그걸 다시 해 보러 돌아오는 때는 지금 당장 꼭 해야할 때이다. 아마 Cocoapods를 처음 쓰는 사람은 비슷한 느낌을 받을 것이다. ↩︎

어... 그러니까 이렇게 말하면 누군가 예외를 알고 있다는 눈빛으로 쳐다보겠지만... 그게 거기엔 나름의 변명이... ↩︎