タイトルバーでのフルパス表示で表示階層を制限したい

  1. Kuroさん

    開発お疲れさまです。
    今年もじんわりと暑い日が見え始めましたね~

    さて、ふと思いつきで便利そうと思ったことがあったので要望を挙げさせてください。お暇なときに検討いただければ嬉しいです。

    タイトルバー上のフルパス表示で、親階層の表示レベルに制限を設けたい、というものです。

    具体的には、以下のような設定に応じた表示になることを想定しています。

    • 対象のパス: C:\parent_dir\child_dir1\child_dir2\無題.txt
    • 現在の仕様: 上記パスがタイトルバーにそのまま表示される
    • 要望の仕様: 設定したレベルまでの親階層が表示されるよう、先頭側を切り詰める。例えば以下のような設定イメージです
      • 「1」を指定 → ...\child_dir2\無題.txt
      • 「2」を指定 → ...\child_dir1\child_dir2\無題.txt
      • 「3」を指定 → C:\parent_dir\child_dir1\child_dir2\無題.txt
        • ※ドライブラベルはこの例のように最上位階層に到達したらセットで表示するのがいいかもしれません

    この設定が便利なケースは、「フルパスが長くタイトルバー上の表示が毎度見切れてしまうが、親階層くらいは一目で知りたい」という場面です。

    例えば、私は「20260514_とあるタスク」のような作業単位のフォルダを切り、その中に惰性で「メモ.txt」のようなざっくりとしたファイル名を置くのをよく行うため、「20260514_とあるタスク\メモ.txt」という親階層込みの情報でなんのメモかを判断しています。
    その場合に配置場所の階層が深いと「20260514_とあるタスク」部分の表示がタイトルバーの「…」の切り詰めによって見えないことがありまして…そうすると、「この “メモ.txt” はどのフォルダー (タスク) のメモだ?」というのがパッと見で分からなかったりします。(そういった際は現状、タブのマウスホバーツールチップで確認しています)

    そういった場面で、前述表示イメージの「1~2階層程度の親で切り詰めて表示する」ができると、タイトルバー上で親階層が見切れるということが減り、親階層のフォルダ名が確実に眺めることができそうだなと思った次第です。

    フルパス表示の調整のように隠しオプションでも利用できると大変助かります 🙇‍♂️

     |  yuko  |  返信
  2. ご愛用いただきありがとうございます。

    > 今年もじんわりと暑い日が見え始めましたね~

    本当にそうですね。ちょっと試運転ということで、早速エアコンをつけてしまいました。暑すぎますねー😫

    > タイトルバー上のフルパス表示で、親階層の表示レベルに制限を設けたい、というものです。
    >
    > 具体的には、以下のような設定に応じた表示になることを想定しています。

    技術的に不可能というわけではありませんが、階層指定まで必要かどうかは悩ましいところですね。

    というのも、「2階層まで」といった固定のルールにしても、フォルダー名の長さやファイルの階層、DPI の違いなどによって結局見切れてしまう場合がありますし、逆に余裕があるのに不要な省略が入ってしまうこともあります。

    また、タスク切り替え時などは Windows 側でもタイトルバーの表示が自動的に省略されるため、アプリ側の制御だけでは完全に意図した表示を保証できません。その結果、二重に省略されたように見えてしまうケースもあり得ますね。

    > この設定が便利なケースは、「フルパスが長くタイトルバー上の表示が毎度見切れてしまうが、親階層くらいは一目で知りたい」という場面です。

    親階層を表示したいということであれば、v3.8.4 で追加したタイトルバーのカスタマイズ機能 (隠しオプション) で事足りるかもしれません。

    詳細はこちらのスレッドで紹介しています。

    【参考】タイトルバーに「「書き込み禁止」表示がほしい
    https://www.haijin-boys.com/discussions/9891#discussion-9981

    使い方は、Mery.ini にて次のように指定します。

    [Window]
    Title=$(FilePath) $(Dirty) - $(AppName)
    

    ↑ これは標準のタイトルバーと同じ構成になります。

    対応している書式は次のとおりです。

    • $(Dirty) : ダーティ インジケーター
    • $(ReadOnly) : 書き換え禁止
    • $(FileReadOnly) : 読み取り専用
    • $(IsUserAdmin) : 管理者
    • $(AppName) : Mery
    • $(Path) : ファイルのフルパス
    • $(FilePath) : アクティブ時フルパス / 非アクティブ時ファイル名
    • $(Dir) : フォルダーのフルパス
    • $(DirName) : フォルダー名
    • $(FileName) : ファイル名
    • $(FileNameEx) : 拡張子付きファイル名
    • $(Ext) : 拡張子

    この中の $(DirName) を使うと、親フォルダー名のみを表示できます。

    たとえば、ダーティインジケーターを先頭にして「ファイル名 + [親フォルダー名]」を表示する場合は、次のように指定します。

    [Window]
    Title=$(Dirty) $(FileNameEx) [$(DirName)] - $(AppName)
    

    この場合、タイトルバーは次のようになります。

    * メモ.txt [20260514_とあるタスク] - Mery
    

    ちなみに、[]() の括弧は中身が空の場合は自動的に非表示になります。

    というわけで、ご要望のように「特定の階層までを省略する」といった柔軟な制御は現状ではできませんが、上記の機能の組み合わせである程度は代替できるかもしれませんので、まずはこちらをお試しいただければと思います。

    また、「特定の階層まで」という指定についても、この方式であれば関数 (たとえば $Directory($(Dir), 2) のようなかたち) として将来的に対応できたら面白いかもしれませんね。

     |  Kuro  |  返信
  3. > 本当にそうですね。ちょっと試運転ということで、早速エアコンをつけてしまいました。暑すぎますねー😫

    私の部屋ではクーラーだけのウィンドウエアコンを付けてるので、夏を過ぎると季節3つ分は動かさないままなのですよね。なので、送風でしばらく動かしてあげないと、夏に稼働したてのときは内部のカビやらほこりやらがすごそう…🤤 本格的に暑くなる前にやらなくては…。

    > 親階層を表示したいということであれば、v3.8.4 で追加したタイトルバーのカスタマイズ機能 (隠しオプション) で事足りるかもしれません。

    おお、この変更は見逃していました。ありがとうございます。
    しかも、驚きの柔軟なプレースホルダー😯 いいですね!

    > [Window]
    > Title=$(Dirty) $(FileNameEx) [$(DirName)] - $(AppName)

    おお…この構成、すごく気に入りました。個人的な使い方としては直上の親フォルダー名がそのファイルの正体を見分ける情報として大事なことが多いので、頂いた設定で便利に運用できそうです。

    > ちなみに、[]() の括弧は中身が空の場合は自動的に非表示になります。

    これまた地味に感動する気遣い!さすがです 👏

     |  yuko  |  返信
  4. > なので、送風でしばらく動かしてあげないと、夏に稼働したてのときは内部のカビやらほこりやらがすごそう…🤤 本格的に暑くなる前にやらなくては…。

    久しぶりに動かした瞬間、1年前の夏にタイムリープできそうですね😆

    > しかも、驚きの柔軟なプレースホルダー😯 いいですね!

    タイトルバーのカスタマイズについては、みなさんからいろいろご意見をいただいたのですが、これがまた本当に好みがバラバラで、シンプルな落としどころを見つけるのが難しかったんです。

    それならいっそ、自由にカスタマイズできるようにしてしまおう、ということで、今のような方式にしてみました。

    > おお…この構成、すごく気に入りました。個人的な使い方としては直上の親フォルダー名がそのファイルの正体を見分ける情報として大事なことが多いので、頂いた設定で便利に運用できそうです。

    おお、それは良かったです!

    実は私も、「フルパスって本当に必要か?」と思うことが結構あって、最近はずっとこのシンプルな構成で使っています。(私の設定だと、管理者権限かどうかを末尾に付けています)

    [Window]
    Title=$(Dirty) $(FileNameEx) [$(DirName)] - $(AppName) ($(IsUserAdmin))
    

    VSCode でも基本はファイル名だけですしね。

    > これまた地味に感動する気遣い!さすがです 👏

    ありがとうございます😉

    気遣いというわけではないのですが、タイトルバーのカスタマイズを実装するにあたって一番悩ましかったのが、「項目が空のときに残る半角スペースや括弧の残骸」だったんです。

    そのため、連続する半角スペースもある程度自動で整理されるようになっています。

    副作用として、ファイル名そのものに連続するスペースが含まれている場合も対象になってしまうのですが、まぁタイトルバー用途ですし、それほど問題にはならないかな、という判断で実装しています。

    また、括弧の自動非表示は []() の2種類のみ対応しています。

    さらに、[$(DirName)] のように、括弧と項目がぴったり隣接している必要があります。

    [ $(DirName) ] ← このようにスペースが入っている場合は、括弧は残ります。

    …ということで、注意点としてはこんな感じですが、ひとまずこのタイトルバーのカスタマイズ機能で、ご希望にはある程度近い感じになりそうでしょうか?

    それとも、やはり「2階層上」「3階層上」まで表示したい感じでしょうか。

    もしそのあたりの需要がありそうなら、改めて検討してみたいと思います。

     |  Kuro  |  返信
  5. > それとも、やはり「2階層上」「3階層上」まで表示したい感じでしょうか。

    ありがとうございます!
    個人的には2階層ほどは表示されると嬉しい感じではあるのですが、とはいえ、ひとまずは1階層上でも十分便利に運用できそうですので他の方からも要望があれば、くらいでも構いません。

    ちなみに、もし実現されるのであれば、省略記号「…」を先頭に、という要望も前述でさせていただきましたが、無しの parent_dir\child_dir みたいな相対パスでも違和感はないので不要かなと考え直しました😅

    …余談ですが、私はPowerShellなどのターミナルで Starship という、シェルのプロンプトをリッチにしてくれるツールを使っているんですが、これに「現在のパス」をプロンプトに表示してくれる機能があるんです。そして、この機能では現在位置含む3階層上のディレクトリ名まで出てくるのがデフォルトになっています (なお表示階層数は truncation_length という設定で行うことができる)。この機能を目にしていたため、複数階層見られると便利かなーと思うに至った、という背景があったりします。

     |  yuko  |  返信
  6. なるほどです、詳細ありがとうございます。

    > 個人的には2階層ほどは表示されると嬉しい感じではあるのですが、とはいえ、ひとまずは1階層上でも十分便利に運用できそうですので他の方からも要望があれば、くらいでも構いません。

    たしかに、project\docs みたいな感じで、2階層ぐらい見えるとちょうど良さそうですね。

    > この機能では現在位置含む3階層上のディレクトリ名まで出てくるのがデフォルトになっています

    おー、Starship は知りませんでした。

    早速試してみたのですが、Nerd Font 周りなど環境依存もあるのか、思ったより導入のハードルは高そうですね😅 (文字化けが……)

    ひとまず、現在地のディレクトリ名が表示される機能は確認できました。

    なるほど、truncation_length みたいな階層数指定で成立している実例がある、というのは参考になります。

    省略記号 ... についても、たしかになくても違和感はなさそうですね。

    むしろ、Windows がタイトルバーに勝手に ... を入れるケースがあることを考えると、アプリ側ではあえて入れないほうがスッキリするかもしれません。

    たとえば、

    $Directory($(Path), 2)\$Directory($(Path), 1)\$(FileNameEx)parent_dir\child_dir\aaa.txt

    みたいな関数を実装したとしても、... を自動で付けたり消したりし始めると、仕様がだいぶ複雑になりそうですしね。

    とはいえ、\ は自動で消さないといけないケースが出てきそうで、これまた悩ましい感じはしますが。

    ひとまず、1階層上だけでも運用できそうとのことで安心しました😊

    ご要望が増えてきたら、そのときはいただいたご意見も参考にしながら、改めて仕様を検討してみたいと思います。

     |  Kuro  |  返信
  7. > > 個人的には2階層ほどは表示されると嬉しい感じではあるのですが、とはいえ、ひとまずは1階層上でも十分便利に運用できそうですので他の方からも要望があれば、くらいでも構いません。
    >
    > たしかに、`project\docs` みたいな感じで、2階層ぐらい見えるとちょうど良さそうですね。

    自分は、パブリックとユーザープロファイルとNASのドキュメントフォルダ以下の区別などのためフルパス表示にしているので、2~3階層というのは良い落としどころかもしれません。

     |  enaka  |  返信
  8. > たしかに、project\docs みたいな感じで、2階層ぐらい見えるとちょうど良さそうですね。

    言われてみれば、 docs みたいな全般的名称のフォルダー命名もプロジェクトフォルダー配下だとしばしばありますね。

    > 早速試してみたのですが、Nerd Font 周りなど環境依存もあるのか、思ったより導入のハードルは高そうですね😅 (文字化けが……)

    そういえば、StarshipはNerd Font導入が必要でしたね。HackGen, PlemolJP, UDEV Gothic あたりであればNerd Font追加合成版もリリースに含まれていますので、機会があればお試しください😊

     |  yuko  |  返信
  9. >> enaka さん

    > 自分は、パブリックとユーザープロファイルとNASのドキュメントフォルダ以下の区別などのためフルパス表示にしているので、2~3階層というのは良い落としどころかもしれません。

    ご意見ありがとうございます。

    なるほど、パブリックとユーザープロファイルあたりであれば、3階層ほど表示できれば十分なケースが多そうですね。

    >> yuko さん

    > 言われてみれば、 docs みたいな全般的名称のフォルダー命名もプロジェクトフォルダー配下だとしばしばありますね。

    そうなんですよね。「どこの docs やねん」となるのを避けるためにも、私も 2~3階層ぐらいは欲しくなってきました。

    > そういえば、StarshipはNerd Font導入が必要でしたね。HackGen, PlemolJP, UDEV Gothic あたりであればNerd Font追加合成版もリリースに含まれていますので、機会があればお試しください😊

    ありがとうございます。無事、Starship の文字化けを解消できました🫡

    その後も引き続き検討していまして…。

    拡張性を考えての、$Directory($(Path), 2) のような関数形式にする案でしたが、そもそもタイトルバー用途にそこまでの拡張性は必要ないのでは?と思うようになり、Starship の truncation_length を参考に、以下のような仕様案を考えてみました。

    対象のパス: C:\parent_dir\child_dir1\child_dir2\無題.txt

    • $(DirName) : 現状どおり → child_dir2
    • $(DirName:2) : child_dir1\child_dir2
    • $(DirName:3) : parent_dir\child_dir1\child_dir2
    • $(DirName:4) : C:\parent_dir\child_dir1\child_dir2
    • $(DirName:5) : C:\parent_dir\child_dir1\child_dir2
    • $(DirName:6) : C:\parent_dir\child_dir1\child_dir2
    • ※ 指定した階層数が実際の階層数を超える場合は、ルートまでを表示します。

    という感じで、関数ではなく、シンプルに :数値 で指定する方式です。

    また、上記の例でいう $(DirName:3) のように最上位フォルダーまで到達した場合に、ルート部分 C:\ を含めるかどうかについてですが、Starship ではルート部分も別階層として扱われており、上記のような仕様になっていました。

    > ※ドライブラベルはこの例のように最上位階層に到達したらセットで表示するのがいいかもしれません

    というご意見をいただいていたので、ここはちょっと悩ましいポイントですが…

    最上位フォルダーにルート部分を含めたほうが分かりやすいケースもあるとは思います。

    ただ、その場合、最上位フォルダーだけ特別扱いするかたちになりますし、C:\ 直下にファイルがあるケースとの整合性も気になります。

    特に、\\server\share\dir1\dir2 のような UNC パスでは、Windows 上では \\server\share 全体がルートとして扱われます。

    そのため、Starship と同様に「ルート部分は別階層として扱い、最上位フォルダーに到達しても自動では含めない」ほうが、仕様としては分かりやすいかな、と今のところは考えています🤔

     |  Kuro  |  返信
  10. > そうなんですよね。「どこの docs やねん」となるのを避けるためにも、私も 2~3階層ぐらいは欲しくなってきました。

    お、Kuroさんの関心も向いてきたようですね (いいぞもっとやれ)

    > という感じで、関数ではなく、シンプルに :数値 で指定する方式です。

    パッと見の分かりやすさが関数方式より高くていいと思います!

    > 特に、\\server\share\dir1\dir2 のような UNC パスでは、Windows 上では \\server\share 全体がルートとして扱われます。
    >
    > そのため、Starship と同様に「ルート部分は別階層として扱い、最上位フォルダーに到達しても自動では含めない」ほうが、仕様としては分かりやすいかな、と今のところは考えています🤔

    なるほど、UNCだとそうなっちゃうんですね。であればたしかに、別階層の方が疑問の湧きづらいシンプルな仕様だと思いますし、賛成です。

     |  yuko  |  返信
  11. 大石です。

    書き込みを見て、拙作の「MeryTabList.dll」にも実装してみました。
    こちらは、階層はComboBoxで指定するようにしました「-1,0,1,2, 25,26」。
    私の考えていた階層とは異なっていますので、「Mery」に合わせたいと思います。
    以下の場合の処理を教えてもらうと助かります。

    $(DirName:-1)を設定した場合の表記を教えて下さい。
    $(DirName:0)を設定した場合の表記を教えて下さい。
    $(DirName:1)を設定した場合の表記を教えて下さい。

    $(DirName:-1)の場合はフルパスでの表示というのはどうでしょうか?

    よろしくお願いします。

     |  大石剛司  |  返信
  12. >> yuko さん

    ご返信ありがとうございます。

    > お、Kuroさんの関心も向いてきたようですね (いいぞもっとやれ)

    完全に Starship の影響を受けまくってます😁

    > なるほど、UNCだとそうなっちゃうんですね。であればたしかに、別階層の方が疑問の湧きづらいシンプルな仕様だと思いますし、賛成です。

    ありがとうございます!では、ひとまずその方向で実装してみようと思います。

    それと、現状の $(DirName) は、C:\無題.txt の場合に空文字を返すのですが、ここは C:\ を返したほうが良さそうですね。こちらも対応しておこうと思います。

    >> 大石剛司さん

    開発お疲れ様です。

    > 以下の場合の処理を教えてもらうと助かります。
    >
    > $(DirName:-1)を設定した場合の表記を教えて下さい。
    > $(DirName:0)を設定した場合の表記を教えて下さい。
    > $(DirName:1)を設定した場合の表記を教えて下さい。

    対象のパスが

    C:\parent_dir\child_dir1\child_dir2\無題.txt
    

    の場合、$(DirName:1)child_dir2 を返します。($(DirName) と同じ意味です)

    また、数値については 1 以上を想定していて、負の値については今のところ特に考えてはいないです。

    もし対応するとしたら、

    • $(DirName:-1) : C:
    • $(DirName:-2) : C:\parent_dir
    • $(DirName:-3) : C:\parent_dir\child_dir1
    • $(DirName:-4) : C:\parent_dir\child_dir1\child_dir2

    のように、ルート側から順に返す仕様だと面白いかもしれませんね。

    たとえば、「ルート (C:) は常に表示したい」みたいな用途にも使えそうですし。

    > $(DirName:-1)の場合はフルパスでの表示というのはどうでしょうか?

    フルパスは $(Dir) で取得できるため、用途としては重複してしまいますね。

    ただ、0 の使い道は今のところ特にないので、0 をフルパス扱いにするのはアリかもしれません。

    • $(DirName:0) : C:\parent_dir\child_dir1\child_dir2
     |  Kuro  |  返信
  13. Kuroさん
    返信ありがとうございます。

    「0」は、とりあえずフルパスの設定で作成しておきました。
    今回は、マイナスの機能は保留にしました。
    「TabList」の画面内にボタンを設けて、フルパスと設定されたパスの切り替えを可能にしました。ボタンは「Ctrl+A..Z」の指定が可能です。

    最新版をアップロードしました。以下からダウンロードして下さい。
    https://www.bonsfm.com/merywindows/merytablistdllwin

    公開している「計算機能」のプラグインで、「ウィンドウ」の「タブを有効にする」がアンチェックの場合に、「Mery」がタスクに残ってしまう不具合があり修正しました。
    最新版をアップロードしました。以下からダウンロードして下さい。
    https://www.bonsfm.com/merywindows/merycalcdllwin

    よろしくお願いします。

    別件ですが、Delphi FMX で作成した iOS のアプリが完成して AppStore に公開されました。インストールしたら、なぜかVer1.00が公開されていました。最終版はVer1.11ですが更新の方法が分からなくて、現在問い合わせ中です。

    公開までは最初の申請から20日間かかりました。4回却下されて、アプリを訂正したり、表示内容の文言を変更したり、操作方法の動画やスクリーンショットを送ったり、操作関係のチェックシートを作成して結果を送ったりして、ようやく公開されました。Appleは丁寧に対応してくれますので、焦らないで対応する事が大事です。

    ソースプログラムは後日公開します。
    開発を進めていって、Delphi12 Community Edition では公開版が作成できない事が判りました。今回は、AppStore に公開が目的だったので、まず Delphi13.1の評価版を使って開発が出来ることを確認しました。確認ができたので、悩んだ末に思い切って Professional 版を購入しました。購入後には XE2 のライセンスを申し込みインストールしました。

    よろしくお願いします。

     |  大石剛司  |  返信
  14. >> 大石剛司さん

    ご返信ありがとうございます。

    > 「0」は、とりあえずフルパスの設定で作成しておきました。

    なるほどです。Mery 側でも、0 はディレクトリのフルパスを返す仕様にしておこうと思います。

    負の値については、たしかに実際の需要を見てからでも良さそうですね。

    TabList、拝見しました。タブを大量に開くユーザーさんには、とても便利そうなプラグインですね。

    表示階層の制限も、きれいに動作していますね。Mery で実装予定の $(DirName:数値) も、TabList と近いイメージになる予定です。

    計算機能プラグインの不具合修正もお疲れ様です。

    > 別件ですが、Delphi FMX で作成した iOS のアプリが完成して AppStore に公開されました。

    おめでとうございます!

    「釣り日記 FishingDiaryEx」、App Store で拝見しました。

    残念ながら、私の iPhone はいまだに iOS 12 なのでインストールできませんでしたが…

    Delphi ユーザー + 釣り好きとしては、かなり気になります。

    ちなみに、私は海釣りメインなのですが、ルアーはいっぱい持っているのに、ルアーで釣れた記憶がほぼありません😫

    > インストールしたら、なぜかVer1.00が公開されていました。最終版はVer1.11ですが更新の方法が分からなくて、現在問い合わせ中です。

    これはちょっと怖いですね…。

    最新版を出したつもりで旧版が公開されてしまうのは、かなり焦りそうです。

    無事に解決できることを祈っています。

    > 公開までは最初の申請から20日間かかりました。4回却下されて、アプリを訂正したり、表示内容の文言を変更したり、操作方法の動画やスクリーンショットを送ったり、操作関係のチェックシートを作成して結果を送ったりして、ようやく公開されました。Appleは丁寧に対応してくれますので、焦らないで対応する事が大事です。

    4 回却下は精神的にもかなり大変そうですが、そこを乗り越えて公開までたどり着いたのはすごいです。改めて、おめでとうございます!

    操作動画やチェックシートまで必要になるとは、Apple の審査はやはり細かいですね…。

    > 開発を進めていって、Delphi12 Community Edition では公開版が作成できない事が判りました。

    ええっ!Delphi 12 の機能的な制限でしょうか。それとも Community Edition のライセンス上の制限でしょうか。

    ともあれ、Delphi 13.1 をご購入されたとは!

    最近の Delphi はいくらぐらいなんだろうと思って調べてみたら、想像以上のお値段でびっくりしました…。

    これはもう、ばりばり開発しないとですね😁

    > 購入後には XE2 のライセンスを申し込みインストールしました。

    それは必須ですね。

    とはいえ、私も他人事ではなくて、もし Mery 開発用 PC (XE2 環境) が壊れたら、Delphi 買い直しコースが待っているので震えています…😱

     |  Kuro  |  返信
  15. 大石です

    >>ええっ!Delphi 12 の機能的な制限でしょうか。それとも Community Edition のライセンス上の制限でしょうか。
    >>ともあれ、Delphi 13.1 をご購入されたとは!

    動作目的の iPhone が iOS26 で、これに対応する Xcode が Xcode26 です。
    また AppStore からダウンロードできる Xcode は最新版のみです。
    この Xcode26 に対応しているのが今年の 3月にリリースされた Delphi 13.1 です。

    財布には厳しかったですが、3週間悩んだ末に購入しました。
    開発を進めていますが、購入して良かったです。

    実は 10年前に Xcode + StoryBoard で釣り日記のアプリを開発をしています。
    その時のソースプログラムを見ましたが、自分で作成したアプリのソースですが、今の自分では理解できそうもない感じでした。
    慣れ親しんだ Delphi で開発ができ、Windows でも iOS でも動作する Delphi は素晴らしいと思います。

    よろしくお願いします。

     |  大石剛司  |  返信
  16. ご返信ありがとうございます。

    > この Xcode26 に対応しているのが今年の 3月にリリースされた Delphi 13.1 です。

    なるほど、そういう事情だったのですね。勉強になりました。

    しかし、App Store から最新版しかダウンロードできないのは、なかなか厳しい仕様ですね…。

    > 実は 10年前に Xcode + StoryBoard で釣り日記のアプリを開発をしています。

    おおっ、10 年前から作られていたのですね!

    昔の自分のコードを見て「読めない…」っていうの、ものすごく共感します。

    私も以前、Mery の片手間で C++ のアプリを作っていたことがあるのですが、今読み返したら、たぶん理解できない自信があります😭

    その点、Delphi で Windows と iOS の両方を開発できるのは、やはり強いですね。

    Delphi は「開発速度の速さ」が最大の魅力だと思っています。思いついたものをサッとかたちにできる感じが気持ちいいんですよね。

    iOS アプリ開発、今後の展開も楽しみにしています!

     |  Kuro  |  返信
  17. >動作目的の iPhone が iOS26 で、これに対応する Xcode が Xcode26 です。
    >また AppStore からダウンロードできる Xcode は最新版のみです。

    古いXcodeは以下のその他からダウンロードできますが、もしかして最新Xcode以外はiOSの審査は不可なのでしょうか。
    https://developer.apple.com/jp/xcode/resources/

    中古のMac Pro (Mid2006)とMacBook Pro (13.3inch Early2013)とMacBook Pro (15.4inch Mid2014)とMacBook Air (11.6inch Early2015)しか持ってないので最近のMacはさっぱりです。

     |  enaka  |  返信
  18. 大石です。

    以下の記載があります。
    >>iOS/iPadOSアプリは、iOS/iPadOS 26 SDK以降でビルドする必要があります
    となると、Dlphi13.1 が必要になります。
    また、Xcode は 26 以降となり、macOSは Sequoia15.6 以降が必要です。

    公開するには比較区的新しい Mac と Delphi13.1 以降が必要になる感じで、簡単には手は出せないですね。
    以前にも書きましたが、MacBooK Pro M2 2022 で Thahoe 26.3.1 を購入しています。
    Delphi13.1 も今回購入しました。

    釣り日記 FishingDiaryEx の最新版はアップロードして無事に公開されました。
    審査を受けるバージョンは自分で設定が必要です。
    初版をアップロードして、訂正版をアップロードしたら最新版が有効になると思い込んでいました。
    今回は公開されたアプリの最新版をアップロードして、審査に提出するアプリのバージョンの選択画面が出たので最新版を指定しました。
    アプリの更新なので、一回の申請で、1日で公開されました。

    現在も機能を更新中で、「釣り日記」の項目を変更した「猫日記」を作成中です。
    ソースは95%が共通で、項目の名称とアプリのアイコンが異なるだけです。

    以下は、Apple の情報です。
    https://developer.apple.com/jp/app-store/submitting/

    新しいOSのリリースに関するアップデート
    iOS、iPadOS、macOS、tvOS、visionOS、watchOS向けの最新のSDKに対応するXcode 26でビルドとテストを行い、
    Appleプラットフォームの最新テクノロジーを活用できます。
    最新のOSを搭載したAppleデバイスでアプリやゲームが正常に動作することをご確認ください。
    2026年4月以降、アプリやゲームをApp Store Connectにアップロードする際は、以下の最小要件を満たす必要があります。

    iOS/iPadOSアプリは、iOS/iPadOS 26 SDK以降でビルドする必要があります
    tvOSアプリは、tvOS 26 SDK以降でビルドする必要があります
    visionOSアプリは、visionOS 26 SDK以降でビルドする必要があります
    watchOSアプリは、watchOS 26 SDK以降でビルドする必要があります

    よろしくお願いします。

     |  大石剛司  |  返信
  19. 情報提供ありがとうございます。

    > 公開するには比較区的新しい Mac と Delphi13.1 以降が必要になる感じで、簡単には手は出せないですね。
    > 以前にも書きましたが、MacBooK Pro M2 2022 で Thahoe 26.3.1 を購入しています。
    > Delphi13.1 も今回購入しました。

    Delphiもですが、自分でも手が出せるMacBook Neoだと開発に使うには厳しそうです。MacBook Airも20万円の大台に乗ってしまったし。

    > 釣り日記 FishingDiaryEx の最新版はアップロードして無事に公開されました。
    > 審査を受けるバージョンは自分で設定が必要です。
    > 初版をアップロードして、訂正版をアップロードしたら最新版が有効になると思い込んでいました。
    > 今回は公開されたアプリの最新版をアップロードして、審査に提出するアプリのバージョンの選択画面が出たので最新版を指定しました。
    > アプリの更新なので、一回の申請で、1日で公開されました。

    クルスタの話とかから、バージョンアップの審査も厳しいと思ってました。
    偶にバージョンアップでプラグイン的に機能追加する隠し動作を入れて、悪意あるプログラムを密かにダウンロードするアプリとかもありしますし。

    > 現在も機能を更新中で、「釣り日記」の項目を変更した「猫日記」を作成中です。
    > ソースは95%が共通で、項目の名称とアプリのアイコンが異なるだけです。

    釣りも猫も無縁ですが、近所の二つ池公園でバス釣りでも始めようか。隣の三ッ池公園はなぜか釣りNG。
    配信ページにリンクしたり視聴予約通知とかできる、動画視聴日記とかほしいかも。

    > 2026年4月以降、アプリやゲームをApp Store Connectにアップロードする際は、以下の最小要件を満たす必要があります。
    >
    > iOS/iPadOSアプリは、iOS/iPadOS 26 SDK以降でビルドする必要があります

    Appleが旧環境の審査を続ける人的負担を考えたら仕方がないですね。
    ローカルなら旧環境でビルドできるだけでも助かっています。

     |  enaka  |  返信
スポンサーリンク