06.はじめてスマホアプリを作ってみた(公開フェーズ)
初稿:
更新:
- 15 min read -

記事の概要
こちらの一覧の6つ目、「公開フェーズ(アプリを公開する)」の記事。
- 検討フェーズ(どんなアプリを作るか)
- 要件フェーズ(どんな要件のアプリにするか)
- 調査フェーズ(どんな技術を使うか)
- 設計フェーズ(どうやって作るか)
- 開発フェーズ(実際に作りはじめる)
- 公開フェーズ(アプリを公開する)【今回】
- 保守フェーズ(公開から現在まで)
ダイジェストで読みたい方はこちらの記事を。
アラフォー初心者だけどスマホアプリを開発~リリースまでがんばってみた【Android・Xamarin.Forms】
あらすじ この度、素人ながらスマホアプリ開発に挑戦してみた。今回の記事では概要と経緯について書き綴ってみたい。実際に行った作業の詳細は、全7回に分けた記事を別途作成
インストールはこちらから。

はじめてのスマホアプリ開発 公開フェーズ
前回は、実装作業の工程で行ったことについて書いた。
今回はいよいよ作ったアプリを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デベロッパーアカウント」に登録する必要がある。
登録は、上記リンクの「ステップ1」にある「デベロッパー アカウントに登録」のリンクから行うことができる。
この作業自体は簡単。
注意として、$25の登録料がかかること。
これは一度だけ発生する初期費用のようなもの。
ちなみにiPhoneアプリの場合は年間サブスクリプションで11,800円かかるらしい。
リリースに向けたアプリの準備

Xamarin.Formsでの開発用には一応、このような公式ドキュメントがある。とりあえずひと通り試してみた。
アプリケーション アイコンを指定する
今回、「Prism」というMVVMでXamarin.Formsを実装するパッケージを使用したため、アイコンはデフォルトを置き換えるだけで済んだ。
イチから作った場合や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」しておく作業が必要で。
とりあえずは未選択としておいた。
後日談として、APK圧縮にチャレンジし敗れ去る話をまとめている。
AndroidアプリのAPKサイズを圧縮しようと試みて敗れる話【Xamarin.Forms / Linker / R8 Shrinker】
『Xamarin.Formsで開発したAndroidアプリのパッケージサイズを圧縮しようと「Linker」「d8/r8」コンパイラを駆使したが、敗北する』、です。現在リリースしているバージョン1.0.4の時点で、ダウンロードサイズは34MB、インストールしたアプリサイズは49.45MBと、アプリの内
アプリケーションを保護する
仮に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ではなくバンドルを選択した。
Googl Play Store API の準備
とりあえず、Visual Studioで行う準備作業は完了。
続いて、App CenterからGoogle Playに直接リリースする導線を貼る作業。
詳しい手順はこちらのサイトを参考にした。
App Centerを通じてXamarin.Formsで作ったAndroidアプリをストアに公開する - shuhelohelo’s blog
docs.microsoft.com Googleデベロッパー登録する 外部ツールからのAPIアクセスを許可する App CenterからGoogle Play Storeにアプリを公開するために,Googl Play StoreのAPIを外部ツールが利用できるようにする必要があります. まずはGoogle Play Consoleにログインします. 左側に設定という項目があるのでそれを選択します. 次にデベロッパーアカウント > APIアクセスを選択します. 新しいプロジェクトを作成ボタンを押します. 自分のGoogle Play ConsoleとリンクしたAPIプロジェクトが自動で作成され…
App CenterからGoogl Play StoreのAPIを通じてアプリをリリースするには「Google Cloud Platform」を使用する。
そして上記ブログにある通り、初回のリリースはGoogle Play Consoleに直接アップロードしておく必要がある。
Google Play Consoleでひととおりアプリの登録・公開が完了することで、App CenterからGoogle Play Consoleのアプリを検索し設定を行うことができるようになる。
Google Play Console にアプリを登録
これがハイライトと言えるボリュームのある作業となった。
色々と準備するものが出てくる。
この作業も、先ほどと同じブログの別記事を参考にさせていただいた。
Google Play StoreにAndroidアプリを公開する メモ - shuhelohelo’s blog
このへんはこちらの記事がとても参考になりました. kuneoresearch.com 「Google PlayにAndroidアプリを公開」を押します. 「アプリの作成」というダイアログが表示されるのでアプリ名などを入力していきます. アプリの説明などを入力します. アプリのスクリーンショットをアップロードする必要がありますが,画像のサイズやアスペクト比など条件があるのでちょっと手間です. 私はストア用のスクリーンショットをアップロード条件を満たすようにいい感じに調整してくれるサービスを使いました. apptoolkit.io 次にフィーチャーグラフィックという画像を作らなければならないが,こ…
意外と面倒だったのは、アプリのスクリーンショットや1024×500指定のフィーチャーグラフィックという宣材画像を用意すること。
高度な画像レタッチアプリは持っていないため、すべてWindows純正アプリを駆使して用意した。
また、埋めていかなければいけない項目は、Google Play Consoleのサイドメニューにわかりやすく表示される。がんばってオールグリーンを目指す。
Visual Studio App Center の準備
App Centerはとても簡単に利用できるWebツールで。
Visual Studio App Centerの始め方 - Download as a PDF or view online for free
強いて言うなら、Environment variablesを使った部分がやや面倒だった。
DBの接続キーなどシークレット情報をApp Centerのビルド時に差し込むよう設定した。
これも別途記事を書こうと思うが、基本的にシークレット対象の情報は、デバッグはMobile.BuildToolsというNuGetパッケージを使用、リリースは上述したようにApp CenterのEnvironment Variablesを使った。
Environment Variablesは、値を差し込むスクリプトを「appcenter-post-clone.sh」というファイル名でAndroidプロジェクトに用意しておく必要がある。
#!/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のリポジトリを経由してリリースまで行ってくれる。
まとめ

駆け足ではあるが、リリースにおいて行った作業全体を書き出してみ。
1日当たりの作業時間が少ないのもあるが、なんだかんだ着手してからリリースまで半年以上の時間を要してしまった。
かかった時間を将来にわたって回収できるよう準備をそれなりにできた気はしている。
それは、ドメイン駆動設計、テスト駆動開発、Azure DevOps、App Centerといった素晴らしい手法やツールのおかげでもある。
バージョン1.0.0で2月13日にリリースをし、これを書いている3月4日現在では1.0.4。都合、4回バグ修正や細かい追加などでアップデートを配布した。
まだまだ改善の余地はあると思うが、それなりの準備のおかげで修正や機能追加もコーディングに集中できるような環境となっている。
それにしてもリリースできたときは本当にうれしかった。
またGoogle Play Consoleから「公開されました」の通知が来たとき、一人飛び上がって喜んでしまった。
これからアプリ開発を行う方にとって、少しでも役立つ情報があればうれしい。
次回は最終回、これまで構築した環境を利用して運用保守をどんな感じで行っているかをまとめてみたい。
長文お付き合いいただき感謝。