It basically means that reading and writing on a property will happen in an atomic way (one operation), then preventing reading outdated values when a writing is occurring and so on.

// A wrapper for values in order to make their reading/writing atomic
final class Atomic<Value> {
    private let queue = DispatchQueue(label: "my.queue.name")
    private var _value: Value

    init(value: Value) {
        self._value = value
    }

    var value: Value {
        return queue.sync {
            self._value
        }
    }

    func mutate(_ transform: (inout Value) -> Void) {
        queue.sync {
            transform(&self._value)
        }
    }
}

• Source: atomic variables - objc.io

Recently I read this post Software development topics I’ve changed my mind on after 6 years in the industry - Blogomatano and even though I didn’t agree with all the points in there, it did motivate me to write my own collection of opinions regarding software development in general. These are a collection of my opinions, you can agree or disagree with and that's ok.

General

• A good software engineer needs to understand/care for the business and user needs to solve problems in an efficient way.
• It’s 100% better to solve the right problem with a less optimal solution, than to have a 100% technical perfect solution for the wrong problem.
• Developers should talk to users as much as possible in order to understand their main pain points and test their solutions “on the field”.
• Build less features and increase the quality of the ones you have.
• Writing is a very important skill to a developer and we need the most practice.
• When presenting ideas, one of the most effective methods I know is to present them in a “story-telling” way. The delivery may sometimes be more important than the content itself.
• When you read other people's code or your past code you will always find flaws and that’s ok, we are all continuously learning.

Craftsmanship

• Writing code requires craftsmanship. Code that shows little care in the small things it's very likely to not be optimal for the big things.
• Linters are essential in projects that involve multiple developers and when there is a lot of developer rotation. They prevent small avoidable mistakes that will compound and make code bases a mess.
• Writing detailed explanations on commits/PRs and code is essential to understand the context in the future for any code that you write. When relevant this context must be provided as code comments as well.
• Understandable code is 100% better than "smart" code, this often ties as explicit code is better than overly-abstract code.
• Always share your learning with others, by any means you feel comfortable with.

System Design

• System design is a very important and under looked skill when it comes to development.
• System design means you think on the whole system when adding/changing features and how those changes affect the whole system.
• For a given piece of UI, the least states that UI can be in, the more easy is to reason about it.
• Writing a higher level documentation with diagrams and so on is something that software developers should do more often.

iOS Specific

• Writing iOS code that is close to the system is way better than writing “fancy” architectures just for the sake of it.
• Developing iOS apps that support most system features: Dark Mode, dynamic type, split screen on iPad, etc. leads to more robust apps overall.
• Subviews should not be declared in view controllers instances, they should be created in custom view types to make the UI “stupid” as it should be a reflection to the state. Defining UI inside a view controller contributes to massive view controllers and poor UI implementations.
• For an iOS developer is important to have a passion for UI and UX, trying to find the best experiences possible for users.
• Implementing a robust design system library is the best way to ensure your UI is consistent and easy to build.
• UI interactions must be the closes to the default apple guidelines, doing custom things should always be a conscious decision with a clear purpose.
• In most cases people use enums they should be using structs, they allow for customization and can be used with a similar syntax to enums.
• Doing cheap discovery prototypes is essential for learning and being an effective developer.
• UI should be able to be invoked from a vacuum (no networking, no tracking), just simple views and simple data passing. Then it's easier to test that UI in multiple contexts: iPhone, iPad, dark mode, different language, different accessibility settings, etc.

I will probably update this list if something important comes to my mind.

You can comment bellow if you want me to elaborate more on a certain points, some of them may deserve their own post.

Integrating with Swift projects which use 'use_frameworks!' in the Podfile

ios - Why do we use use_frameworks in CocoaPods? - Stack Overflow

CocoaPods 1.5.0 — Swift Static Libraries - CocoaPods Blog

Cocoa Touch Frameworks

They are always open-source and will be built just like your app. (So Xcode will sometimes compile it, when you run your app and always after you cleaned the project.) Frameworks only support iOS 8 and newer, but you can use Swift and Objective-C in the framework.

Cocoa Touch Static Libraries

As the name says, they are static. So they are already compiled, when you import them to your project. You can share them with others without showing them your code. Note that Static Libraries currently don’t support Swift. You will have to use Objective-C within the library. The app itself can still be written in Swift.

A SwiftUI view that represents a UIKit view controller can define a Coordinator type that SwiftUI manages and provides as part of the representable view’s context.

You can use this coordinator to implement common Cocoa patterns, such as delegates, data sources, and responding to user events via target-action.

import SwiftUI
import UIKit

struct PageViewController: UIViewControllerRepresentable {
    var controllers: [UIViewController]

    func makeCoordinator() -> Coordinator {
        Coordinator(self)
    }

    func makeUIViewController(context: Context) -> UIPageViewController {
        let pageViewController = UIPageViewController(transitionStyle: .scroll, navigationOrientation: .horizontal)
        return pageViewController
    }

    func updateUIViewController(_ pageViewController: UIPageViewController, context: Context) {
        pageViewController.setViewControllers([controllers[0]], direction: .forward, animated: true)
    }

    class Coordinator: NSObject {
        var parent: PageViewController

        init(_ pageViewController: PageViewController) {
            self.parent = pageViewController
        }
    }
}

UIViewRepresentable
UIViewControllerRepresentable
NSViewRepresentable
NSViewControllerRepresentable

UIHostingController

Source: Interfacting with UIKit - Apple

For a given file A.m we want to create a file A.swift to replace it:

1. Create A.swift with the right properties and intializers
2. Port methods (from private utility methods to public ones*)
   1. write the swift version of method foo in A.swift, not necessarily improving the code, but just translating it from objc to swift
   2. remove foo in A.m
   3. stage new method in swift change and deleted lines only in A.m
   4. commit changes: Converting foo to swift
   5. undo removal of foo in A.m
   6. move to the next method
3. Replace usages of A.m for A.swif in the source code (and commit)
4. Remove A.m and A.h from the project
5. Fix any remaining compile error
6. Improve the current existing swift code and commit changes by one

Then reviewing the changes will be way easier by commit, as only the relevant conversions are set.

*: start with the private methods that don’t depend on other methods

• Source: https://medium.com/@isahkaren16/testing-timer-based-features-in-swift-5ecaa4bb0c73

class MockTimer: Timer {
    var block: ((Timer) -> Void)!

    static var currentTimer: MockTimer!

    override func fire() {
        block(self)
    }

    override open class func scheduledTimer(
        withTimeInterval interval: TimeInterval, repeats: Bool, block: @escaping (Timer) -> Void
    ) -> Timer {
        let mockTimer = MockTimer()
        mockTimer.block = block
        MockTimer.currentTimer = mockTimer
        return mockTimer
    }
}

source: ios - How to debug who is eating my touches in UIKit? - Stack Overflow

Sometimes some fixes are needed only for test targets

if ProcessInfo.processInfo.environment["XCTestConfigurationFilePath"] != nil {
    // Code only executes when tests are running
}

Source: https://stackoverflow.com/a/29991529/611678

On the terminal

defaults write com.apple.dt.Xcode ShowBuildOperationDuration YES

Source: rockthebruno

Take a look at

• Writing new Encoders and Decoders - Using Swift - Swift Forums

• GitHub - Flight-School/Codable-DIY-Kit: A template for creating your own Swift Codable encoders and decoders

• Objc.io - Building a Custom XML Decoder

• Guide to Swift Codable - Chapter 7

Add the following code to your AppDelegate:

NSSetUncaughtExceptionHandler { exception in
    print(exception)
    exception.callStackSymbols.forEach({ print($0)} )
}

• Source: StackOverflow