Mac 的作業系統自從演進到 Mac OS X 之後，有一項不小的變革，就是 resource fork 在某種程度上被揚棄了。傳統的 Mac 檔案上可以由兩種部份組成，一是 data fork，一是 resource fork。一般的主要資料和程式碼多半存在於 data fork，而 resource fork 裡則記載著各種各具特定格式的資料，程式設計師只要運用適當的工具，即可方便且有系統地進行調整。雖然 resource 在 Mac OS X 中仍然可以使用，但 Cocoa 程式幾乎已完全不用傳統的 resource fork 來存放類似的資料，前幾年蘋果也曾刊出文件、希望開發者不要再用到 resource fork，不過由於 resource fork 在 Mac 上具有一些獨特的優勢，許多程式設計師對此有相當的反彈。

Resource fork 被放棄後是否已達到很大的好處我們無法斷言，但其壞處已經出現，這表現在文字處理上，就是軟體已無法自動辨識文字檔的語系。目前電腦上文字編碼種類繁多，但在 Mac OS 9 下即使是打開純文字檔，文書軟體也能知道裡頭的文字是什麼語系（或編碼），這是因為文字檔的字體、語系等資訊都可以記錄在 resource 中。相對之下，在 Mac OS X 下缺少 resource 的文字檔就不一定能被 TextEdit 順利打開，一定要事先在偏好設定中選好要用什麼編碼來開啟檔案，否則就會無法開啟，這在需要打開編碼各異的幾個文字檔時，就變得非常麻煩。例如我們要打開一個 Big 5 的文字檔、一個 GB 的文字檔、以及一個 UTF-8 的文字檔，前後可能必須分別到偏好設定中做三次設定才行。

當然，也許蘋果方面會認為這只是過渡時期的陣痛而已，因為往後系統的文件應該只會採用 Unicode，不再使用傳統的各式不同編碼，而且 RTF 也要取代純文字檔，成為 Mac OS X 通用的文字檔格式，也就不必用到 resource fork 來記錄文字樣式與語系。但問題是，即使 Unicode 也有多種編碼方式，例如 UTF-8 與 UTF-16，所以一個純文字檔會採用何種編碼仍無法預測，而且各式傳統文字編碼（例如中文的 Big 5、GB 及日文的 Shift JIS）短時間內也應不至於完全消失。另外許多文件存在的形式仍是純文字檔，例如網路上常用的 HTML、PHP、CSS 等，而現在的架構只是使得這類檔案的處理更為不便。

Resource fork 顯然還是有其優點的。當然因為 Mac OS 的基礎已轉換到 UNIX 上、且為了與其他平台能有更大的交換性，放棄 resource fork 似乎是不得不然的，只是這也不是蘋果放棄 Mac 特殊優勢的唯一例子，這些改變對傳統 Mac 使用者來說，不管在情感上或習慣上都不一定能很快接受吧。