iOS版BLEアプリの作り方【第5回：アプリの開発】
こんにちは。連載企画「iOS版BLEアプリをゼロから作ってみました（企画〜開発〜審査まで）」を担当させていただきました株式会社ERiの澤村です。
企画の趣旨や概要説明はこちらの記事をご覧ください。
第5回目はアプリの開発に関する諸々についてまとめてみました。
iOSにおける開発中アプリの配布方法
開発段階では、アプリの操作感がイメージ通りであるか、ムセンコネクト清水さんに都度確認していただきながら作業を進めていきました。
「apkファイル」でアプリを配布できるAndroidと違って、iOSでApp Store公開前のアプリを配布するのは少々面倒です。開発中のアプリを実機（iPhone）にインストールすることは難しくありませんが、アプリを修正してインストールし直すたびに清水さんにiPhoneを送ったり、送り返してもらうのはかなり大変です。
そこで今回は、アプリのテスト配布ができるGoogleのサービスである「Firebase App Distribution」を使用しました。
このサービスを使うことで、実機のやり取りなしで公開前のアプリをダウンロードできるため、動作確認からフィードバックの流れを非常にスムーズに行うことができました。
事前にAPIの使用可否を確認しておく
iOSアプリ全般の開発について言えることですが、ある機能を実装しようとしたとき、そのAPIは本当に使用しても問題ないかどうかを先に確認しておきます。
deprecatedとされているメソッドを使用すると、今後のOSバージョンアップでアプリがクラッシュする原因になります。
また、App Extensionには多くの制限があり、使用できないAPIがあったり、バックグラウンドタスクの実行時に特定の処理ができないようになっています。
これらを無視して実装すると、審査でリジェクトの要因になり、修正に時間がかかってしまうため要注意です。
Custom KeyboardでのBLE通信について
Custom KeyboardでCore Bluetoothを使用するにあたり、接続やサービス・キャラクタリスティックの探索については特に制限はなく、普通のアプリと同じように使用できます。
Custom Keyboardのプロセスについて
Custom Keyboardのプロセスについて文献がなかったため、生存期間について独自に調査を行いました。
キーボードを起動させたあと、キーボードを非表示にしたり、ホーム画面に戻って5分間放置したりして、プロセスがキルされるタイミングを確認しました。
確認にはXcodeのInstrumentsという機能を使用しました。
結果としては、メモリ不足によってOSからプロセスをキルされない限り、Custom Keyboardのプロセスはバックグラウンドでも生存し続ける事がわかりました。こちらは、Custom Keyboard単体の場合と、Core Bluetoothを組み合わせた場合のどちらでも同じ結果となりました。（なお、調査結果は上記の通りとなりましたが、今後仕様変更される可能性がありますのでご注意ください。）
開発でつまづいたポイント
仕様通りの動きにならず、苦労した点がありました。
当初の仕様では
「収容アプリで選択をキャンセルした際、接続先のLINBLEと接続中だった場合は、同時に切断処理も行う」
となっていました。収容アプリ内の「キャンセルボタン」を押したらすぐに切断されることを期待していたのですが、再度キーボードが表示されるまで切断処理が実行されず、意図したタイミングで切断できないことがありました。
調査したところ、プロセスが一時停止してしまい、アプリの処理が途中で止まってしまっていたことが原因だとわかりました。
アプリでの処理は以下の順序で行います。
- キャンセルを管理するプロパティを用意しておき、収容アプリとキーボードアプリ間でそのプロパティを共有
- （キーボード）プロパティの値を監視
- （収容アプリ）キャンセルされたらプロパティの値を変更する
- （キーボード）プロパティの値が変更されたら通知する
- （キーボード）BLE通信の切断処理を行う
キーボードがバックグラウンドになると、上記のキーボードプロセスで行う処理がすべて一時停止するため、再度キーボードがフォアグラウンドになるまで処理が実行されないようになっていました（上記順序の2以降が全て停止）。
アプリ側からプロセスへの干渉はできないため、当初の仕様では実装が難しいと判断し、切断のタイミングもキーボード側で管理するように仕様変更しました。
ちなみに、プロパティの共有には前回お話したApp GroupsとUserDefaultsを使い、監視にはKVO（Key-Value Observing）という機能を使っています。
同一スレッド内であればUserDefaultsを使って通知を受け取ることができますが、今回のように別プロセスで受け取る必要がある場合はKVOを使うのが良いそうです。
当初想定していた実現方法（仕様）通りに開発するのが基本ですが、実際に開発してみたらうまくいかないこともありますし、開発してみるまでOSやハードウェアの仕様上困難であることがわからないこともあります。
また、「やっぱりこっちの方がいい」とか「この画面だと操作しづらい」とか、開発中のアプリを実際に操作してみることで新たに気づくこともあり、必ずしも当初の仕様通りに作ることがベストの出来上がりになるとは限りません。
よって当初の仕様に拘らず、柔軟に改良した方が良い場合もありますし、時には「実現できること」に合わせて「実現したいこと」を見直すことも必要です。
ただし、仕様変更は当初予定していた工数に影響が出てしまう場合もあるため、追加費用の有無を確認するなど、依頼者と開発側でしっかり相談してから決めるようにしましょう。
アプリの開発まとめ
以上、第5回「アプリの開発」について解説しました。
- iOSで開発中のアプリを配布する場合は「Firebase App Distribution」を使うと便利。
- 使用予定のAPIが使っても問題ないものか、事前に確認しておくとよい。
- 当初想定していた実現方法（仕様）では実現できない場合がある。可能な実現方法に合わせて「実現したいこと」を見直すこともある。「実現したいこと」と「実現方法」を折り合わせることも必要。
Custom Keyboardについて書かれた文献が非常に少なく、社内でもほとんど知見がない中での開発だったので、調査を行いながらの探り探りの開発となりました。
今までは1つのアプリですべて完結していたため、収容アプリとキーボードアプリという、別々のプロセスを考慮しながらの開発は初めてでした。バックグラウンド動作やプロセスについての勉強になりました。
次回、第6回目は「アプリの評価（動作テスト）」についてお届けします。