최초 작성일 : 2013/05/23 17:28


곧 완성을 앞두고 있는 신규 앱에는 야심차게(?) IAP(In-App Purchase:앱내 구매)를

구현해보기로 했다.

이유는 당근 유/무료 버전을 나누는 것 보다는 IAP가 더 수익성이 좋을 것 같았기 때문이다.
그래봐야 1년이 가도록 겨우 개발자 등록비 뽑는 수준이지만...ㅠ.ㅠ

우선 기본적인 구현은 문제가 없었다.
맥부기 회원들의 도움으로 쉽게 구현을 마쳤다.
그런데 문제는 애플 서버를 이용한 영수증 인증이다.
탈옥을 통한 일종의 해킹 방지 차원이랄까?

이를 위해 특별히 애플에서 기본 소스 코드도 배포를 하고 있다.
아래 링크로 가면 간단한 설명이 있는 페이지가 나오고 그 페이지의 우상단에 보면
Companion File이라고 링크가 걸려있는데 여기에 VerificationController.h와
VerificationController.m 요렇게 약소하게 파일 2개가 들어있다.


이 파일에 적절하게 코드를 추가하여 처리하면 된다.
일단 가장 자세한 설명이 있었던 맥부기의 글이 아래 링크에 있다.


대체로 이 글을 통해 구현을 완료하였는데...
문제는 관련 글에도 있지만 SANBOX로 테스트하던 것을 애플 리뷰 후
실 상품 서버로 연결해야 하는데 이 것을 어떻게 해야 하냐는 것과

기존 코드의 paymentQueue:(SKPaymentQueue *)queue updatedTransactions:(NSArray*)transactions
통해 수행하던 내용 중 [[SKPaymentQueue defaultQueuefinishTransaction:transaction];   
요넘을 어떻게 처리하느냐가 문제였다.

두 번째 문제의 경우 뭐 대충 델리게이트 써가면서 어렵지 않게 해결하였다.
특히 두 번째의 처리를 하지 않으니 IAP 서버에서 상품을 가져올 때마다
이전의 트랜잭션들이 모두 함께 내려와서 문제가 되었기에 반드시 처리를
해주어야 했다.

그리고 어렵게 처리한 첫 번째 문제

우선 구조가 NSMutableURLRequest를 이용해 서버에 연결하는 내용인데
처리는 우선 실 상품 서버로 연결을 하고 거기서 실패를 할 경우 테스트용 SANDBOX로
연결을 해야 하는 것이었다.

만일 테스트 계정으로 실 상품 서버로 연결을 하여 처리하게 되면
connection:didReceiveData: 함수에 response되는 결과값으로 21007이 떨어지게 된다.

이 21007이 확인된 이후 어떻게 해야 하는지에 대한 설명이 아무데도 없어서
혼자서 열심히 쌩X랄을 하였다.

우선 구매 요청부터 다시 보내보았다. 그랬더니 구매 팝업이 2번 뜨는 우스운 모양이
되어버려 실패...

다음으로는 처음 구매 요청후 생성된 transaction을 전역변수에 넣고 다시 서버 연결부 부터
진행을 해보았다. 역시 실패...

그리고 마지막에 처리한 것이 다음 방법이다.

영수증 인증을 위해 NSURLConnection을 이용하여
인증 서버로 연결할 때 인자로 넘기는 것이 transaction의 transactionReceipt 속성을
이용하여 만든 NSData형의 값이다.

그래서 전역 변수로 NSData형을 만들고 transaction. transactionReceipt를 이용하여
만든 NSData 값을 이 전역 변수에 할당 한 후 실 상품 서버에서 21007이 떨어지면
요넘만 인자로 넘겨서 다시 NSURLConnection커넥션을 하니 잘~ 처리가 되었다.

이로써 무사히 IAP 구현을 마치게 되었다...^^

위 설명한 프로세스를 요약하면 아래와 같다.

***
참고로  ITC_CONTENT_PROVIDER_SHARED_SECRET라는 값을 설정하도록 되어있는데
아무리 찾아봐도 내 계정의 아이튠즈 커넥트 화면에서는 그 값을 받아오는 링크가
보이질 않는다...ㅠ.ㅠ

설정을 안해도 테스트는 잘 되던데...이게 테스트이기 때문에 잘 되는 것인지...
요게 쪼끔 걸리네...ㅠ.ㅠ

============================================

PCStoreViewController : IAP 구매 화면 및 구매 시작을 담당함

구매버튼 터치시 아래 내용 실행
//payment는 SKPayment 타입의 전역변수

payment = [SKPayment paymentWithProduct:self.product];

 [[SKPaymentQueue defaultQueue] addPayment:payment];


addPayment 메서드 실행 후 델리게이트인 아래 메서드 실행

- (void) paymentQueue:(SKPaymentQueue *)queue updatedTransactions:(NSArray *)transactions


이 함수 내에서 transactions를 루프 돌리면서 각각의 transaction에 대해
transaction.transactionState에 따라 처리를 하게 되는데 다음 2가지 경우에 대해
VerificationController의 verifyPurchase:transaction 메서드를 호출한다.

SKPaymentTransactionStatePurchased

SKPaymentTransactionStateRestored



VerificationController : 영수증이 유효한 것인지 애플 서버를 통해 인증

 verifyPurchase:transaction 메서드 내에서 인자로 넘겨받은 transaction의
transactionReceipt 속성을 이용하여 NSData형의 값을 NSURLConnection을 통해 서버로 넘김 이 때 인자로 넘어가는 NSData를 전역변수에 할당을 해놓아 이후 21007
코드에 대비를 한다.

NSURLConnection의 델리게이트 메서드인 connection:didReceiveData:에서 최종 구매처리를 한다.
response 값으로 넘어온 NSData형의 data는 NSDictionary로 변환할 수 있는
JSON 값이며 여기에는 receipt라는 키로 NSDictionary 타입의 값이 들어있는데
이 값에는 각종 구매 정보가 들어있다.

그리고 status라는 키로 NSNumber 타입의 상태 정보가 넘어오는데 앞서 설명했듯이
테스트 계정으로 구매를 하는데 실 상품 서버로 연결을 하게 되면 이 값이 21007이
넘어온다.

만일 이 status가 이상이 없으면 (0이면) 구매 완료 처리를 하고 추가로 만든
델리게이트 메서드를 통해 finishTransaction 처리를 한 후 IAP 화면을 닫도록 하였고

21007인 경우 verifyPurchase: 메서드에서 전역변수에 저장해놓은 NSData를
인자로 하고 서버 주소는 SANDBOX(테스트)용 주소로 하여 다시 NSURLConnection
연결을 시도한다.

블로그 이미지

마즈다

이미 마흔을 넘어섰지만 아직도 꿈을 좇고 있습니다. 그래서 그 꿈에 다가가기 위한 단편들을 하나 둘 씩 모아가고 있지요. 이 곳에 그 단편들이 모일 겁니다...^^

최초 작성일 : 2012/10/15 11:21 


1. 카테고리 선정


가장 해보고 싶고 또 대박의 확률이 높은 뷴야가 게임이긴 하지만

스스로의 경험에 비추어보아서나 현재 시장 상황을 보아서나 아직까지 게임은 시기 상조라고 판단하였다.


게임을 제외하고 가장 사용자들이 꾸준히 사용하게되는 카테고리는 어떤 것인가에 대한 고민의 결과

선택된 분야가 '연락처'이다.


사실 연락처는 카테고리 구분이 모호하다. 유틸리티도 될 수 있고 생산성도 될 수 있고 비지니스도 될 수 있고

심지어는 소셜네트워크도 될 수 있다. 우선 위 열거한 카테고리 중 가장 인기가 좋은 소셜네트워크로

카테고리를 정할까 하다가 대부분의 연락처 앱들이 생산성 카테고리에 들어가있기에 나도 생산성으로

카테고리를 정하고 서브 카테고리를 소셜네트워크로 정했다.


사실 지금에 와서는 BizContact의 컨셉과도 부합하는 소셜네트워크쪽을 메인카테고리로 할 것을 그랬다는

생각이 절실하다.


애스토어에서 '연락처'를 검색해본 결과다. 생산성 카테고리가 많은 편이다.







2. BizContact의 중요 컨셉


21세기 IT 세상의 화두라면 역시 SNS다. 다양한 서비스들이 생겨나고 그중 일부는 상상을 초월하는 성공을

거두었다. 사람들은 비록 직접 보이지는 않지만 많은 사람들과 관계를 맺고자 하였고 이러한 열망을

크고 작은 서비스들이 충족시켜주었다.


돌이켜보면 인간을 사회적 동물이라 표현할 만큼 '사회성'이라는 것은 인간이 가진 기본적인 성향 중 하나이며

이런 성향을 표출시켜줄 서비스의 등장은 너무나도 당연한 일이다.


그렇다면 'SNS'라 불리워지는 서비스들이 생겨나기 이전에는 사람들이 어떤 방법으로 이러한 사회성을 유지하고 있었을까?

딱 잘라 말하자면 모바일 폰 그리고 그 안에 들어있는 '연락처'야말로 사람들이 사회성을 유지하고 또 그 영향력을

확대하기 위한 가장 강력한 정보였음이 분명하다.


즉 연락처는 SNS의 기원임과 동시에 현재로서도 그 형태가 다를 뿐 '연락처'라는 형식을 버리고는

SNS를 유지할 수 없다. 친구목록이 없는 페이스북이나 팔로워/팔로잉 목록이 없는 트위터를 상상할 수 있는가?

카톡은 대놓고 사용자들의 연락처를 뒤진다.


BizContact의 컨셉은 연기서 출발한다.

예전의, 전화번호나 주소, 이메일 주소 등만을 기록하던 연락처가 아닌, 그 연락처 안에서 현재 제공되는

SNS 서비스들의 친구들까지 관리해 줄 수 있는 연락처를 확대한 개념의 연락처.


그래서 BizContact는 연락처 안에서 그 연락처의 대상이 활동하고 있는 SNS(현재로서는 페이스북과 트위터)의

정보들을 추려서 볼 수 있도록 하고 이메일의 경우에도 단지 상대방에게 이메일을 보내는 기능에서 벗어나

상대방이 보낸 이메일만을 모아서 볼 수 있는 특화된 기능들이 추가되었다.



iOS 6에서 트위터와 페이스북 계정이 통합되었다.





각각의 계정에 로그인하면 연락처와의 동기화 옵션이 나타난다.






3. 한계


앞서 이야기한 바와 같이 카테고리 및 앱 성경에 대한 홍보에 문제가 있었다.

BizContact의 가장 중요한 특징은 SNS로 확장된 연락처 이상의 무엇이다. 굳이 말을 만들자면 Social Manager이다.

하지만 초기 판매당시 카테고리 자체도 생산성으로 정해진데다가 '연락처'라는 분야에 초점이 맞다보니

상대적으로 다른 연락처 앱에 비해 연락처 앱이 가져야할 필수 요건 몇가지가 빈약한 BizContact로서는 충분한

자기 어필을 할 수가 없었다. 그렇게 BizContact는 그냥 '연락처' 앱으로 전락하고 말았다.


또하나 '연락처'앱이 가질 수 밖에 없는 태생적 한계는 바로 애플의 제한으로 인해 기본 전화 앱의 정보에 접그할 수가

없다는 것이다.


사용자들이 연락처에 대해 중요시하게 생각하는 정보 중 하나가 부재중 수신에 대한 부분이다. 하지만 현재 개발자들은

이 내용을 표시해 줄 수가 없다. 이는 사용자들로 하여금 어쩔 수 없이 기본 전화 앱으로 가도록 만드는 악재 중의 악재이다.


사용자들이 중요시 여기는 부재중 통화(모든 수신목록 및 문자 데이터)에

접근하지 못하는 한계가 있다.



 


4. 전략적 과제


가장 기본적인 앱의 안정성은 두말하면 잔소리이니 제쳐두고...

무엇보다도 BizContact가 '연락처'라는 좁은 범위에서 벗어나는 것이 최우선 과제라고 볼 수 있다.

그러기 위해서는 전체적인 UI가 일반 연락처와는 달라질 필요가 있다. 즉 사용자의 정보 범위가 넓은 만큼

실제 화면상에서 사용자의 정보를 보여주는 영역이 많은 부분을 차지해야 한다. 물론 그 정보를 보기 위해

들어가야 하는 depth역시 최대한으로 줄여야 하는 것은 물론이다.


또한 SNS의 측면이 강화된다면 당연히 패드에 대한 진출도 고려를 해야 한다.

그저 연락처라 하면 '전화'를 기준으로 생각하기 마련이다. BizContact는 이 제약으로부터 벗어나야 한다.


문제는 이미 출시된 지 5개월이 다되가는 현재 기존 사용자들에게 박힌 선입관을 과연 극복할 수 있을까 하는 것이다.

최악의 경우 동일한 기능에 UI만 완전히 바뀐 새 앱을 출시해야 할지도 모른다…ㅠ.ㅠ

(실제로 그 준비도 진행 중이다…-.-)



요런 것이 BizContact만의 특징...^^;;;










5. 개인적인 꿈


나는 BizContact를 아이폰의 필수 앱 중 하나로 만들고자 한다.

마치 전화기에 연락처가 필수적이 듯…

얼마나 특화된 기능을 거부감 없이 BizContact에 심어 넣는냐 하는 것이 최대 관건이 될 것이다.

그리고 아직은 BizContact가 알려지지 않아 '나쁜 예'로서 자리잡고 있어서 별 문제 없겠지만

BizContact가 '좋은 예'로 격상되는 순간 등장하게 될 수많은 유사 앱으로부터 어떻게 자리를

지켜 나가야 하는지도 쉽지 않은 문제일 것이다.


BizContact 혹은 새롭게 탄생될 다른 Social Manager 앱이 스테디 셀러이자 아이폰의 킬러 앱이

되는 그날까지 '한 놈만 팰' 작정이다…^^

블로그 이미지

마즈다

이미 마흔을 넘어섰지만 아직도 꿈을 좇고 있습니다. 그래서 그 꿈에 다가가기 위한 단편들을 하나 둘 씩 모아가고 있지요. 이 곳에 그 단편들이 모일 겁니다...^^

최초 작성일 : 2011/05/18 09:23 


iPhotoDiary를 2.0으로 업그레이드하면서 일기 작성시 앱이 죽는 버그가 생겼다.

가능한한 빨리 작업하고 아이튠즈 커넥트에 업데이트 등록을 했는데
그 때가 벌써 4월 28일이다.

그리고 5월 7일 첫 reject 메일이 날아왔다. 내용은 다음과 같다.

Hello HYOUNG JUN WOO|1074475225,

Thank you for submitting iPhotoDiary to the App Store.

We've completed the review of your app, but cannot post this version to the App Store because it did not comply with the App Store Review Guidelines, as detailed below:

  • 8.1: Apps must comply with all terms and conditions explained in the Guidelines for using Apple Trademark Names and the Apple Trademark Products List

To reply to this message or to get more information, visit the Resolution Center in iTunes Connect. Do not reply directly to this email.

Regards,

App Review

Converse with fellow developers and Apple engineers on technical topics.

Apple Developer Forums — http://devforums.apple.com 

일단 앱스토어 리뷰 가이드라인의 8.1 조항을 어겼다는 것이고
이 조항은 애플의 트레이드마크로 등록된 이름들과 제품들의 사용에 관한
내용으로 쉽게 말해 애플 제품의 이름을 아무렇게나 사용하면 안된다는 것이다.

사실 이전 버전들이 아무런 문제 없이 등록이 되었기에 별로 심각하게 생각지 않았고
그래서 혹시나 앱을 설명하는 내용중에 문제가 있나 싶어 앱 설명을 대폭 줄여서
핵심적인 내용만 남기고 다 지워버렸다.

그리고 다시 5월 14일에 동일한 내용으로 reject 메일을 받았다.
이번엔 좀 요모조모 살펴보았다.

아하...그런데 아이튠즈 커넥트 사이트에 이전엔 못봤던 링크가 하나 눈에 들어왔다.
리젝 사유에 대해 자세히 설명하는 내용이 들어있는 페이지로 가는 링크였다.
아쉽게 해당 내용을 캡쳐하지는 못했지만 핵심적인 내용은 앱 이름에 애플 제품의
이름이 직접 들어가면 안되다는 것이 핵심이었다.

즉 나의 앱 이름은 iPhotoDiary였고 여기에 iPhoto라는 애플의 제품명이 들어있어서
결국 리젝된 것이었다.

애플 제품 이름을 사용할 경우 애플에서 권장하는 방식은

앱 이름 - for iPhone

이런 형식이다.

어쨌든 황당한 것은 처음 등록부터 2차례의 업데이트까지 모두 통과했었는데
이제와서 이런 사유로 리젝을 당하니 사실 좀 불쾌한 느낌도 들었다.

하지만 가이드라인을 제대로 확인 안한 잘못도 있고 또 갑작스레 애플의 정책이
강화되었겠거니 하고 그냥 넘어가는 수 밖에...
내가 잡스랑 맞짱뜰 군번도 아니고...

암튼 이런 리젝은 좀 짜증나는 것이 사실이다...-.-

블로그 이미지

마즈다

이미 마흔을 넘어섰지만 아직도 꿈을 좇고 있습니다. 그래서 그 꿈에 다가가기 위한 단편들을 하나 둘 씩 모아가고 있지요. 이 곳에 그 단편들이 모일 겁니다...^^

최초 작성일 : 2011/04/14 20:15 



App name : 전단지 (또는 동네마트)

내용 :

서비스 개요

동네 마트에서 배포되는 세일 전단지(추후 전자제품이나 피자, 치킨 등으로 확대)를

웹으로 입력받아 스마트폰으로 배포하는 서비스


서비스의 효과

- 불필요한 쓰레기를 만들어내는 종이 전단지를 모바일 전단지로 대체하는 효과

- 전단지가 디지털화 됨으로써 전단지 내용을 정보화 할 수 있는 효과


수익모델

- 전체 메인화면 혹은 지역별 메인 화면의 파워링크를 통해 유료 등록한 마트가 가장 앞에

    보여지도록함

- 증강현실 기능, 구매 목록을 미리 정해놓을 수 있는 간이 장바구니 기능, 상품별 가격비교 정보의

    제공 상품별 가격 변동 추이 정보 제공 등을 유료로 서비스


서비스 내용

- (웹)가맹업체(마트)는 전단지에 들어갈 컨텐츠(제품 사진, 가격 정보 등)을 웹사이트를

    이용하여 업로드

- (오프라인)서비스 제공자는 가맹업체들이 업로드한 전단지를 모바일 디바이스에 적절한 형태로

    재편집하여 서비스함

- (웹)가격 정보등의 별도로 DB화 하여 누적시켜 추후 가격 변동 추이 등의 정보제공

    서비스에 이용

- (모바일 + 웹)가맹업체의 위치 정보를 DB화하여 사용자들에게 증강현실 기능을 통한 정보 제공

- (모바일 + 웹)특히 여행이나 출장 등 타 지역에 갔을 때 주변 마트 정보를 활용하기 좋음

- (모바일)모바일 디바이스에서 세일 품목을 선택하여 쇼핑 전에 미리 구매 목록을

    만들 수 있도록 함

- (모바일 + 웹)각 마트별로 가격 비교를 하여 같은 제품을 더 싸게 살 수 있는 곳을 안내

- (모바일 + 웹)누적된 가격 정보를 통해 구체적인 상품에 대한 체감 물가 변동률을

    알 수 있도록 함


적용 기술 : 증강현실, LBS, 기타 웹서비스 관련 기술

확인 사항 :

위험요소

- 전단지 내용이 작은 스마트폰 화면에서도 잘 보이도록 가독성을 높이는 문제

- 사업 초기의 영업 활동을 통한 충분한 전단지 제공처 확보

- 가격 비교등의 서비스를 제공함으로 인해 가맹업체(마트)간의 경쟁 과다 및 이로인한

    가맹업체의 탈퇴문제

- 전단지의 모바일용 편집에 소요되는 인건비의 증가 문제


블로그 이미지

마즈다

이미 마흔을 넘어섰지만 아직도 꿈을 좇고 있습니다. 그래서 그 꿈에 다가가기 위한 단편들을 하나 둘 씩 모아가고 있지요. 이 곳에 그 단편들이 모일 겁니다...^^

최초 작성일 : 2011/03/25 16:32 






거의 1년이 다되서 두 번째 업데이트를 했습니다.
큰 변화는 없지만 신경을 좀 썼습니다...^^

변경사항

1. 달력의 절기표시를 수정하였습니다. 절기를 구하는 함수를 추가하여
    절기가 표시되도록 하였습니다. 절기를 구하는 함수는 PHPSCHOOL의 산이님이
    PHP로 만든 소스 중에 절기를 구하는 부분만 Objective-C로 변환하여 사용하였습니다.

2. 일기 작성시 날씨와 현재 위치의 주소값이 자동 표시되도록 하였습니다.
    현재 날씨는 구글 날씨API를 사용중인데 국내 대상 앱이므로 조만간 기상청
    데이터로 변경 예정입니다.

3. 디자인을 변경하였습니다. 레티나 디스플레이를 지원하도록 하였습니다.

소스코드 : https://github.com/woohj70/iPhotoDiary 

블로그 이미지

마즈다

이미 마흔을 넘어섰지만 아직도 꿈을 좇고 있습니다. 그래서 그 꿈에 다가가기 위한 단편들을 하나 둘 씩 모아가고 있지요. 이 곳에 그 단편들이 모일 겁니다...^^

최초 작성일 : 2011/03/01 00:21 


커스텀 컨트롤 개발 계획의 첫번째로 커스텀 달력을 구현함



현재까지 구현된 기능

1. 토, 일요일 별도 색 표시
2. 언어 설정에 따라 요일명 변경(현재 영어와 한글만 지원)
3. 전달, 다음달 이동 기능
4. '오늘' 표시 기능

개발자가 커스터마이징 가능한 부분

1. 달력에 사용된 이미지 변경
2. 음력 표시 기능
3. 절기 및 국경일 표시 기능

등등...

커스터마이징의 경우 이미 공개된 iPhotoDiary의 소스를 참고하여 수정 가능함
이 달력 소스는 iPhotoDiary에서 사용한 달력을 그대로 가져와 소스만 좀더 단순하게
수정한 것임.

iPhotoDiary 소스코드 : https://github.com/woohj70/iPhotoDiary

블로그 이미지

마즈다

이미 마흔을 넘어섰지만 아직도 꿈을 좇고 있습니다. 그래서 그 꿈에 다가가기 위한 단편들을 하나 둘 씩 모아가고 있지요. 이 곳에 그 단편들이 모일 겁니다...^^

최초 작성일 : 2011/03/01 00:14


★ 아무리 저질이어도 배경으로 사용된 이미지는 제 창작물이니
저작권을 지켜 주시면 고맙겠습니다...^^






새로 개발 중인 무료 앱 ArtClock에 기본 달력 컨트롤을 구현하였음
더불어 달력 컨트롤을 쉽게 사용할 수 있도록 코드를 수정하여
Mazdah's CustomControl 프로젝트에도 업데이트 함.

블로그 이미지

마즈다

이미 마흔을 넘어섰지만 아직도 꿈을 좇고 있습니다. 그래서 그 꿈에 다가가기 위한 단편들을 하나 둘 씩 모아가고 있지요. 이 곳에 그 단편들이 모일 겁니다...^^

최초 작성일 : 2011/02/22 15:52 







AppStore : iPhotoDiary



사실 네이버의 맥부기 카페에 연재하고 있던 [실전 소스 분석] 마무리 짓고 

소스를 공개하려고 했는데 이래저래 바쁘다보니 연재가 언제 재개될지 기약이 없네요.

그래서 일단 소스를 먼저 공개합니다.


염두에 두실 것은 제가 머리털나고 처음 Objective-C 아이폰을 접하면서 독학으로

만든 것이다보니 소스의 수준이 한참 저질입니다...^^;;;


특히 초보분들은 섣불리  코드 따라 쓰지 마세요...^^;;;

물론 어디에 어떤 용도로 쓰든지 그것은 자유입니다.


그리고 고수분들은 혹시라도 제게 조언을 해주실 것이 있으면

아낌없는 조언 부탁드리겠습니다.


뭐 가장 찾으실만한 내용은 음력을 지원하는 달력이 있는데요

이게 주워온 소스를 사용하다보니 메모리 누수가 보이는 부분이 좀 있네요.

그 부분으 주의 하세요.


https://github.com/woohj70/iPhotoDiary

블로그 이미지

마즈다

이미 마흔을 넘어섰지만 아직도 꿈을 좇고 있습니다. 그래서 그 꿈에 다가가기 위한 단편들을 하나 둘 씩 모아가고 있지요. 이 곳에 그 단편들이 모일 겁니다...^^

최초 작성일 : 2011/01/11 17:34 





내가 만든 2번째 아이폰 앱인 Day Recorder Pro/Lite가 지난 1월 3일자(미국시간)으로
Ready for sale 되었다.

잘 만들어진 앱은 아니지만 그럭저럭 쓸만한 기능들도 좀 있고 또 이번에는 세계 모든
시장에 등록을 하였기에 그래도 무료버전인 Day Recorder Lite만큼은 하루에 몇백건씩은
다운로드가 될 줄 알았다.

그런데 이게 어찌된 일인가?
앱스토어에 앱이 등록된 지 일주일이 넘은 시점에 전체 다운로드 수는 무료버전인
Lite가 모두 57개, 유료버전인 Pro가 모두 21개(그 중 15개는 프로모션 코드로 받은 것들임...-.-)...

처음 만들어 올린  iPhotoDiary가 무료 버전으로 국내 시장만을 대상으로 하여
그래도 꾸준하게 하루 평균 10개 정도의 다운로드를 기록하고 있는 것에 비하면
뭔가  납득하기 어려운 결과다. 하지만 아무리 눈을 씻고 봐도 이게 현실이었다...ㅠ.ㅠ

상황이 이렇다고 해서 포기해버리기엔 그간 투자한 시간이 너무도 아쉬우니 우선
무엇이 문제인가 분석해보는 것으로 재활용(?)을 시작해보자.

1. 좋지 못한 디자인과 스크린샷

앱을 구매하는 대다수의 고객들은 구질구질한 설명 보다는 앱의 아이콘이나
앱스토어에서 보여지는 스크린샷을 근거로 앱을 구매하는 경우가 많다는 이야기를
본 적이 있다. 이것은 결국 앱의 디자인이 얼마나 중요한지, 그리고 자신의 앱을
잘 표현할 수 있도록 스크린샷을 잘 잡아내는 것이 얼마나 중요한지를 알 수 있게
해주는 사용 행태이다.

결국 본업이 개발자인 내가 직접 한 디자인이 얼마나 형편없었는지가 입증된 것이다...ㅠ.ㅠ

그렇다 할지라도 무료 버전의 경우 단지 호기심에서 받아보는 경우도 적지 않을터,
그런 면을 감안하더라도 무료버전 다운로드 횟수는 너무도 적은 수치이다.
그렇다면 다음의 이유 때문일까?

2. 어설픈 국제화

처음 iPhotoDiary를 만들어 올리고는 하루 평균 10건 정도밖에 안되는 다운로드 수에
엄청 좌절했었다. 그래서 고민끝에 내린 결론은 역시 세계 시장에 도전을 해야 한다는
것이었다. 하지만 그 과정에서 지역화를 고려하지 않아 정작 국내 사용자들에게
한글로된 설명과 앱을 제공하지 못한 것이 문제 중의 하나였다.

더욱 안좋은 것은
영어로된 설명 조차 검증받지 못한 상태로 작성된 것이라 영어권 사용자들에게조차
그 의미가 제대로 전달이 된 것인지도 확실치 않다는 것이다.

결국 전문적이지 못한 국제화 작업이 사실상 세계 어느 곳에서도 의미가 통하지 않는
이상한 설명문을 만들어냈고 이것이 사용자들로 하여금 다운로드 받는 것을 주저하게
만든 것이 아닐까 하는 생각이다.

게다가 텍스트가 의미가 통하지 않는다면 스크린샷 같은 이미지로 감을 잡아야 하는데
이조차 1번에서 설명한 바와 같은 문제를 안고 있다보니 역시너지(?)를 만들어 낸 것 같다.

3. 비인기 카테고리의 선택

Day Recorder Pro/Lite는 메인 카테고리가 라이프 스타일이고 서브 카테고리가
여행이다.

앱스토어에 등록된지 일주일이 지난 현재 Pro버전은 오늘(11일) 업데이트가 되어
카테고리의 첫 페이지에 있고 Lite 버전도 아직 두 번째 페이지에 있다.

그만큼 사용자도 적고 그래서 등록되는 앱의 수도 적다는 말이다.
내 앱이 가지고 있는 가치를 보여줄 기회조차 제대로 얻을 수 없었던 것은 아닐까?








4. 프로모션의 부재.

메인 시장을 미국으로 잡은 주제에 실제로 프로모션 코드는 내가 활동하고 있는
카페에 대부분 배포하였다... 이게 뭔 삽질인지...-.-

외국의 유명한 아이폰 앱 관련 블로그에 프로모션을 해야 하겠지만 2번에서도
언급했듯이 언어의 장벽이 만만치 않다...ㅠ.ㅠ

5. 앱의 완성도 부족

가장 중요한 내용이네요. 완성도가 부족한 앱은 무얼 해도 안팔리겠죠...-.-

일단은 짐작할 수 있는 4개의 이유를 적어보았다. 물론 어느 하나 확실한 근거가
있는 것은 아니다. 단지 심증일 뿐.

하지만 이렇게까지 처참한 결과가 나온 데에는 반드시 이유가 있을 것이고 그 것을
밝혀내야 내가 3개월을 고생해서 만든 앱을 그나마도 쓸모있게 만드는 일일 것이다.

아울러 아직도 포기하고 싶지 않은 이유는 Long tail의 법칙을 믿기 때문이다.
비록 지금은 이렇게 누구의 눈에도 띄지 않고 사장되어 있지만 어차피 앱스토어에
등록되어있는 동안 비용이 들어가는 것도 아니고 취미 삼아 조금씩 조금씩 개선을하고
업데이트를 해 나가면 언젠가는 좋은 앱이 되고 많은 사람들에게 알려질 수 있지 않을까 하는
조금은 야무진 꿈을 꿔본다...^^;;;

블로그 이미지

마즈다

이미 마흔을 넘어섰지만 아직도 꿈을 좇고 있습니다. 그래서 그 꿈에 다가가기 위한 단편들을 하나 둘 씩 모아가고 있지요. 이 곳에 그 단편들이 모일 겁니다...^^

최초 작성일 : 2010/12/24 02:10 


사유는 백그라운드 실행시 위치 정보 업데이트 시키는 부분과 관련된 문제인데요.

제가 어딜 잘못했는지 확인하는데만도 시간이 좀 걸릴 것 같고 그리 중요한 기능도 아니고 해서
그냥 백그라운드 위치 정보 사용 관련 부분을 info.plist에서 제외시키고 다시 올렸습니다.

이번엔 통과해야 할텐데 걱정이네요...ㅠ.ㅠ
아래는 메일 전문입니다.

Thank you for submitting Day Recorder Pro to the App Store.
 
We've completed the review of your app, however, we cannot post this version to the App Store because it does not provide any functionality that requires persistent location, but it uses the location background mode, which is not in compliance with the App Store Review Guidelines <https://developer.apple.com/appstore/resources/approval/guidelines.html>:
 
 2.16 Apps may only use background multitasking for one of the approved background modes; VoIP, audio playback, location, task completion
We have included additional details below to help explain the issue and hope you’ll consider revising and resubmitting your application.
 
Your app has declared support for location in the UIBackgroundModes key in your Info.plist. You'll need to add features that require location updates while the app is in the background or remove the "location" setting from the UIBackgroundModes key. 
 
You may wish to refer to the section "Executing Code in the Background" found in the iOS Reference Library <http://developer.apple.com/library/ios/#documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/BackgroundExecution/BackgroundExecution.html>.
 
In addition, your application is using Location Background Mode, you will need to include a battery use disclaimer in your marketing text. Please add the following notice to your Application Description in iTunes Connect, "Continued use of GPS running in the background can dramatically decrease battery life."
 
While your application has been approved, please be sure to update the application description as soon as possible to avoid any interruption in the availability of your app on the App Store. 
 
For future app submissions, please be sure to review the App Store Review Guidelines Guidelines <https://developer.apple.com/appstore/resources/approval/guidelines.html> to help ensure a successful app review.
 
If you have any questions about this response, or would like to discuss it further, please feel free to reply to this email. If you would like to appeal this review, please submit a request to the App Review Board at <http://developer.apple.com/appstore/resources/approval/contact.html>.

블로그 이미지

마즈다

이미 마흔을 넘어섰지만 아직도 꿈을 좇고 있습니다. 그래서 그 꿈에 다가가기 위한 단편들을 하나 둘 씩 모아가고 있지요. 이 곳에 그 단편들이 모일 겁니다...^^