As you start building larger applications in Swift, you will often encounter situations where different types need to provide the same kind of functionality, even though those types may be completely different from each other.
For example, imagine an application where different payment methods can process payments:
Credit Card
Apple Pay
PayPal
Their internal implementations may be different, but they all need one common capability:
Process Payment
Swift protocols allow us to define this common requirement.
protocol PaymentMethod {
func pay(amount: Double)
}
Different types can then conform to the protocol:
struct CreditCardPayment: PaymentMethod {
func pay(amount: Double) {
print("Paid \(amount) using Credit Card")
}
}
and:
struct ApplePayPayment: PaymentMethod {
func pay(amount: Double) {
print("Paid \(amount) using Apple Pay")
}
}
The protocol defines what functionality must exist, while each conforming type decides how that functionality works.
Protocols are one of the most important features in Swift and are heavily used throughout modern Swift and iOS development.
In this guide, you will learn protocols from basic syntax to practical usage with properties, methods, initializers, inheritance, extensions, generics, delegation, dependency injection, and real-world examples.
What Is a Protocol in Swift?
A protocol defines a blueprint of requirements that another type can adopt.
A protocol can require:
- Properties
- Methods
- Initializers
- Type properties
- Type methods
- Subscripts
- Associated types
- Other protocol conformances
Basic syntax:
protocol ProtocolName {
}
For example:
protocol Drivable {
func drive()
}
The protocol says:
Any type conforming to
Drivablemust provide the requireddrive()behavior.
Now create a conforming type:
struct Car: Drivable {
func drive() {
print("Car is driving")
}
}
Use:
let car = Car()
car.drive()
Output:
Car is driving
What Is Protocol Conformance?
When a type adopts a protocol and satisfies its requirements, this is called protocol conformance.
For example:
protocol Printable {
func printDetails()
}
A structure can conform:
struct User: Printable {
let name: String
func printDetails() {
print("User: \(name)")
}
}
Here:
struct User: Printable
means:
User conforms to Printable
Because Printable requires:
func printDetails()
User must provide that method.
What Happens If a Requirement Is Missing?
Consider:
protocol Printable {
func printDetails()
}
Now:
struct User: Printable {
let name: String
}
This will produce a compiler error because User claims to conform to Printable but does not implement:
func printDetails()
The correct version is:
struct User: Printable {
let name: String
func printDetails() {
print(name)
}
}
Protocols therefore create a contract that the compiler can verify.
Why Do We Need Protocols?
Without protocols, you may create functions tied to specific concrete types.
For example:
struct Car {
func start() {
print("Car started")
}
}
Then:
func startCar(_ car: Car) {
car.start()
}
This function only accepts Car.
Suppose you later add:
Bike
Truck
Bus
If all of them can start, we can describe that capability using a protocol:
protocol Startable {
func start()
}
Now:
struct Car: Startable {
func start() {
print("Car started")
}
}
struct Bike: Startable {
func start() {
print("Bike started")
}
}
And:
func startVehicle(_ vehicle: any Startable) {
vehicle.start()
}
Now the function works with any conforming type.
Protocols with Structures
Structures can conform to protocols.
Example:
protocol Displayable {
func display()
}
Then:
struct Product: Displayable {
let name: String
let price: Double
func display() {
print("\(name): $\(price)")
}
}
Use:
let product = Product(
name: "MacBook",
price: 1299
)
product.display()
Output:
MacBook: $1299.0
Protocols with Classes
Classes can also conform to protocols.
protocol LoginService {
func login()
}
Implementation:
class FirebaseLoginService: LoginService {
func login() {
print("Logging in with Firebase")
}
}
Use:
let service = FirebaseLoginService()
service.login()
Output:
Logging in with Firebase
Protocols with Enums
Enums can conform to protocols too.
protocol Describable {
var description: String { get }
}
Example:
enum OrderStatus: Describable {
case pending
case shipped
case delivered
var description: String {
switch self {
case .pending:
return "Order is pending"
case .shipped:
return "Order has been shipped"
case .delivered:
return "Order delivered"
}
}
}
Use:
let status = OrderStatus.shipped
print(status.description)
Output:
Order has been shipped
Protocols are therefore not limited to classes.
They can be adopted by:
Structs
Classes
Enums
Protocol Property Requirements
Protocols can require properties.
Example:
protocol UserProfile {
var name: String { get }
}
The syntax:
{ get }
means the property must be readable.
A conforming type:
struct User: UserProfile {
let name: String
}
Use:
let user = User(name: "Alex")
print(user.name)
Output:
Alex
get and set in Protocols
A protocol can require both reading and writing.
protocol EditableProfile {
var name: String { get set }
}
Now a conforming type must provide a property that satisfies the read/write requirement.
Example:
struct User: EditableProfile {
var name: String
}
Then:
var user = User(name: "Alex")
user.name = "Emma"
print(user.name)
Output:
Emma
{ get } vs { get set }
Remember:
{ get }
↓
Must be readable
while:
{ get set }
↓
Must satisfy read + write requirement
Example:
protocol Profile {
var id: Int { get }
var name: String { get set }
}
Implementation:
struct User: Profile {
let id: Int
var name: String
}
Protocol Method Requirements
Protocols can require instance methods.
protocol AuthenticationService {
func login()
func logout()
}
Implementation:
class AuthManager: AuthenticationService {
func login() {
print("User logged in")
}
func logout() {
print("User logged out")
}
}
Both methods must be implemented.
Methods with Parameters
Protocol methods can accept parameters.
protocol MessageSender {
func send(message: String)
}
Implementation:
struct EmailSender: MessageSender {
func send(message: String) {
print("Email: \(message)")
}
}
Use:
let sender = EmailSender()
sender.send(
message: "Welcome to Swift!"
)
Methods with Return Values
Protocols can also require methods that return values.
protocol Calculator {
func calculate(
first: Double,
second: Double
) -> Double
}
Implementation:
struct AdditionCalculator: Calculator {
func calculate(
first: Double,
second: Double
) -> Double {
first + second
}
}
Use:
let calculator = AdditionCalculator()
let result = calculator.calculate(
first: 10,
second: 20
)
print(result)
Output:
30.0
Mutating Protocol Methods
Structures are value types.
If a protocol method may modify a conforming value type, declare it as:
mutating
Example:
protocol Resettable {
mutating func reset()
}
Implementation:
struct Counter: Resettable {
var value = 0
mutating func reset() {
value = 0
}
}
Use:
var counter = Counter(value: 10)
counter.reset()
print(counter.value)
Output:
0
Classes conforming to the same protocol do not need to write mutating in their implementation.
Protocol Initializer Requirements
Protocols can require initializers.
Example:
protocol UserCreatable {
init(name: String)
}
Structure:
struct User: UserCreatable {
let name: String
init(name: String) {
self.name = name
}
}
Now every conforming type must provide an initializer compatible with:
init(name: String)
Protocol Initializers with Classes
Classes require some additional consideration because initializers participate in inheritance.
For example:
protocol Initializable {
init()
}
A non-final class conforming to the protocol generally needs:
required init()
Example:
class Service: Initializable {
required init() {
}
}
required ensures subclasses must also provide or inherit the required initializer appropriately.
Multiple Protocol Conformance
A type can conform to more than one protocol.
Example:
protocol Drivable {
func drive()
}
protocol Chargeable {
func charge()
}
Now:
struct ElectricCar: Drivable, Chargeable {
func drive() {
print("Electric car is driving")
}
func charge() {
print("Electric car is charging")
}
}
Use:
let car = ElectricCar()
car.drive()
car.charge()
This allows a type to combine several capabilities.
Why Multiple Protocols Matter
Classes cannot inherit from multiple superclasses.
You cannot create a class hierarchy like:
Car inherits Vehicle + Machine + Trackable
through multiple class inheritance.
But protocols allow:
class Car:
Drivable,
Trackable,
Chargeable {
}
This is one reason protocols are so useful in Swift architecture.
Protocol Inheritance
Protocols can inherit requirements from other protocols.
Example:
protocol Identifiable {
var id: Int { get }
}
Then:
protocol UserProfile: Identifiable {
var name: String { get }
}
Now a type conforming to UserProfile must satisfy both:
id
name
Example:
struct User: UserProfile {
let id: Int
let name: String
}
Protocol Composition
Sometimes a function should accept a value that conforms to multiple protocols.
Suppose:
protocol Named {
var name: String { get }
}
and:
protocol Aged {
var age: Int { get }
}
You can combine requirements:
func displayPerson(
_ person: any Named & Aged
) {
print(person.name)
print(person.age)
}
Now the argument must conform to both protocols.
Protocols as Types
A protocol can be used as a type through an existential such as:
any PaymentMethod
Example:
protocol PaymentMethod {
func pay(amount: Double)
}
Implementations:
struct CardPayment: PaymentMethod {
func pay(amount: Double) {
print("Card payment: \(amount)")
}
}
struct CashPayment: PaymentMethod {
func pay(amount: Double) {
print("Cash payment: \(amount)")
}
}
Now:
let payment: any PaymentMethod =
CardPayment()
Then:
payment.pay(amount: 500)
This lets your code work through the protocol rather than depending directly on one implementation.
Arrays of Protocol-Conforming Values
Suppose:
protocol Drawable {
func draw()
}
Create:
struct Circle: Drawable {
func draw() {
print("Drawing Circle")
}
}
struct Rectangle: Drawable {
func draw() {
print("Drawing Rectangle")
}
}
Now:
let shapes: [any Drawable] = [
Circle(),
Rectangle(),
Circle()
]
Loop:
for shape in shapes {
shape.draw()
}
Output:
Drawing Circle
Drawing Rectangle
Drawing Circle
This is protocol-based polymorphism.
Protocol Extensions
One of Swift’s most powerful features is the ability to extend protocols.
Example:
protocol Greetable {
var name: String { get }
func greet()
}
Instead of implementing greet() separately for every type, provide a default implementation:
extension Greetable {
func greet() {
print("Hello, \(name)")
}
}
Now:
struct User: Greetable {
let name: String
}
Use:
let user = User(name: "Alex")
user.greet()
Output:
Hello, Alex
User did not explicitly implement greet().
It received the default implementation from the protocol extension.
Overriding a Default Protocol Implementation
A conforming type can provide its own implementation when the method is a protocol requirement.
Example:
protocol Greetable {
var name: String { get }
func greet()
}
Default:
extension Greetable {
func greet() {
print("Hello, \(name)")
}
}
Custom:
struct Admin: Greetable {
let name: String
func greet() {
print("Welcome Administrator \(name)")
}
}
Use:
let admin = Admin(name: "Alex")
admin.greet()
Output:
Welcome Administrator Alex
Adding Helper Methods Through Protocol Extensions
Extensions can also add useful functionality.
protocol Priceable {
var price: Double { get }
}
Extension:
extension Priceable {
func formattedPrice() -> String {
"$\(price)"
}
}
Now:
struct Product: Priceable {
let price: Double
}
Use:
let product = Product(price: 499)
print(product.formattedPrice())
Output:
$499.0
Conditional Protocol Extensions
Protocol extensions can be constrained.
Example:
protocol Describable {
}
Then:
extension Describable where Self: Collection {
var itemCount: Int {
count
}
}
This functionality applies only when the conforming type also satisfies the specified constraint.
Conditional extensions become especially useful when working with generics.
Class-Only Protocols
Sometimes a protocol should only be adopted by classes.
Use:
protocol Coordinator: AnyObject {
func start()
}
Now a struct cannot conform to Coordinator.
This is useful when reference semantics are required.
A common example is delegation where the delegate reference needs to be weak.
Delegation with Protocols
The delegate pattern is one of the most common protocol use cases in Apple-platform development.
Suppose we have:
protocol DownloadManagerDelegate: AnyObject {
func downloadDidFinish()
}
Download manager:
class DownloadManager {
weak var delegate: DownloadManagerDelegate?
func startDownload() {
print("Downloading...")
delegate?.downloadDidFinish()
}
}
Another class adopts the protocol:
class DownloadScreen:
DownloadManagerDelegate {
func downloadDidFinish() {
print("Update UI: Download completed")
}
}
Set delegate:
let manager = DownloadManager()
let screen = DownloadScreen()
manager.delegate = screen
manager.startDownload()
Output:
Downloading...
Update UI: Download completed
Why Is a Delegate Often weak?
A manager may retain its delegate.
The delegate may also retain the manager.
This can potentially create a strong reference cycle.
Using:
weak var delegate
helps avoid the delegate relationship unnecessarily keeping the delegate object alive.
Because weak works with class instances, delegate protocols are often restricted using:
AnyObject
Protocols and Dependency Injection
Protocols are extremely useful for dependency injection.
Suppose your application fetches users.
Define:
protocol UserService {
func fetchUsers()
}
Real implementation:
class APIUserService: UserService {
func fetchUsers() {
print("Fetching users from API")
}
}
Consumer:
class UserViewModel {
private let userService: any UserService
init(userService: any UserService) {
self.userService = userService
}
func loadUsers() {
userService.fetchUsers()
}
}
Create:
let viewModel = UserViewModel(
userService: APIUserService()
)
The view model depends on:
UserService
rather than directly depending on:
APIUserService
Why Protocol-Based Dependency Injection Helps
Suppose you want to test UserViewModel.
Create:
class MockUserService: UserService {
func fetchUsers() {
print("Returning mock users")
}
}
Then:
let viewModel = UserViewModel(
userService: MockUserService()
)
You can test without making a real network request.
This can make code:
- Easier to test
- Easier to replace
- Less tightly coupled
- Easier to maintain
Real-World Example: Payment System
Let’s build a flexible payment system.
Protocol:
protocol PaymentProcessor {
func processPayment(
amount: Double
)
}
Stripe:
class StripeProcessor:
PaymentProcessor {
func processPayment(
amount: Double
) {
print(
"Processing \(amount) with Stripe"
)
}
}
Apple Pay:
class ApplePayProcessor:
PaymentProcessor {
func processPayment(
amount: Double
) {
print(
"Processing \(amount) with Apple Pay"
)
}
}
Checkout:
class CheckoutService {
private let processor:
any PaymentProcessor
init(
processor: any PaymentProcessor
) {
self.processor = processor
}
func checkout(
total: Double
) {
processor.processPayment(
amount: total
)
}
}
Use:
let checkout = CheckoutService(
processor: ApplePayProcessor()
)
checkout.checkout(
total: 299
)
Output:
Processing 299.0 with Apple Pay
Real-World Example: Notification System
Protocol:
protocol NotificationSender {
func send(
message: String
)
}
Email:
struct EmailSender:
NotificationSender {
func send(
message: String
) {
print(
"Email: \(message)"
)
}
}
Push:
struct PushSender:
NotificationSender {
func send(
message: String
) {
print(
"Push: \(message)"
)
}
}
SMS:
struct SMSSender:
NotificationSender {
func send(
message: String
) {
print(
"SMS: \(message)"
)
}
}
Now:
func notify(
using sender: any NotificationSender,
message: String
) {
sender.send(
message: message
)
}
The same function can work with every supported notification implementation.
Real-World Example: Data Storage
Imagine an application that can save data locally or remotely.
Protocol:
protocol DataStorage {
func save(_ value: String)
func load() -> String?
}
Local implementation:
class LocalStorage:
DataStorage {
private var value: String?
func save(_ value: String) {
self.value = value
}
func load() -> String? {
value
}
}
Mock implementation:
class MockStorage:
DataStorage {
func save(_ value: String) {
print("Mock save: \(value)")
}
func load() -> String? {
"Mock Data"
}
}
Application code can depend on DataStorage rather than a specific storage implementation.
Protocols with Generics
Protocols become even more powerful when combined with generics.
Example:
protocol Repository {
associatedtype Item
func getAll() -> [Item]
}
A repository chooses its own Item type.
Example:
struct User {
let id: Int
let name: String
}
Repository:
class UserRepository:
Repository {
typealias Item = User
func getAll() -> [User] {
[
User(
id: 1,
name: "Alex"
),
User(
id: 2,
name: "Emma"
)
]
}
}
This allows protocols to describe generic relationships between types.
What Is associatedtype?
An associated type is a placeholder type declared inside a protocol.
Example:
protocol Container {
associatedtype Item
func add(_ item: Item)
}
A conforming type decides what Item actually means.
For example:
struct StringContainer:
Container {
typealias Item = String
func add(_ item: String) {
print(item)
}
}
Here:
Item = String
Associated types are especially important when learning advanced protocol-oriented programming and generics.
some vs any with Protocols
Modern Swift commonly uses the keywords:
some
any
with protocols.
Understanding their purpose is useful.
What Does any Mean?
any ProtocolName represents an existential value that can hold a value conforming to that protocol.
Example:
protocol Drawable {
func draw()
}
Then:
let shape: any Drawable =
Circle()
The concrete value is a Circle, but the variable exposes the Drawable interface.
What Does some Mean?
some ProtocolName represents an opaque type.
The function returns one specific concrete type that conforms to the protocol, but the caller doesn’t need to know exactly which type.
A familiar SwiftUI example is:
var body: some View {
Text("Hello")
}
body returns one concrete type conforming to View, while Swift hides the exact underlying type from the API surface.
some vs any
A simplified beginner comparison:
any Protocol
↓
A value boxed behind a protocol interface
some Protocol
↓
One specific concrete conforming type,
hidden from the caller
The exact type-system details become more important when you study generics and SwiftUI deeply.
Protocol-Oriented Programming
Protocols are so important in Swift that Swift development is often discussed in terms of Protocol-Oriented Programming.
Instead of designing everything around class inheritance:
Animal
↓
Mammal
↓
Dog
you can describe capabilities:
Runnable
Swimmable
Trainable
Trackable
A type then adopts only the capabilities it needs.
Example:
protocol Runnable {
func run()
}
protocol Swimmable {
func swim()
}
Then:
struct Dog:
Runnable,
Swimmable {
func run() {
print("Dog running")
}
func swim() {
print("Dog swimming")
}
}
This can create more flexible designs than deep inheritance trees.
Protocols vs Classes
Protocols and classes solve different problems.
| Protocol | Class |
|---|---|
| Defines requirements | Provides concrete implementation/state |
| No class instance by itself | Can create instances |
| Can be adopted by structs | Reference type |
| Can be adopted by enums | Supports inheritance |
| Multiple protocols possible | One superclass |
| Useful for capabilities | Useful for shared identity/state |
For example:
protocol Drivable {
func drive()
}
defines a capability.
While:
class Car {
}
defines a concrete reference type.
Protocols vs Abstract Classes
Some languages provide dedicated abstract classes.
Swift does not use an abstract class keyword.
Instead, many designs can use:
Protocol
+
Protocol Extension
For example:
protocol Animal {
func makeSound()
}
Default behavior:
extension Animal {
func sleep() {
print("Sleeping")
}
}
Concrete type:
struct Dog: Animal {
func makeSound() {
print("Woof")
}
}
This provides required behavior plus reusable default functionality without requiring a traditional abstract superclass.
Built-In Swift Protocols
Swift includes many important protocols.
Common examples include:
Equatable
Comparable
Hashable
Codable
Identifiable
CustomStringConvertible
Sequence
Collection
Error
Understanding protocols makes many other Swift features easier to understand.
Equatable
Equatable allows values to be compared using:
==
Example:
struct User: Equatable {
let id: Int
let name: String
}
Then:
let user1 = User(
id: 1,
name: "Alex"
)
let user2 = User(
id: 1,
name: "Alex"
)
print(user1 == user2)
Output:
true
Swift can synthesize the required equality implementation for many simple value types.
Hashable
Hashable allows values to produce hash values and be used in hash-based collections such as:
Set
Dictionary keys
Example:
struct User: Hashable {
let id: Int
let name: String
}
Now:
let users: Set<User> = [
User(id: 1, name: "Alex"),
User(id: 2, name: "Emma")
]
Codable
Codable is commonly used for encoding and decoding data.
Example:
struct User: Codable {
let id: Int
let name: String
let email: String
}
This is especially useful when working with JSON APIs.
Codable combines:
Encodable
+
Decodable
Identifiable
Identifiable is commonly encountered in SwiftUI.
Example:
struct User: Identifiable {
let id: Int
let name: String
}
Now each User provides a stable identity through:
id
This is useful for SwiftUI lists.
CustomStringConvertible
This protocol allows a type to provide a custom textual description.
Example:
struct User:
CustomStringConvertible {
let name: String
var description: String {
"User(name: \(name))"
}
}
Use:
let user = User(name: "Alex")
print(user)
Output:
User(name: Alex)
Protocols in SwiftUI
SwiftUI uses protocols extensively.
The most obvious example is:
View
A SwiftUI screen might look like:
import SwiftUI
struct ContentView: View {
var body: some View {
Text("Hello Swift")
}
}
Here:
ContentView
conforms to:
View
and provides the required body.
Understanding protocols therefore makes SwiftUI’s design much easier to understand.
Protocols and Testing
Protocols are especially valuable for testable code.
Suppose:
protocol NetworkService {
func fetchData()
}
Production:
class APIService:
NetworkService {
func fetchData() {
print("Real API request")
}
}
Test:
class MockAPIService:
NetworkService {
func fetchData() {
print("Mock API response")
}
}
Consumer:
class ViewModel {
private let service:
any NetworkService
init(
service: any NetworkService
) {
self.service = service
}
}
Production can inject:
APIService()
Tests can inject:
MockAPIService()
The view model itself does not need to change.
Common Beginner Mistake: Creating Empty Protocols
Avoid creating protocols without a clear purpose.
For example:
protocol UserProtocol {
}
Ask:
What capability or contract is this protocol describing?
A better protocol might be:
protocol Authenticatable {
func login()
func logout()
}
The protocol now communicates meaningful behavior.
Common Beginner Mistake: Making Every Class Have a Protocol
Protocols are useful, but not every concrete type automatically needs one.
Avoid creating:
UserService
UserServiceProtocol
ProductService
ProductServiceProtocol
CartService
CartServiceProtocol
without a real reason.
Protocols are most valuable when you need things such as:
- Multiple implementations
- Dependency inversion
- Mocking/testing boundaries
- Delegation
- Generic constraints
- Shared capabilities
Use them intentionally.
Common Beginner Mistake: Confusing Protocols with Classes
A protocol doesn’t normally create an object itself.
This:
protocol Vehicle {
}
defines requirements.
This:
struct Car: Vehicle {
}
provides a concrete conforming type.
Think:
Protocol
↓
Contract
Concrete Type
↓
Implementation
Common Beginner Mistake: Forgetting Requirements
If a protocol says:
protocol UserProfile {
var name: String { get }
func display()
}
then a conforming type must satisfy those requirements unless an applicable default implementation supplies the method behavior.
Common Beginner Mistake: Overusing Inheritance
If several unrelated types need the same capability, inheritance may not represent the relationship correctly.
Instead of forcing:
BaseNotificationSender
↓
Email
SMS
Push
you might use:
protocol NotificationSender {
func send()
}
Each implementation can then remain independent.
Common Beginner Mistake: Misunderstanding any
In modern Swift, when you intentionally store a value as a protocol existential, you may see:
any PaymentMethod
rather than simply treating the protocol name as if it were always a concrete type.
Understanding any becomes increasingly important in modern Swift APIs.
Swift Protocol Cheat Sheet
Create Protocol
protocol Drivable {
func drive()
}
Conform
struct Car: Drivable {
func drive() {
}
}
Property Requirement
var name: String { get }
Read/Write Property
var name: String { get set }
Method Requirement
func login()
Mutating Requirement
mutating func reset()
Initializer Requirement
init(name: String)
Multiple Protocols
struct Car:
Drivable,
Chargeable {
}
Protocol Extension
extension Drivable {
func stop() {
}
}
Class-Only Protocol
protocol Delegate: AnyObject {
}
Protocol Composition
any Named & Identifiable
Protocol Existential
any Drivable
Opaque Return Type
some View
Associated Type
associatedtype Item
Practice Exercise 1: Printable
Create:
protocol Printable
with:
func printDetails()
Then make:
User
Product
Order
conform to it.
Practice Exercise 2: Payment Method
Create:
protocol PaymentMethod
with:
func pay(amount: Double)
Implement:
CardPayment
CashPayment
ApplePayPayment
Then create one function that accepts any payment implementation.
Practice Exercise 3: Vehicle
Create:
Drivable
Chargeable
Trackable
protocols.
Create an ElectricCar that conforms to all three.
Practice Exercise 4: Protocol Extension
Create:
protocol Greetable
with:
var name: String { get }
Provide a default greet() implementation through an extension.
Practice Exercise 5: Delegate
Create:
protocol TimerDelegate: AnyObject
with:
func timerDidFinish()
Create a timer manager and notify its delegate when the operation finishes.
Practice Exercise 6: Dependency Injection
Create:
protocol NetworkService
Then implement:
RealNetworkService
MockNetworkService
Inject the protocol into a view model.
Try switching between real and mock implementations without changing the view model.
Frequently Asked Questions
What is a protocol in Swift?
A protocol defines a set of requirements that conforming Swift types agree to provide.
These requirements can include properties, methods, initializers, and other behavior.
What is protocol conformance?
Protocol conformance means that a type adopts a protocol and satisfies its required functionality.
Example:
struct Car: Drivable {
}
means Car declares conformance to Drivable.
Can a struct conform to a protocol?
Yes.
Structures commonly conform to protocols in Swift.
Can a class conform to a protocol?
Yes.
Classes can conform to one or multiple protocols.
Can an enum conform to a protocol?
Yes.
Enums can also conform to protocols.
Can one type conform to multiple protocols?
Yes.
For example:
struct Car:
Drivable,
Chargeable,
Trackable {
}
Can protocols contain implementations?
A protocol declaration primarily defines requirements.
Default and additional implementations can be provided through protocol extensions.
Can protocols inherit from other protocols?
Yes.
A protocol can build on the requirements of one or more other protocols.
What is a protocol extension?
A protocol extension allows you to provide functionality associated with conforming types, including default implementations for protocol requirements.
What does AnyObject mean in a protocol?
It restricts protocol conformance to class types.
Example:
protocol Delegate: AnyObject {
}
This is common for weak delegate relationships.
What is any in Swift protocols?
any ProtocolName explicitly represents an existential value that can hold a value conforming to that protocol.
Example:
let payment: any PaymentMethod
What is some in Swift?
some ProtocolName represents an opaque type.
The underlying concrete type is fixed but hidden from the caller.
A common example is:
some View
in SwiftUI.
What is an associated type?
An associated type is a placeholder type declared inside a protocol.
A conforming type determines the actual type.
Example:
associatedtype Item
Why are protocols important in Swift?
Protocols help developers create:
- Flexible APIs
- Reusable behavior
- Testable components
- Dependency-injected systems
- Delegate patterns
- Generic algorithms
- Protocol-oriented architectures
Are protocols better than inheritance?
Not universally.
Inheritance is useful when a genuine class hierarchy and shared reference-based implementation are appropriate.
Protocols are useful for defining capabilities and contracts across potentially unrelated types.
Swift applications often use protocols and composition to reduce unnecessary inheritance.
What Should You Learn After Swift Protocols?
After protocols, a strong learning path is:
Swift Protocols
↓
Protocol Extensions
↓
Swift Extensions
↓
Protocol-Oriented Programming
↓
Generics
↓
Associated Types
↓
some vs any
↓
Dependency Injection
↓
Delegation
↓
SOLID Principles
↓
SwiftUI Architecture
These topics build directly on the protocol concepts covered in this guide.
Final Thoughts
Protocols are one of the most powerful parts of the Swift type system.
A protocol lets you define:
What a type must provide
without forcing every conforming type to share the same concrete implementation.
For example:
protocol PaymentMethod {
func pay(amount: Double)
}
can be adopted by:
CreditCardPayment
ApplePayPayment
CashPayment
PayPalPayment
Each type can provide its own implementation while the rest of your application works through the common PaymentMethod contract.
Protocols become even more useful when combined with:
Protocol Extensions
Generics
Associated Types
Delegation
Dependency Injection
Composition
SwiftUI
The key idea to remember is:
A protocol describes a capability or contract, while the conforming type provides the concrete implementation.
Once you understand this concept, many parts of modern Swift—from Codable and Equatable to dependency injection and SwiftUI’s View protocol—become much easier to understand.
