Skip to main content

Native Application

Overview​

ネイティブアプリケーションとは、特定のプラットフォームやOS向けに開発されたアプリケーションのことを指す。
このアプリケーションは、プラットフォーム固有の言語（iOSであればSwiftやObjective-C、AndroidであればJavaやKotlinなど）を使用して開発されており、そのプラットフォームの機能やリソースに直接アクセスできる。
ネイティブアプリケーションは、特にパフォーマンスやデバイスのハードウェア機能を活用したい場合に選ばれることが多く、次のような特徴がある。

  • 高いパフォーマンス プラットフォーム専用に最適化されているため、処理速度が速く、アニメーションもスムーズ。
  • デバイス機能へのフルアクセス カメラやGPS、通知機能など、OSの持つハードウェアやソフトウェア機能にアクセス可能。
  • オフライン動作のサポート 多くのネイティブアプリは、インターネット接続がなくても利用できる。

ネイティブアプリケーションは、ユーザー体験が重視される分野で多く採用されており、特にゲームやSNS、エンタープライズ向けアプリなどで普及している。
しかし、開発にあたってはそれぞれのOSごとに別々のコードベースが必要になるため、リソースやコストがかかることもある。

ネイティブAPIのバージョンと最低サポートOSのバージョン​

iOSアプリ、Androidアプリとしてビルドする際にバージョンを指定する。

  • 最低サポートOSのバージョン
  • ビルドSDKバージョン
  • ターゲットSDKバージョン（Androidのみ）

最低サポートOSのバージョン​

最低サポートOSのバージョンはアプリをインストールできる最低のOSバージョン。
このバージョンを低く保つことでより多くのユーザーがアプリを利用できることになりますが、その分古いOSでの挙動についても考慮する必要がある。
iOSについてはAppleのデベロッパーサイトにてバージョン別のシェアが公開されており、この数値を参考にするとよい。
AndroidについてはAndroid Studioの新規プロジェクト作成時にバージョン別のシェアを確認できる。

最低サポートOSのバージョンを決める際には、いくつかの要素を考慮する。
一般的には次のような基準で決定されることが多い。

  1. ユーザーシェア 対象プラットフォームのOSバージョン別のシェアを確認する。
    例えば、iOSやAndroidの各バージョンの利用割合は公表されており、対象ユーザーのほとんどが使用しているバージョン以上をサポートするのが一般的。
    古いバージョンのユーザーが少ない場合は、それらをサポート対象外にすることが多いです。
  2. プラットフォームの公式ガイドライン AppleやGoogleは、定期的に古いOSバージョンのサポートを終了するため、最新のベストプラクティスに従うことが推奨されている。
    特に、App StoreやGoogle Play Storeでの申請には最新のOSバージョンに対応したSDKが必要になる場合もある。
  3. 使用するサードパーティライブラリ 使いたいライブラリが特定のOSバージョン以降でしかサポートされていない場合、そのバージョンを最低限サポートしなければならない。
    また、新しいOSでのみ使える機能を活用したい場合も、最低サポートバージョンを上げることがある。
  4. アプリのパフォーマンス 最新OSでは性能が最適化されていることが多く、パフォーマンス重視のアプリでは新しいOSバージョンをサポート対象とする傾向がある。

ビルドSDKバージョン​

ビルドSDKバージョンはその名のとおりビルド時に使用するSDKのバージョンで、このバージョンを上げることで新しいネイティブAPIを利用できる。
iOSのビルドSDKバージョンの設定iOSには実はビルドSDKバージョンという考え方はない。
Xcodeのバージョンによって使用できるAPIが変わる。
Xcodeのバージョン変更により、Flutterアプリの挙動が大きく変わることはまれですが、バージョンを上げる際は慎重に動作確認する。
AndroidのビルドSDKバージョンの設定AndroidのビルドSDKバージョンはアプリのビルド構成ファイル android/app/build.gradle に記述する。
androidエントリのcompileSdkVersionが該当する。

caution

このバージョンを上げると古いOSで挙動が変わる場面もあるため注意が必要。
この挙動の変化は特にAndroidに多く見られる。

ターゲットSDKバージョン​

ターゲットSDKバージョンはAndroidのみに存在する概念。
アプリを動作させたいSDKバージョンを指定する。
SDKのバージョンによって見た目や挙動に違いが生じるためどのバージョンで動作させる想定なのかを明示する設定になる。

info

Google Play Storeでは、このtargetSdkVersionを毎年新しいバージョンに引き上げることを必須要件として開発者に課している。
targetSdkVersion を更新しなければ、アプリをアップデートできなくなったり、新しいOSのAndroidからはストアでアプリを検索できなくなったりする。

アプリの設定変更​

アプリ名​

ホーム画面に表示されるアプリ名はiOS/Androidネイティブ部分の設定。

アプリアイコン​

iOS​

デフォルトではさまざまなサイズのアイコン画像を要求される。
xや3xなどのバリエーションは、Flutterのアセットと同じくディスプレイの解像度によって使い分けられる。
大きな画像を1つ指定して自動的にリサイズさせることも可能で、右側のインスペクタで「Single Size」を選択する。
この場合、細かな線が消えてしまうこともあるので注意。

Android​

Androidのアイコンはシンプルな画像のほか、バックグラウンドとフォアグラウンドの2つのレイヤで構成されるアダプティブアイコンと呼ばれるものがある。
アダプティブアイコンはOSバージョン8.0以降で導入され、Androidのモデルによってアイコンの表示が変わる。
円形、角丸四角形、操作によってアイコンだけが動いて見えるアニメーションが加わるなどさまざま。
アダプティブアイコンの作成は任意だが、設定されているとアプリのブランディングに役立つ。

スプラッシュ画面​

スプラッシュ画面とは、アプリ起動時に一瞬表示される画面のこと。

iOSとAndroidで異なるスプラッシュ画面の位置付け​

スプラッシュ画面はiOSとAndroidで位置付けが異なる。
iOSはアプリがすばやく起動することを重視している。
アプリの最初の画面と似たスプラッシュ画面を表示することで、すばやく起動したように感じさせることが推奨されている。
表示時間をコントロールできない。 表現やブランディングの機会ではなく、文字を含めることは避けるようにガイドラインで定められている。

一方、Androidのスプラッシュ画面はアプリアイコンを中央に表示する標準レイアウトが提供され、ブランディングを意識して、アニメーションや色をカスタマイズ可能となっています。表示時間をコントロールすることも可能。

アプリのID​

iOSもAndroidもそれぞれアプリを一意に識別するIDがある。

  • iOSはBundle ID
  • AndroidはApplication ID

このIDは他のアプリと重複しないように自分が所有するドメインを逆順にしたものを使用するのが一般的。
たとえば、所有するドメインが example.com であれば com.example.myapp のようになる。

tip

プログラムがまったく同じアプリでもアプリIDが異なると別のアプリとして扱われる。
これを逆手にとり、検証環境のサーバに接続するアプリと本番環境のサーバに接続するアプリを1台の端末に共存させることができる。

アプリの配布とコード署名​

App StoreやGoogle Play Storeでアプリを配布するには、アプリにデジタル署名をする必要がある。
筆者の考えるモバイルアプリの鬼門はこのコード署名。
コード署名とは、アプリの開発元が正しく、配布されたアプリが改ざんされていないことを証明するしくみ。
秘密鍵を使ってアプリに署名し、その秘密鍵とペアになる公開鍵の証明書をアプリの中に埋め込む。
こうすることで、アプリが改ざんされていないか検証できる。

iOSとAndroidとで証明書の取り扱いがまったく異なり、Flutterエンジニアにとっては敷居が高いものとなっている。
なお、AppleとGoogleの開発者アカウントが必要となる。
Appleの開発者アカウントとGoogleの開発者アカウントはそれぞれ以下から登録できる。

https://developer.apple.com/jp/programs/
https://developer.android.com/distribute/console