Library, Framework 그리고 XCFramework
1. Software 에서의 Library 란 무엇일까?
전통적인 software library 의 의미는, data 와 code 의 묶음을 만들어서 다른 곳에서 재사용하기 위한 형태로 만드는 package 를 일컫는 용어이다.
일반적으로는 code 와 data 만 포함된다고 생각할 수 있는데, 좀 더 넓은 범위에서는 image, document, sound file 등 다양한 것들을 포함하여 library 로 만들 수 있다.
2. 그렇다면 Xcode 에서 사용하는 Framework 은 또 무엇일까?
우리가 iOS 앱을 개발할 때 자주 사용하는 framework 라는 것은, Apple이 Xcode 에서 사용하기 위해 만든 library package 방식을 말한다. (결국은 framework 이라는 것도 library의 형태 중 하나라는 것)
아래 내용은 Apple 문서에 나와있는 framework 의 내부구조인데, 문서가 업데이트 된 지 한참 지났기 때문인지 실제 framework 을 만들어보면 구조가 많이 다르다.
실제로 framework 을 하나 만들고 build 진행해서 결과물 구조를 보면 아래와 같이 나타난다.
3. Dynamic vs Static Library
Xcode에서 framework을 새로 만들려고 하면 dynamic library 혹은 static library 중 하나의 형태를 선택해야 하는데, 그 차이를 한 번 알아보자.
3.1 Static Library
static library 는 build 하는 과정에서 실제 해당 framework 을 import 하는 사용부의 일부분으로 framework code 들이 복사되고 함께 build 되는 방식을 말한다.
framework 을 static library 형태로 만들면 다음과 같은 장단점이 생긴다.
- 장점 : 실제 사용부의 code 와 함께 inline 형태로 build 되는 방식이기 때문에 실행 속도가 빠르다.
- 단점 : 여러 개의 module 에서 동일한 static library 를 import 할 경우 그 횟수만큼 application 의 file size 가 증가한다.
3.2 Dynamic Library
dynamic library 의 경우 import 사용하는 사용부와 함께 build 되는 형태가 아니라 별도로 framework 을 build 한 이후에, 앱이 실행되는 runtime 에 framewrok 을 load 하는 방식이다.
- 장점 : 여러 곳에서 동일한 dynamic library 를 사용할 경우 reference 를 가지고 동일한 dynamic library 를 runtime 에 load 하므로, application 의 file size 가 증가하지 않고 dynamic library 한벌만 존재하는 형태로 사용 가능하다.
- 단점 : 동적으로 load 하기 때문에 static library 에 비해 실행속도가 느리다.
그래서 우리는 무엇을 사용해야 하는가?
일반적으로는 framework 을 생성하면 default 설정이 dynamic library 로 설정될 것이다. static library 에 비해서 느린 것이지 일반적인 사용상에 있어서는 크게 느껴질 정도가 아니기 때문에 dynamic library 를 기본적으로 사용해도 큰 문제는 없다.
다만 앱의 launch time 속도를 개선한다던가, 특정 기능의 동작 속도를 조금이라도 더 빠르게 만들고 싶을 때 static library 사용을 고려하면 좋다.
4. Embed or Not-Embed
framewrok 을 project 에 추가할 때, framework 파일구조를 최종 application 결과물에 포함시킬지 말지에 대해서 선택이 가능하다.
embed 를 선택할 경우에는 최종 application 이 packaging 될 때, 위에서 보았던 framework 의 폴더구조가 그대로 복사된 형태로 application 이 생성된다.
Do Not Embed 를 선택한 경우에는 framrework 폴더가 application 결과물에 포함되지 않는다.
하지만 ^^;;;;;
Mach-O Type 값이 dynamic library 인 경우 ‘do not embed’를 선택하면 crash 가 발생한다. 위에서 설명한 것과 같이 dynamic library 는 동적으로 runtime loading 되는 형태이기 때문에 반드시 ‘embed’된 형태로 사용해야 한다.
그에 비해서 static library 의 경우는 build 할 때 이미 code 가 복사되는 형태이므로 ‘do not embed’ 를 선택해도 문제가 없다.
하지만 static library 내부에 포함된 image 등의 resource bundle 을 사용해야 하는 경우는 ‘embed’ 방식으로 선택해야만 하는데, 이럴 경우 code 복사본이 하나 더 생긴다는 것을 고려해야 한다. (build-time 에 import 하여 사용하는 곳에서 한 번 복사되고, application package 내에 framework 형태로 또 존재하는 형태)
5. XCFramework 은 무엇일까?
XCFramework 은 위에서 이야기한 Framework 들을 모아서 하나의 묶음으로 만들 수 있는 Container Frmaework 이라고 할 수 있다.
WWDC 2019 에 소개된 Binary Frameworks in Swift 영상을 보면 자세한 내용을 확인해 볼 수 있다.
여러개의 framework 을 가지고 XCFrmaework 을 한 번 만들어보자.
일단 framework 을 생성하기 위한 project 에서 simulator, iphone 두 가지 architecture 로 archiving 해보자.
동일 project 내에서 위의 두 커맨드를 실행시키면 아래 화면과 같이 두 개의 xcarchive 파일이 생성될 것이다.
이번에는 위의 두 개 framework 을 하나로 묶어 xcframework 을 생성해보자.
위의 command 를 실행시키면, 이미 생성된 framework 두 개를 묶어 하나의 xcframework 파일을 만들어준다.
이렇게 여러 개의 architecture 용 framework 들을 묶어 하나의 xcframework 을 만들어주면, 빌드상황에 맞는 framework 을 별도로 설정해 줄 필요없이 하나의 xcframework 만 가지고 사용할 수 있기 때문에 매우 편리하다.
오늘은 library, framework, xcframework 이라는 주제에 대해 이야기해 보았다.
iOS 엔지니어라 할지라도 본인의 담당 업무에 따라 framework 을 다룰 기회가 많은 분들도 있고, 그렇지 않은 분들도 있을 것이다.
하지만 framework 의 구조에 대해 이해한 상태로 개발을 하는 것과, 모르는 상태로 개발을 하는 것은 실제 여러가지 상황에 대한 대처능력 면에서 아주 큰 차이가 있다고 생각한다.
워낙 방대한 주제라서 이 글에서 모든 내용을 다루지도 못하거니와, 본인이 모든 주제에 대해서 깊이 있게 이해하지는 못하겠지만, 적어도 큰 맥락에 대해 설명할 수 있는 글이 되도록 노력했다.
여기까지 읽어주셔서 감사하고,
모든 iOS 개발자에게 행복 있기를~
