Appleの「Marzipan」プロジェクトの目的はmacOS/iOSで動くアプリではなく、UIKitやAppKitに続く新しいフレームワークを開発者に提供すること?

スポンサーリンク

 Appleの「Marzipan」プロジェクトはUIKitやAppKitに続くクロスプラットフォーム対応の新しいフレームワークを開発者に提供することにあるのではないかという記事をDaring FireballのJohn Gruberさんが公開しています。詳細は以下から。

Xcodeのアイコン

 2017年12月20日、「Appleは現在macOSとiOSで別々となってしまっているアプリを1つのアプリとして開発し、ユーザーに対し1つのユーザーエクスペリエンスで提供出来るコードネーム『Marzipan』というプロジェクトを進めており、早ければWWDC 2018で公開される予定」という記事をBloombergのMark Gurmanさんが公開し話題になりましたが、

Marzipanプロジェクト

これに対しDaring FireballのJohn Gruberさんはこの「Marzipan」プロジェクトは一般のユーザーに対しmacOS/iOSのクロスプラットフォームで動くアプリを提供するのではなく、開発者に対しクロスプラットフォーム対応のフレームワークを提供するためのプロジェクトだろうという記事を公開しています。

Gurman probably didn’t write the headline, but it doesn’t even make sense. iOS has no concept of a mouse cursor and runs only on touchscreen devices. MacOS has no support for touchscreen devices and requires a mouse pointer. “One user experience” is neither possible nor desirable. The truth is that this effort by Apple is almost certainly not about cross-platform applications but instead cross-platform frameworks for developers. It’s developer news, not user news.

Daring Fireball: Marzipan

 Gruberさんは「Marzipan」がmacOS/iOSで同じアプリを実行できるプロジェクトだとしても、macOSにはAppKit、iOSにはUIKitがあるようにElectronの様な一度書けばどこでも動くwrite-once/run-anywhereアプリがすべてのプラットフォームで優れているわけでは無く、AppleがOS X 10.10.3 YosemiteでmacOSとiOSの互換レイヤーUXKitをプライベートフレームワークとして導入し写真アプリを開発した例を出し、

My only quibble with Mueller’s piece is that “None of them turned out insanely great” is way too generous a description of write-once/run-anywhere application frameworks. Most of them are terrible; none of them are good. Or at least none of them are good from the perspective of what makes truly native Mac and iOS apps good — which isn’t everyone’s perspective, but is certainly Apple’s.

Daring Fireball: Marzipan

この写真アプリでさえmacOSのアプリとして最適なUXを提供しているわけではなく、macOS/iOSで同じクロスプラットフォーム・アプリを開発&利用するには様々な問題がある指摘しています。(例えば、Finderと写真アプリから写真をドラッグ&ドロップしようとする場合、前者はアプリが背面に位置していても可能だが、後者は前面にありアクティブな場合でなければ写真を移動できない)

Photos for MacのUX

 最後にGruberさんはMac上でMac用に修正されたiOSアプリを動かしたり、AppleがOSの統合を目指していると考えるのは無意味で、Appleの最終目的は開発者がより良いMacアプリを開発し共通のMac/iOSアプリのコードを共有しやすくする事だとコメントしています。

In short, Apple’s goal should be to make it easier for developers to create good Mac apps, and easier for Mac and iOS app siblings to share code. Apple’s goal should not be to make it easier to get iOS apps to run on the Mac in slightly modified form. And I think it’s nonsensical to think that Apple is working toward a single unified OS. The best reason for hope on this front is the recent redoubling of Apple’s efforts on pro Mac hardware. The iMac Pro was not designed to run iPhone apps.

Daring Fireball: Marzipan

スポンサーリンク

おまけ

 ちなみに、最後の「iMac ProはiPhoneアプリを動かすように設計されていない」というのは定かではなく、iMac ProのT2チップはA10(Arm64)ベースで、MacBook Proに搭載されているT1チップのApple Watch向けアーキテクチャ「Armv7k」ベースとは別物になっているそうです。

コメント

  1. 匿名 より:

    > AppleがOS X 10.10.3 YosemiteでmcOSとiOSの互換レイヤー「UIKit」をプライベートフレームワークとして導入し写真アプリを開発した例

    UXKitです( ´・‿・`)

    • applech2 より:

      ご指摘ありがとうございます。
      先程該当箇所を修正しましたので、WordPressのキャッシュクリア後に修正されると思います。

  2. 匿名 より:

    あまりにも冷静な物の見方過ぎて寂しい

  3. 匿名 より:

    また後方互換性壊すのかな

  4. 匿名 より:

    >例えば、Finderと写真アプリから写真をドラッグ…
    アクティブなウィンドウ/アプリケーションのオブジェクトを触れないのが基本でFinderが例外なだけじゃないかなあ。なぜかっていうとオブジェクトを置く場所としてのデスクトップがFinderの管理/Finderだけだからかな。AppKit使ってるアプリケーションでもアクティブなウィンドウ/アプリケーションのオブジェクトを触れないんじゃないの

    アクティブでないウィンドウのオブジェクトを弄るというのは、Commandキー押しながらでどのアプリケーションでもというのは昔から最初からあるけど。記事でどの写真アプリかはわからんけど、Photos.app 2.0 でも当然Commadキー押しながらだとアプリケーション/ウィンドウをアクティブにしなくてもになるけど

    簡単にはいかないことはあるだろうけど、例としては不適切だと思うなあ

  5. 匿名 より:

    Finder以外でも別にコマンド押下を必要としないアプリケーションはいくらでもあるし
    むしろそっちが普通

  6. 匿名 より:

    なーんかまた開発者に負担かかりそうな話だなあ
    UIKitをAppKit化(というかマウスカーソル対応)してmacOSに移植するだけのほうが良さそうな気もするし、
    昔あったClassic環境もしくはRosettaのように、iOSアプリ動作レイヤーをmacOS内に儲けちゃった方がいいような気もするし。