ビルド版のクライアントアプリは，公開名またはIPアドレスに基づき，自動的にサーバーを発見して接続を試みますが，Altキーを押しながら起動することにより，「サーバーに接続」ダイアログでサーバーを指定することもできます。同一マシン上に同名のクライアントアプリがインストールされている場合，それぞれのクライアントで接続したサーバーの情報は，いずれも同じ設定ファイルに記録されるため，最後に終了したクライアントのサーバーがデフォルトのサーバーとなります。これは仕様です。
サーバー側のキャッシュフォルダーパスは「アプリケーション/ストラクチャ名」です。v18r5以降，ビルドプロジェクトファイル（buildApp.4DSettings）のServerStructureFolderNameでキャッシュフォルダーパスのストラクチャ名を設定できるようになりました。この仕組みは，同名のサーバーアプリケーション（たとえばバージョン違い）を同一マシンにインストールするような場合に便利です。
https://blog.4d.com/multiple-instances-of-merged-server-applications-on-the-same-machine/
サーバー側のキャッシュフォルダー名は，Info.plistファイルに書き込まれています。
<?xml version="1.0" encoding="UTF-8" standalone="no" ?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>com.4d.ServerCacheFolderName</key>
<string>myCacheFolder</string>
</dict>
</plist>
クライアント側のキャッシュフォルダー名は「ストラクチャ名_サーバーアドレス_ポート番号_ハッシュ値」です。３桁のハッシュ値は，クライアントアプリのファイルパスに基づいて計算されます。v18r5以降，ビルドプロジェクトファイル（buildApp.4DSettings）のClientServerSystemFolderNameでキャッシュフォルダー名をカスタマイズできるようになりました。この仕組みは，別々のサーバーに接続する同名のクライアントアプリケーションを同一マシンにインストールするような場合に便利です。
https://blog.4d.com/multiple-servers-one-shared-local-resources/
クライアントアプリは，ストラクチャ名・サーバーアドレス・ポート番号がすべて一致するローカルキャッシュを利用し，内容が変更されていない限り，サーバー側のキャッシュからリソースをダウンロードしません。この仕組みにより，後から同名の別サーバーに接続したクライアントアプリにより，キャッシュフォルダーが書き換えられてしまうことはありません。
クライアント側のキャッシュフォルダー名は，データベースリンクファイル（.4DLink）で指定することもできます。
<database_shortcut
is_remote="true"
server_database_name="Test"
server_path=":19813"
cache_folder_name="clientCacheFolderName" />
つまり，ビルド版クライアントアプリのEnginedServer.4DLinkと同じ使い方ができます。
v18では，起動後，すぐにサーバーに接続するクライアントアプリ（過去バージョンの4D Client）ではなく，ビルド版のデスクトップアプリから任意のタイミングでサーバーに接続することができます。下記の要領でサーバーに接続することができます。
OPEN DATABASE("path_to_server.4dlink")
起動時にサーバーを検索する代わりにローカルのデータベースプロジェクトを開始するには，ビルドプロジェクトファイル（buildApp.4DSettings）のDatabaseToEmbedInClientWinFolder DatabaseToEmbedInClientMacFolder を使用します。これらのキーが設定されている場合，EnginedServer.4Dlink の代わりにデータベースプロジェクト（.4DC または .4DZ）がビルド版クライアントアプリの Database フォルダーにコピーされます。Default data の仕組みを併用することにより，初回起動時に「データファイルを開く」ダイアログが表示されることを回避できます。
https://blog.4d.com/deployment-made-easy-with-4d-v18/
DELETE RECORDとDELETE SELECTIONでは，レコードロックの仕組みが異なるため，トリガの振る舞いに違いが存在します。後者の場合，複数のレコードがロックされている可能性があるため，LockedSetシステムセットに削除できなかったレコードの情報が記録され，レコード毎にエラー処理メソッドが実行されることはありません。これは仕様です（v2004以降）。v2003では，削除できなかった最初のレコードでON ERR CALLメソッドが実行され，DELETE SELECTIONの処理は中止され，以降のレコードすべてがLockedSetシステムセットに追加されました。現行バージョンでは，レコードが削除できなかった場合，ON ERR CALLメソッドは実行されず，LockedSetシステムセットが更新されるだけで，DELETE SELECTIONの処理は継続されます。これにはトリガで削除が防止されたレコードも含まれます。
下記の記述（「コマンドの実行は即座に停止し・・・」）はv2003の振る舞いを説明しています。
レコードのセレクションで動作しているコマンドのフレームワーク内のトリガーによってエラーが生成されると (DELETE SELECTIONのような) ，コマンドの実行は即座に停止し，セレクションは必ずしも完全に処理されません。この場合は，デベロッパーによる適切な処理が必要となります。例えばセレクションを一時的に保存したり，トリガーの実行前にエラーを取り除くなどの処理が必要です。
https://doc.4d.com/4Dv15/4D/15.6/Triggers.300-3817569.ja.html
現バージョンの振る舞いは下記のとおりです。
レコードのセレクションで動作しているコマンドのフレームワーク内のトリガーによってエラーが生成されると (DELETE SELECTION，APPLY TO SELECTION，ARRAY TO SELECTIONなど)レコードは処理されず，自動的にLockedSet に登録されます(セット 参照)。コマンドは終わりまで実行が続けられ，このときエラーはキャッチされません。つまりエラーハンドリングメソッドは(あったとしても)呼び出されません。このコンテキストにおいて，エラーが生成されたかどうかを確認するためには，コマンドの呼び出しの直後にLockedSet をテストする必要があります。また，トリガでは，エラーをあとで適切に管理するためには，エラーコードを例えばコレクションなどに保存する必要があります。
https://doc.4d.com/4Dv18R6/4D/18-R6/Triggers.300-5199080.ja.html
Mac版の「名前を付けて保存」ダイアログでは，キーボードショートカットの編集メニュー（コピー・カット・ペースト）が使用できません。これは仕様です。4Dのメニューは，独自のコードを実行するようにカスタマイズされているため，Cocoaの標準アクションと互換性がありません。ファイル名のコピー＆ペーストには，コンテキストメニューを使用してください。
Webエリアがページを読み込んでいる間にフォームを閉じたり，フォームのページを切り替えたりすることがないようにしてください。Windowsの場合，タイミング次第ではアプリケーションがクラッシュするかもしれません。WebエリアでURLを開いた場合，On End URL Loadingイベントが発生するまでウィンドウが閉じられることがないように対策を講じる必要があります。
Windows版のマルチスタイルテキストのコンテキストメニューでフォントサイズ（たとえば15）を選択した場合，ソースコードのHTMLには別の数値（たとえば20pt）が挿入されます。これは仕様です。 Macでは，フォームのフォントサイズとspanに書き込まれるフォントサイズの値が一致しますが，Windowsでは72/96倍の値になります。spanには，4Dのフォントサイズではなく，システムのフォントサイズが記録されるようになっているためです。
フォームのDPIは，プラットフォームに関係なく72です。フォームエディター等でフォントサイズを20（つまり20px）に設定した場合，システムのDPIが72であるMacでは20ptのテキストが表示されますが，システムのDPIが96であるWindowsでは15ptのテキストが表示されます。マルチスタイルテキストのソースコードには，システムのフォントサイズ（Windowsであれば15pt）が記録されることになります。
v12でマルチスタイルテキストが追加されたとき，ソースコードにシステムのフォントサイズを記録することにしたのは，明らかに悪い決定でした。クロスプラットフォームの振る舞いではないからです。しかし，過去のバージョンで作成されたアプリケーションに配慮し，現在も上述したような仕様となっています。
Googleのブログで説明されているように，組み込みレンダリングエンジンにブラウザの操作を模倣させてGoogleサービスにログインすることはできなくなりました。Googleユーザー認証には，実際のブラウザを使用するか，OAuth 2.0の手順を踏む必要があります。WebエリアでGmailなどのサービスにログインを試みた場合，「このブラウザまたはアプリケーションは安全ではない可能性があります」というエラーメッセージが表示され，先に進むことができません。これは仕様です。