Forem: Konstantin Shkurko

App Groups Are Not Secure by Default - Here's How to Fix That

Konstantin Shkurko — Tue, 24 Feb 2026 09:30:00 +0000

If you're building an iOS app with a widget, a Watch companion (that's the watchOS app paired with your main iPhone app), or a Share Extension, you'll eventually need to pass data between processes. App Groups are the standard mechanism for this, and on the surface it looks simple: add the capability, write UserDefaults(suiteName:), and off you go. But that apparent simplicity is exactly what causes problems. Data sits in an unencrypted container, any app from your team can read it, and incoming data validation is almost never done. Let's walk through how to set up App Groups properly, what actually belongs there, what risks exist, and how to organize a secure exchange - including a concrete example of passing an authorization token between an app and a widget.

When You Can't Avoid App Groups

iOS sandboxing is strict: every app lives in its own container, and by default there's no access to neighboring processes' files whatsoever. That's great for security, but it creates an obvious problem the moment you have an ecosystem of multiple targets.

Typical scenarios: the main app and a WidgetKit widget need to display the same data; a Share Extension needs to save received content so the main process can handle it on the next launch; a Watch app wants cached data without hitting the network. In all these cases, App Groups are the only native way to set up a shared container without a server in the middle.

It's important to understand that App Groups aren't about real-time inter-process communication. There are no sockets here, no notifications with guaranteed delivery (well, almost - CFNotificationCenter can do some things, but that's a separate story). App Groups are about shared storage. If you need real-time synchronization, look toward XPC or Darwin Notifications built on top of shared storage.

How to Set It Up and Where Everything Breaks

In theory, setting up App Groups takes a minute. In practice, I've seen plenty of projects where it turned into half a day of debugging due to mismatched provisioning profiles.

It starts in Xcode: Signing & Capabilities → + Capability → App Groups. You add an identifier in the format group.com.yourcompany.appname. Important: that same identifier needs to be added to every target participating in the data exchange - the main app, the widget, the extension.

Xcode automatically updates the target's .entitlements file:

<!-- MyApp.entitlements -->
<key>com.apple.security.application-groups</key>
<array>
    <string>group.com.yourcompany.myapp</string>
</array>

You'd think that's enough. But no - Xcode also needs to update the provisioning profile for each target through the Apple Developer Portal. If you're managing signing manually, you need to go into Certificates, Identifiers & Profiles, find the App ID for each target, and make sure the App Groups capability is enabled there with the right identifier. Then regenerate the profiles.

One of the most common mistakes: the App Group is registered only for the main App ID but not for the Extension. The behavior here is particularly nasty - everything works fine on the simulator (profile checks are more lenient there), but on a real device the data simply doesn't get read, with no errors in the logs whatsoever.

If you have multiple extension targets with different bundle IDs, make sure all of them are added to the group. This has to be done manually in the portal, and Xcode won't warn you about it.

What You Can Share and What You Shouldn't

The App Group shared container provides a URL like /private/var/mobile/Containers/Shared/AppGroup/<UUID>/. You can write anything there: files, SQLite databases, Core Data stores. UserDefaults with a suite name is just a wrapper around a plist file in that same container.

UserDefaults(suiteName: "group.com.yourcompany.myapp") is the simplest way to share small pieces of data. It works well for flags, simple settings, and last-updated timestamps. I try not to put anything larger than a couple hundred bytes in there - not because there's a hard limit (there isn't), but because UserDefaults loads the entire plist into memory at once.

For larger data, it's better to work directly with files. You get the container URL via:

let containerURL = FileManager.default
    .containerURL(forSecurityApplicationGroupIdentifier: "group.com.yourcompany.myapp")

Core Data on top of App Groups works, but requires care. The store needs to be created with a URL inside the container, and if multiple processes might access it simultaneously (say, an extension is writing while the main app is reading), you need to use WAL journal mode and accept that NSPersistentContainer doesn't handle cross-process concurrent access automatically. In practice, for inter-process exchange I prefer atomically-written files, keeping Core Data exclusively in the main process.

What you definitely shouldn't do is store large binary data that gets rewritten frequently in the shared container. Each process holds the file open in its own way, and writes can easily produce a race condition. For safe atomic writes, write to a temp file first, then call FileManager.replaceItem(at:withItemAt:).

The Security Risks Nobody Likes to Talk About

The shared container doesn't get any additional encryption beyond iOS's standard filesystem encryption. Data is protected by the NSFileProtectionCompleteUntilFirstUserAuthentication class by default - meaning it's accessible after the first unlock, which in practice means "almost always."

The main risk that's frequently underestimated: any app signed with the same Team ID and registered in the same group has full read and write access. If your team has multiple apps, they can all potentially read each other's data if they're registered in the same group. That's not a bug - it's a feature. That's exactly why naming your group group.com.yourcompany.shared and dumping data from all your apps in there is a terrible idea.

Another attack vector: if an extension gets compromised (via a vulnerability in its content-handling logic), an attacker can write arbitrary data into the shared container, which the main app will then read and process. That's a classic data injection path. So data that the main app reads from the container should be validated just as strictly as data from a server.

On macOS things are slightly different - App Groups work through ~/Library/Group Containers/, and Gatekeeper adds extra checks. But the risks are conceptually identical.

How to Do It Safely

Rule number one: no raw strings in the shared container. I've seen code where authorization tokens were stored as UserDefaults.standard.set(token, forKey: "auth_token") - in a suite accessible to the widget. If it later turns out another app from the same team is registered in that group, the token leaks without leaving any trace.

Use Codable to structure your data. It gives you a schema, versioning, and the ability to validate:

struct SharedAuthState: Codable {
    let version: Int
    let accessTokenHash: String   // hash only, not the token itself
    let expiresAt: Date
    let isAuthenticated: Bool
}

Notice that the example above stores a hash of the token, not the token itself. The real token should live in the Keychain with kSecAttrAccessGroup, which can also be shared between targets - but that's a much more secure storage with hardware encryption on devices with Secure Enclave.

For data that genuinely needs to be shared in full (say, small cached API responses), it's worth adding encryption on top. A straightforward approach - CryptoKit with a symmetric key from the Keychain:

import CryptoKit

func encrypt(_ data: Data, using key: SymmetricKey) throws -> Data {
    let sealedBox = try AES.GCM.seal(data, using: key)
    return sealedBox.combined!
}

func decrypt(_ data: Data, using key: SymmetricKey) throws -> Data {
    let sealedBox = try AES.GCM.SealedBox(combined: encrypted)
    return try AES.GCM.open(sealedBox, using: key)
}

The key is stored in the Keychain with kSecAttrAccessible = kSecAttrAccessibleAfterFirstUnlock and kSecAttrAccessGroup for sharing between targets. The shared container itself then holds only an encrypted blob - useless without the key.

Validation on read is non-negotiable: check the schema version, check that dates aren't in the past, check that fields aren't nil where they shouldn't be. Don't trust data from the container any more than you'd trust data from the network.

Example: Passing Auth State Between the App and a Widget

Here's a concrete implementation. The goal: the widget needs to know whether the user is authenticated, and display either data or a "sign in" call to action.

First, the model and manager for the main app:

// SharedModels.swift (shared target or copied into both targets)

struct WidgetAuthState: Codable {
    let version: Int
    let isAuthenticated: Bool
    let displayName: String?
    let tokenExpiresAt: Date?

    static let currentVersion = 1

    var isValid: Bool {
        guard version == Self.currentVersion else { return false }
        if isAuthenticated, let expiry = tokenExpiresAt {
            return expiry > Date()
        }
        return true
    }
}

// SharedStateManager.swift

final class SharedStateManager {
    static let shared = SharedStateManager()

    private let groupID = "group.com.yourcompany.myapp"
    private let stateFileName = "widget_auth_state.encrypted"

    private var containerURL: URL? {
        FileManager.default.containerURL(
            forSecurityApplicationGroupIdentifier: groupID
        )
    }

    private var stateFileURL: URL? {
        containerURL?.appendingPathComponent(stateFileName)
    }

    // Encryption key from Keychain
    private func encryptionKey() throws -> SymmetricKey {
        let query: [String: Any] = [
            kSecClass as String: kSecClassGenericPassword,
            kSecAttrService as String: "com.yourcompany.myapp.widgetkey",
            kSecAttrAccessGroup as String: "TEAMID.group.com.yourcompany.myapp",
            kSecReturnData as String: true
        ]

        var result: AnyObject?
        let status = SecItemCopyMatching(query as CFDictionary, &result)

        if status == errSecSuccess, let keyData = result as? Data {
            return SymmetricKey(data: keyData)
        }

        // Generate a new key on first run
        let newKey = SymmetricKey(size: .bits256)
        let keyData = newKey.withUnsafeBytes { Data($0) }

        let addQuery: [String: Any] = [
            kSecClass as String: kSecClassGenericPassword,
            kSecAttrService as String: "com.yourcompany.myapp.widgetkey",
            kSecAttrAccessGroup as String: "TEAMID.group.com.yourcompany.myapp",
            kSecValueData as String: keyData,
            kSecAttrAccessible as String: kSecAttrAccessibleAfterFirstUnlock
        ]
        SecItemAdd(addQuery as CFDictionary, nil)

        return newKey
    }

    func writeAuthState(_ state: WidgetAuthState) throws {
        guard let url = stateFileURL else {
            throw SharedStateError.containerUnavailable
        }

        let key = try encryptionKey()
        let plaintext = try JSONEncoder().encode(state)
        let sealedBox = try AES.GCM.seal(plaintext, using: key)

        guard let combined = sealedBox.combined else {
            throw SharedStateError.encryptionFailed
        }

        // Atomic write via temp file
        let tempURL = url.deletingLastPathComponent()
            .appendingPathComponent(UUID().uuidString)

        try combined.write(to: tempURL, options: .atomic)
        _ = try FileManager.default.replaceItemAt(url, withItemAt: tempURL)
    }

    func readAuthState() -> WidgetAuthState? {
        guard
            let url = stateFileURL,
            let encrypted = try? Data(contentsOf: url),
            let key = try? encryptionKey(),
            let sealedBox = try? AES.GCM.SealedBox(combined: encrypted),
            let plaintext = try? AES.GCM.open(sealedBox, using: key),
            let state = try? JSONDecoder().decode(WidgetAuthState.self, from: plaintext),
            state.isValid
        else {
            return nil
        }

        return state
    }
}

enum SharedStateError: Error {
    case containerUnavailable
    case encryptionFailed
}

In the widget, call readAuthState() inside getTimeline or getSnapshot. The main app calls writeAuthState() on login/logout and whenever the token is refreshed.

A few details worth noting. First, the kSecAttrAccessGroup for the Keychain item is different from the App Group identifier - it follows the format TEAMID.identifier. Second, the atomic write through a temp file protects against the widget reading the file mid-write while the main app is in the middle of updating it. Third, isValid on the reader's side isn't an optional nicety - it's mandatory.

Testing and Debugging

The simulator works with App Groups, but there are quirks. The shared container on the simulator lives at ~/Library/Developer/CoreSimulator/Devices/<DeviceID>/data/Containers/Shared/AppGroup/. The easiest way to find it is print(FileManager.default.containerURL(...)) on first run. It's useful to have that folder open in Finder and watch the files in real time - I often keep a Terminal with watch -n1 cat widget_auth_state.encrypted | xxd | head running while debugging.

There are a few ways to reset App Group data on the simulator. The nuclear option is xcrun simctl erase <DeviceID>, which wipes the entire simulator. More surgical: delete the folder with the relevant UUID manually. If you're working with multiple simulators, keep in mind that each one has its own container, even if the app bundle IDs are identical.

A common problem on first launch of an extension: the group container doesn't exist until one of the apps in the group has accessed it. containerURL will return a URL, but no files will have been created there yet. Always check that the directory exists before writing:

if let url = containerURL {
    try FileManager.default.createDirectory(
        at: url, 
        withIntermediateDirectories: true
    )
}

Debugging on a real device is trickier - you don't have direct filesystem access. Use os_log and Console.app, or temporarily add the file hash directly to your widget's UI. Instruments with the File Activity template lets you see which process is touching the container files and when.

One more thing that's burned me before: when you regenerate a provisioning profile, the container UUID can sometimes change. That means all the data in the old container becomes inaccessible. Graceful degradation when data is missing isn't optional - it's required. The widget must handle nil from readAuthState() gracefully, showing a "not authenticated" state or a placeholder.

Wrapping Up

App Groups are a powerful mechanism that's easy to use insecurely. The key takeaways: use the Keychain for encryption keys and sensitive data, encrypt what you put in the shared container, always validate what you read back, make writes atomic, and build in graceful degradation. Complexity grows non-linearly with the number of targets - the sooner you encapsulate your shared state logic into a dedicated module with clean interfaces, the less pain you'll have down the road.

The Dead Don't Bite, But They Glow: How Find My Works in iOS in 2026

Konstantin Shkurko — Sat, 07 Feb 2026 09:12:49 +0000

You'll learn how the magic of Find My actually works: from the hardware tricks of the power controller to post-quantum encryption algorithms. We'll break down why a "dead" iPhone is just an illusion for the user, how mathematics protects your coordinates from Apple itself, and why your smartphone turns into a cryptographic beacon when the screen goes dark. This article will be interesting for developers, security specialists, and anyone who wants to understand the real capabilities (and limitations) of modern electronics.

It's amusing to watch users' faces when they learn that their iPhone 17, which "died" from a depleted battery three hours ago, is still actively communicating with the outside world. For most people, this looks like black magic; for the paranoid, it's a reason to wrap their gadget in foil. For us, though, it's an elegant engineering case where the most efficient crowdsourced network in history was born at the intersection of microampere power consumption and asymmetric cryptography.

Power Reserve Mode: Death Is Just the Beginning

Let's start with the fact that "off" is a flexible concept. In 2026, an iPhone doesn't completely power down as long as the chemical processes in the lithium-ion cells are capable of delivering current at all. When you see the empty battery icon, the system forcibly shuts down iOS and the main processor (Application Processor), but leaves a "power reserve" for critical subsystems.

This mode is called Power Reserve. The smartphone transforms into a very expensive and technologically advanced AirTag. The main consumer here is the Bluetooth LE (Low Energy) chip and its accompanying Always-on Processor (AOP).

Why not shut everything down to preserve battery resources? The answer is simple: Find My has become part of the Safety system. Apple bet that the ability to find a stolen or lost device within 48-72 hours after its "death" is more important than the extra 0.5% charge that might save you from deep discharge.

Hardware: Who Doesn't Sleep When Everyone Sleeps?

Architecturally, this is implemented through power domain separation. While the monstrous A-series chip (main processor) is in the deepest sleep, the PMIC (Power Management IC) continues to supply voltage to:

Secure Enclave (SEP) - the heart of security, where your keys reside.
Bluetooth LE controller.
U2/U3 chip (Ultra Wideband) - for precise nearby finding.

In 2026, advertising intervals have become adaptive. If the accelerometer (which also runs in micro-mode) realizes the device is stationary, the frequency of "broadcasts" into the air drops to once every few minutes. As soon as the device is moved, the frequency increases. This allows the "corpse" to stay alive for three days.

The Mathematics of Privacy: Why Apple Is Blind

The most common myth: "Apple sees where I am." In reality, Find My's architecture is built so that even under torture, engineers in Cupertino couldn't decrypt your device's coordinates on their servers.

Key Generation

Your iPhone doesn't broadcast its serial number or Apple ID. That would be too easy for tracking. Instead, it uses a Rotating Public Keys mechanism. Every 15 minutes (or so), the device generates a new public key $K_{pub}$ based on a master key that never left your device's Secure Enclave during initial setup.

The process looks like this:

iPhone generates a key pair $(K_{pub}, K_{priv})$.
Only $K_{pub}$ goes out over the air via BLE.
Any passerby with an iPhone (let's call them a "Helper"), catching this signal, takes their GPS coordinates and encrypts them with this key.

Report Formula

Mathematically, it looks roughly like this:

$$Location_Report = Encrypt(GPS_Coords + Timestamp, K_{pub})$$

This encrypted packet is sent to Apple's servers. Important point: the "Helper" doesn't have the private key and can't read what they encrypted. Apple doesn't have the private key either. Only you have it - on your second trusted device (iPad, Mac, or old iPhone).

Data Relay and Crowdsourcing

Imagine your iPhone is a person in the forest who's lost their voice but has an infinite supply of notes. They leave them on the trail, and other hikers (strangers' iPhones), without reading them, deliver them to the post office (iCloud).

The data transmission scheme:

[Your iPhone (OFF)] --(BLE)--> [Stranger's iPhone] --(Internet)--> [iCloud] --(Key)--> [Your iPad]

In 2026, this network has become so dense that even in the forest, the probability that someone with an Apple Watch or iPhone will pass by is extremely high. Apple and Google finally agreed on a unified standard (DULT - Detecting Unwanted Location Trackers), so now Android devices can also anonymously help find your things, and vice versa.

2026 Innovations: Post-Quantum Protection and UWB 2.0

We've entered an era where the threat of quantum computers has ceased to be theoretical. Apple implemented the PQ3 protocol in iMessage, and Find My was no exception. Now the keys that encrypt coordinates are protected against "Record Now, Decipher Later" attacks.

UWB 2.0 (Ultra Wideband)

The new chips in iPhone 17 and AirTag 2 allow using signal phase shift to determine distance with accuracy down to 1-2 centimeters. Even if the device is "off," in Precision Finding mode it responds to your phone's request, using induced energy or minimal residual charge.

Here's what it looks like on the Swift side (simplified, to understand the logic of framework interaction):

import CoreLocation
import NearbyInteraction

// Example session initialization for device finding in 2026
class FindingManager: NSObject, NISessionDelegate {
    var niSession: NISession?

    func startPreciseFinding(for deviceToken: NIDeviceCapability) {
        guard NISession.isSupported else { return }
        niSession = NISession()
        niSession?.delegate = self

        // In 2026 we work with encrypted tokens even in UWB
        let config = NINearbyPeerConfiguration(peerToken: deviceToken.sentinelToken)
        niSession?.run(config)
    }

    func session(_ session: NISession, didUpdate nearbyObjects: [NINearbyObject]) {
        if let object = nearbyObjects.first {
            // Distance and direction accounting for U2/U3 phase modulation
            print("Distance: \(object.distance)m, Azimuth: \(object.direction)")
        }
    }
}

Physics vs. Technology: Where the Network Is Powerless

Despite all the coolness, you can't fight physics. I often see user disappointment when their device "drops off the radar." There are two main enemies:

Faraday Cage. If your iPhone is stuffed into a microwave (turned off!) or wrapped in several layers of foil, the BLE signal won't escape. Metal safes and deep concrete basements work the same way.
Device Density. In the Siberian taiga, where there's one bear per 100 kilometers and not a single iPhone, crowdsourcing doesn't work. There's simply no one to pick up the "tourist in the forest's" note.

Verdict

Find My in 2026 is a triumph of systems programming. Engineers made "dead" hardware perform the most complex cryptographic operations while consuming nanoamperes. It reminds me of old-school microcontroller development, where every processor cycle counted, but adjusted for modern privacy requirements.

If you're designing your own IoT devices, remember: the future isn't in powerful transmitters, but in smart use of others' infrastructure.

MVVM + C + Factory: The Holy Trinity of Dependency Injection

Konstantin Shkurko — Sat, 31 Jan 2026 08:08:11 +0000

This article is the final chord in our architecture trilogy. We've already learned to bring order within screens using MVVM and manage transition flows through Coordinator. But one awkward question remains: who will create all these dependencies? If your Coordinator has turned into a dumping ground for a dozen services that it simply passes along, it's time to introduce Factory. You'll learn how to separate object creation from object management, why global DI containers are slow-acting poison, and how to build a system where each component receives only what it needs without knowing the unnecessary details.

When we first start implementing Coordinator, everything seems beautiful. But a couple of months pass, the project grows, and suddenly it turns out that your MainCoordinator accepts NetworkService, DatabaseService, AnalyticsService, ImageLoader, and half a dozen other "absolutely necessary" things in its initializer. Moreover, the Coordinator itself doesn't use these services—it just holds onto them to pass them to the ViewModel later.

Congratulations, you've built a "dependency pipeline." This is a bad practice. The Coordinator should know when to show a screen, but it doesn't need to know how to assemble that screen brick by brick. That's what the Factory pattern is for.

The Problem: The Overloaded Coordinator

Let's face the truth: if your code looks like this, you have decomposition problems:

// DON'T DO THIS
final class ProductCoordinator: Coordinator {
    let networkService: NetworkProtocol
    let authService: AuthProtocol
    let cache: CacheProtocol
    // ... 5 more services

    func start() {
        // Coordinator knows too much about assembly details
        let vm = ProductViewModel(network: networkService, auth: authService)
        let vc = ProductViewController(viewModel: vm)
        navigationController.pushViewController(vc, animated: true)
    }
}

Here, the Coordinator is tightly coupled to concrete implementations of ViewModel and ViewController. If you want to change how ProductViewModel is created (for example, add a new logger), you'll have to dig into the Coordinator. Now imagine you have ten screens like this.

The Solution: Dependency Container & Factory

The idea is simple: we create a separate object (or group of objects) whose sole task is knowing how to assemble a screen. I prefer splitting this into two parts: Dependency Container (service storage) and Module Factory (screen creator).

1. Dependency Container: The Source of Truth

This is a long-lived object that stores singletons or service configurations. But importantly: it shouldn't be a global singleton like Container.shared. That's a trap that turns your code into an untestable mess (Service Locator anti-pattern).

The container should be passed explicitly or injected into the Factory.

protocol DependencyContainerProtocol {
    var networkService: NetworkProtocol { get }
    var databaseService: DatabaseProtocol { get }
}

final class AppDependencyContainer: DependencyContainerProtocol {
    // Lazy initialization to avoid creating everything at once
    lazy var networkService: NetworkProtocol = NetworkService()
    lazy var databaseService: DatabaseProtocol = DatabaseService()
}

2. Module Factory: The Builder

The Factory is a "workshop" that churns out ready-made modules. It knows about the Container's existence and can extract the necessary parts from it.

protocol ModuleFactoryProtocol {
    func makeProductListModule(coordinator: ProductListCoordinator) -> UIViewController
    func makeProductDetailModule(product: Product) -> UIViewController
}

final class ModuleFactory: ModuleFactoryProtocol {
    private let container: DependencyContainerProtocol

    init(container: DependencyContainerProtocol) {
        self.container = container
    }

    func makeProductListModule(coordinator: ProductListCoordinator) -> UIViewController {
        let viewModel = ProductListViewModel(
            network: container.networkService,
            coordinator: coordinator
        )
        return ProductListViewController(viewModel: viewModel)
    }
}

Integrating Factory into Coordinator

Now our Coordinator becomes truly lightweight. It simply asks the factory: "Give me a controller for the product list, here's a reference to me for feedback."

final class ProductListCoordinator: Coordinator {
    var childCoordinators: [Coordinator] = []
    var navigationController: UINavigationController

    private let factory: ModuleFactoryProtocol

    init(navigationController: UINavigationController, factory: ModuleFactoryProtocol) {
        self.navigationController = navigationController
        self.factory = factory
    }

    func start() {
        let viewController = factory.makeProductListModule(coordinator: self)
        navigationController.pushViewController(viewController, animated: true)
    }
}

Look at that cleanliness! The Coordinator now doesn't know about NetworkService, it doesn't know about ViewModel. If tomorrow you decide to replace MVVM with VIPER for one specific screen—you simply change the implementation in the Factory. The Coordinator won't even know about it.

Why not Service Locator?

There's often a temptation to do ServiceLocator.shared.get(NetworkProtocol.self). It seems convenient: no need to pass anything through initializers.

But I'm categorically against this in large projects.

Hidden dependencies: Looking at a controller's init, you don't see that it needs networking. This only surfaces at runtime if you forget to register the service.
Testing complexity: You'll have to reset the global singleton's state before each test, which turns parallel test execution into hell.

Explicit passing through the Factory (Constructor Injection) is the honest way. Yes, there's slightly more code, but you sleep peacefully at night.

Composition Root: Where it all begins

Where is this whole machinery created? In the Composition Root. Usually, this is SceneDelegate or AppDelegate. This is the only place in the app that knows about all components and ties them together.

class SceneDelegate: UIResponder, UIWindowSceneDelegate {
    var window: UIWindow?
    var appCoordinator: AppCoordinator?

    func scene(_ scene: UIScene, willConnectTo session: UISceneSession, options connectionOptions: UIScene.ConnectionOptions) {
        guard let windowScene = (scene as? UIWindowScene) else { return }

        let container = AppDependencyContainer()
        let factory = ModuleFactory(container: container)
        let nav = UINavigationController()

        appCoordinator = AppCoordinator(navigationController: nav, factory: factory)
        appCoordinator?.start()

        let window = UIWindow(windowScene: windowScene)
        window.rootViewController = nav
        self.window = window
        window.makeKeyAndVisible()
    }
}

Practical Tips & Observations

Protocols for Factories: Always hide the factory behind a protocol. This lets you write a MockFactory for tests and verify that the coordinator is actually trying to create the right screen.
Many factories are better than one: If the project is huge, don't make one GiantFactory. Split them by features: AuthFactory, ProfileFactory, ChatFactory.
SwiftUI and DI: In SwiftUI there's EnvironmentObject, which is often confused with DI. Remember that EnvironmentObject is essentially a global variable within the view tree. For complex business logic, I still recommend using classic DI through initializers of your ObservableObject (ViewModel).

The combination of MVVM, Coordinator, and Factory is the gold standard for scalable iOS applications. This gives you:

Testability: Each component is isolated.
Flexibility: You can change UI or logic without rewriting navigation.
Order: Every object has one clear responsibility.

Yes, at first it seems like you're writing a lot of "extra" code. But as soon as you get a task like "let's replace the second screen in this flow with a new one, but only for users from the US," you'll thank yourself for choosing this path.

Coordinator Pattern: Taking Control of the Flow

Konstantin Shkurko — Thu, 29 Jan 2026 15:55:38 +0000

This article is a logical continuation of our dive into architecture. If in the first part we brought order inside the "black box" called ViewModel, here we'll step beyond its boundaries. You'll learn how to rip out navigation logic from ViewControllers and ViewModels, why prepare(for:sender:) is an architectural dead end, and how to build a navigation system that won't turn your project into spaghetti when you add the tenth screen. We'll break down the concept of Child Coordinators, solve memory leak problems, and discuss whether this pattern survived in the SwiftUI era.

If MVVM is responsible for what happens inside a screen, then Coordinator is the answer to the question "where are we going next?".

In Apple's standard approach, navigation is baked right into UIViewController. This is convenient for small demo projects, but in real production it leads to controllers knowing way too much about each other. When LoginViewController creates HomeViewController, you get tight coupling. Try changing the flow later or reusing LoginViewController somewhere else - and you'll understand why this is a bad idea.

I believe a controller should be selfish. It shouldn't know where it came from or where it's going. Its job is to display data and report that the user tapped a button. That's it.

The Problem: Hardcoded Navigation

Let's be honest: who among us hasn't written self.navigationController?.pushViewController(nextVC, animated: true) directly in a button tap handler?

Problems start when:

You need to change the logic: If the user is not authorized, we go to one screen, if authorized but hasn't filled out their profile - to another. Writing this inside the controller means bloating its logic.
Dependency Injection: To create the next controller, the current one needs to pass dependencies (database, API client) into it. Where does the current controller get them from? Store them "just in case"? That's garbage in the code.
Deep Linking: Try implementing a transition to a deeply nested screen from a Push notification if all navigation is baked into controllers. It'll be a chain of if-else statements and hacks.

The Basic Implementation

A coordinator is a simple object that encapsulates the logic of creating controllers and managing their lifecycle. Let's start with a basic protocol.

Swift

protocol Coordinator: AnyObject {
    var childCoordinators: [Coordinator] { get set }
    var navigationController: UINavigationController { get set }

    func start()
}

Why do we need childCoordinators? This is a critically important point for memory management. If you just create a coordinator and don't save a reference to it, it'll die right after exiting the method. The childCoordinators array keeps them "alive" while working with a specific flow.

The "Start" Method

The start() method is the entry point. No magic, just creating the needed screen and displaying it.

Swift

final class AuthCoordinator: Coordinator {
    var childCoordinators: [Coordinator] = []
    var navigationController: UINavigationController

    // Delegate for communication with parent (e.g., AppCoordinator)
    weak var parentCoordinator: MainCoordinator?

    init(navigationController: UINavigationController) {
        self.navigationController = navigationController
    }

    func start() {
        let viewModel = LoginViewModel()
        // Here we link the VM and Coordinator
        viewModel.coordinator = self 
        let viewController = LoginViewController(viewModel: viewModel)
        navigationController.pushViewController(viewController, animated: true)
    }

    func showRegistration() {
        let regVC = RegistrationViewController()
        navigationController.pushViewController(regVC, animated: true)
    }
}

Communication: ViewModel to Coordinator

How does ViewModel tell the coordinator "time to navigate"? I prefer two approaches:

Closures: Simple and effective for small projects.
Delegates: More structured and familiar for iOS development.

Personally, I've been leaning toward closures lately because it reduces boilerplate code. But if the flow is complex and there are many events, delegates look cleaner.

Swift

// Closure approach in ViewModel
final class LoginViewModel {
    var onLoginSuccess: (() -> Void)?
    var onForgotPassword: (() -> Void)?

    func loginPressed() {
        // ... API call
        onLoginSuccess?()
    }
}

// In Coordinator
func start() {
    let vm = LoginViewModel()
    vm.onLoginSuccess = { [weak self] in
        self?.showMainFlow()
    }
    // ...
}

The "Back Button" Nightmare

The biggest pain in UIKit when using coordinators is the system back button. The user taps it, the controller gets removed from memory, and your coordinator is still hanging in the childCoordinators array. Congratulations, you have a memory leak.

There are three ways to solve this:

Subscribe to UINavigationControllerDelegate: The didShow method lets you check which controller was removed, and if it was "ours", remove the coordinator too.
Custom back button: Brutal, inconvenient, breaks native UX (swipe to back). Don't recommend.
Using a wrapper over UIViewController: Overriding viewDidDisappear. Also has nuances.

I usually use the first option. It requires a bit more code, but it works reliably and preserves native system behavior.

Parent and Child: The Hierarchy

Imagine the app as a tree. At the root is AppCoordinator. It decides whether to launch AuthCoordinator or MainCoordinator.

When AuthCoordinator finishes its work (user logged in), it must notify the parent. The parent removes it from childCoordinators, clears the stack, and launches the next flow.

Swift

func didFinishAuth() {
    // Remove from children list
    childCoordinators.removeAll { $0 === authCoordinator }
    // Launch main flow
    showMainTabbar()
}

DI: Dependency Injection on Steroids

Coordinator is the perfect place for dependency injection. Instead of passing NetworkService through five controllers, you keep it in the coordinator (or get it from a DI container) and pass it only to the ViewModel that actually needs it.

This makes the code insanely easy to test. You can create a coordinator with MockNetworkService and verify that it handles errors correctly.

SwiftUI: Is the Coordinator Dead?

With the release of NavigationStack in iOS 16 and NavigationPath, Apple gave us tools for managing navigation at the state level. Does this mean the death of the pattern?

Yes and no. In SwiftUI, the classic coordinator that holds UINavigationController is no longer needed. But the concept of separating navigation logic from View hasn't gone anywhere. Now we often call it Router.

Instead of manipulating controllers, Router manages NavigationPath (an array of data representing the stack).

Swift

class Router: ObservableObject {
    @Published var path = NavigationPath()

    func navigateToDetails(product: Product) {
        path.append(product)
    }
}

It's the same coordinator, just dressed in modern SwiftUI clothes.

Anti-patterns to Avoid

God Coordinator: Don't try to cram navigation for the entire app into one file. Divide into logical blocks (Auth, Profile, Settings).
Passing ViewControllers: Coordinator should never return UIViewController to the outside. It should show or push it itself.
Strong References to Parents: Always use weak for references to parent coordinators, otherwise you'll create a retain cycle, and memory will never be released.

To sum up: Coordinator isn't just an extra layer of code. It's freedom. Freedom to swap screens in five minutes, freedom to test navigation separately from UI, and freedom to never see prepare(for:segue:) in your nightmares. Yes, it requires discipline and writing slightly more protocols, but in a project that lives longer than a couple of months, it pays off handsomely.

MVVM Beyond the Buzzword: A Practical Guide

Konstantin Shkurko — Wed, 28 Jan 2026 07:37:57 +0000

This article isn't another documentation rehash. We'll examine why "pure" MVVM from textbooks falls apart in real projects, how to transform ViewModel from a garbage dump for logic into a clear state machine, and why navigation in architecture is always a pain that you need to know how to handle. You'll learn to separate data from its presentation so that tests write themselves, and your colleagues don't curse you during code review.

If you've ever opened a project where the ViewModel turned into a garbage heap of a couple thousand lines, congratulations—you've seen "smoker's MVVM." It usually happens like this: a developer hears that you can't write logic in View, and joyfully moves everything, including date formatting and transition logic, into the ViewModel. As a result, we get the same Massive View Controller, just with a different sauce and an even more complex lifecycle.

I hold the opinion that architecture isn't about how you organize files into folders, but about how you manage complexity and state. Let's break down how to make MVVM work for you, not against you.

Why MVVM Often Fails in Practice

Most problems with MVVM stem from a misunderstanding of responsibilities. Often, ViewModel is perceived as "the place where I put everything that didn't fit in View."

Main reasons for failure:

Violation of encapsulation: View knows too much about ViewModel's internals, or even worse, ViewModel holds references to UI components. If your ViewModel has import UIKit (or any other UI library), you have problems.
Lack of clear State: Variables like @Published var name, @Published var isLoading, @Published var error live their own lives. As a result, you can end up in a state where both the spinner is spinning and the error is showing simultaneously. This is an "invalid state," and it's a sin.
Navigation logic inside VM: ViewModel shouldn't decide where to go next. Its job is to say: "I'm done, data is saved." But who leads the user where after that—that's the job of a coordinator or router.

Core Principles: Separation, Testability, Unidirectional Data Flow

Forget about Two-Way Binding as a standard. It's appropriate in simple input forms, but on complex screens, it turns data flow into chaos. The future (and present) belongs to Unidirectional Data Flow (UDF).

View sends an Action (button press, viewDidLoad).
ViewModel processes the Action, calls the service, and updates State.
View subscribes to State and re-renders.

This makes the system predictable. You always know which event led to the state change. Plus, it dramatically simplifies testing: you just feed in an action and check if the final state matches what's expected.

ViewModel as a State Machine (Not Just a Bag of Properties)

Instead of a scattering of disparate properties, I prefer to use a single State. The ideal tool for this is an enum.

final class ProductListViewModel: ObservableObject {
    enum State {
        case idle
        case loading
        case loaded([Product])
        case error(String)
    }

    @Published private(set) var state: State = .idle

    private let repository: ProductRepositoryProtocol

    init(repository: ProductRepositoryProtocol) {
        self.repository = repository
    }

    func loadProducts() {
        state = .loading
        repository.fetchProducts { [weak self] result in
            switch result {
            case .success(let products):
                self?.state = .loaded(products)
            case .failure(let error):
                self?.state = .error(error.localizedDescription)
            }
        }
    }
}

Why is this cool? Because now View is maximally dumb. It just "renders" the state. In SwiftUI, this turns into an elegant switch inside body. I'm categorically against logic in View, even if it's a simple if-else. The less View "thinks," the fewer chances of catching weird bugs during rendering.

Handling Side Effects: Networking, Analytics, Navigation

ViewModel is a dispatcher. It shouldn't go to the network or write to the database itself. It calls an abstraction (protocol).

Navigation

I'm a proponent of the Coordinator pattern. ViewModel should communicate the need for navigation through a closure or delegate.

final class LoginViewModel: ObservableObject {
    var onLoginSuccess: (() -> Void)?

    func handleLogin() {
        // ... authorization logic
        onLoginSuccess?()
    }
}

Analytics

Don't clutter business logic methods with Analytics.log(...) calls. This is a "side effect." It's best to extract this into separate decorators or use observers that watch for state changes. But if the project is small, I allow injecting an analytics service into ViewModel, as long as it doesn't turn into spaghetti.

Binding Strategies: Combine vs Closures vs @Published

The choice of tool depends on your stack and religion.

@Published (SwiftUI): The simplest and most concise option. But be careful: updates happen in objectWillChange, which sometimes leads to nuances in the lifecycle.
Combine: Gives you the power of operators (debounce, filter, combineLatest). If you have complex input with "on-the-fly" validation, Combine is indispensable. But debugging long chains is a special kind of masochism.
Closures: Old-school and the fastest option. No external dependencies, no magic. If you're writing a library, this is the best choice to avoid forcing Combine or RxSwift on the user.

I personally prefer Combine for iOS 13+, but I try to keep chains short. If a chain is more than 5-6 operators—it's time to break it into parts or extract the logic into a separate method.

Testing ViewModels Without UIKit/SwiftUI

If you can't test a ViewModel without creating an instance of UIViewController or View—your architecture has failed. A test should look roughly like this:

func test_onLoad_setsLoadingState() {
    let mockRepository = MockProductRepository()
    let sut = ProductListViewModel(repository: mockRepository)

    sut.loadProducts()

    if case .loading = sut.state {
        // success
    } else {
        XCTFail("Expected .loading state")
    }
}

I always use Dependency Injection through the initializer. This allows you to easily slip in mocks. Testing async code in Combine is a bit more complex (you need Expectations), but it's still orders of magnitude faster than running UI tests.

Anti-Patterns to Avoid

Massive ViewModel: If your VM has crossed 500 lines—cut it. Extract formatting logic into Formatter, data work into Service, and complex transformations into Use Case (hello, Clean Architecture).
Leaky Views: Passing UI objects into ViewModel. Never pass UIImage or NSAttributedString. Pass Data or just String. ViewModel should live in the world of pure logic.
Shared ViewModels: Using the same instance model for different screens via Singleton. This is a direct path to the state of "someone changed data on the third screen, and everything crashed for me." Each screen gets its own ViewModel. If you need to share data—use a common Service or Storage.

MVVM isn't a dogma, it's a tool. It scales beautifully if you don't try to make it the "architecture of the entire application." In reality, MVVM works great with coordinators for navigation and services for business logic.

The main thing is to remember: ViewModel is responsible for what to show, and View is responsible for how it looks. If you separate these concepts in your head, your code will become cleaner, and your sleep—more peaceful.

Secure Data Exchange Between Android Apps: intents, URI schemes, shared preferences

Konstantin Shkurko — Fri, 23 Jan 2026 13:42:52 +0000

In Android development, sooner or later you'll face the task of passing data between applications. Seems simple enough - send an intent, get a result. But dig a little deeper, and it turns out that behind this simple API lurks a whole zoo of potential security holes. We'll examine three main mechanisms for data exchange in Android: intents, URI schemes, and shared preferences. We'll look at how they work under the hood, where the pitfalls lie, and how to protect your app from prying eyes. If you're writing for Android and want to understand why "just pass the data" is a bad idea, read on.

Intents: the standard way to break something

Let me start by saying that intents are the foundation of inter-process communication in Android. Essentially, they're message-requests that one app sends to the system or another app. Think of an intent as an envelope where you put information and send it either to another screen within your app or to a completely different app.

Simple analogy: you want to open a photo - you create an intent asking "show this picture", the system looks and says: "Oh, there's the Gallery app, it knows how to show pictures" and opens it. Or you want to share a link - you create an intent to "share text", the system shows a list of apps (WhatsApp, Telegram, Email) that can do this.

There are two types of intents:

Explicit - you specifically say: "Open this particular screen in my app". It's like addressing a letter to a specific person - relatively safe.
Implicit - you say: "I need someone who can open PDFs" or "I need an app for making calls". The system decides who's suitable. It's like writing "To: any doctor" - anyone can respond, and this is where security problems begin.

[!IMPORTANT]

Here and throughout the article, all code examples are simplified for clarity. Production code will require more error handling and edge cases.

// Explicit intent - relatively safe
val intent = Intent(this, TargetActivity::class.java)
intent.putExtra("user_id", 12345)
startActivity(intent)

// Implicit intent - this is where questions begin
val intent = Intent(Intent.ACTION_VIEW)
intent.data = Uri.parse("myapp://profile/12345")
startActivity(intent)

What can go wrong? Any app on the device can register an intent filter for the myapp:// scheme. Imagine: a user clicks a link, and instead of your app, a shady one opens that just collects data. In the past (relatively recently), this is exactly how banking apps were hacked - by intercepting deeplinks with payment information.

How to protect yourself

First rule - never pass sensitive data through implicit intents. If you absolutely must, use App Links (Android 6.0+), which require domain verification.

<intent-filter android:autoVerify="true">
    <action android:name="android.intent.action.VIEW" />
    <category android:name="android.intent.category.DEFAULT" />
    <category android:name="android.intent.category.BROWSABLE" />
    <data
        android:scheme="https"
        android:host="myapp.com"
        android:pathPrefix="/profile" />
</intent-filter>

Here autoVerify="true" forces Android to verify that you actually own the myapp.com domain. The system will download a JSON file from your server and make sure you have the right to handle these links. Yes, it's additional setup, but it cuts off 90% of deeplink attacks.

Second - always validate incoming data. Never trust what comes in an intent.

override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)

    val userId = intent.getStringExtra("user_id")

    // Bad - blindly trust the data
    loadUserProfile(userId)

    // Good - validate
    if (userId != null && userId.matches(Regex("^[0-9]{1,10}$"))) {
        loadUserProfile(userId)
    } else {
        // Log suspicious activity
        Timber.w("Invalid user_id received: $userId")
        finish()
    }
}

I've seen code where developers passed SQL queries through intent extras. Yes, you heard that right. The result was predictable - SQL injection through a regular deeplink. Don't repeat others' mistakes.

URI schemes: when the browser becomes an intermediary

URI schemes are a way to launch an app from a browser or another app via a special link like myapp://action/params. In iOS this works through Custom URL Schemes, in Android - through intent filters.

The main problem with URI schemes is the lack of owner verification. Any app can register the same scheme as yours. On Android this turns into an app selection dialog, which the user might accidentally ignore by choosing the wrong one.

<!-- Anyone can register this -->
<intent-filter>
    <action android:name="android.intent.action.VIEW" />
    <category android:name="android.intent.category.DEFAULT" />
    <category android:name="android.intent.category.BROWSABLE" />
    <data android:scheme="myapp" />
</intent-filter>

Classic attack scenario: you make a payment app with URI scheme support for initiating payments. An attacker publishes an app with the same scheme. The user clicks a payment link, selects the wrong app, and voilà - their data is leaked.

Migrating to App Links

I try to avoid custom URI schemes wherever possible. Instead, I use HTTPS links with App Links. The difference is fundamental: the system automatically opens your app without a selection dialog because you've proven domain ownership.

// Handling App Link
val appLinkIntent = intent
val appLinkData: Uri? = appLinkIntent.data

appLinkData?.let { uri ->
    val path = uri.path // /profile/12345
    val params = uri.queryParameterNames // ?ref=email

    // Parse and handle
    when {
        path?.startsWith("/profile") == true -> {
            val userId = path.removePrefix("/profile/")
            openProfile(userId)
        }
        path?.startsWith("/payment") == true -> {
            // Critical: verify payment signature on server
            verifyAndProcessPayment(uri)
        }
    }
}

What's important: even with App Links, you can't blindly trust parameters. In the payment example above, I always verify data on the server. An attacker can forge a link (for example, through a phishing site), but server-side signature verification won't allow a payment to execute with modified parameters.

Protecting parameters in URIs

If a URI scheme is still necessary (for example, for backward compatibility), add a cryptographic signature.

// Generating a signed link on the server
fun generateSecureLink(action: String, params: Map<String, String>): String {
    val timestamp = System.currentTimeMillis()
    val data = "$action|${params.entries.joinToString("|")}|$timestamp"
    val signature = HMAC_SHA256(data, SECRET_KEY)

    return "myapp://$action?" +
           params.entries.joinToString("&") { "${it.key}=${it.value}" } +
           "&timestamp=$timestamp&signature=$signature"
}

// Verification on the client
fun verifySecureLink(uri: Uri): Boolean {
    val signature = uri.getQueryParameter("signature") ?: return false
    val timestamp = uri.getQueryParameter("timestamp")?.toLongOrNull() ?: return false

    // Check freshness (link valid for 5 minutes)
    if (System.currentTimeMillis() - timestamp > 300_000) {
        return false
    }

    // Verify signature
    val params = uri.queryParameterNames
        .filter { it != "signature" && it != "timestamp" }
        .sorted()
        .joinToString("|") { "$it=${uri.getQueryParameter(it)}" }

    val expectedSignature = HMAC_SHA256(params, SECRET_KEY)
    return signature == expectedSignature
}

Yes, this complicates the code, but it makes intercepting and modifying links pointless. Without knowing the SECRET_KEY, an attacker can't create a valid signature.

Shared Preferences: when private becomes public

Now about the most insidious mechanism - Shared Preferences. By default they're private to the app, but Android allows making them accessible to other apps through MODE_WORLD_READABLE and MODE_WORLD_WRITEABLE.

Good news: these modes are deprecated since API 17 and completely removed in API 24. Bad news: I still encounter code that tries to use them, or worse, stores sensitive data in regular SharedPreferences thinking they're protected.

// DON'T do this
val prefs = getSharedPreferences("user_data", Context.MODE_PRIVATE)
prefs.edit()
    .putString("password", password) // Storing password in plain text
    .putString("credit_card", cardNumber)
    .apply()

Shared Preferences are stored in an XML file in the /data/data/package.name/shared_prefs/ directory. On rooted devices or through ADB backup, anyone can read these files. I once audited a popular finance app and found access tokens stored in plaintext. They didn't even bother using EncryptedSharedPreferences.

EncryptedSharedPreferences: doing it right

With Android Security Library, a proper way to encrypt data appeared.

val masterKey = MasterKey.Builder(context)
    .setKeyScheme(MasterKey.KeyScheme.AES256_GCM)
    .build()

val encryptedPrefs = EncryptedSharedPreferences.create(
    context,
    "secure_prefs",
    masterKey,
    EncryptedSharedPreferences.PrefKeyEncryptionScheme.AES256_SIV,
    EncryptedSharedPreferences.PrefValueEncryptionScheme.AES256_GCM
)

encryptedPrefs.edit()
    .putString("auth_token", token)
    .apply()

Here both keys and values are encrypted using Android Keystore, which is protected at the hardware level (if the device supports it). Even if someone gains access to the file, they can't decrypt it without access to the Keystore.

What's important: EncryptedSharedPreferences don't solve all problems. On older devices without hardware-backed Keystore or on emulators, the protection is weaker. Therefore, critically important data (payment information, medical data) is better not stored on the device at all or use additional encryption at the application level.

Content Providers for inter-process exchange

If you need to securely pass data between your own apps (for example, between the main app and a widget), use Content Provider with proper permissions.

class SecureDataProvider : ContentProvider() {
    override fun onCreate(): Boolean {
        return true
    }

    override fun query(
        uri: Uri,
        projection: Array<String>?,
        selection: String?,
        selectionArgs: Array<String>?,
        sortOrder: String?
    ): Cursor? {
        // Check that the calling app is us
        val callingPackage = callingPackage
        if (callingPackage != context?.packageName) {
            throw SecurityException("Unauthorized access")
        }

        // Return data
        return null // Your logic
    }
}

In the manifest:

<provider
    android:name=".SecureDataProvider"
    android:authorities="com.myapp.provider"
    android:exported="true"
    android:permission="com.myapp.permission.ACCESS_DATA" />

<permission
    android:name="com.myapp.permission.ACCESS_DATA"
    android:protectionLevel="signature" />

protectionLevel="signature" means only apps signed with the same key will get access. This is the ideal option for data exchange between your apps without risk of leaking to third parties.

Instead of a conclusion

Attacker systems constantly evolve, new attacks and new defenses appear. What worked in Android 8 might be insecure in Android 14. Therefore, security in Android isn't a one-time setup, but a process.

My main advice: read Android Security Bulletins, follow CVEs related to your dependencies, and regularly audit your code.

And finally: if you're unsure whether to pass some data between apps - don't. It's better to make an extra server call than to deal with the consequences of a data leak later. Seriously, it's not worth it.

Secure Data Sharing Between iOS Apps

Konstantin Shkurko — Thu, 22 Jan 2026 13:41:38 +0000

Inter-process communication in iOS is a tricky business. Apple has built an entire system of sandboxes and restrictions, and you can't just transfer data from one app to another willy-nilly. But once you figure it out, a world of possibilities opens up: from basic image sharing to building entire app ecosystems. Let's break down all the main methods of data exchange between apps (from URL Schemes to App Groups) with a focus on security and real problems you might encounter. I'll show you code, explain where each method fits, and teach you how to avoid creating holes in user data protection.

URL Schemes: Simplicity with a Catch

URL Schemes are the most obvious way to launch one app from another and pass it some data. The mechanics are simple: you register your scheme in Info.plist, like myapp://, and any app can call yours at this address.

// Opening another app
if let url = URL(string: "myapp://action?param=value") {
    UIApplication.shared.open(url)
}

In the receiving app, you catch this in AppDelegate or SceneDelegate:

func scene(_ scene: UIScene, openURLContexts URLContexts: Set<UIOpenURLContext>) {
    guard let url = URLContexts.first?.url else { return }

    if url.scheme == "myapp" {
        handleDeepLink(url)
    }
}

The problem is that URL Schemes are a public interface. Any app can call your scheme, and you won't know who exactly. Early in my development career, I once made a payment function via URL Scheme - passing the amount and product ID right in the parameters. Naturally, my lead pointed out in code review that an attacker could substitute the parameters and conduct a transaction for pennies. Had to redo it: now I only pass a token and verify the amount on the backend.

Never trust data from URL Schemes. Validate everything that comes in, and don't pass sensitive information in plain text.

Universal Links: The Civilized Approach

Universal Links appeared in iOS 9, and it's a completely different level. Instead of a custom scheme, you use a regular HTTPS domain. When a user taps a link, the system first checks if there's an app associated with this domain, and if there is - opens the app instead of Safari.

Setup is a bit more complex. You need an apple-app-site-association file on your server:

{
  "applinks": {
    "apps": [],
    "details": [
      {
        "appID": "TEAMID.com.example.app",
        "paths": ["/action/*", "/promo/*"]
      }
    ]
  }
}

This file must be at the domain root or in .well-known/apple-app-site-association and served over HTTPS without redirects. Apple verifies it when the app is installed.

In Xcode, you add the Associated Domains capability:

applinks:example.com

And handle it the same way as URL Schemes, but through a different method:

func scene(_ scene: UIScene, continue userActivity: NSUserActivity) {
    guard userActivity.activityType == NSUserActivityTypeBrowsingWeb,
          let url = userActivity.webpageURL else { return }

    handleUniversalLink(url)
}

Universal Links solve the security problem at the infrastructure level. Only the domain owner can configure the association, so faking such a link is much harder. Plus they work even if the app isn't installed - the user simply lands on the website.

Downsides: setup requires server control, and if something goes wrong with the certificate or association file, you'll be debugging for a long time. Apple caches these files, and updates can take hours.

Custom Document Types: File Exchange

Sometimes you need not just to pass parameters, but to share a file. This is where UTI (Uniform Type Identifiers) and Document Types come into play.

You need to register in Info.plist the document types your app can open:

<key>CFBundleDocumentTypes</key>
<array>
    <dict>
        <key>CFBundleTypeName</key>
        <string>My Document</string>
        <key>LSItemContentTypes</key>
        <array>
            <string>com.example.mydoc</string>
        </array>
        <key>LSHandlerRank</key>
        <string>Owner</string>
    </dict>
</array>

And export your UTI:

<key>UTExportedTypeDeclarations</key>
<array>
    <dict>
        <key>UTTypeIdentifier</key>
        <string>com.example.mydoc</string>
        <key>UTTypeConformsTo</key>
        <array>
            <string>public.data</string>
        </array>
        <key>UTTypeTagSpecification</key>
        <dict>
            <key>public.filename-extension</key>
            <array>
                <string>mydoc</string>
            </array>
        </dict>
    </dict>
</array>

Now, when another app sends a file through Share Sheet or Files, your app will appear in the list.

Handling happens through the same method as URL Schemes:

func scene(_ scene: UIScene, openURLContexts URLContexts: Set<UIOpenURLContext>) {
    guard let url = URLContexts.first?.url else { return }

    // This is a security-scoped URL, need to work with it carefully
    guard url.startAccessingSecurityScopedResource() else { return }
    defer { url.stopAccessingSecurityScopedResource() }

    // Copy the file to our own storage
    let data = try? Data(contentsOf: url)
    // Process...
}

Important point: the file you received is in someone else's sandbox. The system grants temporary access through a security-scoped bookmark. If you need to save the file long-term, copy it to your app's Documents or Cache. And always verify the contents - who knows what's actually in there.

App Groups: Shared Data for Your Own Apps

When you have multiple apps or extensions that need to share data directly, App Groups is what you need. Enable the capability in Xcode, create a group with an identifier like group.com.example.shared, and you get a shared container for files and UserDefaults.

// Writing to shared UserDefaults
if let sharedDefaults = UserDefaults(suiteName: "group.com.example.shared") {
    sharedDefaults.set("some value", forKey: "sharedKey")
}

// Path to shared directory
if let containerURL = FileManager.default.containerURL(
    forSecurityApplicationGroupIdentifier: "group.com.example.shared"
) {
    let filePath = containerURL.appendingPathComponent("data.json")
    try? someData.write(to: filePath)
}

This is convenient for widgets, keyboard extensions, Share Extensions. For example, I had an app with a widget. The main app would download data and put it in the App Group, and the widget would simply read from there.

But there's a nuance: App Groups don't provide inter-process synchronization. If both apps write to the same file simultaneously, you'll get a data race. You need to either use locks via NSFileCoordinator or organize exchange through notifications.

// Notifying another app about changes
extension Notification.Name {
    static let dataUpdated = Notification.Name("com.example.dataUpdated")
}

// In the source app
NotificationCenter.default.post(name: .dataUpdated, object: nil)

// In the receiving app (or extension)
CFNotificationCenterAddObserver(
    CFNotificationCenterGetDarwinNotifyCenter(),
    Unmanaged.passRetained(self).toOpaque(),
    { _, observer, name, _, _ in
        // Handle changes
    },
    "com.example.dataUpdated" as CFString,
    nil,
    .deliverImmediately
)

Darwin Notifications work between processes but don't carry a payload. It's just a signal that it's time to re-read the data.

Keychain Sharing: For Real Secrets

If you need to share tokens, passwords, or other sensitive data between apps from the same developer, there's Keychain Sharing. Works similarly to App Groups, but for Keychain.

You need to enable the Keychain Sharing capability and specify a group (usually matches the Team ID):

let query: [String: Any] = [
    kSecClass as String: kSecClassGenericPassword,
    kSecAttrAccount as String: "userToken",
    kSecAttrAccessGroup as String: "TEAMID.com.example.shared",
    kSecValueData as String: tokenData,
    kSecAttrAccessible as String: kSecAttrAccessibleAfterFirstUnlock
]

SecItemAdd(query as CFDictionary, nil)

Keychain is automatically encrypted by the system, and data is protected by hardware encryption on devices with Secure Enclave. This is the only proper way to store secrets in iOS.

I always use a wrapper like KeychainAccess or write my own, because working with the Security framework directly is quite an experience. But the point is that through kSecAttrAccessGroup your apps see the same records.

Share Extension: System Integration

Share Extension allows your app to appear in the system Share Sheet. This is a powerful mechanism for receiving data from other apps - text, images, links, anything.

You create a new target of type Share Extension in Xcode and get a standard ShareViewController:

class ShareViewController: SLComposeServiceViewController {
    override func isContentValid() -> Bool {
        // Content validation
        return true
    }

    override func didSelectPost() {
        guard let item = extensionContext?.inputItems.first as? NSExtensionItem,
              let attachments = item.attachments else { return }

        for attachment in attachments {
            if attachment.hasItemConformingToTypeIdentifier(UTType.url.identifier) {
                attachment.loadItem(forTypeIdentifier: UTType.url.identifier) { url, error in
                    if let url = url as? URL {
                        // Save to App Group for main app
                        self.saveSharedURL(url)
                    }
                }
            }
        }

        extensionContext?.completeRequest(returningItems: [], completionHandler: nil)
    }
}

Extensions run in a separate process with strict memory limits (usually 120 MB). If you exceed it, the system will kill the process without warning. So heavy processing is better postponed and done in the main app.

Data is passed through App Groups, and the main app can be woken up via URL Scheme or background fetch (I prefer this method). I usually save received data to the shared container, write a flag to UserDefaults, and on next launch the main app picks them up for processing.

XPC Services: For Advanced Users

XPC (inter-process communication via mach ports) is a low-level mechanism for communication between processes in macOS and iOS. In iOS it's only available for your own apps and extensions, but gives very precise control.

You create a protocol for communication:

@objc protocol DataServiceProtocol {
    func fetchData(completion: @escaping ([String]) -> Void)
}

And implement it in the XPC Service:

class DataService: NSObject, DataServiceProtocol {
    func fetchData(completion: @escaping ([String]) -> Void) {
        // Some heavy work
        completion(["data1", "data2"])
    }
}

This is useful when you need to isolate dangerous or resource-intensive code. For example, parsing untrusted data can be moved to a separate process. If it crashes, the main app will continue working.

Truth is, in everyday iOS app development, XPC is almost never used. It's more for system-level tasks or macOS. But it's useful to know about.

What to Pay Attention To

Data protection during exchange isn't just about choosing the right API. Here are some things I've learned from practice:

Input data validation. Whatever comes from another app - verify the format, size, content. Especially if it's files. You never know if they'll slip you a 100 MB image or a disguised executable.

Data Protection classes. When saving files to a shared container, don't forget about protection attributes:

try data.write(to: fileURL, options: .completeFileProtection)

completeFileProtection means the file is encrypted and inaccessible while the device is locked. For most cases, this is the right choice.

Minimizing permissions. If an extension doesn't need photo access - don't request it. If you can do without background modes - do without. Apple is very picky about permissions in App Review.

Cleaning up temporary data. Share Extensions and other extensions should clean up after themselves. Don't forget to delete temporary files after processing:

defer {
    try? FileManager.default.removeItem(at: tempURL)
}

What to Use and When

Usually the choice of method is dictated by the task:

Just need to open another app with parameters? URL Scheme is enough, just don't pass anything critical.
Want civilized integration with the ability to fallback to web? Universal Links.
Working with files that users can open from different apps? Document Types.
Your own apps need to share data? App Groups for files and UserDefaults, Keychain Sharing for secrets.
Want users to be able to share content to your app from anywhere? Share Extension.

I usually start with the simplest solution and only complicate if needed. Universal Links are cooler than URL Schemes, but require more setup. App Groups are convenient, but add dependencies between apps. All this needs to be considered. Each method has its niche, and it's important to understand not only how to use them, but what threats they carry. The main thing - always think about who and how can use your data exchange interface. Validate, encrypt, restrict permissions. User data protection isn't a checkbox on a checklist, it's the foundation of user trust in your app.