Marketing Versionとは？Build Numberとの違いと設定方法

Marketing Versionとは

Marketing Versionは、エンドユーザー向けにアプリケーションのバージョンを表すセマンティック文字列です。iOSではCFBundleShortVersionStringキーで設定し、AndroidではversionNameで設定します。

“Marketing Version”という用語はXcodeで正式に使用されています。ターゲット設定のインターフェースではフィールド名が“Marketing Version”で、Info.plistではCFBundleShortVersionStringに対応します。Androidでの相当品はversionNameですが、この用語はあまり使用されません。

Apple Developerドキュメント（2025年）によると、Marketing Versionはドットで区切られた最大3つの数字で構成され、スペースや特殊文字を含んではいけません。各数字は255を超えてはいけません。

変更の重要度を反映するようにMarketing Versionを選択してください。根本的な変更にはメジャーアップデート、新機能にはマイナーアップデートを使用します。

内部Build Numberとの違い

Marketing VersionはBuild Numberとは目的が根本的に異なります。前者はユーザーに情報を伝え、後者はストア向けにビルドを識別します。Build NumberはMarketing Versionを変更せずに増やすことができます。

たとえば、公開済みリリースの重大なバグを修正する場合、チームは同じMarketing Version（1.2.0）でもBuild Numberを大きくして（15から16へ）アプリケーションを再ビルドできます。ユーザーは同じバージョンを表示しますが、ストアはビルドが新しいことを認識します。

この柔軟性により、開発者はバージョン変更をユーザーに通知せずに修正をリリースできます。

Marketing Versionの表示場所

Marketing Versionは、ユーザーとアプリケーションのやり取りにおけるいくつかの主要な接点で表示されます。アプリストアでは、アプリカード、アップデートの説明、バージョン履歴に表示されます。

デバイス上では、Marketing Versionはシステム設定（“情報”または“アプリ”セクション）、App StoreまたはGoogle Playのアップデートダイアログ、およびアプリ内の“バージョン情報”画面に表示されます。

明確なMarketing Versionは、ユーザーがインストールされているバージョンの最新性を評価し、アップデートの判断を行うのに役立ちます。

iOSのMarketing Version

iOSでは、Marketing VersionはXcodeのターゲット設定のGeneralタブにある“Marketing Version”フィールドで設定します。値はInfo.plistにCFBundleShortVersionStringとして保存されます。

バージョン形式はAppleによって厳格に規制されています。文字列はドットで区切られた1〜3つの数字で構成する必要があります（例：1、1.2、1.2.3）。最大長は18文字です。各数字は255を超えてはいけません。

Apple App Store Review Guidelines（2025年）によると、App Store ConnectはMarketing Versionが以前の公開バージョンからメジャーまたはマイナーの値で1つ以上異なるビルドのアップロードを許可しません。これにより、ユーザーがアップデートを見逃すのを防ぎます。

コマンドラインからMarketing Versionを管理するにはagvtoolを使用してください。CI/CDとの統合が簡素化され、Build Numberとの同期が保証されます。

AndroidのMarketing Version

Androidでは、Marketing Versionはbuild.gradleファイルのversionNameパラメータで設定します。iOSとは異なり、Androidはバージョン文字列の形式に厳格な制限を課しません。

versionNameには任意の文字（英字、数字、ハイフン、ドット）を含めることができます。Google Playはこの文字列をアプリカードとアップデートリストに表示しますが、特定のパターンに対する検証は行いません。

ただし、Google Playは一貫性のためにセマンティックなMajor.Minor.Patch形式に従うことを推奨しています。これにより、ユーザーがバージョンを理解しやすくなり、アップデートの自動分析が可能になります。

リリースタイプ（メジャー、マイナー、パッチ）を明確に反映するversionNameを設定してください。これにより、ユーザーは変更の重要度を迅速に評価できます。

動的なversionNameの生成

AndroidのversionNameは、GitタグやCI/CD変数に基づいて動的に生成できます。これにより、バージョニングプロセスが簡素化され、リポジトリとビルド間の不一致が解消されます。

一般的なアプローチは、Gitタグ（例：v2.1.0）を読み取り、その値をversionNameとして使用することです。タグがない場合は、日付とコミット番号に基づいてバージョンを生成できます。

このアプローチにより、versionNameが常にソースコードの状態と一致し、手動での更新が不要になります。

Marketing VersionとBuild Numberの違い

Marketing VersionとBuild Numberは、異なる目的を果たす2つの独立したパラメータです。Marketing Versionはユーザーに情報を伝え、Build Numberは技術的にビルドを識別します。

主な違いは一意性です。Build Numberは各ビルドで一意である必要があります。Marketing Versionは繰り返し使用できます。同じバージョンの複数のビルドは同じMarketing Versionを持ちますが、Build Numberは異なります。

Google Playポリシー（2025年）によると、同じMarketing Versionでも異なるBuild Numberを持つ2つのAPKをアップロードした場合、Google Playは両方を同じバージョンの異なるビルドとして受け入れます。App Storeでも同様のルールが適用されます。

覚えておいてください。Build Numberはマシン用、Marketing Versionは人間用です。前者は自動化し、後者は慎重に計画してください。

バージョニング戦略

戦略の選択は、アプリケーションのタイプ、対象ユーザー、リリースプロセスによって異なります。セマンティック、カレンダー、ハイブリッドの3つの主要なスキームがほとんどのシナリオをカバーします。

セマンティックバージョニング（SemVer）はMajor.Minor.Patch形式を使用し、各コンポーネントをいつ増やすべきかを厳密に定義します。公開APIと複雑な統合を伴うアプリケーションに最適です。

semver.org（2023年）によると、SemVer仕様のバージョン2.0.0はオープンソースのモバイルプロジェクトの89%で使用されており、すべてのパッケージマネージャーでサポートされています。

カレンダーバージョニング

カレンダーバージョニング（CalVer）はリリース日をバージョンとして使用します（例：2025年6月の場合は25.06）。このアプローチは頻繁にアップデートされるアプリケーションで人気があります。

CalVerは変更の重要度に関する情報を伝えませんが、バージョンの新しさを明確に示します。ユーザーはバージョン25.06が25.03より新しいことをすぐに理解できます。

アプリが頻繁にアップデートされ、ユーザーが変更の範囲よりもデータの新しさを重視する場合は、カレンダーバージョニングを選択してください。

選択の推奨事項

MVPやスタートアップには、パッチなしのシンプルなセマンティックバージョン（Major.Minor）が適しています。長期的なサポートが必要な成熟製品には完全なSemVer、継続的リリースのアプリにはCalVerを選択してください。

決して日付をBuild Numberとして使用しないでください。1日に複数のビルドがある場合に競合が発生する可能性があります。Build Numberは順序番号または複合番号で、常に単調増加する必要があります。

Marketing Versionのよくある間違い

典型的な間違いは、新しいメジャーラインに移行する際にバージョンコンポーネントをスキップすることです。たとえば、バージョン1.9.9の次は2.0.0であるべきで、1.10.0ではありません。これはセマンティクスを壊し、ユーザーを混乱させます。

もう1つの一般的な問題は、コードとアプリストアでMarketing Versionが一致しないことです。レビュー用にビルドを提出する前に、build.gradleのversionNameがGoogle Play ConsoleまたはApp Store Connectで指定されたバージョンと一致していることを常に確認してください。

Marketing Versionの設定例

コード例では、両方のプラットフォームでMarketing Versionを設定し、その更新を自動化する方法を示します。

Android GradleでのversionNameの設定

Androidでは、versionNameはbuild.gradleで設定します。値は静的に設定することも、環境変数から読み取ることもできます。

android {
    defaultConfig {
        versionCode 15
        versionName "2.1.0"
    }
}

// Gitタグからバージョンを読み取り
def getVersionNameFromGit = {
    def tag = "git describe --tags".execute().
        text.trim()
    return tag.startsWith("v") ? tag.substring(1) : tag
}

versionNameはGitタグから抽出され、リポジトリのバージョンとビルドされたアプリケーションの整合性が保証されます。

XcodeでのMarketing Versionの管理

iOSでは、Marketing VersionはXcodeまたはagvtoolを使用して設定します。以下のコマンドで新しいマーケティングバージョンを設定します。

# Marketing Versionを設定
xcrun agvtool new-marketing-version 2.1.0

# 自動インクリメント
xcrun agvtool next-marketing-version

agvtoolは自動的にInfo.plistを更新し、Xcodeプロジェクトのすべてのターゲット間でバージョンを同期します。

両方のプラットフォーム向けFastlane

Fastlaneを使用すると、1つのスクリプトから両方のプラットフォームでMarketing Versionを管理でき、クロスプラットフォームプロジェクトのメンテナンスが簡素化されます。

# マーケティングバージョンを設定
increment_version_number(
    version_number: "2.1.0"
)

# マイナーバージョンの自動インクリメント
increment_version_number(
    bump_type: "minor"
)

Fastlaneは両方のプラットフォームで動作し、ほとんどのCI/CDサービスでサポートされています。