Developer登録を済ませる

　開発したアプリを登録するためには申請者がAppleの登録Developerである必要があるので、まず事前にDeveloperの登録手続きを済ませておきます。二段階認証を済ませた端末から申請してDeveloperの年間登録料（2022年現在12,800円）を支払う必要があります（多分クレジットカードとの紐付け必須）。また、政府発行の身分証明書のコピーの送付が最終段階で必要でした（フォームから画像を送る）。会社としての登録の場合にはそれ以外に「D-U-N-S番号」が必要になるようです。詳しくはこちら。
　自分の場合はMacのDeveloper.app内から申請して通しました。それ以前にiPhoneから申請したところずっと審査中で止まってしまっていて、あらためてMacから申請し直したらあっさり通ったような経緯です。止まっていた理由は何も表示されないのでよくわかりません。

「App用パスワード」を作っておく

　Xcode以外の環境でビルドしたアプリの登録には「App用パスワード」が必要になるとのことなので事前にこちらにDeveloper登録に使ったApple IDでログインしてApp用パスワードを作っておきます。「+」ボタンをクリックして分類名（任意でよい）を入れ、表示されるパスワードをメモしておきます。

キーチェーンアクセスで証明書（CSR）を発行しておく

　Macの「キーチェーンアクセス」アプリを開き、ドロップダウンメニューから「証明書アシスタント」→「認証局に証明書を要求」を選択します。

　Apple IDの登録メールアドレス、通称（登録しようとしているアプリの略称など）を入れ、「ディスクに保存」「鍵ペア情報を指定」を選んで「続ける」をクリック。証明書ファイル（以下Apple Developer Programで作る証明書と紛らわしいので「CSRファイル」と呼称する）の保存先を指定し、次の画面で秘密鍵、公開鍵に「2048ビット」、「RSA」の設定を選んで保存を実行します。これで指定した場所にCSRファイルが保存されたはずです。

　なお、この作業中何度かアカウントのログインパスワードの入力を求められましたが、これは環境によって変わるかもしれません。

アプリとインストーラーの証明書を発行する

　まずアプリ本体の証明書を発行します。Apple Developer Programのサイトにログインし、「アカウント」タブから「証明書、ID、プロファイル」の「証明書（英語）」を選択し、次画面で「Certificates」の横の「+」ボタンを押して証明書の種類を選びます。

　Xcode以外で作成したアプリを自分のサイト等から配布したい場合は「Developer ID Application」を選んで「Continue」ボタンを押します。App Store経由での配布の場合はここで選ぶ証明書の種類が変わるようです。

　次に「Certificates, Identifiers & Profiles」の画面が出るので、画面下の「Choose File」ボタンをクリックし、さきほど作成して保存したCSRファイルを選択してアップロードします。「Profile Type」はよくわからなかったので「Previous Sub-CA」を選びましたが、特に問題なかったようです。「Continue」を押し、次の画面で「Download」をクリックして証明書をダウンロードします。

　同じくインストーラの証明書も必要になるので、「証明書、ID、プロファイル」の「証明書（英語）」から「Developer ID Installer」を選んで証明書を作ります。CSRファイルは同じもので良いようです。

　ダウンロードした証明書のファイルをダブルクリックするとキーチェーンアクセスに取り込まれますので、その状態にしておきます。

Xojoでデベロッパ署名をいれた状態でアプリをビルドする

　Xojoで配布対象のアプリのビルド元ファイルを開き、発行されたDeveloper IDを「Build Settings」の「macOS」内にある「Sign」に記入してアプリをビルドします。

　Developer IDはキーチェーンアクセスで対象の証明書の項目を見れば確認できるはずです。

　テスト時にはこのあとアプリ本体へのコード署名処理でエラーが出てしまって困ったのですが、この形で事前に署名を済ませておいてターミナルでのコード署名処理では署名部分を指定しないことで回避できたようです。
　また、同一の署名がキーチェーンアクセス内に複数あるとエラーになるようです。各アプリごとにアプリとインストーラーの証明書を取得してキーチェーンアクセスに登録する必要は無く、使い回して大丈夫な模様。あるいは公証が終わったらキーチェーンアクセス内の証明書は消す形でしょうか。
　なお余談ですが、パッケージ内に含めたい外部ファイル／フォルダはビルドする前にパーミッションを適切に設定しておかないとインストール後にそれが原因で一部の機能が動かなくなったりします（なった）。ターミナルで

などとやってパーミッションを設定しておきましょう。

配布用ファイル作成作業用のフォルダを作る

　配布用ファイル作成作業用のフォルダを作ります。今回は参照サイトに従ってMacのApplicationsフォルダにインストーラ（.pkg）でインストールする形を取りますので、pkg/Applications/“アプリ名フォルダ”/“アプリ名.App” の構成としました。

　署名の処理に必要になるentitlements.plistは参照先サイトのものをそのままコピーして保存（文字コードUTF-8指定に注意）。一応以下に同じものを置いておきます。

アプリ本体へのコード署名を行う

　以下のコマンドで署名処理を実行します。

　で作成作業フォルダに移動してから

　のコマンドを実行。「replacing existing signature」のメッセージが出ればOK。

　なお、参考にしたページの情報だと-sの後で指定するのが「”Developer ID Application: ${DEVELOPER_ID}”」となっていたのですが、なぜかこの指定だと「--options runtime」で「--options というコマンドが見当たらない」という旨のエラーが出てしまっていました。その状態だとHardened Runtime対応がされないので、この後のAppleのサーバへの登録で蹴られます（ました）。理由はわからないのですが「“Developer ID Application”」とだけ入れておけば処理が通る模様。なんでしょうねえ。つまりここではアプリへのDeveloper IDの署名自体は行っていない（ビルド時にXojo内で済ませている）のですが、上記のコマンドの実行は必要です。

　署名ができているかの確認は以下のコマンドで行います。

　署名が確認できればOK。

インストーラパッケージ（.pkg）の作成

　次はインストーラパッケージの作成です。Dmg形式やZIP形式での配布もできるようなのですが、とりあえず参照先サイトに従ってpkg形式のインストーラを作成することとします。

　まずpkgファイルに含めるファイルを指定するための.plistファイルのひな形を出力します。

　で作成作業用フォルダ内のpkgフォルダに移動後、

　を入れると、packages.plistの名前でひな形が出てきます。

　それを開いて編集するとのことなのですが、参照先サイトに従ってとりあえず「BundleIsRelocatable」の指定を「false」にすることだけしました。以下に一応置いておきます。

　編集が済んだら、以下のコマンドを実行して「インストーラパッケージ」を作成します。

　「--identifier」で指定するリバースドメインはXojoのビルド元ファイルを開いて「Build Settings」の「macOS」から「Bundle Identifer」を見れば確認できます。
　「--version」はインストーラのバージョンとのことなので何でもよさげですが、一応アプリのバージョンをそのまま入れました。
　実行すると「.pkg」ファイルが生成されます。

　なお、.pkgファイルを一旦XMLとして出力することでインストーラの内容を編集できるようなのですが、参照したサイトで記述があったタイトルの抜けもこちらの環境では見られなかったので省略しました。pkgutil側でアップデートがあったのかもしれません。

インストーラパッケージに署名を行う

　次にパッケージに署名を行います。以下のコマンドで「署名済のインストーラパッケージ」が作成できます。

　Developer IDは「キーチェーンアクセス」で対象の証明書の項目を見れば確認できます。

　署名できたかの確認は先ほどのアプリの時と同じく pkgutil --check-signature コマンドで

　で実行できます。

アップルの公証サーバにアップロードして登録

　いよいよ最終段階です。以下のコマンドを実行してアップルの公証サーバに登録を行います。

　しばらく経って

　のメッセージが出ればアップロードは完了です。

　このあと公証サーバで処理が行われ、終了後に登録メールアドレスに結果の通知が来ます。

　「Your Mac software was successfully notarized.」の通知が来れば公証は完了。あとは配布するだけです。

　一応ターミナルでの確認方法も書いておきます。

　で確認できます。「Status: success」と出ていればOK。

　なお、参照先サイトにはログに残さないためにApp用パスワードをキーチェーンアクセスに入れておいて指定する方法の記述もありましたが、個人作成フリーウェア程度では必要ないと思われたので割愛しました。

印刷組版データ制作者は両者を分けて考えている

　私は電子書籍制作を担当する前には組版データの作成もやっていましたが、その際には自然に組版ソフトとワープロは別のものとして考えていました。ワープロ等で作成されたテキストデータが元原稿として入ってきて、それを元にの印刷組版データを制作していたわけなのでこれは当然です。おそらく今現在組版データの作成を仕事としている多くの人も同様なのではないかと思います。

一般的には混同されている感がある

　一方で、原稿の執筆者含めて一般的には両者は混同されている感があります。これはPCユーザーの目線に立ってみればわかることで、今は例えばInDesignのような組版ソフトは汎用のコンピュータにインストールして使用するものであり、その同じコンピュータにはワープロソフトも入っていたりするでしょう。「とりあえずAdobe CCは契約してるからInDesignも入れてある」という人は珍しくもないのではないでしょうか。しかもInDesignのようなWysiwygのUIを採用している組版ソフトは簡単な使用感としてはワープロに近いものがありますし、場合によってはワープロの代わりに使ったりもされていそうです。混同されるのも無理はなさそうです。「フォント指定や図版の厳密な配置ができる高級なワープロ」ぐらいの感覚で認識されているのではないでしょうか。もっとも組版ソフトの中にはWysiwygのUIを採用していないものもありますので^※1、全てがそうだというわけではないですが。

それぞれのソフトの成立経緯をみれば違うものなのがわかる

　では実際両者の違いがどこにあるのかということを考えるときに、それぞれが「そもそも何を目的に作られたものなのか」を考えるのが有効な視点かなと思います。

　「組版ソフト」は元々は「活版印刷の組版工程をデジタル化したもの」のはずです。つまり、「本の紙面を効率的に作成するためのもの」です。汎用のパソコンにインストールして使用する「DTPソフト」の前段階として、専用のハードウェアを使用した「電算写植機」などの時代はありましたが^※2、大きな流れとしては間違っていないものと思います。ですから、当たり前ですが図版の配置位置は厳密に指定できますし、フォントや文字等の装飾要素を効率的に指定するための機能も充実しています。一方で、テキスト入力の支援機能、用語統一やスペルチェッカー等の機能は一般的にはありません。元々そこで文章を作成することは想定されていないはずですので、それは当然です。テキスト入力や編集は可能ですが、本来的にはそれは「一度組んだものを発注者の要望に添って修正するための機能」であるように思われます。
　一方で「ワープロ」は元々、「タイプライターをデジタル化したもの」もしくは「原稿用紙をデジタル化したもの」として作られたものであるように思います。つまり、「デジタルテキストを入力するための道具」です。私くらいの年齢だと、その昔は「日本語ワープロ専用機」が当たり前のように使われていたのを覚えています。「OASYS」や「書院」の時代です。ワープロ普及の初期には手書きの原稿をもとに入力が行われていたかと思いますが、やがて個人でもワープロ専用機を使って直接デジタル文書を作成するのが当たり前になり、それはやがて「一太郎」や「WORD」といった汎用のパソコンにインストールして使用するワープロソフトに代替されていきました。もともとがそこでテキストを入力するためのものなので、用語統一やスペルチェッカー等のテキスト入力支援の機能は充実しています。一方で、図版を必ずこの位置に配置したい、などの機能は少なくとも組版ソフトほど充実してはいません。それは後からユーザーの要望に応えて追加されたものに過ぎないからです。

活版印刷の時代には組版作業は工場で行うしかなかった

　さて、ちょっと昔を振り返ってみると、そもそも活版印刷の時代には、本の版面制作は「工場で職人が行うしかない作業」でした^※3。大量の金属活字を置く場所が必要だったはずですし、各工程ごとに職人がいなければ成立しない仕事だったので当然です。
　もちろんその前段階の原稿のタイプライター入力や、原稿用紙への執筆は各出版社や著者の手元の環境で出来る作業でしたが、その先の「組版」は物理的に無理だったわけです。ですから、自然に別のものとして認識されていたでしょう。

　その後の電算写植機の時代にも（現物のキー配置を見れば一目瞭然ですが）、専門性の高い高価な機材を適切に扱うために長期間の訓練を経たオペレータが必要でしたので、組版作業は自然と工場で行うものになっていて、混同はあまりなかったのではないかと思います。
　大幅な変化が起きたのは明らかに2000年以降、汎用コンピュータに組版アプリをインストールして使う「DTP」の普及以降のはずです^※4。DTPは組版処理に必要な機材コストおよび人的コストを大幅に低減化させた功績がありますが、一方で組版のプロの領域の仕事とそうではない前作業の領域の境目をわかりにくくもしました。その結果何が起きたかというと、本来なら前作業の段階で終わらせておくべき推敲や原稿整理を組版工程に入ってから行う例が後を絶たなくなったわけです。組版ソフトをワープロと同じように捉えられているのであれば、当然といえば当然の結果でしょう。これによって（当たり前ですが）組版の現場にそれまでにはなかった負荷がかかるようになりました。

「設計」と「施工」は分けて考えられるべき

　本来、本の制作で推敲や原稿整理などの「設計」にあたる工程と、そのあとの組版処理、「施工」にあたる部分は分けて考えられるべきものです。これは、例えば家を建てることに置き換えれば簡単に理解できるはずで、例えば「一旦3階建ての家を建ててしまってから2階建てに作り替えて地下室を追加する」とか「日本家屋を建てたあとで気に入らないから西洋風に改装する」とかやっていたらコストがかかって仕方ないはずです。内容の吟味は「設計」の段階で終わらせておくべきもので、「施工」をしてしまってからの修正は小規模なものに止めるのが当然です。
　最近ではワープロに限らず、Web方面では一般的なMarkDown記法やその他のテキストをハンドリングするための技術を用いて本を効率的に作ろうという試みをあちこちで目にしますが、これらも基本的には推敲や原稿整理の段階で用いるべきもので、それを組版作業の工程に融合させる方向性には抵抗感があります。そこを混ぜてしまうと結局現場に多大な負荷がかかるだけで終わるケースが多々あるからです。組版作業工程の効率化はもちろん模索していくべきと思っていますが、それは推敲や原稿整理とは分離して考えられるべきものと考えています。
　なお、「リフロー型電子書籍」の作成は、作成時に特定の版面を前提とした組版調整を行わない（行うことができない）という意味ではワープロ等の文書に性質が近いですが、支給されたテキストを流せば簡単に作れるというものでもないのでやはり「施工」にあたる工程でしょう。ただ、その元データとして「印刷用DTPデータ」が使われるのは明らかに非効率の源ですので、将来的にはそのあたりも含めて出版ワークフローの最適化がなされるとよいなと思っています。