データストアクラス（Entity, EntitySelection, DataClass）のメンバー関数は local 指定しなければサーバー側で実行されますが，オブジェクトまたはコレクションにクライアント/サーバー環境でネイティブオブジェクトをカプセル化して返すことはできません。これは仕様です。ネイティブオブジェクトには，Entity, EntitySelection, DataClass, DataStore, Pointer, File, Folder, CryptoKey, WebServer などが含まれます。
近年のWebブラウザおよびレンダリングエンジンは，window.originでページのオリジンを参照することができなくなっています。たとえば，v19の統合Webエリアでファイルを開いた場合，window.originはfile://を返しますが，v20の統合Webエリアでファイルを開いた場合，window.originはnullを返します。現行のAPIはwindow.location.originです。
https://stackoverflow.com/questions/55451493/what-is-window-origin
マウス等のデバイス操作によるスクロールイベントは，マウスポインターの直下にあるアクティブなオブジェクトに送信され，そのオブジェクトがイベントを処理しない場合，その直下にあるオブジェクトに伝播します。v18以降，ホイールイベントを処理しないオブジェクト（ボタンなど）については，イベントが親オブジェクト（サブフォームコンテナ）に伝わるよう動作が見直されました。
リストボックスやテキスト入力オブジェクトなど，ホイールイベントに対応しているオブジェクトについては，イベントは親オブジェクトに伝播しないので，サブフォーム内でマウスポインターの直下にこれらのオブジェクトがある場合，そこからサブフォーム自体をスクロールすることはできません。
プロジェクトモードでは，フォームのプロパティ全般を.cssファイルで定義することができます。Webページのそれとは違い，フォームオブジェクトのプロパティ全般にスタイルシートが使用される点に留意してください。
スタイルシートは，フォームを開いたタイミングで一度だけ評価されます。つまり動的なものではありません。たとえば，下記のような.cssを記述し，macOSのダークモードとライトモード向けに暗いブルーと明るいブルーを設定した場合，モードの切り替えに応じてウィンドウの背景色やフォントカラー（この例ではautomatic）は動的に変化しますが，オブジェクトの背景色が動的に変化することはありません。これは仕様です。
@media (prefers-color-scheme: light){
.blue {
fill: #98bfe0;
stroke: automatic;
}
}
@media (prefers-color-scheme: dark){
.blue {
fill: #344a6d;
stroke: automatic;
}
}
Logs フォルダーには，プロジェクトが使用するすべてのログファイルが格納されます。 v18以降，このフォルダーはデータファイルと同階層に作成されるようになりました。
v17以前の Logs フォルダーはストラクチャファイルと同階層に作成されました。ビルド版アプリケーションの場合，通常は書き込み禁止であるディレクトリにコンパイルされたストラクチャファイル（ .4DC ）またはパッケージされたプロジェクトフォルダー（ .4DZ ）が置かれます。ログファイルは，ストラクチャファイルではなく，データファイルと同階層に作成したほうが実際的です。データファイルは基本的に書き込みができるディレクトリに作成されるからです。
Logs フォルダーのパスは，下記いずれのコマンドで取得することができます。
上記の Logs フォルダーとは別に，Maintenance & Security Centerが出力するメンテナンスログファイルを記録するための Logs フォルダーが存在します。こちらのフォルダーは，Get 4D folderからパスが返されるユーザー設定フォルダーに作成されます。なお，本来の Logs フォルダーが使用できない場合，プロジェクトが使用するログファイルもこちらのフォルダーに記録されます。
特定のコマンドが処理に3秒以上を要する場合，デフォルトで進捗バーが自動的に表示されます。v18r3以降，同等のORDAオペレーションでも進捗バーが表示されるようになりました。
時間がかかっている処理に関する情報を収集したい場合，START MONITORING ACTIVITYに閾値とオペレーションのタイプを指定することができます。オペレーションのタイプは，ランゲージ・ネットワーク・データベースオペレーションの組み合わせで指定します。
オペレーションのタイプにランゲージを含めた場合，SET DATABASE PARAMETERと Log command list で監視するコマンドを指定することができます。その場合，コマンド番号をひとつずつセミコロン区切りで列挙するか，負のコマンド番号をセミコロン区切りで列挙することにより，監視の対象から除外することができます。
PHP Executeを実行すると，プロジェクトの/RESOURCES/フォルダーに既定の php.ini ファイルが（なければ）コピーされます。このファイルには，4D_Execute_PHP.php （4D/PHP間でパラメーターのデータ型を自動的に変換したり，PHPの関数を直接コールするためのユーティリティスクリプト）のパスが記述されています。このファイルは，ビルドしたphp-cgiをphp-fcgi-4dにリネームし，内部PHPインタープリターの代わりに使用する場合にも使用されます。
外部PHPインタープリターを使用する場合，PHP Executeに備えて事前にPHPを起動する必要があります。プロジェクトの/RESOURCES/フォルダーの php.ini ファイルは使用されません。コマンドライン引数で明示的に初期化ファイルのパスを渡す必要があります。これは仕様です。
ドキュメントには「サーバー上で禁止されるコマンド」および「サーバー上で使用すべきでないコマンド」が列挙されています。過去バージョンのドキュメントでは，下記の印刷関係コマンドも「サーバー上で禁止されるコマンド」として挙げられていました。現行バージョンにそのような制約はありません。見直されたリストはv20のドキュメントに掲載されています。
現在ベータ版が公開されているフィーチャーリリース（v20 R2）は，Windows Server 2012 R2プラットフォーム非対応となります。当該バージョンでは，統合Webエリアが使用しているCEF (Chrome Embedded Foundation) のアップデートとセキュリティ強化が反映されており，2012 R2で起動するとDiscardVirtualMemoryエントリーポイントがみつからない，というエラーメッセージが表示されます。
Windows Server 2012 R2のサポート終了日が近づいているため，今後，4D v20は，CertifiedではなくCompatibleレベルでWindows Server 2012 R2対応となります。