DropTalk | HMDT Blog

カテゴリー : DropTalk

iOSアプリをWindowsに移植してみた


何度もここに書いてるけど、HMDTはDropTalkっていうアプリにかなり力を入れてやっています。もう、7年目になるのかな。最初はiPhone向けに開発して、iPadに移植してプチブレイクした。去年はAndroidにも移植したけど、これはぜんぜんダウンロード数伸びなかったねー。iPadの1/10以下で、誤差の範囲内でした。

で、今年はWindowsに移植しました。ずっと要望は多かったんですよ。ようやく出せました、という感じです。先週あたりからMicrosoftストアにも登場しています。ダウンロード数伸びてくれるといいんだけど。

今回、初めてiOSアプリをWindowsに移植してみたんで、そのときの技術的な話を書いてみたいです。

マシンと開発環境の整備

Windowsへの移植を始めたのは、ちょうど一年前くらいかな。2016年の12月あたりからです。まずヨドバシカメラにWindowsマシンを買いに行くことから始めました。個人で使うWindowsマシンを買うのは、初めての体験だった。キャーキャー言いながら悩んで、ASUSのノートPCに決めました。安かったから。15万くらいだったかな。一緒に行った社員の人は、Surface選んでました。

入っていたOSは、Windows 10。この年はWindows 10への無料アップグレードが終わるとかで、その告知が執拗に出てくることがニュースになってたので、噂では知ってたけど、触るのは初めてでした。これが10か、と感動することしきり。そういや、その前に触ったWindowsはなんだっけ? と、思い出してみたら、Vistaでした。Vista以来のWindowsになります。

続いて開発環境を整えます。IDEは、Visual Studioで決まり。フレームワークは何使えばいいのかな、と検索してみたら、なんかいっぱいあるのね。Win32とか、Windows Formとか、WFPとか、UWPとか。どれがどれで、何が何よ?! 調べれば調べるほどわからなくなるので、こっちの条件を羅列してみました。

  • 新規に作る(レガシーコードはない)
  • いわゆるネイティブアプリにする
  • ストアで配布したい
  • タブレットPCで動かしたい(タッチ必須)

以上の条件から絞り込むと、どうやらUWPになるらしいです。この中ではいちばんモダンになるのかな。Windows 10より前では動かないみたいだけど、うーん、まぁいいやということで決めました。ほんとは、DropTalkのターゲットは教育市場なので、Windows 10への移行はものすごく遅れているのでちょっと厳しいです。でも、これから5年とか10年とかサポートし続けていくものなので、中途半端なレガシーは切り捨てることにしました。

ちなみに、Xamarinは最初から選択肢に入ってませんでした。クロスプラットフォームは幻想だと確信してるので。

プログラミング言語

プログラミング言語は、C#にしました。ずっとC言語由来の言語ばっかり触っているので、C#も30分程度勉強したら書き始めることできました。印象としては、モダンさの度合いとしては、Objective-C以上Swift以下ってとこですか。ラムダ式とかLINQとか使い出したら楽しくなってきた。でも余計な記述が多くなって、言語全体が古臭くなって来ている感は否めないですね。そろそろ、後継言語が欲しいです。SwiftやKotlinレベルのものを。C##とかいう名前になるのか。それか、KotlinをUWPに対応させた方が速いのかも。

UWP

GUIフレームワークとしてのUWPは、最初はとにかくXAMLにとまどいました。ユーザインタフェースは、XMLベースのXAMLっていうフォーマットで記述します。Visual Studioに付属するビジュアルエディタを使おうとしたのが失敗でしたね。Interface Builderみたいなものかと期待したけど、ぜんぜんダメだった。XML直接手書きに切り替えてからは、サクサクと開発進むようになりました。

あと、見た目のカスタマイズが厄介ですね。UWPでは、見た目のかなりの部分まで、XAMLで記述されています。だから、このXAMLを変更することにより、柔軟に、そしてコーディングなしでカスタマイズできる、ってのが売りです。でも、なんでもできるってことは、やらなきゃいけないこともたくさんある、ってことにつながります。ちょっとした変更をするにも、なかなかに記述量が多くて大変でした。

もうひとつとまどったのは、View Model。UWPは全体的に、データはView Modelの形式で与えることになってます。Cocoaでいうと、Bindingみたいなもんですね。モデルを管理すれば、ビューの更新は自動的に行われる、素晴らしい仕組みです。でもこれ、便利なのはその仕組みの枠内だけで使っているときだけなんですよ。ビューの表示の仕方をちょっと変えようとすると、とたんにイバラの道が待っています。できないわけじゃないんだけど、書き換えないといけないところが多すぎる。これだったら、View Model使わないで、ベタにViewを触った方が圧倒的に速いよ、ってのがしょっちゅう出てくる。

というわけで、UWPはXAMLとかView Modelとか、かなり洗練されたアーキテクチャを備えるんだけど、その仕組みから外れると途端に使いにくくなります。UWPの枠内で、素早く簡単なアプリを作りたいときにはこれでいいんですよ。でも正直なところ、それで収まるアプリなんてほとんどないです。結局、XAMLやView Modelの枠に縛られないようにプログラムを書いていきました。なんだかなー。高度に統合されたものよりも、緩やかに連携するものの方が、アプリ作る上では使いやすいんだよね。

AFTERWARD

そんなことで、どうにかリリースできるものを作り上げました。思ったより楽しかったです。違う世界を体験すると知見が広がるので、iOSアプリを作っている人もトライしてみるといいと思います。

ただね、いまどきWindows PCで何かやりたい人は、かなり少数派だよね。iPhoneとiPadの方が高機能で高効率になっちゃったから。DropTalkは、いまだ教育分野ではWindows PCを使っているという背景があるから移植したけど、それ以外の分野では必然性が薄いよね。そこがいちばんの問題かな。

DropTalkのApple Pay対応の話:審査編


先日の投稿に書いたように、DropTalkをApple Payに対応させました。その時の流れを書いておきますね。

そもそも対応させようと思い立ったのは、去年の10月25日、Apple Payが日本でスタートした日。ご多分にもれず、私もそそくさと手持ちのiPhone 7にSUICAを登録しまして、これでオサイフケータイみたいなことができるぜ、へっへー、と早速コンビニでお昼ご飯を買ったりしてました。それを食べながらiPhoneで関連ニュースを眺めていると、なにやらApple Payをアプリに組み込むことができるらしいと。このときに初めて認識しました。ふーん、でもうちの会社には関係ないかなー、と一瞬思ったけど、そういやTシャツ売ってたや! これをネタに、Apple Pay対応しよう!

早速事務所に戻って社員の人と話して、ひとしきり盛り上がりました。よし、じゃ対応することで決定ね。とりあえず契約周りは私がやるから、実装の方はよろしく〜。ま、そんなに手間かからないでしょ。。。と、この時点では思ってたのですが、実際はストア画面(商品紹介、カートなど)を新規に作らないといけないので、結構な時間がかかりました。

契約の方は、決済サービスプロバイダーとしてPAY.JPを選択して、手続き開始。開発者登録はすんなりできて、どうやら本番申請というものをやらないといけないらしい。うーむ、よく分からんけど実装が終わってから申請するか、と考えてそのまま保留。今から考えると、この本番申請を早めにやっておけばよかったんだと思う。

で、実装が終わったのが11/11。よーし、本番申請するぞ! どうやら申請の手順は、

  1. VISA、MasterCardの審査
  2. 追加のカード会社(JCB、American Express、Diners Club、Discover)の審査
  3. Apple Payの審査

という流れになるらしい。なんでクレジットカード会社の審査が2つに分かれているのかは不明。Apple Payの審査が、その後になっている理由も不明。そもそも、審査で何を審査しているのかもよく分からない。こちらから提供する情報は会社の基本情報くらいで、アプリの提出とかそういったものはなし。

審査申請した後は、特にやることなしで待つだけ。11/21に、VISAとMasterCardの審査を通過したと連絡あり。続いて12/5に、残りのカード会社の審査を通過。そして12/21に、待ちわびたApple Pay審査通過のお知らせが! 申請してから一ヶ月と10日でした。

よーし、早速アプリ公開するぜ! と、思ったものの、12/23からiTunes Connectはクリスマス休暇で審査停止。さらに12/28からは弊社冬休みで業務休止。トラブった時のことを考えると、これは年明けの審査提出かねぇ、ということで少し待機しました。明けて翌年、無事アプリの審査通過して、1/5に公開できました。

ほんとはApple Payブームに沸いている最中に公開できればよかったけど、様々な審査が必要だったので、まぁ、こんなものでしょうか。審査自体は、こちらに何の連絡もなくて、何をやっているのか本当に不明。でも無事通過したので、簡単に固定料金なしでクレジットカード決済をやりたい会社さんにはオススメです。

DropTalkをApple Payに対応


iOS版DropTalkの新しいバージョンを公開しました。バージョン番号は3.1.4。マイナーバージョンアップに見せかけて、大きい機能追加があります。Apple Payに対応しました。

指先一つで決済できるApple Payは、SUICAとして電車に乗れるだけでなく、アプリに組み込むこともできます。これで、アプリ内部で様々な物販が行えるんですね。

いや、ちょっと待て。アプリの決済の仕組みって、In App Purchaseもあるよね? どう違う? これはAppleによれば、アプリ内で使うゲームのアイテムみたいなものや、機能制限の解除などは、In App Purchaseを使え。それに対して、物理的な何かを販売するときはApple Payを使え。と、いう住み分けだそうです。

DropTalkでは、今までWebサイトの方で、製本したマニュアルや、Tシャツなんかを販売していたんです。これらをApple Payで買えるようにしました。

新しく追加した、「ストア」タブから買えますよ。リンゴマークの「Pay」ボタンが眩しい。

アプリに組み込む場合は、Apple Payプログラミングに加えて、決済業者さんと契約をする必要があります。いくつかあるんですが、今回はPAY.JPさんにお願いしました。理由は、固定料金がかからないことと、ダッシュボート画面が綺麗だったから。開通までに時間はかかりましたが、特に大きなトラブルもなく開始できました。

Apple Payアプリだと、ネットでの買い物の手間が劇的に減りますね。確かにこれは革命的かもしれない。これで売り上げが少しでも伸びてくれるといいんだけど。