こんにちは。Sun Asteriskでモバイルアプリエンジニアをやっている、井手 将太(いで しょうた)です。
本記事は、Sun* Advent Calendar 2022 の 6 日目の記事です。
私は、Sun Asterisk でモバイルアプリエンジニアとして iOS と Android のアプリ開発プロジェクトに参画しています。
より魅力的なアプリを素早く世の中に届けるためエンジニアの領域から何ができるか、ということをミッションとして業務に取り組んでいます。
プライベートでは最近、SwitchBot などのスマート家電を Siri や Google Apps Script で制御することにはまっています。
時間帯や日没のタイミングに合わせてシーリングライトの色や明るさを変えるなどして、気取った空間を演出することに凝っています。
今回は、いま私がリリース済みのモバイルアプリをリプレイスするプロジェクトに参画していますので、その際に得た知見を書いてみます。
想定する読者
本記事は、モバイルアプリプロジェクトに関わるエンジニア、デザイナー、プロダクトマネージャーを対象として書いています。
リプレイスの背景
プロジェクトでリプレイスをしている背景は、リリーススピードが遅滞していて、新しい価値を素早くユーザーに届けられないという問題があったためです。
リリーススピードの遅滞の根本原因には、コードの複雑化による修正時の影響範囲の把握しにくさがありました。
リリース時のテストの影響範囲が絞れず、自動テストが構築されていないため、手動によるテストに大きな工数がかかっていました。
また、コードの複雑化やドキュメントの不足による、コード修正のスピード自体の低下も原因にありました。
以上とその他の状況を考慮した結果、コードを 0 から組み立てなおすリプレイスというチャレンジを選択しました。
既存のアプリに関するコードは全く再利用することなく、0 からアーキテクチャーを組み、実装していくという進め方です。
記事を書こうと思った理由
リプレイスにあたり、リプレイス前に実現していたアプリの仕様や体験は維持する必要があります。
ただし、コードが複雑化していることやドキュメントも不足していることから、リプレイス前のアプリの仕様や体験を洗い出す必要がありました。
これに関しては、プロダクトマネージャー、デザイナー、エンジニアで協力して進めていました。
洗い出しする際、特にエンジニアとして関わるからこそ気づきやすい仕様があると感じました。
明確な機能や体験はプロダクトマネージャー、デザイナーからも気づきやすいですが、OS の機能や仕様、ビルドシステムに関わる部分などは、エンジニアとして関わらないとなかなか気づきにくい部分です。
そして、エンジニア視点でこその気づきやすい部分は、今のプロジェクト特有のものではなく、に既存仕様を洗い出しつつリプレイスするようなプロジェクトで再利用可能な知見とも感じました。
この知見を再利用可能にすべく何かしらの形で残しておきたいと考えため、チェックリストという形式で記事に起こしました。
チェックリスト
以下に、エンジニア視点であるからこそ気づきやすい、アプリの仕様や体験に関わる内容を記載していきます。
ビルド設定
アプリをビルドする際の設定は、基本的にはエンジニアしか見ない部分なので、エンジニア視点こそ気づきやすい仕様が多くあります。
アプリストア上のアプリケーション識別子
リプレイス前のアプリと同一のアプリとしてアップデート配信をするために、アプリケーション識別子を揃える必要があります。
揃えない場合、リリース作業でアプリストア[1]にアプリをアップロードする際に、リプレイス前のアプリと同一のものとして登録できなくなります。
iOS では Product Bundle Identifier、Android では applicationId という名前で、プロジェクト設定[2]に記載されます。
ビルド署名
リプレイス前のアプリと同一のアプリとしてアップデート配信をするために、ビルド署名を揃える必要があります。
揃えない場合、リリース作業でアプリストアにアプリをアップロードする際に、電子署名が一致しないエラーによりアップロードできなくなります。
リプレイス前のアプリで利用していた署名のための秘密鍵＆証明書ファイルは、関係者から個別に共有してもらう必要がある可能性もあります。
秘密鍵＆証明書ファイルは秘匿情報であり、セキュリティ上のポリシーからリポジトリに格納されていない場合があるためです。
ビルド署名は、iOS では Code Signing Identity、Android では signingConfigs という名前で、プロジェクト設定に記載されるものです。
ターゲットとする OS バージョン
アプリが利用する OS の機能の動作を制御するために、ターゲットとする OS バージョンを正しく設定する必要があります。
意図せずリプレイス前のアプリと不一致となると、アプリから利用される OS の機能の動作が異なってしまう場合があります。
例えば、画像を選択する、通知の権限を取得する、などの機能に影響が出たりします。
iOS は Xcode のバージョンにより自動的に決定されるため、自動ビルド環境などを組んでいない場合は注意が必要です。
一方、Android では targetSdk という名前でプロジェクト設定に記載されます。
OS との連携
OS の機能を利用する仕様の中には、エンジニア視点でこそ気づきやすい仕様がいくつかあります。
特定形式の URL でアプリを開く機能
他のアプリからの遷移やブラウザー上でのリンクタップからの遷移を制御するために、URL の受け取り定義を正しく設定する必要があります。
これらの機能は、マニュアルに記載がなかったり、知る人ぞ知るマニアックなものになっていることがあります。
開発者視点で受け取り定義がリプレイス前のアプリにあるかチェックし、ある場合は仕様に詳しい人へヒアリングすることが必要です。
iOS の詳細は、「Allowing apps and websites to link to your content」に記載されています。
また、同様の機能を持つ古い技術に関しては、「Defining a custom URL scheme for your app」に記載されています。
Android の詳細は、「アプリ コンテンツ用のディープリンクを作成する」に記載されています。
加えて、Firebase Dynamic Links が上記の機能を iOS と Android 両方で包括的に提供するフレームワークになっているので、そのドキュメントも詳細把握に役立ちます。
(Android 8.0 以上)通知チャンネル
OS 設定内のアプリ毎の通知設定における通知カテゴリーの表示を制御するため、通知チャンネルの定義を正しく設定する必要があります。
意図せずリプレイス前のアプリと不一致となると、特定のカテゴリーを通知オフにしていたユーザーが、アプリアップデート後、オフにしたはずの通知を受け取ってしまう、というケースの発生が考えられます。
詳しい内容は、「通知チャネルを作成して管理する」に記載があります。
(Android 6.0 以上)バックアップ機能
OS が提供するバックアップ機能の有効性を維持するため、バックアップ有効設定を揃える必要があります。
詳しい内容は、「自動バックアップでユーザーデータをバックアップする」に記載があります。
(Android)メインアクティビティのクラス名
Android のホーム画面に存在するショートカットを維持するため、メインアクティビティのクラス名を揃える必要があります。
揃えない場合、リプレイス後のアプリアップデート時にショートカットが維持されず、消えてしまうことがあります。
ホーム画面を表示するアプリ(ランチャーアプリ)によっては、消えないこともあると考えられますが、揃えておいた方が安全です。
揃えるのは、AndroidManifest.xml で android.intent.action.MAIN を受け取るアクティビティのクラス名（以下の例では MainActivity）です。
<manifest>
<application>
<activity
android:name=".MainActivity">
<intent-filter>
<action android:name="android.intent.action.MAIN" />
<category android:name="android.intent.category.LAUNCHER" />
</intent-filter>
OS 設定やデバイスと連動する UI/UX
OS の設定やデバイスと連動する UI/UX は、エンジニア視点でこそ気づきやすい仕様がいくつかあります。
画面回転に対するレイアウト変更
端末を回転させた際のアプリの挙動を制御するため、画面回転に対する挙動を正しく設定する必要があります。
意図せずリプレイス前のアプリと不一致となると、元々横画面でアプリを利用していたユーザーが、リプレイス後のアプリで今まで通り横画面で利用できなくなる、というケースの発生が考えられます。
iOS ではプロジェクト設定の iPhone Orientation と iPad Orientation に定義されています。
Android では AndroidManifest.xml 各アクティビティの screenOrientation に定義されています。
OS 設定に連動した文字サイズ
OS 設定の文字サイズを変更した際のアプリ内の文字サイズも連動して変化する機能を維持するために対応が必要です。
機能が維持されない場合、元々文字サイズを大きくして利用していたユーザーが、リプレイス後のアプリでは文字サイズが小さくなり見づらくなる、というケースの発生が考えられます。
iOS では Dynamic Type という仕組みを利用して文字サイズを設定することで実現できます。
「Human Interface Guidelines の Typography」に詳しい記載があります。
Human Interface Guidelines とは、Apple が iOS アプリに課している UI/UX 設計時の指針が記載されたドキュメントです。
Android では sp (Scale-independent Pixels)という単位により文字サイズを設定することで実現できます。
「各種のピクセル密度をサポートする」に詳しい記載があります。
Bluetooth キーボードを接続した際の挙動
Bluetooth キーボードを接続したときの UI のフォーカス機能を維持するために対応が必要です。
例えば、以下のような仕様が考えられます。
- キーボードの Tab キーを押下した際のフォーカスの移動
- 入力欄からフォーカスを外した際の挙動
- ソフトキーボードの表示領域が消えたことをトリガーに本イベントを発動していると、Bluetooth キーボードの場合上手く動作しない問題が発生しやすい。Bluetooth キーボードの場合、画面のキーボード領域の高さがソフトキーボードと比べて非常に低いため。
(Android 8.0 以上)柔軟な外形変化に対応したアプリアイコン
OS のホーム画面やアプリ一覧などでアプリアイコンの形や表示を維持するために対応が必要です。
詳しくは「アダプティブ アイコン」に記載があります。
その他
上述以外でも、エンジニア視点でこそ気づきやすい仕様がいくつかあります。
エラー・クラッシュレポート
アプリで発生したエラーやフリーズ(ANR)、クラッシュなどを監視する維持するために対応が必要です。
ユーザーに直接見える機能ではないため、見落とされがちな機能となります。
取得するプライバシー情報
アプリストアやプライバシーポリシーで表明が必要なため、正しい制御が必要な箇所です。
例えば、ユーザー登録時における個人情報や端末識別情報、ヘルスケア情報などの取得状況などがプライバシー情報に該当します。
もし取得するプライバシー情報が変化している場合、アプリストアでの表明やプライバシーポリシーの修正が必要になります。
iOS の App Store での表明に関しては、「App Store での App のプライバシーに関する詳細情報の表示」に詳しい記載があります。
Android の Google Play での表明に関しては、「アプリのプライバシーとセキュリティの方針について理解する」に詳しい記載があります。
OSS のライセンス違反
依存するフレームワークやライブラリに関して、ライセンスに違反しないよう注意する必要があります。
例えば、商用リリースの場合は基本的にソースコードの公開はしないことが多いので、コピーレフトのライブラリが含まれていないかという点をチェックする必要があります。
また、アプリ内にライセンス表記を要求するものがほとんどですので、利用しているもの全てのライセンス表記が含まれているかを確認する必要があります。
まとめ
アプリの仕様や体験を良くしていくためには、プロダクトマネージャーやデザイナー、エンジニアが各々の専門性を発揮しつつ協力することが不可欠です。
技術視点で細かい仕様漏れを防ぎ、体験を良くしていくというのは、エンジニアだからこそできることだと考えますので、これからも同様の知見があればどんどんまとめていきたいです。
さて、Sun* Advent Calendar 2022 の明日の記事は、デザイナーのせーなさんによる記事です。
本 Advent Calendar で最初のデザイナーによる記事ですので、ぜひお楽しみに。
Discussion