Xcode Build Settings 타겟분리

일단 Xcode에는 debug 와 Release가 있습니다.

Build Setting을 개발과 운영 어떤 방식으로 구분할 지 그 방법에 대해서 고민해본 결과를 서술합니다.

 

이 글을 시작하기 전...

일단 Xcode에는 debug 와 Release가 기본적으로 분리되어 있죠.

이와 관련하여, Build Setting을 개발과 운영 어떤 방식으로 구분할 지 그 방법에 대해서 고민해본 결과를 서술합니다.

저의 목적!

개발과 운영을 나눠, Log 는 Release일때 당연히 ㄴㄴ, 빼고 싶은 파일들이 있으므로 Release로 아카이브 했을때 그 파일들은 담기면 안됩니다!

 

 

항목	Debug	Release
내부 상수의 IS_DEBUG	true	false
Log 출력	허용	허용 안함
MOCK network code	포함	포함 안됨
최적화	최소	최대

 

Target 분리

방법

구글링을 해보면 꽤 많은 사람들이 Target을 개발과 운영 분리해서 사용하고 있습니다. 일단 장단점을 확인 하기 전, 아래 간단한 방법~

 

저렇게 기존에 있던 target을 duplicate 하고!

Manage Schemes 해보면 copy로 생성된 스키마가 있습니다~ 명명 원하시는 대로 수정해주시면 됩니다.

 

이렇게 아래와 같이 plist가 같이 생성되어 있습니다. 이 아이도 명명 수정 하고

프로젝트 파일에서 같은 명명으로 변경해줍니다.

이렇게 하고 새로운 타겟으로 build하면 완벽하게 빌드~ bundle id가 같기 때문에 기존에 있던 타겟과 같은 앱이 실행될겁니다! 어쨌든 이렇게 타겟을 분리해 놓고 개발과 운영을 관리하는 방법이 있습니다!

(여기서 잠깐, Enterprise target은 내부용 테스트에요~)

장단점

장점단점

명시적으로 타겟이 분리되어 있기때문에 확연히 눈에 드러납니다. 프로젝트는 공통적으로 모든 타겟에 반영됩니다. ( Info, Build Setting, Swift Pacakges ) 안전하다는 장점은 있습니다. 보통 같은 앱(소스)이나 아주 조금 다른 두개의 앱을 만들어 낼때 사용합니다. (제 느낌상, 뭔가 다른 output이 나오는 느낌입니다.)

파일을 하나 생성해보세요, 그게 바로 Copy에 적용되지는 않습니다.  즉 분리 된 만큼, 따로따로 적용해야 될 일이 늘어난다는 것입니다.

 

결론

아래 더 쉬운 방법이 있습니다. 그걸로 결정했죠!

Configuration

configuration file

우선, Xcode는 자체적으로 아주 쉽게 Debug와 Release를 나눠 놓았습니다.

찾아보니, 저기에 있는 Configuration File을 아예 따로 작성해서 관리하는 사람도 있다고는 합니다만은 위의 목적을 보시면 그정도로 나눠서 분리할게 오히려 더 없기때문에 그냥 그런 방법만 있다 하고 넘어가겠습니다

주의 아닌 주의! Target의 BuildSetting만 변경할 경우 모든 Target에 적용되지 않을 수 있습니다~ 상황에 따라 적용하세요! 위의처럼 Project의 BuildSetting을 수정하면 모두 공통적으로 수정됩니다! 앞으로의 수정사항들도 같습니다!

장단점

장점	단점
편하고 익숙합니다. 이미 분리되어서 제공되는 option들이 아주 잘 되어있습니다.	debug와 Release의 차이가 아주 많아서, 한눈에 이를 비교하거나 많은 것들이 따로 관리되어야 할 경우 쉽게 알기 어렵습니다.

최적화

프로젝트 명 - Build Settings 를 확인합니다.

debug 모드 일때 최소, Release 일때 최대입니다.

아래는 최적화 옵션 설명입니다.

출처 : https://developer.apple.com/library/archive/documentation/Performance/Conceptual/CodeFootprint/Articles/CompilerOptions.html

아래의 Whole Module 및 속도 optimization 세팅도 최적화를 위해 Set해줍니다.

Log & IS_DEBUG

우선 기본적으로 아래 preprocess가 정의되어 있다면,

 

아래와 같이 코드를 작성할 수 있습니다.

그러면 디버그 모드로 빌드했을때 아래와 처럼 확인할 수 있습니다.

 

이건 논외지만, 기본적으로 제공되는 debug/Release도 있지만, swift 버전이라던지, os의 종류에 따라서 처리하는것도 됩니다.

혹시 궁금할까봐 예시~

 

자 여기서 Flag에 대한 상세한 면을 알아봅니다.

이렇게 아래처럼 Flag를 바꿀수도 있습니다.

그러면

 

위의 코드의 결과는?!

당연하쥬~ DEBUG와 IS_DEBUG 둘다 하고싶다면 당연히 추가해서 flag 를 두개로 쓸 수 있도록 해주면 됩니다~ Custom은 알아서!

이러면 디버그 모드로 빌드했을때 위의 코드 모두 돕니다!!

 

이외에도 바꾸고 싶은게 있으시다구요?

DEBUG랑 RELEASE말고 하나 더 있었으면 좋겠다! → 이건 scheme를 따라갑니다. 위에 타겟분리 설명하면서 Scheme만드는거 있죠?! 그렇게 만들면 build/CustomScheme/Release 오예!

RELEASE일때도 DEBUG 가 True 였으면 좋겠다! → 아래 처럼 DEBUG를 Flag로 추가하면 flag로 등록한거니까, Release Mode로 빌드했으나 #if DEBUG를 탑니다~ Release 모드에서 에러가 났는데 로그가 보고싶다! 이렇게 Flag 추가해주면 되겟죠?! 저렇게 추가만 해주면 끝, 나온다는거!

File 분리

TEST 프로젝트의 목킹 네트워크 파일은 Release때 포함하지 않도록 하였습니다. 따라서 특정 파일은 debug 또는 운영일때 포함되어서는 안되는 예제를 작성해보았습니다.

아래는 예시를 위해 debug일때 test.swift 파일을 제외한 경우입니다. 아래와 같이 파일을 추가할경우 빌드에 포함되지 않고, 코드내에서 불리지도 않습니다.

기존 옵션

 

Test가 불리는지 확인해보겠습니다. 아래와 같은 예시 코드를 작성하고 오른쪽 처럼 불러봅니다.

아래와 같이 제외 파일을 추가합니다.

파일을 추가하고 나면, 두둥! 에러로 제외되었음을 확인할 수 있습니다.

이 프로젝트의 경우 제외시켜야 하는 폴더를 미리 만들어 놓고 그 폴더 밑에 파일들을 추가해 일일이 파일을 제외시키지 않더라도, 제외할 폴더를 지정해둡니다.

• 폴더 제외 예시 (서브 폴더를 생성할 경우 따로 적어줘야합니다.)

자 여기서 중요한 사실이 있습니다. 저기 위에 보셨듯이 파일이 제외되면 error가 납니다.

그럼 저와 같은 디버그 모드에만 파일을 쓰고 운영일때는 빼고 빌드하고싶다면

코드 작성시에도 위에 있던 이런식으로 아이들을 불러 줘야 에러가 나지 않을겁니다,,,

진짜 끝~

(사실... 이 방법 외에도 파일을 만들고 거기의 target을 체크 해제하는 등의 방법이 있으나, 폴더를 만들어 놓고 제외파일은 거기 넣기로 정하는 편이 매번 파일을 만들때 마다 신경쓰지 않아도 되는 방법이라고 생각되어 이렇게 하기로 했습니다~)