サーバーサイド開発からiOSアプリ開発チームに異動して感じたこと

こんにちは！ジモティーでiOSアプリ開発を行っている小林です。

私は元々サーバーサイドエンジニアでしたが、2ヶ月ほど前にiOSチームにジョインしました。今回はiOSアプリ開発を始めたばかりの私が感じたRailsによるサーバーサイド開発との違いについて感じたことや、アプリの開発を始めて良かったと感じたことをご紹介したいと思います。

iOSチームにジョインした経緯

入社して約2年半Railsを使用してサーバーサイドの開発を行ってきました。Railsで一通りの開発が経験できたのと、Railsとは違った開発手法を体験したいという思いがありiOSチームへの異動を希望していたところ、その願いが叶えられiOSチームに異動することになりました。 今は約1ヶ月間の研修が終わり実際のアプリ開発を着手し始め、日々新しい学びがありワクワクしながら仕事をしています。

次からは、iOSアプリ開発を始めて感じたサーバーサイド技術との違いについてご紹介します。

iOSアプリ開発を始めて感じたサーバーサイド技術との違い

動的型付け言語 (Ruby) と静的型付け言語 (Swift) の違い

コンパイルの有無の違い

Rubyはソースコードを変えるとすぐに結果を確認できますが、Swiftはコンパイルが必要なためコーディング⇄結果確認のサイクルに時間がかかるようになりました。その代わりにコンパイル時にバグを見つけることができたり、実装時にIDE (Xcode) が随時エラーを指摘してくれたりするため、実装の手戻りは減ったように感じます。

ダックタイピングできないためインターフェースの数が多くなる

SwiftはRubyと違いダックタイピングの機能がないため、同等の機能を実現するためにインターフェース（Swiftのプロトコル）を多用することになります。そのため、記述が冗長になったり、ファイル数が増加したりしますがエラーがコンパイル時点で分かったり、可読性が高いという利点があると思います。

nilの取り扱い

Swiftの利点として大きく感じたのはnilを許容するかしないかを型として明示的に表現できることです。Rubyではnilのチェックが漏れているため実行時にエラーになることが多々ありましたが、Swiftでは実装時やコンパイル時にエラーになり間違いに気づくことができます。その代わりとしてnilを許容するオプショナル型を扱うための構文を学習するコストが少しかかりました。

# Ruby
foo = nil
# ~中略~
foo.size # nilになる可能性があるが、ぼっち演算子（&.）をつけ忘れたため実行時エラー

// Swift
var foo: String  // String型
var bar: String? // nilを許容する Optional<String> 型

foo = nil // コンパイルエラー（fooはnilを許容しないため）
bar = nil // OK（barはnilを許容するため）

print(foo.count)  // => 0
print(bar.count)  // コンパイルエラー（barはnilを許容するが、値をアンラップしたり、オプショナル・チェインを使用したりしておらず、nilになることが考慮できていないため）
print(bar?.count) // => nil （Rubyのぼっち演算子に似たオプショナル・チェインという仕組みが用意されている）

Rubyで参照型なものがSwiftで値型になっている

Rubyでは参照型だったStringが、Swiftでは値型になっています。Swiftでは配列やハッシュまでもが値型なのには驚きました。しかし、値型になことになったことにより、Rubyで防御的にdupによるコピーを行っていたケースでコピーが不要になりました。また、Copy on Writeの仕組みによりデータが変更される時になってはじめてコピーされる仕組みのためパフォーマンスも確保されているようです。

# Ruby
foo = [1, 2, 3]
bar = foo
foo[0] = 5
p bar # => [5, 2, 3] （Rubyの配列は参照型のため、fooと同じ配列を参照しているbarも書き換わる）

// Swift
var foo = [1, 2, 3]
var bar = foo
foo[0] = 5
print(bar) // => [1, 2, 3] （Swiftの配列は値型のためbarは書き換わらない）

アプリケーション開発におけるフレームワークによる違い

弊社ではWebアプリケーション開発にRuby on Railsを使用しています。Railsの場合はRailsが敷いてくれたMVCをベースとしたCoC（設定より規約）のレールに乗り効率よく開発ができていました。 一方iOSのネイティブアプリケーション開発の場合は、標準でMVCをサポートしているものの自由度が高く、規約がない状態だと三者三様の書き方になってしまうこともあり、弊社では以前本ブログでもご紹介したClean Architectureを導入しています。 Clean ArchitectureがRailsより疎結合なことと、依存関係逆転のためのインターフェース（プロトコル）が多いことにより、1つのアクションを実現するために必要なファイル数が多くなっています。

設計で重視される部分の違い

前述の通りWebアプリケーションの開発ではRailsが敷いたレールに乗っていれば効率良く開発することができましたが、ビジネスロジックの設計の良し悪しが後々の改修の際の開発効率に影響することがありました。 逆にiOSアプリの開発では、ビジネスロジックは主にサーバー側にあるためビジネスロジックの設計が開発効率に及ぼす影響は少ないですが、アーキテクチャー設計の良し悪しが開発効率に及ぼす影響が大きいと感じました。

リリース方法の違い

サーバーサイド開発ではリリース、障害発生時の切り戻しは簡単に実施できましたが、iOSアプリのリリースは事前にAppleによる審査が必要なため簡単には実施できません。また、Appleのガイドラインを満たしていないと審査がパスせずにリリースができないといったことが起こりえます。 そのため、予めリリース内容にガイドライン違反になるものがないかのチェックや、サーバーサイド開発よりテスト工数を多く確保し、複数人での実機を用いたテストを集中的に実施する期間を設けて品質を担保しています。

iOSアプリ開発を始めて良かった点

これまで行ってきたサーバーサイド開発に加えてiOSアプリの開発も始めたことにより、特に以下の点が良かったと感じました。

• モダンな静的型付け言語であるSwiftを学んだことにより、プログラミング言語に対する知識が相対化され理解が深まった。
• サーバーとアプリ両方のソースコードを把握することにより、サービス全体への理解や、問題が発生した場合の原因特定までのスピードが上がった。
• サーバーとアプリのインターフェースであるAPIの設計について、開発着手後に仕様が変更された場合のアプリ開発への影響の大きさを理解することにより、その重要性が改めて認識できた。

おわりに

最後までお読みいただきありがとうございます。

ジモティーを更に成長させる為に一緒に取り組んでいただけるエンジニアを募集しています。 ジモティーのエンジニア組織は比較的少人数で一人ひとりの貢献がプロダクトの成長に大きく寄与するため、やりがいが大きいと感じています。また、上に記載した通り、チームの異動についても柔軟に対応してもらえるので色々な技術を習得することが可能です。 もし少しでも気になればお気軽にご応募ください。