Artem Mirzabekian iOS Articles & Videos

SwiftUI tabs used to be simple on iPhone and more awkward on iPad. On iPhone, TabView naturally mapped to a bottom tab bar. On iPad, many apps needed something closer to a sidebar: more space, grouped destinations, and a layout that feels better on a large display.

The usual answer was to build a custom sidebar, split the app into separate navigation structures, or use conditional code for iPhone and iPad. That worked, but it also meant you were responsible for keeping selection, layout, and platform behavior in sync.

Enums are one of the most useful modeling tools in Swift. We use them for screen states, navigation routes, user actions, errors, commands, feature flags, and many other parts of iOS applications.

A lot of these models have something in common: they describe a closed set of possible values. A screen can be loading, loaded, or failed. A route can open a list, details, or settings. An action can represent view appearance, refresh, or item selection. These concepts map naturally to enums.

Reactive programming became popular because it solved a real problem. Apple platforms had many asynchronous and event-driven APIs, but they lacked a unified model for composing them. RxSwift, ReactiveSwift and Combine offered that model, and for many years, that made them feel like the missing piece in iOS architecture.

Swift 6.4 continues the ownership work that has been building through noncopyable types, borrowing, consuming parameters, lifetime dependencies, Span, and MutableSpan. The important part of this direction is that Swift is gaining more ways to describe ownership and access rules directly in APIs, instead of leaving them as compiler internals, documentation comments, or unsafe pointer conventions.

Feature flags are a foundational tool for modern mobile development. They allow teams to control behavior at runtime, roll out features gradually, run experiments, and decouple deployment from release. In iOS applications, a well-designed feature flag system also becomes a central coordination mechanism between product, QA, and engineering.

This article walks through a type-safe and thread-safe feature flag implementation in Swift. It explains the design decisions behind the approach, the problems it solves, and how to integrate it into a real application.

Building an event bus for communication between loosely coupled parts of an app. The implementation focuses on type safety (events conform to a marker protocol), thread safety with NSLock, automatic cleanup when the subscriber is deallocated, explicit cancellation via SubscriptionToken, MainActor delivery for UI code, and AsyncStream support. The key design choice is that subscriptions follow the owner's lifetime (weak reference), not the token's. The bus cleans up dead subscriptions lazily during publish or subscribe operations. Publishing creates a snapshot of subscribers and delivers events synchronously outside the lock.

The article presents a layered approach to iOS performance. It covers product level (perceived performance, optimistic updates, testing under Low Power Mode), metrics and observability (user centric metrics, breaking down latency, local vs production monitoring), architecture and data flow (reducing dependency breadth, critical path), UI and rendering pipeline (body execution cost, update frequency, scrolling, layout strategy), network and backend (round trips, request orchestration, concurrency), data and caching (reuse over recomputation, prefetching, cache layers), energy and power (continuous work, background activity), concurrency and scheduling (main thread, priorities, task structure), algorithms and data structures (complexity, access patterns, branching), memory and representation (heap allocations, copying, data layout), and CPU and hardware (branch prediction, cache, instruction level parallelism). The article emphasizes starting from user perception and moving down the stack, not micro optimizing prematurely.

The article explains how Swift's reference counting has evolved. It starts with the early design where objects stored strong and weak counts inline, creating "zombie objects" that remained allocated until all weak references were accessed. It then covers why this changed (memory overhead, concurrency concerns) and the modern side table design where weak references trigger allocation of an external structure. The article explains inline counts, the transition to side tables, how weak and unowned work today (including why unowned crashes), unowned(unsafe), and performance trade-offs between strong, weak, and unowned.

The article explains the motivation and mental model behind Swift Concurrency, starting from the 2017 Concurrency Manifesto. It covers isolation domains (MainActor, custom actors, nonisolated), how isolation propagates through calls and closures, Sendable for safe data crossing, and common problem areas like mixed isolation, detached tasks, MainActor.run, and unstructured concurrency. It also explains actors under the hood (executors, job queues, thread independence), global actors, and the recent shift toward approachable concurrency where async code stays in the caller's isolation domain by default.

The article compares three approaches to thread safety in Swift: actors (language level isolation with compiler enforcement), DispatchQueue (execution level coordination with serial or concurrent queues), and locks (critical section level control). It explains how each works under the hood, including actor reentrancy, queue deadlocks, lock recursion problems, and the new Mutex type from the Synchronization framework. It also covers atomics for simple operations and provides practical guidance on choosing based on safety, performance, API shape, and cognitive load.