> For the complete documentation index, see [llms.txt](https://docs.wantedly.dev/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.wantedly.dev/fields/apps/apps_platforms.md).

# アプリを提供するプラットフォーム

Wantedlyのサービスを提供するアプリをWebアプリとネイティブアプリの2つに大別し、それぞれの特徴とリリース戦略を説明します。

## Webアプリ

Webアプリは、Webブラウザ上で利用できるアプリです。

デスクトップとモバイルのデザインがあり、閲覧するデバイスや画面幅によってレスポンシブに切り替えます。 一部機能はデスクトップからのみ利用を想定しているためモバイル対応（レスポンシブ等）をしていないケースがあります。 e.g.) 管理画面はデスクトップでの利用想定であるためレスポンシブ対応をしていない

### リリース戦略

Webアプリは、デプロイ容易性が高い特徴があります。

リリースしたい機能や施策ごとにPull Requestを作成し、Pull Requestをマージすることで即座にデプロイされます。 Pull Requestのマージをリリース決定判断とすると、リリース決定判断からユーザーに届くまでのリードタイムは、15分前後です。

デプロイ容易性を活かし、Canary Releaseによりバグの影響範囲を最小限に抑えたり、デプロイのロールバックを行うことでユーザー影響を素早く最小限に抑えることができます。

## ネイティブアプリ

ネイティブアプリは、Webブラウザを介さず、OSのようなプラットフォーム上でネイティブに動作するアプリです。

代表例として、iOSとAndroid向けのネイティブアプリがあります。 他にもiPadやmacOS、Windowsのデスクトップアプリもネイティブアプリに該当します。

プラットフォームごとに最適なデザインが異なります。プラットフォームを横断してデザインする際には、各プラットフォームの特徴を捉える必要があります。

### リリース戦略

ネイティブアプリは、ユーザーがアプリをインストールしてユーザーが利用可能となるため、アプリを配信する必要があります。 基本的にApp StoreやGoogle Playといったプラットフォーマーのストアへ配信し、プラットフォーマーの審査を通ったらユーザーが利用可能となります。

プラットフォーマーの審査は、半日から2日程度かかる場合もあり、コントロールできません。 そのため、リリース決定判断からユーザーに届くまでのリードタイムが長くなります。

ストアでアプリをリリースしても、ユーザーがアップデートをしない限り、新しいバージョンがユーザーに届きません。 一度ユーザーに届いてしまったバグは、バグを修正したアップデートをユーザーがインストールしない限り、ユーザーの手元に残り続けます。

こういった特徴から、ネイティブアプリのリリースは、品質を重要視します。 そのため、リリースごとに1週間程度の準備期間を設けています。 QAの実施期間、デザイナーによる品質確認、QAバグ対応やストアレビュー対応などが含まれます。

## Webアプリとネイティブアプリの違い

ネイティブアプリは、デバイスのハードウェアを扱えたり、プラットフォームのAPIを活用できるため、Webアプリに比べるとできることがかなり広いです。 ただし、AppleやGoogleといったプラットフォーマーの制限を受けます。例えば支払いが発生する場合、プラットフォーマーの手数料が取られるケースがあります。

ユーザーがネイティブアプリを使うには、アプリをインストールするという手間が必要です。 また、ユーザーに新機能を使ってもらうには、アプリをユーザーにアップデートしてもらう必要があります。 Webアプリでは、サーバーサイドの変更でアップデートを提供できます。

ネイティブアプリは、インストールする反面、一度インストールすればユーザーがアクセスしやすいです。 Push通知のような定期的にユーザーを引き付ける要素もあり、Webアプリよりもユーザーエンゲージメントが高い傾向があります。