マイクロソフト社よりWinObjC ((コードネーム”Project Islandwood”)) がプレビュー版ながらリリースされており、Windows 10とVisual Studio 2015 ((Expressを除く)) をインストールしていれば誰でもiOS向けアプリのプロジェクトをUniversal Windows Platformアプリとしてビルドして実行できるとのことであるが、現時点では修正しなければ箇所が多く、アプリの種類にもよるがまだ実用に耐えられない状態である。個人的にWinObjCを使ってみて気になった点を述べてみたい。
デフォルトではプロパティーはreadonly?
OS X及びiOSのObjective-Cのプロパティーでは、明示的にreadonlyを指定しないと、readwrite属性になるが、WinObjCではバージョン0.1プレビューの段階においてはデフォルトではreadonlyになる模様である(readwriteにするには明示的に設定する必要がある?)。この違いのせいで、OS X及びiOSでは問題なくビルドが通ったのにWindowsでは通らないという事例が相当数出ることが想定される。
なお、冗長だが、すべてのプロパティーにreadonly,readwriteを指定した場合やメソッドなどについてはそれほど実害はないと考えられる。
現時点ではフレームワークが不十分
バージョン0.1プレビューの時点ではFoundationやUIKit、OpenGLES、OpenALなどの最低限のライブラリーはあるものの、十分にフレームワーク類やライブラリー類が揃っているとはいえず、基本機能のみを使ったアプリであればそれほど苦労せずに開発できる可能性はあるものの、SNSサービスの連携機能やCoreDataなどの機能の多くがまだ実装されていないため、これらを使うアプリについては現時点ではUniversal Windows Platformに対応させるには外部のライブラリーで代替するか、フレームワークが届くのを待たなければならない。
とはいえ、これについてはまだ始まったばかりであるため、iOS向けアプリの機能の相当数はWindowsでも移植可能になるのではと考えられる。
Interface Builder関連部分は使い物にならない
現時点ではStoryboardは未対応、それを使用したアプリは真っ黒になってしまい、動作しない。
従来のxibファイルについては、xib2nibでnibファイルにコンバートされるのだが、それもクラッシュしてしまい、エラーになる ((Xib2Nib.exeを起動しようとしてクラッシュする。 Xib support #27 – GitHubも参照のこと。)) 。ビルドが完了扱いになっても正常にnibファイルが生成されていないので、画面は真っ黒のままである。
これらから、現時点ではInterface Builder関連は未完成で、実用には全く耐えられない状態となっている。特にXcode 6系ではStoryboardがデフォルトになっているため、現状はかなり厳しいといえる。
POSIXシステムコールに要注意
これはObjective-Cには直接関わらないことだが、POSIXシステムコールを多用しているアプリの場合、WinObjCを使ったUniversal Windows Platformへの移植は困難を極める可能性が非常に高い。iOSはOS Xと同じく、Unix系ベースのOSであり、POSIXシステムコールの多くが使えるため、Unix系向けに作られたコードを動かす点でもそれほど苦労しないという利点がある。
しかしながら、Universal Windows Platformでは基本的にはWindows APIあるいは.NET Framework、もしくはWindows Runtimeが基本になり、POSIXのシステムコールは基本的に使えない。
ほぼすべてObjective-C ((それもFoundationやUIKitで完結しているものであれば)) で書かれたコードであればまだしも、C言語などでPOSIXシステムコールが多用された場合、それをWindows APIに対応させる必要性があり、それで難航すること可能性が高い。
最後に
ここまで、当方がWinObjCのプレビュー版を使用しての感想及び気になった点を述べてみた。ライブラリー・フレームワーク類が不十分でまだ実用に耐えられるレベルではないが、これが正式版になった時、従来iOS向けに作っていたアプリを、基本的にCocoa Touchフレームワークのみを使っているなどの条件を満たせばそれほど改修を必要とせずにUniversal Windows Platformへと移植できる可能性があるといえる。
しかしながら、iOS向けのコードによっては、POSIXシステムコールを多用しているものもあり、その場合はWindows APIあるいは.NET Framework、Windows Runtimeなどに置き換える必要性があり、その点では移植が困難になる要素も多いといえる。もっとも、POSIXシステムコールについても吸収できるラッパーライブラリーあるいはラッパーフレームワークがつけられたとしたら、その問題が解決される可能性はある。
いずれにしても、まだ不明瞭な部分は大きいが、個人的には期待したいものである。
ウェブマスター。本ブログでITを中心にいろいろな情報や意見などを提供しています。主にスマートフォン向けアプリやウェブアプリの開発を携わっています。ご用の方はコメントかコンタクトフォームにて。
