Why You Should Read This:

This is not another “boring Singleton” article. This is the real-world guide to Singletons that production codebases actually need.

This is:
The real mistakes you are making right now in production code
Why your tests fail or require elaborate mocking gymnastics
The @MainActor confusion that’s causing crashes you can’t reproduce
Thread safety pitfalls that only show up under load
The architecture patterns that distinguish senior developers from everyone else

By the end, you will have a battle-tested, testable architecture that scales with your team and your app.

The Monster Singleton — A God Object

The Symptoms You are Already Experiencing:
- You dread opening a file: It has 1000+ lines of code.
- Everyone touches it: Merge conflicts every sprint
- Nothing can be tested in isolation: Your test suite is a mess.
- Changes cascade unpredictably: Fix one method, break five screens.
- Thread safety is a prayer — Sometimes it crashes, sometimes it doesn’t

What started as convenience evolved into a global state that became a monster or God Object.

Why This Singleton Is Untestable?

This class violates every principle of good design:
1. It mixes responsibilities — UI, networking, business logic, and caching all jammed together.
2. Exposed Mutable State — Anyone, anywhere can modify anything
3. Tight Coupling — Every feature directly depends on this global object
4. No Abstraction — Can’t swap implementations, can’t test parts independently
5. Thread Chaos — No isolation, no safety guarantees
6. Memory Hoarding — Global state means global memory consumption

The Core Insight That Changes Everything

We don’t fix monsters by fighting them.
We fix them by isolating them.

Tumb Rule: Never depend on .shared directly inside business logic. Depend on the protocols that the Singleton implements.

This single change transforms everything.

Before: Tight Coupling Hell

class CartViewModel {
    func loadCart() {
        let items = AppManager.shared.cartItems  // Locked to global state
        // Can't test without AppManager
        // Can't swap implementations
        // Can't run tests in parallel
    }
}

After: Protocol-Based Isolation

// Define what you need, not how it's implemented
protocol CartReadable {
    func items() async -> [CartItem]
}

protocol CartWritable {
    func add(_ item: CartItem) async
}

// Singleton implements the protocols
actor CartStore: CartReadable, CartWritable {
    static let shared = CartStore()
    private var cart: [CartItem] = []

    func items() async -> [CartItem] { cart }
    func add(_ item: CartItem) async { cart.append(item) }
}

Why this matters:

• Business logic depends on capabilities, not concrete types
• Tests can inject fake implementations without touching production code
• You can swap implementations without changing the calling code
• Dependencies are explicit and visible in initialisers

Dependency Injection — The Pattern That Makes Testing Possible

The Problem: Hidden Global Dependencies
When you write AppManager.shared.somethingYou've created an invisible dependency. The function signature doesn't show what it needs. Tests can't control it.

The Solution:

final class CartViewModel {
    private let store: CartReadable & CartWritable

    // Default to production, but allow injection for tests
    init(store: (CartReadable & CartWritable)? = = nil) {
        self.store = store ?? CartStore.shared
    }

    func loadCart() async -> [CartItem] {
        await store.items()
    }
}

Why the ? = nil Pattern in Swift 6?

This avoids the “Main actor-isolated property accessed from nonisolated context” error:

// Old pattern - causes Swift 6 errors
init(store: CartReadable & CartWritable = CartStore.shared) {
    // Default evaluated at call site = requires await everywhere!
}

// New pattern - Swift 6 compliant
init(store: (CartReadable & CartWritable)? = nil) {
    self.store = store ?? CartStore.shared
    // Default evaluated inside init = no await needed!
}

What changed:

• The dependency is visible in the initialiser
• Production code uses the default: CartViewModel() — no changes needed
• Test code injects a mock: CartViewModel(store: mockStore) — no await required!
• Swift 6 concurrency is fully supported

Your Test

// Mock implementation
final class MockCartStore: CartReadable, CartWritable {
    var data = [CartItem]()
    
    func items() async -> [CartItem] { data }
    func add(_ item: CartItem) async { data.append(item) }
}


func test_loading_cart() async {
    // Create a controlled fake
    let mock = MockCartStore()
    mock.data = [CartItem(id: 1), CartItem(id: 2)]

    // Inject it
    let vm = CartViewModel(store: mock)
    
    // Test in complete isolation
    let result = await vm.loadCart()

    XCTAssertEqual(result.count, 2)
}

Results:
No global state pollution
No .shared calls
No side effects between tests
Yes, Fast, reliable, parallel-safe tests

Thread Safety — Understanding Sendable and When Actors Matter

The Confusion: When Should a Singleton Be Sendable?
Short answer: Rarely, and only in specific cases.

Let’s break down the scenarios.

Mistake 1: Forcing Sendable on Class Singletons

final class Logger: Sendable {   // Compiler error incoming
    static let shared = Logger()
    private init() {}
    
    var logs: [String] = []  // Mutable state = not Sendable
}

Error: "Class 'Logger' does not conform to Sendable"

Why it fails:

Classes with mutable state are inherently unsafe to share across threads. No amount of annotation fixes this. The compiler is protecting you from data races.

The mistake: Trying to paper over thread safety with Sendable conformance.

Solution 1: Use an Actor for Mutable Shared State

actor Logger {
    static let shared = Logger()
    
    private var logs: [String] = []
    
    func log(_ message: String) {
        logs.append(message)  // Safe: actor provides isolation
    }
}

Why this works:

• Actors provide automatic isolation — only one task accesses the state at a time
• Actors are automatically Sendable — safe to pass between concurrency domains
• The compiler enforces safe access patterns at compile time

Solution 2: Immutable Singleton Structs

struct AppConfig: Sendable {
    let apiBaseURL: String
    let timeout: TimeInterval
    
    static let shared = AppConfig(
        apiBaseURL: "https://api.example.com",
        timeout: 30
    )
}

Why this works:

Immutable data is inherently thread-safe. No synchronisation needed because nothing changes.

The @MainActor Trap — When UI Safety Becomes a Performance Prison

What @MainActor Actually Does

It forces all access to happen on the main thread. This is:

• Perfect for UI states that UIKit/SwiftUI require on the main thread
• Disastrous for networking, caching, or heavy computation

The Mistake: @MainActor on Everything

@MainActor
final class ImageCache {
    static let shared = ImageCache()
    private var cache = [String: UIImage]()  // Blocks main thread
    
    func store(_ image: UIImage, for url: String) {
        // This now runs on main thread
        // Blocks your UI during large operations
        cache[url] = image
    }
}

What goes wrong:

• Image processing blocks UI updates
• Cache operations freeze scrolling
• Memory warnings trigger on the main thread, blocking user interaction
• Your app feels sluggish under load

The Fix: Use @MainActor Only for Actual UI State.

// CORRECT: UI state on main actor
@MainActor
final class UIState: ObservableObject {
    static let shared = UIState()
    @Published var isLoggedIn = false
    @Published var selectedTab: Tab = .home
}

// CORRECT: UI state on main actor for iOS 17+
@MainActor
@Observable
final class UIState {
    static let shared = UIState()

    var isLoggedIn = false
    var selectedTab: Tab = .home

    private init() {}
}

// CORRECT: Heavy work in isolated actor
actor ImageCache {
    static let shared = ImageCache()
    private var store = [String: Data]()  // Store Data, not UIImage
    
    func store(_ data: Data, for url: String) {
        store[url] = data
    }
}

The @MainActor Decision Guide

Use @MainActor for:

• @Published properties in ObservableObject
• UI state flags (login status, theme selection)
• Navigation state
• Anything directly bound to SwiftUI views

Never use @MainActor for:

• Network operations
• File I/O
• Image processing
• JSON parsing
• Database operations

Real-World Refactor — Turning Chaos Into Clean Architecture

The Starting Point: Your Current God-Singleton

final class AppManager {
    static let shared = AppManager()
    
    var user: User?
    var cachedImages = [String: UIImage]()
    
    func fetchProducts() async -> [Product] { /* networking */ }
    func calculateDiscount(cart: [Item]) -> Double { /* business logic */ }
    func loadHomeUI() { /* UI coordination */ }
    func trackEvent(_ name: String) { /* analytics */ }
}

This singleton does everything. That’s the problem.
The Refactored Architecture: Separated Concerns

1. UI State — Main Thread Safe

@MainActor
final class UIState: ObservableObject {
    static let shared = UIState()
    
    @Published var isLoggedIn = false
    @Published var currentUser: User?

    private init() {}
}

// For iOS 17+
@MainActor
@Observable
final class UIState {
    static let shared = UIState()

    var isLoggedIn = false
    var currentUser: User?

    private init() {}
}

Purpose: UI bindings only. Fast, main-thread-safe updates.

2. Networking — Protocol-Based for Testing

protocol ProductAPI {
    func fetchProducts() async throws -> [Product]
}

struct RealProductAPI: ProductAPI {
    func fetchProducts() async throws -> [Product] {
        // Real network call
        let url = URL(string: "https://api.example.com/products")!
        let (data, _) = try await URLSession.shared.data(from: url)
        return try JSONDecoder().decode([Product].self, from: data)
    }
}

// Test mock
struct MockProductAPI: ProductAPI {
    var productsToReturn: [Product] = []
    
    func fetchProducts() async throws -> [Product] {
        productsToReturn
    }
}

Purpose: Network operations. Mockable for tests.

3. Business Logic — Pure, Testable Functions

struct DiscountEngine {
    func calculate(cart: [Item]) -> Double {
        let subtotal = cart.reduce(0) { $0 + $1.price }
        let discount = subtotal > 100 ? subtotal * 0.1 : 0
        return subtotal - discount
    }
}

Purpose: Pure logic. No dependencies. Fast unit tests.

4. Caching — Actor-Isolated, Thread-Safe

actor ImageCache {
    static let shared = ImageCache()
    
    private var store = [String: Data]()
    private var maxBytes: Int = 50_000_000  // 50MB limit
    
    func store(_ data: Data, for url: String) {
        if currentSize() > maxBytes {
            evictOldest()
        }
        store[url] = data
    }
    
    func retrieve(for url: String) -> Data? {
        store[url]
    }
    
    private func currentSize() -> Int {
        store.values.reduce(0) { $0 + $1.count }
    }
    
    private func evictOldest() {
        // Implement LRU or similar
    }
}

Purpose: Safe caching without blocking UI.

5. Environment Coordinator — Thin Wiring Layer

@MainActor
final class AppEnvironment {
    static let shared = AppEnvironment()

    let ui = UIState.shared
    let productAPI: ProductAPI
    let discountEngine = DiscountEngine()
    let cache = ImageCache.shared

    init(productAPI: ProductAPI = RealProductAPI()) {
        self.productAPI = productAPI
    }
}

Purpose: Wire dependencies together. No logic, just composition.

What Changed:

Testing Every Layer

Testing Business Logic

func test_discount_calculation() {
    let engine = DiscountEngine()
    let cart = [
        Item(price: 50),
        Item(price: 60)
    ]
    
    let result = engine.calculate(cart: cart)
    
    XCTAssertEqual(result, 99.0)  // 110 - 11 (10% discount)
}

• No mocks. No setup. Pure function testing.

Testing ViewModels with Injected Dependencies

final class CartViewModel {
    private let cart: CartReadable
    private let discount: DiscountEngine

    init(cart: CartReadable = CartStore.shared, discount: DiscountEngine = DiscountEngine()) {
        self.cart = cart
        self.discount = discount
    }

    func total() async -> Double {
        let items = await cart.items()
        return discount.calculate(cart: items.map { $0.item })
    }
}

// Test
func test_total_calculation() async {
    let mockCart = MockCartStore()
    mockCart.data = [
        CartItem(item: Item(price: 10)),
        CartItem(item: Item(price: 20))
    ]

    let vm = CartViewModel(cart: mockCart)
    let total = await vm.total()

    XCTAssertEqual(total, 30)
}

Testing Actor Singletons

func test_image_cache_storage() async {
    let cache = ImageCache()  // Create instance for test
    let testData = Data([0x1, 0x2, 0x3])
    
    await cache.store(testData, for: "test-url")
    let retrieved = await cache.retrieve(for: "test-url")
    
    XCTAssertEqual(retrieved, testData)
}

• Isolated actors. No shared state between tests.

Testing UI State (Main Actor)

@MainActor
func test_login_state_change() async {
    let state = UIState()
    
    XCTAssertFalse(state.isLoggedIn)
    
    state.isLoggedIn = true
    
    XCTAssertTrue(state.isLoggedIn)
}

• Main actor tests stay on the main thread.

Complete Example — Shopping App Architecture

Want to see this in action? Check out the complete working implementation on GitHub: Swift-Singleton-Architecture-Example.
Clone it, run it, and see the patterns from this article in a real SwiftUI app!

Singletons aren’t the enemy. Bad architecture is.

The pattern itself is fine. What matters is:

1. What you put in it (thin coordination, not heavy logic)
2. How you access it (through protocols, not directly)
3. Where it lives (appropriate thread context)
4. How do you test it (dependency injection, not global state)

A well-designed Singleton becomes an invisible, reliable piece of infrastructure.

A poorly-designed one becomes technical debt that slows your entire team.

Choose and use wisely.

• Goal: Skip aims to blend into the background, offering an uncompromised iOS development experience as its Xcode plugin manages the Android version.
• Core Technology: At the core of Skip is an intelligent Swift to Kotlin transpiler, utilizing Apple’s SwiftSyntax library — the same used in Swift macros — to parse Swift source code.
• Output: The transpiler converts Swift code into clean, human-readable Kotlin, often indistinguishable from hand-written Kotlin, with even comments preserved.
• Special Handling: SwiftUI is transpiled into Compose, although some Swift compiler magic cannot be fully replicated in Kotlin.

Here’s how to do it:

Step 1: Install Skip Tools on macOS

Open the Terminal application and run the following command to install Skip tools on your machine:
brew install skiptools/skip/skip

Step 2: Register on the Website (Optional)

• Free Trial: Skip offers a 14-day free trial, which starts automatically upon installation.
• Evaluation License: As the trial period ends, Skip will prompt you to obtain a free evaluation license from this link.
• License Purchase: Before the evaluation period ends, Skip will remind you to purchase a license online. Visit the pricing page to select the appropriate license.
• Node-Locked License: Each license key is tied to a single machine, requiring the output of the skip hostid command.
• Registration: To get started, register on the Skip website by visiting this link and selecting a plan. You’ll need to enter your name, email address, and optionally, your organization name. Additionally, you must provide a host identifier, which can be obtained by running the following command in the Terminal:
  skip hostid
  After agreeing to the terms, you will receive your license key via the registered email address.

Step 3: Set Up the License Key

To set up the license key in your macOS environment, create a file in the Skiptools directory if it doesn’t already exist:

touch ~/.skiptools/skipkey.env

Next, open the file and add the license key you received via email:

open -a TextEdit ~/.skiptools/skipkey.env

Step 4: To check system requirements

write the next command on a terminal to check prerequisite systems
skip doctor

Step 5: To Perform system Full evaluation

write the next command on a terminal to system full evaluation
skip checkup

Project Setup

Now that Skip is installed and registered, you can start building a new project using Skip.

To create a new dual-platform app project, run the following command:
skip init --appid=bundle.id project-name AppName

Note:
The skip init the command creates a functional template app, but before you can build and launch it, an Android emulator must be running. Open Android Studio, go to the Virtual Device Manager from the ellipsis menu in the Welcome dialogue and create a device. Then, launch the emulator.

For example, let’s create a project using the following command:

skip init --appid=com.amp.swiftskip Swift-Skip SwiftSkip

• Project Name: Swift-Skip
• Application Name: SwiftSkip
• Directory Structure: Running the command will create a Swift-Skip/ folder.
• SwiftPM Package: Inside the folder, you’ll find a new SwiftPM package containing a single module named SwiftSkip.
• Platform-Specific Folders: The folder will include both Darwin and Android directories.
• Configuration File: A shared Skip.env app configuration file will be generated.
• Darwin Folder: Within the Darwin folder, there will be a SwiftSkip.xcodeproj project with a SwiftSkip target, which can be opened in Xcode.

You can also open the project in Xcode immediately by using:

skip init --open-xcode --appid=com.amp.swiftskip Swift-Skip SwiftSkip

Conclusion

With Skip, you’ve streamlined the process of building dual-platform apps, starting from installation to project setup. By using a simple command, you create a robust project structure with everything you need to develop for both iOS and Android seamlessly. From the initial setup to launching your app in Xcode and Android Studio, Skip handles the heavy lifting, allowing you to focus on what you do best — coding.

Whoo-hoo! You’re all set to dive into your project. Happy coding! 🎉

If you found this guide helpful, please follow and clap! 👏

What are watchpoints?
Watchpoints are breakpoints that pause your program when the value of a specific variable changes. They are useful for finding out which part of your code changes the variable’s value, helping you track down and fix bugs more effectively.

How do I set watchpoints?

Step-by-Step Debugging with Watchpoints

1. Set a Breakpoint: Set a breakpoint at the line let calculator = Calculator() to pause the execution before the total a variable is modified.
2. Run and Pause: Run the application. Execution will pause at the breakpoint.
3. Set a Watchpoint: Locate the total variable under the calculator object in the debug area. Right-click on total and select “Watch.”
4. Continue Execution: Continue running the application by clicking the Continue button or pressing Cmd + Ctrl + Y. The application will run until the total variable is modified.
5. Observe Watchpoint Trigger: When the total a variable is incremented or decremented, Xcode will pause execution, allowing you to inspect the state of your application at that point.

Manually set watchpoints in LLDB

• Set a breakpoint where the variable is in scope.
• When the execution pauses at the breakpoint, open the LLDB console (bottom of the debug area).
• Enter the following command:
  watchpoint set variable calculator.total or
  w s v calculator.total
• Continue running the application. The execution should pause when total changes are made.

Final Output

Note: Watchpoints need to be set each time you launch your app, as they are not persistent like breakpoints

Conclusion

Watchpoints are a powerful tool in Xcode for tracking down bugs related to variable modifications. By setting watchpoints, you can pause the execution of your program exactly when a variable’s value changes, providing valuable insights into your application’s behaviour.

In this blog post, we’ve covered the basics of watchpoints and how to set them up in Xcode. We also walked through a simple example to demonstrate their use. By incorporating watchpoints into your debugging toolkit, you can streamline the process of identifying and fixing bugs, ultimately leading to more robust and reliable code.

Merge conflicts in Xcode .pbxproj files can be a headache for developers, often leading to frustration and wasted time. Resolving these conflicts in Xcode after merging code changes can sometimes feel like hitting a wall. However, navigating through .pbxproj merge information can be a smooth process if you have the right technique and knowledge.

In this blog post, we will explore developers' most common challenges when resolving .pbxproj conflicts and provide practical ways to overcome them.

Join us as we fix complex .pbxproj decisions in Xcode, turning what once seemed like an unmanageable task into a manageable effort. Let’s get in and make your development work better today!

Step 1: Install a homebrew, If you have not found it in your machine.

Step 2: Install a kin library usingbrew install kin

Step 3: Go to your project folder in the terminal and type kin
Using Kin from your Xcode project directory. Kin will automatically detect where your project configuration is located and check whether it is correct.

ERROR: line 7166:2 mismatched input 'B2AE182B871767008BAE99' expecting 'sourceTree'

ERROR: line 400:3 mismatched input ')' expecting 'inputPaths'

Now you can go to your favourite editor and update the error detected by the Kin.

Time saver information & Happy Coding !!

Introduction:

In the dynamic world of iOS development, creating a live preview screen is a valuable skill that enables developers to showcase their app’s interface in real-time. This blog will guide you through the process of creating a live preview screen using UIViewController and UIView with programmatically applied constraints, allowing for a responsive and visually engaging user interface.

UIViewController Preview Extension

import SwiftUI

extension UIViewController {
    
    private struct ControllerPreview: UIViewControllerRepresentable {
        let viewcontroller: UIViewController
        
        func makeUIViewController(context: Context) -> some UIViewController {
            return viewcontroller
        }
        
        func updateUIViewController(_ uiViewController: UIViewControllerType, context: Context) {
            
        }
        
    }
    
    func showLivePreview() -> some View {
        ControllerPreview(viewcontroller: self)
    }
    
}

UIView Preview Extension

import SwiftUI

extension UIView {
    private struct ViewPreview: UIViewRepresentable {
        typealias UIViewType = UIView
        let view: UIView
        func makeUIView(context: Context) -> UIView {
            return view
        }
        
        func updateUIView(_ uiView: UIView, context: Context) {
            
        }
    }
    
    func showLivePreview() -> some View {
        ViewPreview(view: self)
    }
}

Indeed, it’s incredibly useful; you can now check live previews of UIKit by simply adding a small chunk of code.

import SwiftUI

/// UIViewController
 
#Preview {
    UIViewController().showLivePreview()
}

/// UIView

#Preview {
    UIView().showLivePreview()
}

“You can utilize the provided code for each class and display a live preview side by side. In the live preview, you can apply constraints programmatically.

Usage Example: For instance, if you create a LoginViewController class:

LoginViewController().showLivePreview()

Similarly, if you create a BannerView class:

BannerView().showLivePreview()

It’s worth noting that programmatically managing constraints becomes significantly easier in such cases. Moreover, I recommend utilizing the SnapKit library for straightforward constraint handling.

I have shared the code for the demonstrated GIF on GitHub, allowing you to download and understand it.

Happy Coding :) :)

Introduction:

The SwiftUI and Swift Combine frameworks have revolutionized the way developers build robust and responsive iOS applications. Combine, introduced by Apple, is a powerful framework that brings reactive programming to Swift, allowing developers to handle asynchronous events more elegantly and concisely. In this blog, we will delve deep into the Combine Framework step-by-step.

Before delving into Combine, let’s first grasp the concept of reactive programming.

Reactive Programming: Reactive programming is a programming paradigm focused on handling asynchronous data streams and responding to changes in a declarative manner. In the context of a real-life example with the human body, reactive programming can be compared to the body’s automatic response when touching a hot bike silencer.

• Asynchronous Responses: When accidentally touching a hot bike silencer, the body reacts immediately by retracting the hand to avoid injury.
• Declarative Nature: The response is automatic and instinctive, involving neural pathways and reflexes that prioritize self-preservation.

In this scenario, the human body’s rapid and instinctive reaction to the hot bike silencer mirrors the principles of reactive programming, where responses to events happen without explicit, conscious commands.

Key Concepts of Combine Framework

We’ll explore the core concepts of Combine: publishers, subscribers, operators, and subjects. For each concept, we’ll provide examples with a human analogy.

1. Publishers: The Warning Signal

At the heart of Combine lies the concept of publishers. Publishers are entities that emit a sequence of values over time. They serve as the source of truth in a reactive data flow. Combine provides a variety of built-in publishers, and developers can create custom publishers to represent different data sources.

Example:
Publishers are akin to the nervous system’s receptors in our body. Just as the skin’s nerve endings detect heat, publishers emit signals or values over time. In our scenario, the hot bike silencer serves as the source of the stimulus, triggering a warning.

import Combine

let publisher = Just("Hot Surface Warning!")

In this example, 'Just' publisher emits a single value and warning message, simulating the body’s detection of a hot surface.

2. Subscribers: Immediate Reaction

Subscribers receive and react to the values emitted by publishers. They define what to do with the received values, handle errors, and respond to completion events. Subscribers subscribe to publishers, establishing a connection that allows them to react in real time to changes in the data stream.

Example:
Subscribers are comparable to the body’s reflexes — immediate responses to a stimulus. They receive and react to the emitted values. In our analogy, the body’s reflexes represent the subscribers.

let cancellable = publisher.sink { warningMessage in
    print("Reacting to Warning: \(warningMessage)")
}

In this example, 'Sink' attaches a subscriber to the publisher, warning message emitted by the publisher.

3. Operators: Adaptive Responses

Combine provides a rich set of operators for transforming, filtering, and combining values emitted by publishers. These operators allow developers to manipulate data flows in a declarative and concise manner. Operators chain together, enabling the creation of complex data transformations.

Example:
Operators are like the body’s adaptive mechanisms, allowing for transformations of the emitted values. In this context, they represent how the body adjusts its reaction based on the severity of the stimulus — a form of adaptation.

let adaptedPublisher = publisher
    .map { $0.lowercased() }
    .filter { !$0.contains("warning") }

In this example, the 'map' and 'filter' operators adapt the warning message, showcasing how modify data flows.

4. Subjects: Communication Hub

Subjects act as both publishers and subscribers, providing a bridge between imperative and reactive code. They allow for the injection of values into a Combine pipeline. There are various types of subjects, such as PassthroughSubject and CurrentValueSubject.

Example:
Subjects act as a communication hub, both emitting and receiving values. In our analogy, the nervous system serves as a subject, transmitting signals between different parts of the body.

import Combine

let subject = PassthroughSubject<String, Never>()

let cancellable = subject
    .sink { value in
        print("Received Signal: \(value)")
    }

subject.send("Caution: Hot Surface!")

In this example, 'PassthroughSubject' imitates the body’s communication system, receiving and transmitting caution signals.

Now that we comprehend the type of publisher and subscription, the subsequent section will be arriving shortly.

In my previous article, I talked about the basics of Swift catalogs—why they matter, adding files to projects, and the basics of using them. This time, we’re going practical. We’ll cover everything you need to know about Swift catalogs. I’ll present the information using a question-and-answer format for better clarity and understanding.

Question: Could you guide me through using localized strings in SwiftUI?
Answer: Sure, in SwiftUI, incorporating localized strings involves using the Text view alongsideLocalizedStringKey. When defining text within a Text view, you utilize LocalizedStringKey it to reference the localized string from your String Catalog.

import SwiftUI

struct ContentView: View {
    var body: some View {
        VStack {
            Spacer()
            Text("Localized")
            Text("Welcome to the app")
            Spacer()
            Text("Not Localized")
            Text(verbatim: "Welcome to the app")
            Spacer()
            Text("Not Localized")
            Text(String("Welcome to the app"))
            Spacer()
        }
        .padding()
        .border(.black)
    }
}

#Preview {
    ContentView()
}


#Preview {
    ContentView().environment(\.locale, .init(identifier: "fr"))
}

Output

While your code seems correct and I understand the concept of localized strings, it appears that the output doesn’t reflect the localization of the same string.

Question: Why doesn’t SwiftUI localize strings using the verbatim or String() approach?
Answer: This occurs because SwiftUI’s Text view treats its argument as a localizable type, such as LocalizedStringKey."

extension Text {
  public init(_ key: LocalizedStringKey, 
                tableName: String? = nil, 
                bundle: Bundle? = nil, 
                comment: StaticString? = nil)
}

Question: How do I use plurals and dynamic strings in the String Catalog?
Answer: I’ll illustrate both concepts using one example.

I’ll demonstrate how to form sentences in the plural.

Observing the image below, you can now see the resemblance.

Notice how the state requires review because I’ve reviewed all strings except for the single-item string.

Observe the state: all remain ‘new’ because I haven’t translated any strings into French yet.

Utilizing all string catalog strings within SwiftUI code for better understanding.

import SwiftUI

struct ContentView: View {
    @State var dynamicText: String = ""
    var body: some View {
        VStack {
            Spacer()
            Text("Dynamic Text")
                .bold()
            TextField("What do you want to play?", text: $dynamicText)
                .padding()
                .overlay (
                    RoundedRectangle(cornerRadius: 14)
                               .stroke(Color.green, lineWidth: 2)
                )
            Text("I want to play \(dynamicText)")
            Spacer()
            Text("Plural Text")
                .bold()
            Text("You have \(0) pizza slices.")
            Text("You have \(1) pizza slices.")
            Text("You have \(2) pizza slices.")
            Spacer()
        }
        .padding()
        .frame(maxWidth: .infinity, maxHeight: .infinity)
    }
}

Question: Explain ‘Vary by device’.
Answer: “Vary by device” refers to the ability to adjust the display or behavior of your interface elements based on the characteristics of the device running the app. This feature allows you to adapt your app’s user interface according to different devices, such as iPhones, iPads, or Macs, ensuring a more optimized and tailored experience for each device.

I’ll illustrate with an example

Swift Catalog serves as a comprehensive tool within SwiftUI, offering a practical and versatile approach for managing strings and accommodating various device types. Through the provided examples, it becomes evident how this functionality streamlines the localization process and facilitates dynamic content presentation across different Apple devices. Embracing the Swift Catalog empowers developers to create more adaptable and user-friendly applications in SwiftUI, optimizing the user experience across diverse platforms effortlessly.

In software development, managing and presenting strings efficiently within an application is crucial for internationalization and localization. In Swift, a powerful programming language developed by Apple, the String Catalog is a valuable tool used to streamline the process of handling strings for multiple languages. Let’s delve into the world of string catalogs in Swift.

Understanding String Catalogs

String catalogs, introduced in Xcode 15 onwards, are essentially collections of localized string resources. They allow developers to manage strings separately from the main codebase, making it easier to support multiple languages without cluttering the code.

Benefits of String Catalogs

• Localization: String catalogs facilitate the process of translating and adapting an application to different languages and regions.
• Centralized Management: Developers can maintain all strings in one place, making it simpler to update and manage translations.
• Clearer Code: Using String Catalogs helps declutter the codebase by separating strings from the main code, improving readability and maintenance.

Creating a String Catalog

Let’s explore how to create and utilize a string catalog in a Swift project:

Step 1: Create a New String Catalog File

1. Open Xcode and navigate to the project navigator.
2. Right-click on the project folder or use the “File” menu.
3. Choose “New File” and select “String Catalog” from the template list.

Name the file appropriately, likeLocalizable.xcstrings

Step 2: Add Localized Strings

• Inside the newly createdLocalizable.xcstrings file,
• Open theLocalizable.xcstrings file from the left navigator in Xcode; you’ll now see the following screen.

• If you want to add language support for a multi-language application, you’ll notice that English is set as the default base language. Click on the plus sign within the same language window. You’ll now see the following screen:

• Now, add the appropriate language that you want to support for your application. You’ll now see the following screen:

• Add strings to be displayed on a screen, then utilize a third-party translation tool to update these strings. Once updated, you’ll notice a green indicator signifying the changes.
• Xcode monitors your translation progress, displaying the percentage of translated strings next to each language. This feature helps maintain focus on the task at hand by presenting a comprehensive view of entries that have been successfully translated, indicated by a green checkmark.

Xcode categorizes entries based on their status, each denoting a specific meaning.

• STALE: Indicates a string that’s no longer utilized in the code, likely deleted recently.
• NEW: This represents a fresh entry requiring translations to be added.
• NEEDS REVIEW: Allows marking entries for further review and consideration.
• Green Checkmark: This signifies that the entry has been translated.

Best Practices and Tips

• Use Descriptive Keys: Employ keys that are descriptive and easily recognizable to avoid confusion while managing multiple strings.
• Test Localization: Always test the app with different language settings to ensure that all strings are properly localized.
• Update String Catalogs Regularly: Keep the String Catalog updated with new strings and translations as the app evolves.

Conclusion

String catalogs in Swift are a powerful tool for managing and localizing strings in applications. They simplify the process of adapting an app to different languages, enabling developers to provide a more inclusive and accessible user experience. By using string catalogs efficiently, developers can create applications that resonate with a global audience, breaking language barriers and expanding their reach.

For a better understanding of string catalog and how to use it in SwiftUI with practicality, click on it