1. What is Declarative Programming (SwiftUI)?

SwiftUI is Apple’s framework introduced in 2019 for developing user interfaces in a declarative way. In declarative UI, you describe what the UI should look like, not how to create it. You declare your user interface and its behavior in a way that is much closer to natural language, using SwiftUI’s body property.

Key Characteristics of SwiftUI:

• Less Code: SwiftUI requires fewer lines of code to achieve the same result as UIKit.
• Data-driven: The UI components are a function of the state. When the state changes, the UI updates automatically.
• Consistency Across Platforms: SwiftUI works across all Apple platforms, providing a unified development experience.
• Live Preview: With SwiftUI, you can see live previews of your UI as you code.

import SwiftUI

struct ContentView: View {
    @State private var isButtonPressed = false

    var body: some View {
        Button(action: {
            self.isButtonPressed.toggle()
        }) {
            Text(isButtonPressed ? "Pressed!" : "Press Me")
        }
    }
}

In this SwiftUI code, we describe a Button and its behavior. The UI automatically updates when isButtonPressed changes, without any need for explicit UI manipulation code.

2. What is Imperative Programming (UIKit)?

UIKit, the traditional framework used in iOS development, is imperative. This means you instruct the program how to perform operations to achieve the desired UI. You manually update the UI based on the state of the application, often leading to more boilerplate code.

Key Characteristics of UIKit:

• Detailed Control: UIKit gives you granular control over UI elements and their behaviors.
• Familiarity and Maturity: Being older, UIKit has a vast community, resources, and a proven track record.
• Manual Updates: Changes in the UI need to be manually handled, requiring more lines of code and effort.

import UIKit

class ViewController: UIViewController {
    private var isButtonPressed = false
    private let button = UIButton()

    override func viewDidLoad() {
        super.viewDidLoad()
        setupButton()
    }

    private func setupButton() {
        button.setTitle("Press Me", for: .normal)
        button.addTarget(self, action: #selector(buttonTapped), for: .touchUpInside)
        // additional code to layout the button
    }

    @objc private func buttonTapped() {
        isButtonPressed.toggle()
        updateButtonTitle()
    }

    private func updateButtonTitle() {
        button.setTitle(isButtonPressed ? "Pressed!" : "Press Me", for: .normal)
    }
}

In the UIKit example, we manually manage the state and update the UI (button title) based on the user interaction.

3. SwiftUI vs UIKit – Main Differences

Declarative vs. Imperative:

• SwiftUI: You declare the UI elements and their dependencies on data (datasource). The framework takes care of the rest.
• UIKit: You explicitly create and manage UI elements and their lifecycle.

State Management and UI Updates:

• SwiftUI: The view is a function of the state. Any changes in the state lead to a re-render of the UI.
• UIKit: You have to manually listen to changes and update the UI accordingly.

Code Conciseness and Readability:

• SwiftUI: Less and more readable code. Easier for beginners and reduces the chance of bugs.
• UIKit: More verbose, offering finer control but at the cost of more code.

4. How Views Update in SwiftUI and UIKit

SwiftUI:

In SwiftUI, the view automatically updates when the state changes. SwiftUI’s view is a struct, which is a value type, ensuring a single source of truth. When the underlying data changes, SwiftUI intelligently re-renders the view to reflect those changes, making the data flow seamless and straightforward.

UIKit:

In UIKit, updating the view is a manual process. When the data changes, you need to write additional code to update the UI elements. This approach gives you more control but requires a deeper understanding of the view lifecycle and state management.

Conclusion

In summary, SwiftUI’s declarative nature offers a modern, efficient, and streamlined approach to UI development in iOS, ideal for rapid development and reducing boilerplate code. UIKit, with its imperative approach, provides detailed control and is backed by years of community support and resources. Both have their place in iOS development, and the choice largely depends on the project requirements and developer preference.

The post SwiftUI vs UIKit – Declarative vs. Imperative Programming appeared first on AppMakers.Dev.

SwiftUI Weather Display: A Facade Pattern Implementation

To demonstrate the Facade Pattern’s prowess, let’s walk through a SwiftUI example that fetches and displays weather information. This scenario involves coordinating multiple services—temperature, humidity, and weather conditions—into a cohesive and user-friendly interface.

Step 1: Laying the Groundwork with Subsystems

Our first task is to define the subsystems responsible for delivering distinct weather metrics:

class TemperatureService {
    func getTemperature() -> String { "72°F" }
}

class HumidityService {
    func getHumidity() -> String { "65%" }
}

class ConditionService {
    func getCondition() -> String { "Sunny" }
}

Step 2: Crafting the Facade

With our subsystems in place, we then construct a Facade, WeatherFacade, to abstract the complexities of individual service interactions:

class WeatherFacade {
    private let temperatureService = TemperatureService()
    private let humidityService = HumidityService()
    private let conditionService = ConditionService()
    
    func getWeatherInfo() -> String {
        let temp = temperatureService.getTemperature()
        let humidity = humidityService.getHumidity()
        let condition = conditionService.getCondition()
        
        return "It's \(temp) with \(humidity) humidity and \(condition) outside."
    }
}

Step 3: Integrating the Facade within SwiftUI

Finally, we employ the Facade in a SwiftUI view, enabling a seamless display of integrated weather information:

import SwiftUI

struct ContentView: View {
    private let weatherFacade = WeatherFacade()
    
    var body: some View {
        VStack {
            Text("Current Weather:")
                .font(.headline)
            Text(weatherFacade.getWeatherInfo())
                .font(.title)
        }
        .padding()
    }
}

Learn more: App Design Patterns in SwiftUI

The post Facade Pattern in SwiftUI appeared first on AppMakers.Dev.

Transforming Data with the Adapter Pattern: A SwiftUI Temperature Conversion

Consider the task of integrating a Fahrenheit-based temperature reading into a SwiftUI app designed to display Celsius. The Adapter Pattern provides the perfect framework to reconcile these differences, facilitating a seamless data transformation.

Step 1: Establishing the Foundation with Legacy Systems

Our journey begins with a legacy temperature sensor, deeply entrenched in the Fahrenheit scale:

// Legacy system
class FahrenheitTemperatureSensor {
    func getTemperatureFahrenheit() -> Double {
        return 72.0 // Sample temperature in Fahrenheit
    }
}

Step 2: Crafting the Adapter for Celsius Conversion

Next, we introduce the Adapter, a pivotal component that translates Fahrenheit readings into the Celsius scale:

// Adapter
class CelsiusTemperatureAdapter {
    private var fahrenheitSensor: FahrenheitTemperatureSensor
    
    init(fahrenheitSensor: FahrenheitTemperatureSensor) {
        self.fahrenheitSensor = fahrenheitSensor
    }
    
    func getTemperatureCelsius() -> Double {
        return (fahrenheitSensor.getTemperatureFahrenheit() - 32) * 5 / 9
    }
}

Step 3: Integrating the Adapter within SwiftUI

With the Adapter in hand, we can now effortlessly incorporate Celsius temperature readings into our SwiftUI view:

import SwiftUI

struct ContentView: View {
    private let sensor = FahrenheitTemperatureSensor()
    private var adapter: CelsiusTemperatureAdapter
    
    init() {
        adapter = CelsiusTemperatureAdapter(fahrenheitSensor: sensor)
    }
    
    var body: some View {
        VStack {
            Text("Temperature")
                .font(.headline)
            Text("\(adapter.getTemperatureCelsius(), specifier: "%.1f") °C")
                .font(.title)
        }
    }
}

This approach not only showcases the Adapter Pattern’s ability to facilitate interoperability within SwiftUI apps but also underscores its role in enhancing app functionality without the need for extensive rework or overhaul of existing systems.

Learn more: App Design Patterns in SwiftUI

The post Adapter Pattern in SwiftUI appeared first on AppMakers.Dev.

The Factory Pattern: A Catalyst for Modular SwiftUI Development

Picture yourself navigating the vast corridors of an advanced manufacturing facility, where each section is dedicated to assembling a distinct model of vehicle, tailored to precise specifications. This analogy parallels the Factory Pattern’s role in programming, where it abstracts the instantiation process, enabling the creation of objects without necessitating knowledge of the underlying class that produces them.

Implementing the Factory Pattern: A SwiftUI Scenario

Let’s delve into an illustrative example of employing the Factory Pattern within a SwiftUI application, aimed at producing a versatile and engaging animal sound generator.

Defining the Blueprint: The AnimalSound Protocol

Initially, we outline a protocol to serve as a blueprint for our sound-producing entities, ensuring uniformity across all implementations:

protocol AnimalSound {
    func makeSound() -> String
}

struct CatSound: AnimalSound {
    func makeSound() -> String { "Meow!" }
}

struct DogSound: AnimalSound {
    func makeSound() -> String { "Woof!" }
}

The Factory at Work: AnimalSoundFactory

The Factory Pattern comes into play, dictating the creation logic and deciding the specific product to generate based on the provided identifier:

enum AnimalType {
    case cat, dog
}

class AnimalSoundFactory {
    static func createAnimalSound(for type: AnimalType) -> AnimalSound {
        switch type {
        case .cat:
            return CatSound()
        case .dog:
            return DogSound()
        }
    }
}

Bringing It All Together in SwiftUI

The Factory’s versatility shines in a SwiftUI view, allowing users to select their preferred animal and hear the corresponding sound:

struct ContentView: View {
    @State private var selectedAnimal: AnimalType = .cat
    @State private var animalSound: String = ""
    
    var body: some View {
        VStack {
            Picker("Select an animal", selection: $selectedAnimal) {
                Text("Cat").tag(AnimalType.cat)
                Text("Dog").tag(AnimalType.dog)
            }
            .pickerStyle(SegmentedPickerStyle())
            .padding()
            
            Button("Make Sound") {
                let animal = AnimalSoundFactory.createAnimalSound(for: selectedAnimal)
                animalSound = animal.makeSound()
            }
            
            Text(animalSound)
                .font(.largeTitle)
                .padding()
        }
    }
}

The post Factory Pattern in SwiftUI appeared first on AppMakers.Dev.

The Essence of the Builder Pattern in SwiftUI Development

Imagine the process of assembling a deluxe sandwich, where each layer, from the choice of bread to the variety of fillings, is selected to match your taste preferences perfectly. The Builder Pattern in SwiftUI operates on a similar principle, allowing developers to construct UI components with precision, specifying attributes step-by-step to achieve the desired outcome without overwhelming the initial setup call with parameters.

Crafting Custom UI Elements with the Builder Pattern

To bring this concept to life, let’s delve into a practical application within SwiftUI, illustrating how the Builder Pattern can be harnessed to create customizable text elements.

The CustomTextBuilder Blueprint

Our journey begins with defining a CustomTextBuilder, a struct designed to construct text views tailored to specific stylistic preferences:

struct CustomTextBuilder {
    private var text: String
    private var font: Font = .body
    private var textColor: Color = .black
    private var alignment: TextAlignment = .leading
    
    init(_ text: String) {
        self.text = text
    }
    
    func font(_ font: Font) -> CustomTextBuilder {
        var builder = self
        builder.font = font
        return builder
    }
    
    func textColor(_ color: Color) -> CustomTextBuilder {
        var builder = self
        builder.textColor = color
        return builder
    }
    
    func multilineTextAlignment(_ alignment: TextAlignment) -> CustomTextBuilder {
        var builder = self
        builder.alignment = alignment
        return builder
    }
    
    func build() -> some View {
        Text(text)
            .font(font)
            .foregroundColor(textColor)
            .multilineTextAlignment(alignment)
    }
}

This builder equips developers with a fluent interface to configure text elements — from font size and color to alignment — in a clear and concise manner.

Implementing in SwiftUI Views

Utilizing the CustomTextBuilder within a SwiftUI view showcases its potential to enhance both code readability and UI customization:

struct ContentView: View {
    var body: some View {
        VStack {
            CustomTextBuilder("Welcome to SwiftUI Patterns!")
                .font(.title)
                .textColor(.blue)
                .multilineTextAlignment(.center)
                .build()
            
            CustomTextBuilder("Embrace the power of the Builder Pattern.")
                .font(.headline)
                .textColor(.green)
                .multilineTextAlignment(.leading)
                .build()
        }
    }
}

Learn more: App Design Patterns in SwiftUI

The post Builder Pattern in SwiftUI appeared first on AppMakers.Dev.

The Singleton Pattern: Your App’s Universal Remote Control

Picture a scenario where you possess a universal remote control capable of commanding every digital device in your space with the push of a button. This remote is the only one of its kind and simplifies the control over your devices, embodying the essence of the Singleton pattern in software development.

This design pattern ensures a class has just one instance while providing a global point of access to that instance. It’s akin to having a single, shared control point for managing app-wide settings or preferences, guaranteeing consistency across your application’s lifecycle.

Implementing the Singleton Pattern in SwiftUI: A User Preferences Case Study

In our case study, we’ll employ the Singleton pattern to manage user preferences within a SwiftUI app. This centralized approach allows for the modification of settings such as notification permissions and background color from anywhere within the app, reflecting changes instantaneously across all views that rely on these preferences.

User Preferences Singleton

Here’s how we define a class to manage user preferences, utilizing the Singleton pattern:

class UserPreferences {
    static let shared = UserPreferences()
    
    var notificationsEnabled: Bool = false
    var bgColor: Color = .white
    
    private init() {} // Ensures Singleton pattern adherence
}

SwiftUI ContentView

Within the ContentView, we leverage the Singleton to adapt the app’s settings based on user interactions:

struct ContentView: View {
    @State private var notificationsEnabled: Bool = UserPreferences.shared.notificationsEnabled

    var body: some View {
        ZStack {
            UserPreferences.shared.bgColor
            Form {
                Toggle("Enable Notifications", isOn: $notificationsEnabled)
                    .onChange(of: notificationsEnabled) { _, newValue in
                        UserPreferences.shared.notificationsEnabled = newValue
                        // Toggle the background color between two states
                        UserPreferences.shared.bgColor = UserPreferences.shared.bgColor == .red ? .blue : .red
                    }
            }
            .padding()
        }
        .ignoresSafeArea()
    }
}

In this example, a toggle switch allows users to enable or disable notifications, demonstrating the Singleton pattern’s utility in managing shared application states and preferences. Changes in the toggle state are instantly applied app-wide, thanks to the centralized management of settings through the UserPreferences class.

Learn more: App Design Patterns in SwiftUI

The post Singleton Pattern in SwiftUI appeared first on AppMakers.Dev.

The Observer Pattern: A Digital Classroom

Visualize a digital classroom where notifications and updates are constantly shared. Just as students stay alert to the teacher’s announcements, in app development, certain components keep an eye on specific data or state changes to react accordingly. This scenario mirrors the essence of the Observer pattern – establishing a watchful relationship between objects, where one (the subject) notifies others (the observers) about changes in its state.

Practical Application in SwiftUI: BooksCounterViewModel

Consider a SwiftUI application designed to track the number of books in a library. Employing the Observer pattern allows the app to update its UI in real-time as new books are added to the collection.

Implementation Example:

@Observable class BooksCounterViewModel {
   
    var booksCount: Int = 0

    func addBook() {
        booksCount += 1
    }
}

struct ContentView: View {
   
    let viewModel = BooksCounterViewModel()

    var body: some View {
        VStack {
            
          
            Button("Add One More Book", action: {
                viewModel.addBook()
            }).padding(.bottom)
            
            
            
            Text("\(viewModel.booksCount) books in the Library")
            
        }
        .padding()
    }
}

In this example, BooksCounterViewModel acts as the subject, keeping track of the book count. The ContentView, serving as the observer, reflects changes to booksCount instantly, ensuring the UI remains accurate and up-to-date without manual intervention.

Learn more: App Design Patterns in SwiftUI

The post Observer Pattern SwiftUI appeared first on AppMakers.Dev.

The MVVM Pattern: A Culinary Analogy

Picture yourself as a chef orchestrating a grand dinner party. Your pantry stocked with ingredients (the Model) is the foundation of your feast, encompassing everything from veggies to spices. The dishes you meticulously prepare in the kitchen (the ViewModel) are tailored creations, blending ingredients with culinary techniques. Finally, the guests at your table (the View) eagerly await, ready to savor the meal presented before them, yet unaware of the kitchen’s hustle.

In SwiftUI, this narrative translates seamlessly. The Model is your app’s data and business logic, akin to raw ingredients waiting to be transformed. The ViewModel, much like the chef, takes these ingredients, whips up a dish applying specific techniques (or business logic), and decides how the meal (data) should be served. The View, mirroring the dinner party guests, presents this data in a user-friendly manner, offering an interface for users to interact with the app.

This delineation ensures a manageable app architecture, with the ViewModel acting as a mediator to process data, allowing the View to focus solely on presentation. It’s a pattern that not only promises a well-structured codebase but also aligns with SwiftUI’s declarative UI paradigm, making it a favored choice among developers for building scalable and maintainable apps.

Implementing MVVM in SwiftUI: An Example

Let’s put theory into practice with a simple MVVM example in SwiftUI, focusing on a list of people with the ability to dynamically add a new person.

Model

The Model represents the basic data structure:

struct Person {
    var name: String
    var age: Int
}

ViewModel

The ViewModel manages the data and prepares it for presentation:

@Observable class PersonListViewModel {
    var persons = [Person]()
    
    func addPerson(name: String, age: Int) {
        let newPerson = Person(name: name, age: age)
        persons.append(newPerson)
    }
}

Mock Data

Mock data simulates a dataset for initial display:

struct MockData {
    static let persons = [Person(name: "Ali", age: 18), Person(name: "Jane", age: 22)]
}

View

The View displays the data, allowing user interaction:

struct ContentView: View {
    var viewModel = PersonListViewModel()

    var body: some View {
        VStack {
            List(viewModel.persons, id: \.name) { person in
                Text("\(person.name), Age: \(person.age)")
            }
            .onAppear {
                if viewModel.persons.isEmpty {
                    viewModel.persons = MockData.persons
                }
            }
            
            Button("Add Alex, 30") {
                viewModel.addPerson(name: "Alex", age: 30)
            }
        }
    }
}

If you want to learn about other App Design Patterns in SwiftUI, Read this Guide

The post MVVM in SwiftUI – Design Pattern appeared first on AppMakers.Dev.

1. MVVM Pattern (Model-View-ViewModel)

Imagine you’re organizing a dinner party. You’re the chef (the ViewModel) in charge of preparing the meal, which is based on ingredients (the Model) like vegetables, meats, and spices. Your guests (the View) are waiting at the dining table, eager to enjoy whatever you serve them. You decide how to combine the ingredients into dishes, when to serve them, and how to present them on the plates. Your guests don’t see the preparation in the kitchen; they only see the beautifully prepared dishes you bring out to them.

In app development, the MVVM pattern (Model-View-ViewModel) mirrors this dinner party. The Model is like your ingredients, the raw data and business logic of your app. The View is akin to your guests, the user interface that presents the data to the user. The ViewModel is you, the chef, taking the Model’s data, preparing it (applying business logic), and deciding what and how the View should display the data.

This separation of concerns makes the app’s architecture more manageable. The ViewModel acts as a mediator that handles the logic and preparation of data, ensuring the View can remain simple and just focus on presenting the data. It leads to more maintainable and testable code, as each component has its distinct responsibility, much like how a well-organized dinner party runs smoothly when everyone knows their roles.

The MVVM pattern is widely used in SwiftUI for decoupling UI code from business logic and data models, facilitating easier testing and maintenance.

Here is a MVVM pattern example:

// Model
struct Person {
    var name: String
    var age: Int
}

// ViewModel

@Observable class PersonListViewModel {
   
    var persons = [Person]()
    
    func addPerson(name: String, age: Int) {
        let newPerson = Person(name: name, age: age)
        persons.append(newPerson)
    }
    
}


// MockData

struct MockData {
    
    static let persons = [Person(name: "Ali", age: 18), Person(name: "Jane", age: 22)]
    
}

// View
struct ContentView: View {
    
    let viewModel = PersonListViewModel()

    var body: some View {
        
        VStack {
            
            List(viewModel.persons, id: \.name) { person in
                Text("\(person.name), Age: \(person.age)")
            }.onAppear {
                
                if viewModel.persons.isEmpty {
                    viewModel.persons = MockData.persons
                }
            }
            
            Button {
                
                viewModel.persons.append(Person(name: "Alex", age: 30))
                
            } label: {
                Text("Add Alex, 30")
            }

            
        }
        
    }
}

#Preview {
    ContentView()
}

2. Observation Pattern

Imagine you’re in a classroom where the teacher is an announcer with a news bulletin. Whenever there’s an update or news, the teacher announces it to the entire class. As a student (listener), if you’re in the class, you hear the news right away. If you step out, you miss the update. When you return, you’re back in the loop for any new announcements.

In programming, the Observer pattern works similarly. It’s a way for objects (observers) to “listen” for changes or updates in another object (the subject). The subject keeps a list of its observers and notifies them of any state changes, usually by calling one of their methods.

This pattern is useful when you want to create a system where changes to one object need to be automatically reflected in others. For example, in a weather app, the weather station (subject) might broadcast temperature updates to multiple display elements (observers), like a temperature gauge or a forecast panel, ensuring they all show the current temperature without having to check it individually.

The Observer pattern allows objects to notify other objects about changes in their state. SwiftUI’s @Published and ObservableObject leverage this pattern. Starting iOS 17 we can use @Observable without using @Published and ObservableObject

@Observable class BooksCounterViewModel {
   
    var booksCount: Int = 0

    func addBook() {
        booksCount += 1
    }
}

struct ContentView: View {
   
    let viewModel = BooksCounterViewModel()

    var body: some View {
        VStack {
            
          
            Button("Add One More Book", action: {
                viewModel.addBook()
            }).padding(.bottom)
            
            
            
            Text("\(viewModel.booksCount) books in the Library")
            
        }
        .padding()
    }
}

3. Singleton Pattern

Imagine you have only one remote control that works with all the electronic devices in your living room. No matter where you are in the room or which device you want to control, you reach for that same remote. This remote control is unique; there’s just one for everything, making it simple and convenient to manage your devices.

In programming, the Singleton pattern is like having that one remote control. It ensures that a class has only one instance and provides a global point of access to it. This means no matter how many times you try to create a new instance of this class, you’ll always get the same, single instance.

Singleton Pattern: User Preferences Example

The Singleton pattern ensures that only one instance of a class exists throughout the app’s lifecycle. Here, we’ll use it to manage user preferences.

class UserPreferences {
    static let shared = UserPreferences()
    
    var notificationsEnabled: Bool = false
    
    var bgColor: Color?
    
    private init() {} // Private initializer to ensure Singleton usage
}

SwiftUI ContentView

In the ContentView, we use the Singleton to toggle notification settings and background color.

struct ContentView: View {
  
    @State private var notificationsEnabled: Bool = UserPreferences.shared.notificationsEnabled

    var body: some View {
        
        ZStack {
            
            UserPreferences.shared.bgColor ?? .white
         
            Form {
            
                Toggle("Enable Notifications and change BG", isOn: $notificationsEnabled)
            }
            .background( UserPreferences.shared.bgColor ?? .white)
            .scrollContentBackground(.hidden)
            .onChange(of: notificationsEnabled, initial: true) { oldValue, newValue in
                
                UserPreferences.shared.notificationsEnabled = newValue
                
                if UserPreferences.shared.bgColor == .red {
                    
                    UserPreferences.shared.bgColor = .blue
                  
                } else {
                    
                    UserPreferences.shared.bgColor = .red
                    
                }
                
            }
            .padding()
        }
        .padding(.top)
        .ignoresSafeArea()
        
    }
    
}

4. Builder Pattern

The Builder pattern is like ordering a custom burger at a restaurant. Instead of telling the chef all your preferences at once (which can be easy to mix up or forget), you specify each ingredient step by step: “Start with a beef patty, add lettuce, then cheese, and finally, pickles.” This way, you ensure the burger is made exactly to your liking, with all your chosen ingredients.

In programming, the Builder pattern lets you construct complex objects piece by piece. Instead of creating an object all at once (which might require a lot of parameters, some of which could be optional), you use a builder class that takes care of assembling the object for you. You call methods on the builder, each adding a part of the final object, and then finally, you ask the builder to give you the completed object.

This pattern is especially useful when you have an object that requires several steps to build or when the object needs many variations. It makes your code cleaner and more readable, as you avoid constructors with lots of parameters and can clearly see which object parts are being set at each step.

CustomText Builder

This builder will allow us to chain configuration methods to set up a Text view with various styles.

struct CustomTextBuilder {
    private var text: String
    private var font: Font = .body
    private var textColor: Color = .black
    private var multilineTextAlignment: TextAlignment = .leading
    
    init(_ text: String) {
        self.text = text
    }
    
    func font(_ font: Font) -> CustomTextBuilder {
        var builder = self
        builder.font = font
        return builder
    }
    
    func textColor(_ color: Color) -> CustomTextBuilder {
        var builder = self
        builder.textColor = color
        return builder
    }
    
    func multilineTextAlignment(_ alignment: TextAlignment) -> CustomTextBuilder {
        var builder = self
        builder.multilineTextAlignment = alignment
        return builder
    }
    
    func build() -> some View {
        Text(text)
            .font(font)
            .foregroundColor(textColor)
            .multilineTextAlignment(multilineTextAlignment)
    }
}

Usage in ContentView

Now, let’s use our CustomTextBuilder in a ContentView to demonstrate its flexibility and how it enhances readability and customization.

import SwiftUI

struct ContentView: View {
    var body: some View {
        VStack {
            CustomTextBuilder("Hello, UIExamples.com Friend!")
                .font(.title)
                .textColor(.blue)
                .multilineTextAlignment(.center)
                .build()
            
            CustomTextBuilder("This is an example using the Builder Pattern.")
                .font(.headline)
                .textColor(.red)
                .multilineTextAlignment(.leading)
                .build()
        }
    }
}

struct ContentView_Previews: PreviewProvider {
    static var previews: some View {
        ContentView()
    }
}

5. Strategy Pattern

The Strategy pattern is a design pattern that lets you define a family of algorithms, put each of them into a separate class, and make their objects interchangeable. Imagine you have a task, and there are multiple ways (strategies) to accomplish it. The Strategy pattern allows you to switch between these strategies easily, even during runtime, based on the situation or user preference.

Here’s an easy way to understand it:

Think of the Strategy pattern as going on a trip and having to choose the mode of transportation. Your goal (task) is to get to your destination, but you can get there in several ways: you could drive a car, take a bus, ride a bike, or even walk. Each of these modes of transportation represents a different strategy for achieving your goal.

Using the Strategy pattern, you can easily switch your transportation method without changing your destination or how you plan your trip. Just like you might choose to ride a bike on a sunny day or take a bus when it’s raining, the Strategy pattern allows your software to adapt its behavior dynamically by switching between different algorithms or strategies based on the current conditions or user preferences.

Strategy Pattern Example

This simplified example of the Strategy pattern allows users to switch between bold and italic text styles within the app. By adhering to the TextStyleStrategy protocol, BoldTextStyleStrategy and ItalicTextStyleStrategy provide concrete implementations for styling text. The ContentView includes a toggle for the user to select their preferred text style. Depending on the toggle state (useBoldText), it dynamically chooses the appropriate strategy to apply to the displayed text. This pattern showcases how you can encapsulate and interchange different behaviors (text styles, in this case) seamlessly within a SwiftUI view.

First, we define a protocol that all our text style strategies will conform to.

protocol TextStyleStrategy {
    func applyStyle(to text: String) -> Text
}

Implement Concrete Strategies

Next, we create concrete implementations of TextStyleStrategy for bold and italic text styles.

struct BoldTextStyleStrategy: TextStyleStrategy {
    func applyStyle(to text: String) -> Text {
        Text(text).fontWeight(.bold)
    }
}

struct ItalicTextStyleStrategy: TextStyleStrategy {
    func applyStyle(to text: String) -> Text {
        Text(text).italic()
    }
}

ContentView with Strategy Selection

In ContentView, the user can toggle between bold and italic text styles.

import SwiftUI

struct ContentView: View {
    @State private var useBoldText = true
    
    private let text = "Hello, Strategy Pattern!"
    
    var body: some View {
        VStack(spacing: 20) {
            Text("Choose Text Style:")
            Toggle("Use Bold Text", isOn: $useBoldText)
                .fixedSize()
            
            if useBoldText {
                BoldTextStyleStrategy().applyStyle(to: text)
            } else {
                ItalicTextStyleStrategy().applyStyle(to: text)
            }
        }
        .padding()
        .frame(maxWidth: .infinity, maxHeight: .infinity)
    }
}

struct ContentView_Previews: PreviewProvider {
    static var previews: some View {
        ContentView()
    }
}

6. Factory Pattern

Imagine you’re at a car manufacturing plant where there are different assembly lines for various car models. When you order a car, you don’t worry about the specifics of how each part is assembled. Instead, you just specify the model you want, and the factory takes care of producing the car according to that model’s specifications.

The Factory pattern in programming works similarly. It provides a way to create objects without specifying the exact class of object that will be created. You define an interface or a base class for creating an object, but let subclasses or another class decide which class to instantiate. This pattern is particularly useful when you have a set of related objects that share a common theme but have different details.

Simple SwiftUI Example: Animal Sounds

Let’s create a simple SwiftUI app that uses the Factory pattern to play different animal sounds.

This SwiftUI app demonstrates the Factory pattern by allowing the user to select an animal (Cat or Dog) and display the corresponding animal sound when a button is pressed. The AnimalSoundFactory acts as the factory, creating an instance of AnimalSound based on the selected animal type, abstracting the creation logic away from the ContentView. This way, the ContentView doesn’t need to know about the concrete implementation details of each animal sound, following the Factory pattern’s principle of creating objects without specifying their concrete classes.

First, define an interface for your product, in this case, AnimalSound, and then implement concrete products.

protocol AnimalSound {
    func makeSound() -> String
}

struct CatSound: AnimalSound {
    func makeSound() -> String { "Meow!" }
}

struct DogSound: AnimalSound {
    func makeSound() -> String { "Woof!" }
}

Create the Factory

Now, implement the Factory to decide which product to create based on an identifier.

enum AnimalType {
    case cat, dog
}

class AnimalSoundFactory {
    static func createAnimalSound(for type: AnimalType) -> AnimalSound {
        switch type {
        case .cat:
            return CatSound()
        case .dog:
            return DogSound()
        }
    }
}

Use in SwiftUI View

Finally, use the Factory in a SwiftUI view to display an animal sound based on user selection.

struct ContentView: View {
    @State private var selectedAnimal: AnimalType = .cat
    @State private var animalSound: String = ""
    
    var body: some View {
        VStack {
            Picker("Select an animal", selection: $selectedAnimal) {
                Text("Cat").tag(AnimalType.cat)
                Text("Dog").tag(AnimalType.dog)
            }
            .pickerStyle(SegmentedPickerStyle())
            .padding()
            
            Button("Make Sound") {
                let animal = AnimalSoundFactory.createAnimalSound(for: selectedAnimal)
                animalSound = animal.makeSound()
            }
            
            Text(animalSound)
                .font(.largeTitle)
                .padding()
        }
    }
}

7. Adapter Pattern

Imagine you’re on a trip abroad and you’ve brought along your favorite electronic gadgets. Upon arriving, you realize the plug of your charger doesn’t fit the local electrical outlets. The solution? You use an adapter that allows your charger to connect to the local outlets, enabling you to use your devices without any issue.

The Adapter pattern in programming serves a similar purpose. It allows objects with incompatible interfaces to work together. Essentially, it acts as a bridge between two incompatible interfaces, much like a physical adapter connects plugs to foreign outlets.

Simple SwiftUI Example: Temperature Display

Let’s say we have a legacy temperature sensor system that provides temperature in Fahrenheit, but we want to display the temperature in Celsius in our SwiftUI app. We can use the Adapter pattern to bridge the Fahrenheit system to our Celsius-based display.

Step 1: Define the Incompatible Interface and Adapter

First, we have our legacy system that gives us the temperature in Fahrenheit.

// Legacy system
class FahrenheitTemperatureSensor {
    func getTemperatureFahrenheit() -> Double {
        return 72.0 // Example temperature in Fahrenheit
    }
}

Next, we create an adapter to convert Fahrenheit to Celsius.

// Adapter
class CelsiusTemperatureAdapter {
    private var fahrenheitSensor: FahrenheitTemperatureSensor
    
    init(fahrenheitSensor: FahrenheitTemperatureSensor) {
        self.fahrenheitSensor = fahrenheitSensor
    }
    
    func getTemperatureCelsius() -> Double {
        return (fahrenheitSensor.getTemperatureFahrenheit() - 32) * 5 / 9
    }
}

Step 2: Use the Adapter in SwiftUI View

Now, let’s use the adapter in our SwiftUI view to display the temperature in Celsius.

import SwiftUI

struct ContentView: View {
    private let sensor = FahrenheitTemperatureSensor()
    private var adapter: CelsiusTemperatureAdapter
    
    init() {
        adapter = CelsiusTemperatureAdapter(fahrenheitSensor: sensor)
    }
    
    var body: some View {
        VStack {
            Text("Temperature")
                .font(.headline)
            Text("\(adapter.getTemperatureCelsius(), specifier: "%.1f") °C")
                .font(.title)
        }
    }
}

struct ContentView_Previews: PreviewProvider {
    static var previews: some View {
        ContentView()
    }
}

Explanation

This SwiftUI example illustrates the Adapter pattern by using a CelsiusTemperatureAdapter to convert temperatures from Fahrenheit (provided by a legacy FahrenheitTemperatureSensor) to Celsius, enabling the ContentView to display the temperature in the desired format. The adapter effectively bridges the gap between the old Fahrenheit system and the new requirement to display temperatures in Celsius, demonstrating how the Adapter pattern can solve compatibility issues in software development.

8. Facade Pattern

Imagine you’re at a complex entertainment system with multiple devices: a TV, a Blu-ray player, a sound system, and maybe even a game console. Each device has its own remote and settings. Turning on a movie involves several steps across different devices. Now, imagine having a single remote with a “Watch Movie” button that knows exactly which devices to turn on, which inputs to set, and what volume is just right. This simplification is what the Facade pattern does in programming.

The Facade pattern provides a simplified interface to a complex system, making it easier to use. It doesn’t remove the complexity; it just hides it behind a simpler interface.

Simple SwiftUI Example: Weather Info Display

Let’s create a Facade that simplifies fetching and displaying weather information from multiple subsystems (like temperature, humidity, and weather condition) into a single, easy-to-use interface.

This SwiftUI example demonstrates the Facade pattern by encapsulating the complexity of fetching weather information from multiple services (temperature, humidity, condition) into a single WeatherFacade class. The ContentView then uses this facade to display the combined weather information in a simple and concise way. The Facade pattern allows developers to work with a complex system through a simplified interface, making it easier to use and reducing dependencies.

Step 1: Define Subsystems

First, define the subsystems that provide specific pieces of weather information.

class TemperatureService {
    func getTemperature() -> String { "72°F" }
}

class HumidityService {
    func getHumidity() -> String { "65%" }
}

class ConditionService {
    func getCondition() -> String { "Sunny" }
}

Step 2: Create the Facade

Next, create a Facade that uses these services to provide simplified access to the weather information.

class WeatherFacade {
    private let temperatureService = TemperatureService()
    private let humidityService = HumidityService()
    private let conditionService = ConditionService()
    
    func getWeatherInfo() -> String {
        let temp = temperatureService.getTemperature()
        let humidity = humidityService.getHumidity()
        let condition = conditionService.getCondition()
        
        return "It's \(temp) with \(humidity) humidity and \(condition) outside."
    }
}

Step 3: Use the Facade in SwiftUI View

Finally, use the Facade in a SwiftUI view to display the weather information.

import SwiftUI

struct ContentView: View {
    private let weatherFacade = WeatherFacade()
    
    var body: some View {
        Text(weatherFacade.getWeatherInfo())
            .padding()
    }
}

struct ContentView_Previews: PreviewProvider {
    static var previews: some View {
        ContentView()
    }
}

The post App Design Patterns in SwiftUI: A Comprehensive Guide appeared first on AppMakers.Dev.