In a 1986 technical note, Apple strongly recommended that developers do not put general data into the resource fork of a file.
The presence of a resource fork makes it easy to store a variety of additional information, such as an icon that the desktop should display for that file.
The Mac BinHex and MacBinary formats were invented to encode resource and data forks into one file, for transfer between systems.
This arrangement is very powerful – it permits local resources to override more global ones lower down – so an application can provide its own icons or fonts in place of the standard system ones, for example.
Resource Manager APIs allow the programmer to manipulate the stack and modify the search behaviour.
This uses a dedicated language, also called Rez, which can be used to create a resource fork by compiling source code.
After a resource fork is accessed, its contents can be found by reading it in as appropriate for the data types defined in advance.
Using this method increases the visibility of the data when viewed with a program such as ResEdit, making later editing simpler.
As the Macintosh platform originated with Motorola-based processors (68k and PPC), the data is serialized to disk in big-endian format.
The SMB protocol supports a file metadata system similar to Macintosh forks known as Alternate Data Streams (ADSes hereafter).
macOS did not support storing resource forks in ADSes on SMB volumes by default until Mac OS X v10.6.
This is also true when writing to certain types of local file systems, including UFS, and on SMB volumes where Alternate Data Stream support is not enabled.
Another challenge is preserving resource forks when transmitting files using non-resource fork-aware applications or with certain transfer methods, including email and FTP.
Command-line system tools SplitForks and FixupResourceForks allow manual flattening and merging of resource forks.
Older applications written with the Carbon API have a potential issue when being ported to the current Intel Macs.
Until the advent of Mac OS X v10.4, the standard UNIX command-line utilities in macOS (such as cp and mv) did not respect resource forks.
The concept of a resource manager for graphics objects, to save memory, originated in the OOZE package on the Xerox Alto in Smalltalk-76.
Early versions of the BeOS implemented a database within the file system, which could be used in a manner analogous to a resource fork.
Its executable files are internally divided into a modular structure of large pieces (hunk) capable of storing code, data, and additional information.
A dialog box accessible by right-clicking the icon allows the user to see and modify the metadata present in the .info file.
Under these systems the resources are left in an original format, for instance, pictures are included as complete TIFF files instead of being encoded into some sort of container.
This approach was not an option on the classic Mac OS, since the file system (MFS) did not support separate catalog directories.
When catalog file support was included in Mac OS, with the HFS filesystem, the resource fork was retained.
macOS does retain the classic Resource Manager API as part of its Carbon libraries for backward compatibility.