管理デバイスへのXcodeデプロイ

このブログではApp Storeあるいはポリシー経由でXcodeをインストールする方法を解説し、管理者権限を持たないユーザ向けのアプリ設定方法や、Xcode 14および15でプラットフォームSDKを管理する方法について取り上げます。

August 8 2023 投稿者

Armin Briegel

Developer using Xcode on their managed Macbook

macOSを使用してAppleプラットフォーム向けのアプリを開発する組織内の開発者との関係で苦労しているMac管理者は少なくありません。開発者はmacOS についての知識が豊富で情熱を持っていますが、これは同時にMacのツールや構成の設定に対して非常に厳しい要求を持っていることを意味し、全てを正しくセットするために自分達の邪魔をしないように求めてくることさえあります。

macOSで最も重要な開発ツールはXcodeですが、管理された環境にこのXcodeをデプロイする場合、Mac管理者は多くの課題に直面します。

注釈:このブログを書いている時点では、Xcode 14.3.1が最新バージョンであり、Xcode 15はまだベータテストの段階です。管理された環境へのXcodeデプロイに関して、Xcode 14では複数の変更があり、Xcode 15でも更なる変更が加えられました。さらにXcode 15はまだベータ版であるため、9月のリリースまでに他の変更が加えられる可能性があります。

Xcodeのインストール

最初の課題は、複数のMacにXcodeアプリをインストールすることです。Xcodeは膨大な量のストレージスペースを占有するため、かなり特殊な課題が発生。Xcode14は最大23GB、Xcode 15は最大11.7GBを占有します。(Xcode 15で大幅に縮小された理由については後ほど説明します。)

Mac App Store

AppleはMac App StoreでXcode を提供しており、Mac管理者は「アプリとブック」の一括購入からXcodeのデプロイが可能です。Apple Business ManagerまたはApple School ManagerからXcodeの無料ライセンスを「購入」し、管理システムのデプロイメント機能を使ってアプリをデバイスにプッシュできます。しかしこの方法でアプリをデプロイすることにはいくつかの欠点があり、さらにそれらはXcodeの特異な性質とサイズによってさらに悪化します。

現在(macOS Ventureおよび以前のバージョン)のMDM プロトコルでは、サーバーがアプリをインストールするコマンドを送信しても、クライアントがサーバーに応答しないため、ローカルユーザはインストールの進行状況を確認することができません。ユーザは、バックグラウンドで重要なダウンロード&インストールが行われていることさえ知らない可能性があります。また、ダウンロードやインストールが失敗する理由は色々とありますが、何らかの理由によりクライアント側でのインストールが失敗したとしても、ユーザにもMDMサーバにも通知されません。

ダウンロードまたはインストール中に、ノートパソコンを閉じたり、スリープ状態にしたり、あるいはデバイスをネットワーク域外に移動させたりすると、インストールは失敗します。失敗はどんなインストールでも発生する可能性がありますが、Xcodeのサイズ、そしてステータスがユーザに通知されないこと考慮すると、失敗の可能性は遥かに高くなります。

App Store経由でインストールする利点の1つは、ネットワークで有効になっているコンテンツキャッシュを利用し、ダウンロードスピードを大幅にアップできることです。

AppleはiOS 17とmacOS SonomaのMDMプロトコルを変更すると発表しました。この変更によりMac App Storeアプリの導入ワークフローは大幅に改善されるはずです。とは言っても、MDM開発者がこの新機能を採用、実装し、また組織、ユーザ、開発者がXcodeとオペレーティングシステムの新しいバージョンを導入するまでしばらく時間がかかるはずであり、これらの新機能の恩恵を受けられるようになるのは、まだ少し先になるでしょう。

ポリシーのインストール

概してMac App Storeのインストールは、ユーザがSelf Serviceから自分でダウンロードする方が、インストールが行われていることや時間がかかる場合があることをユーザ自身が認識できるので、より確実に実施されます。しかし(少なくともVenturaまでは)ポリシーを使用したインストールの方が「アプリとブック」の一括購入よりも信頼性が高くなります。

「アプリとブック」によるアプリデプロイのもう1つの特徴は、常に非ベータの最新版が提供されることです。インストールが完了し、Xcodeが有効になっていなくとも、Xcodeはアップデートを自動的にダウンロードして適用します。ただし、古いバージョンやベータ版のデプロイは管理できません。これは、組織によってはメリットにもデメリットにもなる可能性があります。

Xcodeの再パッケージ化

Jamfポリシーを使用してXcodeをインストールする場合は、Xcodeを含むインストールパッケージまたはpkgファイルを提供する必要があります。

Appleは、開発者ポータルでXcodeのダウンロードを提供しており、ダウンロードページには、Xcodeの旧バージョンとベータ版が(その他多数と共に)表示されます。このページにアクセスするにはApple Developer アカウントが必要ですが、無料利用枠で十分です。(便利な概要があるXcode Releasesページもお勧めです。)

Xcodeはxipアーカイブとしてダウンロードされ、Finderでアーカイブをダブルクリックすると、展開できます。アーカイブには10万以上ものファイルが保存されており、展開前にアーカイブの署名と整合性が検証されるため、展開にはかなり時間がかかるでしょう。

Xcodeを解凍したら、再パッケージ化できます。高度なパッケージングツールは不要、使うのはproductbuildだけです。

% productbuild --component /path/to/Xcode.app /Applications Xcode-14.3.1.pkg

--componentフラグの後の最初のパスはXcodeアプリケーションバンドルの場所を示し、2番目のパスはターゲットシステムにインストールされるファイルパスです。最後の引数は、作成されるpkgのファイル名です。pkgファイル名にバージョンを追加することを強くお勧めします。Xcodeは/Applicationsに必ずつける必要はなく、この再パッケージ化コマンドのために起動や構成する必要もありません。

これには通常かなり時間がかかります。

注1:ダウンロード時間とファイルサイズが気になる場合は、「--componentcompression auto」オプションを追加することで最大25%削減できます。このオプションは、圧縮に時間がかかりますが(さらにターゲットクライアントでの解凍にも時間がかかります)、ファイルサイズが小さくなるという利点があります。詳細については、こちらの投稿を参照してください。

注2:同じシステムに複数の異なるバージョンのXcodeをインストールする必要がある場合は(ベータ版と現在のバージョンなど)、インストールパッケージで「relocatable(再配置可能)」フラグを無効にする必要があります。詳細な手順はこの投稿に記載されていますが、最も簡単な方法はやはりquickpkgツールを使用することです。

初回の起動設定(管理者権限を持たないユーザの場合)

Mac管理者の仕事は、Xcodeアプリをデプロイしたら終わり、ではなく、ユーザがXcodeを使用できるように設定する必要があります。新しいシステムで初めて新バージョンのXcodeを起動すると、管理者権限を必要とする追加コンポーネントのインストールを求めるプロンプトが表示されます。

ユーザが管理者権限を持っていれば、これらのステップを自分で承認できるので、それほど難しいことではありません。一方で、一部デプロイは、これらのステップを承認できない標準のユーザを使用します。

macOSのアーキテクチャと組み込みのセキュリティにおいて、標準ユーザのセキュリティ上の利点は非常に限られており、標準ユーザは多くのデプロイにおいてもはや有用ではない「過去の遺物」だという意見もあります。(Graham Gilbertの投稿MacSysAdminのプレゼンテーションを参照。)

しかしながら、学校やその他の教育環境など一部のデプロイではこの選択肢がありません。Mac管理者の中には別のアプローチを試してみたいと思う人もいるかもしれませんが、組織の管理とセキュリティに関する議論は慎重に進められるべきであり、ともかく理由はなんであれ、標準ユーザにも対応する必要があるということです。

また、バックグラウンドで構成の一部を自動化すると全体的なエクスペリエンスが向上するため、ユーザが管理者権限を持っている場合でも、敢えて標準ユーザの方が好まれる場合もあります。

Xcodeが最初の起動時に要求するこれらの手順には、管理者権限が必要です:

  • 複数のバージョンのXcodeがインストールされている場合は、新しいバージョンを選択する
  • XcodeとApple SDKの規約に同意する
  • 追加コンポーネントをインストールする
  • 管理者以外のユーザに対して開発者ツールのセキュリティを有効にする

これらすべての手順を実行するコマンドラインツールがあるため、スクリプトで自動化できます。これらのコマンドはJamf Proのインストール後スクリプトポリシーなどからroot として実行する必要があります。

まず最初にコマンドラインツールがxcode-selectコマンドでインストールしたばかりの最新Xcodeを使用していることを確認し、xcodebuildを使用してライセンスに同意の上、「最初の起動」ワークフローを開始します。どちらの手順にも管理者権限が必要です。

続いて、全員を_developerグループに追加し、次の行でDevToolSecurityを有効にします。これにより、管理者または_developerグループのメンバーは、パスワード認証不要で特定のデバッグやパフォーマンス分析ツールを実行できるようになります。

_developerグループに全てのグループを追加することで、システム上の全ユーザが事前に権限を持つグループに追加され、これにはスクリプトの実行後に作成されたユーザーも含まれます。より制限を厳しくしたい場合は、dseditgroupを変更して、現在ログインしているユーザのみを追加することも可能です。

DevToolsSecurityによって有効になるプロセスは、主にコマンドラインツールとスクリプトを使用したデバッグとパフォーマンスワークフローに関連しているようです。特にセキュリティを重視する場合は、これを有効化にせずに開発者がワークフローを使用できるかどうかテストすることもできます。

Xcode 14および15を使用したプラットフォーム SDKの管理

事前にインストールしておきたいものがもうひとつあります。ここ数年でAppleはXcodeのダウンロードサイズを大幅に削減してきています:

  • Xcode 11: 7.5 GB
  • Xcode 12: 11 GB
  • Xcode 13: 10 GB
  • Xcode 14: 7 GB *
  • Xcode 15: 3.1 GB**

* watchOS および tvOS SDKは含みません。
** iOS、watchOS、tvOS、visionOS SDKは含みません

削減できた主な理由は、XcodeにすべてのプラットフォームSDKが含まれなくなったためです。(Xcode 14はmacOSとiOSに対応、Xcode 15はmacOSのみ対応。)アプリをビルドおよびシミュレートするのにプラットフォームSDKを必要とするプラットフォームは複数あります。よってユーザはまずダウンロード&インストールしたいプラットフォームを最初に起動するよう求められます。

つまり大量のダウンロードは回避されるのではなく、単に延期されるだけということで、実際のところXcode 15とすべてのプラットフォーム(iOS、watchOS、tvOS)の合計は17GBを超え、visionOSはさらに約7GBが追加となります。つまり、新しいXcodeバージョンにおいてダウンロードの実質的な削減はないのですが、最初のXcodeインストールのサイズが大幅に縮小されたことで、Mac App Storeからのインストールやアプリとブックを使用したインストールの信頼性がアップするはずです。

管理されたデプロイの利点は、Xcodeユーザが追加のSDK をダウンロードしてインストールするために管理者権限を持っている必要がないことです。最初にプロンプトが起動された際に、ダウンロードしたいものを選択、あるいはXcode設定の「プラットフォーム」タブに移動して、後で追加のプラットフォームを取得できます。

しかし、エンドユーザの負担を少しでも減らしたいと思われるかたもいらっしゃるでしょう。教室環境でXcodeをデプロイする場合、必要なダウンロードで全員の時間を無駄にしたくない、また、ユーザの手を全く煩わせることのないようビルドプロセスを完全に自動化したい、そのような場合には必要なプラットフォームSDKの自動デプロイを検討すべきです。

少し驚かれるかもしれませんが、これに関するAppleの記事でもxcodebuildコマンドの使用を推奨しています。

xcodebuildには3つのオプションがあります:-downloadAllPlatformsは、利用可能なすべてのプラットフォームをダウンロードします。これは便利ですが、Xcode 15の全てのプラットフォームで15GB以上占有してしまうため、Xcode更新後は、-downloadAllBeforeSelectedPlatformsの方が実用的です。

3つ目に、指定されたプラットフォームをダウンロードする-downloadPlatformがあります。プラットフォーム名は明記されていませんが、おそらくiOS、watchOS、tvOS、xrOSで間違い無いでしょう(visionOS SDKは、まだベータテスト段階であるため、今後変更される可能性があります)。

プラットフォームがすでにインストールされているのにコマンドを再度実行すると、重複とみなされダウンロードは拒否されます。よって必要なすべてのプラットフォームを構成スクリプトの最後に追加するだけで済みます。

Xcode 14にはiOS SDKが含まれていますが、xcodebuildは既存のSDKを検出し、重複を回避します。私のテストでは、ダウンロードはローカルキャッシュサーバーを使用していたため、処理スピードが大幅に改善されました。

Xcode 15では、ダウンロードの確認中にプログレスバーが表示されました。プロセスを起動させていないのに、プログレスバーがポップアップ表示されると、ユーザは不安になるかもしれません。しかしこれは初期導入ワークフローの一部であるため、問題はありません。

最後に

ポリシーで使用可能なスクリプトとすべての手順を含むはGitHubからご確認いただけます

Xcodeは、多くのユーザーにとって重要なアプリですが、管理されたデプロイに特有の課題をもたらします。このブログで紹介したツールとスクリプトは、あなたと、あなたのユーザの体験をより良いものにしてくれるはずですが、

これらが唯一のアプローチではなく、特定の環境においてはさらに良いアプローチがあるかもしれません。その点はご留意ください。

Jamfブログの購読

市場トレンドやAppleの最新情報、Jamfのニュースなどをお届けします。

当社がお客様の情報をどのように収集、利用、移転、および保存するかに関しては、プライバシーポリシーをご参照ください。

タグ: