寄付窓口はこちら

native macOS application、またはAppKitの世界 | try! Swift Tokyo 2019 1-1

SwiftはiOSmacOSなどの世界でネイティブアプリケーションを作るのに欠かせない言語ですが、さてnativeアプリケーションとはなんでしょうか? SwiftからCocoaフレームワークを使えばネイティブアプリケーションなのでしょうか。ネイティブの真価を発揮するにはプログラマがFrameworkを知り尽くしHuman Interface Guidelinesに精通し、自身が対象OSの良き理解者である必要があります。そういえばMazipanの足音も聞こえてきましたね。美しいmacOSネイティブアプリケーションを作る上で欠かせない視点をお話しします。

f:id:niwatako:20190321100346j:plain

f:id:niwatako:20190321100402j:plain

本名ではありません、ハンドルネームです。

研究者として働いています。IT畑ではありません。学術論文を書いています。

でも

f:id:niwatako:20190321100436j:plain

でもコンピューターの世界では、CotEditorの開発者として知られています。

f:id:niwatako:20190321100500j:plain

アイコンの提供も。それからmacOS Nativeコミュニティも。

macos-native.connpass.com

CotEditorはほぼ私一人が開発していますがOSSです。

f:id:niwatako:20190321100532j:plain

Plain Text Editorにはたくさんの競合がいます。

レッドオーシャンです。どこに素人の開発するアプリケーションが入り込む好きがあるのでしょうか。

f:id:niwatako:20190321100616j:plain

f:id:niwatako:20190321100622j:plain

f:id:niwatako:20190321100629j:plain

Nativeアプリで、親和性が高く設計されているからです。それだけでユーザーにとっては使う理由に成るのです。

このなかでmacOSのアプリを書いたことがある人、そのなかで、ここ1年で更新した人。

では

f:id:niwatako:20190321100712j:plain

macOSでSwiftを書いている人。

みんな書いているのに、macOSアプリ開発はあまりポピュラーではありません。

良いものを書くというノウハウはあまり議論されていません。

この登壇で多くのみなさんがmacOSアプリの開発に興味を持ってくださったら幸いです。

f:id:niwatako:20190321100803j:plain

2つにフォーカスを当ててお話します。

なにをもってNativeアプリというのでしょう

f:id:niwatako:20190321100829j:plain

一般的に行ってCocoaフレームワークを使えばNativeだということは多くの人が同意するところだと思いますが、ヒューマンインターフェースガイドラインを無視していたらどうでしょう、丁寧にガイドラインに沿ったReactNativeと比べてどちらが使いやすいでしょう

macOS向けにしっかりと設計されたものがNativeアプリ

f:id:niwatako:20190321100922j:plain

言語でネイティブを考えます

f:id:niwatako:20190321100948j:plain

非ネイティブの言葉をきいて違和感を感じるのと、Nativeでないアプリは同じ

f:id:niwatako:20190321101018j:plain

macOSではiOSよりさらにこのことが重要になる

macOSではすべてをコントロールすることは推奨されない

iOSではアプリがディスプレイ全体をカバーする。

macOSではウィンドウが重なり合っている

f:id:niwatako:20190321101109j:plain

窓からアプリケーションの中を覗く。縁の外側はOSに属する。

f:id:niwatako:20190321101133j:plain

f:id:niwatako:20190321101138j:plain

iOSではデバイスの縁がアプリの縁。

macOSでは、フレームはウィンドウ。

アプリケーションはiPhoneを物理的に変形箚せられないが、macOSアプリでは外側を変形させることができる

f:id:niwatako:20190321101233j:plain

アプリケーションから設定パネルまで、すべてのものがmacOSのパーツとしてデザインされる必要がある。

無限のデザインの権限を持っているわけではない

複数のアプリのウィンドウが同時に広げられるゆえに、ユーザーにとって、同じ用途は視覚的に同じであることが重要

f:id:niwatako:20190321101320j:plain

他のアプリと統一感が必要。

f:id:niwatako:20190321101325j:plain

機能的にもほかのアプリと移動する。ドラッグ、Quick Look、他のアプリがアクティブのままスクロールする。ユーザーは個々のアプリケーションを操作しているのではなく、macを操作している。

他の作業に集中しながら他のアプリケーションにちょっと触れたい。そのときに違う動作をされたらどうでしょう。

f:id:niwatako:20190321101426j:plain

f:id:niwatako:20190321101434j:plain

タイトルバーは標準パーツですが、開発者がデザインします。

パーツの重ね合いで質感を出します。ドラック出来たりする。

f:id:niwatako:20190321101500j:plain

これが見た目が違うとどこを掴んでドラッグできるのかわからない

f:id:niwatako:20190321101515j:plain

f:id:niwatako:20190321101533j:plain

f:id:niwatako:20190321101541j:plain

小さなアイコンはドラックアンドドロップできる。

f:id:niwatako:20190321101556j:plain

オートセーブに対応していればタイトルをクリックして名前を変えられる。

f:id:niwatako:20190321101620j:plain

プラットフォームの慣習を尊重し、ユーザーがそれまでの経験に基づいて操作できるようにしましょう

アプリケーションを使っているという感覚はユーザーにない。

f:id:niwatako:20190321101655j:plain

息をしているようにアプリを使う。お箸を使うときにお箸を使うことを意識していないように。

あなたの新機能を使いながら、ユーザーはそれに気づいていないかもしれない、それが目指すところです。

開発者のエゴを殺す。

f:id:niwatako:20190321101745j:plain

ユーザーにとって最高なのはアプリケーションを使わずに目的を達成すること。

アプリケーションを使うことは目的ではない。皆さんのアプリのUIを学ばずに使うことができる、透明になってユーザーを目的に集中させてください

f:id:niwatako:20190321101821j:plain

たくさんのスキルが必要です。これはデザイナーの領域でしょうか。いえ、すべてが重なり合う領域を持っています。

f:id:niwatako:20190321101844j:plain

f:id:niwatako:20190321101853j:plain

開発者にとって最も簡単なのは、Appleが提供するAPIを利用すること。

でもハイコンテストモードやAppleScriptが使われたときどうなるのか?すべて把握している人はいません

f:id:niwatako:20190321101933j:plain

ヒューマンインターフェースガイドラインが助けになります。

この1年呼んでいなかったら、帰ったら読みましょう。必要なことです。

一方Mazipanがそこまで来ています。

f:id:niwatako:20190321102007j:plain

iOSのネイティブの感覚でmacOSアプリを開発できる。

チャンスでしょうか?いえ、ただのエミュレーターでしかありません。

f:id:niwatako:20190321102030j:plain

ただのきれいなElectronでしかない。

ターゲットプラットフォーム向けに設計しなければなりません。iOSアプリをmacに持ち込める素晴らしい技術です。しかし、あなたがもし高品質のmacOSアプリを提供したいの出れば、AppKitを使う必要があります。

UIKitのひどくて古臭いものではありません。慣れていないだけです。そしてmacOSは毎日使っていますからみなさん詳しいはずです。

美しいOSであることもご存知だと思います。

f:id:niwatako:20190321102154j:plain

あなたのサービスの本質に集中できるように、ネイティブフレームワークを使い、HIGにそいましょう。良い開発を楽しんでください