Author: Aleksei Pichukov

This article provides a brief overview of techniques that can be used in your mobile iOS application to keep it secure enough for the vast majority of cases. If you are a junior or middle iOS developer and have not given much thought to security topics, this material will provide a great introduction. I will try to explain it simply, so even if you have no prior knowledge of security, you should be able to follow along.

Although Apple has a closed ecosystem, it still has security vulnerabilities. If you thought that iOS takes care of all the security issues and we as developers can do nothing about it — you were wrong. There is one simple evidence for those of you who held this position: Apple regularly releases security updates to close some of the known iOS vulnerabilities. And God knows how many of them are still open and being used by attackers to gain access to personal and important data in the apps that users have installed on their devices.

There is an infinite discussion about the topic of knowing algorithms and data structures for a frontend (in my case, mobile) developer needed only to pass technical interviews in large tech companies, or if there is some benefit of using it in daily work. I think the truth is somewhere in between, as always. Of course, you rarely find a case when you need to implement a min heap or use dynamic programming approaches while working on UI and business logic for a service with a REST API, but having a basic understanding of performance, time, and memory complexity can help make small, simple optimizations in the app that can pay off a lot in the long run.

I want to give an example of such a small optimization and decision-making process that can help us decide whether the extra effort is worth it or not.

In iOS 17, Apple introduced a new Observation framework which provides an implementation of the observer design pattern.

The following is a snippet from the Apple documentation outlining this feature:

This article is designed for developers who strive to maintain a native mobile experience as much as possible. While we all (hopefully) prefer to preserve the native spirit, there are instances when we can't avoid integrating web components into our mobile application. This might be driven by business needs, time constraints, or simply common sense.

Here are a few examples:

Most of the examples Apple provides to demonstrate Dependency Injection in SwiftUI use @Environment. When creating a new project with SwiftData in XCode, you'll notice that the template uses Environment for injecting the modelContext.

struct ContentView: View {
    @Environment(\.modelContext) private var modelContext // <-- 1
    @Query private var items: [Item]

    var body: some View {
        NavigationSplitView {
            List {
                ...
            }
            .toolbar {
                ToolbarItem {
                    Button(action: addItem) {
                        ...
                    }
                }
            }
        }
        ...
    }

    private func addItem() {
        withAnimation {
            let newItem = Item(timestamp: Date())
            modelContext.insert(newItem) // <-- 2
        }
    }

    ...
}

#Preview {
    ContentView()
        .modelContainer(for: Item.self, inMemory: true) // <-- 3
}