寄付窓口はこちら

try! Swift 書き起こし 実践的クロスプラットフォームSwift #tryswiftconf Day1-2

SwiftApple以外のプラットフォームでも利用できるようになりました。iOSアプリ以外でも好きなようにSwiftを書けます。この講演では、CocoaObjective-Cの機能を犠牲にせずに、クロスプラットフォームSwiftを用いるときの実践的な書き方、テスト・デバッグ手法、について解説します。

twitter.com

私はJPともうします Realmという会社に努めています。

try! Swiftへようこそ 信じられないくらい多いですね

RealmははじめからSwiftを大切にしています。

どうやって開発環境を設定するか 適切なテストをどうするか、CIをどうするか。。

クロスプラットフォームSwiftを考えるとプラットフォームはいくつ有るのでしょうか。2つです。DarwinLinux?実際には3つあります。Swiftバイナリ、オープンソースバージョンのSwift、 ほぼ三種類あるといえる。 Raspberry Piやアンドロイドでもかなりの作業が進んでいます。実際にはプラットフォームは沢山あるが、あらゆるところでSwiftを走らせたい。

純粋なSwiftを書けばどこでも走らせられるというのを理想にしていますが、じっさいにはうまく行っていない

f:id:niwatako:20160302103550j:plain f:id:niwatako:20160302103553j:plain

Appleは迅速に作業を成し遂げましたが改善が必要です。

理想的にはクロスプラットフォームをするならコードを出来るだけクロスプラットフォームフレンドリにする。そして一つのデバイスで開発したい。Xcodeと、ツールチェーンと、DockerやCLI、Editorという環境が居る。

f:id:niwatako:20160302103718j:plain

Xcode7.3ではツールチェーンを選択できる

f:id:niwatako:20160302103805j:plain

だんだんややこしくなってくる

f:id:niwatako:20160302103823j:plain

Dockerがオススメ。コンテナ型仮想化環境です。この場合必要なのはhomebrewだけで数コマンドで出来ます。

ここで重要なのはローカルなディレクトリをマウントしてDocker環境にマウントすることです。 そして好きなエディタで編集しながら開発ができます。

Swift Package Manager

f:id:niwatako:20160302104029j:plain

是非オススメしたいのはSPMを使う時に自分のコードを細かいプロジェクトに分けることです。

そしてもう一つクロスプラットフォーム開発で遭遇するのは、見た目はシンプルだが隠された依存性が有る。ObjectiveCに依存しているとか。ダイナミックなメッセージとかですね。

f:id:niwatako:20160302104242j:plain

これを何とかしないとクロスプラットフォームで開発できない。キャスティングObjective-Cランタイムに依存しています。

それから非常に重要なフレームワークがあるのはDarwinだけ。これは今後対応するという決定がAppleでありました。

Linuxにインポートする時に非常にシンプルだと思ったのはResultライブラリです。イーザータイプのようなものです。Appleフレームワークを使っておらず自分自身で成立する。 でもいくつか例外が有る、キャスティングエラーが発生する。一見ピュアスウィフトに見えても、うまく動かない

物を動かしてサポートしていく必要がある。

フラグメントのワークアラウドも必要。

f:id:niwatako:20160302104538j:plain

#if がたくさん必要になる。 アーキテクチャチェック、AppleFrameworkを使っていないか、Objective-Cランタイムを使っていないかなど。この辺は慣れていくしか無い。時間がたてば軽減していくと思われる。

テスト

f:id:niwatako:20160302104639j:plain

数週間前の様子

f:id:niwatako:20160302104651j:plain

依存性を扱うことが出来なかったり。最新では自動でテストターゲットを作ってくれる。

f:id:niwatako:20160302104744j:plain

Linux環境では振る舞いが別になるケースが有る。DarwinXCTextではないのでテストファンクションが何か伝える必要がある。Darwinバージョンなら全部分かってくれる。でもだいぶわかりやすくなって良い。

CI

f:id:niwatako:20160302104934j:plain

CIでは全てをテストしビルドメトリクスをとりましょう。 Travisはシンプル。

f:id:niwatako:20160302104949j:plain

この3つで動かします

f:id:niwatako:20160302105005j:plain

SPMを使うとちょっと複雑な設定が必要になります。

f:id:niwatako:20160302105026j:plain

Linuxではそんなに複雑ではありません。

f:id:niwatako:20160302105048j:plain

これで満足? いろいろやってみて、SwiftOpenSourceのプロジェクトに是非貢献してみてください。 Appleも歓迎すると思います。

f:id:niwatako:20160302105459j:plain

QA

XcodeDarwin以外でOSSで走る物が出るか?

おそらくはない、Apple内で開発する。Xcode自体はOpensourceではない。 Swiftチームはいい仕事をした。頻繁にクラッシュしたSwiftはいまは安定している。殆どのIDEサポートは、Xcodeの外で行われている。SourceKitなど、ツールとしてはOpensourceされています、その中にはプラットフォームまたがるものも有る。本質的にはSourceKitをLinuxに入れてIDEサポートをするのは出来ると思います。

ツールチェーンの他の部分をOpenSourceすることでXcode自体はされない

ちょっと先の話になるかもしれないが、キャストのどの部分がResultライブラリに入っていてObjective-Cに依存しているのでしょうか

わからないです。ただ言えるのは、デバッグに苦労しています。コンパイラパーツのデバッギング、だけではなくSwiftProjectに入っているものは苦労しています。基本的にはもっと、私よりすぐれたデバッガになって解決するのがよい。あなたなら出来る!

うまく行かなかったらランタイムのせい?

手探りですね。なぜObjective-Cに依存していると思うかというと、型解決を利用しているので何らかの関係があると思っているが、他の部分が使われているかもしれない。

f:id:niwatako:20160302105725j:plain

(おまけ:お隣さんの手)

気に入った記事は はてなブックマーク

はてなブックマークアプリiOS開発チームから来ました! はてなブックマークにはSwift特集があります! 良い記事を見逃さないように、ご利用ください! http://b.hatena.ne.jp/hotentry/it/Swift

そして良いまとめ記事があったらはてなブックマークでブックマークしましょう! try! Swift の記事で盛り上がると嬉しいです!