대다수의 많은 사람들처럼 나도 아이폰을 접한 즉시 아이폰에 매료되었다. 나는 웹 개발자이기 때문에 처음에는 wep apps만이 장치에 사용자 정의 애플리케이션을 올리는 유일한 방법이었다. 몇 개월 후 App Store가 공지를 했을 때 매우 흥분된 마음으로 서점에 가서 Objective-C에 관한 모든 책을 구입했다. 내가 만든 web apps의 일부는 이미 어느 정도 인기가 있었기 때문에 그것들을 단지 native apps로 재작성하여 App Store에 올리면 그야말로 돈방석에 오르는 건 시간문제라고 생각했다.
하지만 Objective-C를 배우는데 어려움이 있었고 언어가 Mac 프로그래밍 밖에서 약간만 사용된다는 사실에 환멸을 느꼈다. Xcode와 Interface Builder는 꽤 매끄러웠지만 주로 개발하던 환경이 아니었기 때문에 익숙하지 않았다. 테스트를 위해 애플리케이션과 아이폰에 설정만을 위해서도 뛰어넘어야 할 난관이 많다는 것에 격분했다. App Store에 애플리케이션을 올리는 과정은 더욱 복잡했다. 한두 주 이러한 변수와 사투를 벌인 후 내가 왜 이러한 문제들 속에서 허우적대고 있는지에 대한 의문을 가지게 되었다. 어쨌든 내가 만든 web apps는 이미 전 세계적으로 웹상에서 사용되고 있는데 왜 꼭 App Store에 올려야만 한다고 생각했을까?
이 모든 상황 위에는 Apple이 애플리케이션을 거부할 수 있고 이미 그러고 있다는 것이다. 이것은 확실히 그들의 특권이고 아마도 그들은 그럴만한 이유를 가지고 있을 것이다. 그러나 외부에서 보기에는 변덕스럽고 독단적인 횡포로 보인다. 실제 상황을 들어 생각해보면, 여러분은 Objective-C를 배우기 위해 약 100 시간을 사용하고 native 아이폰 애플리케이션을 만드는데 또 100 시간을 보낸다. 결국 애플리케이션은 황금시간이 투자되어 준비되고 여러분은 App Store에 올리는 과정을 성공적으로 마쳤다. 다음은 무슨 일이 일어날까?
여러분은 기다리고 또 기다린다. 우리는 몇 주, 때로는 몇 달을 기다린 후 마침내 회신을 받는다. “당신의 애플리케이션은 거부되었습니다.” 이젠 어떻게 하면 좋을까? 더 이상 여러분이 들인 노력을 아무데도 보요주지 못하고 결국 물거품이 되고 마는 것이다.
그러나 상황은 더 나빠질 수도 있다. 애플리케이션이 승인을 받았다고 치자. 수백만 또는 수천만의 사람들이 애플리케이션을 다운로드 받았고 아직 요금을 지급받지 못한 상황에서 버그 보고서가 오기 시작한다. 몇 분 안에 버그를 찾아내어 수정한 후 iTunes에 수정한 애플리케이션을 올린다. Apple이 교정을 승인하는 동안 기다리고 또 기다려야 한다. 그 사이 화가 난 고객들은 App Store에 지독한 평가와 재검토를 요청할 것이다. 여러분은 화난 고객들에게 반품을 제안하고 싶겠지만 App Store를 통해 이 방법도 제공되지 않는다. 그래서 몇 일 또는 몇 주 전에 버그가 이미 수정되었음에도 불구하고 애플리케이션에 대한 평점이 바닥으로 떨어지는 것을 앉아서 볼 수밖에 없게 되는 것이다.
물론, 이 이야기는 한 개발자의 경험을 바탕으로 한 것이다. 어쩌면 이는 주변의 예이고 실제 데이터는 이러한 이론을 확증하지는 않을지도 모른다. 그러나 문제는 여전히 남아있다. 개발자들은 Apple의 데이터나 App Store의 승인 절차의 실제 세부사항에 접근할 수 없다. 이러한 변화가 올 때까지 Objective-C로 native 애플리케이션을 만드는 것은 위험한 제안이라고 생각한다.
다행히 선택의 여지는 남아있다. 오픈 소스와 표준기반 웹 기술을 이용하여 웹 애플리케이션을 만들 수 있고 이를 실제 사용자가 로드한 상황에서 디버그하고 테스트할 수 있다. 일단 준비되면 웹 애플리케이션을 native 아이폰 애플리케이션으로 변경하고 App Store에 올린다. 궁극적으로 거부되더라도 여전히 웹 애플리케이션을 제안할 수 있기 때문에 물거품이 되어버리지는 않는다. 승인될 경우에는 장치에 알맞은 하드웨어 특징을 이용해서 웹 애플리케이션을 향상시키기 위한 기능을 추가하기 시작할 수 있다. 두 경우 모두 최고의 선택이 아닌가?
