DEV Community: Mark Kazakov

Essential Claude Code Skills for Mobile Developers

Mark Kazakov — Thu, 02 Apr 2026 07:33:19 +0000

Claude Code skills are packaged folders of instructions, scripts and resources that teach the AI coding agent how to perform specialised tasks.

Each skill has a SKILL.md file containing YAML metadata and step by step instructions. Claude scans the names and descriptions of installed skills and loads the full content only when your request matches.

Because skills are part of an open standard adopted by multiple agent frameworks, a single skill can work across Claude Code, OpenAI Codex, Cursor and other tools.

Installing Claude Code skills

Skills can be installed globally or per project. Personal skills go into ~/.claude/skills/ and become available across all your projects, while project specific skills live in .claude/skills/ inside your repository so everyone who clones the repo can use them.

Most skills are plain Markdown folders: clone the repository and copy the skill directory into the appropriate folder. For example, the Swift Development skill’s README shows that you can install it by copying the Swift Development skill directory into ~/.claude/skills/ and then invoking it via /swift-development.

Recommended skills for mobile developers

Below is a curated list of Claude Code skills that are particularly valuable for mobile developers working with native iOS, Android or Kotlin Multiplatform (KMP). The list covers a range of design and development tasks. Each skill is linked to its repository or marketplace page along with a brief description.

Swift Development
https://github.com/hmohamed01/swift-development
This comprehensive skill turns Claude into a competent Swift engineer. It packages patterns for SwiftUI navigation, concurrency (async/await, actors) and testing frameworks, along with helper scripts for building, running tests, formatting code and managing simulators. Installation is simple: copy the Swift Development directory into your personal skills folder and invoke it with /swift-development.

iOS Mobile Design
https://mcpmarket.com/tools/skills/ios-mobile-design
For designers and developers building polished iOS apps, this skill provides expert guidance on Apple’s Human Interface Guidelines. It teaches Claude how to apply SwiftUI layout systems, dynamic type, SF Symbols and modern navigation patterns so interfaces feel native to iPhone, iPad and visionOS. Key features include accessible design with dynamic type, responsive layouts, Material You style theming and Dark Mode optimisation.

iOS App Builder
https://mcpmarket.com/tools/skills/ios-app-builder
This skill transforms Claude into a senior iOS developer who builds and ships native apps using a command line only workflow. It uses Xcode’s xcodebuild and simctl tools to scaffold projects, run tests and launch apps without opening Xcode. The skill emphasises a “prove, don’t promise” methodology: it verifies logic through tests and simulator screenshots, manages the full app life cycle from scaffolding to App Store readiness and includes features like performance profiling and memory leak detection.

SwiftUI agent skill
https://github.com/twostraws/swiftui-agent-skill
A SwiftUI skill create by Paul Hudson (hacking with swift).
This skill helps identify and fix common mistakes AI agents make when writing SwiftUI – things like modern API usage, performance, accessibility, and more.

Android Development
https://github.com/dpconde/claude-android-skill
Designed for modern Android projects, this skill teaches Claude clean architecture with separate UI, domain and data layers. It covers Jetpack Compose patterns and best practices, multi module project structures, offline first architecture using Room and reactive streams, dependency injection with Hilt and comprehensive testing strategies. After cloning the repository into your skills folder, you can ask the agent to scaffold features, create Compose screens or set up repositories following Android best practices.

Android Kotlin Development
https://fastmcp.me/skills/details/241/android-kotlin-development
This skill focuses on building native Android apps with Kotlin. The description explains that it covers Model-View-ViewModel architecture with Jetpack, Compose for declarative user interfaces, Retrofit for API calls, Room for local storage and navigation patterns. It includes detailed instructions and code samples for models, API services and MVVM view models, making it a practical guide for Kotlin developers.

Mobile Android Design
https://fastmcp.me/skills/details/644/mobile-android-design
When you need to design Android interfaces that follow Google’s Material Design 3 guidelines, this skill is indispensable. It teaches Claude how to build adaptive layouts with Jetpack Compose, implement navigation patterns like bottom navigation and drawers, use dynamic colour and Material You theming, and create accessible UI for phones, tablets and foldables. It is especially helpful for modernising existing apps or ensuring new designs comply with Material Design principles.

Jetpack Compose Expert
https://github.com/aldefy/compose-skill
This skill provides Claude with real source code and extensive reference guides for Jetpack Compose. Without it, AI tools often misuse remember, generate inefficient recompositions or misorder modifiers; with the skill, Claude picks the right state primitive, applies stability annotations and orders modifiers correctly. The reference guides cover state management, view composition, performance, navigation, animation, lists, side effects, modifiers, theming, accessibility and deprecated patterns. Installation requires cloning the repository and copying the Jetpack Compose expert skill directory into your skills folder; Claude will automatically activate it when you mention Compose or related API names.

Kotlin Multiplatform (KMP) Abstraction Guide
https://fastmcp.me/skills/details/2190/kotlin-multiplatform
KMP projects often involve tough decisions about what to share between platforms and what to keep platform specific. This skill guides those decisions by providing a platform abstraction decision tree. It explains when to use commonMain, jvmAndroid or expect/actual patterns, covers targets like Android, JVM/Desktop and iOS, and offers triggers for questions such as "should I share this ViewModel?". It helps developers place code correctly and prepare for future web or WebAssembly targets.

Android build types, product flavors, and variants from zero to production

Mark Kazakov — Tue, 03 Mar 2026 11:39:18 +0000

How do you build different versions of the same app from one codebase?
You use build types, product flavors, and variants!
Let's explain the concept and dive into some examples.

What is a build type

A build type defines how the app is built.
The most common build types are:

debug
release

Debug is what you use during development. It usually:

Is debuggable
Has logging enabled
Is signed with a debug key
May include tools like LeakCanary

Release is what you ship to users. It usually:

Is not debuggable
Has code shrinking enabled
Is signed with your real keystore
Has logging disabled

So build types describe technical behavior.

What is a product flavor

A product flavor defines what app you are building.

Examples:

demo vs prod, different backend servers
free vs paid, different features
white label apps for different clients
staging vs production

Flavors describe business or product differences.
You can think of flavors as different personalities of your app.

What is a variant

A variant is the combination of:

One build type
One flavor from each flavor dimension

For example:

demoDebug
demoRelease
prodDebug
prodRelease

Each of those is a fully buildable and installable app.
When you click Run in Android Studio, you are running a specific variant.

Step 1: Basic Android app setup

Open your app module file:
app/build.gradle.kts

Inside the android block, you typically have something like:

android {
    namespace = "com.example.variants"
    compileSdk = 35

    defaultConfig {
        applicationId = "com.example.variants"
        minSdk = 24
        targetSdk = 35
        versionCode = 1
        versionName = "1.0"
    }
}

This defines your base app configuration.

Step 2: Understanding build types in practice

Add build types inside the android block:

android {

    buildTypes {
        debug {
            applicationIdSuffix = ".debug"
            versionNameSuffix = ".debug"
            isDebuggable = true

            buildConfigField("Boolean", "LOGGING_ENABLED", "true")
        }

        release {
            isMinifyEnabled = true
            isShrinkResources = true

            buildConfigField("Boolean", "LOGGING_ENABLED", "false")

            proguardFiles(
                getDefaultProguardFile("proguard-android-optimize.txt"),
                "proguard-rules.pro"
            )
        }
    }
}

What this does:

Debug builds have a different application id, so you can install them next to release.
Debug builds expose a constant called LOGGING_ENABLED.
Release builds enable code shrinking.

Use the generated constant in code:

object LoggerConfig {
    val loggingEnabled = BuildConfig.LOGGING_ENABLED
}

Now your app behaves differently depending on build type.

Step 3: Creating your first flavor

Now we introduce flavors.

We will create two environments:

demo
prod

First, define a flavor dimension:

android {

    flavorDimensions += "environment"

    productFlavors {
        create("demo") {
            dimension = "environment"
            applicationIdSuffix = ".demo"
            versionNameSuffix = ".demo"

            buildConfigField(
                "String",
                "API_BASE_URL",
                "\"https://api.demo.example.com\""
            )
        }

        create("prod") {
            dimension = "environment"

            buildConfigField(
                "String",
                "API_BASE_URL",
                "\"https://api.example.com\""
            )
        }
    }
}

Now you have:

demoDebug
demoRelease
prodDebug
prodRelease

Each one has a different API base URL.

Use it in your networking layer:

object ApiConfig {
    val baseUrl: String = BuildConfig.API_BASE_URL
}

No if statements required.

Step 4: Source sets and environment specific code

Android supports separate folders per flavor.

Structure example:

app/src/main
app/src/demo
app/src/prod
app/src/debug
app/src/release

Suppose you want a developer menu only in demo.

Create:
app/src/demo/java/com/example/variants/FeatureFlags.kt

And in:
app/src/prod/java/com/example/variants/FeatureFlags.kt

object FeatureFlags {
    const val showDeveloperMenu = false
}

The correct file is compiled automatically depending on variant.

This is cleaner than runtime checks.

Step 5: Multiple flavor dimensions

Now let us introduce branding.

Suppose you want:

One codebase
Two clients: acme and globex

Add a second dimension:

android {

    flavorDimensions += listOf("environment", "brand")

    productFlavors {

        create("demo") { dimension = "environment" }
        create("prod") { dimension = "environment" }

        create("acme") {
            dimension = "brand"
            applicationIdSuffix = ".acme"
            resValue("string", "brand_name", "Acme")
        }

        create("globex") {
            dimension = "brand"
            applicationIdSuffix = ".globex"
            resValue("string", "brand_name", "Globex")
        }
    }
}

Now total variants:
2 environments times 2 brands times 2 build types equals 8 variants.
This is how large production apps handle white labeling.

Step 6: Variant specific dependencies

You can attach dependencies to specific variants.

dependencies {

    implementation("androidx.core:core-ktx:1.13.1")

    debugImplementation("com.squareup.leakcanary:leakcanary-android:2.14")

    demoImplementation("com.jakewharton.timber:timber:5.0.1")
}

LeakCanary only in debug.
Timber only in demo builds.

This keeps production builds clean.

The Hidden Cost of Supporting Old OS Versions

Mark Kazakov — Thu, 22 Jan 2026 18:37:42 +0000

Supporting older operating system versions is often seen as a safe and user friendly choice. The assumption is simple. The more OS versions you support, the more users you can reach. In practice, the cost of backward compatibility is rarely visible at first, but it accumulates steadily and affects development speed, code quality, testing effort, and even product decisions.

This post looks at the real cost of supporting old OS versions and offers practical guidance on how to choose a realistic minimum OS version for a mobile app.

Slower Feature Development

Every new OS release brings new APIs, better tooling, and improved platform capabilities. When an app supports old OS versions, developers cannot freely use these improvements.

Instead of implementing a feature once, teams often need to:

Write conditional code paths for old and new APIs
Maintain fallback implementations
Avoid newer platform features entirely

Over time, this leads to a lowest common denominator approach. Features are designed not around what the platform can do today, but around what the oldest supported OS allows. This slows development and limits innovation.

Increased Testing Complexity

Supporting a wide OS range multiplies testing effort. Each additional OS version adds more combinations to validate:

Different system behaviors
API inconsistencies and edge cases
Vendor specific issues on older Android devices

Manual testing matrices grow quickly, and automated tests become harder to maintain. Bugs often appear only on specific OS versions that developers no longer use daily, making them harder to reproduce and fix.

The result is more time spent verifying existing behavior instead of building new functionality.

Design and UX Limitations

Older OS versions often lack modern UI components, animation capabilities, or system behaviors users now expect. Designers are forced to compromise to ensure consistency across versions.

This can result in:

Simpler interactions than desired
Visual inconsistencies between devices
Features that feel outdated on modern hardware

In some cases, entire UX improvements are postponed or cancelled because they cannot be implemented cleanly on older systems.

The Business Impact

From a business perspective, supporting old OS versions is not free. It increases development time, QA costs, and release risk. These costs are often hidden because they appear as slower velocity rather than explicit line items.

At the same time, users on very old OS versions tend to:

Upgrade less frequently
Engage less with new features
Be overrepresented in crash and support reports

This creates a mismatch between effort invested and value returned.

How to Choose a Realistic Minimum OS Version

Here are some important factors to consider when deciding on your minimum supported version:

User Distribution
Look at real usage data. If a small percentage of users are on very old OS versions, supporting them may not justify the cost.

Platform Support and Tooling
Align your minimum OS with what the platform vendor actively supports. Tooling, libraries, and documentation are optimized for recent versions.

App Category and Audience
Enterprise apps, internal tools, and professional products can usually move faster than consumer apps with broad audiences.

Feature Roadmap
If upcoming features rely on newer platform capabilities, raising the minimum OS early can simplify delivery and reduce technical debt.

Maintenance Budget
If the team is small, reducing compatibility overhead can significantly improve focus and release quality.

Essential RSS Feeds for Mobile Developers

Mark Kazakov — Tue, 06 Jan 2026 20:42:00 +0000

Keeping up with mobile development requires a steady flow of high quality information. RSS feeds are still one of the best ways to follow platform updates, deep technical articles, and long form insights without relying on social media algorithms.

What are RSS feeds

RSS stands for Really Simple Syndication.
An RSS feed is a constantly updated stream of content published by a website. Instead of visiting dozens of sites every day, you subscribe to their feeds and read all new articles in one place.

When a site publishes a new post, it automatically appears in your RSS reader. No algorithms, no distractions, no missing important updates.

RSS is especially useful for developers because it lets you follow official blogs, deep technical articles, and long form content in a clean chronological order.

How to read RSS feeds

To read RSS feeds you need an RSS reader. An RSS reader is an app or web service where you add feed links and read new posts as they appear.

You copy the feed URL and add it to the reader. From that moment on, new articles show up automatically.

A curated list of essential RSS feeds for mobile developers

Android Developers Blog
https://android-developers.googleblog.com/atom.xml
The official Android Developers Blog published by Google. It covers platform changes, new APIs, tooling updates, Jetpack libraries, performance improvements, and long term Android roadmap insights.

Google Android Medium Publication
https://medium.com/feed/androiddevelopers
Articles written by Android engineers at Google and the community. Often complements the official Android Developers Blog with practical examples and deep dives.

Android Weekly
https://androidweekly.net/rss.xml
A weekly curated newsletter with links to the best Android articles, libraries, tools, and open source projects. Very useful for discovering high quality content you might otherwise miss.

AppCoda
https://www.appcoda.com/rss/
A popular blog focused mainly on iOS development. It provides practical tutorials on Swift, SwiftUI, UIKit, and Apple platform APIs with clear explanations and code examples.

Apple Developer News
http://developer.apple.com/news/rss/news.rss
The official Apple developer feed. It includes announcements about SDK changes, App Store policies, WWDC updates, platform releases, and new Apple frameworks.

iOS Dev Weekly
https://iosdevweekly.com/issues.rss
A long running weekly newsletter curated by Dave Verwer. It aggregates the best iOS development articles, tools, libraries, and discussions from across the community.

Kotlin Blog by JetBrains
https://blog.jetbrains.com/kotlin/feed/
The official Kotlin blog by JetBrains. It covers Kotlin language evolution, Kotlin Multiplatform updates, compiler changes, and best practices relevant to Android and cross platform development.

ProMobile.Dev
https://promobile.dev/feed
A focused feed covering mobile development news, articles and tutorials across Android, iOS, and Kotlin Multiplatform.

Swift.org Blog
https://www.swift.org/atom.xml
The official Swift language blog. It publishes proposals, language evolution updates, compiler changes, and announcements relevant to Swift developers on all platforms.

Use Your Loaf
https://useyourloaf.com/blog/rss.xml
An iOS focused blog with deep dives into Apple frameworks, APIs, and platform behavior. Known for clear explanations and attention to technical detail.

Paul Hudson - Hacking with Swift
https://www.hackingwithswift.com/articles/rss
High quality Swift and iOS development content ranging from beginner to advanced topics, written clearly and consistently updated.

Modern Networking in iOS with URLSession and async/await – Part 2

Mark Kazakov — Thu, 25 Dec 2025 13:29:45 +0000

In Part 1 we built a clean networking layer using Swift’s modern concurrency and URLSession. The example endpoints were public and didn’t require authentication. Real-world apps, however, usually require you to authenticate users and attach short-lived access tokens to every request. These tokens eventually expire, and we need a way to obtain a new access token without forcing the user to log in again. In this part we’ll walk through how to implement a secure and robust token handling mechanism on top of the networking client from Part 1.

Understanding access and refresh tokens

Access tokens grant access to protected APIs. They are typically short‑lived (minutes to hours) so that an attacker only has a limited window if the token is compromised.
Refresh tokens are credentials that allow the client to request a new access token. Because they can be used to mint new access tokens, they need to be protected as if they were user passwords.

Token model

import Foundation

/// A container for access/refresh tokens and their expiration date.
/// Conforms to Codable so it can be encoded to and decoded from JSON.
struct TokenBundle: Codable {
    let accessToken: String
    let refreshToken: String
    let expiresAt: Date

    /// Returns true if the access token is expired.
    var isExpired: Bool {
        return expiresAt <= Date()
    }
}

This struct mirrors the JSON payload returned by your authentication server (e.g. { "access_token":…, "refresh_token":…, "expires_at":… }). The isExpired is a computed property that helps us decide when to refresh.

Secure persistence - Keychain

Let's create a helper for storing and retrieving tokens:

import Foundation
import Security

/// A simple helper for storing and retrieving data from the Keychain.
/// This stores and retrieves a single `TokenBundle` under a fixed key.
/// You can generalize it if you need to store more items.
enum KeychainService {

    /// Errors thrown by keychain operations.
    enum KeychainError: Error {
        case unhandled(status: OSStatus)
    }

    /// Change this to your app’s bundle identifier to avoid key collisions.
    private static let service = "pro.mobile.dev.ModernNetworking"
    private static let account = "authTokens"

    /// Saves the given token bundle to the keychain, overwriting any existing value.
    static func save(_ tokens: TokenBundle) throws {
        let data = try JSONEncoder().encode(tokens)
        // Remove any existing entry.
        try? delete()
        // Add the new entry.
        let query: [String: Any] = [
            kSecClass as String: kSecClassGenericPassword,
            kSecAttrService as String: service,
            kSecAttrAccount as String: account,
            kSecValueData as String: data
        ]
        let status = SecItemAdd(query as CFDictionary, nil)
        guard status == errSecSuccess else {
            throw KeychainError.unhandled(status: status)
        }
    }

    /// Loads the token bundle from the keychain, or returns nil if no entry exists.
    static func load() throws -> TokenBundle? {
        let query: [String: Any] = [
            kSecClass as String: kSecClassGenericPassword,
            kSecAttrService as String: service,
            kSecAttrAccount as String: account,
            kSecReturnData as String: true,
            kSecMatchLimit as String: kSecMatchLimitOne
        ]
        var item: AnyObject?
        let status = SecItemCopyMatching(query as CFDictionary, &item)
        if status == errSecItemNotFound {
            return nil
        }
        guard status == errSecSuccess, let data = item as? Data else {
            throw KeychainError.unhandled(status: status)
        }
        return try JSONDecoder().decode(TokenBundle.self, from: data)
    }

    /// Removes the token bundle from the keychain.
    static func delete() throws {
        let query: [String: Any] = [
            kSecClass as String: kSecClassGenericPassword,
            kSecAttrService as String: service,
            kSecAttrAccount as String: account
        ]
        let status = SecItemDelete(query as CFDictionary)
        guard status == errSecSuccess || status == errSecItemNotFound else {
            throw KeychainError.unhandled(status: status)
        }
    }
}

This helper encodes a TokenBundle to Data, stores it under a single key in the Keychain, and decodes it back to a TokenBundle when needed. It also includes a delete() method to clear the stored tokens when the user logs out.

Concurrency‑safe token management

When multiple network requests need a valid token simultaneously, we must avoid refreshing the token more than once at the same time.
Using a Swift actor ensures that only one refresh call happens concurrently.

import Foundation

/// Manages access and refresh tokens.
/// Uses an actor to serialize token access and refresh operations safely.
actor AuthManager {
    /// The currently running refresh task, if any.
    private var refreshTask: Task<TokenBundle, Error>?
    /// Cached token bundle loaded from the keychain.
    private var currentTokens: TokenBundle?

    init() {
        // Load any persisted tokens at initialization.
        currentTokens = try? KeychainService.load()
    }

    /// Returns a valid token bundle, refreshing if necessary.
    /// Throws if no tokens are available or if refresh fails.
    func validTokenBundle() async throws -> TokenBundle {
        // If a refresh is already in progress, await its result.
        if let task = refreshTask {
            return try await task.value
        }
        // No stored tokens means the user must log in.
        guard let tokens = currentTokens else {
            throw AuthError.noCredentials
        }
        // If not expired, return immediately.
        if !tokens.isExpired {
            return tokens
        }
        // Otherwise refresh.
        return try await refreshTokens()
    }

    /// Forces a refresh of the tokens regardless of expiration status.
    func refreshTokens() async throws -> TokenBundle {
        // If a refresh is already happening, await it.
        if let task = refreshTask {
            return try await task.value
        }
        // Ensure we have a refresh token.
        guard let tokens = currentTokens else {
            throw AuthError.noCredentials
        }
        // Create a new task to perform the refresh.
        let task = Task { () throws -> TokenBundle in
            defer { refreshTask = nil }
            // Build a request to your auth server’s token endpoint.
            // Replace api.example.com and path with your actual auth server and endpoint.
            var components = URLComponents()
            components.scheme = "https"
            components.host = "api.example.com" // change to your auth server
            components.path = "/oauth/token"
            var request = URLRequest(url: components.url!)
            request.httpMethod = "POST"
            request.setValue("application/json", forHTTPHeaderField: "Content-Type")
            let body: [String: String] = ["refresh_token": tokens.refreshToken]
            request.httpBody = try JSONEncoder().encode(body)
            // Perform the network call.
            let (data, response) = try await URLSession.shared.data(for: request)
            guard let httpResponse = response as? HTTPURLResponse,
                  (200..<300).contains(httpResponse.statusCode) else {
                throw AuthError.invalidCredentials
            }
            // Decode the new tokens.
            let newTokens = try JSONDecoder().decode(TokenBundle.self, from: data)
            // Persist and cache the tokens.
            try KeychainService.save(newTokens)
            currentTokens = newTokens
            return newTokens
        }
        // Store the in‑flight refresh task so concurrent callers reuse it.
        refreshTask = task
        return try await task.value
    }

    /// Clears stored tokens from memory and the keychain.
    func clearTokens() async throws {
        currentTokens = nil
        try KeychainService.delete()
    }
}

/// Errors thrown by `AuthManager`.
enum AuthError: Error {
    /// No tokens exist; the user must log in.
    case noCredentials
    /// Refresh failed or credentials are invalid.
    case invalidCredentials
}

This actor lazily loads tokens from the keychain at initialization.
When a valid token is requested, it either returns the cached token (if it hasn’t expired) or refreshes it by calling server’s refresh token endpoint.
The refresh process is protected by a single Task: if multiple calls to validTokenBundle() happen concurrently, they will all await the same refresh task.
If no tokens are stored or the refresh fails, AuthManager throws an AuthError we can react to and logout the user.

Adding auth token to endpoints that require it

We will update our Endpoint enum to have a variable indicating whether this endpoint requires authentication or not.

var requiresAuthentication: Bool {
    switch self {
    case .secureEndpoint: return true
    default : return false
    }
}

We will add the auth token when needed inside the NetworkClient func send<T: APIRequest>:

if request.endpoint.requiresAuthentication {
    let tokens = try await authManager.validTokenBundle()
    urlRequest.setValue("Bearer \(tokens.accessToken)", forHTTPHeaderField: "Authorization")
}

We will need an AuthManager object in our client:

final class NetworkClient {
    private let authManager: AuthManager

    init(authManager: AuthManager = AuthManager()) {
        self.authManager = authManager
    }

    func send<T: APIRequest>(_ request: T, allowRetry: Bool = true) async throws -> T.Response {
        ...
    }
}

Our send function requires a variable to know if a retry is allowed:

 func send<T: APIRequest>(_ request: T, allowRetry: Bool = true) async throws -> T.Response

Lastly let's check for auth errors and react accordingly:

if httpResponse.statusCode == 401 {
    guard allowRetry else {
        throw NetworkError.unauthorized // A new error type 
    }

    do {
        _ = try await authManager.refreshTokens()
        return try await send(request, allowRetry: false)
    } catch {
        // refresh failed -> force re-auth path
        // optionally: try? await authManager.clearTokens()
        throw error
    }
}

We are done!

You can checkout the full project on GitHub.

Freeing Up Xcode Garbage with DevCleaner

Mark Kazakov — Thu, 04 Dec 2025 13:48:22 +0000

If you’ve been using Xcode for a while, you’ve probably noticed that it eats up storage on your Mac at an alarming rate. Between old device/OS support files, derived data, caches, logs, and archives, it’s not unusual for Xcode to consume tens or even hundreds of gigabytes of disk space.

While you can manually dig through ~/Library/Developer/ to delete old files, it’s both risky and tedious.
That’s where DevCleaner for Xcode comes to the rescue. It's a free macOS utility that safely clears out unneeded Xcode data and helps you reclaim valuable disk space.

With a simple UI you can quickly remove all the various OS support files you no longer need since you've updated your iPhone, unneeded macOS and tvOS files, and more...

Managing Multiple Xcode Versions with Xcodes.app

Mark Kazakov — Sat, 06 Sep 2025 19:30:12 +0000

Apple releases new Xcode versions frequently, often requiring developers to switch between stable, beta, and older versions for compatibility testing. Xcodes.app is a simple yet powerful macOS application that allows you to:

Easily install and manage multiple versions of Xcode
Quickly switch between them
Keep track of updates

This tutorial walks you through installing Xcodes.app, downloading multiple Xcode versions, and using its Make Active feature to set your desired Xcode version system-wide.

Step 1: Install Xcodes

Download Xcodes

Visit https://www.xcodes.app and download the zip from the download link (github release page).
Extract the app and move it to your Applications folder.

Launch the App

On first launch, macOS may show a security prompt since it’s a third-party app.
Click Open.

Step 2: Sign In to Apple Developer Account (Optional but Recommended)

Some Xcode versions (especially betas) require authentication.

In Xcodes:

- Go to Xcodes → Settings → General → Sign In.

- Sign in with your Apple Developer credentials.

Step 3: Install Multiple Xcode Versions

Browse available versions (Stable, Beta, Older).
Click Install next to the version you need.
Xcodes handles downloading and extracting Xcode automatically, saving time compared to manual DMG/XIP processes.

Step 4: Using “Make Active”

What it does:

macOS uses the xcode-select tool to define which Xcode version is the default for command-line tools like xcodebuild, swift, or CocoaPods.
Normally, switching versions requires:
sudo xcode-select --switch /path/to/Xcode.app
With Xcodes, Make Active handles this for you.

How to use it:

Find the Xcode version you want to make the default.
Click Make Active.
All command-line tools (Terminal, CI scripts, Fastlane, etc.) now use that version automatically.

Original post:
https://www.promobile.dev/tutorials/xcodes-app

UIKit Previews in Xcode

Mark Kazakov — Sat, 24 May 2025 18:48:24 +0000

If you’ve been working with SwiftUI, you’re probably used to the live previews that allow you to see UI changes in real time. But for UIKit developers, the struggle has been real!

In Xcode 15 and iOS 17, Apple finally introduced UIKit Previews, making it possible to preview UIKit views without running the app on a simulator or device. This is a game changer for UIKit-based projects!

How to Use UIKit Previews in Xcode

UIKit previews work similarly to SwiftUI previews. You can wrap an UIView or UIViewController inside the #Preview macro.

Basic Example: Previewing a UILabel

Here’s a simple way to preview an UILabel:

import UIKit

class ViewController: UIViewController {

    func makeLabel() -> UILabel {
        let label = UILabel(frame: CGRect(x: 0, y: 0, width: 200, height: 200))
        label.backgroundColor = .red
        label.text = "Hello, World!"
        label.textAlignment = .center
        return label
    }
}

@available(iOS 17, *)
#Preview {
    ViewController().makeLabel()
}

What’s happening here?

• makeLabel() creates a simple UILabel with a red background.

• #Preview { ViewController().makeLabel() } renders it directly in the Xcode canvas, just like SwiftUI previews.

• No need to run the app - you can see the label instantly!

Previewing a Custom UIView

Most of the time, we’re not just dealing with simple labels. Let’s wrap a custom UIView inside a preview:

import UIKit

class CustomView: UIView {
    override init(frame: CGRect) {
        super.init(frame: frame)
        setupUI()
    }

    required init?(coder: NSCoder) {
        fatalError("init(coder:) has not been implemented")
    }

    private func setupUI() {
        backgroundColor = .blue

        let label = UILabel()
        label.text = "UIKit Previews! 🚀"
        label.textColor = .white
        label.textAlignment = .center
        label.translatesAutoresizingMaskIntoConstraints = false

        addSubview(label)

        NSLayoutConstraint.activate([
            label.centerXAnchor.constraint(equalTo: centerXAnchor),
            label.centerYAnchor.constraint(equalTo: centerYAnchor)
        ])
    }
}

@available(iOS 17, *)
#Preview {
    CustomView(frame: CGRect(x: 0, y: 0, width: 200, height: 200))
}

Previewing a UIViewController

You can also preview a UIViewController using #Preview:

import UIKit

class MyViewController: UIViewController {
    override func viewDidLoad() {
        super.viewDidLoad()
        view.backgroundColor = .systemGreen
    }
}

@available(iOS 17, *)
#Preview {
    MyViewController()
}

Summary

UIKit Previews introduced in Xcode 15 are a huge step forward for UIKit development. Here’s why you should start using them:

No more waiting for the simulator to launch.
Real-time preview of UIKit views and view controllers.
Faster iteration and development.

If you’re still maintaining a UIKit project, this feature will save you so much time!

You can examine the code in the Github repo.

Modern Networking in iOS with URLSession and async/await: A Practical Guide

Mark Kazakov — Sat, 05 Apr 2025 19:00:50 +0000

Networking is at the core of most iOS apps. Almost every modern application needs to talk to remote services, fetch or send data, and present fetched information in real time. This makes it essential to have a reliable, safe, and maintainable approach to performing HTTP requests.

Apple provides URLSession as the standard way to handle network communication in iOS. It's robust, battle-tested, and highly configurable. Whether you need to fetch JSON, download files, or upload data, URLSession is the foundation you'll build on. In the past, developers relied on completion handlers or Combine to manage these asynchronous calls. While functional, those methods introduced complexity and verbosity.

Enter async/await, introduced in Swift 5.5. This modern concurrency model transforms asynchronous code into something that reads and behaves like synchronous code. With async/await, networking becomes:

Easier to read and maintain
Safer and less error-prone
More Swift-native and familiar

This tutorial will walk you through building a modern, fully async network layer using URLSession and async/await and display the fetched data in a SwiftUI list.

The APIs We’ll Use

The following public testing APIs will be used

GET https://jsonplaceholder.typicode.com/users
GET https://jsonplaceholder.typicode.com/posts
GET https://jsonplaceholder.typicode.com/comments

They return dummy data, which we will use to display lists of users, posts and comments

Step 1: Create the Models

Before we can decode any JSON, we need to define some models that mirror the structure of the API responses. In Swift, we use the Codable protocol to enable easy JSON parsing and Identifiable to make integration with SwiftUI lists seamless.

Codable allows us to convert between JSON data and Swift structs automatically.
Identifiable is required for SwiftUI's List view to uniquely identify each element in a collection.

struct User: Codable, Identifiable {
    let id: Int
    let name: String
    let username: String
    let email: String
}

struct Post: Codable, Identifiable {
    let id: Int
    let userId: Int
    let title: String
    let body: String
}

struct Comment: Codable, Identifiable {
    let id: Int
    let postId: Int
    let name: String
    let email: String
    let body: String
}

Step 2: Create the Networking Layer

We use two powerful Swift features: enums and generics to create a scalable and maintainable networking layer.

enum Endpoint

The Endpoint enum encapsulates all supported API paths in a single type-safe structure.
Each case in the enum maps to a specific endpoint (e.g. .users, .comments(postId:)), avoiding stringly-typed URLs scattered throughout your code.
It helps centralize logic like HTTP method selection and URL path construction.

enum Endpoint {
    case users
    case posts
    case comments(postId: Int)

    var path: String {
        switch self {
        case .users: return "/users"
        case .posts: return "/posts"
        case .comments(let postId): return "/posts/\(postId)/comments"
        }
    }

    var method: HTTPMethod {
        switch self {
        case .users, .posts, .comments: return .GET
        }
    }
}

enum NetworkError

Structured error handling: Clearly categorizes different failure scenarios such as URL construction issues, server errors, and decoding problems.
Better debugging: By distinguishing error types, you can display user-friendly messages or handle specific issues differently (e.g., retry on .serverError).
Swift-native: Conforms to Swift’s Error protocol and integrates seamlessly with try/catch.

enum NetworkError: Error {
    case invalidURL
    case decodingError
    case serverError(statusCode: Int)
    case unknown(Error)
}

enum HTTPMethod

enum HTTPMethod: String {
    case GET, POST, PUT, DELETE
}

Clarity: This enum defines common HTTP methods as strongly-typed cases instead of using raw strings like "GET" or "POST" throughout your code.
Safety: Prevents typos and allows the compiler to catch invalid method usage.
Scalability: Easy to extend by adding methods like .PATCH or .HEAD later.

protocol APIRequest

protocol APIRequest {
    associatedtype Response: Decodable
    var endpoint: Endpoint { get }
}

extension APIRequest {
    var url: URL? {
        var components = URLComponents()
        components.scheme = "https"
        components.host = "jsonplaceholder.typicode.com"
        components.path = endpoint.path
        return components.url
    }
}

Generic Request Definition: This protocol defines the structure for any type of API request.
associatedtype Response: This allows each request to specify the exact data type it expects to receive. For example, one request might return [User], another might return [Post].
Decodable constraint: Ensures the response can be parsed from JSON using Swift’s Decodable system.
Extensibility: By conforming to this protocol, you can add any number of request types (GetPostsRequest, GetCommentsRequest, etc.) without modifying the networking logic.
Extension with default URL construction: Instead of requiring every request to build its own URL, we use a protocol extension to provide a shared implementation.
Encapsulation of base URL logic: Centralizes the host and scheme configuration (e.g. "https://jsonplaceholder.typicode.com"), keeping the logic DRY (Don't Repeat Yourself).
Reusability: Any request that conforms to APIRequest gets this default URL computation for free.

struct GetUserRequest: APIRequest {
    typealias Response = [User]
    let endpoint: Endpoint = .users
}

struct GetPostsRequest: APIRequest {
    typealias Response = [Post]
    let endpoint: Endpoint = .posts
}

struct GetCommentsRequest: APIRequest {
    typealias Response = [Comment]
    let endpoint: Endpoint = .users
}

func send

This is a generic function that works with any type conforming to APIRequest, as long as it defines what type of response it expects.
Using generics allows the networking client to remain decoupled from specific model types like User, Post, or Comment.
This makes the network layer reusable and extensible: just create new request types for different endpoints and the same send function will work with them.
async: Indicates this function performs asynchronous work.
throws: Indicates this function can fail and will throw errors you need to handle.
Returns: The decoded result of the API call, e.g., [User] or [Post].

final class NetworkClient {
    func send<T: APIRequest>(_ request: T) async throws -> T.Response {
        guard let url = request.url else {
            throw NetworkError.invalidURL
        }

        var urlRequest = URLRequest(url: url)
        urlRequest.httpMethod = request.endpoint.method.rawValue

        let (data, response): (Data, URLResponse)
        do {
            (data, response) = try await URLSession.shared.data(for: urlRequest)
        } catch {
            throw NetworkError.unknown(error)
        }

        guard let httpResponse = response as? HTTPURLResponse else {
            throw NetworkError.unknown(NSError(domain: "Invalid response", code: 0))
        }

        guard (200..<300).contains(httpResponse.statusCode) else {
            throw NetworkError.serverError(statusCode: httpResponse.statusCode)
        }

        do {
            return try JSONDecoder().decode(T.Response.self, from: data)
        } catch {
            throw NetworkError.decodingError
        }
    }
}

In the above snippet, note the:

(data, response) = try await URLSession.shared.data(for: urlRequest)

The call is made asynchronously (as promised by async) thanks to await.
It suspends execution until the response is received, meaning the next line in the code won't run until await is done.
If any network error occurs (e.g. no connection, timeout), it throws — and we catch it below. Wrapping the error into our custom .unknown error case, preserving the original error for context.

} catch {
    throw NetworkError.unknown(error)
}

Next, we validate the response:

guard let httpResponse = response as? HTTPURLResponse else {
    throw NetworkError.unknown(NSError(domain: "Invalid response", code: 0))
}

guard (200..<300).contains(httpResponse.statusCode) else {
    throw NetworkError.serverError(statusCode: httpResponse.statusCode)
}

First checks if the response is an HTTP response.
Then ensures the HTTP status code is in the success range (200–299).
If not, throws a .serverError(statusCode:), making it easier to handle in UI or logs later.

After validation, we are trying to decode the response:

return try JSONDecoder().decode(T.Response.self, from: data)

Tries to decode the received Data into the expected response type (T.Response) using Swift’s Decodable.
If decoding fails, it’s caught and rethrown as our custom .decodingError.

} catch {
    throw NetworkError.decodingError
}

Step 3: Integrating with SwiftUI

ViewModel

import SwiftUI

@MainActor
class UsersViewModel: ObservableObject {
    @Published var users: [User] = []
    @Published var isLoading = false
    @Published var errorMessage: String?

    private let client = NetworkClient()

    func loadUsers() async {
        isLoading = true
        errorMessage = nil

        do {
            let users = try await client.send(GetUsersRequest())
            self.users = users
        } catch {
            errorMessage = "Failed to load users: \(error.localizedDescription)"
        }

        isLoading = false
    }
}

View

import SwiftUI

struct UsersView: View {
    @StateObject private var viewModel = UsersViewModel()

    var body: some View {
        NavigationView {
            Group {
                if viewModel.isLoading {
                    ProgressView("Loading...")
                } else if let error = viewModel.errorMessage {
                    Text(error).foregroundColor(.red)
                } else {
                    List(viewModel.users) { user in
                        VStack(alignment: .leading) {
                            Text(user.name).bold()
                            Text(user.email).font(.subheadline).foregroundColor(.gray)
                        }
                    }
                }
            }
            .navigationTitle("Users")
            .task {
                await viewModel.loadUsers()
            }
        }
    }
}

And we are done!

You can checkout the full project on GitHub.

You can read part II of this subject - dealing with auth tokens here:
https://dev.to/markkazakov/modern-networking-in-ios-with-urlsession-and-asyncawait-part-2-1d3i

Advanced Jetpack Compose Previews

Mark Kazakov — Thu, 27 Mar 2025 19:55:56 +0000

Jetpack Compose provides powerful tools to preview UI components without running the app on a device or emulator. The @Preview annotation is a key feature that enables developers to visualize their UI in different configurations. By using decorators (parameters), such as uiMode, fontScale and more, you can quickly test your UI under various conditions.

For this tutorial, let's consider the following data class and a list of data entries:

data class StarWarsMovie(
    val title: String,
    val releaseYear: String,
    val imageRes: Int
)

val movies = listOf(
    StarWarsMovie("A New Hope", "1977", R.drawable.a_new_hope),
    StarWarsMovie("The Empire Strikes Back", "1980", R.drawable.empire_strikes_back),
    StarWarsMovie("Return of the Jedi", "1983", R.drawable.return_of_the_jedi),
    StarWarsMovie("The Phantom Menace", "1999", R.drawable.phantom_menace),
    StarWarsMovie("Attack of the Clones", "2002", R.drawable.attack_of_the_clones),
    StarWarsMovie("Revenge of the Sith", "2005", R.drawable.revenge_of_the_sith),
    StarWarsMovie("The Force Awakens", "2015", R.drawable.force_awakens),
    StarWarsMovie("The Last Jedi", "2017", R.drawable.last_jedi),
    StarWarsMovie("The Rise of Skywalker", "2019", R.drawable.rise_of_skywalker)
)

Basic Usage of @Preview

The @Preview annotation is used in Jetpack Compose to render a Composable function inside the Android Studio preview window. A basic example looks like this:

@Preview
@Composable
fun StarWarsMoviePreview() {
    StarWarsMovieCard(movie = movies[1])
}

This will render a simple list entry for a Star Wars movie in the default light mode, default font size, and a standard device configuration.

Preview Parameters (Decorators)

Jetpack Compose allows you to customize previews using additional parameters in the @Preview annotation. These parameters make it easier to test different UI states without manually changing device settings.

1. Dark Mode Preview

To preview your UI in dark mode, use the uiMode parameter and wrap the component inside your theme:

@Preview(name = "Night mode", uiMode = UI_MODE_NIGHT_YES, showBackground = true)
@Composable
fun StarWarsMovieDarkModePreview() {
    AdvancedComposePreviewsTheme {
        Box(modifier = Modifier.padding(8.dp)) {
            StarWarsMovieCard(movie = movies[2])
        }
    }
}

Also note the name parameter, which allows you to set a title above the preview:

2. Font Scale Preview

To test how your UI adapts to different font scales (for accessibility testing), use fontScale:

@Preview(name = "Large font", fontScale = 1.5f)
@Composable
fun StarWarsMovieLargeFontPreview() {
    StarWarsMovieCard(movie = movies[3])
}

This is useful to ensure text elements are not cut off and layouts adjust properly when the user increases text size in system settings.

3. Multiple Device Previews

You can specify different devices for testing:

@Preview(device = Devices.PIXEL_4)
@Preview(device = Devices.NEXUS_7)
@Composable
fun StarWarsMovieMultipleDevicesPreview() {
    StarWarsMovieCard(movie = movies[4])
}

This ensures that your UI is responsive across various screen sizes.

4. Custom Background Color

To set a background color for better visibility in previews, use backgroundColor:

@Preview(backgroundColor = 0xFFFF0000, showBackground = true)
@Composable
fun StarWarsMovieWithBackgroundPreview() {
    Box(modifier = Modifier.padding(8.dp)) {
        StarWarsMovieCard(movie = movies[5])
    }
}

The backgroundColor parameter in the @Preview annotation accepts a hexadecimal ARGB color value - specifically, a Long formatted as 0xAARRGGBB:

5. Show System UI Elements

You can enable showing system UI elements, such as status bars and navigation bars, using showSystemUi:

@Preview(showSystemUi = true)
@Composable
fun StarWarsMovieWithSystemUIPreview() {
    StarWarsMovieList(modifier = Modifier.padding(top = 40.dp))
}

Testing Edge Cases

If you have conditional view presentation logic in your compose code, it is a good idea to have some previews with those cases to ensure nothing breaks when you make changes.

Consider the following card that presents the Star Wars movie using a ConstraintLayout:

@Composable
fun StarWarsMovieCardWithConditions(movie: StarWarsMovie) {
    Card(
        modifier = Modifier
            .fillMaxWidth(),
        elevation = CardDefaults.cardElevation(defaultElevation = 4.dp),
        colors = CardDefaults.cardColors(containerColor = MaterialTheme.colorScheme.surfaceContainer)
    ) {
        ConstraintLayout(
            modifier = Modifier
                .fillMaxWidth()
        ) {
            val (image, titleAndCount, chevron) = createRefs()
            Image(
                modifier = Modifier
                    .constrainAs(image) {
                        start.linkTo(parent.start)
                        top.linkTo(parent.top)
                        bottom.linkTo(parent.bottom)
                    },
                painter = painterResource(id = movie.imageRes),
                contentDescription = "${movie.title} Poster",
            )
            Column(
                modifier = Modifier
                    .constrainAs(titleAndCount) {
                        top.linkTo(parent.top)
                        start.linkTo(image.end)
                        bottom.linkTo(parent.bottom)
                        // Notice the issue here, if the chevron is not present the view breaks
                        end.linkTo(chevron.start)
                        width = Dimension.fillToConstraints
                    },
            ) {
                Text(text = movie.title, style = MaterialTheme.typography.titleLarge)
                Text(
                    text = "Released: ${movie.releaseYear}",
                    style = MaterialTheme.typography.bodyMedium
                )
            }
            if (movie.title.contains("Force")) {
                Image(
                    imageVector = Icons.AutoMirrored.Filled.KeyboardArrowRight,
                    modifier = Modifier
                        .constrainAs(chevron) {
                            end.linkTo(parent.end)
                            top.linkTo(parent.top)
                            bottom.linkTo(parent.bottom)
                        },
                    alignment = Alignment.CenterEnd,
                    contentDescription = null
                )
            }
        }
    }
}

The part:

end.linkTo(chevron.start)

Could be problematic because the chevron is not always rendered. In cases where the chevron is present, everything works well:

@Preview
@Composable
fun StarWarsMovieCardWithConditionsPreview() {
    StarWarsMovieCardWithConditions(movie = movies[6])
}

But in cases where the chevron is not rendered our view will be broken:

@Preview
@Composable
fun StarWarsMovieCardWithConditionsFailPreview() {
    StarWarsMovieCardWithConditions(movie = movies[7])
}

By having previews that cover all conditional cases, we can catch this bug very quickly.

For the full project please check out the github repo.