Before the rise of cloud drives and cross-platform file systems, Apple built a native solution tailored for its own ecosystem—Apple Filing Protocol (AFP). Developed by Apple in the 1980s, AFP served as the cornerstone of file sharing across early Macintosh networks. Not merely a protocol, but the default method for transmitting files between Mac devices, AFP integrated tightly with the classic Mac OS, offering features like resource fork support and user authentication through AppleShare.
Originally introduced as part of AppleShare in System 6, AFP emerged at a time when networked computers were uncommon in home and small office environments. Its optimization for Mac hardware and software made it the go-to protocol for seamless integration across Apple-only infrastructures. Long before SMB and NFS became widespread choices, AFP defined how early Apple users shared files, collaborated, and managed permissions over LocalTalk and later Ethernet-based networks.
Curious how AFP maintained relevance for decades, or why Apple eventually phased it out? Keep reading to explore the evolution, architecture, and enduring impact of Apple’s first native file sharing protocol.
Apple Filing Protocol (AFP) is a network protocol designed specifically for file sharing on Apple systems. Developed by Apple Inc., AFP allows users to access and manage files on remote servers in a manner optimized for the macOS environment. Unlike open-standard protocols, AFP remains proprietary and tightly integrated with Apple’s ecosystem.
From the outset, AFP catered exclusively to Apple hardware and operating systems. It handled resource forks, metadata, and Apple-specific features with precision, offering support for HFS and later HFS Plus volumes. This specific optimization made it the default network file system for Mac OS through many iterations—including the classic Mac OS up to macOS High Sierra for particular use cases.
AFP doesn’t exist in isolation. It operates in a landscape dominated by other protocols such as SMB (Server Message Block) and NFS (Network File System). Here's how it stands apart:
This Apple-centric focus enabled AFP to deliver efficient file sharing across Mac networks, particularly in environments that required precise file metadata support—such as creative studios, education labs, and business departments using macOS clients and servers.
Apple Filing Protocol first emerged during the 1980s, developed specifically to support file services over Apple’s proprietary AppleTalk networking system. Integrated deeply into classic Mac OS, AFP was designed to provide seamless file sharing between Macintosh systems, avoiding compatibility complications with third-party protocols. Under the hood, it operated on the AppleTalk Filing Protocol (AFP over DDP), a data-delivery system that leveraged AppleTalk’s Datagram Delivery Protocol (DDP) to manage file transactions.
This strategy offered plug-and-play networking, self-configuring devices, and human-readable service naming — a stark contrast to the more technical and manual configurations required in Network File System (NFS) or Server Message Block (SMB) environments of the time.
As IP networking became dominant in enterprise and consumer environments throughout the 1990s, Apple adapted AFP accordingly. With the release of Mac OS 9 and then Mac OS X 10.0, AFP gained support for TCP/IP-based transport, parallel to its traditional AppleTalk compatibility. This dual-mode operation allowed Macs to interact across increasingly heterogeneous networks.
Starting with AFP 2.2 in Mac OS X, TCP/IP grew to be the favored transport layer. By AFP 3.0, Apple streamlined support for IP-based operations, setting the stage for deprecating AppleTalk entirely. This version brought enhancements to Unicode file name support, larger file sizes, and increased data throughput by eliminating packet size restrictions inherent in AppleTalk.
The official removal of AppleTalk support came with Mac OS X 10.6 Snow Leopard in 2009. At that point, Apple eliminated both user-facing and under-the-hood support for AppleTalk, completing the networking transition that began nearly a decade earlier. AFP remained the default file sharing protocol but was now functioning exclusively over TCP/IP. This allowed greater interoperability with modern network hardware and infrastructure while maintaining backward compatibility with older AFP clients running over IP.
This evolution underscored Apple’s shift toward open standards and IP-based interoperability, while still retaining features uniquely optimized for Mac environments.
In macOS networking architecture, Apple Filing Protocol (AFP) operated at the application layer, sitting above the TCP/IP stack and leveraging port 548 for communication. It facilitated file sharing between Macs by providing a structured communication mechanism for file requests, metadata retrieval, record locking, and client authentication. Under the hood, AFP handled resource forks, extended file attributes, and other intricacies of HFS+—macOS’s native file system prior to APFS.
macOS managed AFP services through the Apple File Service daemon (afpd) in earlier versions, and later via netatalk in UNIX-style deployments. When a client sent a file read or write request, AFP parsed it, authenticated the session using protocols like Kerberos or cleartext (depending on configuration), and responded with data that preserved the file system’s integrity and structure.
From macOS Server 10.0 up to 10.6 Snow Leopard Server, AFP served as the default protocol for file sharing. Administrators interacting through the Server Admin tool or command-line utilities could configure AFP shares with fine-tuned access control, including guest access, user quotas, and shared folder permissions.
In these legacy versions, enabling file sharing through AFP was a straightforward process. System Preferences' Sharing pane listed AFP under "File Sharing," and once toggled, made shared directories immediately accessible on the local network to other Mac users. AFP's tight integration with Directory Services supported seamless user authentication across AppleTalk and later IP-based networks.
AFP maintained backward compatibility across multiple macOS versions for nearly two decades. For example, macOS X 10.3 Panther could still connect to shares hosted on macOS 9 via AFP over AppleTalk, while macOS 10.10 Yosemite could connect to AFP shares on Tiger Server (10.4) using AFP over TCP/IP.
What did this mean for users? A Power Mac G4 running Mac OS 9 could still mount a share from a modern Mac, provided AFP support was enabled and authentication methods aligned. This level of compatibility was unmatched by SMB in early macOS versions, reinforcing AFP's role in long-term interoperability within Apple environments.
When a user initiates a connection to an AFP server, the process starts with authentication. The client, typically a macOS machine, sends login credentials using the Apple Authentication Protocol. Once verified, the server provides access to shared volumes, which appear as mounted drives on the client desktop.
AFP supports a persistent connection model. Users maintain access to remote files until the connection is explicitly closed or interrupted. This allows both seamless file operations and fewer reconnection delays.
AFP was engineered for low-latency communication within local area networks (LAN). When browsing shared files over AFP, the user interface in Finder reacts quickly, offering an experience comparable to accessing files on a local disk. Metadata handling plays a big role here—AFP preserves extended attributes, Type and Creator codes, and resource forks, which are specific to classic Mac filesystems like HFS+, ensuring data integrity during transfer.
Users can drag and drop files between shared volumes and local storage, leverage features like Quick Look on remote documents, and benefit from AFP’s support for file locking, which prevents data conflicts when multiple users access the same file.
Peer-to-peer sharing between Mac computers became straightforward with AFP. Under the Sharing preferences pane in System Preferences, activating "File Sharing" enabled AFP service by default until macOS 10.9 Mavericks. Other users on the same network could then access designated shared folders using the “Go > Connect to Server” feature in Finder, typing in an address like afp://hostname.local.
This setup required minimal configuration. Bonjour, Apple’s zero-configuration networking protocol, announced available AFP services automatically, eliminating the need to remember IP addresses or hostnames.
For decades, AFP was the default file-sharing protocol in macOS. That changed in 2013 with the release of OS X 10.9 Mavericks. As of that version, SMB2 became the new default. Apple cited performance gains, improved Windows compatibility, and broader industry support as key reasons for the switch. AFP remained available but had to be manually selected by users when connecting to file shares.
In benchmark testing conducted by Ars Technica in 2013, SMB2 showed faster file transfer performance compared to AFP in several scenarios, particularly with large file sets and cross-platform environments. The decision aligned macOS networking architecture with enterprise and mixed-platform workflows without completely removing AFP support—at least initially.
Network file systems allow users to access files over a network with the same ease as if they were stored on a local disk. These protocols enable remote file storage, sharing, and management across heterogeneous systems without duplicating data. Common examples include NFS, SMB, and AFP, each with differing priorities in compatibility, performance, and metadata support.
Apple Filing Protocol distinguished itself among network file systems by closely aligning with the Macintosh file system architecture. Unlike SMB or NFS, both of which originated from Windows and Unix systems respectively, AFP was built specifically to support classic Mac OS and later macOS behaviors.
AFP encapsulated the dual-fork file structure that Mac files relied on—consisting of a data fork and a resource fork—preserving file integrity in ways other protocols couldn't match during its time of widest adoption. It not only transmitted the raw content but included the structural nuances unique to HFS+ volumes.
Metadata handling was one of AFP’s defining strengths. It supported:
AFP transmitted these elements seamlessly, avoiding data loss or corruption often seen with protocols not designed to manage these structures. This was particularly relevant during cross-version macOS network interactions or when sharing files between older and newer Macintosh systems.
During file exchanges, AFP maintained attribute consistency using Apple’s proprietary mechanisms. For example, the protocol utilized AppleDouble formatting when transmitting files to non-HFS+ volumes. This approach stored the data fork in the main file and saved the resource fork and metadata in a parallel companion file—usually beginning with ._—ensuring compatibility while retaining essential macOS-specific information.
This fidelity ensured user environments behaved predictably across systems. Icons stayed where users placed them. Aliases worked as expected. Spotlight results remained accurate because metadata persisted regardless of network transmission.
While other network file systems eventually adopted support for extended attributes in their own ecosystems, AFP's native integration kept macOS file semantics intact far more reliably throughout its primary usage era.
In earlier macOS versions, AFP consistently outperformed SMB in network throughput and latency when exchanging files between Macs. Benchmarks conducted using macOS 10.6 through 10.9 showed AFP delivering up to 20% faster read/write speeds under identical conditions, particularly when handling metadata-rich resource forks or large directories with thousands of files.
However, performance equilibrium shifted with the introduction of SMB2 in OS X 10.10 (Yosemite) and further with SMB3's integration. SMB3 introduced multichannel support, improved compression, and better caching mechanisms. In macOS 12 Monterey, SMB3 achieved read/write speeds that were on par with or higher than AFP, especially over high-throughput gigabit or 10 GbE networks. Today, SMB3 handles most high-demand file operations more efficiently in modern macOS deployments.
AFP lacks built-in encryption. While macOS systems can secure AFP traffic using VPN tunnels or underlying network-layer encryption, the protocol itself does not support data-at-rest or in-transit encryption. It also offers no native support for secure negotiation or modern authentication mechanisms like Kerberos constrained delegation.
SMB3, by contrast, offers end-to-end encryption as a protocol feature. It supports AES-128-GCM and AES-256-GCM encryption algorithms, delivering both data confidentiality and integrity. Additionally, SMB3 enforces better session security through mechanisms like pre-authentication integrity and secure dialect negotiation. These enhancements mitigate man-in-the-middle attacks and session hijacking risks without requiring external encryption layers.
AFP integrates more closely with macOS's HFS+ and APFS file systems. It preserves Mac-specific metadata, such as resource forks and Finder flags, without translation or loss. Named forks, Type/Creator codes, and Finder tags remain intact when transferring files over AFP. This nuanced handling avoids data corruption in creative workflows involving legacy software.
In contrast, SMB handles metadata differently. While macOS has extended SMB to support many Mac-specific file attributes using AppleDouble files or extended attributes (xattrs), some metadata translation inconsistencies persist—especially when files are copied between Mac and Windows clients. For instance, copying via SMB may result in lost Finder tags or misapplied executable flags depending on share configuration and filesystem compatibility.
Apple Filing Protocol (AFP) mirrors the macOS file permission model by supporting both traditional POSIX permissions and Access Control Lists (ACLs). When a file is created or modified over AFP, the protocol applies the same permission semantics that a user would expect when interacting with files directly on macOS. AFP ensures that a file's read, write, and execute permissions for the owner, group, and others are preserved and accurately enforced.
This alignment with macOS expectations means file interactions across the network retain local permission behaviors. If a user lacks write access to a file locally, the same restriction applies when accessing the file over AFP. Moreover, AFP servers accurately map UNIX user IDs (UIDs) and group IDs (GIDs), a necessary step for consistent access control enforcement.
AFP supports extended permissions by maintaining full compatibility with both POSIX and macOS ACL systems. Unlike simple UNIX mode bits, ACLs provide fine-grained control that supports:
macOS uses the NFSv4 ACL model, and AFP integrates this natively. For instance, administrators can assign a file permission allowing one user to read and write, while granting another user read-only access, all within a single ACL. AFP supports these rich access control scenarios without translation loss or degradation.
While both AFP and SMB are capable of working with macOS’s ACLs and POSIX permissions, their behaviors aren't identical. AFP was designed tightly around macOS metadata models and file systems—especially HFS+ and APFS—which results in cleaner and more predictable permission mapping.
SMB, in contrast, often introduces permission ambiguity due to its origin in Windows-based ACL systems. macOS has to translate Windows-style ACLs when using SMB, which can produce unpredictable access results.
AFP respects macOS ACL semantics and avoids the permission mismatches that sometimes occur with SMB connections. This includes better handling of inherited ACEs (Access Control Entries), enforcement of deny entries, and more consistent permission resolution across shared volumes.
For workflows where granular user-level access must align with macOS standards, AFP delivers more reliable and precise ACL support—especially in legacy Mac environments.
In Apple's macOS Server, Apple Filing Protocol (AFP) served as the default file-sharing protocol for decades. From the early days of Mac OS X Server 1.0 in 1999 through to macOS Server 5.6.1 released in 2018, AFP underpinned file distribution across Mac-native environments. Admins relied on AFP's integration with Open Directory for network home directories, mobile accounts, and distributed file systems.
Before the introduction of SMB2 as the default preference in OS X Mavericks (10.9), server installations prioritized AFP due to its optimized handling of resource forks, legacy metadata, and case-insensitive HFS+ volumes. AFP efficiently managed Finder labels, Type and Creator codes, and file names containing prohibited characters in other protocols, like colons.
Starting with OS X Server 4.0 (Yosemite), Apple included SMB and AFP in the File Sharing service module. Although SMB was presented as the default protocol from Mavericks onwards, AFP remained active by default for macOS clients accessing older volumes or Time Machine backups. Admin interfaces in Server.app allowed toggling between AFP and SMB, and administrators could enable both protocols to maintain compatibility with mixed OS environments.
When administrators configured shares for macOS 10.8 and earlier clients—or when dealing with NAS units standardizing around AFP—the protocol’s retained position in the default stack allowed cohesion without additional configuration overhead.
Technical user communities persisted in AFP use well beyond its official deprecation trajectory. Creative professionals relying on shared libraries of Final Cut Pro X projects and Adobe applications often preferred AFP to avoid metadata collisions and filename truncations seen in some SMB configurations. In production studios and design firms with aging Mac Pros or Xserves, AFP ensured uninterrupted workflows on RAID-attached storage via macOS Server.
In education and research settings, particularly in labs running managed Macs with legacy workflows, university IT staff configured AFP shares to support campus-wide home directories. AFP’s familiarity and functional predictability ensured its place in these environments—long after its successor became the industry recommendation.
Time Machine, Apple’s built-in backup solution introduced with Mac OS X 10.5 Leopard in 2007, originally relied exclusively on Apple Filing Protocol (AFP) for network-based backups. When users configured Time Machine to back up to a network device—such as a macOS Server or a compatible NAS—the system required the destination share to be mounted over AFP.
This design wasn't arbitrary. AFP offered features well-aligned with Time Machine’s requirements: metadata preservation, efficient file handling, and resource fork support. These capabilities ensured the integrity of HFS+ filesystem attributes over the network, something SMB implementations of the time struggled to provide.
Early versions of Time Machine rejected network destinations unless they were mounted via AFP. This wasn’t simply a preference—it was a technical necessity. The protocol’s support for:
SMB, in contrast, lacked native support for these HFS+-specific features, making it a riskier choice for data fidelity. Consequently, Apple certified only AFP as a supported protocol for Time Machine backups over the network up until macOS High Sierra (2017).
Starting with macOS Mojave (10.14) and formalized in macOS Catalina (10.15), Apple shifted Time Machine’s support to SMB. This change coincided with broader strategic moves: the deprecation of AFP and the adoption of APFS as the default file system. At this point, Time Machine required SMB 3.0 with specific extensions that included:
With these additions, SMB could now meet or even surpass AFP in maintaining metadata, handling large datasets, and reducing latency in sparsebundle image manipulation—key actions for macOS backup operations.
Wondering what this means for older hardware? Devices that only support AFP remain incompatible with newer macOS versions unless updated or replaced. SMB has become the standard, but AFP’s legacy still defines the backup architecture of many older deployments.
©2026 American TV. All Rights Reserved
Disclaimer: All rights reserved. AmericanTV.com is a website for research and comparison as such, falls under "Fair Use". AmericanTV.com does not provide directly phone, TV, and internet service. All trademarks, logos, etc. remain the property of their respective owners and are used by AmericanTV.com only to describe products and services offered by each respective trademark holder. The use of any third party trademarks on this site in no way indicates any relationship between AmericanTV.com and the holders of said trademarks, nor any endorsement of AmericanTV.com by the holders of said trademarks.
We are here 24/7 to answer all of your TV + Internet Questions:
1-855-690-9884
1-855-690-9884