1. bitbucket에 두 개의 repository가 필요함.
- 실제 프레임워크로 사용할 코드 저장할 remote repo
- 1번에서 올린 cocoapod 프레임워크의 스펙을 관리할 remote repo
비트버킷에 두 개 다 private으로 만들고 git 주소 저장해두기.
2. Pod으로 라이브러리 만들기
- cmd 창에서 코코아팟 프레임워크를 만들 폴더로 이동.
pod lib create [프레임워크명]
입력 후 아래 코드 입력
* What platform do you want to use?사용할 플랫폼? -> iOS 선택* What language do you want to use??사용할 언어? -> Swift 선택* Would you like to include a demo application with your library?데모 프로젝트 끼워서 빌드할건지? -> 라이브러리 수정할 때마다 테스트가 가능하기 때문에 yes로 설정.yes로 설정해두고 따로 사용하지 않아도 괜찮음. * Which testing frameworks will you use?유닛 테스트용 프레임워크 쓸거냐고 묻는게 Quick 누르면 에러나서.. None으로 설정* Would you like to do view based testing?yes로 설정하면 뷰 테스트용 프레임워크가 설치됨. 그러나 굳이 안 해도 되는 설정이므로 No로 설정
- 위의 문답까지 완료하면 라이브러리용 프로젝트가 바로 열림. 바로 열리지 않는다면 finder에서 프로젝트가 생성된 위치로 가서 Example >
프레임워크명.xcworkspace
오픈. - 팟 수정할 준비 완료. 위에서 연 워크스페이스를 빌드하면 오류가 날 수 있는데 프레임워크가 아닌 데모 프로젝트에만 code signing 부분에서 서명을 해주거나 target iOS version을 통일해주면 해결됨. 버전은 Targets에 대해서도 다 통일해주어야 함.
주의점
- framework의 info.plist는 깃에 올라가더라도 컨슈머 측에서 프레임워크를 install할 때 반영되지 않음. 따라서 따로 info.plist의 정보를 사용할 일이 있다면 컨슈머 측의 info.plist에 key-value 값을 넣어주도록 가이드에 추가해야 함. 접근은 가능함. (다른 페이지에 기술)
만들어진 다른 파일
- 프로젝트 폴더 >
_Pods.xcodeproj
: 프레임워크 내 코드를 수정할 수 있는 프로젝트. cocoapod podspec meta data는 수정할 수 없음. - 프로젝트 폴더 > Example >
프레임워크명.xcodeproj
: 데모 프로젝트 코드와 cocoapod podspec meta data를 수정할 수 있음. - 프로젝트 폴더 > Example >
프레임워크명.xcworkspace
: 프레임워크 내 코드, 데모 프로젝트 코드, cocoapod podspec meta data 모두 수정 가능한 워크스페이스. - 프로젝트 폴더 > 프레임워크명 폴더 > Classes 폴더 : 프레임워크에 포함되어야 하는 코드가 이 폴더 내에 들어있음.
3. podspec 수정하기
위에서 워크스페이스 열고 hierarchy 창에서 프레임워크명 > Podspec Metadata > 프레임워크명.podspec 선택
주석을 다 제외하면 팟 스펙 파일이 아래와 같을 것임. podspec 언어는 Ruby로 작성되어 있으며 신경써줘야 할 부분은 아래와 같음.
s.name
: 프레임워크 이름s.version
: 프레임워크의 버전을 관리하는 부분. 버전이 올라갈 때마다 꼭 이 부분을 수정해주고 빌드해주어야 함.s.summary
: 요약s.description
: 설명s.source
: s.source의 :git => '주소'에 1번에서 만들었던 실제 프레임워크로 사용할 코드 저장할 remote repo의 주소를 넣어줌.s.ios.deployment_target
: 이 프레임워크의 타겟 iOS 버전을 작성- 나머지 요소는 굳이 당장 신경쓰지 않아도 될듯. 그리고
s.private
을 true로 설정하면 내부 코드가 closed source가 된다고 해서 수정해봤는데s.private
은 쓸 수 없는 키워드임...
Pod::Spec.new do |s| s.name = '프레임워크명' s.version = '버전 정보' s.summary = 'A short description of 프레임워크명.' s.description = <<-DESCTODO: Add long description of the pod here. DESC s.homepage = 'https://github.com/사용자' # s.screenshots = 'www.example.com/screenshots_1', 'www.example.com/screenshots_2' s.license = { :type => 'MIT', :file => 'LICENSE' } s.author = { '사용자명' => '사용자 이메일 주소' } s.source = { :git => '프레임워크 실제 코드가 있는 깃 주소', :tag => s.version.to_s } # s.social_media_url = 'https://twitter.com/<TWITTER_USERNAME>' s.ios.deployment_target = '10.0' # incorrect usage!!! # s.private = true s.source_files = '프레임워크명/Classes/**/*' # s.public_header_files = 'Pod/Classes/**/*.h' # s.frameworks = 'UIKit', 'MapKit' # s.dependency 'AFNetworking', '~> 2.3'end
4. 프레임워크 코드 수정
2번에서 연 워크스페이스에서 hierarchy 창에서 Pods > Development Pods > ReplaceMe.swift 파일의 파일명을 수정하고 코드를 수정해서 프레임워크 코드를 넣거나 ReplaceMe.swift 파일 우클릭 > New File > Swift File > 위치를 프레임워크명, Classes 폴더까지 이동한 후 Create을 눌러주어야 함.
프레임워크에서 사용할 코드를 수정했다면 테스트를 하는 부분은 hierarchy 창에서 프레임워크명 선택 > Example for 프레임워크명 폴더 > ViewController.swift 파일에서 수정해주고 빌드해주면 됨.
5. 프레임워크 깃에 올리기
- cmd 창에서 pod lib create 했던 폴더 위치로 이동 (프레임워크 프로젝트 있는 위치로 이동)
- git status : 변경사항 확인
- git add . : 모든 파일 깃 트래킹에 추가
- git commit -m “커밋 메세지” : 위에서 추가한 파일들 커밋
- git tag 버전명 : 위의 커밋한 것까지 태그 설정한다는 의미. 버전 컨트롤 용도 ex) git tag 0.1.0
- git remote add origin git주소 : 여기의 git주소는 1번에서 만들었던 실제 프레임워크로 사용할 코드 저장할 remote repo의 주소를 넣어줌.
- git push origin master 버전명 : 현재 master 브랜치도 push, 버전 태그도 push한다는 의미.
6. Pod Spec Repo 만들기
- cmd 창 열기
pod repo add [REPO_NAME] [깃 주소]
: REPO_NAME은 Spec repo로 사용할 이름 아무거나 지어주면 되고 깃 주소는 1번에서 만들었던 cocoapod 프레임워크의 스펙을 관리할 remote repo의 주소를 넣어줌.cd ~/.cocoapods/repos
cd [REPO_NAME]
: 2번에서 만든 폴더로 이동pod repo push [REPO_NAME] [.podspec 파일의 경로]
: REPO_NAME은 2번에서 넣어준 이름으로 사용하면 됨. .podspec 파일의 경로는 pod lib create로 만든 폴더로 이동한 후 프레임워크명.podspec 파일 우클릭 후 option 누르고 경로 이름을 복사 클릭. 그 후 cmd 창에서 붙여주면 됨. 이 명령어가 master branch를 감지해서 spec에 .podspec 파일의 s.version에 맞춰서 spec을 자동으로 저장해줄 것임.- 만약 현재 브랜치 이름이 master가 아니라면 브랜치명 변경이 필요함.
git branch -m 이전_브랜치_name master
로 브랜치 이름 변경. - 만약 remote project가 비어있어서 브랜치 관련 오류가 발생한다면 빈 커밋을 일단 push하고 사용하면 해결됨.
git commit --allow-empty -m "메세지"
로 empty 커밋을 해주고git push origin
실행.
- 만약 현재 브랜치 이름이 master가 아니라면 브랜치명 변경이 필요함.
7. 프레임워크 사용
- 프로젝트 cmd 창에서 open
pod init
- 2번으로 생성된 podfile에
pod "프레임워크_NAME", :git => "git_주소", :tag => '버전(ex: 0.0.0)'
추가. git 주소는 spec 주소가 아닌 실제 프레임워크로 사용할 코드 저장한 remote repo의 주소를 넣으면 됨. pod install
8. 프레임워크 업데이트
- 프레임워크 워크스페이스에서 코드 수정
- 프레임워크 프로젝트의 변경 사항을 git에 반영해주어야 함.
- 프레임워크 프로젝트가 있는 곳에서 cmd open
git add .
git commit -m "update: version 0.0.0"
git tag 0.0.0
git push origin master 0.0.0
- cocoapod spec이 있는 폴더로 이동 후 cmd 열고
pod repo push [REPO_NAME] [.podspec 파일의 경로]
- 이 프레임워크를 사용하는 프로젝트로 가서 tag 변경 후
pod update
수행
9. 프레임워크 파일 따로 빼기
- 데모 프로젝트를 포함해서 만들고 빌드해본 경우
- 데모 프로젝트의 hierarchy 창에서 Pods > Products > 프레임워크 우클릭 > show in finder 선택 > 프레임워크 폴더 추출
- 아닌 경우
- 7번을 통해 프레임워크 사용하고 hierarchy 창에서 Pods > Products > 프레임워크 우클릭 > show in finder 선택 > 프레임워크 폴더 추출
10. 프레임워크 배포 선택지
cocoapod 자체가 open source 배포 툴임. 따라서 내부 소스코드를 비공개하면서 코드를 배포할 수는 없음. 내부 소스코드를 공개하면서 코드를 배포하는 방식에는 두 가지가 있음.
- 일반적으로 cocoaPod을 사용하는 방식인 내부 코드소스를 public remote repository에 올리고 trunk로 spec(버전 관리)을 배포하는 것
- 내부 소스 코드를 private remote repository에 올리고 spec 배포도 private remote repository에 올리는 것.
- 내부 소스 코드는 비공개지만 코드를 배포하는 것이 아닌 프레임워크 자체를 배포하는 방식
첫 번째 방식은 이 소스 자체에 권한이 있는 사람이든, 없는 사람이든 모두 접근할 수 있지만 두 번째 방식은 배포자 쪽에서 선정한 사람에게만 이 pod lib을 다운받을 수 있게 하여 내부 소스 코드 자체는 공개지만 모든 사람에게 public 하지는 않음. 마지막 방법은 컨슈머가 pod을 통해 받는 대상이 (앞 두 가지 방법) 프레임워크의 소스 코드가 아니고 프레임워크 그 자체임. 결과물은 아래 그림을 보면 차이를 확인할 수 있음.
프레임워크의 소스 코드를 공유 | 프레임워크 자체를 공유 |
![]() |
![]() |
헤더와 .c 파일을 보면 내부 코드가 다 공개되어 있음. | 프레임워크 자체로 공유하기 때문에 확인할 수 없음. |
11. 참고
'CS > iOS, Swift' 카테고리의 다른 글
[iOS] XCFramework build script (0) | 2023.04.06 |
---|---|
[iOS] XCFramework private repository에 cocoapod으로 배포하기 (0) | 2023.04.06 |
[iOS] framework 기본 (0) | 2023.02.14 |
[iOS] xcode, bitbucket 연동 (0) | 2023.02.14 |
[iOS] IDFA 값 받아오기 (0) | 2023.02.14 |