앱 버전 비교하기 - 뀔뀔(swieeft)의 개발새발기

앱 개발을 하다보면 종종 크리티컬한 이슈사항이나, 또는 호환되지 않는 API 사용 등으로 인해 앱 버전을 비교해서 강제 업데이트를 진행해야 할 때가 있습니다.

이를 위해 서버 API를 통하거나, Firebase RemoteConfig 등의 기능을 활용해서 현재 업데이트 된 버전의 정보를 받아와 현재 사용하고 있는 앱의 버전과 비교하는 로직을 만들어야 합니다.

이때 버전 체크 로직 자체가 헷갈리는 경우가 있어 종종 생각지도 못한 케이스에 대해서 실수하곤 합니다.

저도 지금 프로젝트에서 예외 사항에 대해 제대로 고려하지 않고 개발을 해서 로직을 벌써 세번째 바꿨는데 이번에 수정한 로직은 여러 차례 검증을 한 로직입니다.

나중에 다른 프로젝트를 하더라도 사용할 가능성이 높기 때문에 로직에 대해서 정리를 하려고 합니다.

버전의 형태

앱 버전은 주로 1.1.1(Major, Minor, Patch) 형태로 만들어집니다. (아닌 곳도 종종 있습니다.)

각각의 숫자를 설명하자면 아래와 같습니다.

Major : 전체적인 UI 변경이나 이전 버전과 호환되지 않는 API 변경 등의 큰 변화가 이루어졌을 때 증가
Minor : 주요 기능이 추가 되거나 변경 되었을 때 증가
Patch : 버그 수정, 간단한 UI 개선 등의 작은 변화가 있을 때 증가

Version과 Build

iOS에서는 앱 내부적으로 개발자가 앱의 버전을 확인할 때 사용할 수 있는 값에 Version과 Build가 있습니다.

Version : 실제 앱스토어에서 사용자에게 보여지는 버전으로 릴리스 버전으로 사용됩니다. 대부분 1.1.1과 같은 형태로 사용됩니다.
Build : 앱 내부적으로 개발자가 확인하기 위한 번들 버전으로 형태는 Version과 동일하게 사용하기도 하고, 정수, 빌드한 날짜시간 형태로도 사용 가능합니다. 동일한 Version에 여러 Build 버전이 존재할 수 있습니다.
- Version : 위의 버전 형태와 동일
- 정수 : 1, 2, 3, 4, 5…
- 날짜시간 : 202108171500, 202108171600, 202108180900…
앱스토어에서 표현되는 Version과 Build
- 빨간색 박스 : Version
- 파란색 박스 : Build
하나의 Version에 여러개의 Build가 있는 것을 확인 할 수 있습니다.

간단한 앱 버전 비교 방법

회사 프로젝트에서는 Version을 이용해서 앱 버전을 비교하고 있지만 개인 앱의 경우에는 Build를 정수형태로 계속 증가 시켜서 비교하고 있습니다.

이렇게 하면 좋은 점이 Major, Minor, Patch에 대해 각각의 값을 비교하는 로직 처리 없이 바로 정수 vs 정수를 비교해서 버전 비교를 할 수 있다는 장점이 있습니다.

하지만 안드로이드와 공통된 API를 사용한다면 이 방법은 사용하기 어려울 수 있고, 실수로 개발자가 빌드 버전을 수정하지 않고 새로운 버전을 업데이트 할 때에 다시 업데이트를 진행 해야 되는 위험이 있기는 합니다.

아래는 Build를 이용해서 버전 비교를 하는 예제 코드 입니다.

빌드 버전 수정에 대한 이슈는 빌드 시에 쉘 스크립트를 이용해서 자동으로 증가 시키는 방법이 있지만 이 글에서 자세히 다루기에는 글의 성격과 맞지 않는 것 같아서 궁금 하신 분들은 구글에 xcode build number auto increment로 검색해보세요.

Version을 이용한 비교 방법

이제는 이 글의 주요 내용인 Version을 이용한 비교 방법에 대해 알아보려고 합니다.

단순하게 생각하면 Major, Minor, Patch를 각각 나눠서 두개의 버전을 비교하는 로직을 구성하면 되는데요.

Major, Minor, Patch 각각의 값도 고려해야 되고, 상위 버전에 따라서 하위 버전을 비교하지 않을지 등의 케이스를 체크해야 되기 때문에 단순히 어떤게 높다 낮다로만 판단하면 오류가 발생할 수 있습니다.

제가 생각했던 3가지 방법은 아래와 같습니다.

Major, Minor, Patch에 .을 제거해서 정수화 시켜서 비교

단순히 Major, Minor, Patch에 .을 제거해서 비교하면 되지 않을까 해서 시도 했던 방법입니다.

각각의 성공 케이스와 실패 케이스를 예를 들면
- 성공 케이스
  - 앱 버전 : 1.2.0
  - 서버 버전 : 1.2.3
  - 비교 : 120 < 123 업데이트 진행!
- 실패 케이스
  - 앱 버전 : 1.2.10
  - 서버 버전 : 1.3.0
  - 비교 : 1210 < 130 오류!
1.2.0 < 1.2.3을 정수화 시켜서 120 < 123을 비교하면 제대로 비교가 되는 것 같지만, 1.2.10 < 1.3.0을 비교했을 때 1210 < 130이 되어 정상적으로 비교 되지 않는 것을 볼 수 있습니다.
Major, Minor, Patch를 각각 나누어서 순서대로 비교

다음으로 생각해낸 방법은 Major, Minor, Patch를 각각 나누어서 순서대로 비교하는 방법입니다.

이 방법으로도 충분히 버전 비교 로직을 구현할 수 있지만 제가 개발한 코드로는 각각의 조건(<, ==, >)을 모두 비교하면서 내려가야 되다보니 로직이 복잡해보이고 눈에 딱 들어오지 않았습니다.
- 예제 코드
좀 더 다듬어서 사용해도 될 것 같긴하지만 저는 다른 방법을 찾아보았습니다.
Major, Minor, Patch를 각각 나누어서 역순으로 비교

좀 더 간결한 비교 로직을 만들 수 없을까해서 생각한 방법이 Patch, Minor, Major 순서대로 비교를 하는 방법이었습니다.

아래서부터 비교해나가면서 업데이트 여부를 체크하면 순차적으로 체크가 가능하니깐 업데이트 여부 체크 값을 하나 가진 상태로 순차적으로 상태를 바꿔주면 되지 않을까 생각했습니다.

그래서 역순으로 for문을 돌려 비교를 진행 했고, 해당 로직으로 비교가 정상적으로 되는 것을 확인 했습니다.
- 예제 코드