대다수의 많은 사람들처럼 나도 아이폰을 접한 즉시 아이폰에 매료되었다. 나는 웹 개발자이기 때문에 처음에는 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에 올린다. 궁극적으로 거부되더라도 여전히 웹 애플리케이션을 제안할 수 있기 때문에 물거품이 되어버리지는 않는다. 승인될 경우에는 장치에 알맞은 하드웨어 특징을 이용해서 웹 애플리케이션을 향상시키기 위한 기능을 추가하기 시작할 수 있다. 두 경우 모두 최고의 선택이 아닌가? ---머리말중에서

모바일 폰이 스마트폰으로 발전하면서 데스크톱 애플리케이션 위주에서 이제는 모바일 애플리케이션의 시대로 가고 있음을 많이 실감하게 된다. 모바일 애플리케이션의 요구가 많음에도 불구하고 지금까지 개발자들에게 큰 호응을 얻지 못한 이유는 프로그램이 장치 독립적이지 못했기 때문일 것이다. 개발자에게 새로운 환경과 또다른 언어의 습득은 큰 부담이 아닐 수 없다. 모바일 개발을 고려하는 대부분의 개발자들은 아이폰 또한 Mac환경에서 Object-C를 배워야 한다고 알고 있을 것이다. 이 책은 제목에서 알 수 있듯이 이러한 편견과 부담감을 여실히 깨주는 가뭄의 단비와 같은 책이 될 것을 확신한다. 사용자는 늘 개발자가 만든 것 이상의 기능을 요구하고 그리 오래 기다려주지 않는다. 이에 Apple은 편리하고 합리적인 환경을 제공해주지 못한다. 이 때 개발자가 발휘할 수 있는 융통성을 이 책에서 알려주고 있다. 이 책은 웹 개발자라면 누구라도 쉽게 아이폰 애플리케이션 개발자가 될 수 있도록 도와주는 친절한 안내서가 될 것이다.

HTML, CSS, JavaScript를 안다면 아이폰 애플리케이션 개발을 위해 필요한 툴을 이미 다룰 수 있는 것이다. 이 책을 통해 여러분은 Objective-C나 Cocoa를 사용하지 않고 플랫폼 위에서 아이폰과 아이팟 터치를 위한 애플리케이션을 디자인하고 작성할 수 있는 오픈 소스 웹 기술들을 사용하는 방법을 배울 것이다.<br/><br/>장치에 구애받지 않는 애플리케이션이 미래의 흐름이고, 이 책에서 여러 플랫폼에 대한 하나의 제품을 생성하는 방법을 여러분에게 보여줄 것이다. 무료인 PhoneGap 프레임워크를 이용하여 여러분의 제품을 native 아이폰 애플리케이션으로 바꾸기 위한 가이드라인을 발견할 것이다. 그리고 버그를 찾아 수정하고 테스트하기 위해서는 여러분의 제품을 우선 웹 애플리케이션으로 출시하는 것이 Apple이 제공하는 툴을 이용하여 App Store에 바로 올리는 것보다 훨씬 빠르다는 것을 알게 될 것이다.<br/><br/>■ 이미 다룰 수 있는 툴을 이용하여 아이폰 애플리케이션을 작성한다.<br/>■ 아이폰 애플리케이션처럼 보이고 또 그렇게 동작하는 기존의 웹사이트를 만드는 방법을 배운다.<br/>■ 웹 애플리케이션에 애니메이션을 추가하기 위해 jQTouch를 사용한다.<br/>■ 아이폰이 오프라인 상태일 때에도 애플리케이션이 작동하도록 Client-Side 데이터 기억장치를 활용한다.<br/>■ JavaScript를 이용하여 accelerometer, geolocation, vibration과 같은 향상된 아이폰 기능에 빠져본다.<br/>■ 애플리케이션을 Xcode로 App Store에 올린다.<br/><br/>이 책의 대상 독자<br/>이 책을 읽는 독자는 HTML, CSS, JavaScript(특히 jQuery)를 읽고 쓰는 기본 경험이 있다고 가정한다. 5장과 6장에서는 약간의 기본적인 SQL 코드를 포함하고 있기 때문에 SQL 문법을 잘 알고 있다면 도움이 되겠지만 필수 사항은 아니다.<br/><br/>이 책을 읽기 위해 필요한 도구<br/>이 책은 가급적 아이폰 SDK의 사용을 자제할 것이다. 대부분의 예제들을 따라하기 위해서는 텍스트 에디터, 최신버전의 Safari (또는 아직은 더 나은 Webkit: Mac과 Windows 모두에서 사용 가능한 최첨단 버전이고 http://webkit.org에서 구할 수 있다)가 필요하다. 7장에서는 PhoneGap을 위해 Mac이 필요하며 여기서는 web app를 native app로 바꾸는 방법을 설명하고 App Store에 올릴 것이다.

모바일 개발의 미래는 CSS, HTML, JavaScript이다. Jonathan은 이 기술들을 이용하여 native 아이폰 애플리케이션을 작성하는 방법을 여러분에게 보여줄 것이다.
John Allsopp (Web Directions의 저자이자 설립자)

Jonathan의 책은 모바일 Safari에서 웹 애플리케이션을 가능하게 하는 가장 포괄적인 문서이다.
Brian LeRoux (Nitobi Software)