[iOS] App Thinning 앱 씨닝과 Slicing, On-Demand Resource, Bitcode

 

 

에셋 카탈로그에 등록하는 1X, 2X, 3X 이미지 크기에 대해 정리하며

앱 씨닝에 대한 글도 곧 쓰겠다고 한지 어언 3주가 되어 가는ㅎㅎ

 

 

((1x, 2x, 3x에 대해서도 궁금하다면 이 글을 보고오기로 해욤))

[iOS] image asset의 크기 1x ,2x, 3x 사용하는 이유 | scale factor, 해상도(Resolution), pixel, point

 

 

귀찮은 거 아니고 bitcode란 아이를 이해하느라 쫌 늦었습니다.. 

(( 근데 이제 공부를 다 하고 나서 Xcode14부터는 애플에서 bitcode에 대한 지원을 하지 않기로 했다고 한 것을 봐버렸는데요

조금은 허무한 결과를 맞이했지만 그래도 좋은 공부였따.. ))

 

 

여튼 오늘은 App Thinning에 대해 이야기를 해볼 거고 

어떤 어떤 기술들이 이  App Thinning을 구성하고 있는지 살펴볼게요

 

 

 

 

 

 

📍 App Thinning

 

일단 앱 씨닝이라는 것은 뭘까?

 

thinning이라는 단어에서 유추해 보면

뭔가 최적화해서 용량, 크기를 작게/얇게 만드는 것 같지 않나요?

맞습니다.

 

 

 

App thinning이라는 것은

앱스토어와 운영체제가 다양한 디바이스의 특성에 맞게 앱을 설치할 수 있게 하는 설치 최적화 기술입니다!

이렇게 기기별로 필요한 것만 추려서(?)ㅎㅎ 앱을 설치하게 되면

최소한의 디스크 사용하면서 다운로드 속도도 향상 시킬 수 있겠네요?!

 

 

 

근데 이걸 누가 하고 어떤 기술들로 앱씨닝이 가능한 것이냐!

를 차차 설명해 보도록 하겠습니다

 

 

 

 

 

 

 

 

 

App Thinning을 가능하게 하는 기술들로는

Slicing, On-Demand Resource, Bitcode(XCode14 이전)가 있는데 

Slicing, On-Demand Resource는 wwdc15의 세션에서 발표한 자료를 중심으로 설명해 볼게요~

 

https://developer.apple.com/videos/play/wwdc2015/404/

App Thinning in Xcode - WWDC15 - Videos - Apple Developer

 

 

 

 

 

 

 

 

 

📍 Slicing 슬라이싱

 

저희가 앱을 하나 만들면서 Xcode에 정말 많은 정보들을 넣죠.

그리고 만들어진 앱을 컴파일해보았을 때 이렇게 많은 정보가 들어간 앱이 탄생합니다.

 

 

 

 

 

아래 그림에서도 볼 수 있듯이

 

 

 

에셋 카탈로그에 있는 1x, 2x, 3x 크기의 리소드 들도 들어가 있고

그걸 또 iPhone idiom, iPad idiom로 구분하여 기기별로 차별화시키기도 합니다.

+

게임이나 다른 3D 그래픽 기반 앱을 사용하는 경우에는

OpenGL ES, Metal 로 그래픽 기술별 차별화를 시키기도 하고,

리소스의 메모리와 그래픽 capability에 따라 High/Low Quality로 차별화가 되기도 하네욤

+

오디오 리소스도 bit rate 측면에서 차별화되어 존재하게 됩니다!

+

그 외에도 정말 여러 가지 데이터/리소스들이 하나의 앱에 들어가겠죠?

 

 

 

 

 

 

이렇게 개발자는 필요한 리소스 담아서 준비는 다 해놨다고 했을 때..!

사용자가 해당 앱을 다운로드할 때도 이 리소스를 다 받아야 하는 걸까?

생각만 해도 그러기엔 앱이 너무 커지겠죠?

 

그렇다면! 사용자 디바이스에서 필요한 것만 넣어서 앱을 다운로드하게 할 수 있을 까?라고 했을 때 

YES! 이 과정이 바로 App Slicing입니다!

 

 

기술적인 단어로 풀어서 설명하면

"서로 다른 디바이스를 위한 다양한 앱 번들 (app variant)를 만들어 전달하는 과정"이고

쉽게 설명하면

"사용자 기기별로 알맞은 리소스들만 간추린 앱 버전(?)을 만드는 과정" 이라고 할 수 있겠네요 ㅎㅎ

 

 

 

 

 

 

사진에서 볼 수 있듯이 iPhone 6 Plus 디바이스의 경우에는

밑의 사진처럼 필요한 것들만 숑숑 뽑아서 App Variant를 만들어내고

 

 

 

 

 

 

iPad mini의 경우에는 이런 식으로 필요한 리소스만 뽑아 

App Variant를 만들어낸다고 합니다.

 

 

wwdc15의 자료이다 보니 예전 기기의 예시밖에 없네요 ㅎㅎ

 

 

 

 

 

 

 

그럼 누가 App Slicing이라는 걸 하는데?

 

[iOS] image asset의 크기 1x ,2x, 3x 사용하는 이유

여기서 잠깐 언급했던 것처럼 앱스토어가 이 일을 하는데요.

 

개발자가 이것저것 데이터/리소스들이 모여있는 범용앱(universal app)하나를 업로드하면

앱스토어가 디바이스의 특성을 보고 , 위 그림처럼 필요한 것만 조합해서 별도의 IPA 를 만드는 것입니다!

 

**IPA?

- 간단하게 말하면 iOS 및 iPadOS 앱의 아카이브 파일!

- IPA파일에는 앱의 압축데이터가 포함되어 있음(앱의 메인 패키지 파일(".ipa")파일 )

- 사용자가 앱을 다운로드 받을 때 장치에 다운로드 되는 파일

- iOS 앱은 파일 확장자가 IPA인 문서와도 같다

(iPad, iPhone과 같은 iOS,iPadOS같은 운영장치에서만 다운로드할 수 있는 것)

 

 

 

 

 

 

 

---

Can we do better?

 

wwdc 세션에서는 여기서 그치지 않고 앱을 더 최적화할 수 있는 방법에 대해 이야기합니다!

 

 

 

왜냐하면 우리 앱에서는

항상 필요한 리소스,

+ 아마도 나중에 필요할 것 같은 리소스,

+ 초기 한두 번만 보여주면 그 이후에는 필요할 일이 없는 리소스

등이 있기 때문에 이것들을 앱 내에서 모두 가지고 있으면 너무 비효율적이고 앱자체가 무거워지기 때문입니다.

 

 

 

 

 

저도 처음에는 지금 굳이 가지고 있을 필요 없거나 앱 사용 초반에만 필요한 리소스들이 뭔지 감이 안 왔는데

예시들을 보니 감이 좀 오더라구요.

 

항상 필요한 것은 우리가 앱을 사용하면서 기본적으로 필요한 에셋이나 인터페이스 실행 코드 등이 있을 것이고,

+

만약 사용자 레벨이 있는 앱이라고 가정했을 때 현재 레벨 상태에서 필요한 리소스들만 가지고 있으면 되고 나보다 높은 레벨에서 필요한 리소스들은 굳이 지금 가지고 있을 필요가 없을 것이고,

+

그리고 앱 사용 방법을 보여주기 위해 초기에만 띄워주는 앱 튜토리얼 화면은 보여준 이후 계속 리소스를 가지고 있지 않아도 되겠죠?

 

 

 

 

 

 

이렇게 사용자가 앱을 사용하는 시기, 권한 별로 필요한 리소스들이 다르기 때문에

이것들을 앱이 다 가지고 있는 게 아니라 필요할 때 요청해서 보여줄 수 있도록 하는 것이

바로 주문형 리소스 (on-demand resource)라는 것입니다!

 

 

 

---

 

 

 

 

 

 

 

📍on-demand resource 주문형 리소스

 

이어서 설명해 보면

말 그대로 요청을 했을 때, 주문을 했을 때 비로소 내어주는 리소스인데요

 

ODR 은 앱스토어에서 IPA와 별도로 저장된다고 합니다?!

 

 

 

여기서 알 수 있듯이 주문형 리소스 ODR에 관한 것도 앱스토어가 관리해주고 있네요.

생각보다 많은 일을 하고 있잖아? 앱스토어?

 

즉, on-demand resource는 우리의 앱 번들에 저장되는 게 아니고

앱스토어의 시스템에서 관리하는 메모리에 저장되고, 이 메모리는 다양한 App에서 발생하는 ODR를 캐시 하는 역할을 한다.

 

 

 

위에서 알아본 슬라이싱 방법으로 앱이 thinned down 되었으면,

모든 asset의 타입이 위 그림처럼 하나의 variant들로만 이루어져 있을 것이다.

 

 

그다음 단계로서 우리는

이 그림처럼 단계별로  필요한 리소스들을 나눌 수 있다.

shared는 단계에 상관없이 항상 필요한 것들일 것이고, 나머지는 단계별로 요구되는 시기가 따로 있는 리소스 들일 것이다!

 

왼쪽은 사용자의 디바이스가 가지고 있고

오른쪽은 앱스토어에서 보유하고 있는데

 

이렇게 나누었을 때

실제로 앱의 기본 공간을 축소하면서도 콘텐츠에는 계속 액세스 할 수 있는 것이다.

 

필요할 때 단계별로 다운로드 받을 수 있게 해주는 것입니다

 

 

그리고 제가 잘 이해한 건지 모르겠지만 레벨4에 필요한 리소스들을 받아왔다고 했을 때

레벨 1을 제거하는 것도 가능하다고 합니다?!

 

 

 

 

 

 

 

 

 

WWDCD에서 요약한 ODR에 대해서 보면

 

 

Xcode에서 자산에 태그를 지정하여 자산 팩을 빌드할 수 있고

이때에는 당장 실행하지 않는 에셋이라고 해도 다 담아놓을 수 있습니다.

ODR은 앱스토어에 의해 관리되고

우리의 코드에 기반하여 필요할 때만 다운로드됩니다.

필요에 따라 필요 없어진 리소스들은 회수하기도 합니다

 

즉, 필요할 때 요청을 할 수도 있지만 

필요 없는 시점에 회수할 수도 있는 시스템이네요!

 

 

이렇게  한 번에 22MB를 가지고 있는 것보다

 

지금 필요한 14MB를 가지고 있다가

필요할 때 8MB를 요청해서 받는 것이 훨씬 효율적이겠죠?

 

특히 미디어가 많은 대규모 응용 프로그램의 경우 비용 절감 효과가 더 크겠네요!

 

 

 

 

 

 

 

 

애플은 ODR이 이러한 이점이 있다고 설명하는데

결국은 앱이 최적화되어 용량이 더 작고, 다운로드가 빠른 앱이 될 수 있고 사용자 경험을 좋게 할 수 있다는 게 핵심입니다! 

 

 

 

 

 

 

 

xcode에서 odr 설정 방법은 이렇습니다

 

 

 

 

각각 필요한 시기별로 리소스를 태그하는 방법은 실제로 사용할 프로젝트가 생겼을 때

적용해 보면서 기회가 되면 정리해 볼게요!

 

 

 

 

 

 

 

 

 

 

 

📍Bitcode 비트코드

그리고 대망의..

이해하는데 어려웠지만 지금은 지원하지 않는다는 Bitcode..

 

그래도 공부했고 내 시야는 한 층 넓어졌으니

공부한 걸 기반으로 정리해 보자면

 

 

 

 

앱을 최적화하기 위해 필요한 중간 단계의 코드 bitcode

비트코드는

고수준의 코드 (내가 이해할 수 있는 코드 ) 수준도 아니고

기계가 이해하는 코드 수준도 아닌

=> 중간 단계의 코드라고 하는데요!

 

 

bitcode를 사용하면 앱이 다운로드되기 전에 디바이스에 맞게 앱을 최적화 하여 제공할 수 있다고 합니다

 

그럼 여기서 말하는 최적화란?

최신 컴파일러 용으로 자동으로 앱을 컴파일하고 특정 아키텍쳐( 64비트 프로세서 등 )에 맞게 최적화하는 것을 뜻합니다.

근데 이런 최적화를 하려면 앱스토어에 앱을 “중간 표현(intermediate representation)”으로 아카이브 해야 하는데

→ 그 중간 표현이 바로 bitcode!인 것!

 

즉, bitcode를 사용하면(활성화시키면) 앱스토어에 최종 컴파일 결과가 아닌  intermediate representation을 올리게 되어

특정 아키텍처에 맞게 최적화가 가능한 것이라고 합니다 :)

 

 

 

 

 

 

 

 

fat binary와 최적화된 binary

fat binary라는 것을 들어보셨나요?

디바이스에 맞는 아키택쳐 아닌 것까지 다 포함한 바이너리가 바로 fat binary입니다.

 

bitcode라는 것을 지원하기 전까지는 앱이 실행될 수 있는 모든 환경, 예를 들어 32bit, 64bit, arm6, arm7, arm7s, arm64 등에 대한 바이너리를 생성하여 하나로 합친 바이너리를 올렸다고 합니다

이것이 바로 fat binary인데

 

이름만 들어도 다운로드 용량 클 것 같고 그렇죠?

그리고 심지어 새로운 환경이 지원된다고 했을 때 코드를 다시 컴파일해서 올려야 하는 것..

 

 fat binary를 제공하게 되면 다운로드 용량도 넘 커지고 너무 비효율적이기 때문에

다운로드하는 디바이스에 필요한 것만으로 최적화한 바이너리를 만들 수 있는 중간 표현인 bitcode가 필요한 것!

 

 

 

 

 

 

 

 

 

bitcode의 장점

 

bitcode는 앱을 최적화할 수 있게 하여 다운로드 용량을 줄이기도 하지만

 

 

애플에서 새로운 CPU, 아키텍처에 대한 지원을 추가했을 때

개발자들이 따로 코드 수정 없이 중간 단계 코드(bitcode)를 이미 올려놓았으므로 그 코드에 맞게 다시 컴파일을 할 수 있는 장점도 있습니다.

 

 

이게 가능한 것은

LLVM이라는 라이브러리가 우리가 작성한 코드를 intermediate(중간코드)혹은 machine(기계코드)로 컴파일해주기 때문입니다.

bitcode는 LLVM를 통해 애플이 추가한 지원에 따라 기계가 이해할 수 있는 코드로 다시 컴파일될 수 있는 것!

 

 

 

 

 

 

 

 

 

그럼 이 최적화를 또 누가 하는데?

 

라고 물어본다면, 이 역시 앱스토어!

 

앱스토어에 fat binary를 올리지 않고 bitcode만 업로드하면

앱스토어는 각 디바이스 환경에 맞는 바이너리를 생성하여 사용자가 최적화된 앱을 다운받을 수 있도록 하는 것

 

생각보다 아주 많은 일을 하는 앱스토어..

나는 그저 앱을 다운로드 받는 플랫폼이라고만 생각했던 앱스토어...

장하네

 

 

 

 

 

 

🚨 bitcode 지원 중단??! XCode 15.3에서 enable bitcode 옵션 찾을 수 없는 이유

 

 

와아우 이렇게 어찌저찌 bitcode에 대해 이해를 하고 정리를 해봤는데..

build settings에서 enable bitcode설정에 대한 태그를 찾을 수가 없는 것임..

왜 그런가 하고 찾아봤더니

 

 

Xcode 14부터 Apple은 Bitcode 지원을 중단하기로 결정했기 때문에, Xcode 15.3에서는 Bitcode를 설정하는 옵션이 더 이상 제공되지 않는 것이라고 함.. Apple은 최근 몇 년 동안 이를 더 이상 필요로 하지 않다고 판단하고 이 지원을 중단했다고 한다,,;;

 

나의 xcode 버전인 15.3에서는 찾을 수 없는 게 정상인 것 ㅇㅇ

지금은 bitcode 설정 없이도 정상적으로 앱을 빌드하고 배포할 수 있으므로 신경 쓰지 말고 프로젝트 진행하면 된다고 한다.

 

 

 

 

 

 

왠지 앞으로 몇 년간을 새로운 CPU나 아키텍처가 추가 지원되는 것은 어렵다고 판단해서일까?라고 추측했다가 챗 gpt에게 물어보니

애플의 공식적인 설명은 없었지만 아래와 같은 것들이 이유가 될 수 있다고 한다.

 

bitcode가 아니어도 컴파일러 기술과 최적화 도구들이 충분히 발전했고, 빌드 프로세스에서 최적화 및 크기 줄이기를 효과적으로 처리할 수 있게 되었다고 한다. 그리고 어쨌든 개발 과정에서 설정해주어야 하는 옵션이었으므로 apple이 bitcode를 유지보수 하는 비용에 비해 이것을 실질적으로 활용하는 개발자들이 적었을 수도 있는 것!

 

 

 

 

 

 

bitcode가 deprecate된 것은 xcode14 release notes에서 찾아볼 수 있다.

 

https://developer.apple.com/documentation/xcode-release-notes/xcode-14-release-notes

Xcode 14 Release Notes | Apple Developer Documentation

 

 

Deprecations 섹션에 보면

watchOS, tvOS, iOS에서 모두 더 이상 bitcode가 요구되지도 않고, 더 이상 bitcode의 제출도 받지 않는다고 한다

 

 

 

Xcode 14 및 그 이후 버전에서 Bitcode를 중단한 결정은 앱 개발 워크플로우를 단순화하고 컴파일 및 앱 제출 과정과 관련된 잠재적인 복잡성을 줄이기 위한 것임을 시사한다.  그리고 Apple은 컴파일러 기술과 기타 최적화 기법의 발전으로 인해 Bitcode가 이전만큼 중요하지 않다고 판단한 것으로 보입니다.

 

 

 

 

사실 어쨌든 추가 설정 같은 거 없이 더 효율적으로 돌아가게 하는 것이 좋은 기술이니

bitcode라는 기술을 공부했다는 것에 의의를 두어야겠다!

 

 

 

 

 

 

 

---

 

 

 

 

 

이렇게 앱씨닝에 대해서 정리해보았는데

 

우리가 올리는 범용앱(universal app)에 대해

앱스토어가 이렇게 야무지게 최적화를 해주는지 처음 알았고

 

이러한 설치 최적화 기술 덕분에

우리는 아이폰의 용량을 아끼며, 앱을 빠르게 다운로드 받을 수 있는것이었습니다.!!

 

공부할수록 재밌는 iOS의 세계ㅎㅎ