17
15

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

ネクストスケープ配信事業本部AdventCalendar2017の4日目担当の坂本です。
新しいアプリを開発する場合、まずはアプリのリリースを目標にするかと思いますが
残念ながらアプリのリリースはアプリ開発の終わりではありません。

サービスが続く限りは機能追加や最新OSへの対応を行なっていく必要があります。
サービスイン後に後悔しないために、サービスイン後の作業を見据えたアプリを作りましょう。

(12/4 : 追記予定の項目は順次更新します!)

ユーザーエージェント(UserAgent)をカスタムする

サーバーと通信して動くアプリの場合、呼び出し元を特定する情報としてUserAgentを渡しているかと思いますが
アプリリリース後を見据えてUserAgentには必要な情報を含めるようにしましょう。

UserAgentに含める情報の例

  • アプリケーション名
  • アプリバージョン
  • OSバージョン
  • デバイス名
  • デバイスのビルド番号
  • UUID(未ログインユーザーの特定やユニークユーザー集計のために利用する)

UserAgentは後述の全ての項目の助けとなるため必ず設定しておきましょう。

適切なエラーコードを定義する

まず、アプリリリース後の開発者を悩めるのは以下の問い合わせです。
「エラーが発生しているので原因を調査して下さい」

この時に適切なエラーコードを定義しているかいないかで調査の難易度が激的に変わります。

[システムエラー]
問題が発生しました。

なんて通知は何の役にも立たないので必ず以下のようなエラー表示にします。

[エラーコード : 200-12345] ← 解決の糸口となるエラーコードを含める
通信エラーが発生しました。しばらく待ってやり直してください。 ← 原因と解消手順があれば教えてあげると問い合わせを減らせる

また、サービスを続けていくうちにエラーコードは増えていきます。
エラーコードを定義する際はエラーコードが増えることを意識して連番は避けましょう。
けっして、iTunesのエラーコードは参考にしてはいけません。
https://support.apple.com/ja-jp/HT203174

エラー情報を送信する

エラーコードだけでエラー原因を特定するのは難しいため、エラー解析に役立つ情報を送信するようにしましょう。
「OSバージョン」「アプリバージョン」「デバイス名」「内部エラーコード」「WiFi or 3G/LTE」「ストレージ残量」など

よくクラッシュレポートは送信しているけど、エラー情報は送信していないというアプリがありますが
アプリのエラーはクラッシュを伴わないエラーが大半のためエラー情報の送信はしておいたほうが吉です。
ただし、ユーザの中にはエラー情報の送信を嫌がる人も多いため「エラー情報を送信して良いかの確認」を取ることも忘れずに。

強制バージョンアップ機能

多くのユーザはアプリのバージョンアップを望んでおりませんが
サービスを進めていくうちにどうしても「古いバージョンのアプリを排他したい」状況が出てきます。
そうした状況を見据えて、強制的にバージョンアップする機能を実装しておきましょう。

強制的にバージョンアップすると言っても、一般的なアプリにはそんな権限はないため
「特定のアプリに最新バージョンのインストールを促す通知を出す」という機能を実現します。

強制バージョンアップを行う際に守らないといけないことは、古いバージョンのアプリからの利用を排他することです。
けっして抜け漏れが無いように慎重に実装しましょう。

実装時に注意する点

  • バージョンアップを促す理由は多岐に渡るため「バージョンアップするかどうかの判断」は必ずサーバー側で行う
  • 「起動時」など特定のタイミングのみでのチェックは危険。なるべく複数の箇所でチェックすること
  • アプリを立ち上げ続けているユーザーのことを考慮する
  • バージョンアップのチェック処理がエラーや圏外状態でスキップ出来ないように注意する
  • 強制バージョンアップの使いすぎに注意する(レビューが荒れます)

全てのユーザに対して必ずしも「最新のアプリ=安定版」とはならないため強制的にバージョンアップを促す前に
ユーザが任意にバージョンアップ可能な期間を設けると良いかと思います。

メンテナンス中の利用を考慮する

サーバーと通信して動くアプリの場合、メンテナンスの考慮が必要です。
ユーザがアプリを利用しようとした際には「メンテナンス中です」という通知を出し、
メンテナンス中でも開発者であればアプリの動作確認を行えるようにメンテナンス中にアプリを利用する方法を用意しておきましょう。

慎重に選定したライブラリのみを利用する

(追記予定)

ポリシーの無い画面回転は実装しない

(追記予定)

ビルド環境は自動化する

(追記予定)

開発中のアプリケーション配布を自動化する

(追記予定)

テストは自動化する

(追記予定)

17
15
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
17
15

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?