라이브러리 준비
라이브러리를 직접 만들고, SPM을 직접 배포해 봅시다.
라이브러리는 모든 프로젝트에서 사용되는 Log 기능으로 만들어볼건데요.
이에 몇 가지 주의점이 있습니다.
혹시 라이브러리 클래스에 고유한 단어를 붙이는 이유가 뭔지 아시나요?
예를 들면, Kingfisher는 "kf"라는 글자처럼요.
이런 글자를 붙이는 이유는 라이브러리 사용자가 사용하는 이름과 중복되는 것을 피하기 위해서 입니다.
같은 이름의 클래스가 있으면 안 된다는 것은 대부분 아실거에요.
그 규칙이 라이브러리의 클래스에도 적용되기 때문에 kf같은 특수한 단어를 붙이는 겁니다.
(클래스 뿐만 아니라 이름이 겹치면 안 되는 모든 것에 적용되는 얘기입니다.)
따라서 이번 Logger 라이브러리 이름을 JeongLogger로 만들고,
클래스도 JeongLogger로 네이밍해서 만들겠습니다.
참고로 라이브러리 코드는 https://github.com/jeongju9216/JeongLogger 에서 확인하실 수 있습니다.
라이브러리 프로젝트 만들기
Xcode에서 Package 프로젝트를 생성합니다.
File - Package를 선택하고 라이브러리 이름을 입력합니다.
프로젝트를 연 Xcode 전체 모습입니다.
Sources에 소스 코드를 작성하면 되고, Tests에서는 코드 테스트가 가능합니다. (너무 당연한 얘기)
위 사진에서 보이는 Package에는 라이브러리 지원 버전, 종속성 등을 추가할 수 있습니다.
이번 JeongLogger는 iOS 13 이상부터 사용 가능하도록 만들건데요.
platforms를 추가하여 지원할 플랫폼을 작성하면 됩니다.
자동 완성으로 작성 가능한 플랫폼 리스트도 보여줍니다.
만약 라이브러리에 의존성이 있다면(예를 들면, Moya의 Alamofire)
dependecies에 추가하면 됩니다.
친절하게도 Xcode에서 주석으로 가이드를 제공하니 잘 읽어보시고 작성하시면 어렵지 않습니다.
또 한 가지 주의할 점은 위 프로젝트 구조를 변경하면 안 됩니다.
마음대로 Sources 파일 밖에 파일을 생성한다거나, Package 파일을 다른 디렉토리에 넣는 등의 작업은 하면 안 됩니다.
SPM을 지원하는 라이브러리의 프로젝트 구조가 모두 동일한건 그만한 이유가 있어서 입니다..!
소스 코드 작성
소스 코드는 Sources에 작성하면 됩니다.
감사하게도 여기도 기본으로 무언가 적혀있지만, 가차없이 날려줘도 됩니다.
가볍게 로그를 남기는 코드를 작성해주었습니다.
미리 말씀드리면 위 코드는 제대로 동작하지 않습니다.
어떻게 동작하지 않는지와 수정 코드는 아래에서 접근제어자에 대한 설명과 함께 다루겠습니다.
(대충 메서드에 public 접근제어자를 안 붙였다는 내용 ㅎ;)
SPM 배포
SPM 배포를 위해서는 깃허브에 레파지토리를 생성하고 소스코드를 올려야 합니다.
private 레파지토리로 생성하면 자신만 사용할 수 있고, 사용하는 기기에 github 계정 인증을 해야 합니다.
public 레파지토리로 생성하면 제한 없이 사용 가능합니다.
깃허브에 업로드 하는건 특별한건 없습니다.
이렇게 업로드를 완료하면 SPM 배포가 완료되었습니다.
Swift Pacakge 추가
라이브러리를 사용할 프로젝트에서 JeongLogger를 사용해 봅시다.
Package Dependencies 탭에서 Swift Package를 추가할 수 있습니다.
저기서 + 버튼을 누르면 Swift Package 검색 창이 나오는데요.
우측 상단 검색창에 깃허브 주소를 넣으면 JeongLogger가 나옵니다.
Dependency Rule은 Branch와 버전 중에 선택할 수 있습니다.
위 사진처럼 설정하고 추가하면 main 브랜치 내용을 사용하겠다는 의미이고,
저는 main을 deleveop으로 바꿔서 develop 브랜치의 내용을 사용하겠습니다.
약간의 로딩 후 Package 추가가 완료됩니다.
("약간의 로딩"에는 몇 가지 과정이 포함되는데 읽어보시고 스무스하게 넘어가시면 됩니다.)
정말 간단하죠?
서드파티인 CocoaPod과는 달리 SPM은 퍼스트파티라서 이렇게 간단하게 추가가 가능합니다.
라이브러리 코드 수정, 재배포, 업데이트
라이브러리 코드를 수정하고 재배포, 업데이트 하는 과정을 알아봅시다.
위에서 말씀드렸듯이 지금 JeongLogger는 제대로 동작하지 않습니다.
JeongLogger 클래스는 open 접근제어자로 외부 모듈에서 접근할 수 있게 설정했지만,
그 안의 메서드들은 그대로 internal 이기 때문에 외부 모듈에서 접근하지 못해요.
그래서 이렇게 public 접근제어자를 추가해주었습니다.
(open은 외부 모듈에서 서브 클래싱이 가능, public은 접근만 가능합니다.)
라이브러리를 수정했으면 깃허브에 push를 해주면 됩니다.
그럼 수정과 재배포가 완료되었어요.
이제 사용하는 쪽에서 업데이트를 해봅시다.
퍼스트파티인 SPM의 장점 중 하나가 업데이트가 편하다는거에요.
File - Packages - Update to Lastest Package Versions를 선택하면 업데이트가 완료됩니다.
SPM이 퍼스트파티이기 때문에 가능한... 아주 간편한 방법입니다.
그리고 다시 확인을 해보면!
메서드에 제대로 접근이 되는 것을 확인할 수 있습니다.
로그도 잘 찍히네요 ㅎㅎ
라이브러리 릴리즈
깃허브에서 라이브러리 릴리즈도 가능합니다.
v1.0.0 이렇게 버전으로 나눌 수 있어요.
라이브러리 레파지토리에 들어가면 오른쪽에 Release 탭이 있습니다.
아무것도 릴리즈를 안 했다면 Create a new release 버튼이 활성화 되있을 거에요.
그 버튼을 누르면 됩니다.
어떤 버전으로 릴리즈할지 태그를 등록하고,
네이밍, 설명까지 적은 뒤 Publish release를 누르면 릴리즈가 완료됩니다.
릴리즈된 라이브러리는 소스 코드도 다운로드할 수 있고,
레파지토리에서 최신 릴리즈 버전도 확인할 수 있답니다.
마무리
여기까지 SPM 라이브러리를 생성하고 배포까지 해보았습니다.
지금처럼 간단한 라이브러리도 좋은 경험이 되겠지만,
조금 더 복잡한... 라이브러리 사용자를 생각하면서 접근제어자까지 고민하다 보면
iOS 개발 시야가 확 트이는 경험을 할 수 있습니다. (제가 그랬음)
시간이 오래 걸리는 것도 아니니 (이번 포스팅 내용도 스샷 찍는거 포함 1시간도 안 걸렸어요)
여유가 되신다면 간단하게라도 해보시는 것을 추천드립니다!
감사합니다!
아직은 초보 개발자입니다.
더 효율적인 코드 훈수 환영합니다!
공감과 댓글 부탁드립니다.
