This article will break down the key differences between structs and classes in modern SwiftUI development and how SwiftData influences these choices.

The Basics: Structs vs. Classes

Structs

• Value types: Structs are copied when passed or assigned to new variables.
• Immutable by default: Changes to a struct instance do not affect other copies.
• No ARC (Automatic Reference Counting): Structs are more lightweight, and Swift can optimize them for better performance.
• Better for simple data: Ideal for models that represent small, self-contained pieces of data.

Classes

• Reference types: Classes are passed by reference, meaning changes made to one instance affect all references to it.
• Mutable by nature: Changes can propagate across references, which is useful when you need shared state.
• Managed by ARC: Classes come with ARC, which tracks and manages the lifecycle of objects.
• Better for shared or complex data: Ideal for cases where objects need to be shared across different parts of your app or involve relationships.

SwiftUI: Using Structs for Models

In most SwiftUI applications, structs are the default choice for models. Since SwiftUI is designed around declarative programming principles, structs’ value semantics align perfectly with SwiftUI’s philosophy.

Here’s an example of using a struct for a simple Person model:

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

Why Use Structs in SwiftUI?

1. Performance: Structs are faster and more efficient due to their value semantics.
2. Predictability: Since structs are copied when passed, each instance is independent, which makes it easier to reason about your code.
3. Concurrency Safety: Structs’ immutability (unless explicitly mutable) helps avoid issues when working with concurrency.

In simple terms, structs are great for SwiftUI models when you:

• Don’t need shared state between views or components.
• Are modeling simple data that doesn’t rely on persistence frameworks like SwiftData.

SwiftData and the Case for Classes

While structs are great for lightweight models, the need for classes becomes apparent when working with SwiftData (or other persistence frameworks, like Core Data). SwiftData requires reference semantics, making classes necessary for models to ensure data consistency and lifecycle management.

Here’s an example of a Person model in SwiftData:

import SwiftData

@Model
class Person {
    var name: String
    var age: Int
    
    init(name: String, age: Int) {
        self.name = name
        self.age = age
    }
}

Why Use Classes with SwiftData?

1. Reference Semantics: SwiftData needs objects to be shared across multiple components. If you update the Person class in one part of the app, the changes will automatically reflect everywhere it is referenced.
2. Persistence: SwiftData (and Core Data) manages object graphs, relationships, and persistence through reference types.
3. Complex Relationships: If your model has relationships (e.g., a Person having a list of friends), classes are better suited to managing these references without duplicating data.

Thus, classes are essential when:

• You’re using SwiftData or other persistence frameworks that need managed object contexts.
• Your data is shared across multiple parts of the app, and you want to observe and react to changes.
• You’re modeling complex relationships between objects.

When to Use Structs vs. Classes: A Recap

Final Thoughts

In modern SwiftUI development (2024 and beyond), structs are the default choice for most models due to their performance and value semantics. However, when working with frameworks like SwiftData—where persistence, shared state, and reference management are essential—classes become a necessity.

To summarize:

• Use structs for lightweight, simple, and self-contained models that don’t require shared state.
• Use classes when working with SwiftData or any scenario where reference semantics and persistence are required.

For more about Classes and Structs read this Article

Understanding when to use structs vs. classes will help you design more efficient and scalable SwiftUI applications. Happy coding!

The post Structs vs. Classes in SwiftUI: When to Use Each and why we use Classes in SwiftData appeared first on AppMakers.Dev.

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.

Using @AppStorage for Persistent State Management

@AppStorage reads and writes values to UserDefaults, automatically updating your view when values change. It is ideal for storing simple data types and user preferences that need to persist between app launches.

Example: Storing User Preferences with @AppStorage

import SwiftUI

struct SettingsView: View {
    @AppStorage("darkModeEnabled") private var darkModeEnabled: Bool = false

    var body: some View {
        Toggle("Enable Dark Mode", isOn: $darkModeEnabled)
            .padding()
    }
}

What’s Happening:

• The Toggle control is bound to darkModeEnabled, stored in UserDefaults under the key "darkModeEnabled".
• Changes to the toggle will automatically save to UserDefaults and the view will update accordingly to reflect the user’s preference.

Using @SceneStorage for Scene-Specific State Restoration

@SceneStorage is used to store data specific to a scene, which is useful for apps that support multiple windows or need to manage state in complex multi-scene setups like on iPadOS.

Example: Preserving Text Editor State with @SceneStorage

import SwiftUI

struct EditorView: View {
    @SceneStorage("editorContent") private var editorContent: String = ""

    var body: some View {
        NavigationStack {
            TextEditor(text: $editorContent)
                .padding()
        }
    }
}

What’s Happening:

• TextEditor is bound to editorContent, which is stored and restored automatically for each scene instance using @SceneStorage.
• If the user edits text in one window, closes the app, and reopens it, the text they were editing will be preserved and restored.

Practical Considerations

• Data Security: Neither @AppStorage nor @SceneStorage should be used for storing sensitive data as they do not provide secure storage.
• Data Volume: It is recommended to only store minimal data necessary for restoring state. Large data sets should be managed differently, possibly using databases or more secure storage solutions.

Conclusion

Using @AppStorage and @SceneStorage in SwiftUI enables developers to manage app state effectively, providing continuity for users across app launches and maintaining individual scene states in multi-window environments. By integrating these tools, you can enhance the robustness and user-friendliness of your SwiftUI applications. Experiment with these property wrappers to find the best ways to keep your app’s user interface responsive and intuitive.

The post @AppStorage and @SceneStorage in SwiftUI appeared first on AppMakers.Dev.

1. ColorPicker: This component lets users choose a color. By binding it to state variables (backgroundColor and textColor), any changes made by the user are immediately reflected in the app’s UI.
2. Customization Options: While ColorPicker supports opacity by default, you can disable it to simplify the color selection process.

import SwiftUI

struct ThemeEditorView: View {
  
@State private var backgroundColor = Color(.systemBackground) 
    @State private var textColor = Color.primary 

    var body: some View {

            Form {
             
                Section(header: Text("Customize Your Theme")) {
                    
                    ColorPicker("Background Color", selection: $backgroundColor, supportsOpacity: true)
                        .padding()
                    
                    ColorPicker("Text Color", selection: $textColor, supportsOpacity: false)
                        .padding()
                    
                }
            }.scrollContentBackground(.hidden)
            .background(backgroundColor)
            .foregroundColor(textColor)

    }

}

The post ColorPicker in SwiftUI appeared first on AppMakers.Dev.

Let’s develop a settings form for a hypothetical “Daily Water Intake Tracker” app. The form will allow users to set their daily water intake goal using a Slider, adjust notification frequency with a Stepper, and enable/disable motivational messages via a Toggle.

Explaining the Components

1. Slider: Allows users to select a value within a defined range. We use it here to set the daily water intake goal, ranging from 0 to 20 liters.
2. Stepper: Lets users increase or decrease a value. We utilize it to set how frequently the app should send notification reminders.
3. Toggle: Provides a way to enable or disable a setting. In our form, it controls whether motivational messages are active.

import SwiftUI

struct SettingsView: View {
    @State private var dailyWaterIntake = 8.0
    @State private var notificationFrequency = 1
    @State private var motivationalMessagesEnabled = true

    var body: some View {
        NavigationView {
            Form {
                Section(header: Text("Daily Goals")) {
                    Slider(value: $dailyWaterIntake, in: 0...20, step: 0.5) {
                        Text("Daily Water Intake")
                    } minimumValueLabel: {
                        Text("0L")
                    } maximumValueLabel: {
                        Text("20L")
                    } onEditingChanged: { editing in
                        print("Slider value is now \(dailyWaterIntake)")
                    }
                }

                Section(header: Text("Notifications")) {
                    Stepper("Notify me every \(notificationFrequency) hours", value: $notificationFrequency, in: 1...12)
                }

                Section(header: Text("Messages")) {
                    Toggle("Motivational Messages", isOn: $motivationalMessagesEnabled)
                }
            }
            .navigationBarTitle("Settings")
        }
    }
}

Incorporating Sliders, Steppers, and Toggles into your SwiftUI apps can significantly enhance the interactivity and functionality of your forms. By following this tutorial, you’ve learned how to effectively implement these controls in a practical application scenario. Experiment with these elements to discover new ways to engage users and gather inputs in your iOS projects.

The post Slider, Stepper, and Toggle in SwiftUI appeared first on AppMakers.Dev.

Using MultiDatePicker – Simple Vacation Tracker example

In this tutorial, we will explore how to leverage MultiDatePicker to build a user-friendly vacation tracker app. This app will not only help users plan their holidays but also visualize them in a compelling way.

Begin by setting up your SwiftUI view’s structure:

import SwiftUI

struct VacationTrackerView: View {
    @State private var selectedDates: Set<DateComponents> = []

    var body: some View {
        NavigationView {
            VStack {
                multiDatePicker
                selectedDatesList
            }
            .navigationTitle("Vacation Tracker")
            .padding()
        }
    }

    private var multiDatePicker: some View {
        MultiDatePicker(
            "Plan Your Vacations",
            selection: $selectedDates,
            displayedComponents: [.date] // Show only the date component
        )
        .frame(height: 300)
    }

    private var selectedDatesList: some View {
        List(selectedDates.sorted(by: { $0.date! < $1.date! }), id: \.self) { date in
            Text("\(date.date!, formatter: itemFormatter)")
        }
    }
}

// Helper to format the date
private let itemFormatter: DateFormatter = {
    let formatter = DateFormatter()
    formatter.dateStyle = .long
    return formatter
}()

This SwiftUI tutorial introduces you to the MultiDatePicker component, a valuable addition for any developer looking to streamline date selection in their apps. By building a vacation tracker, you learn to integrate multiple date selections with other UI elements, enhancing both functionality and aesthetics.

The post MultiDatePicker in SwiftUI appeared first on AppMakers.Dev.

Selecting a Language and Region in the Run Scheme

1. Open your project in Xcode and navigate to Product > Scheme > Edit Scheme.
2. In the scheme editor that appears, select the Run action from the sidebar on the left.
3. Go to the Options tab on the right side.
4. Under the Application Language dropdown, select the language in which you want to run your app.
5. Under the Application Region dropdown, select the specific region you want to test. You can choose from:
   • System Region – Uses the operating system’s region settings.
   • [Development Region] – Defaults to the region you’re developing the app in.
   • [Specific Region] – Allows you to choose from a list of all available regions, organized by continent.
6. After setting your preferences, click Close to save the changes and dismiss the dialog.
7. Run your app by clicking the Run button in the toolbar to see your app in the chosen language and region settings.

The post Testing Localizations in SwiftUI appeared first on AppMakers.Dev.

What is LocalizedStringKey?

LocalizedStringKey is a type used to retrieve localized strings from .strings files within your app’s bundle. When you use string literals in SwiftUI elements like Text, Toggle, or Picker, SwiftUI automatically uses LocalizedStringKey to fetch the appropriate localized version of the string. This automatic mechanism is possible because LocalizedStringKey conforms to the ExpressibleByStringLiteral protocol.

Localized and Non-Localized Text

The beauty of LocalizedStringKey lies in its flexibility. For instance, when you initialize a Text view with a string literal, SwiftUI implicitly converts this string into a LocalizedStringKey and looks up the localized string:

Text("Welcome")

In contrast, if you pass a String variable to the initializer, SwiftUI treats this as a direct instruction to use the string as-is, without localization. This approach is particularly useful when displaying dynamic content, such as user-generated data, that doesn’t require localization:

let dynamicText = "User's input text"
Text(dynamicText)

However, there are scenarios where you might need to localize a string stored in a variable. In such cases, you can explicitly convert your string into a LocalizedStringKey to ensure it is localized:

let greeting = "Hello"
Text(LocalizedStringKey(greeting))

Practical Example

Imagine a simple task list app that supports multiple languages. You want the static text to be localized, but the task descriptions, which are user input, should not be:

struct TaskListView: View {
    let tasks = ["Buy milk", "Schedule meeting", "Call mom"]
    
    var body: some View {
        List {
            Text("Tasks for today").fontWeight(.bold) // This will be localized
            ForEach(tasks, id: \.self) { task in
                Text(task) // Displays user input directly
            }
        }
    }
}

If your app supports German, for example, and your Localizable.strings file contains:

“Tasks for today” = “Aufgaben für heute”;

The header “Tasks for today” will appear as “Aufgaben für heute” to German users, enhancing the localized experience while keeping the task descriptions in the original language provided by the user.

Conclusion

LocalizedStringKey enhances SwiftUI’s text handling capabilities by providing a simple yet effective way to support multiple languages in your app. By distinguishing between when to use string literals and when to use string variables, you can control the localization behavior of your app, making it intuitive and accessible to a global audience. Embrace LocalizedStringKey in your SwiftUI projects to seamlessly integrate localization and improve user engagement worldwide.

The post Localizing Text in SwiftUI with LocalizedStringKey appeared first on AppMakers.Dev.

Understanding Keyboard Types in SwiftUI

SwiftUI allows developers to specify the keyboard type for text views, which tailors the keyboard layout to the expected content type, such as numbers, email addresses, or URLs. This is accomplished using the .keyboardType(_:) modifier, which accepts a parameter from the UIKeyboardType enumeration.

Example: Setting Up Various Text Fields with Specific Keyboard Types

Here’s a practical example demonstrating how to implement different keyboard types for a variety of text input needs in a SwiftUI view.

import SwiftUI

struct KeyboardTypeExampleView: View {
    @State private var emailAddress: String = ""
    @State private var phoneNumber: String = ""
    @State private var url: String = ""
    @State private var quantity: String = ""

    var body: some View {
        Form {
            Section(header: Text("Contact Information")) {
                TextField("Email Address", text: $emailAddress)
                    .keyboardType(.emailAddress)
                    .autocapitalization(.none)
                
                TextField("Phone Number", text: $phoneNumber)
                    .keyboardType(.phonePad)
            }
            
            Section(header: Text("Website")) {
                TextField("Enter URL", text: $url)
                    .keyboardType(.URL)
                    .autocapitalization(.none)
            }
            
            Section(header: Text("Order Quantity")) {
                TextField("Quantity", text: $quantity)
                    .keyboardType(.numberPad)
            }
        }
    }
}

Explanation of Keyboard Types Used

• Email Address: The .emailAddress keyboard is optimized for email entry, making it easier to access symbols commonly used in email addresses.
• Phone Number: The .phonePad keyboard displays a numeric keypad, ideal for entering phone numbers.
• URL: The .URL keyboard is tailored for URL entry, with convenience keys for symbols commonly used in web addresses.
• Quantity: The .numberPad keyboard presents a simple numeric pad, perfect for entering numeric values such as quantities.

Best Practices for Keyboard Types

1. Match the Keyboard to the Input Type: Always choose the keyboard layout that best matches the expected input to minimize user effort and potential input errors.
2. Disable Auto-Capitalization Where Necessary: For fields like email addresses and URLs, disable auto-capitalization to prevent the automatic capitalization of the first letter.
3. Use Appropriate Return Keys: You can also customize the return key on the keyboard to reflect the action the user will take, like “Search” or “Done”, which provides an additional clue about what happens next.

By carefully selecting the appropriate keyboard type for each text input field in your SwiftUI views, you can create a more streamlined, efficient, and user-friendly data entry experience.

The post Keyboard Types in SwiftUI appeared first on AppMakers.Dev.

Step 1: Setting Up the Environment

First, let’s set up our SwiftUI view with state variables to hold the username and password:

import SwiftUI

struct LoginFormView: View {
    @State private var username: String = ""
    @State private var password: String = ""
}

Step 2: Creating the User Interface

Next, we will add a TextField for the username input and a SecureField for the password input within a form. We’ll ensure that the text input does not auto-capitalize or auto-correct, which is common for login forms.

var body: some View {
        VStack {
           
            Text("Current username: \(username)")
            Text("Current password: \(password)")
            
            TextField("Username", text: $username)
                .autocorrectionDisabled(true)
                .textInputAutocapitalization(.never)
                .textFieldStyle(RoundedBorderTextFieldStyle())
                .padding()
            
            SecureField("Password", text: $password)
                .textFieldStyle(RoundedBorderTextFieldStyle())
                .padding()
        }
        .padding()
    }

In this snippet, TextField and SecureField are embedded in a VStack. The SecureField masks the input, showing dots instead of the actual characters typed by the user.

Step 3: Handling Submissions

To handle form submissions, let’s add an onSubmit modifier to SecureField. This will trigger when the user presses the Return key after entering their password. We’ll define a handleLogin method to process the login credentials.

  SecureField("Password", text: $password)
                .textFieldStyle(RoundedBorderTextFieldStyle())
                .padding()
                .onSubmit {
                    handleLogin()
                }

func handleLogin() {
    // Placeholder for login logic
    print("Login attempted with username: \(username) and password: \(password)")
}

This setup calls handleLogin when the form is submitted, allowing you to add whatever login logic your app requires.

Step 4: Enhancing User Guidance

Lastly, it’s often helpful to guide users with placeholder text. Here, we use the prompt as a placeholder to instruct users what to enter.

TextField("Username", text: $username, prompt: Text("Enter your username"))

SecureField("Password", text: $password, prompt: Text("Enter your password"))

Conclusion

SecureField is a critical component in SwiftUI for handling sensitive information securely. By pairing it with TextField for non-sensitive data, you can create forms that are both user-friendly and secure. This example demonstrates how to set up a basic login form, but you can expand upon this with additional security measures and UI enhancements as needed.

The post SecureField in SwiftUI appeared first on AppMakers.Dev.