06．はじめてスマホアプリを作ってみた（公開フェーズ）【 Android / Xamarin.Forms 】

記事の概要

こちらの一覧の６つ目、「公開フェーズ（アプリを公開する）」の記事となります。

はじめてスマホアプリを作ってみた 記事一覧

1. 検討フェーズ（どんなアプリを作るか）
2. 要件フェーズ（どんな要件のアプリにするか）
3. 調査フェーズ（どんな技術を使うか）
4. 設計フェーズ（どうやって作るか）
5. 開発フェーズ（実際に作りはじめる）
6. 公開フェーズ（アプリを公開する）
7. 保守フェーズ（公開から現在まで）

こちらでインストールできます
※アンドロイド版のみです。iPhoneユーザの方すみません。

全７回に分割して書いていますが長いので、ダイジェストで読みたい方はこちらの記事をご覧ください。

はじめてのスマホアプリ開発 公開フェーズ

前回は、実装作業の工程で行ったことについて書きました。

今回はいよいよ作ったアプリをGoogle Playでリリースするまでに行ったことをまとめてみたいと思います。

リリースで行った作業メニューです。

• アップデートを見据えたリリース環境の設計
• リリースに向けたアプリの準備
• Google Play デベロッパー アカウントへの登録
• Googl Play Store API の準備
• Google Play Console にアプリを登録
• Visual Studio App Center の準備

ようやく開発を終え、一息付けたと思ったらリリース作業は思った以上に大変でした。

この記事では、大まかにどのような作業が発生するのかを記していきたいと思います。
それぞれの項目の細かい手順などは、後日、別途記事を書きたいと思います。

アップデートを見据えたリリース環境の設計

単純に作成したアプリをGoogle Playに公開するだけであればローカルでビルド・アーカイブを行い、Google Playに手動でアップロードすれば済みます。

しかし、リリース後にバグを発見したり、機能を追加するたびに慎重な作業を強いられるのは何かと面倒です。

ということで、リモートリポジトリから自動でビルド＆リリースができる環境を構築しながら初めてのリリースを目指したいと考えました。

イメージとしてはこんな感じです。

では順を追って書いていきたいと思います。

Google Play デベロッパーアカウントへの登録

AndroidアプリをGoogle Playで公開するには、「Google Play デベロッパーアカウント」に登録する必要があります。

登録は、上記リンクの「ステップ１」にある「デベロッパー アカウントに登録」のリンクから行うことができます。

この作業自体は簡単です。
注意としては、$25の登録料がかかることぐらいでしょうか。
これは一度支払えばよい初期費用のようなものです。

ちなみにiPhoneアプリの場合は年間サブスクリプションで11,800円かかるそうです。
(2021/3/5 時点 Apple Developer Program)

リリースに向けたアプリの準備

Xamarin.Formsでの開発用には一応、このような公式ドキュメントがありますので、ひと通り試してみました。
リリースに向けてアプリケーションを準備する

アプリケーション アイコンを指定する
わたしは「Prism」というXamarin.FormsをMVVMで実装するためのパッケージを使用したので、アイコンはデフォルトを置き換えるだけで済みましたが、イチから作った場合やAndroid Studioで開発した場合には設定が必要かと思います。

アプリケーションのバージョン
Android Manifest にバージョンを管理する項目があります。
ここのバージョン番号は、Google Playのリリースノートに表示されます。
デフォルトでは「1.0」となっていますが、とりあえず「1.0.0」と番号を区切ることにしました。
定義としては、大幅なリニューアルはメジャーバージョン番号、機能追加などマイナーアップデートは真ん中のマイナーバージョン番号、バグ修正などは一番右の番号をインクリメントすることとしました。

APK を圧縮する
これはですね、非常にやっかいです。
Android Studioでネイティブ開発をした方は、快適にリンカーや難読化を利用できるのでしょうか。

わたしの環境は、「Visual Studio Community 2019」です。

パッケージサイズを小さくできるならと、なんの準備もせずにリンカーを「[SDK およびユーザー アセンブリ」に設定すると、見事にリリースしたアプリは起動しませんでした。

このリンカーは、未使用と判断したコードを削除することで軽量化を行ってくれるツールのようですが、削除対象から外す設定をしっかりしておかないと、必要なコードまで削ってしまいます。

最初は「SDK アセンブリのみ」を選択しておくのがよいと思います。

これでも、リンカーをオフにするよりパッケージサイズはかなり小さくなります。

もうひとつ、Java バイトコード レベルで最適化をしてくれる「ProGuard」の説明がありますが、ドキュメント通りに設定するとビルドが通りません。

ProGuardは非推奨で「R8」を使えとなります。

で、R8を選択してリリースビルドするとあら不思議、またもやアプリは起動しません。

これも、必要なライブラリや自分のコードを設定ファイルで「keep」しておく作業が必要です。

これも、とりあえずは未選択としておきました。

※追記：2021/03/13
後日談として、APK圧縮にチャレンジし敗れ去る話をまとめています。

アプリケーションを保護する
仮にR8を使用したとしても、Xamarin.Forms の場合はコードの難読化はされません。
必要があれば「Dotfuscator」なるものを使えとあります。

Integrating Dotfuscator's Protection into Your Xamarin Apps in Visual Studio

こちらも試してみましたが、ビルドが通るようにするまでにかなり苦労しました。

しかし、コードの難読化はなされず……。

Root Checkは入れておきたいと思っているので、いずれまた挑戦するとして、今回は諦めることにしました。

AODコンパイルやLLVMコンパイラは、Visual Studioのエンタープライズエディションが必要なのでパスです。

パッケージング プロパティを設定する

わたしのAndroid.csprojのリリース用PropertyGroupはこんな感じになりました。

<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">
  <DebugType>pdbonly</DebugType>
  <Optimize>true</Optimize>
  <OutputPath>bin\Release</OutputPath>
  <DefineConstants>TRACE</DefineConstants>
  <ErrorReport>prompt</ErrorReport>
  <WarningLevel>4</WarningLevel>
  <AndroidUseSharedRuntime>false</AndroidUseSharedRuntime>
  <AndroidLinkMode>SdkOnly</AndroidLinkMode>
  <AotAssemblies>false</AotAssemblies>
  <EnableLLVM>false</EnableLLVM>
  <BundleAssemblies>false</BundleAssemblies>
  <AndroidDexTool>d8</AndroidDexTool>
  <AndroidPackageFormat>aab</AndroidPackageFormat>
  <MandroidI18n />
  <AndroidSupportedAbis>armeabi-v7a;arm64-v8a</AndroidSupportedAbis>
  <AndroidEnableProfiledAot>false</AndroidEnableProfiledAot>
  <AndroidEnableSGenConcurrent>true</AndroidEnableSGenConcurrent>
</PropertyGroup>

ターゲットアーキテクチャはインテル系はいまやモバイルではほぼ無いということで対象外としました。

ABIごとにパッケージを分けるは、APKではなくバンドルを選択したので選択の必要はありません。

Multi-Dexは64Kを超えるメソッド制限の対象となるコードがないのでチェックしていません。

App Bundleは、次期必須となることをGoogleがアナウンスしているのでapkではなくバンドルを選択しています。
Android App Bundle について

Compile

発行のためのアーカイブ
ビルドとアーカイブはApp Centerで行うのでスキップします。

Googl Play Store API の準備

とりあえず、Visual Studioで行う準備作業は完了しました。

続いて、App CenterからGoogle Playに直接リリースする導線を貼る作業です。

詳しい手順はこちらのサイトを参考にさせていただきました。

App CenterからGoogl Play StoreのAPIを通じてアプリをリリースするには、「Google Cloud Platform」を使用します。

そして、上記ブログにある通り、初回のリリースはGoogle Play Consoleに直接アップロードしておく必要があります。

Google Play Consoleで一通りアプリの登録・公開が完了することで、App CenterからGoogle Play Consoleのアプリを検索し設定を行うことができるようになります。

Google Play Console にアプリを登録

これがハイライトと言えるボリュームのある作業となりました。
色々と準備するものが出てきます。

この作業も、先ほどと同じブログの別の記事を参考にさせていただきました。

意外と面倒だったのは、アプリのスクリーンショットや1024×500指定のフィーチャーグラフィックという宣材画像を用意することですね。

高度な画像レタッチアプリは持っていないので、すべてWindows純正アプリを駆使して用意しました。

また、埋めていかなければいけない項目は、Google Play Consoleのサイドメニューにわかりやすく表示されるので、がんばってオールグリーンを目指しましょう。

Visual Studio App Center の準備

App Centerはとても簡単に利用できるWebツールです。

強いて言うならば、Environment variables を使った部分がやや面倒でした。
DBの接続キーなどシークレット情報をApp Centerのビルド時に差し込むように設定しました。

これも別途記事を書こうと思いますが、基本的にシークレット対象の情報は、デバッグはMobile.BuildToolsというNuGetパッケージを使用し、リリースは上述したようにApp CenterのEnvironment Variablesを使っています。

Environment Variablesは、値を差し込むスクリプトを「appcenter-post-clone.sh」というファイル名でAndroidプロジェクトに用意しておく必要があります。

appcenter-post-clone.sh
#!/usr/bin/env bash

echo "Environment Variables data replace"

##################################################
# variables

# (1) The target file
DirName=$BUILD_REPOSITORY_LOCALPATH
FilenameVariables="$DirName/OneThird.Core/Constants/Variables.cs"
FilenameCosmosdb="$DirName/OneThird.Infrastructure/CosmosDb/CosmosDBConstants.cs"

##################################################

echo ""
echo "######################################################################"
echo " Variables.cs"
echo "######################################################################"
echo " Working directory:" $DirName
echo "       Target file:" $FilenameVariables
echo "######################################################################"

# APP_ID_ANDROID
echo ""
echo "APP_ID_ANDROID - " $APP_ID_ANDROID
sed -i -e "s/\[APP_ID_ANDROID\]/$APP_ID_ANDROID/" $FilenameVariables

# TENANT_ID
echo ""
echo "TENANT_ID - " $TENANT_ID
sed -i -e "s/\[TENANT_ID\]/$TENANT_ID/" $FilenameVariables

# CLIENT_ID
echo ""
echo "CLIENT_ID - " $CLIENT_ID
sed -i -e "s/\[CLIENT_ID\]/$CLIENT_ID/" $FilenameVariables

# SIGN_IN_POLICY
echo ""
echo "SIGN_IN_POLICY - " $SIGN_IN_POLICY
sed -i -e "s/\[SIGN_IN_POLICY\]/$SIGN_IN_POLICY/" $FilenameVariables

# PASSWORD_RESET_POLICY
echo ""
echo "PASSWORD_RESET_POLICY - " $PASSWORD_RESET_POLICY
sed -i -e "s/\[PASSWORD_RESET_POLICY\]/$PASSWORD_RESET_POLICY/" $FilenameVariables

# AD_UNIT_ID_BANNER
echo ""
echo "AD_UNIT_ID_BANNER - " $AD_UNIT_ID_BANNER
sed -i -e "s|\[AD_UNIT_ID_BANNER\]|$AD_UNIT_ID_BANNER|" $FilenameVariables

# AD_UNIT_ID_INTERSTITIAL
echo ""
echo "AD_UNIT_ID_INTERSTITIAL - " $AD_UNIT_ID_INTERSTITIAL
sed -i -e "s|\[AD_UNIT_ID_INTERSTITIAL\]|$AD_UNIT_ID_INTERSTITIAL|" $FilenameVariables

# print out for reference
echo ""
echo "######################################################################"
echo "show result"
cat $FilenameVariables

echo ""
echo "######################################################################"
echo " CosmosDBConstants.cs"
echo "######################################################################"
echo " Working directory:" $DirName
echo "       Target file:" $FilenameCosmosdb
echo "######################################################################"

# COSMOSDB_ACCOUNT_URL
echo ""
echo "COSMOSDB_ACCOUNT_URL - " $COSMOSDB_ACCOUNT_URL
sed -i -e "s|\[COSMOSDB_ACCOUNT_URL\]|$COSMOSDB_ACCOUNT_URL|" $FilenameCosmosdb

# COSMOSDB_ACCOUNT_KEY
echo ""
echo "COSMOSDB_ACCOUNT_KEY - " $COSMOSDB_ACCOUNT_KEY
sed -i -e "s|\[COSMOSDB_ACCOUNT_KEY\]|$COSMOSDB_ACCOUNT_KEY|" $FilenameCosmosdb

# print out for reference
echo ""
echo "######################################################################"
echo "show result"
cat $FilenameCosmosdb

あとは、mainブランチを自動でビルド、リリースするように設定しておきます。
こうすると、Visual Studioで作業ブランチをmainブランチにマージしてリモートpushすると、自動でAzure DevOpsのリポジトリを経由してリリースまで行ってくれます。

まとめ

駆け足ではありましたが、リリースにおいて行った作業全体を書き出してみました。

個々の作業詳細は、それぞれ別途記事で分かりづらかったポイントなどを書きたいと思います。

１日当たりの作業時間が少ないのもありますが、なんだかんだで着手してからリリースまで半年以上の時間を要してしまいました。

ただかかった時間を将来にわたって回収できるような準備をそれなりに出来たと思います。

それは、ドメイン駆動設計、テスト駆動開発、Azure DevOps、App Centerといった素晴らしい手法やツールのおかげです。

バージョン1.0.0で2月13日にリリースをしてからこれを書いている3月4日現在では1.0.4なので、4回バグ修正や細かい追加などでアップデートを配布しています。

まだまだ改善の余地はあると思いますが、それなりの準備のおかげで修正や機能追加もコーディングに集中できるような環境となっています。

それにしてもリリースできたときは本当にうれしかった。
またGoogle Play Consoleから「公開されました」の通知が来たときは一人飛び上がって喜んでしまった。

タイトルの通りではありますが、この度なんとかアプリをリリースするところまで漕ぎつけました。大変だったけど楽しかった。 / “アラフォー初心者だけどスマホアプリを開発～リリースまでがんばってみた | neputa note” https://t.co/owLYbmgUwH

— neputa (@h_neputa) February 13, 2021

これからアプリ開発を行う方にとって、少しでも役立つ情報がありましたら幸いです。

次回は最終回、これまで構築した環境を利用して運用保守をどんな感じで行っているかをまとめてみたいと思います。

長文にお付合いいただきありがとうございます。

はじめてスマホアプリを作ってみた 記事一覧

1. 検討フェーズ（どんなアプリを作るか）
2. 要件フェーズ（どんな要件のアプリにするか）
3. 調査フェーズ（どんな技術を使うか）
4. 設計フェーズ（どうやって作るか）
5. 開発フェーズ（実際に作りはじめる）
6. 公開フェーズ（アプリを公開する）
7. 保守フェーズ（公開から現在まで）