DEV Community: Haris Madhavan

Access Control Levels in Swift

Haris Madhavan — Tue, 24 Dec 2024 13:26:02 +0000

Access control levels in Swift determine the scope and visibility of classes, structures, functions, properties, and other entities in your code. They define who can access or modify a particular piece of code, helping you manage code organization, security, and modularity.

Access Control Levels in Swift

1. Open (Most Permissive)

Scope: Available to any module or file, including subclasses outside the module.
Usage: Used for public APIs or frameworks where entities must be subclassable and overridden outside the module.

Example:

open class OpenClass {
    open func greet() {
        print("Hello!")
    }
}

class Subclass: OpenClass {
    override func greet() {
        print("Hi!")
    }
}

This allows OpenClass and its greet() method to be subclassed and overridden in other modules.

2. Public

Scope: Accessible in any module but not subclassable or overridable outside the module.
Usage: Used for exposing interfaces or functionality to other modules without subclassing.

Example:

public class PublicClass {
    public func greet() {
        print("Hello!")
    }
}

3. Internal (Default)

Scope: Accessible only within the same module (e.g., app target or framework).
Usage: The default access level for most entities unless explicitly specified.

Example:

class InternalClass {
    func greet() {
        print("Hello!")
    }
}

4. Fileprivate

Scope: Accessible only within the same source file.
Usage: Used when you want to restrict access to helper methods or properties within a single file.

Example:

fileprivate class FileprivateClass {
    fileprivate func greet() {
        print("Hello!")
    }
}

class AnotherClassInSameFile {
    func sayHi() {
        let instance = FileprivateClass()
        instance.greet()
    }
}

5. Private (Most Restrictive)

Scope: Accessible only within the same enclosing declaration (e.g., class, struct).
Usage: Used to encapsulate implementation details and restrict access within a specific declaration.

Example:

class PrivateClass {
    private var secretMessage = "Hidden!"

    private func showSecret() {
        print(secretMessage)
    }

    func revealSecret() {
        showSecret() // Accessible within the same class.
    }
}

Why Are Access Control Levels Useful?

Encapsulation:
Access control enforces the principle of hiding implementation details, exposing only what is necessary for use.
Code Modularity:
Helps in creating modular and reusable code by defining clear boundaries for access.
Security:
Restricts access to sensitive data or critical code sections to prevent misuse or unintended modifications.
API Design:
Public or open access levels allow you to define APIs for other developers while keeping the implementation private or internal.
Code Maintenance:
Prevents accidental access or modifications to parts of code that are not meant to be externally visible.

Choosing the Right Access Level

Use private for implementation details you don’t want accessed outside a class/struct.
Use fileprivate sparingly, typically for testing or tightly related logic.
Use internal by default for most app logic.
Use public or open only for entities that need external visibility, such as APIs or framework components.

Understanding and using access control effectively helps build secure, modular, and maintainable Swift applications.

Happy Coding!

MVC vs MVVM: A Real-Life iOS Interview Insight

Haris Madhavan — Mon, 23 Dec 2024 01:41:24 +0000

In a recent interview for an iOS Developer position, I encountered an interesting question that tested my knowledge of design patterns and my understanding of how they evolve. The discussion revolved around MVC and MVVM, two fundamental design patterns in iOS development. While I was prepared to explain their basics, the interviewer’s follow-up question surprised me.

In this article, I’ll share the question, my initial response, and what I learned from the experience. If you’re preparing for iOS interviews, this might help you navigate similar situations!

The Question: “How Does the Controller Fit into MVVM?”

The interview started with a familiar question:
“Can you explain the difference between MVC and MVVM?”

I confidently answered:

MVC stands for Model-View-Controller, where the Controller handles user input and updates the View and Model accordingly.
MVVM stands for Model-View-ViewModel, where business logic is separated from the View and placed in the ViewModel.

Feeling good about my response, I didn’t expect the next question:
“In MVVM, there’s no ‘Controller.’ So, where does the Controller’s role go?”

I was stumped. I hadn’t thought about this distinction in depth before. After the interview, I took some time to reflect and understand the concept better.

Understanding MVC and MVVM:

MVC (Model-View-Controller):

The Model represents the data and business logic.
The View displays the data to the user.
The Controller acts as a bridge between the Model and View, handling user inputs and updating the data.

In this pattern, the Controller often takes on a lot of responsibility, making it prone to becoming “massive” (the infamous Massive View Controller problem).

MVVM (Model-View-ViewModel):

The Model remains the same.
The View still handles the UI.
The ViewModel introduces a layer that manages the business logic and data-binding to the View.

In MVVM, there’s no explicit Controller. Instead, its responsibilities are split between the View(handling user inputs) and the ViewModel (handling logic and data).

Where the Controller’s Role Goes in MVVM:

In UIKit-based MVVM apps, the ViewController still exists but acts purely as part of the View. It:

Handles UI setup and user input.
Binds the UI to the ViewModel.
Forwards actions to the ViewModel.

In SwiftUI, the View directly binds to the ViewModel, eliminating the need for a separate ViewController altogether.

My Takeaways:

Design Patterns Evolve:
It’s important to understand not just the structure but also the responsibilities of each component.
Be Prepared for Deeper Questions:
Interviewers often go beyond surface-level questions to test your understanding of concepts.
Reflection is Key:
While I didn’t have a perfect answer in the moment, reflecting on the question helped me solidify my understanding for the future.

If you’re preparing for iOS interviews, take some time to deeply understand how design patterns distribute responsibilities. MVC and MVVM are more than just acronyms — they represent different philosophies in organizing code.

I hope this insight helps you in your interview journey. Have you faced similar questions? I’d love to hear about your experiences!