지혜의 개발공부로그

iOS URI Schemes, Universal Link, Native Link

09 Feb 2022 | URI Schemes Universal Link Native Link

개인적인 연습 내용을 정리한 글입니다.
더 좋은 방법이 있거나, 잘못된 부분이 있으면 편하게 의견 주세요. :)

iOS의 경우 기본적으로 샌드박스 환경이기 때문에 다른 앱들간 정보를 주고받는 것이 간단하지 않습니다.
이때 정보를 주고받을 수 있는 대표적인 방법 중 하나가 URI Schemes입니다.


우선 잠깐의 정보 공유!

  • 딥링크: 상세 콘텐츠로 유저를 랜딩 시키는 링크. 대부분의 웹 링크가 딥링크에 속함
    • 모바일 딥링크는 3가지 방식으로 구분됨(URI Scheme, 유니버설링크(iOS), 앱링크(AOS)
  • URI Scheme: 애플의 iOS9이전까지의 표준 딥링크 형식
  • 유니버설 링크: iOS9부터 그 이후의 표준 딥링크 형식

1. URI Schemes

앱의 고유한 scheme을 정의하고 이 scheme으로 시작하는 URL 안에 정보를 담아서 URL을 열게 되면 해당 scheme가 갖는 다른 앱을 실행하면서 정보전달을 할 수 있게 됩니다. (특정 뷰컨트롤러를 여는 것이 아니라 스키마를 통해 앱 자체를 여는것임을 명확히 알고 있어야 합니다.) 하지만 이 방법에는 치명적인 단점이 존재합니다. 애플 앱 스토어에서 해당 앱이 정의한 scheme의 고유성을 보장해주지 않기 때문에 다른 앱들이 자신이 정의한 scheme을 사용하고 있을 수 있기 때문입니다.

내 앱을 ZehyeApp이라고 하고 zehyeapp://이라는 custom URL scheme 사용한다고 가정해 봅시다.

이렇게 정의한 커스텀 스키마는 유니크가 보장되지 않는다는 특징을 가지기 때문에, 앱스토어에 올라온 다른 앱에서 내가 지정한 스키마와 동일한 이름의 스키마를 사용하고 있다면 이때 어떤 앱이 실행될지 모르는 일이 발생할 수 있게 됩니다. 즉, ZehyeApp과 OtherApp이 동시에 설치되어있는 디바이스에서 두 앱 모두 zehyeapp://이라는 동일한 스키마를 사용하고 있었고, 이때 해당 스키마를 실행시키게 된다면 이 두 앱중에 어떤 앱이 실행될지 모르는 상황이 발생한다는 것입니다. 이는 설치 순서에 영향을 받는것도 아니고 특정한 규칙이 있는것도 아니기 때문에 상황에 따라 항상 랜덤하게 앱이 열릴 수 있다는 단점이 존재하게 됩니다.

즉 이는 보안상의 헛점이 존재한다는 것을 의미하게 되죠.

이를 보안하기 위해 등장한 것이 유니버설 링크입니다.


앱 번들 아이디를 미리 특정 도메인의 웹 사이트에 등록하는 방식으로 해당 도메인과 서버의 소유권이 있어야지만 사용할 수 있기 때문에 custom URL Scheme처럼 어뷰징되는것이 불가능한 것이 특징입니다. 이를 하기 위해 우선 해야할 동작은 앱에서 유니버셜 링크를 허용할 도메인을 추가 하는 것 입니다.

예: applinks:zehye.co.kr

즉, 사용자가 앱 설치 시 여기에 등록된 도메인으로 apple-app-site-association 파일에 대한 요청을 보내게 됩니다.

위 그림처럼 올바르게 추가 되어있다면 유저가 유니버설 링크를 탭하면 iOS가 앱을 실행하게 됩니다.

유니버설 링크로 들어오는 요청은 UIApplicationDelegate의 application:continueUserActivity:restorationHandler:메서드에서 전달받은 NSUserActivity객체를 사용해 처리가 가능합니다.

- (BOOL)application:(UIApplication *)application continueUserActivity:(NSUserActivity *)userActivity restorationHandler:(void(^)(NSArray * __nullable restorableObjects))restorationHandler {
    if ([userActivity.activityType isEqualToString:NSUserActivityTypeBrowsingWeb]) { // NSUserActivityTypeBrowsingWeb 타입이다.
        // userActivity.webpageURL 로 대상 URL을 확인할 수 있다. 값이 없는 경우는 없다.
        ...
        return YES; // 처리하려면 YES
    }
    return NO; // 아니라면 NO
}

그런데 만약 앱이 close 된 상태라면 application:continueUserActivity:restorationHandler:가 호출되지 않는데, 이럴때는 didFinishLaunchingWithOptions:메서드에서 옵션을 가져와 처리가 가능하다.

// In application: didFinishLaunchingWithOptions:
NSDictionary *activityDic = [launchOptions objectForKey:UIApplicationLaunchOptionsUserActivityDictionaryKey];

if (activityDic) {
    // Continue activity here
}


브랜치에서 이번에 새로운 네이티브 링크라는 것이 출시 되었습니다.
네이티브 링크는 브랜치의 디퍼드 딥링크 기능 중 하나로 앱 설치 과정에서 정보가 손실되는 한계를 보완한 새로운 기능입니다.

애플은 이번 iOS15에서 Private Relay 를 도입하게 되었습니다. 이 비공개 릴레이는 유료 iCloud 고객(iCloud+)을 위한 개인용 VPN이라고 생각하면 쉬운데, 예를 들어 유저가 iCloud 저장공간을 쓰기 위해 0.99 달러를 지불하게 되면 유료 서비스의 일환으로 비공개 릴레이를 사용할 수 있게 되고 이 비공개 릴레이는 iCloud+ 고객이 사파리를 사용할때 해당 유저의 IP주소와 브라우징 데이터를 mask(보호)하는 것이 특징입니다.

기존 딥링크 방식은 유저가 이미 앱을 설치했을 경우 링크를 클릭하자마자 곧바로 앱의 원하는 곳으로 이동하게 되는것이 특징입니다. 이 과정에서는 비공개 릴레이의 영향을 받지 않고 앱이 설치되어있지 않은 유저가 링크를 클릭하게 되면 유저는 앱스토어로 이동을 하게 되고, 유저의 클릭 위치는 원격에 저장되어 있다가 유저의 앱설치가 완료되면 이 저장된 데이터를 참고해 유저가 원하는 앱 내의 위치로 바로 이동을 시켜주게 됩니다. 그런데 이때 iOS15에서 제공하는 비공개 딜레이 기능은 수많은 iCloud+ 유저의 디퍼드 딥링크 경험에 영향을 주게 됩니다.

디퍼드 딥링크는 IP 주소에 의존 하는 경우가 많기 때문에 이 비공개 릴레이를 사용하는 iCloud+ 유저 고객또한 영향을 받게 되는데, 그 이유는 이 비공개 릴레이는 사파리를 사용하는 iCloud+ 고객의 IP를 차단하고 있기 때문!입니다.

IP주소가 없으면 디퍼드 딥링크는 원활하게 작동하지 않고, 유저는 링크가 연결되지 않는 불편을 겪게 됩니다.
이때 이를 극복하기 위해 출시된 것이 바로 네이티브 링크이고 이는 IP 주소 없이 원활한 디퍼드 딥링크를 보장합니다.

기존의 과정

비공개 릴레이의 영향

이러한 네이티브 링크는 기존 디퍼드 딥링크에서 IP주소를 사용할 필요가 없는 온디바이스 솔루션을 통해 비공개 릴레이도 단절된 사용자 경험을 다시 이어줍니다. 개인 식별이 가능한 고유 정보가 필요하지 않기 때문에 네이티브 링크를 사용하면 개인정보가 추적될 위험이 없으며 이 네이티브 링크는 이미 휴대폰에 기본 내장된 복사 붙여넣기 기능을 활용해 작동되어집니다.

네이티브 링크의 동작과정은 아래와 같다.

  1. 유저가 딥링크를 클릭
  2. 새로운 네이티브 링크 환경으로 연결 > 파란색 클릭 버튼이 표시 됨
  3. 이 버튼을 클릭하게 되면 현재 url 위치가 클립보드로 복사됨
  4. 유저가 앱스토어로 이동하기 전 ‘콘텐츠가 복사되었습니다.’라는 알림을 보게 됨
  5. 표준 디퍼드딥링크와 마찬가지로 유저가 앱스토어로 연결되어 앱을 다운로드 할수 있게 됨
  6. 앱 설치 후 네이티브링크가 클립보드에 url이 있는지 확인하고 있는 경우 url을 붙여넣기 함
  7. 유저에게 ‘사파리로부터 붙여넣음’ 알림이 잠시 나타나고 유저는 원래 클릭했던 앱 내 위치로 바로 연결됨

사용방법은 간단합니다.

  1. BranchSDKfmf 1.39.4 버전 이상으로 업데이트
  2. 브랜치 대시보드에서 네이티브 링크 토글 스위치를 ON으로 변경
  3. iOS 타겟 옵션을 선택

이 유니버설 링크는 iOS9 이후부터의 표준 딥링크 형식으로 이 딥링크(특정 페이지에 도달할 수 있는 링크)에도 변천과정이 있습니다.

  1. 다이렉트 딥링크
  2. 디퍼드 딥링크
  3. 원링크

1. 다이렉트 딥링크

초창기 딥링크 형태의 모습으로 앱이 설치된 유저의 경우 특정 페이지로 랜딩이 되는것은 가능했지만, 앱이 설치되지 않은 유저의 경우 각 플랫폼의 앱스토어로 이동되며 설치 후 앱을 열었을 때 딥링크는 유실되었습니다. 이러한 앱 미설치 유저에게의 링크 유실이라는 단점을 보완하고자 디퍼드 딥링크 개념이 등장했습니다.

2. 디퍼드 딥링크

다이렉트 딥링크와 마찬가지로 앱 미설치자는 각 플랫폼의 앱스토어로 이동되지만, 설치 후 앱을 열엇을 때 링크가 유실되지 앟고 특정 컨텐츠로 이동됩니다.

그러나 디퍼드 딥링크는 각각의 플랫폼별에서만 작동한다는 한계가 존재했습니다. AOS 딥링크는 AOS에서만, iOS 딥링크는 iOS에서만 작동하기 때문에 트래킹 링크를 발급받으려면 2번의 생성작업을 거쳐야 했고 따라서 이로인해 광고를 집행할 때에도 목적이 동일한 하나의 캠페인을 AOS캠페인, iOS캠페인 이렇게 나누어져야만 했습니다. 따라서 이 문제를 해결하기 위해 원링크 개념이 등장했습니다.

3. 원링크

하나의 링크에서 각각의 플랫폼으로 자동 분기처리해주는 원링크

Related Posts