Mac版のビルドアプリケーションをネットワーク経由で配付するためには，アプリをコード署名する必要があります。アプリの構成ファイルを署名後に変更すると，コード署名が無効となるので，アプリの中に暫定的なファイルを含めることは推奨されていません。これにはWebサーバーのTLS証明書も含まれます。証明書には，有効期限があるためです。Mac版では，データベースフォルダー内の証明書を暗黙的に使用するのではなく，新しいWEB Serverコマンドを使用し，certificatesFolderでアプリ外のパスを指定するようにしてください。
ODBCドライバー経由でOracleデータベースにアクセスする場合，文字セットの設定をUnicodeにする必要があります。
環境変数NLS_LANGは<LANG>_<SUBLANG>.AL32UTF8というフォーマットで設定することができます。区切り文字がアンダースコアとピリオドであることに留意してください。デフォルトはWE8MSWIN1252のように特定の文字セットとなっています。多言語のデータを扱うためには，SUBLANGに加えてAL32UTF8も設定する必要があるかもしれません。たとえば，下記のように設定することができます。
NLS_LANG=JAPANESE_JAPAN.AL32UTF8
クライアント側でトランザクション中にオブジェクト型フィールドを何度か更新した場合，entity.save(dk
auto merge)が成功しないことがあります。
クライアント/サーバー版のORDAでは，トランザクションを確定またはキャンセルした後，サーバー側で更新されたエンティティを明示的にリロードする必要があるかもしれません。たとえば，クライアント側でトランザクション中にエンティティを更新した場合，その時点ではクライアント側にあるエンティティのスタンプ値はインクリメントされておらず，古いスタンプ値のままとなっています。そのようなときは，一旦，トランザクションを確定またはキャンセルした後，エンティティを保持している変数にNullをセットする，dataClass.get() entity.reload()などの方法で最新のエンティティをサーバーからリロードした上で次のトランザクションを開始することができます。
Windows版でSET DATABASE PARAMETERでDirect2D statusをDirect2D disabledにセットした場合，Write Proエリアは使用できなくなります。これは仕様です。v17のWrite Proエリアは，GDI/GDIPlusモードが残されていたので，Direct2Dモードが無効にされていてもレンダリングすることができました。これは，デバッグ目的の措置であり，Direct2Dのない環境でWrite Proエリアは正式にサポートされていませんでした。
必要要件: Windows上では，4D Write Proの機能はDirect2Dに依存しています。Windows 7またはWindows Server 2008以降のマシンでは，必要なバージョンのDirect2Dを利用可能にするために，Windowsプラットフォーム更新プログラムがインストールされていることを確認して下さい。
アプリの高DPI設定が有効にされている場合（19r4以降のデフォルト），Direct2Dモードは必須であり，無効にすることはできません。その場合，SET DATABASE PARAMETERでDirect2D statusをDirect2D disabledにセットしても無視されます。
Write Proドキュメントの更新
Write Proエリアに表示されたドキュメントに対してWP SET ATTRIBUTESを使用した場合，フォームの編集メニューに操作が記録されます。取り消し/やり直しができるようにするためです。ユーザーがドキュメントに加えた変更も履歴に残ります。編集メニューの履歴には，特にサイズの制限がないため，ループ処理でコマンドを使用した場合，膨大な量の操作が記録されるかもしれません。コマンドでドキュメント大幅に変更し，特にやり直しをする必要がないのであれば，Write Proエリアにドキュメントを表示する前に，オフスクリーンでWrite Proドキュメントを加工することを検討してください。フォームに表示されていないドキュメントには取り消し/やり直しの履歴が存在しないため，より効率的に更新することができます。
ツールボックスのスタイルシートは，プラットフォーム間に存在するフォントの違いをある程度は解消することができますが，簡易的なシステムであり，できることには限界があることを理解する必要があります。たとえば，MacとWindowsで別々のフォントが割り当てられたスタイルシートをオブジェクトに設定し，Macで作成したフォームをWindowsで開くと，オブジェクトの高さが変化します。そのフォームをWindowsからMacに戻すと，再び高さが変化しますが，元の高さに戻るわけではありません。これはドキュメントに説明されていることであり，仕様です。
注: オブジェクトに他のプラットフォームのフォントが設定されている場合，その高さはカレントのプラットフォーム用に選択されたフォントに適するよう自動で調整されます。 オブジェクトを描画する際この点を考慮に入れるべきです。
UUIDでは，16進数の13桁目および17桁目にそれぞれアルゴリズムとバリアント（変種）のコードが出力される場合があります。たとえばバージョン４のバリアント１であれば，13桁目が常に4，17桁目が8からbの値になります。
Windows版の4Dでは，UUIDのバージョンコードが13桁目ではなく15桁目に出現します。Mac版は慣例どおり13桁目です。言い換えるならば，値は確かにUUIDですが，フォーマットはMicrosoftのGUIDやCLSIDのものを踏襲しており，Macと比較すると，HHHHHHHH-HHHH-HHHHグループがそれぞれバイトスワップされたような格好になっています。これはプラットフォームの設計に由来する仕様です。
128.1-128.08という数式を4Dで評価すると0.01999999999998という値が返されます。127.1-127.08であれば0.02が返されるのとは対照的です。
プログラミングで小数を扱う場合，実数は近似値を表現したものであることを憶えておきましょう。小学校で習った算数とは違うことをしている，ということです。計算の結果がぴったり割り切れるかどうかは，実数の内部的なデジタル値に左右されます。上述した例では，どちらも「およそ0.02」という近似値が返されているのであり，これを「およそ等しい」と判定するために SET REAL COMPARISON LEVELのような仕組みが存在します。これは計算間違いではなく仕様です。