OSSライセンス表記の自動生成機能をCocoaPods Pluginで改善した話

モバイルファースト室の@y_310です。

iOSアプリでオープンソースなライブラリを使う場合、サーバサイドアプリケーション以上にソフトウェアライセンスを意識する必要があります。 多くのライブラリはMITライセンスや修正BSDライセンスで提供されていますが、それらのライブラリを使う場合、再配布時に元のライセンス条文を配布物のどこかに含めることが要求されています。

とは言え、アプリケーションに含めたライブラリのライセンスを確認して確実に配布物に含めていく作業というのはどうしても漏れがちで手間なものです。

そこでiOSで標準的に使われているパッケージ管理ツールであるCocoaPodsでは、ライブラリのインストール時に自動的に各ライブラリのライセンス表記を集約し1つのplistファイルにまとめてくれる機能を持っています。 あとはこのファイルをSettings.bundleの中に移動すれば設定アプリの中にライセンスが表示されるようになります。

この辺りのやり方についてはCocoaPodsのWikiに掲載されています。

https://github.com/CocoaPods/CocoaPods/wiki/Acknowledgements

GitHubなどで公に公開されているライブラリのみを使用する場合はこれで終わりです。 しかし社内用のライブラリなど外部に公開していないものがPodfileに含まれている場合、それも自動的にこのファイルに含まれてしまうためあまり具合が良くありません。

ここでようやく本題ですが、この問題を解決するためにcocoapods-ack_filterというCocoaPods Pluginを作りました。

このプラグインを使うと、plistファイルを生成する際に、ライセンス本文が指定した正規表現にマッチするライブラリを除外することができます。

CocoaPods Pluginとは

CocoaPods PluginはCocoaPods 0.28から導入されたプラグイン機構で、podコマンドに機能追加ができるようになります。 作り方の詳細はこちらのオフィシャルブログに書かれています。 http://blog.cocoapods.org/CocoaPods-0.28/

PluginのルールにそってRubyのgemを作るだけなので、Rubyに慣れている人であれば簡単に作ることができます。

インストール

gem install cocoapods-ack_filter

設定

まず、除外したいライブラリのpodspecを変更します。このtextに指定した文字列にマッチさせてライセンス表記を除外させます。

Pod::Spec.new do |s|
  ...
  s.license = { type: 'Private Library', text: 'Copyright 2014 MyCompany Inc. All Rights Reserved.' }
  ...
end

Podfileに以下のpost_installブロックを追加し、正規表現と出力先のパスを適切に変更します。

# Podfile

pod 'AFNetworking'
pod 'MyCompanyLib'

post_install do
  Pod::Command::AckFilter.filter(
    pattern: /MyCompany/,
    output: 'OurApp/Settings.bundle/Acknowledgements.plist'
  )
end

実行

いつものようにpod installするだけです。

pod install

これで、outputに指定したパスにライセンスの記載が不要なライブラリを除外したplistファイルが出力されます。

ちなみにCocoaPods Pluginとして実装しているのでコマンドラインから実行することもできます。

pod ack-filter MyCompany --output=OurApp/Settings.bundle/Acknowledgements.plist

生成されたAcknowledgements.plistは変更管理できるようにリポジトリに含めておきましょう。

まとめ

cocoapods-ack_filterを使うことでライセンス表示ファイルの生成を日常のワークフローの中で完全に自動化することが出来ました。 セットアップも簡単なので新しいアプリに導入する際も少ない工数ですぐに導入できます。

iOSアプリでレシピ投稿機能を統合したねらい

レシピ投稿推進室の大前です。

クックパッドでは、公式アプリ(以下、本体アプリ)から独立したアプリケーション(「クックパッド のせる」)として提供していたレシピ投稿の機能を、2014年9月に本体アプリに完全統合しました。

※iOSプラットフォームのみ。Androidは2012年に統合済み

今回は、もともと別アプリケーションとして分離していた投稿機能を統合したねらいと、統合において課題となった点などについて簡単にご紹介したいと思います。

統合の目的・ねらい

レシピ投稿機能を統合するねらいは大きく2つありました。

1点目は、レシピ投稿機能を統合することで、「今日つくる料理を見つける」ことを主要な目的として本体アプリを利用されている方にも、より身近にレシピ投稿の機会を感じてもらえるようにするという点。

2点目は、クックパッドというレシピサービスがユーザーのレシピ投稿によるエコシステムによって成り立っているということを、レシピを投稿するユーザー、さがすユーザー双方に実感してもらえるようにしたい、という点でした。

クックパッドを利用していただくユーザーさんが増えるにつれ、モバイルアプリケーションのみでクックパッドを利用し始めるという方もおり、そういった方々に上記のような点を感じてもらいながら、それと同時にモバイルアプリケーションからのレシピ投稿者を増やすことを実現することを目的に統合プロジェクトをスタートさせました。

課題

例えば、インスタグラムのように、同じユーザー投稿型のサービスでも、利用者のほとんどが投稿も閲覧もするユーザーであるようなユーザー構成のサービスとは違い、クックパッドの利用者の大半はレシピを検索、閲覧するユーザーで、レシピ投稿者の割合はごくわずかなユーザー構成のサービスです。

統合における一番の課題は、当初、分離という選択肢をとっていた理由そのものでもあるのですが、そのような「今日つくる料理を見つける」と「レシピを投稿する」というまったく異なる目的・異なるターゲットユーザーを持った価値を一つのアプリケーションで実現する必要がある点でした。

ウェブページとモバイルアプリケーションの違い

とは言え、もともとクックパッドはウェブサービスとしてスタートしたサービスで、現行のウェブ版のサービスでもすべての機能が分離されず(別サービスとして展開されているものを除き)ひとつのウェブサービスとして提供されています。

ウェブサイトでのレシピページ

以下はPCサイトでわたし自身が投稿したレシピページを表示したものです。 WYSIWYGの思想を元に他人がこのレシピを見たのとほぼ同じような表示のまま編集できるような作りになっています。 また、右カラムにはレシピがどれくらい見られたかというような自分だけが見ることのできる情報を表示するエリアがあります。

f:id:yuki-omae:20140925094614p:plain

おおまかに分類するとこのページでは以下の3点の目的を実現するための機能が混在しています。

  • レシピを閲覧するコンテキストでの機能(
  • レシピを編集するコンテキストでの機能(
  • レシピに対するフィードバックを閲覧するコンテキストでの機能(

f:id:yuki-omae:20140925094618p:plain

これをモバイルアプリケーションのレシピ画面で実現することを検討してみるとどうでしょうか。 以下がモバイルアプリケーションでのレシピの画面です。

f:id:yuki-omae:20140925094621p:plain

PCでの表示より圧倒的に表現できる情報量が少ないことがわかると思います。 この面積の中に、先ほどのPCページが満たしていた機能を全て混在させるとどうでしょうか。

例えば、レシピを編集する観点で見た場合、「レシピを送る」という機能は余計だし、このレシピを見て料理をつくろうとした場合「フィードバック」の要素は邪魔にならないでしょうか。

異なる利用コンテキストへの対応を、モバイルアプリケーションの小さな画面サイズで実現しようとした場合、PCなどの大画面をベースに設計されたものを、単純には移植するだけではだめだということがわかっていただけると思います。

モードを分ける

今回の統合では、このような異なるコンテキストでの利用が想定されるような場面では、基本的にモードを分離する、という方法でひとつのアプリケーション内で異なる利用コンテキストを考慮して機能を共存させることを徹底しました。

先ほどのレシピページは以下の様な構成で利用できるようにしました。

f:id:yuki-omae:20140925094624p:plain

自分のレシピの一覧から「閲覧」「編集」「フィードバックの閲覧」という異なるコンテキストを導線として分岐させ、利用しようとしているコンテキストに応じて、最適化された画面を表示して利用することができるようにしています。

レシピページは一例ですが、このように異なる利用コンテキストやユーザーが混在することを考慮して、レシピを投稿するための機能や導線を既存の「今日つくる料理を見つける」ことを実現するためにデザインされたアプリケーションに統合していきました。

まとめ

上記のような対応を経て、2014年9月に機能統合をはたした結果、現在、iOSプラットフォームは、全プラットフォームの中でも1番レシピ投稿者の多いプラットフォームになっています。

投稿者数の面だけでなく、クックパッドというサービスがレシピの投稿者あってのサービスだという認識の向上にも貢献できているのではないかと思います。

今回は、レシピページという一部の実例だけの紹介にとどまりましたが、今回紹介させていただいたような観点でぜひ実際のアプリ内でレシピ投稿をお試しいただければと思います。