iOS 쿠폰 시스템 구현 방법에 대한 고찰

현재 출시 되어있는 수많은 모바일 게임들을 살펴 보면 홍보를 목적으로 하는 쿠폰 시스템을 차용하고 있는것을 볼 수 있습니다. 이러한 쿠폰은 개발사에서 직접 발행한 문자/숫자로 이루어진 형태로 이루어져 있는 경우가 많으며 올아니 또는 오프라인의 실물 쿠폰을 만들어서 유저에게 뿌리고 있습니다. 가령 프렌즈팝의 경우 다음과 같은 모습의 오프라인 쿠폰이 있습니다.

ios_coupon_system_01

위의 쿠폰의 경우에는 이용방법을 읽어보면 “구글 플레이 혹은 애플 앱스토어에서” 라는 언급이 되어있습니다. 즉 이 쿠폰을 구글플레이/앱스토어에서 다운받은 프렌즈팝 게임에 사용할 수 있는다. 정도로 이해할수가 있습니다. 하지만 백발백중의 오프라인 쿠폰에는 다음과 같은 언급이 있습니다.

ios_coupon_system_02

“안드로이드 OS에서만 쿠폰을 입력할 수 있습니다”라는 부분이 중요합니다. 실제로 백발백중의 쿠폰을 사용하기 위해서 iOS판을 실행하여 설정 메뉴에 들어가 보면 다음과 같은 쿠폰 버튼이 존재하지 않습니다.

ios_coupon_system_03

iOS에서는 이 쿠폰을 사용할 수 없다는 이야기인데요 이는 단순히 개발자가 귀찮아서라는 이유는 아닐것입니다. 실제로 이렇게 쿠폰 시스템을 갖춘 게임/앱을 애플에 심사를 넣어보면 다음과 같은 리젝을 먹게 됩니다.

11.1

We found your app inappropriately unlocks or enables additional functionality with mechanisms other than the App Store, which is not in compliance with the App Store Review Guidelines.

Specifically, we noticed that the app utilizes codes to unlock features.

애플의 [리뷰 가이드라인]을 확인해 보면 11.1 항목에 다음과 같은 내용이 있습니다.

11. Purchasing and currencies

11.1
Apps that unlock or enable additional features or functionality with mechanisms other than the App Store will be rejected

앱스토어 이외의 어떤 매커니즘을 통해서 어떤 추가적인 기능이 언락되거나 활성화된다면 리젝될것이다..라는 무서운 언급인데요. 내가 만든 앱이지만 내 맘대로 하지도 못하게 하는 애플입니다. 결과적으로 앱스토어가 제공하는 기능들(예: In-App Purchase 등)을 제외한 모든 형태의 개발자가 개인적으로 구현한 유저에게 이익을 주는 행위는 리젝 사유입니다.

결론적으로 개발사가 임의로 구현한 쿠폰 시스템(예: 쿠폰 번호를 입력하면 다이아 500개 지급)은 애플에서 허용하지 않습니다. 하지만 iOS용 게임임에도 불구하고 쿠폰 시스템을 사용할 수 있는 게임을 볼 수 있습니다. 지금 부터 그런것을 어떻게 구현하면 될지 더 나아가 좀 더 나은 방법은 없을지 정리해 보겠습니다.

방법1. 서버에서 쿠폰 메뉴를 보여줄지 말지 결정하기

아마 이 방법이 많은 게임사들이 iOS에서 쿠폰 시스템을 구현하기 위해서 사용하는 방법이 아닐까 생각합니다. 게임뿐만 아니라 많은 앱들이 애플의 심사를 통과하는데 불필요한 화면들을 심사 기간동안 감추는 방법을 사용하고 있으며 나중에라도 애플이 걸리게 되면 좋은 일은 없겠지만 그럼에도 불구하고 많이들 사용하고 있는 방법입니다.

이 방법은 서버상에서 “심사” 플래그를 두고, 클라이언트는 실행되는 시점에 이 심사 플래그 값을 서버로부터 읽어갑니다. 심사 플래그가 참일 경우 클라이언트는 심사에 불리한 모든 기능을 보여주지 않는식으로 동작을 하게 합니다.

이후에 “Ready for Sale” 로 상태를 변경하면서 심사 플래그를 거짓으로 변경하면 일반 유저들은 온전히 모든 컨텐츠를 즐길 수 있게 됩니다.

방법2. 커스텀 스킴을 통해 앱 외부에서 쿠폰 정보를 넘겨받기

해외의 포럼글을 읽다가 매우 그럴싸한 글을 하나 발견하였습니다. 위에 언급한 서버에서 플래그를 두어서 쿠폰 메뉴를 보였다가 감추었다가 하는 방식은 애플의 불시 검문에 발각될(?) 가능성이 있습니다. 하지만 이러한 플래그를 두지 않고 앱 바깥에서 쿠폰지급을 처리한다면 문제가 다릅니다. 앱 내부에 쿠폰을 지급처리하는 어떠한 메뉴나 기능의 요소가 존재하지 않으며 바깥에서 지급처리를 하게 됨으로 애플의 불시 앱 검문에서도 문제가 되지 않습니다.

하지만 여기서도 생각해볼 문제가 하나 있습니다. 검증된 유저에게 한번의 지급만을 해야 한다면, 앱 외부에서 어떻게 해당 유저의 인증 여부를 명확하게 판단할 수 있을까요? 대부분의 인증 시스템의 구현은 앱 내부에서 구현되어있습니다. 하지만 이 부분은 앱 외부에서 쿠폰 정보를 들고 게임으로 넘어가는 방법으로 구현할 수 있습니다.

  1. 먼저 쿠폰 입력이 가능한 프로모션 페이지를 개발합니다. 이곳에는 일반적으로 게임 내부에서 볼 수 있는 쿠폰을 입력할 수 있는 폼이 존재하게 됩니다.
  2. 유저에게 전달될 쿠폰에 “구글플레이/앱스토어에서 XXX 게임을 검색해서 설치 후 설정 – 쿠폰 메뉴에서 다음의 코드를 입력” 이 문구 대신에 단순히 프로모션 페이지 URL에 접속하여 사용하라고만 안내합니다.
  3. 유저가 쿠폰입력 사이트에 접속하여 쿠폰을 입력한 뒤 “확인” 버튼을 누르면 앱이 설치되어있다면 해당 쿠폰 정보를 들고 앱을 실행하고 앱이 설치되어있지 않다면 앱 다운로드 URL로 이동시킵니다.
  4. 앱이 실행될 때 쿠폰 정보가 커스텀 스킴을 통해 입력되었다면 곧바로 지급 처리를 하고 팝업을 띄워 정상적으로 쿠폰 지급이 되었음을 알립니다.

대충 서버에서 쿠폰 페이지를 만든다면 예제는 다음과 같은 형태를 가질 것입니다.

<html>
<head>
  <script type="text/javascript">
    function formSubmit() {
		var couponValue = document.forms['couponForm']['coupon'].value;
		document.location = 'myCouponApp://?coupon=' + couponValue;
	}
  </script>
</head>
<body>
  <form name="couponForm" onsubmit="formSubmit(); return false;">
    쿠폰: <input type="text" name="coupon"/>
	<input type="submit" value="확인" />
  </form>
</body>
</html>

그리고 iOS의 경우 커스텀 스킴에서 저렇게 넘겨 받은 coupon의 값을 읽어서 아이템 지급 처리에 사용합니다. 다음의 메소드는 AppDelegate.m 파일에 추가해야할 부분입니다.

- (BOOL)application:(UIApplication *)app openURL:(NSURL *)url
  options:(NSDictionary<NSString *,id> *)options {

    NSString *query = [url query];
    NSArray *queryComponents = [query componentsSeparatedByString:@"&"];
    
    for (NSString *component in queryComponents) {
        NSArray *keyValue = [component componentsSeparatedByString:@"="];
        if ([[keyValue objectAtIndex:0] isEqualToString:@"coupon"]) {
            NSString *couponValue = [keyValue objectAtIndex:1];
            NSLog(@"입력된 쿠폰번호 : %@", couponValue);
            
            // 이곳에서 사용자 정보를 가져와 아이템을 지급 처리 합니다.
            // 처리 결과를 팝업 형태로 띄워서 알려줍니다.
        }
    }
    
    return YES;
}

이곳의 처리는 앱 내부에서 진입하여 처리되는 부분이 아니며 앱의 외부를 통해 접근할 때 실행되는 로직의 영역입니다. 하지만 앱 내부이기 때문에 기 로그인되어있는 유저의 정보에도 접근이 가능합니다. 즉 “쿠폰정보”와 “사용자 정보” 둘 모두가 있기 때문에 정상적으로 상품 지급의 처리를 할 수 있습니다. 물론 중복 처리를 막는 처리도 할 수 있겠지요.

참고 :

  • https://forums.coronalabs.com/topic/37264-rejected-by-apple-cause-of-promo-code-custom-solution/
  • https://forums.coronalabs.com/topic/37264-rejected-by-apple-cause-of-promo-code-custom-solution/