DEV Community: Tarik Dahic

macOS storage cleaning tips for iOS developers

Tarik Dahic — Fri, 02 Feb 2024 21:53:21 +0000

While we work as developers we are constantly downloading, installing, moving and changing files on our drive. This results to populating the drive to its limit, at least in my case. In this article I will show you two tools that I use on my Mac to detect and free the used storage.

DevCleaner

DevCleaner is a great macOS app for freeing the storage used by Xcode. It is developed by Konrad Kołakowski and it is available on Mac App Store and GitHub.

The app allows you to clean device support files from development phones, build archives, derived data, documentation cache and old simulator & device logs. I found it really useful to quickly free the data that I don’t need.

GrandPerspective

GrandPerspective is a compact macOS utility that visually represents disk usage in a file system. It aids in disk management by allowing you to quickly identify the files and folders consuming the most space. The visualization employs a tree map, where each file is depicted as a rectangle, its size proportional to the actual file size. Files within the same folder are grouped together, but their placement is otherwise random.

It is developed by Erwin Bonsma. More info can be found on its SourceForge page.

This app helped me a lot of times to identify what is taking up my drive space. It is very simple to use. When opening the app you pick the base folder from where the scanning will start and after the scanning is done you will get a view with rectangular blobs showing what takes your disk space. I often choose the root (/) folder for the scanning so that I can see all the files on my computer.

If you have any other tips or apps for freeing storage please leave them in the comments. I hope that this article helped you to understand what takes up the space on your macOS computer.

Limit concurrent function executions using Go channels

Tarik Dahic — Mon, 21 Aug 2023 17:49:11 +0000

This article will explain how to limit concurrent function execution using Go channels. I worked on a Go service that executes another program inside its HTTP request handler. The program that is executed uses a lot of CPU usage and memory usage since it works with photos and videos so I had to limit how many of them could be running at the same time.

Luckily, Go channels come very handy in situations like these. We will also add timeout support so that our waiting goroutines don’t block indefinitely. Buffered Go channels will be needed to develop this so let’s remember what they are.

Buffered Go channels

Buffered channels can hold a limited number of values (determined by the buffer size), and will only block the sending goroutine when the buffer is full. This can allow for some additional concurrency, but requires careful consideration to avoid deadlocks and other synchronization issues.

Buffered channels are an ideal solution for what we are going to build in this article.

Limiting concurrent function execution

We start by creating a new package called limiter and we define a data structure for Limiter type. We will provide a limit and a timeout when creating a Limiter and the data structure will hold that timeout and a buffered channel created with provided limit.

Translated to code we can write something like this:

type Limiter struct {
    timeout time.Duration
    ch chan struct{}
}

func NewLimiter(limit int, timeout time.Duration) *Limiter {
    return &Limiter{
        timeout: timeout,
        ch: make(chan struct{}, limit),
    }
}

We now need to define how a Limiter type will be used. I thought that it would be the best if we could pass a function that takes no arguments and returns no values to the limiter. If the buffer of a buffered channel is not full then the passed function will be executed. If the buffer is full then the caller will wait for a timeout that was defined when Limiter was created. If a slot is freed then the function will be executed and if time for timeout passes an error will be returned.

The buffered channel is created with the type of an empty struct. Empty structs are useful for signaling where data is not important because their memory footprint is 0. You can find more on empty structs reading this great article.

We can see the definition of Execute function in the code below.

func (l *Limiter) Execute(f func()) error {
    select {
    case l.ch <- struct{}{}:
        // Added execution for running...
    case <-time.After(l.timeout):
        return errors.New("execution timed out")
    }

    // On exit, remove this execution from limit channel
    defer func() {
        <-l.ch
    }()

    f()

    return nil
}

Execute function first tries to insert the empty struct into the buffered channel. If the channel is not full, the select statement will continue and the provided function will be executed. But, if the channel is full the select statement will wait and two things can happen. The buffered channel will be emptied below its capacity and we will execute the provided function. If the amount of time passes as defined in the timeout value of the limiter the select statement will enter the case where it returns the error. In that case, function will not be executed. Before invoking the provided function we add a function with defer statement that will be executed when Execute completes. This function will that the buffered channel is being emptied.

This is all for limiter, a struct that can limit function calls. I would also like to point that in a select statement you can define custom time intervals using channels like in the example code above. This can be very useful to check some things periodically or to do timeouts like in this example.

Here is an example on how to use the structure that we’ve defined:

// 1. Define the limiter
l := limiter.NewLimiter(5, 20*time.Second)

// 2. Somewhere in your code you can add a function for execution   
l.Execute(func() {
    // Processing..
})

If you want to see the entire file I’ve created a gist on GitHub so you can visit this link or copy the code from the GitHub embed below.

Thank you for reading this article and I hope that it helped you to solve your problem or learn something new.

Non-blocking sequential processing in Go using infinite (unbounded) buffered channel

Tarik Dahic — Wed, 09 Aug 2023 18:04:31 +0000

While developing the backend service that will handle a lot of real-time events at the company I work for we had a requirement to queue and process events sequentially while not blocking the reader that is reading them. Representing this requirement in a diagram looks like this:

After the event is queued for processing the control is given to the reader so that it could read new events and not block the reading.

In Go this type of problem cannot be solved without using channels and goroutines so we will go down that road.

Buffered and unbuffered Go channels

When creating a Go channel we can create it as a buffered or an unbuffered channel. Here is an example:

ch := make(chan int) // Unbuffered
ch := make(chan int, 3) // Buffered

Unbuffered channels block the sending goroutine until there is a corresponding receiver ready to receive the value being sent. This means that data is guaranteed to be received in the order it was sent, and that synchronization is built into the channel. However, if we send one event as per our requirement and it starts processing, the next event will block and will have to wait for the first one to complete processing. The reading of the next event will be blocked. We don’t want that.

Buffered channels, on the other hand, can hold a limited number of values (determined by the buffer size), and will only block the sending goroutine when the buffer is full. This can allow for some additional concurrency, but requires careful consideration to avoid deadlocks and other synchronization issues. On the first thought, this could work, if we know the system demand we can provide a buffer big enough so that we don’t worry that it will get blocked.

But, we know better and we want to eliminate all the ifs. That is why we will build a Go buffered channel with infinite (unbounded) capacity.

Go buffered channel with infinite capacity

Let’s start with a name. I named my package and the data structure executor. There are a lot of use cases for queuing data so we will need to use Go generics so that every type of data can be passed into the executor. Go generics are available from Go version 1.18 and up. We also need to define the executor API, how it will be used when it is used in Go software. I decided to pass the function to the executor that will be called within when some data is ready to be processed.

To make it easy for ourselves we can define a new type that will describe this function:

type ExecHandler[T any] func(T)

Since we will be queuing something, preferably, on another goroutine, we will need a pair of channels to send data from that goroutine and to read data for processing. A data structure encapsulating all of the mentioned above could be defined like:

type Executor[T any] struct {
    reader chan T
    writer chan T
    buffer []T
    execHandler ExecHandler[T]
}

Buffer property will hold queued elements that are waiting to be processed.

We also need to provide a factory function for executor so that everything is properly initialised:

func New[T any](execHandler ExecHandler[T]) *Executor[T] {
    e := &Executor[T]{
        reader: make(chan T),
        writer: make(chan T),
        buffer: make([]T, 0),
        execHandler: execHandler,
    }

    go e.run()

    return e
}

New function constructs and returns the executor object. It also spawns a new goroutine and calls a run method on executor which starts listening for new elements that will be queued for processing.

func (e *Executor[T]) run() {
    go e.listenForReading()
    for {
        if len(e.buffer) > 0 {
            select {
            case e.reader <- e.buffer[0]:
                e.buffer = e.buffer[1:]
            case data := <-e.writer:
                e.buffer = append(e.buffer, data)
            }
        } else {
            data := <-e.writer
            e.buffer = append(e.buffer, data)
        }
    }
}

func (e *Executor[T]) listenForReading() {
    for data := range e.reader {
        e.execHandler(data)
    }
}

There’s a lot happening in the run method and we will now break it down. In the first line we spawn a new goroutine that will be doing processing of queued elements. By processing I mean that the exec handler will be called with that element.

Next, we have an infinite loop that queues and sends data to processing. If the buffer of queued elements is empty we wait for a new element from writer channel. When we get a new element it is stored in the buffer and the new iteration of the loop begins.

If the buffer is not empty, we stop on a select statement where two things can happen:

If reader channel is ready, element can be dispatched to processing and it will be removed from the buffer.
In case a new element is waiting to be queued it will be added to the buffer.

Only thing left is to add an exported method to executor for queuing elements:

func (e *Executor[T]) Dispatch(data T) {
    e.writer <- data
}

That would be it, we now have a functioning infinite (unbounded) channel that processes data sequentially.

If you want to see the entire file I’ve created a gist on GitHub so you can visit this link or copy the code from the GitHub embed below.

There are a lot of solutions to this problem so if you have one that differs from the one in the article please discuss it below. I would love to see what else is possible. If you are working in other technologies or in Go, I encourage you to play with stuff like this to get better understanding of the language and its concurrency mechanisms.

Calculate values in background and use the result after with Swift concurrency

Tarik Dahic — Thu, 13 Oct 2022 20:07:08 +0000

If you need to compute a value and don’t want to block the main thread you can do so by calculating that value in a Swift Task structure that will return that computed value. Prior to Swift concurrency you would probably jump to a background queue and compute the value that you need and proceed with some action if necessary.

Let’s jump into an example. I defined a struct called Example that will create a Task at its init in which it will try to compute and return a String value. The struct will also have an async method called value() which will return that computed value.

struct Example {

  private var someTask: Task<String, Error> = Task {
    // Some calculation
    try await Task.sleep(nanoseconds: 3_000_000_000)
    return "example"
  }

  func value() async throws -> String {
    return try await someTask.value
  }
}

When we want to access the computed value we can use the value property that is defined on the Swift Task structure. If the task hasn’t completed, accessing this property waits for it to complete and its priority increases to that of the current task.

To use the Example structure we need to instantiate it and read the value from an async context:

let example = Example()

Task {
  do {
    print("Value is:", try await example.value())
  }
}

If the Task will not throw an error then its type would be Task<ReturnType, Never> and we wouldn’t need to use try keyword when accessing the task’s value.

This has helped me in some situation where I want to calculate something in advance and if user requests it that I instantly have it. For example, I wanted to compress the image from camera in case user presses the button to send the image. I start the compression on the image preview screen and then when user wants to send it I have the compressed image ready.

Wrapping delegates with Swift async/await and continuations

Tarik Dahic — Thu, 30 Jun 2022 13:52:44 +0000

In this article you will learn how to convert or use existing delegate patterns and wrap them with Swift’s structured concurrency to use it with async/await mechanism in your apps.

I will show you an example with AVCapturePhotoCaptureDelegate to start capturing a photo and return the resulting UIImage when the capture is over.

Adopting delegate and using completion handler

In the code example below I implemented a simple class CameraPhotoProcessor and that class adopts the AVCapturePhotoCaptureDelegate protocol. Its responsibility is to start capturing the photo and convert it to a UIImage when the photo is captured. It is done asynchronously. I introduced a completion handler that can notify the code that calls the startCapture() when the photo is actually captured. The completion handler will be invoked with Swift’s Result type and it will be one of the two supported values, success with image object or failure with error object.

class CameraPhotoProcessor: NSObject {

    private var completion: ((Result<UIImage, Error>) -> Void)?

    func startCapture(from photoOutput: AVCapturePhotoOutput, using settings: AVCapturePhotoSettings, completion: @escaping (Result<UIImage, Error>) -> Void) {
        self.completion = completion
        photoOutput.capturePhoto(with: settings, delegate: self)
    }
}

// MARK: - AVCapturePhotoCaptureDelegate

extension CameraPhotoProcessor: AVCapturePhotoCaptureDelegate {

    func photoOutput(_ output: AVCapturePhotoOutput, didFinishProcessingPhoto photo: AVCapturePhoto, error: Error?) {
         if let error = error {
             completion?(.failure(error))
             return
         }

         guard let data = photo.fileDataRepresentation() else {
             completion?(.failure(CustomError(msg: "Cannot get photo file data representation")))
             return
         }

        guard let image = UIImage(data: data) else {
            completion?(.failure(CustomError(msg: "Invalid photo data")))
            return
        }

        completion?(.success(image))
    }
}

We can see that the code above is error prone. The completion handler that will be passed will need to use the [weak self] capturing to avoid creating retain cycles. Let’s say that we have a function that is called when the capture button is pressed. This is how we would use the code above:

func captureButtonPressed() {
    photoProcessor.startCapture(from: photoOutput, using: settings) { [weak self] result in
        switch result {
            case .success(let image):
                // We have the image and now we can pass it or process it further
            case .failure(let error):
                print(error.localizedDescription)
        }
    }
}

When using completion handlers we always need to watch out where the code will continue executing and what will we do beneath or inside the closure. For an experienced developer it doesn’t matter but when using the async/await the code looks a lot cleaner and less error prone.

Introducing continuations

Continuations are mechanisms to interface between synchronous and asynchronous code. They wrap our existing code and wait for us to notify them about changes. The notifying part is called the resume operation that we can use on the continuation.

There are two types of continuations:

Checked continuation - This type of continuation performs checks if continuation is resumed more than one time or if it is resumed after some time. Resuming from a continuation more than once is undefined behavior. Never resuming leaves the task in a suspended state indefinitely, and leaks any associated resources. Checked continuation logs a message if either of these invariants is violated.
Unsafe continuation - Checked continuation performs runtime checks for missing or multiple resume operations. Unsafe continuation avoids enforcing these invariants at runtime because it aims to be a low-overhead mechanism for interfacing Swift tasks with event loops, delegate methods, callbacks, and other non-async scheduling mechanisms.

During development, the ability to verify that the invariants are being upheld in testing is important. Because both types have the same interface, you can replace one with the other in most circumstances, without making other changes.

Continuations can also be throwing or non-throwing. We can create them using global functions:

withCheckedContinuation()
withCheckedThrowingContinuation()
withUnsafeContinuation()
withUnsafeThrowingContinuation()

Applying continuations

We will now use the theory from above and apply it onto our example with capturing a photo. Instead of creating a completion property we will now have an imageContinuation property.

In this example I will use the checked throwing continuation because even though I know that my resume operation on continuation will be called one time. The throwing part is needed because our photo capturing operation can fail and we need a way to throw errors when the operation is aborted or failed.

class CameraPhotoProcessor: NSObject {

    private var imageContinuation: CheckedContinuation<UIImage, Error>?

    func startCapture(from photoOutput: AVCapturePhotoOutput, using settings: AVCapturePhotoSettings) async throws -> UIImage {
        return try await withCheckedThrowingContinuation { continuation in
            imageContinuation = continuation
            photoOutput.capturePhoto(with: settings, delegate: self)
        }
    }
}

// MARK: - AVCapturePhotoCaptureDelegate

extension CameraPhotoProcessor: AVCapturePhotoCaptureDelegate {

    func photoOutput(_ output: AVCapturePhotoOutput, didFinishProcessingPhoto photo: AVCapturePhoto, error: Error?) {
         if let error = error {
             imageContinuation?.resume(throwing: error)
             return
         }

         guard let data = photo.fileDataRepresentation() else {
             imageContinuation?.resume(throwing: CustomError(msg: "Cannot get photo file data representation"))
             return
         }

        guard let image = UIImage(data: data) else {
            imageContinuation?.resume(throwing: CustomError(msg: "Invalid photo data"))
            return
        }

        imageContinuation?.resume(returning: image)
    }
}

And to use this in a Swift Task:

func captureButtonPressed() {
    Task {
        do {
            let image = try await startCapture(from: photoOutput, using: settings)
            // We have the image and now we can pass it or process it further
        } catch let error {
            print(error.localizedDescription)
        }
    }
}

Using Swift’s structured concurrency is more safe and less error prone as we can see. It also improves readability when multiple async operations are used. Imagine that we have three async operations using completion handlers. In that case we would need to indent the code three levels to use the final result. When using async/await we don’t have that. Everything is a straight line :)

Making properties read only outside their scope using private(set) in Swift

Tarik Dahic — Fri, 22 Apr 2022 15:06:28 +0000

I recently discovered Swift feature where setter for class and struct properties could be set to private while getter is internal or publicly accessed. This allows us to expose properties to the outside world without worrying if someone is going to change them in the future. I mostly do this to make dependencies of some type accessible.

The example below shows how could we use this in a class or a struct.

class Example {
  // prop will have an internal access modifier
  private(set) var prop: Type

  // prop with public access modifier
  public private(set) var prop: Type
}

prop can be changed (set) only in the scope of the encapsulated struct or class but the outside world can only read it.

Setting a private setter only works with properties marked as var and not let because properties marked with let are constants and by nature they are immutable.

This Swift feature could also be used in cases when we have a read-only property backed by another private property. Something like this:

class Example {
  private var _prop: Type

  var prop: Type {
    get {
      return _prop
    }
  }
}

// Using private(set) makes code more readable and reduces the complexity:

class Example {
  private(set) var prop: Type
}

Fetch and display the latest git commit hash in your iOS apps

Tarik Dahic — Thu, 25 Nov 2021 21:17:54 +0000

If you want to know from what exact commit your app is built you can include the latest git commit hash to the place where you display the app version. I like to call that generated hash “revision” or in short “rev”.

Displaying this can be useful when you are distributing internal versions of your apps to QA engineers and you want to know on what app version they are testing. While the changes are coming in on development branches we don’t increase version or build numbers, we follow the revision value and always know what version is in use.

In this article I will explain how to fetch the latest git commit hash in Xcode and display it in the iOS app.

Fetching the latest git commit hash

The procedure I will describe adds a new row to your Info.plist file with specified key and sets the value to the short git commit hash.

The first step is to go to your target’s Build phases setting and add a new run script phase. The “Run script” action will be on the bottom and you need to move it above the “Copy bundle resources” action.

When you move it, you can paste this code for the script:

GIT=`xcrun -find git`
GIT_REV=`${GIT} rev-parse --short HEAD`
/usr/libexec/PlistBuddy -c "Set :REVISION ${GIT_REV}" "${SRCROOT}/{{path-to-your-info.plist-file}}"

In the script above we rely on PlistBuddy to set the key REVISION and the value of the latest git commit hash to the app’s Info.plist file. PlistBuddy is a macOS utility that helps us to manage plist files. You can read more about it here or you can type /usr/libexec/PlistBuddy -h in your terminal to find out more of what it can do.

Now, when you have run the build process, the script that we added should’ve inserted a new entry in your Info.plist file and we can proceed to displaying it.

Displaying the revision

To display the revision we just need to fetch our Info.plist and provide a key to read the value from it:

let revision = Bundle.main.object(forInfoDictionaryKey: "REVISION") as? String

In Objective-C we would do it like this:

NSString *revision = [NSBundle.mainBundle objectForInfoDictionaryKey:@"REVISION"];

Display SwiftUI views from Objective-C codebase

Tarik Dahic — Thu, 18 Nov 2021 18:44:55 +0000

SwiftUI is getting more mature with every new major iOS release and it is now in a state where it can be used for a lot of use cases. The app that I work on my daily job is based on Objective-C and I wanted to prototype some things in SwiftUI because it was faster and more fun. It was also a great way to escape UIKit for a little and learn more about SwiftUI. That means I had to display SwiftUI views from Objective-C ViewControllers. In this article I will explain how I did that.

There are some limitations between Objective-C and Swift regarding SwiftUI. SwiftUI views are structs and they are not visible from the Objective-C code. The only way to bridge the two worlds is to use some kind of a mediator class between Objective-C and Swift code.

SwiftUI and UIKit

Because we will be displaying SwiftUI views from UIKit we first need to know what abstractions to use to wrap SwiftUI views. UIKit can only present or push UIViewController instances. To create UIViewController instance from SwiftUI view we need to wrap it into a UIHostingController. In UIHostingController initializer we pass the SwiftUI view that we want to wrap like in the example below:

let controller = UIHostingController(rootView: SwiftUIView())

UIHostingController is a subclass of UIViewController and now controller variable can be used from our UIKit code to present it, push it onto the navigation stack or add it as a child view controller. You can read more about UIHostingController here.

Adding Obj-C to the mix

Now that we know how to display SwiftUI views inside UIKit we need to bridge UIHostingController to the Objective-C world. As I mentioned earlier, Swift structs are not visible from the Objective-C context so we need to add a middleman that will create UIHostingController instances wrapped around SwiftUI views.

I like to call the middleman implementations as SwiftUIViewAdapter or SwiftUIViewFactory. I am still not settled on a final suffix but something between these two seems right.

Let’s start with a simple SwiftUI view that will display the text that is passed into its initializer:

import SwiftUI

struct HelloWorldView: View {

    var text: String

    init(text: String) {
        self.text = text
    }

    var body: some View {
        Text(text)
    }
}

To display the HelloWorldView we need to wrap it into the middleman class that will create the UIHostingController:

@objc class HelloWorldViewFactory: NSObject {

    @objc static func create(text: String) -> UIViewController {
        let helloWorldView = HelloWorldView(text: text)
        let hostingController = UIHostingController(rootView: helloWorldView)

        return hostingController
    }
}

There are a couple of things happening in the HelloWorldViewFactory class implementation above, so let’s cover them one by one:

HelloWorldViewFactory class has one static function create(text:) that will create the HelloWorldView and initialize it, wrap it inside the UIHostingController and return it.
To expose HelloWorldViewFactory to Objective-C code we need to prefix it with @objc annotation and we need to subclass NSObject. This is because NSObject is the root class of most Objective-C class hierarchies, from which subclasses inherit a basic interface to the runtime system and the ability to behave as Objective-C objects.
You can also notice that we are passing text String argument to create function. This allows us to use custom initializers for SwiftUI views and to pass dependencies that views need.

Now we can display this view from Objective-C like this:

UIViewController *vc = [HelloWorldViewFactory createWithText:@"Hello from Obj-C!"];
[self presentViewController:vc animated:YES completion:nil];

In this example the device should display the view that has text centered and set to Hello from Obj-C!

Importing Swift code into Objective-C

If you didn’t use Swift in your existing Objective-C project it is important to know that you need to import the Swift module header into the Objective-C file that will use your Swift code. That header file is named like $(SWIFT_MODULE_NAME)-Swift.h and if you want, you change the name for that header file inside build settings for your target. The config option that defines the name is Objective-C Generated Interface Header Name.

If your app target is called MyTestApp you can import the Swift code into Objective-C like this:

#import "MyTestApp-Swift.h"

If you are in the same situation as I was I hope that this article will help you.

Using semaphores in iOS to serialise callback completion

Tarik Dahic — Fri, 12 Nov 2021 10:11:57 +0000

In most of the situations when you are developing apps you will encounter APIs provided to you by someone else (framework, library, system, etc.). You cannot change the API and you need to use it as it is. Let’s say, to use that API, you give it a function that will be called when the result is ready or some action is completed (also known as a callback).

But, what if you don’t want to continue if the result is not ready or action is not completed? I’ve found that using semaphores is good for this situation and I will describe how to do it in this article. But first, we need to learn more about semaphores.

Semaphore 🚦

Semaphore mechanism was proposed by Dijkstra in the sixties which is a very significant technique to manage concurrent operations on shared resources. A trivial semaphore is a variable, like integer or a boolean that is incremented/decremented or toggled and depending on the state of that variable threads can access the resource or wait for it to become free.

A useful way to think of a semaphore as used in a real-world system is as a record of how many units of a particular resource are available, coupled with operations to adjust that record safely (i.e., to avoid race conditions) as units are acquired or become free, and, if necessary, wait until a unit of the resource becomes available.

There are two types of semaphores:

Binary Semaphore — It can have only two values – 0 and 1, and we can also represent this semaphore with a boolean. It will allow only one thread to use the resource while others will wait.
Counting Semaphore — By creating this semaphore we provide it with a number of how many threads are allowed to use it at the same time. When threads use the resource the semaphore counter is decremented. If the counter reaches 0 the threads that want to access the resource will wait until one of the threads is finished.

If we think of the implementation, a simple semaphore could be implemented by using one integer variable and one FIFO queue. Initial count of the integer variable determines how many available resources we have for consumers to use. If someone asks for access we decrement the count variable and if the value is not negative we allow the access to the resource. If the value is negative we add that consumer to FIFO queue and halt it until one of the consumers that is already using the shared resource signals that it has finished. When the thread signals that it has finished using the shared resource we increment the count variable and if threads are waiting in the FIFO queue we use the first one and give it access to the shared resource. Implementation like this where there is no prioritisation of threads can lead to a problem called priority inversion.

The operation that consumers use to request access of the shared resource which decrements the count variable is called wait and the operation of incrementing the count variable and telling the semaphore that we’re done using the shared resource is called signal.

Another great analogy that I found is:

Semaphore is the number of free identical toilet keys. Example, say we have four toilets with identical locks and keys. The semaphore count — the count of keys — is set to 4 at beginning (all four toilets are free), then the count value is decremented as people are coming in. If all toilets are full, ie. there are no free keys left, the semaphore count is 0. Now, when eq. one person leaves the toilet, semaphore is increased to 1 (one free key), and given to the next person in the queue.

Officially: “A semaphore restricts the number of simultaneous users of a shared resource up to a maximum number. Threads can request access to the resource (decrementing the semaphore), and can signal that they have finished using the resource (incrementing the semaphore).”Ref: Symbian Developer Library

Semaphores in iOS

In iOS semaphore implementation is a part of the Dispatch framework. You can use semaphores with Obj-C and Swift. I will provide an example for both languages.

The API to use semaphores is not complicated and it is very straightforward. We have 3 operations: create, wait and signal. In semaphore implementation for iOS the wait operation can be requested with a timeout to limit how much we want to wait to resource to become free. I advise to always provide a timeout so that the threads don’t become blocked.

To create the semaphores we can use the code below:

// Swift
let semaphore = DispatchSemaphore(value: 2)

// Obj-C
dispatch_semaphore_t semaphore = dispatch_semaphore_create(2);

Now, if we want to wait and signal we can use the operations below:

// Wait - Swift
semaphore.wait(timeout: .now() + 5)
// Wait - Obj-C
dispatch_semaphore_wait(semaphore, dispatch_time(DISPATCH_TIME_NOW, (int64_t)(5.0 * NSEC_PER_SEC)));

// Signal - Swift
semaphore.signal()
// Signal - Obj-C
dispatch_semaphore_signal(semaphore);

Serialising callback completion

While dealing with some async APIs that take completion handlers I’ve run in to a problem where I need to wait for the execution of that API call to complete so that I can continue with the execution of my program. I didn’t want to end the function that is currently running and I used semaphores to wait for the async API to complete.

This has proven very useful to me when I work on iOS App Extensions that run in the background and that have very limited time of execution. While dealing with UNUserNotificationCenter that provides async operations this technique helped me a lot. So, without further ado, let’s go to the example.

In the code below I have a function that takes another function as a parameter and runs it after the work is completed. This is just a simulation of what other real-world APIs provide.

func doSomethingAndNotifyMe(via completion: @escaping () -> Void) {
    DispatchQueue.global().async { // some work is being done here :)
        sleep(3)
        completion()
    }
}

I will use doSomethingAndNotifyMe in the example below to see what happens and how my code executes:

print("1. Starting the work")

doSomethingAndNotifyMe {
    print("2. Work done")
}

print("3. End of the work")

After running the example above, I get this output:

1. Starting the work
3. End of the work
2. Work done

You can see that the output messages are not in the order I want them to be, they are ordered as 1, 3, 2 and I want the order to be 1, 2, 3. To have the order that I want I will introduce semaphore to the example above:

print("1. Starting the work")
let semaphore = DispatchSemaphore(value: 0)

doSomethingAndNotifyMe {
    print("2. Work done")
    semaphore.signal()
}

semaphore.wait(timeout: .now() + 5)
print("3. End of the work")

When I run the example with the semaphore I get the output that I want:

1. Starting the work
2. Work done
3. End of the work

You can see that I initialised the semaphore with the value 0. This is not a practice that is commonly seen and I like to think of this type of a semaphore as a blocking semaphore. You can think of it as using a lock where the default state of the lock is locked.

Wait operation can be dangerous so don’t use it on the main thread and always try to provide the timeout for it.

Although this might not be the best practice for this kind of situations it has really proven to work great. A modern alternative to using semaphores for examples like this is using DispatchGroup API from the Dispatch library. DispatchGroup is only available on Apple platforms while semaphore implementations are available for almost every platform.

Have you used semaphores in your projects or any other mechanisms for dealing with multi-threaded environments? Please share your experiences and thank you for reading this article.

Using Network Link Conditioner to simulate bad network conditions on iOS and macOS

Tarik Dahic — Thu, 04 Nov 2021 19:53:57 +0000

Network Link Conditioner is a network utility tool provided by Apple that can simulate various network conditions and help us to develop better apps. If you ever received a bug report where user mentioned slow network connection the Network Link Conditioner will help you to reproduce that issue.

We are always on the go, using our mobile devices in different places with different network conditions and we need to adjust the apps that we develop for that conditions. For example, the elevators are ruthless, somehow the app that I work on has always issues with them! 😀

Installation

Network Link Conditioner is available on iOS and macOS and in this article I will cover how to install and use it on both platforms.

iOS

To enable Network Link Conditioner on iOS device you will need to enable that device for development. You can do that by connecting and building the app directly to your device. If your device is not enabled for development, Xcode will do that before building and installing your app.

The other option is to go to Window → Devices and Simulators in Xcode and from there select your device and enable it for development.

Inside the Settings app you will now have a Developer section and inside that section you will be able to use Network Link Conditioner.

macOS

You will need to go to more downloads page on the Apple Developer portal to and search for appropriate Additional Tools for your Xcode version. This link will take you directly to those search results. Download the dmg file, open it, and inside Hardware folder you will find the file called Network Link Conditioner.prefPane.

Double click on it to install it and when the installation is completed you can open the Network Link Conditioner by going to the Settings app and at the bottom of the window you will find it.

How to use

Network Link Conditioner comes with a lot of presets that you can use like 3G, Edge, Very Bad Network, LTE, 100% Loss and more. They are great for testing your app on bad network conditions and in most cases you will not need to create custom presets (profiles).

To use it, pick a preset and just flip the switch to enable it. It is that easy, but don’t forget to turn it off after you are done with testing because it is applied on the entire system.

Every preset has following:

Downlink bandwidth, packet drop rate and delay in ms
Uplink bandwidth, packet drop rate and delay in ms
DNS Delay

By tweaking these attributes you can simulate a lot of different network conditions.

Edge is a great preset to see how your app behaves on very slow networks. Very Bad Network preset is great when you want to test that you have connection to the Internet but that it is very unreliable.

I am working with VoIP and I have found that custom profile with 60% packet loss in both directions is very great for testing reconnection and recovery mechanisms.

If you are using iOS Simulator you will need to install the Network Link Conditioner on macOS and apply it to entire system. This will affect the connection of your entire macOS.

Here’s a little trick that I use for uploading. When I need to upload a large file and I don’t want to make my home network unusable I just turn on Network Link Conditioner with custom profile that limits my upload speed. It is configured like this:

Network Link Conditioner is a very useful tool and if you are not using it to test your apps your users might suffer! If you have any questions, please post them in the comments below.

Build iOS apps from the command line using xcodebuild

Tarik Dahic — Wed, 27 Oct 2021 18:06:46 +0000

At some point in your iOS development career you will want to automate app building and distribution when there are new changes on your version control system. At the company I work for we did just that - whenever a pull request is merged our CI/CD system is notified and it starts to build and test the app with the newest changes. The successful builds are then deployed to QAs and they are ready for manual testing and verification. This can save you a lot of time in your development workflow. In this article I will go through the process on how to create .ipa file from your project that is ready for testing or distribution using only terminal.

Tools

You will need to have Xcode Command Line Tools installed on the machine that will be building the app. If you already have Xcode it is very likely that you have Xcode Command Line Tools installed. Specifically, we will be using the xcodebuild tool . To see if you have it installed you can run:

xcodebuild -help

If you have Xcode and don’t have this tool you can install it by running this in the terminal:

xcode-select --install

Or you can download the command line tools from developer.apple.com.

Building

Building iOS apps is a two step process. First we compile and link the compiled code using archive step and then we export and sign that archive to create the .ipa file.

Choosing what to build

Open the terminal and navigate to the root of the folder of your project. We need to know what will we build so let’s see what options we have:

# If you are using Xcode project:
xcodebuild -list -project <project-name>.xcodeproj
# or if you are using Xcode workspace:
xcodebuild -list -workspace <project-name>.xcworkspace

You should get information about available targets, build configurations and schemes. Schemes contain data about which targets and configurations to use when building so remember what scheme you want to use.

Clean

Before building anything that will be distributed internally or externally I always like to perform clean operation. You can do that via xcodebuild like this:

xcodebuild clean

Export

In export step we need to decide how are we gonna distribute the .ipa file that we will generate and we need to sign it with distribution certificate. If you already archived and exported the app from your computer using Xcode you have the distribution certificate in Keychain and you will be able to complete this step. If you don’t have the distribution certificate you can generate a new one or you can export existing one from your development computer and import it into the computer that will be doing the export step.

We can run the export operation with the command below:

xcodebuild -exportArchive -archivePath <path-and-name-for-archive-from-the-previous-step>.xcarchive -exportOptionsPlist exportOptions.plist -exportPath <path-where-ipa-file-will-be-saved>

The export options plist file plays an important role in this step. It is an xml formatted file that contains all the necessary information for xcodebuild so that the .ipa file can be generated.

Export options

If you don’t know how to generate your export options plist file you can see how Xcode does it for your app. For example, archive the app inside Xcode and then proceed with exporting it from the Xcode Organizer. Choose Ad-Hoc distribution and export it wherever you like. Navigate to the folder where your app .ipa file was exported and in it you will find the ExportOptions.plist file that Xcode internally generated. This could be a great starting point for manually building your apps because we can use that file for builds from command line.

This is how the export options file looked for one of my apps:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>compileBitcode</key>
    <true/>
    <key>destination</key>
    <string>export</string>
    <key>method</key>
    <string>ad-hoc</string>
    <key>signingStyle</key>
    <string>automatic</string>
    <key>stripSwiftSymbols</key>
    <true/>
    <key>teamID</key>
    <string>YOUR_TEAM_ID</string>
    <key>thinning</key>
    <string>&lt;none&gt;</string>
    <!-- If you need to provide provisioning profiles you can do it like this: -->
    <key>provisioningProfiles</key>
    <dict>
        <key>APP_IDENTIFIER</key>
        <string>Ad Hoc Distribution</string>
    </dict>
    <!-- I didn't need to provide provisioning profiles for this app 
         because its signing style is set to automatic -->
</dict>
</plist>

There are a lot of more options which you can find by running xcodebuild -help.

Export method

Documentation for export method from xcodebuild:

Describes how Xcode should export the archive. Available options: app-store, validation, ad-hoc, package, enterprise, development, developer-id, and mac-application. The list of options varies based on the type of archive. Defaults to development.

Mostly used ones for iOS are:

app-store: Generates an .ipa signed with your distribution certificate that is ready for production or deploying to TestFlight.
ad-hoc: Generates an .ipa signed with Ad-Hoc distribution certificate which will enable users that have their device identifiers registered in your Developer portal to install the app.
enterprise: Generates an .ipa signed with your Enterprise Distribution certificate which will enable you to distribute the app in your organisation. For this option you need to have Enterprise Apple developer account.
development: Generates an .ipa signed with your Development certificate which will enable your account members to install and use the app.

At the company I work for we use Ad-Hoc export method for distributing apps to our QAs and we use enterprise export method for sending custom builds with debug options so that we can resolve tricky issues.

Building with different versions of Xcode

In some cases we need to build apps with different version of Xcode. This might happen when a new Xcode with new iOS version and SDK is announced but there are some breaking changes that will take some time to fix. To build the app with an older Xcode version we need to change what Xcode our command line tool uses.

To see the current Xcode path we can enter this command:

xcode-select -p

To change the path to custom version of Xcode we can enter this command:

xcode-select -switch <path>

where <path> is the path to Xcode.app package.

If you want to verify that correct version is being used by command line tool you can use this command:

xcodebuild -version

Issues that can happen

There might be an error with unverified .framework files and to fix this issue, this command should be entered before the build process:

sudo spctl --master-disable

Deploying and installing

Now that you have the .ipa file, you can upload it to App Store for production and TestFlight or you can distribute it to your organization or QAs.

Uploading to App Store

You can upload the generated .ipa file to App Store from terminal or using the Transporter, an app from Apple that is made for uploading builds.

Uploading from the command line can be done using xcrun altool. To read more about it you can run man altool and get the manual for using it. Example for uploading the app to the App Store using this tool coud look like this:

xcrun altool --upload-app --type ios --file <path-to-your-package-ipa> --username <user-name> --password <app-specific-password>

You need to provide the altool with username and app specific password. The username is your Apple ID and app specific password can be generated in App Store Connect for this app to authorize it.

Installing to devices

This procedure depends on the operating system that the person who wants to install the app is using. The prerequisite for this step is to connect your iOS device to the computer.

macOS users can use Apple Configurator 2 which is an app from Apple. This is my preferred way of installing the apps via macOS.
Linux users can use ideviceinstaller which I tested and it worked great.
Windows users can use iMobileDevice builds for Windows. I haven’t tested this approach but after researching it a bit it seems to work good.

Distributing to your organisation

If you have the Enterprise Apple Developer account the best way to distribute the apps is by using the manifest file that Xcode can generate for you when you export the app via Xcode. You can use that manifest file to host the .ipa on some web server and allow the users of your organisation OTA updates.

Manifest can also be generated when you use xcodebuild. This is what the documentation says:

manifest : Dictionary

For non-App Store exports, users can download your app over the web by opening your distribution manifest file in a web browser. To generate a distribution manifest, the value of this key should be a dictionary with three sub-keys: appURL, displayImageURL, fullSizeImageURL. The additional sub-key assetPackManifestURL is required when using on-demand resources.

This is a really great way to ease the app installation for enterprise users.

Conclusion

Although you might never need to build your apps manually from the command line because there are great tools like fastlane and bitrise it will be very beneficial to understand what happens under the hood. When things go wrong you will have the knowledge to fix the issues that happen by automating app building.

By knowing this you can even create your own CI/CD tool. Add a git hook to run tests and builds for your app in a script that contains the contents of this post, expose the generated .ipa file via some web server and you have a great in-house solution!

I hope that this article has helped you to understand how the build process for iOS apps work. If I forgot to add something or made a mistake somewhere please let me know in the comments!

The Holy Grail of UIKit: Delegate Pattern

Tarik Dahic — Wed, 20 Oct 2021 19:15:00 +0000

When I started learning to develop apps for iOS I stumbled upon the delegate pattern for the first time. Adopting UITableViewDataSource and UITableViewDelegate protocols felt very strange and confusing.

Why am I doing this? Is this really how to do these things? I asked myself.

After a couple of weeks of learning and reading materials, I clicked and really started to enjoy using this pattern.

What is it?

According to Apple:

Delegation is a simple and powerful pattern in which one object in a program acts on behalf of, or in coordination with, another object. The delegating object keeps a reference to the other object—the delegate—and at the appropriate time sends a message to it. The message informs the delegate of an event that the delegating object is about to handle or has just handled. The delegate may respond to the message by updating the appearance or state of itself or other objects in the application, and in some cases, it can return a value that affects how an impending event is handled. The main value of delegation is that it allows you to easily customize the behavior of several objects in one central object.

This is a very good definition. But let’s take it step by step by following the illustration below.

Someone creates a Worker. A Worker is someone who does the work and then notifies us when the work is completed or when something is needed to continue the work.
We tell the worker: “This is your delegate. Ask it for something or notify it when you are done.”. That depends on the language that is known between the worker and its delegate. This is always known upfront.
The Worker starts to work.
While the Worker is working it needs some data to continue its work. The worker asks its delegate “How should I do this or that?” and the delegate knowing what the worker needs provides it. When the Worker finishes the work it can tell its delegate “I finished the work and here are the results!”.

This is how the delegate pattern works. The communication flow is always 1-to-1 between the delegate and the worker.

The worker is always doing the same job, but by providing different data and reacting differently on work completions we can reuse the worker in a lot of places where we need to handle the different cases.

Delegation works great when there is a clear relationship between the owner and the “Worker”. For other cases, you will want to resort to other patterns.

I would also like to repeat that the worker knows what to send or request from the delegate.

Translating this into code

After we’ve covered the basics with the theory we will try to translate this into code. I will be using Swift to implement this pattern.

Define the protocol

We should always start with the delegate protocol, the interface or the language that will the delegate adopt and that the worker will know in advance.

protocol WorkerDelegate: AnyObject {
    func didFinishWork()
}

I declared WorkerDelegate protocol that has one method for this example and that is didFinishWork(). When the worker completes the work it will use the delegate that has conformance to WorkerDelegate protocol and will call the didFinishWork() method on it.

AnyObject

You can notice that the WorkerDelegate protocol conforms to another one and that is AnyObject. We use AnyObject to limit that only class types can inherit our delegate protocol. Only class objects can be weak because they are passed by reference and we want weak delegates so that we don’t create retain cycles while using delegates.

Define the worker

class Worker {
    weak var delegate: WorkerDelegate?

    func startWork() {
        // Start some work..
        //
        //
        // .. and when it is completed, notify the delegate:
        delegate?.didFinishWork()
    }
}

The Worker class has a property delegate that is of type WorkerDelegate. It has a weak reference to something that will be stored in this variable and that is, as I mentioned above to avoid creating potential retain cycles. The delegate is also optional so by default it is nil. This is useful in some cases where setting the delegate is not mandatory.

The Worker has a startWork() method that will start some work and when the work is completed it will notify its delegate by invoking the didFinishWork() method if the delegate is set.

Create the worker and adopt the WorkerDelegate

class ViewController: UIViewController {

    private let worker = Worker()

    override func viewDidLoad() {
        super.viewDidLoad()

        // It is always important to set the delegate before we invoke the worker to start doing something.
        // Better alternative could be to pass the delegate in the initializer of the Worker.
        worker.delegate = self

        worker.startWork()
    }
}

extension ViewController: WorkerDelegate {

    func didFinishWork() {
        // Worker finished the work. Now we can react to it by fetching some data or updating the UI.
    }
}

The ViewController has a worker property. In the viewDidLoad() lifecycle method of the ViewController, we set the delegate of the worker to self, so that when the worker is done it will notify the ViewController instance. After setting the delegate, we invoke the startWork() method of the worker and we wait for it to complete to notify us via the didFinishWork() method that we conformed to via WorkerDelegate.

I always like to conform to different protocols in the extensions of the classes because it improves the organisation and the readability of the code.

Examples from UIKit

While working with UIKit we use delegates on daily basis so this is why it is very important to understand this pattern. A good tip for you is when you need to conform to some delegate protocol is to open the protocol definition and see what it has to offer.

Here are a couple of examples:

UITableViewDataSource

We use UITableViewDataSource to provide the UITableView with data. A data source object responds to data-related requests from the table. The minimum for every UITableView that we need to do is to provide it with the numbers of rows per section and to provide UITableViewCell for every row. We do that by implementing methods from the UITableViewDataSource protocol:

// Return the number of rows for the table. We'll assume that the table has only one section.
func tableView(_ tableView: UITableView, numberOfRowsInSection section: Int) -> Int {
   return items.count
}

// Provide a cell object for each row
func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell {
   // Fetch a cell of the appropriate type
   let cell = tableView.dequeueReusableCell(withIdentifier: "cellTypeIdentifier", for: indexPath)

   // Configure the cell using items[indexPath.row]

   return cell
}

In this example we can see how the UITableView asks us (the data source delegate) for data that it will display.

UITableViewDelegate

With UITableViewDelegate we can react to some interactions with the UITableView. In the example below we can override the didSelectRowAt delegate method so that we get notified when user presses the UITableView row.

func tableView(_ tableView: UITableView, didSelectRowAt indexPath: IndexPath) {
    // React to the selection of the cell at the indexPath
}

UITableViewDelegate can also be used for more advanced UITableView customization.

MFMailComposeViewControllerDelegate

If we want to use native system UI and configuration to send an email we can use MFMailComposeViewController. We will create the instance of MFMailComposeViewController, configure it, adopts its delegate and send the email. The email completion will be delegated to us in the delegate method below that we implemented by overriding MFMailComposeViewControllerDelegate:

func mailComposeController(_ controller: MFMailComposeViewController, didFinishWith result: MFMailComposeResult, error: Error?) {
  // React to mail sending completion
}

From here we can see if the email sending was successful or not and react according to that information.

UIImagePickerControllerDelegate

If you want to use some images or videos from the Photos app you possibly implemented UIImagePickerController and conformed to its protocol so that you know when the user picked the media files.

func imagePickerController(_ picker: UIImagePickerController, didFinishPickingMediaWithInfo info: [UIImagePickerController.InfoKey : Any]) {
  // Use picked images or videos
}

Conclusion

The delegate pattern is very popular in the iOS world and it is very present in UIKit. I like this pattern and I use it in my work but it has some limitations. The communication is always 1-to-1 and that is not practical in some cases so we need to resort to something like an Observer pattern. The amount of code that needs to be added is not small if we are developing something trivial and the testing is harder.

Alternative to using delegates can be passing functions to “Workers” and invoking them when we need something or when we want to notify someone. This can result in fewer lines of code but can complicate things if we overuse it. We would also need to be careful not to create retain cycles with this approach.

I hope that this article helped you to understand or to strengthen your knowledge with this pattern.