· 1. Create a Wrapper Module for the SDK (e.g. Firebase)
· 2. Wrap SDK Logic and Use Protocols
· 3. Other Modules Import Only the Wrapper
· Benefits of This Pattern

When building a multi-module iOS app using Swift Package Manager, importing third-party libraries like Firebase directly into multiple feature modules quickly becomes messy. It leads to duplicated configurations, tight coupling, and hard-to-maintain code.

The best practice is to create a wrapper module (e.g. FirebaseModule) that imports and manages all Firebase logic in one place. Then, other modules like LoginModule, Data, etc., only depend on this wrapper — they never import the third-party library directly.

1. Create a Wrapper Module for the SDK (e.g. Firebase)

Modules/FirebaseModule/Package.swift:

// Only in the wrapper module
.package(url: "<https://github.com/firebase/firebase-ios-sdk.git>", branch: "main"),

.target(
  name: "FirebaseModule",
  dependencies: [
    .product(name: "FirebaseAuth", package: "firebase-ios-sdk"),
    .product(name: "FirebaseFirestore", package: "firebase-ios-sdk"),
    .product(name: "FirebaseStorage", package: "firebase-ios-sdk")
  ]
)

2. Wrap SDK Logic and Use Protocols

CommonModule/AuthService.swift:

public protocol AuthService {
    func login(email: String, password: String) -> AnyPublisher<User, Error>
}

FirebaseModule/FirebaseAuthService.swift:

import FirebaseAuth
import Combine

public class FirebaseAuthService: AuthService {
 public init() {}
 func login(email: String, password: String) -> AnyPublisher<Void, Error> {
       Future { promise in
           Auth.auth().signIn(withEmail: email, password: password) { result, error in
               if let error = error {
                   promise(.failure(error))
               } else {
                   promise(.success(()))
               }
           }
       }.eraseToAnyPublisher()
   }
}

3. Other Modules Import Only the Wrapper

Modules/Data/Package.swift:

.package(path: "../FirebaseModule")

.target(
  name: "Data",
  dependencies: ["FirebaseModule", "CommonModule", ...]
)

In your Swift code:

import FirebaseModule

let authService: AuthService = FirebaseAuthService()

Benefits of This Pattern

• Clean separation of concerns
• No direct Firebase SDK imports in features
• Easier unit testing via protocols
• Centralized SDK configuration
• Avoids duplication and compile issues

This practice applies to any third-party SDK (Firebase, Alamofire, Realm, GRDB, etc.). Keep them wrapped in a dedicated module, expose interfaces via protocols, and let your app scale cleanly.

Thanks for Reading! ✌️

If you have any questions or corrections, please leave a comment below or contact me via my LinkedIn account Pham Trung Huy.

Happy coding 🍻

Best Practices for Managing Third-Party Libraries in Multi-Module iOS Apps was originally published in Towards Dev on Medium, where people are continuing the conversation by highlighting and responding to this story.

Table of contents

· Task Tree
· Task Cancellation

Task Tree

Let’s take a look at the code below

As you can see, the function printStudentInfo() has 2 child Tasks defined using async let. Inside the child Task getClassesAndScores(), it also has 2 child Tasks getClasses() and getScores() . So we have a Task tree with 3 levels here:

Although there are 5 Tasks in the parent-child relationship here, they all run simultaneously. Because the Tasks have parent-child relationships, they call this approach Structured Concurrency.

The explicit parent-child relationships between tasks have several advantages:

1. The parent task is complete when all of its child tasks are complete.

2. When setting a higher priority on a child task, the parent task’s priority is automatically escalated.

3. When a parent task is canceled, each of its child tasks is also automatically canceled.

4. When a child task throws an error, the error propagates to the parent task.

Task Cancellation

What happens to other tasks when a Task is canceled?

If a Task is canceled, the cancellation state cascades down from the parent to all its children. This is called cooperative cancellation. Tasks continue their work when canceled and don’t return anything. So it’s important that we should stop running canceled Tasks, we can check this canceled state in our code and terminate processing.

There are two ways a task can do this:

1. by calling the Task.checkCancellation() type method

Calling Task.checkCancellation() throws an error if the task is canceled, a throwing task can propagate the error out of the task, stopping all of the task’s work. This has the advantage of being simple to implement and understand

2. reading the Task.isCancelled type property

For more flexibility, use the Task.isCancelled property, which lets you perform clean-up work as part of stopping the task, like closing network connections and deleting temporary files.

Thanks for Reading! ✌️

If you have any questions or corrections, please leave a comment below or contact me via my LinkedIn account Pham Trung Huy.

Happy coding 🍻

When working with arrays in Swift, you might have come across a common error called “Fatal error: Index out of range”. This error typically occurs when you unintentionally try to access an index that is not present in the array. Actually, accessing elements from an array is not safe by default. Therefore, today we’re going to explore how to code more securely when accessing elements in an array. 😊

Let’s look at an example:

let shoppingList = ["apples", "raspberries"]
let item = shoppingList[2]

Accessing an element this way will crash the app if the element isn’t there.

We’ll define an extension on the Collection type that adds a “safe” subscript. This subscript returns an optional value, which will be nil if the index is out of bounds.

extension Collection {

    /// Returns the element at the specified index if it exists, otherwise nil.
    subscript (safe index: Index) -> Element? {
        return indices.contains(index) ? self[index] : nil
    }
}

By using “if let” statement to unwrap the optional value, we can safely access the array item without worrying about out-of-bounds errors

if let item = shoppingList[safe: 2] {
    // use item
}

Thanks for Reading! ✌️

If you have any questions or corrections, please leave a comment below or contact me via my LinkedIn account Pham Trung Huy.

Happy coding 🍻

Table of contents

· What is a scheduler
· Types of schedulers in Combine
· DispatchQueue
· OperationQueue
· ImmediateScheduler
· Default Scheduler
· Switching Schedulers
· receive(on:)
· subscribe(on:)
· Performing asynchronous tasks with schedulers
· Summary

What is a scheduler

According to the scheduler documentation, a scheduler is “a protocol that defines when and where to execute a closure.” You can use a scheduler to execute code as soon as possible, or after a future date

Combine does not work directly with threads. Instead, it allows Publishers to operate on specific Schedulers.

The where means current run loop, dispatch queue or operation queue.

The when means virtual time, according to the scheduler’s clock. The work performed by a scheduler will adhere to the scheduler’s clock only, which might not correspond to the real-time of the system.

Types of Schedulers in Combine

Combine provides several types of schedulers, all of which conform to the Scheduler protocol:

DispatchQueue

a DispatchQueue is a first-in-first-out queue that can accept tasks in the form of block objects and execute them serially or concurrently. You’ll commonly use serial or global queues for the background work, and the main queue for the UI-related work

The system manages work submitted to a DispatchQueue on a pool of threads. The DispatchQueue doesn’t guarantee which thread it will use for executing tasks unless the DispatchQueue represents an app’s main thread

DispatchQueue is one of the safest ways to schedule commands

OperationQueue

Performs the work on a specific operation queue. Similarly to the dispatch queues, use OperationQueue.main for UI work, and other queues for the background work.

ImmediateScheduler

An IntermediateScheduler is used to perform asynchronous operations immediately. This means that commands will be immediately executed on the application’s current threads

import Combine
import Foundation

let immediateScheduler = ImmediateScheduler.shared
let aNum = [1, 2, 3].publisher
    .receive(on: immediateScheduler)
    .sink(receiveValue: {
        print("Received \($0) on thread \(Thread.current)")
    }
)

The code snippet above is running on the main thread, so the result will be also received in the main thread

Received 1 on thread <_NSMainThread: 0x600001704040>{number = 1, name = main}
Received 2 on thread <_NSMainThread: 0x600001704040>{number = 1, name = main}
Received 3 on thread <_NSMainThread: 0x600001704040>{number = 1, name = main}

Default Scheduler

💡 Even if you don’t specify any scheduler, Combine provides you with the default one. The scheduler uses the same thread, where the task is performed. For example, if you perform a background task, Combine provides a scheduler that receives the task on the same background thread

let subject = PassthroughSubject<Int, Never>()
// 1
let token = subject.sink(receiveValue: { value in
    print(Thread.isMainThread)
})
// 2
subject.send(1)
// 3
DispatchQueue.global().async {
    subject.send(2)
}

1. Print true if the value is received on the main thread, and false otherwise.
2. Send 1 from the main thread.
3. Send 2 from the background thread.

It will print:

true

false

As expected, the values are received on different threads.

Switching Schedulers

In order not to freeze or crash when interacting with the user interface, the resource-consuming tasks should be done in the background and then handle their result on the main thread. The Combine’s way of doing this is by switching schedulers with two methods: subscribe(on:) and receive(on:)

receive(on:)

The receive(on:) method changes a scheduler for all publisher that comes after it is declared

Just(1)
   .map { _ in print(Thread.isMainThread) }
   .receive(on: DispatchQueue.global())
   .map { print(Thread.isMainThread) }
   .sink { print(Thread.isMainThread) }

it will print:

true
false
false

The process is visualized as follows:

All operators to the right of receive(on:) deliver elements on DispatchQueue.global() scheduler.

subscribe(on:)

subscribe(on:) sets where subscription work happens. It stays there unless receive(on:) changes it. Think of it as assigning work locations.

Just(1)
   .subscribe(on: DispatchQueue.global())
   .map { _ in print(Thread.isMainThread) }
   .sink { print(Thread.isMainThread) }

It will print:

false

false

Let’s visualize the process:

All the operations happen on the DispatchQueue.global()scheduler

The position of subscribe(on:) doesn’t matter, as it affects the time of subscription. This snippet is equivalent to the previous one:

Just(1) 
   .map { _ in print(Thread.isMainThread) }
   .subscribe(on: DispatchQueue.global()) // Position of subscribe(on:) has changed
   .sink { print(Thread.isMainThread) }

💡 You must notice that the definition of subscribe(on:) says nothing about the scheduler on which we receive values. In case a publisher emits values on a different thread, it will be received on that thread. A typical example is a data task publisher:

URLSession.shared.dataTaskPublisher(for: URL(string: "<https://www.vadimbulavin.com>")!)
   .subscribe(on: DispatchQueue.main) // Subscribe on the main thread
   .sink(receiveCompletion: { _ in },
         receiveValue: { _ in
           print(Thread.isMainThread) // Are we on the main thread?
   })

The code will print false because the publisher emits values on a background thread. In such cases, we must use receive(on:) to specify a scheduler

Performing asynchronous tasks with schedulers

Let’s see how we can switch schedulers by combining subscribe(on:) and receive(on:)

Assume that we have a publisher with a long-running task:

struct BusyPublisher: Publisher {
    typealias Output = Int
    typealias Failure = Never
    
    func receive<S>(subscriber: S) where S : Subscriber, Failure == S.Failure, Output == S.Input {
        sleep(5)
        subscriber.receive(subscription: Subscriptions.empty)
        _ = subscriber.receive(1)
        subscriber.receive(completion: .finished)
    }
}

When call from the UI thread, it freezes the app for 10 seconds. Remember, Combine defaults to the same scheduler from where the element is fired:

BusyPublisher()
  .sink { _ in
    print("Received value") 
  }
print("Hello")

As expected, Hello is printed after the value is received:

Received value
Hello

💡 So the solution for doing asynchronous work with Combine is subscribing on the background scheduler and then receiving the events on the UI Scheduler:

BusyPublisher()
   .subscribe(on: DispatchQueue.global())
   .receive(on: DispatchQueue.main)
   .sink { _ in print("Received value") }
print("Hello")

As expected, Hello is printed before the value is received, this means that the application is not frozen by the publisher blocking the main thread.

Hello
Received value

Summary

Let’s recap the main takeaways.

• subscribe(on:) and receive(on:) are primary multithreading methods of the Combine Swift framework.
• The default scheduler uses the same thread from where the element was generated.
• receive(on:) sets a scheduler for all operators coming afterward.
• subscribe(on:) sets a scheduler for the whole stream, starting at the time the Publisher is subscribed to. The stream stays on the same scheduler until receive(on:) specifies another scheduler.
• The position of subscribe(on:) does not matter.
• Asynchronous work is typically performed by subscribing on the background scheduler and receiving values on the UI scheduler.

Thanks for Reading! ✌️

If you have any questions or corrections, please leave a comment below or contact me via my LinkedIn account Pham Trung Huy.

Happy coding 🍻

Scheduler in Combine: Managing Asynchronous Tasks Efficiently was originally published in Towards Dev on Medium, where people are continuing the conversation by highlighting and responding to this story.

Table of contents

· Errors types in Combine
· mapError
· retry
· catch
· replaceError
· Conclusion

Handling errors properly is essential for creating a robust and reliable application. Error handling in reactive programming is comparatively more complex than its imperative counterpart. But when using Combine, you’re equipped with handy operators that can help you handle the errors properly.

This article assumes you have the basic knowledge about Combine including Publisher, Subscriber,…. You can also check my series about Combine here

Errors types in Combine

Before we learn about handling errors strategies, it’s crucial to understand different types of errors that can occur when you use Combine

• Publisher errors: These errors occur when a publisher fails to produce a value due to an internal error, such as a network failure or a runtime error.
• Operator errors: These errors occur when an operator in the pipeline fails to process a value due to an error condition, such as an invalid argument or a runtime error.
• Subscription errors: These errors occur when a subscriber fails to receive values due to an error condition, such as a canceled subscription or a runtime error.

mapError

mapError operator is used for mapping an error to the expected error type

import Combine
enum MyError: Error {
    case testError
}
enum MappedError: Error {
    case transformedError
}
let publisher = PassthroughSubject<Int, MyError>()
let cancellable = publisher
    .mapError { _ in MappedError.transformedError }
    .sink(receiveCompletion: { completion in
        switch completion {
        case .finished:
            print("Publisher completed successfully.")
        case .failure(let error):
            print("Publisher completed with error: \(error)")
        }
    }, receiveValue: { value in
        print("Received value: \(value)")
    })
publisher.send(1)
publisher.send(completion: .failure(.testError))
//Outputs
//Received value: 1
//Publisher completed with error: transformedError

retry

Another common strategy for handling errors in Combine is to use the retry operator. You might want to use the retry operator before accepting an error when working with data requests.

enum MyError: Error {
    case unknown
}

let url = URL(string: "<https://example.comm>")!
let cancellable = URLSession.shared.dataTaskPublisher(for: url)
    .mapError { error -> Error in
        if let urlError = error as? URLError, urlError.code == .networkConnectionLost {
            return urlError
        } else {
            return MyError.unknown
        }
    }
    .retry(3)
    .sink(receiveCompletion: { completion in
        switch completion {
        case .finished:
            print("Request completed successfully.")
        case .failure(let error):
            print("Request failed with error: \(error)")
        }
    }, receiveValue: { value in
        print("Received value: \(value)")
    })

However, The retry operator in Combine does not have the same functionality as the retry(when:) operator in RxSwift. In Combine, the retry operator simply resubscribes to the upstream publisher when an error occurs, up to a specified number of times. It does not provide a mechanism to conditionally decide whether to retry based on the error that occurred.

catch

One of the most common strategies for handling errors in Combine is to use the catch operator. The catch operator allows you to handle errors and recover from failures in a reactive pipeline.

let publisher = URLSession.shared.dataTaskPublisher(for: url)
    .map(\.data)
    .catch { error -> Just<Data> in
        print("Error: \(error)")
        return Just(Data()) // return a default value if an error occurs
    }

For example, if you have a publisher that retrieves data from the server, you can use catch operator to catch any errors and recover by returning a default value or retrying the request

replaceError

replaceError seems quite the same as the catch operator. The difference is that replaceError completely ignores the error and still returns a recovering value.

In the above example, we’re doing nothing than returning the placeholder image in case of an error.

URLSession.shared
    .dataTaskPublisher(for: URL(string: "<https://mydomain/image_654>")!)
    .map { result -> UIImage in
        return UIImage(data: result.data) ?? UIImage(named: "placeholder-image")!
    }
    .replaceError(with: UIImage(named: "placeholder-image")!)
    .sink(receiveCompletion: { print("received completion: \($0)") }, receiveValue: {print("received auth: \($0)")})

Conclusion

Recognizing the importance of handling both happy and unhappy scenarios, it’s vital to discuss error management strategies in Combine. Also, you can check out the code snippet featured in this article via My Playground 🙌

Thanks for Reading! ✌️

If you have any questions or corrections, please leave a comment below or contact me via my LinkedIn account Pham Trung Huy.

Happy coding 🍻

Table of contents

· How to create Subscriber
· Assign
· Sink
· Custom Subscriber
· AnyCancellable and memory management
· Conclusion
· References:

It’s time to review a little:

Subscribers will receive values from Publisher, all subscribers must inherit the Subscriber protocol.

public protocol Subscriber {
  associatedtype Input
  associatedtype Failure: Error
  func receive(subscription: Subscription)
  func receive(_ input: Self.Input) -> Subscribers.Demand
  func receive(completion: Subscribers.Completion<Self.Failure>)
}

• Input: Type of data provided, it has to be matched the Output of Publisher
• Failure: Type of data for error

3 important methods:

• receive(subscription:) when receiving subscription from Publisher
• receive(input:) when receiving value from Publisher and we will adjust the request for further data through Demand.
• receive( completion:) when receiving completion from the publisher.

You can subscribe to a Subscriber by using subscribe of Publisher (if you haven’t read my article about Publisher in Combine yet, you can check this link)

publisher.subscribe(subscriber)

An important note that only when a subscriber connects does the publisher emit data

Subscriber has the ability to self-destruction when subscription is disconnected. That cancellation helps memory automatically release unnecessary objects. We have 2 types of cancellation:

• Auto cancel by AnyCancellable when we create subscribers by sink or assign
• Manually cancel by method cancel() of Subscriber

How to create Subscriber

Assign

Assigns each element from a publisher to a property on an object.

func assign<Root>(
    to keyPath: ReferenceWritableKeyPath<Root, Self.Output>,
    on object: Root
) -> AnyCancellable

Use the assign(to:on:) subscriber when you want to set a given property each time a publisher produces a value.

import Combine
class MyModel {
    @Published var value: Int = 0
}
let model = MyModel()
var cancellable = Set<AnyCancellable>()
Just(10)
    .assign(to: \.value, on: model)
    .store(in: &cancellable)
print(model.value)  // Output: 10

You can use Subscribers.Assignto get the same approach, but note that the instance created by this operator maintains a strong reference to object, and sets it to nil when the upstream publisher completes (either normally or with an error), you can see the below example and try it yourself in Playground

import Combine
class ViewModel {
    var name: String = ""
    private var cancellable: Set<AnyCancellable> = Set()
    deinit {
        print("deinit")
    }
    init(publisher: CurrentValueSubject<String, Never>) {
        publisher.assign(to: \.name, on: self).store(in: &cancellable)
    }
}
let publisher = CurrentValueSubject<String, Never>("Test")
var viewModel: ViewModel? = ViewModel(publisher: publisher)
viewModel = nil // the ViewModel object can't be released because upstream publisher hasn't finished
publisher.send(completion: .finished) // finish the publisher, now the ViewModel object is completely released

I also find out an extension at forums.swift.org can replace the primary assign method to properly prevent the memory leak, that’s awesome!

extension Publisher where Self.Failure == Never {
    public func assignNoRetain<Root>(to keyPath: ReferenceWritableKeyPath<Root, Self.Output>, on object: Root) -> AnyCancellable where Root: AnyObject {
        sink { [weak object] (value) in
        object?[keyPath: keyPath] = value
    }
  }
}

Sink

Attaches a subscriber with closure-based behavior.

Use sink(receiveCompletion:receiveValue:) to observe values received by the publisher and process them using a closure you specify.

let publisher = Just("Hello, Combine!")
let cancellable = publisher
    .sink(receiveCompletion: { completion in
        switch completion {
        case .finished:
            print("Publisher completed successfully.")
        case .failure(let error):
            print("Publisher completed with error: \(error)")
        }
    }, receiveValue: { value in
        print("Received value: \(value)")
    })

• The receiveValue: closure is called with the value emitted by the publisher, and the receiveCompletion: closure is called when the publisher completes.
• The receiveCompletion: closure takes a Subscribers.Completion parameter, which is an enum that can be either .finished or .failure(let error). In this case, since Just cannot fail, there’s no error to handle, but in a real-world scenario, you would handle potential errors in the .failure case.

Please note that sink(receiveCompletion:receiveValue:) returns an AnyCancellable instance, which is stored in Set<AnyCancellable> to keep the subscription alive. If you don’t store this instance, the subscription is canceled immediately

Custom Subscriber

Implementing custom subscribers in Combine allows us to define our own logic for handling values received from publishers.

Step 1: Define Your Custom Subscriber

This class should conform to the Subscriber protocol. The Subscriber protocol requires you to specify types for Input and Failure.

class CustomSubscriber: Subscriber {
    typealias Input = Int
    typealias Failure = Never

Step 2: Implement the receive(subscription:) Method

This method is called once when the publisher is connected to the subscriber. Here, you can request a certain number of values from the publisher.

func receive(subscription: Subscription) {
    subscription.request(.max(1))
}

Step 3: Implement the receive(_:) Method

This method is called each time a new value is delivered by the publisher. Here, you can handle the received value.

func receive(_ input: Int) -> Subscribers.Demand {
    print("Value:", input)
    return .none
}

This mode returns Demand means that every time receives the value, Subscriber will adjust its request through Demand . With returning:

• none : do not get any more elements
• unlimited : take all
• max(n): get the next n elements

Step 4: Implement the receive(completion:) Method

This method is called when the publisher completes, either successfully or with an error. Here, you can handle the completion event.

func receive(completion: Subscribers.Completion<Never>) {
        print("Completion: \(completion)")
    }
}

Step 5: Use Your Custom Subscriber

Finally, you can use your custom subscriber with a publisher. The subscribe(_:) method is called on the publisher with the subscriber as an argument, which connects the publisher to the subscriber.

let publisher = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10].publisher
let subscriber = CustomSubscriber()
publisher.subscribe(subscriber)

You can also get the full code of CustomSubscriber here

AnyCancellable and memory management

AnyCancellable is a type-erasing cancellable object that executes a provided closure when canceled. It’s used to manage the lifetime of a subscription

Here are some key points about AnyCancellable:

• Cancellation token: Subscriber implementations can use AnyCancellable to provide a “cancellation token” that makes it possible for a caller to cancel a publisher. This means you can stop the subscription whenever you want by calling the cancel() method.

let publisher = Just("Hello, Combine!")
let cancellable: AnyCancellable = publisher
    .sink { value in
        print(value)
    }

// When you want to cancel the subscription
cancellable.cancel()

• Automatic cancellation: An AnyCancellable instance automatically calls cancel() when de-initialized. This means if the AnyCancellable instance is deallocated, the subscription will be canceled automatically.

class MyClass {
    var cancellable: AnyCancellable? = nil

    init() {
        cancellable = Just("Hello, Combine!")
            .sink { value in
                print(value)
            }
    }
}

var myClass: MyClass? = MyClass()  // prints "Hello, Combine!"
myClass = nil  // `cancellable` is deallocated, so the subscription is cancelled

• Storing AnyCancellable instances: You can store AnyCancellable instances in a collection or a set using the store(in:) method. This is useful when you have multiple subscriptions and want to manage them together.
• Memory Management: When you store AnyCancellable instances in a set (or any other collection), you’re essentially creating a strong reference to those instances. As long as there’s a strong reference to an AnyCancellable, the subscription it represents stays alive. However, if you remove all references to an AnyCancellable, then those AnyCancellable instances get deallocated, and the subscriptions they represent are automatically canceled.

class MyClass {
    var cancellables = Set<AnyCancellable>()

    init() {
        Just("Hello, Combine!")
            .sink { value in
                print(value)
            }
            .store(in: &cancellables)
    }
}

var myClass: MyClass? = MyClass()  // prints "Hello, Combine!"
myClass = nil  // MyClass instance is deinitialized, so all subscriptions are cancelled

In this code, when myClass is set to nil, the MyClass instance is deinitialized. As a result, the cancel() method of each AnyCancellable instance will be called automatically, effectively canceling all subscriptions. This is a key feature of AnyCancellable and a reason why it’s commonly used for managing subscriptions in Combine

Conclusion

This article covers subscribing to publishers with assign , sink and custom subscribers. Lastly, take advantage of AnyCancellable for efficient subscription and memory management in Combine.

References

https://developer.apple.com/documentation/combine/publisher/assign(to:on:)

https://stackoverflow.com/questions/57980476/how-to-prevent-strong-reference-cycles-when-using-apples-new-combine-framework

AnyCancellable | Apple Developer Documentation

Thanks for Reading! ✌️

If you have any questions or corrections, please leave a comment below or contact me via my LinkedIn account Pham Trung Huy.

Happy coding 🍻

Here are some preliminary-level threats that every iOS developer should take care of:

1. Screen Recording and Screen Capturing

An attacker can record sensitive screens such as login pages to capture username and password. Also possible to record paid video content

To fix that, we can observe the UIScreen.capturedDidChangeNotification and check for UIScreen.main.isCaptured

Observe changes to isCaptured with NotificationCenter:

NotificationCenter.default.addObserver(self, selector: #selector(screenCaptureDidChange),
                                       name: UIScreen.capturedDidChangeNotification,
                                       object: nil)

Handle the notification:

@objc func screenCaptureDidChange() {
    print("screenCaptureDidChange.. isCapturing: \\(UIScreen.main.isCaptured)")
    if UIScreen.main.isCaptured {
            //TODO: They started capturing..
            print("screenCaptureDidChange - is recording screen")
    } else {
        //TODO: They stopped capturing..
        print("screenCaptureDidChange - screen recording stoped")
    }
}

2. Weak Jail Break Detection

Application logic and behavior can be compromised on JailBroken devices, which can expose the application to attacks. Relying solely on jailbreak detection methods may not be sufficient to ensure the safety of your app

3 ways to identify whether a device is jailbroken or not:

1. Looking for unique files and applications that are installed on jailbroken devices

private var filesPathToCheck: [String] {    
  return ["/private/var/lib/apt",
            "/Applications/Cydia.app",
            "/private/var/lib/cydia",
            "/private/var/tmp/cydia.log",
            "/Applications/RockApp.app",
            "/Applications/Icy.app",
            "/Applications/WinterBoard.app",
            "/Applications/SBSetttings.app",
            "/Applications/blackra1n.app",
            "/Applications/IntelliScreen.app",
            "/Applications/Snoop-itConfig.app",
            "/usr/libexec/cydia/",
            "/usr/sbin/frida-server",
            "/usr/bin/cycript",
            "/usr/local/bin/cycript",
            "/usr/lib/libcycript.dylib",
            "/bin/sh",
            "/usr/libexec/sftp-server",
            "/usr/libexec/ssh-keysign",
            "/Library/MobileSubstrate/MobileSubstrate.dylib",
            "/bin/bash",
            "/usr/sbin/sshd",
            "/etc/apt",
            "/usr/bin/ssh",
            "/bin.sh",
            "/var/checkra1n.dmg",
            "/System/Library/LaunchDaemons/com.saurik.Cydia.Startup.plist",
            "/System/Library/LaunchDaemons/com.ikey.bbot.plist",
            "/Library/MobileSubstrate/DynamicLibraries/LiveClock.plist",
            "/Library/MobileSubstrate/DynamicLibraries/Veency.plist"]
}

func isJailBrokenFilesPresentInTheDirectory() -> Bool {
    var checkFileIfExist: Bool = false
    filesPathToCheck.forEach {
        checkFileIfExist =  fm.fileExists(atPath: $0) ? true : false
        if checkFileIfExist{
            return
        }
    }
    return checkFileIfExist
}

2. Checking if a file can be modified outside the application bundle. Developers can use this test to check if their application follows sandboxing rules

func canEditSandboxFilesForJailBreakDetection() -> Bool {
    let jailBreakTestText = "Test for JailBreak"
    do {
      try jailBreakTestText.write(toFile:"/private/jailBreakTestText.txt", atomically:true, encoding:String.Encoding.utf8)
      return true
    } catch {
    let resultJailBroken = isJailBrokenFilesPresentInTheDirectory()
    return resultJailBroken
    }
}

3. Calling the Cydia URL scheme (Cydia://) from an application successfully, it means the device is jailbroken

// Protocol function extended for JailBreak detection
func assignJailBreakCheckType() -> Bool {
  // If it is run on simulator follow the regular flow of the app
  if !isSimulator {
    // Check if Cydia app is installed on the device
      guard UIApplication.shared.canOpenURL(URL(string: "cydia://")!) else {
        return false
      }
      return true
    }
    return true
}

3. Keychain Data Protection

On JailBroken devices, a keychain item with a vulnerable accessibility option can be easily exposed to other applications or attackers with physical access

However, developers have multiple actions to mitigate this security risk:

1. kSecAttrAccessibleWhenUnlocked
2. kSecAttrAccessibleAfterFirstUnlock
3. kSecAttrAccessibleAlways
4. kSecAttrAccessibleWhenUnlockedThisDeviceOnly
5. kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly
6. kSecAttrAccessibleAlwaysThisDeviceOnly

Choose the easiest or more prone to vulnerable options like kSecAttrAccessibleWhenUnlocked may lead to potential security risk

The ‘kSecAttrAccessibleAfterFirstUnlock' or 'kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly' modes should only be used when the application requires a KeyChain item for background processing.

4. File Data Protection

When a file is to be saved, a developer can choose from these options to better use data protection

1. atomic: An option to write data to an auxiliary file first and then replace the original file with the auxiliary file when the write completes.
2. withoutOverwriting: An option that attempts to write data to a file and fails with an error if the destination file already exists.
3. noFileProtection: An option to not encrypt the file when writing it out.
4. completeFileProtection: An option to make the file accessible only while the device is unlocked.
5. completeFileProtectionUnlessOpen: An option to allow the file to be accessible while the device is unlocked or the file is already open.
6. completeFileProtectionUntilFirstUserAuthentication: An option to allow the file to be accessible after a user first unlocks the device.
7. fileProtectionMask: An option the system uses when determining the file protection options that the system assigns to the data.

Choosing noFileProtection should lead to potential security risks.

You should use ‘completeFileProtectionUnlessOpen’ and ‘completeFileProtectionUntilFirstUserAuthentication’ to have data protection on all files.

Encrypting a file on the first write

do {
    try data.write(to: fileURL, options: .completeFileProtection)
}
catch {
   // Handle errors.
}

For an existing file, you can use either NSFileManager/FileManager or NSURL:

try FileManager.default.setAttributes([.protectionKey: .completeFileProtection], ofItemAtPath: fileURL.path)
// Or
// cast as `NSURL` because the `fileProtection` property of `URLResourceValues` is read-only.
try (fileURL as NSURL).setResourceValue(URLFileProtection.complete, forKey: .fileProtectionKey)

With Core Data, you can pass the protection type when adding the persistent store:

try persistentStoreCoordinator.addPersistentStore(ofType: NSSQLiteStoreType, configurationName: nil, at: storeURL, options: [NSPersistentStoreFileProtectionKey: .completeFileProtection])

5. Show/Hide password field

When you identify that the screen is being recorded, use a mask over the password or any sensitive text field to protect data security. Also, hide/dismiss the keyboard while the app is being recorded

if(isRecording){
    let maskView = UIView(frame: CGRect(x: 64, y: 0, width: 128, height: 128))
    maskView.backgroundColor = .blue
    maskView.layer.cornerRadius = 64
    yourView.mask = maskView
}

6. HTTP Request

If the application uses an insecure communication channel (HTTP), means that an attacker on the same network as the victim could carry on a man-in-the-middle attack by injecting a 301 HTTP redirection response to an attacker-controlled server

7. Privacy Resources Access

The application can access user resources like contacts, location, Bluetooth device ID, camera, photos

However, this could lead to a data leak if the data is transmitted insecurely

The data must be encrypted before transmitting to the server to prevent this. In addition, it’s crucial to verify that there are no third-party libraries in use that access resources insecurely

8. Debug Logs Enabling

Developer should avoid printing method completion details and sensitive information in release builds

Use #if DEBUG when we want to log information for only debug builds

let logger = Logger(subsystem: "com.yourdomain.yourapp", category: "yourcategory")
#if DEBUG
logger.info("This is an info message")
// logger.debug("This is a debug message")
#endif

You can check OSLog and Unified logging as recommended by Apple

References

IOS Mobile App Security: Best Practices for iOS Mobile Developers. | by Munendra Pratap Singh | Feb, 2024 | Medium

Thanks for Reading! ✌️

If you have any questions or corrections, please leave a comment below or contact me via my LinkedIn account Pham Trung Huy.

Happy coding 🍻

Essential iOS App Security Cases Developers Shouldn’t Overlook was originally published in Towards Dev on Medium, where people are continuing the conversation by highlighting and responding to this story.

· Publishers
· Publisher from a Sequence
· Publisher from transformation
· Publisher from the Class’s property
· Just
· Future
· Subject
· PassthroughSubject
· CurrentValueSubject
· Type Erasure
· Conclusion

Continue with the Combine series, today we will discuss Publisher. Combine needs something that can model a data stream. This is the role of the Publisher protocol.

If you haven’t read my article about Combine in general, let’s check it out: Introduction to Combine in iOS. What is Combine? | by Huy Pham | Apr, 2024 | Medium

Now we will focus on types of Publisher regularly used and how to use them

Publishers

Publisher from a Sequence

A data stream can be viewed as a sequence of events over time. Therefore a Sequence is a great source for a simple publisher. Like this example above, Array conforms to Sequence. Sequence has a property called publisher that creates a publisher that emits the element from the source sequence

let arrayPublisher = [1, 2, 3, 4, 5].publisher

Another example:

let stringPublisher = "Huy Pham".publisher

The initial value is a String, after transforming to a publisher, its emitted values are characters

The characteristic of this Publisher type is that it never makes errors, so the data type for Failure is Never

Publisher from transformation

We can create a new publisher by using transform operators

[1, 2, 3].publisher // publisher of integers
    .map(String.init) // now a publisher of strings
    .sink {
        print($0)
    }
    .store(in: &cancellable)

The map function takes the values emitted by the upstream publisher and passes them as input to theString.init function. So the result Publisher now emits a String rather than an Int

Besides, we can create publishers from other sealed struct of Publishers, be able to transform upstream data to your expected publisher. See the example below:

// combine latest operator
let publisher1 = PassthroughSubject<Int, Never>()
let publisher2 = PassthroughSubject<String, Never>()
let combined = Publishers.CombineLatest(publisher1, publisher2)

// create a sequence by sequence operator 
let numbers = [1, 2, 3, 4, 5]
let sequencePublisher = Publishers.Sequence<[Int], Never>(sequence: numbers)

It’s we simulate the operators. I will have an article next week giving more detail about Combine’s operators.

Publisher from the Class’s property

@Published is a property wrapper that makes any property using it Publisher

This wrapper is class-constrained, meaning that you can only use it in instances of a class

class ViewModel {
    @Published var title = "the first title"
}

@Published doesn’t need to call send() method or access .value. When you directly change its value, it will update the value. Note that we’re using the dollar sign to access the projected value. If you’re not familiar with this technique, check Apple’s document about Property Wrapper and projected value

var cancellable = viewModel.$title.sink(receiveValue: { newTitle in
    print("Title changed to \(newTitle)")
})
viewModel.title = "the second title"

// Prints:
// Title changed to the first title
// Title changed to the second title

This approach is very efficient with UIKit and SwiftUI in case you don’t want to change the architecture of your project

Just

Just struct creates a straightforward publisher that will emit one value and then complete

Just("A")

This is handy for use as the return type of a function or if you just want to emit just 1 value

Future

Future means a publisher that eventually produces a single value and then finishes or fails. It provides closure as Future.Promise has Result type parameter without a return value. In the successful case, the future downstream subscriber receives the element before the publishing stream finishes normally. If the result is an error, publishing terminates with that error.

func generateAsyncRandomNumberFromFuture() -> Future <Int, Never> {
    return Future() { promise in
        DispatchQueue.main.asyncAfter(deadline: .now() + 2) {
            let number = Int.random(in: 1...10)
            promise(Result.success(number))
        }
    }
}
cancellable = generateAsyncRandomNumberFromFuture()
    .sink { number in print("Got random number \\(number).") }
    
// Prints
// Got random number 9

Future can replace the callback of the function, which can allow you to express asynchronous behavior without deeply nested callbacks (callback hell)

Subject

PassthroughSubject

PassthroughSubject can be used to emit values to downstream subscribers. However, it doesn’t store or cache the most recent value

CurrentValueSubject

Like PassThroughSubject, it can emit values to downstream subscribers. However, unlike PassThroughSubject, CurrentValueSubject maintains and provides access to the most recent value it has received. When a new subscriber attaches to a CurrentValueSubject, it immediately receives the current value (if available) before getting any subsequent updates

import Combine
class DataManager {
    // Create a PassThroughSubject to emit updates
    let passThroughSubject = PassthroughSubject<String, Never>()
    
    // Create a CurrentValueSubject with an initial value
    var currentValueSubject = CurrentValueSubject<Int, Never>(0)
    
    func updateData(value: String) {
        passThroughSubject.send(value)
    }
    
    func updateCurrentValue(value: Int) {
        currentValueSubject.send(value)
    }
}

let dataManager = DataManager()

let passThroughSubscription = dataManager.passThroughSubject.sink { value in
    print("Received value from PassThroughSubject: \\(value)")
}
let currentValueSubscription = dataManager.currentValueSubject.sink { value in
    print("Received value from CurrentValueSubject: \\(value)")
}
// subjects emit data
dataManager.updateData(value: "Hello, World!")
dataManager.updateCurrentValue(value: 42)
// Prints
// Received value from PassThroughSubject: Hello, World!
// Received value from CurrentValueSubject: 0
// Received value from CurrentValueSubject: 42

The main difference between both subjects is that a PassthroughSubject doesn’t have an initial value or a reference to the most recently published element. Therefore, new subscribers will only receive newly emitted events.

• A PassthroughSubject is like a doorbell push button When someone rings the bell, you’re only notified when you’re at home
• A CurrentValueSubject is like a light switch When a light is turned on while you’re away, you’ll still notice it was turned on when you get back home.

Type Erasure

Sometimes you want to subscribe to the publisher without knowing too much about its details or the chain operators create complicated nested type

let publisher = Fail<Int, Error>(error: ErrorDomain.example)
    .replaceError(with: 0)
    .map { _ in "Now I am a string" }
    .filter { $0.contains("Now") }

The type of this publisher is:

Publishers.Filter<Publishers.Map<Publishers.ReplaceError<Fail<Int, Error>>, String>>

To manage these nested types publishers have the eraseToAnyPublisher() method. This is a form of “type erasure”. This method erases the complex nested types and makes the publisher appear as a simpler AnyPublisher<String, Never> to any downstream subscribers.

With AnyPublisher, can’t call send(_:) method, it’s important to wrap a subject with AnyPublisher to prevent the view from sending events through it. When you use type erasure in the MVVM way, you can change the underlying publisher implementation over time without affecting existing clients.

Conclusion

In summary, Combine’s Publishers provides iOS developers with a powerful solution for managing asynchronous events and data streams. Mastering Publishers is essential for creating robust, scalable iOS applications with reactive capabilities.

Thanks for Reading! ✌️

If you have any questions or corrections, please leave a comment below or contact me via my LinkedIn account Pham Trung Huy.

Happy coding 🍻

Publisher in Combine: Unveiling the Publisher Role was originally published in Towards Dev on Medium, where people are continuing the conversation by highlighting and responding to this story.

Asynchronous programming in Swift often involves using completionHandler within functions to handle events. While this approach is common, there are potential pitfalls that developers need to be mindful of. One such pitfall is that there is no guarantee all code paths will eventually call the completionHandler. This means if we forget to call it, the code will still build successfully, leading to unexpected behaviors or bugs.

To create safer code that ensures the completionHandler is always called, we can follow a simple two-step process:

1. Declare a constant using the let keyword to store the result.
2. Use a defer statement to call the completionHandler.

The defer statement is a powerful tool in Swift. It ensures that a block of code is executed when the current scope exits, which in this case is just before the function returns. This guarantees that the completionHandler will always be called, even if an error occurs during the function's execution.

Here’s an example of how you can implement this in your code:

import Foundation
func fetchData(url: URL, _ completion: @escaping (Result<Data, Error>) -> Void) {
    URLSession.shared.dataTask(with: url) { data, _, error in
        let result: Result<Data, Error>
        defer {
            completion(result)
        }
        guard error == nil else {
            result = .failure(error!)
            return
        }
        guard let data else {
            result = .failure(NetworkError.noData)
            return
        }
        result = .success(data)
    }
    .resume()
}

In the above code, we first declare a constant result to store the outcome of our network call. We then use a defer statement to call the completionHandler with the result just before the function exits. This ensures that regardless of the path our code takes, our completionHandler is always called.

By incorporating these steps, we can create a safer and more reliable asynchronous code that guarantees our completionHandler is always executed.

Reference: Here’s the trick to make a completionHandler much safer! 😌 — YouTube

Thanks for Reading! ✌️

If you have any questions or corrections, please leave a comment below or contact me via my LinkedIn account Pham Trung Huy.

Happy coding 🍻

When developing in Swift, a common task you may come across is comparing strings. However, did you know that using the .lowercased() method might not be the best way to do it?

Let’s take a look at an example where we compare two strings using .lowercased():

import Foundation

let searchQuery = "cafe"
let databaseValue = "Café"
if searchQuery.lowercased() == databaseValue.lowercased() {
    //...
}

At first glance, this seems like a reasonable approach. After all, the .lowercased() method is simple and easy to use. However, it has a couple of significant drawbacks.

Firstly, the .lowercased() method creates a new copy of each String every time it's called. This could potentially harm performance, especially if you're dealing with large strings or performing the operation numerous times.

Secondly, using .lowercased() only provides a case-insensitive search. It doesn't account for diacritics, such as accents. For instance, it wouldn't match "cafe" with "Café".

So, what’s the solution? Swift provides the compare() method, allowing us to specify comparison options. This method is more flexible and can handle diacritics and case sensitivity.

Here’s how you can use it:

import Foundation

let searchQuery = "cafe"
let databaseValue = "Café"
let comparisonResult = searchQuery.compare(
    databaseValue,
    options: [.caseInsensitive, .diacriticInsensitive]
)
if comparisonResult == .orderedSame {
    //...
}

In this example, we’re using the .caseInsensitive and .diacriticInsensitive options to compare the strings. This means the comparison will ignore both case and diacritics, making it a more robust solution for string comparison in Swift.

In conclusion, while .lowercased() may seem like an easy solution for string comparison, it's worth considering the compare() method for a more versatile and efficient approach.

Reference: Different ways to compare string in Swift | Sarunw

Thanks for Reading! ✌️

If you have any questions or corrections, please leave a comment below or contact me via my LinkedIn account Pham Trung Huy.

Happy coding 🍻