Xcode의 버전 대 빌드

Xcode의 버전 대 빌드

---

Xcode 3으로 개발 한 앱이 있고 최근에 Xcode 4로 편집을 시작했습니다. 대상 요약에는 식별자, 버전, 빌드, 장치 및 배포 대상과 같은 필드가있는 iOS 응용 프로그램 대상 양식이 있습니다. 버전 필드는 비어 있고 빌드 필드는 3.4.0입니다 (Xcode 3으로 편집 중일 때의 앱 버전과 일치).

내 질문은 다음과 같습니다.

1. 버전 및 빌드 필드의 차이점은 무엇입니까?

2. Xcode 4로 업그레이드 한 후 버전 필드가 비어있는 이유는 무엇입니까?

---

애플은 필드를 재배치 / 재 목적했습니다.

앞으로 응용 프로그램 대상에 대한 정보 탭을 보면 버전 (예 : 3.4.0)으로 "번들 버전 문자열, 단축"을 사용하고 빌드 (예 : 500 또는 1A500)로 "번들 버전"을 사용해야합니다. ). 둘 다 표시되지 않는 경우 추가 할 수 있습니다. 요약 탭의 적절한 버전 및 빌드 텍스트 상자에 매핑됩니다. 동일한 값입니다.

정보 탭을 볼 때 마우스 오른쪽 버튼을 클릭하고 원시 키 / 값 표시를 선택 하면 실제 이름이 CFBundleShortVersionString(버전) 및 CFBundleVersion(빌드)임을 알 수 있습니다.

버전은 일반적으로 Xcode 3에서 사용하는 것처럼 보이는 방식으로 사용됩니다. 버전 / 빌드 차이에 대해 어떤 수준을 묻는 지 잘 모르겠으므로 철학적으로 대답하겠습니다.

모든 종류의 계획이 있지만 인기있는 계획은 다음과 같습니다.

{MajorVersion}. {MinorVersion}. {Revision}

• 주요 버전 -주요 변경, 재 설계 및 기능 변경
• 마이너 버전 -마이너 개선, 기능 추가
• 개정 -버그 수정을위한 패치 번호

그런 다음 빌드를 개별적으로 사용하여 릴리스 또는 전체 제품 수명 동안 총 빌드 수를 나타냅니다.

많은 개발자가 빌드 번호를 0부터 시작하고 빌드 할 때마다 번호가 하나씩 증가하여 영원히 증가합니다. 내 프로젝트에는 빌드 할 때마다 빌드 번호를 자동으로 늘리는 스크립트가 있습니다. 아래 지침을 참조하십시오.

• 릴리스 1.0.0은 빌드 542 일 수 있습니다. 1.0.0 릴리스에 도달하려면 542 빌드가 필요했습니다.
• 릴리스 1.0.1은 빌드 578 일 수 있습니다.
• 릴리스 1.1.0은 빌드 694 일 수 있습니다.
• 릴리스 2.0.0은 빌드 949 일 수 있습니다.

Apple을 포함한 다른 개발자는 주요 버전 + 부 버전 + 릴리스의 빌드 수로 구성된 빌드 번호를 가지고 있습니다. 마케팅에 사용되는 값이 아닌 실제 소프트웨어 버전 번호입니다.

Xcode 메뉴> Xcode 정보 로 이동 하면 버전 및 빌드 번호가 표시됩니다. 당신이 공격하면 더 많은 정보를 ... 버튼을 사용하면 서로 다른 버전의 무리를 볼 수 있습니다. 이후 추가 정보 ... 버튼이 엑스 코드 5를 제거하고,이 정보는에서 구할 소프트웨어> 개발자 의 섹션 시스템 정보 , 응용 프로그램 열어 사용할 수 애플 메뉴> 이 매킨토시에 관하여 > ... 시스템 보고서 .

예 : Xcode 4.2 (4C139). 마케팅 버전 4.2는 빌드 메이저 버전 4, 빌드 마이너 버전 C 및 빌드 번호 139입니다. 다음 릴리스 (예상 4.3)는 빌드 릴리스 4D 일 가능성이 높으며 빌드 번호는 0에서 시작하여 거기에서 증가합니다.

iPhone Simulator 버전 / 빌드 번호는 iPhone, Mac 등과 같은 방식입니다.

• 3.2 : (7W367a)
• 4.0 : (8A400)
• 4.1 : (8B117)
• 4.2 : (8C134)
• 4.3 : (8H7)

업데이트 : 요청에 따라 Xcode에서 앱을 빌드 할 때마다 실행되는 스크립트를 생성하여 빌드 번호를 읽고, 증분하고, 앱의 {App}-Info.plist파일에 다시 쓰는 단계는 다음과 같습니다 . Settings.bundle/Root*.plist파일에 버전 / 빌드 번호를 기록하려는 경우 선택적 추가 단계가 있습니다 .

이것은 어떻게에 기사에서 확장 여기 .

Xcode 4.2-5.0 :

1. Xcode 프로젝트를로드하십시오.
2. 왼쪽 창에서 계층 구조 맨 위에있는 프로젝트를 클릭합니다. 프로젝트 설정 편집기가로드됩니다.
3. 중앙 창의 왼쪽에서 TARGETS 제목 아래에있는 앱을 클릭 합니다. 각 프로젝트 대상에 대해이 설정을 구성해야합니다.
4. 빌드 단계 탭을 선택합니다 .
5. • Xcode 4의 오른쪽 하단에서 빌드 단계 추가 버튼을 클릭하고 스크립트 실행 추가를 선택 합니다.
   • Xcode 5에서 편집기 메뉴> 빌드 단계 추가 > 실행 스크립트 빌드 단계 추가를 선택 합니다 .
6. 새 스크립트 실행 단계를 드래그 앤 드롭하여 번들 리소스 복사 단계 (app-info.plist 파일이 앱과 함께 번들로 제공되는 경우) 바로 이전으로 이동합니다 .
7. 새로운 스크립트 실행 단계에서 Shell :을 설정 /bin/bash합니다.

8. 정수 빌드 번호의 스크립트 영역에 다음을 복사하여 붙여 넣으십시오.

   buildNumber=$(/usr/libexec/PlistBuddy -c "Print CFBundleVersion" "$INFOPLIST_FILE")
   buildNumber=$(($buildNumber + 1))
   /usr/libexec/PlistBuddy -c "Set :CFBundleVersion $buildNumber" "$INFOPLIST_FILE"
   

   @Bdebeez가 지적했듯이 Apple Generic Versioning Tool ( agvtool)도 사용할 수 있습니다. 대신 사용하려는 경우 먼저 변경해야 할 몇 가지 사항이 있습니다.

   • 빌드 설정 탭을 선택합니다 .
   • 언더 버전 관리 섹션에서 설정 현재 프로젝트 버전을 사용하려는 초기 빌드 번호, 예를 들어,에 1 .
   • Back on the Build Phases tab, drag-and-drop your Run Script phase after the Copy Bundle Resources phase to avoid a race condition when trying to both build and update the source file that includes your build number.

   Note that with the agvtool method you may still periodically get failed/canceled builds with no errors. For this reason, I don't recommend using agvtool with this script.

   Nevertheless, in your Run Script phase, you can use the following script:

   "${DEVELOPER_BIN_DIR}/agvtool" next-version -all
   

   The next-version argument increments the build number (bump is also an alias for the same thing), and -all updates Info.plist with the new build number.

9. And if you have a Settings bundle where you show the Version and Build, you can add the following to the end of the script to update the version and build. Note: Change the PreferenceSpecifiers values to match your settings. PreferenceSpecifiers:2 means look at the item at index 2 under the PreferenceSpecifiers array in your plist file, so for a 0-based index, that's the 3rd preference setting in the array.

   productVersion=$(/usr/libexec/PlistBuddy -c "Print CFBundleShortVersionString" "$INFOPLIST_FILE")
   /usr/libexec/PlistBuddy -c "Set PreferenceSpecifiers:2:DefaultValue $buildNumber" Settings.bundle/Root.plist
   /usr/libexec/PlistBuddy -c "Set PreferenceSpecifiers:1:DefaultValue $productVersion" Settings.bundle/Root.plist
   

   If you're using agvtool instead of reading the Info.plist directly, you can add the following to your script instead:

   buildNumber=$("${DEVELOPER_BIN_DIR}/agvtool" what-version -terse)
   productVersion=$("${DEVELOPER_BIN_DIR}/agvtool" what-marketing-version -terse1)
   /usr/libexec/PlistBuddy -c "Set PreferenceSpecifiers:2:DefaultValue $buildNumber" Settings.bundle/Root.plist
   /usr/libexec/PlistBuddy -c "Set PreferenceSpecifiers:1:DefaultValue $productVersion" Settings.bundle/Root.plist
   

10. And if you have a universal app for iPad & iPhone, then you can also set the settings for the iPhone file:

    /usr/libexec/PlistBuddy -c "Set PreferenceSpecifiers:2:DefaultValue $buildNumber" Settings.bundle/Root~iphone.plist    
    /usr/libexec/PlistBuddy -c "Set PreferenceSpecifiers:1:DefaultValue $productVersion" Settings.bundle/Root~iphone.plist
    

---

(Just leaving this here for my own reference.) This will show version and build for the "version" and "build" fields you see in an Xcode target:

- (NSString*) version {
    NSString *version = [[[NSBundle mainBundle] infoDictionary] objectForKey:@"CFBundleShortVersionString"];
    NSString *build = [[[NSBundle mainBundle] infoDictionary] objectForKey:@"CFBundleVersion"];
    return [NSString stringWithFormat:@"%@ build %@", version, build];
}

In Swift

func version() -> String {
    let dictionary = NSBundle.mainBundle().infoDictionary!
    let version = dictionary["CFBundleShortVersionString"] as? String
    let build = dictionary["CFBundleVersion"] as? String
    return "\(version) build \(build)"
}

---

The Build number is an internal number that indicates the current state of the app. It differs from the Version number in that it's typically not user facing and doesn't denote any difference/features/upgrades like a version number typically would.

Think of it like this:

• Build (CFBundleVersion): The number of the build. Usually you start this at 1 and increase by 1 with each build of the app. It quickly allows for comparisons of which build is more recent and it denotes the sense of progress of the codebase. These can be overwhelmingly valuable when working with QA and needing to be sure bugs are logged against the right builds.
• Marketing Version (CFBundleShortVersionString): The user-facing number you are using to denote this version of your app. Usually this follows a Major.minor version scheme (e.g. MyAwesomeApp 1.2) to let users know which releases are smaller maintenance updates and which are big deal new features.

To use this effectively in your projects, Apple provides a great tool called agvtool. I highly recommend using this as it is MUCH more simple than scripting up plist changes. It allows you to easily set both the build number and the marketing version. It is particularly useful when scripting (for instance, easily updating the build number on each build or even querying what the current build number is). It can even do more exotic things like tag your SVN for you when you update the build number.

To use it:

• Set your project in Xcode, under Versioning, to use "Apple Generic".
• In terminal
  • agvtool new-version 1 (set the Build number to 1)
  • agvtool new-marketing-version 1.0 (set the Marketing version to 1.0)

See the man page of agvtool for a ton of good info

---

The script to autoincrement the build number in the answer above didn't work for me if the build number is a floating point value, so I modified it a little:

#!/bin/bash    
buildNumber=$(/usr/libexec/PlistBuddy -c "Print CFBundleVersion" "$INFOPLIST_FILE")
buildNumber=`echo $buildNumber +1|bc`
/usr/libexec/PlistBuddy -c "Set :CFBundleVersion $buildNumber" "$INFOPLIST_FILE"

---

The marketing release number is for the customers, called version number. It starts with 1.0 and goes up for major updates to 2.0, 3.0, for minor updates to 1.1, 1.2 and for bug fixes to 1.0.1, 1.0.2 . This number is oriented about releases and new features.

The build number is mostly the internal number of builds that have been made until then. But some use other numbers like the branch number of the repository. This number should be unique to distinguish the different nearly the same builds.

As you can see, the build number is not necessary and it is up to you which build number you want to use. So if you update your Xcode to a major version, the build field is empty. The version field may not be empty!.

---

To get the build number as a NSString variable:

NSString * appBuildString = [[NSBundle mainBundle] objectForInfoDictionaryKey:@"CFBundleVersion"];

To get the version number as a NSString variable:

NSString * appVersionString = [[NSBundle mainBundle] objectForInfoDictionaryKey:@"CFBundleShortVersionString"];

If you want both in one NSString:

NSString * versionBuildString = [NSString stringWithFormat:@"Version: %@ (%@)", appVersionString, appBuildString];

This is tested with Xcode Version 4.6.3 (4H1503). The build number is often written in parenthesis / braces. The build number is in hexadecimal or decimal.

---

In Xcode you can auto-increment the build number as a decimal number by placing the following in the Run script build phase in the project settings

#!/bin/bash    
buildNumber=$(/usr/libexec/PlistBuddy -c "Print CFBundleVersion" "$INFOPLIST_FILE")
buildNumber=$(($buildNumber + 1))
/usr/libexec/PlistBuddy -c "Set :CFBundleVersion $buildNumber" "$INFOPLIST_FILE"

For hexadecimal build number use this script

buildNumber=$(/usr/libexec/PlistBuddy -c "Print CFBundleVersion" "$INFOPLIST_FILE")
buildNumber=$((0x$buildNumber)) 
buildNumber=$(($buildNumber + 1)) 
buildNumber=$(printf "%X" $buildNumber)
/usr/libexec/PlistBuddy -c "Set :CFBundleVersion $buildNumber" "$INFOPLIST_FILE"

---

Thanks to @nekno and @ale84 for great answers.

However, I modified @ale84's script it little to increment build numbers for floating point.

the value of incl can be changed according to your floating format requirements. For eg: if incl = .01, output format would be ... 1.19, 1.20, 1.21 ...

buildNumber=$(/usr/libexec/PlistBuddy -c "Print CFBundleVersion" "$INFOPLIST_FILE")
incl=.01
buildNumber=`echo $buildNumber + $incl|bc`
/usr/libexec/PlistBuddy -c "Set :CFBundleVersion $buildNumber" "$INFOPLIST_FILE"

---

another way is to set the version number in appDelegate didFinishLaunchingWithOptions:

- (BOOL)application:(UIApplication *)application         didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
{
     NSString * ver = [self myVersion];
     NSLog(@"version: %@",ver);

     NSUserDefaults* userDefaults = [NSUserDefaults standardUserDefaults];
     [userDefaults setObject:ver forKey:@"version"];
     return YES;
}

- (NSString *) myVersion {
    NSString *version = [[[NSBundle mainBundle] infoDictionary] objectForKey:@"CFBundleShortVersionString"];
    NSString *build = [[[NSBundle mainBundle] infoDictionary] objectForKey:@"CFBundleVersion"];
    return [NSString stringWithFormat:@"%@ build %@", version, build];
}

참고URL : https://stackoverflow.com/questions/6851660/version-vs-build-in-xcode