Titanium mobileからXcode+swiftへと移行

今ではXcode+swiftで普通に開発していますが、その前はTitanium mobileで開発していました。移行しようと判断した理由などを、簡単に書きます。

　

iPad用のアプリは、数年前に開発を始めました。まず最初に、開発ツール選びで迷いました。細かい部分まで作れて、そこそこ作りやすいツールを探したところ、当時はTitanium mobileがベストだと感じたからです。確か、Titanium Studioが出始めた頃だったと思います。Titanium mobileのバージョンが1.6とか1.7ぐらいでしたかね。

プログラミング言語は、お馴染みのJavaScriptです。クラスは使えないものの、オブジェクト指向っぽい書き方ができます。データ型の扱いが緩い感じで、個人的にはあまり好きになれない言語でした。ただ、関数中心という点だけは好きでしたね。

ツールの使い方や、Titanium mobileのAPIは、日本語の情報が出始めていたので、大まかな理解は素早くできました。あとは、TitaniumのウェブサイトにAPIの解説が載ってますから、それを参照しつつ、開発を進めました。

ただし、Titaniumのウェブサイトは最小限の情報しか載っていません。また、その場で見れるサンプルも非常に少ないです(この点は、Appleだとさらに悪いです)。細かな機能を使おうとすると、ウェブ上の資料だけでは目的の機能かどうか判断できませんでした。結局、自分でコーディングして動かしながら、期待したとおりの動作かどうか調べ、目的の機能を探していった感じです。余計な手間を多くかけたなと、今でも思い出します。

　

Titanium mobileを使った開発で、一番困った点はバグです。バージョン1.8ぐらいまでの時期は、描画関係に大きなバグがあり、それを回避しようと小技を多用しました。普通に描画すると大きく乱れて描かれるのが、透明度を設定すると乱れないことを発見して、それを使って回避するという技も見付けました。

画像を描画するアプリの開発では、描画関係のバグは致命的です。画面上での様々な演出を考えたのですが、バグを回避できなければ採用できません。回避方法を試行錯誤したおかげで、７割程度の描画演出が、何とか作れました。本当に苦労したのを覚えています。

Titanium mobileのバグで苦労している間、Xcode+Objective-Cでの開発も並行して勉強し始めました。Objective-Cでの書き方が、どうしても好きになれず、暇なときに勉強という感じでした。そのうちに、Titanium mobileを使ったアプリが完成し、Objective-Cの勉強も中断しました。

その後、iPadのアプリ開発はありませんでした。過去に作ったアプリの小さな改良はありましたが、Titanium mobileをそのまま使って、機能を少し追加しただけです。

私は今まで、色々な言語を経験してきました。もっともマシンに近い言語だと、大型汎用機やパソコンのマクロアセンブラです。他にも、フォートランやCなど古い言語から、Javaなどのオブジェクト指向言語も使いました。そうそう、若い頃はLISPも使ったことがあります。どれでも作ろうと思えば作れますが、今はモダンな言語を選んで使う時代でしょう。Objective-Cは、もう形式が古い言語だと思いますね。

　

こんな感じで時間が流れている間に、Appleからswiftが発表されました。いちおう言語仕様を見てみたら、かなり気になる存在に思えます。これは使ってみるしかないと判断しました。

本格的にマスターするには、ある程度の大きさのアプリを作るのが一番です。過去にTitanium mobileで作った中から業務アプリを選び、すべてswiftで書き直してみました。いろいろな要素が含まれるアプリだったので、これを作り終わったら、かなりのノウハウが蓄積できると考えたからです。

新言語といっても特殊な点は少ないので、マスターするのに苦労しません。もっとも大変なのは、数多くあるAPIの理解です。同じ機能を実現するにしても、Titanium mobileで使っていたAPIと、iOSのAPIでは名前すら違うため、一から勉強し直しとなります。どんなAPIがあるのか調べながら、１つ１つ機能を作っていきました。

ネットで検索すると、Objective-Cで作った例がいくつも見付かります。後で知ったのですが、Objective-Cとswiftでは、APIの定義値の名前などが微妙に違うのです。この微妙に違うという点が曲者で、swiftだと短めに区切ってある名前がいくつもありました。Objective-Cで使う名前が長いと批判されたのを、それを受けての変更だと思います。結果として、コンパイルエラーを消すためにAPI資料やサンプルを探しまくりました。

探しまくったのには、理由があります。Swift専用の短い名前は、Appleのサイト内のAPI資料にも載ってないことも結構あり(これは本当にひどすぎます)、誰かが使っているサンプルを頑張って見付けたりして、本当に余計な手間がかかりました。使っている人は、どこから探し出したのでしょうか。Appleのサンプルにでも載っているのでしょうか。

実際、今でもswift側だけ載っていない定義値の名前があります。もしかして、古いバージョンを見ているのでしょうか。クラス名やメソッド名をGoogleで検索して、トップ近くに出てくるページなので、古いバージョンとは考えられないのですが。

まあ、私の場合は、ソースコードを再利用しやすくライブラリ化するので、一度知ってしまえばOKです。作成した共通ライブラリを呼び出すだけなので、細かいコードを暗記してなくても大丈夫なのです。こうして共通ライブラリを１つずつ作りながら、業務アプリを完成させました。結果として、業務アプリが出来上がっただけではなく、いくつかの共通ライブラリも同時に得られました。

作成した共通ライブラリは、すべての機能を最初から作るのではなく、必要な機能だけを作ります。最初のうちは機能が少ないのですが、利用するアプリの数が増えることで、少しずつ機能が加わります。これからも、どんどんと成長していくでしょう。

　

Titanium mobileは、iOS用だけでなく、Android用のアプリを開発できる点も大きな特徴です。でも、私の周囲には昔からのMacユーザーがばかりで、Androidを持ってすらいない人ばかり。Android用のアプリを作ってくれと言われたことが、一度もありません。そのため、Titanium mobileを使わなくなっても、ほとんど困らないのです。

といった私なりの特殊状況のため、安心してXcode+swiftへと移行できたのでした。使ってみると、やはり純正ツールは一番良いなと感じました。アニメーションなどの機能が簡単に使えるし、珍しい機能を使っても、余計なバグに遭遇する可能性は相当減りました。当たり前ですが、開発ツールは純正が一番ですね。最新バージョンへのタイムラグもないですし。

試しに移植した業務アプリも無事に完成し、たまたま機能追加の依頼があったので、swift版に切り替えることにしました。本番での切り替えも順調に進み、今後はswift版だけをメンテします。

　

新言語のswiftは、使い始めから気に入りました。データの型を厳密にチェックするので、自分の間違いをコンパイル時に見付けやすくなります。厳しい型チェックを嫌う人もいますが、私は大好きです。

この型チェックを積極的に使うように、コーディングしています。具体的には、varやletで変数を宣言するとき、型やクラス名をあえて付けて、自分の理解が正しいかどうか、コンパイラーにチェックしてもらってます。値を入れられる側の変数で型宣言すると、宣言した型に必ずなりますから、以降のソースコードでエラーが出たときも、原因を追及しやすくなります。ソースコードの文字数は増えますが、今後も型宣言をどんどん入れて書こうと思います。

swiftの総評ですが、きっちりと書きたい派の私にとって、非常に良いプログラミング言語だと感じました。もちろん、小さな欠点はありますが、許容範囲に入ってます。いろいろ言われている細かな欠点は、さらに使いやすくバージョンアップしてほしいですね。全体としては、非常に魅力的なプログラミング言語だと思います。この言語が広く普及し、Apple以外の環境でも使えるようになってもらいたいです。