[iOS] 앱을 테스트&배포할 때 알게되었던 개념들 - 2

개요

그동안 회사를 다니면서 제 개인 프로젝트를 발표하기도 하고, 제가 맡은 기능을 넣은 내부 배포 버전, 라이브 배포 버전도 아카이빙을 해봤는데요.

앱을 테스트, 배포하는 과정에 필수적으로 알아야될 기초개념들이 많이 있어서 글로 정리해놓지 않으면 분명 까먹는다는걸 깨닫고 오늘 이 글로 정리해보고자 합니다.

 

큰 줄기로는

Apple Certification

Provisioning Profile

Code Signing

App Thinning

BitCode

on-demand resource

을 정리하는 글이라고 볼 수 있겠네요.

 

---

4. App Thinning (앱 시닝)

앱 시닝이란

앱이 디바이스에 설치될 때 앱 스토어와 운영체제가 그 디바이스의 특성에 맞게 설치하도록 하는 설치 최적화 기술

을 의미합니다.

 

이를 통해 앱의 설치용량을 최소화하고, 다운로드 속도를 향상시킬 수 있습니다.

앱 시닝의 기술 구성요소는 슬라이싱(Slicing), 비트코드(bitCode), 주문형 리소스(on-demand resource)가 있습니다.

 

5. 슬라이싱(Slicing)

슬라이싱 이란

앱이 지원하는 다양한 디바이스에 대한 여러 조각의 앱 번들(app bundle)을 생성하고 디바이스에 알맞은 조각을 전달하는 기술

을 의미합니다.

 

더 자세히 보자면....

우리가 만든 앱은 크게 실행 가능한 코드 / 리소스 들로 이루어져 있습니다.

코드도 여러가지 버전(32/64, armv...)이 있을 수 있고, 리소스(asset catalog, opengl...)도 여러가지로 나눌 수 있고, 오디오 데이터도 있을 것이며 여러 다른 데이터들도 포함되어 있을 것입니다. 

따라서 앱에 들어가는 것을 세분화하며 쪼개보면....

대략 이렇게 나타낼 수 있습니다.

그렇다면 이 전체 버전의 App을, 각각 디바이스에 맞는 것만 다운로드 하게 되면 어떤 모습일까요?

이렇게 됩니다.

 

따라서....

1. 개발자가 앱의 전체 버전을 App Store Connect에 업로드 하게 되면,

2. 앱 스토어는 각 디바이스 특성에 맞는 다양한 버전의 조각들(= 별도의 .ipa 파일)을 생성합니다.

3. 사용자가 앱을 설치할 때는 전체 버전이 아닌 슬라이싱(slicing)된 조각들 중 사용자의 디바이스에 가장 적합한 조각이 설치됩니다. 애셋 카탈로그에서 관리하는 이미지들은 자동으로 적용됩니다.

 

이 앱 슬라이싱은 앱 스토어에서 알아서 해줍니다.

 

6. on-demand resource(주문형 리소스)

쉽게 말해 유저가 요청할 때만 앱스토어에서 더 많은 리소스를 가져올 수 있는 개념입니다.

주문형 리소스는 앱스토어에 IPA 파일과 별도로 저장됩니다. 

기기의 앱 번들에 저장되지 않으며, 시스탬에서 관리되는 메모리에 저장되기 때문에 여러 앱에서 ODR을 캐싱할 수 있습니다.

 

그림으로 보자면...

xCode에서 올린 전체 버전의 App에는 이런 리소스들이 올라갑니다.

 

여기서 Level1만 유저가 받고, 나머지 Level의 리소스들은 유저의 요청이 있을 때만 다운된다는 개념입니다.

 

7. BitCode(비트코드)

비트코드는 잘 이해가 되지 않아서 zeddios.tistory.com/655 에 있는 글을 참고해서 써봅니다.

 

비트코드란

기계언어로 번역되기 이전 단계의 중간단계의 코드(Intermediate Representation)을 말합니다.

 

뭔말일까요?

애플은 디바이스에 맞게 앱을 최적화 하여 재컴파일해 바이너리를 새로 만들어 제공합니다.

비트코드를 사용하면, 최신 컴파일러용으로 자동으로 앱을 컴파일하고, 특정 아키텍처에 맞게 최적화합니다.

 

비트코드는 다른 아키텍처에 대한 최적화를 제거하여 다운로드는 더 적게 만들고, 관련 최적화만 다운로드 하여 위에 언급한 app thining 기술과 함께 사용됩니다.

 

따라서 앱스토어가 앱을 최적화하려면, 비트코드를 켜서 Archive하고 앱스토어에 올려야 합니다.

 

비트코드가 나오기 전에는,

해당 앱이 실행될 수 있는 모든 환경, 즉

이 모든것을 실행할 수 있는 모든 환경에 대해 바이너리를 생성하여 이를 하나로 합치고 앱스토어에 올렸다고 합니다.

(이를 fat binary라고 합니다)

 

근데 비트코드가 있다면

앱스토어 제출 시 fat binary를 만들지 않고, bitcode를 사용하여 업로드 합니다.

앱스토어는 bitcode를 받아, "다시" 컴파일하여 각 환경 별 바이너리(app binary)를 생성합니다.

그래서 사용자는 사용자의 환경에 딱 맞는 바이너리를 받을 수 있는 것 입니다.

 

---

비트코드를 사용해서 최적화를 할 수 있지만, 개발자에게는 약간 귀찮은 점이 하나 생깁니다.

 

바로 디버깅할 때 필요한 dSym 파일을 따로 받아야 한다는 건데요.

 

비트코드 때문에 애플은 앱을 "재컴파일"하여 유저에게 새로운 바이너리를 제공하기 때문에,

xCode에서 내가 올린 바이너리와 실제 사용자가 받는 바이너리가 다르게 됩니다.

 

따라서 개발자가 크래쉬에대한 정보를 보려면, App Store Connect에서 개발자가 올린 앱의 dysm파일을 따로 다운로드하여 크래쉬 분석 툴에 올려줘야합니다.

 

출처:

zeddios.tistory.com/655

ttuk-ttak.tistory.com/42