Mobile Dev Diary

Say hello to the Apple's new Liquid Glass design

Tue, 17 Jun 2025 00:00:00 +0000

At this year’s WWDC, Apple introduced a major visual update the “Liquid Glass” design - a dynamic new material arriving with iOS 26. Yes, you read that right: all the rumours were true, and we’re jumping straight from iOS 18 to iOS 26.

How do I feel about the new design? Honestly, I like it. I did a small side by side comparison using Simulator between iOS 18 and iOS 26. The new look speaks to me more. It feels more modern…

WWDC25 - New possibilities have arrived!

Mon, 16 Jun 2025 00:00:00 +0000

New possibilities have arrived! 🛬

This year, Apple released 14 new beta frameworks, bringing powerful tools for product builders to craft outstanding features.

As the platform grows, so does its complexity. Don’t worry! You don’t have to master all of them at once (most you may never even use). Instead, focus on understanding each framework’s core purpose. This will broaden your awareness of available tooling and help you later assess which framework you need to solve a given problem - you can dive deeper when the need comes.

Will enter foreground or won't?

Tue, 03 Jun 2025 00:00:00 +0000

Intro

All across iOS dev blogs and posts you read about AppDelegate being deprecated in the next major iOS release.

AppDelegate has been a go-to for app lifecycle handling since iOS 2.
From iOS 13, SceneDelegate lives alongside AppDelegate handling per-scene lifecycle.

Do the methods applicationWillEnterForeground and sceneWillEnterForeground actually behave the same?

Difference 1 - App-wide vs per-scene calls

AppDelegate’s will enter foreground
- Fires once when the entire app moves from background to foreground
SceneDelegate’s will enter foreground
- Fires once per scene as each one enters foreground

This behaviour is reflected in each method’s signature (look on arguments) ⤵️

Turning Singleton Usage into Testable Code

Tue, 27 May 2025 00:00:00 +0000

See how you can wrap any singleton behind a protocol to make it injectable and your code fully testable 💯

The blog post shows how to deal with URLSession.shared usage.

The same strategy can be applied to all other singletons in your code!

The problem

Service uses URLSession.shared directly.
Tight coupling makes unit testing impossible without real network calls.

struct PostsAPISerivce {
    func fetchPosts() async throws -> [Post] {
        let url = URL(string: ".../posts")!
        let (data, _) = try await URLSession.shared.data(from: url)
        return try JSONDecoder().decode([Post].self, from: data)
    }
}

In the sections, you’ll get step-by-step guide of making this service testable. These same steps can be applied to all other singletons found in your code.

Swift Concurrency Riddle - TaskLocal

Sat, 17 May 2025 00:00:00 +0000

Intro

If you’re able to solve this, it means you understand TaskLocal really well.

Riddle

Look at the attached code snippet and guess:

What will be printed at each step?
Is the order of prints always the same?

class Riddler {
    @TaskLocal static var message = "Hello"

    static func riddleMe() {
        Self.$message
          .withValue("Bye", operation: {
              print("Print 1: \(Self.message)") // ???
              Task {
                  print("Print 2: \(Self.message)") // ???
              }
              Task.detached {
                print("Print 3: \(Self.message)") // ???
              }
          })
        print("Print 4: \(Self.message)") // ???
    }
}

Riddler.riddleMe()

Hint

Do you want to learn more about TaskLocal and Test Scoping in Swift 6.1 first? - Check out my blog post on “Concurrency-Safe Testing in Swift 6.1 with TaskLocal and Test Scoping” HERE.

Concurrency-Safe Testing in Swift 6.1 with @TaskLocal and Test Scoping

Wed, 07 May 2025 00:00:00 +0000

Today’s example shows a static property providing the current date.

Perfect mechanism when we don’t want to inject it everywhere where it’s used.

How to test it? Check it out ⤵️

Initial setup

let currentDateFormatter: DateFormatter = {
    let formatter = DateFormatter()
    formatter.dateStyle = .short
    formatter.timeStyle = .none
    return formatter
}()

var currentDateFormatted: String {
    currentDateFormatter.string(from: DateEnvironment.currentDate())
}

enum DateEnvironment {
    static var currentDate: () -> Date = Date.init
}

extension Date {
    // 16.04.2025
    static let sixteenthOfApril = Date(timeIntervalSince1970: 1744840515)
}

Old way - XCTest

Override the static property in tests.
Works, but not concurrency-safe (Ok, for XCTest because test ran serially).

class CurrentDateFormatterTests: XCTestCase {
    func test_dateFormatting() { // ✅
        DateEnvironment.currentDate = { .sixteenthOfApril }
        XCTAssertEqual(currentDateFormatted, "16.04.2025")
    }
}

Swift Testing before Swift 6.1

enum DateEnvironment {
    @TaskLocal static var currentDate: () -> Date = Date.init
}

struct CurrentDateFormatterTests {
    @Test
    func dateFormatting() { // ✅
        DateEnvironment.$currentDate
            .withValue({ .sixteenthOfApril }) {
                #expect(currentDateFormatted == "16.04.2025")
            }
    }
}

Why @TaskLocal?

3 Ways to Name Parameters in Swift Parametrised Tests

Thu, 24 Apr 2025 00:00:00 +0000

Mind your argument names in Swift Testing’s parametrised tests!

As a follow up to my recent post on refactoring to use Swift Testing’s parametrised tests, I’m diving into the crucial - yet often overlooked topic of how to name your parametrised test inputs.

Option 1: First Named Tuples

Only the first tuple is named, all others rely on positional matching to (a, b, result).

✅ Minimal boilerplate for small input sets
❌ Readability drops after adding more cases
❌ Easy to mix up arguments position
❌ Hard to scan or extend

func add(_ a: Int, _ b: Int) -> Int {
    a + b
}

...

@Test(arguments: [
    (a: 1, b: 2, result: 3),
    (10, 15, 25),
    (1, -5, -4),
    (-1, -5, -6),
    (0, 0, 0),
    (1000, 1000, 2000),
    (10000, 50000, 60000),
    (-10, -3, -13)
])
func add_returnsCorrectSum(a: Int, b: Int, result: Int) {
    #expect(add(a, b) == result)
}

Option 2: Named Tuples

Every tuple entry explicitly names all its fields (a: …, b: …, result: …) for all cases.

Swift Testing Challange - Can you refactor this?

Thu, 17 Apr 2025 00:00:00 +0000

Intro

Have you already started using Swift Testing instead of XCTest?

I’m curious to see how you can refactor the test function (add_returnsCorrectSum) from the code snippet to use all powers of the Swift Testing framework.

Could you explain what benefits does your refactored version has compared to my original code snippet?

My approach

In both approaches the test gives the same result.

The point is the refactored version uses a Swift Testing parametrised test, and this makes a real difference.

#3 Swift code refactor in action - a sneaky problem hidden in code snippet

Wed, 09 Apr 2025 00:00:00 +0000

Swift code refactor in action 👨🏻‍💻

Take a close look at the validate function. There’s a sneaky problem hidden in this code snippet.

What will the function call return when passed nil?
What problem is hidden here?

First, the guard statement is redundant here. We can simplify the function to ⤵️

func validate(password: String?) -> Bool {
    password?.count ?? 0 > 8
}

There’s no need to wrap password?.count ?? 0 in parentheses since the ?? operator already has higher precedence than >.

Imperative, Functional, Functional Reactive: Do you know the difference?

Tue, 25 Feb 2025 00:00:00 +0000

Paradigms

Imperative

In the imperative approach, we have a sequence of instructions that describe step by step how the program’s state is modified.

Let’s look on the example ⤵️

var value = 0

func increment() {
    value += 1 // Mutating the state
}

print(value) // 0
increment()
print(value) // 1

In the code we have a mutable variable value and a function increment that mutates the state (value). We first print the initial value, then increment it, and finally print the updated value.

Imperative, Functional, Functional Reactive

Sun, 16 Feb 2025 00:00:00 +0000

Do You Know the Difference Between Imperative, Functional, and Reactive Programming?

Test your understanding of imperative, functional, and functional reactive programming with this interactive quiz. These questions cover the key concepts from the main post to help you solidify your knowledge for your next interview.

--- primary_color: green secondary_color: lightgray text_color: black shuffle_questions: false shuffle_answers: true --- # What is functional programming about? 1. [ ] Writing functions that may modify state as needed 1. [x] Avoiding side effects and state mutation 1. [ ] Relying on side effects to manage state transitions 1. [ ] Emphasizing object-oriented design patterns # In functional programming, why must functions avoid side effects? 1. [ ] To improve performance 1. [x] To prevent unpredictable state changes 1. [ ] To enable state mutation 1. [ ] To allow recursion # Which paradigm describes a sequence of instructions that modify the program’s state step by step? 1. [ ] Functional 1. [ ] Functional Reactive 1. [x] Imperative 1. [ ] Declarative # What is considered a side effect in a function? 1. [ ] Returning a computed value 1. [x] Modifying a variable outside its scope 1. [ ] Calling another pure function 1. [ ] Using recursion # How is state typically managed in functional programming? 1. [ ] By mutating global variables 1. [x] By transforming old state into new state 1. [ ] By ignoring state changes 1. [ ] By centralizing state in a single object # Which pattern is used by functional reactive programming? 1. [ ] Singleton 1. [ ] Factory 1. [ ] Delegate and Callback 1. [x] Publisher and Subscriber # What is the primary benefit of using pure functions? 1. [ ] They allow state mutations 1. [x] They are easier to test and debug 1. [ ] They increase code complexity 1. [ ] They require global variables # Examine the code below. Does it fully follow the functional programming principles? ```swift var value = 0 func increment(_ value: Int) -> Int { value + 1 } value = increment(value) print(value) ``` 1. [ ] Yes, it's correct 1. [ ] No, the function has side effects 1. [x] No, it mutates state by reassigning a mutable variable 1. [ ] No, it mutates the "value" variable inside the increment function

Didn’t get the full result? No worries! All the answers are in the blog post HERE

#7 XCTest vs Swift Testing: A modern way of linking bugs

Fri, 13 Dec 2024 00:00:00 +0000

What’s the difference?

In XCTest we relied on the old fashioned simple comments to add more context to our test case e.g link to the bug description.

With Swift Testing, we now have a special bug trait that can be passed to the @Test macro. The bug trait takes a URL String as argument and optionally a title for the bug allowing us to add short description of it. The key advantage over regular comment is that the bug title is visible in the test results. Better yet, tapping on it takes you directly to the related webpage with the bug report.

#6 XCTest vs Swift Testing - Parameterized tests in the fight for more reusable code

Thu, 05 Dec 2024 00:00:00 +0000

What’s the difference?

XCTest doesn’t provide a built-in solution for parameterized tests. To achieve this, we create test cases as structs or tuples, defining test inputs and expected results. Then, we write a loop to iterate through these test cases and execute the necessary assertions.

Swift Testing simplifies this process by allowing tests to be parameterized directly. Using the @Test macro, you can pass test cases as an argument. What’s the benefit? While you still need to define your test cases, the iteration code is no longer needed — Swift Testing handles it for you.

#2 Swift code refactor in action - price $$$

Tue, 03 Dec 2024 00:00:00 +0000

Swift code refactor in action 👨🏻‍💻

Today, let’s talk about refactoring for clarity, maintainability, and scalability!

This time, the scenario is calculating the final price depending on the price and membership status.

This initial code has a few code smells:

1️⃣ nested ifs - impacts general readability, making the code hard to understand,
2️⃣ duplicated conditions - “price > 100” which violates the Don’t Repeat Yourself principle,
3️⃣ lack of scalability - not possible to easily add a new discount, it’d require to rework everything.

Checkout the gif or the post on my website to see how I solve these code smells and make the code cool, clean and scalable!

#5 XCTest vs. Swift Testing - Conditional disabling - when a test needs a nap

Thu, 28 Nov 2024 00:00:00 +0000

Today we check the diff in conditional disabling.

In XCTest there is XCTSkipIf function that takes Bool argument to decide whether a test should run or not.
In Swift Testing there’s “disable” trait accepting Bool argument and behaving like XCTSkipIf from XCTest.

XCTSkipIf - are you surprised this kind of function exists? To be honest - I was

I can admit I learned about it when preparing this post. This already shows how often I’ll be using the Swift Testing version of it, but never say never!

#4 XCTest vs. Swift Testing - Disable tests - handle with care

Wed, 27 Nov 2024 00:00:00 +0000

This week with Swift Testing starts with checking how test disabling differs from XCTest.

In XCTest, Xcode identifies a function as a test only if its name starts with the “test” prefix, so putting e.g. “disabled” instead makes the test inactive. Swift Testing simplifies that approach by introducing the @Test macro with a .disabled trait that you can pass as an argument.

What’s the benefit? You no longer need to modify each test name to disable it. What’s more, you can include context directly within the trait to justify why the test is disabled.

Two types of Swift macros

Tue, 26 Nov 2024 00:00:00 +0000

What is macro?

💡 Macro is a feature that generates code during compilation. Unlike macros in C, which work like “find and replace”, Swift macros are type-safe and context aware, making them powerful tools reducing boilerplate code.

Two types of macros

attached - use @ prefix, tied to a declaration adding extra logic to it, like: @Test, @Model, @Observable
freestanding - use # prefix, standalone code that can be invoked independently as a part of the code, like #expect, #Predicate, #warning

Example of attached macro ⤵️

#3 XCTest vs. Swift Testing - Unwrapping optionals

Thu, 21 Nov 2024 00:00:00 +0000

Optionals are a core of Swift - we deal with them daily, both in production and testing code. Whether you write tests with XCTest or Swift Testing, unwrapping optionals is a common case.

In XCTest there is XCTUnwrap operator.

Swift Testing introduces #require macro.

Is there any difference between them? Not really! Both require the test function to handle exceptions and try keyword before.

Gif ⤵️

Code ⤵️

XCTest

#1 Swift code refactor in action - user profile name

Wed, 20 Nov 2024 00:00:00 +0000

Swift code refactor in action 👨🏻‍💻

Common scenario: formatting user profile name - I bet any of you faced this kind of task.

At first glance, it look straightforward, but when you take a closer look, you’ll notice two potential improvements:

1️⃣ One single return - simplification of the function flow.

2️⃣ Centralised formatting logic - reduces the chance of bugs.

Check out the animated gif and the code where I refactor to address these issues.

#2 XCTest vs. Swift Testing - Has error testing been simplified?

Tue, 19 Nov 2024 00:00:00 +0000

Today we check how testing error has changed in the new framework.

In XCTest, we use XCTAssertThrowsError to check if a specific error is thrown. This assertion comes with the error handler closure where we can perform additional checks like e.g. verifying the exact error type.

With Swift Testing, this process is even simpler, especially when an error conforms to Equatable. We can directly specify the expected error in the expect macro and it automatically checks the type.

#1 XCTest vs. Swift Testing - fresh look on a new testing framework

Thu, 14 Nov 2024 00:00:00 +0000

New Series! XCTest vs. Swift Testing - fresh look on a new testing framework.

Swift Testing was presented at WWDC24 as a new, modern, simplified framework for writing automated tests. It’s a perfect candidate to replace XCTest unit tests, so it’s definitely worth learning.

I haven’t had a chance yet to use Swift Testing in production and the series is my motivation for me to discover it.

Today we cover 2 basic differences ⤵️

TDD with SwiftUI - Triggering API request

Fri, 13 Sep 2024 00:00:00 +0000

Recap

Hello everyone and welcome to the next chapter of the series about SwiftUI code automated testing!

In the previous post we

defined acceptance criteria for the Joke app that we’re implementing
we covered by snapshot tests all UI cases mentioned in the acceptance critieria

That’s what the app looks like ⤵️

Here’s the link to the previous blog post ⤵️ (Worth reading before this one)

Testing SwiftUI Code - The beginning (UI)

Swift Testing parametrized tests

Mon, 12 Aug 2024 00:00:00 +0000

Swift Testing can elevate your unit tests writing 🚀

Hello Apple Developer! I prepared a special post that will help you write better unit tests using the new SwiftTesting framework 🫢

The Swift Testing framework is the successor to XCTest for unit tests. It was introduced at this year’s WWDC24 and is worth learning 📚

One of the main features of Swift Testing are parameterized tests 🧪

Click to learn how to leverage this new feature ⤵️

Insights about Swift Testing Tags

Thu, 11 Jul 2024 00:00:00 +0000

Today, I have a special post about Apple’s new testing framework - Swift Testing! 🤩

Swift Testing was presented at WWDC24 as a new, modern, simplified framework for writing automated tests. It’s a perfect candidate to replace XCTest unit tests, so it’s definitely worth learning 🧑‍🏫

The topic of Swift Testing is quite broad, so I decided to break it down into more digestible parts, starting with Swift Testing Tags. What is this? 🤔

My WWDC 2017 Scholarship submission

Mon, 10 Jun 2024 00:00:00 +0000

Intro

This year’s WWDC is just around the corner, and I decided to write about how I ended up at WWDC in 2017. At that time, I was a computer science student and Apple was organizing Swift Student Challange for which I was eligible for. As a young iOS apprentice, I couldn’t miss this opportunity - I signed up. How did I get there? That’s what I want to share with you today. ⤵️

Testing SwiftUI Code - The beginning (UI)

Thu, 06 Jun 2024 00:00:00 +0000

Intro

Hello everyone and welcome to my first (ever) blog series!

Today, I’m going to begin experimenting with SwiftUI. The mission is to build a small application and having it fully tested 💯. I decided to go for that quest to broaden my knowledge around SwiftUI and verify the rumors that it cannot be tested.

To keep it relatively readable I decided to split it up and we’re going to see how many parts we end up with.

Combine: flatMap, map + switchToLatests (flatMapLatest) demystified

Thu, 11 Apr 2024 00:00:00 +0000

Intro

Combine is a framework made by Apple designed to support us in writing code that could be way more complex if written in an imperative way. It’s often said that with great power comes great responsibility. Therefore, as developers, it’s essential for us to understand how to harness it, so it does not backfire.

Today, we’re going to take a closer look 👀 at a few Combine operators, showcasing their practical application.

Testing SwiftData and the Query property wrapper through an example

Sun, 25 Jun 2023 00:00:00 +0000

We’re just after this year’s WWDC where we had a chance to witness the unveiling of a new persistence framework called SwiftData. Naturally, I couldn’t resist delving deeper into it. One particular topic that caught my attention was the observation of local storage using Query and its testability.

SwiftData

SwiftData makes it easy to persist data using declarative code. You can query and filter data using regular Swift code. And it’s designed to integrate seamlessly with SwiftUI.

Keep your project clean using synx

Thu, 21 Oct 2021 00:00:00 +0000

A tool written in Ruby which can keep your project and a .pbxproj file clean. A valuable ally when solving complex conflicts inside the project file.

Keeping a project file clean during a project life could be tough especially while working in a team, and we conflict our branches from time to time. Solving multiple conflicts in a .pbxproj can lead to mistakes that can cause duplicated references, not removed old references, or files not referenced by a project, but still existing in a project directory. In today’s article, I’ll share my tips on how to deal with described problems pretty easily.

Mon, 01 Jan 0001 00:00:00 +0000

Thanks for reading. 📖

I hope you found it useful!

If you enjoy the topic don’t forget to follow me on one of my social media - LinkedIn, X, Mastodon, Bluesky or via RSS feed to keep up to speed. 🚀

About

Mon, 01 Jan 0001 00:00:00 +0000

My adventure with the iOS platform started over eight years ago. I belong to a generation of developers who started out learning how to create mobile iOS applications in Swift, but I’m also familiar with Objective-C.

During over eight years of work, I’ve created 7 applications in Swift from scratch. The experience allowed me to test many solutions, as well as design patterns (MVC, MVVM, Redux) and frameworks in practice.