A+ programming moments

How to use custom variable fonts in UIKit

Thu, 13 Nov 2025 21:39:00 +0000

If you go with the solution 1 to the previously discussed issue, I strongly suggest you embed variable fonts inside your app. Taking a look at Google’s Roboto font family, it has 54 static fonts which takes up ~8MB. There are just two variable font files though, each less than 500kB.

These two files contains condensed and standard widths, 9 different weights in both normal and italic styles thus producing 54 different font variants. That is bloody awesome, if you ask me.

But how do you use them in iOS app?

First of course, you check the usage license and only then dive into technical details:

You can use them in your products & projects – print or digital, commercial or otherwise.

Now add the two files into your project and get ready for some coding.

Debug availability of font features

To figure out what fonts are available to your and how exactly they are called inside CoreText / UIKit, call this simple method anywhere in your app:

public extension UIFont {
	static func listAvailableFonts() {
		for family in UIFont.familyNames {
			print("\(family)")
			
			for name in UIFont.fontNames(forFamilyName: family) {
				print("== \(name)")
			}
		}
	}

You’ll see that family name is Roboto and specific fontName values are:

 Roboto	//	font-family
 == Roboto-Regular
 == Roboto-Italic
 == Roboto-Thin
 == Roboto-ThinItalic
 == Roboto-ExtraLight
 == Roboto-ExtraLightItalic
 ...

Now, we need to figure out what OpenType’s axis tags are present for these fonts. OpenType docs are incredibly complex; it took an entire day just to get my head around all this and I feel like I know just few percents of it all.

This is how you can write out axis tag config for all 54 font variants, using familyName: "Roboto" argument:

public extension UIFont {
	static func printVariationAxes(familyName family: String, size: CGFloat = 18) {
		for name in UIFont.fontNames(forFamilyName: family) {
			printVariationAxes(fontName: name, size: size)
		}
	}

	/// Print all available axes in the given font
	static func printVariationAxes(fontName: String, size: CGFloat = 18) {
		let descriptor = UIFontDescriptor(name: fontName, size: size)
		
		let font = UIFont(descriptor: descriptor, size: size)
		
		if let axes = CTFontCopyVariationAxes(font as CTFont) as? [[String: Any]] {
			print("\n=== Variation Axes for \(fontName) ===")
			for axis in axes {
				print("Axis: \(axis)")
				if let identifier = axis[kCTFontVariationAxisIdentifierKey as String] as? Int {
					print("  Identifier (decimal): \(identifier)")
					print("  Identifier (hex): 0x\(String(identifier, radix: 16))")
				}
				if let name = axis[kCTFontVariationAxisNameKey as String] {
					print("  Name: \(name)")
				}
				if let minValue = axis[kCTFontVariationAxisMinimumValueKey as String] {
					print("  Min: \(minValue)")
				}
				if let maxValue = axis[kCTFontVariationAxisMaximumValueKey as String] {
					print("  Max: \(maxValue)")
				}
				if let defaultValue = axis[kCTFontVariationAxisDefaultValueKey as String] {
					print("  Default: \(defaultValue)")
				}
				print("")
			}
		} else {
			print("No variation axes found (not a variable font)")
		}
	}
}

Here’s an example output for one font:

 === Variation Axes for Roboto-ThinItalic ===
 Axis: ["NSCTVariationAxisIdentifier": 2003265652, "NSCTVariationAxisDefaultValue": 400, "NSCTVariationAxisName": Weight, "NSCTVariationAxisMaximumValue": 900, "NSCTVariationAxisMinimumValue": 100]
 Identifier (decimal): 2003265652
 Identifier (hex): 0x77676874
 Name: Weight
 Min: 100
 Max: 900
 Default: 400
 
 Axis: ["NSCTVariationAxisName": Width, "NSCTVariationAxisIdentifier": 2003072104, "NSCTVariationAxisDefaultValue": 100, "NSCTVariationAxisMaximumValue": 100, "NSCTVariationAxisMinimumValue": 75]
 Identifier (decimal): 2003072104
 Identifier (hex): 0x77647468
 Name: Width
 Min: 75
 Max: 100
 Default: 100

So it has weights from 100 to 900 and widths from 75 to 100.

Couple of useful extensions

I used Claude Code to summarize all 54 of these and produce much of the ensuing enums I will write about. Right of the bat, we will need CoreText framework:

import UIKit
import CoreText

Axis tags

OpenType variable font axis tags that we need are listed below:

enum OpenTypeAxisTag: Int {
	/// Width axis ('wdth') - Controls the width of glyphs
	/// Range varies by font; Roboto supports 75-100
	case width = 0x77647468  // 'wdth'
	
	/// Weight axis ('wght') - Controls the weight/boldness of glyphs
	/// Range varies by font; Roboto supports 100-900
	case weight = 0x77676874  // 'wght'
	
	/// Italic axis ('ital') - Binary italic on/off (0 or 1)
	case italic = 0x6974616C  // 'ital'
	
	/// Slant axis ('slnt') - Oblique slant angle in degrees
	case slant = 0x736C6E74  // 'slnt'
	
	/// Optical size axis ('opsz') - Optimizes rendering for different sizes
	case opticalSize = 0x6F70737A  // 'opsz'
	
	/// Grade axis ('GRAD') - Adjusts weight while preserving width
	case grade = 0x47524144  // 'GRAD'
	
	var nsNumber: NSNumber {
		NSNumber(value: self.rawValue)
	}
}

We will later reference these values to force CTFont match-up to appropriate font variant. I included more than the three I need. Digging-out these specific values is super convoluted thus keeping them here for possible future use.

Roboto declarations

Roboto has condensed and standard widths, per axis tag printout from before.

extension UIFont {
	enum Roboto {
		enum Width: CGFloat, CaseIterable {
			/// Condensed width (75) - Minimum width supported by Roboto
			case condensed = 75
			
			/// Normal width (100) - Maximum width supported by Roboto (default)
			case normal = 100
			
			var value: CGFloat { rawValue }
		}
	}
}

We should ideally use UIFont.Width in iOS16+ and these correspond to .condensed and .standard values. Because my app at hand still supports iOS 15+ I opted for this enum.

Other font families might have more widths; per OpenType spec, allowed numerical values are between 50 and 200. I’m not 100% sure these are correct values but here’s a possible map:

@available(iOS 16, *)
private extension UIFont.Width {
	var numericValue: CGFloat {
		switch self {
			case .compressed:	return 50
				
			case .condensed:	return 75
				
			case .standard:		return 100
				
			case .expanded: 	return 150

			default:
				// Handle unknown widths by returning standard.
				return 100
		}
	}
}

We don’t need separate enum for 9 weights as they all correspond to UIFont.Weight values although Google uses slightly different font names:

 - Thin ⇥ `.ultraLight`
 - ExtraLight ⇥ `.thin`
 - Light ⇥ `.light`
 - Regular ⇥ `.regular`
 - Medium ⇥ `.medium`
 - Semibold ⇥ `.semibold`
 - Bold ⇥ `.bold`
 - ExtraBold ⇥ `.heavy`
 - Black ⇥ `.black`

After adding few more helpful declarations:

extension UIFont.Weight: @retroactive CaseIterable {
	public static var allCases: [UIFont.Weight] {
		return [.ultraLight, .thin, .light, .regular, .medium, .semibold, .bold, .heavy, .black]
	}
}

private extension UIFont.Weight {
	var numericValue: CGFloat {
		switch self {
			case .ultraLight:	return 100
			case .thin:			return 200
			case .light:		return 300
			case .regular:		return 400
			case .medium:		return 500
			case .semibold:		return 600
			case .bold:			return 700
			case .heavy:		return 800
			case .black:		return 900

			default:
				// Handle unknown weights by returning regular.
				return 400
		}
	}
}

we are ready to build actual font instances.

Roboto

Ideally one would use UIFontDescriptor APIs to build the font attributes dictionary and create the font but for the life of me I couldn’t figure out how to make it work.

The approach below, using CoreText APIs did work.

extension UIFont {
	static func roboto(
		size: CGFloat,
		width: Roboto.Width = .normal,
		weight: UIFont.Weight = .regular,
		italic: Bool = false
	) -> UIFont {
		// Use the registered font names
		let baseFontName = italic ? "Roboto-Italic" : "Roboto"
		
		// Create base font
		guard let baseFont = UIFont(name: baseFontName, size: size) else {
			print("Warning: Roboto font not found")
			return UIFont.systemFont(ofSize: size, weight: weight)
		}
		
		// Create variation dictionary using enum
		let variations: [NSNumber: NSNumber] = [
			OpenTypeAxisTag.width.nsNumber: NSNumber(value: Float(width.value)),
			OpenTypeAxisTag.weight.nsNumber: NSNumber(value: Float(weight.numericValue))
		]
		
		// Create new font with variations using CoreText
		let variedFont = CTFontCreateCopyWithAttributes(
			baseFont,
			size,
			nil,
			CTFontDescriptorCreateWithAttributes([
				kCTFontVariationAttribute: variations
			] as CFDictionary)
		) as UIFont  // CTFont is toll-free bridged with UIFont
		
		return variedFont
	}
}

And now it’s so simple to create whatever combination you want:

let font1 = UIFont.roboto(size: 18, width: .condensed, weight: .black, italic: true)

let condensed = UIFont.roboto(size: 16, width: .condensed, weight: .regular)
let normal = UIFont.roboto(size: 16, width: .normal, weight: .regular)

You can use this debug method to build all possible UIFont instances:

extension UIFont {
	enum Roboto {
		static func generateAllFonts() -> [UIFont] {
			var arr: [UIFont] = []
			
			for width in Width.allCases {
				for weight in UIFont.Weight.allCases {
					arr.append(
						UIFont.roboto(size: 18, width: width, weight: weight, italic: false)
					)
				}
			}
			for width in Width.allCases {
				for weight in UIFont.Weight.allCases {
					arr.append(
						UIFont.roboto(size: 18, width: width, weight: weight, italic: true)
					)
				}
			}

			return arr
		}
	}
}

and then call it from any breakpoint to print out fontDescriptor for generated fonts:

(lldb) po UIFont.Roboto.generateAllFonts().map { $0.fontDescriptor }

Very simple way to validate your desired combination of weight+width+italic actually selected proper font variant.

This was far more complex than I expected it to be but it is what it is.

The Mystery of black italic condensed UIFont

Wed, 12 Nov 2025 17:39:00 +0000

Today I encountered frustrating issue while working on custom font styling in an iOS app. I needed to create italic system fonts with custom weight and width variants - something that should be straightforward with UIKit’s font descriptor API.
Spoiler alert: it wasn’t.

The Initial Setup

I started with what seemed like a reasonable approach - an extension to create italic fonts with custom weight and width:

private extension UIFont {
    @available(iOS 16.0, *)
    static func prepareItalicAttributes(for weight: Weight, width: Width) -> [UIFontDescriptor.AttributeName: Any] {
        return [
            UIFontDescriptor.AttributeName.traits: [
                UIFontDescriptor.TraitKey.weight: weight.rawValue,
                UIFontDescriptor.TraitKey.width: width.rawValue,
                UIFontDescriptor.TraitKey.symbolic: UIFontDescriptor.SymbolicTraits.traitItalic.rawValue
            ]
        ]
    }

    @available(iOS 16.0, *)
    static func italicSystemFont(ofSize size: CGFloat, weight: Weight, width: Width) -> UIFont {
        let attributes = prepareItalicAttributes(for: weight, width: width)
        let desc = UIFont.systemFont(ofSize: size).fontDescriptor.addingAttributes(attributes)
        return UIFont(descriptor: desc, size: size)
    }
}

This code failed to produce an italic condensed font. If I removed the .width trait from the dictionary, it would produce a condensed font. Something was clearly conflicting so I tried mixing things up hoping it would work.

Attempt 1: Apply Symbolic Traits Separately

Maybe setting symbolic as a raw value might be conflicting with the .width trait. I tried using withSymbolicTraits(_:) as a separate step:

@available(iOS 16.0, *)
static func italicSystemFont(ofSize size: CGFloat, weight: Weight, width: Width) -> UIFont {
    let attributes = prepareItalicAttributes(for: weight, width: width)
    var desc = UIFont.systemFont(ofSize: size).fontDescriptor.addingAttributes(attributes)
    
    // Apply italic trait separately
    if let italicDesc = desc.withSymbolicTraits(.traitItalic) {
        desc = italicDesc
    }
    
    return UIFont(descriptor: desc, size: size)
}

When I inspected the descriptors of the generated font:

// Before withSymbolicTraits
UICTFontDescriptor <0x6000027074e0> = {
    NSCTFontFeatureSettingsAttribute = ( ... );
    NSCTFontTraitsAttribute = {
        NSCTFontProportionTrait = 0;
        NSCTFontWeightTrait = "0.2300000041723251";
    };
    NSCTFontUIUsageAttribute = CTFontRegularUsage;
    NSFontSizeAttribute = 10;
}

// After withSymbolicTraits
UICTFontDescriptor <0x600002628ea0> = {
    NSCTFontFeatureSettingsAttribute = ( ... );
    NSCTFontUIUsageAttribute = CTFontObliqueUsage;
    NSFontNameAttribute = ".AppleSystemUIFontItalic";  // ⚠️ Concrete font name!
    NSFontSizeAttribute = 10;
}

The withSymbolicTraits method was discarding my custom weight and width traits entirely and replacing them with a concrete font name.

Attempt 2: Reverse the Order

Maybe if I applied the italic trait first, then added the weight and width back, it would work?

@available(iOS 16.0, *)
static func italicSystemFont(ofSize size: CGFloat, weight: Weight, width: Width) -> UIFont {
    var desc = UIFont.systemFont(ofSize: size).fontDescriptor
    
    // Apply italic trait first
    if let italicDesc = desc.withSymbolicTraits(.traitItalic) {
        desc = italicDesc
    }
    
    // Now reapply weight, width, and feature settings
    let attributes: [UIFontDescriptor.AttributeName: Any] = [
        .traits: [
            UIFontDescriptor.TraitKey.weight: weight.rawValue,
            UIFontDescriptor.TraitKey.width: width.rawValue
        ],
        .featureSettings: [ ... ]
    ]
    
    desc = desc.addingAttributes(attributes)
    return UIFont(descriptor: desc, size: size)
}

Nope. The italic was now being ignored. Looking at the final font descriptor:

UICTFontDescriptor <0x60000264bc60> = {
    NSCTFontFeatureSettingsAttribute = ( ... );
    NSCTFontUIUsageAttribute = CTFontMediumUsage;  // Not italic anymore!
    NSFontSizeAttribute = 10;
}

The weight/width traits were overriding the italic characteristic.

Attempt 3: Remove Concrete Font Names

What if I explicitly removed the concrete font name that withSymbolicTraits was adding and used a slant trait instead?

@available(iOS 16.0, *)
static func italicSystemFont(ofSize size: CGFloat, weight: Weight, width: Width) -> UIFont {
    var desc = UIFont.systemFont(ofSize: size).fontDescriptor
    
    if let italicDesc = desc.withSymbolicTraits(.traitItalic) {
        desc = italicDesc
    }
    
    var attributes = desc.fontAttributes
    attributes.removeValue(forKey: .name)
    
    attributes[.traits] = [
        UIFontDescriptor.TraitKey.weight: weight.rawValue,
        UIFontDescriptor.TraitKey.width: width.rawValue,
        UIFontDescriptor.TraitKey.slant: 0.07  // Explicit slant
    ]
    
    desc = UIFontDescriptor(fontAttributes: attributes)
    return UIFont(descriptor: desc, size: size)
}

This created a descriptor with all the right traits:

UICTFontDescriptor <0x6000026484e0> = {
    NSCTFontFeatureSettingsAttribute = ( ... );
    NSCTFontTraitsAttribute = {
        NSCTFontProportionTrait = "-0.2000000029802322";
        NSCTFontSlantTrait = "0.07000000000000001";
        NSCTFontWeightTrait = "0.4000000059604645";
    };
    NSCTFontUIUsageAttribute = CTFontRegularUsage;
    NSFontSizeAttribute = 32;
}

Perfect, right? But when I created the UIFont from this descriptor:

UICTFontDescriptor <0x6000026486c0> = {
    NSCTFontFeatureSettingsAttribute = ( ... );
    NSCTFontTraitsAttribute = {
        NSCTFontProportionTrait = "-0.2000000029802322";  // Width survived
    };
    NSCTFontUIUsageAttribute = CTFontBoldItalicUsage;  // iOS picked a concrete variant
    NSFontSizeAttribute = 32;
}

iOS resolved descriptor to the closest concrete system font variant (CTFontBoldItalicUsage) and discarded custom weight and slant.

Attempt 4: Direct Font Names

Maybe I could bypass the system font resolution entirely by using the actual San Francisco Pro font names:

let fontName: String
switch width {
case .compressed: fontName = ".SFCompact-RegularItalic"
case .condensed: fontName = ".SFCompact-RegularItalic" 
case .standard: fontName = ".SFUI-RegularItalic"
case .expanded: fontName = ".SFExpanded-RegularItalic"
default: fontName = ".SFUI-RegularItalic"
}

var desc = UIFontDescriptor(fontAttributes: [
    .name: fontName,
    .traits: [
        UIFontDescriptor.TraitKey.weight: weight.rawValue,
    ],
    .featureSettings: [ ... ]
])

The result?

(lldb) po UIFont(descriptor: desc, size: size).fontDescriptor
UICTFontDescriptor <0x60000261b300> = {
    NSFontNameAttribute = TimesNewRomanPSMT;
    NSFontSizeAttribute = 18;
}

Times New Roman, WTH…😵‍💫? Let me check actual font names:

static func listAvailableFonts() {
	for family in UIFont.familyNames {
		print("\(family)")

		for names in UIFont.fontNames(forFamilyName: family) {
			print("== \(names)")
		}
	}
}

San Francisco fonts were nowhere to be found so this was apparently futile to even attempt. That dot at the start of .AppleSystemUIFontItalic should’ve been hint enough.

Meh.

It indeed looked like I have encountered a fundamental limitation in UIKit’s font system where you cannot reliably combine custom weight, custom width, and italic traits simultaneously using UIFontDescriptor..?

On Apple Fonts page things are a bit vague. There’s…

Nine weights, including italics — and features like small caps, fractions, inferior and superior numerals, indices, arrows, and more — offer breadth and depth for precision typesetting.

and also:

SF Pro features nine weights, variable optical sizes for optimal legibility, four widths, and includes a rounded variant.

but those are two separate paragraphs. 🤷🏻‍♂️ So I opened FontBook app and filtered to SF Pro which yielded 45 fonts. There are all the required italic + width variants and there are width + weight variants but not a single “italic + width + weight” variant.

It seems the only way to achieve this would be to either:

Ship custom font files with all the weight/width/italic combinations just for this part of the app which would look ridiculous.
Accept the limitations and use only the combinations that iOS provides out of the box
Figure out a way to artificially italicize fonts but .slant already failed to do that. Not sure is there another way…

I’d love to hear ideas as I’m a bit out of them, for now.

Debugging an Xcodebuild hang, when the Swift compiler gets stuck

Mon, 03 Nov 2025 09:42:00 +0000

Building a complex iOS project with the Release scheme would hang indefinitely - no errors, no messages, just stuck. The Debug config worked fine but any Release configuration scheme would never complete. The build would appear to be running, but never finish.

The Investigation

Initial suspicion: circular dependencies between few local Swift packages that were shared among many other local packages (app has over 20 local packages and about 20+ more remote ones).

Step 1: Initial Database Lock Error

Running xcodebuild with verbose output:

xcodebuild build -project MeridianBet.xcodeproj -scheme XX \
  -destination 'generic/platform=iOS' -verbose 2>&1 | tee build.log

revealed the first issue — build database was locked:

error: unable to attach DB: database is locked
Possibly there are two concurrent builds running in the same filesystem location.

This was very unnecessary self-sabotage step as I had a build running in Xcode which I completely forgot and started another build in command line. Unrelated to the problem but thought to still include it as it’s super easy to run into this.

Thus here just kill all running builds and do Clean derived data.

rm -rf ~/Library/Developer/Xcode/DerivedData/MeridianBet-*

Step 2: The Real Hang

After cleaning, the build started but got stuck during package compilation. The process was running but making no progress.

Check process status:

# Check xcodebuild CPU usage
top -l 1 -pid <xcodebuild_pid> -stats pid,cpu,time,command

Result: xcodebuild at 0.0% CPU - not doing work, but not crashed either.

Find the hung compiler:

pgrep -fl swift

Result: Found swift-frontend process compiling XXData package, also at 0.0% CPU, running for 8+ minutes.

Step 3: Sampling the Hung Process

Used macOS sample command to see what the compiler was doing:

sample <swift-frontend-pid> 1 -file /tmp/swift_sample.txt
grep -A 30 "Call graph:" /tmp/swift_sample.txt

And there it was — the call stack showed an infinite recursion:

swift::GenericSpecializer::run()
  -> swift::trySpecializeApplyOfGeneric()
    -> swift::ReabstractionInfo::prepareAndCheck()
      -> swift::TypeMatcher::visitNominalType()
        -> Traversal::doIt(swift::Type)
          -> Traversal::visitBoundGenericType()
            -> Traversal::doIt(swift::Type) [RECURSING INFINITELY]

The Root Cause

The Swift compiler’s generic specializer was stuck in an infinite loop when trying to optimize complex generic types in the XXData package with -O -whole-module-optimization enabled.

This was not any of the stuff I suspected:

a circular package dependency
a deadlock between processes
a missing file or corrupted cache

It was:

Swift compiler bug with complex generic type traversal
Triggered only by whole-module optimization in Release builds
Specific to the XXData package (likely from auto-generated CoreData models)

The funny thing is — I did check each local package on their own. Each one built just fine. But I was using simple auto-generated schema you get when you open Package.swift in Xcode and that did not reveal the issue.

The Solution

Disable whole-module optimization for the problematic package by modifying XXData/Package.swift:

targets: [
    .target(
        name: "XXData",
        dependencies: [...],
        swiftSettings: [
            // Disable whole-module optimization to prevent compiler hang
            // during generic specialization in Release builds
            .unsafeFlags(["-Onone"], .when(configuration: .release))
        ]
    ),
]

DEBUG builds don’t enable whole-module optimization by default, so they never triggered the compiler bug. Release builds (-O -whole-module-optimization) attempted aggressive generic specialization, causing the infinite loop.

Here’s compact summary of key steps as some of these shell tools are quite new for me.

# 1. Clean derived data when build seems stuck
rm -rf ~/Library/Developer/Xcode/DerivedData/MeridianBet-*

# 2. Run build with verbose output in background
xcodebuild build -project Project.xcodeproj -scheme Scheme \
  -destination 'generic/platform=iOS' -verbose 2>&1 | tee build.log &

# 3. Monitor xcodebuild process
top -l 1 -pid <pid> -stats pid,cpu,time,command

# 4. Find hung Swift compiler
pgrep -fl swift

# 5. Sample the hung process to see call stack
sample <pid> 1 -file /tmp/sample.txt
grep -A 30 "Call graph:" /tmp/sample.txt

Lessons Learned

A hang at 0% CPU is different from a hang at 100% CPU - the former suggests waiting on something (or infinite recursion with tail call optimization), the latter suggests an infinite computation loop.
Verbose build output catches database/file lock issues that silent builds hide.
The sample command is invaluable for diagnosing hung processes on macOS.
Compiler bugs can manifest as build hangs - not all hangs are your code’s fault.
Per-package compiler flags are useful for working around compiler issues without affecting the entire project

I have to commend Claude Code (Sonnet 4.5) as invaluable helper for all of this analysis and investigation. Of all the various tasks one can delegate to LLM tools, those are where it truly excels.

AI sceptic in LLM adventure land

Sun, 15 Jun 2025 08:00:00 +0000

Ever since ChatGPT and its gen-AI ilk arrived, I have been very vocal and adamant that these are bullshit generators: they try to guess what you want and will continually hallucinate things until you say it’s OK. Depending on the body of existing knowledge they were trained on, they’ve becoming ever more successful in that endeavour. In the span of just few years and after countless energy spent on their development and training, those tools have become quite capable delivering amazing, believable results in certain areas.

I have deeply ingrained disdain of someone’s creativity being blatantly ripped off thus countless Studio Ghibli-like image generators make me sick. What I want people to do — what I consider useful and pragmatic use of time and engineering prowess — is building tools that help me create something new, tools that help me automate boring & tedious. To paraphrase an old tweet (I sadly long lost the link to it):

I don’t want AI that copies existing work of art. I want the AI that clean my dishes and iron my clothes so I can spend my time imagining new work of art.

I am an app developer. In my line of work, knowledge how to craft good Swift code and how to use iOS frameworks is (sometimes, not always) the tedious part of the job. Learning, testing, trying, reading documentation, trying, testing, reading more docs…rinse and repeat.
The final output, the app experience presented to people, that is the creation.

In the last several months, I have seen quite a few effusive posts from peers I respect about various AI/LLM tools in day to day work. People I personally know and those I know from Mastodon and general Apple-related blogs, conferences and podcasts. I don’t know will I ever be ready to live dangerously as Peter did but his gushing posts about usage of Claude Code and Gemini tipped me over to try it out.

I prepared. I read suggestions and recommendations from Peter, Philipp, Atharva, Rob, Thomas, I watched few presentations from Anthropic people.

Thus I installed NodeJS, installed Claude Code and paid $5 in credits to test the waters.

First thing Anthropic recommends to do is just ask Claude to analyze the existing project and tell you what it finds. It will use this analysis to create CLAUDE.md in project root and use it as initial context.

❶ Start by initializing Claude in the current folder

/init

and it goes chugging along. After few minutes, this was the result (slightly redacted by me):

# CLAUDE.md

This file provides guidance to Claude Code (claude.ai/code) when working with code in this repository.

## Development Commands

### Building and Running
- **Build**: Use Xcode (`⌘+B`) or `xcodebuild -scheme THE-APP-scheme -project THE-APP.xcodeproj build`
- **Run**: Use Xcode (`⌘+R`) or run from simulator
- **Target**: The app target is named "THE-APP" (internal name) but the scheme is "THE-APP-scheme"

### Testing
- No test files are currently present in the project
- Tests would typically be run via Xcode (`⌘+U`) or `xcodebuild test`

## Architecture Overview

### App Structure
This is a **SwiftUI-based iOS health and fitness app** with the following architectural layers:

1. **App Entry Point**: `THE-APPApp.swift` - Main app struct with dependency injection setup
2. **Navigation Flow**: `RootView.swift` → `AppState` manages flows (splash → onboarding → main app)
3. **Main Features**: Home tab, Progress tab, Settings tab, Store tab (Shopify integration)

### Key Architecture Patterns

**Observable Pattern**: The app uses Swift's `@Observable` macro extensively for state management:
- `DataStorage` - Central data store for model types
- `HealthKitService` - Manages HealthKit integration and background processing
- `AppState` - Handles app navigation flow states
- `ShopifyStore` - Manages e-commerce product data

**Dependency Injection**: Dependencies are injected through SwiftUI's environment system:
- `AppService` - API service layer (protocol with HTTP implementation)
- `DataStorage` - Observable data layer
- `HealthKitService` - Health data integration
- `PushNotificationService` - Firebase messaging

### Core Domains

**Health Data Integration**:
- `HealthKitService.swift` - HealthKit read/write operations
- `THE-APPHealthKit` package - Local SPM package for health data extraction
- Background processing tasks for health data sync
- Local notifications for workout detection

**Data Models** (in `Domain/`):
- [...redacted...] - Core domain events
- [...redacted...] - User interaction models
- DTOs in `NetworkEncoding/` for API communication

**UI Structure**:
- `UI/Main/` - Tab-based main interface (Home, Progress, Settings)
- `UI/Onboarding/` - User onboarding flow with coordinator pattern
- `UI/Components/` - Reusable SwiftUI components (cards, pickers, camera)

### External Dependencies

**Local Packages**:
- `THE-APPHealthKit` - Custom HealthKit wrapper
- `THE-APPMacros` - Swift macros for code generation

**Third-Party Libraries**:
- **Firebase**: Auth, Analytics, Crashlytics, Messaging (push notifications)
- **Shopify Mobile Buy SDK**: E-commerce integration
- **Pulse + Sentinel**: Network debugging and developer tools
- **Nuke/NukeUI**: Image loading and caching
- **SlidingRuler**: Custom UI component for weight/height selection

### Key Services

**Network Layer**:
- `HttpAppService` - Main API client with authorized requests
- `AuthorizedHttpClient` - Firebase token-based authentication
- Base URL configurable in `EnvironmentConfiguration`

**Background Processing**:
- Background app refresh for HealthKit sync
- Background processing tasks registered in Info.plist
- Local notifications for new event detection

### Configuration Notes

- **Bundle ID**: App uses `$(PRODUCT_BUNDLE_IDENTIFIER)` placeholder
- **Entitlements**: HealthKit, Background App Refresh, Push Notifications
- **Privacy**: Camera, Photo Library, HealthKit usage descriptions in Info.plist
- **Firebase**: Configured via `GoogleService-Info.plist`

### Development Notes

- Uses iOS 17+ minimum deployment target
- SwiftUI with iOS-only target (no watchOS/macOS)
- Supports both iPhone and iPad orientations
- Uses Firebase for backend services and Shopify for commerce

This floored me. 🤯
It is objectively good analysis, which cost me ~30 cents in API credits.

Think about onboarding new developers to the team and having to explain the structure of the project. Instead, you could just place them at the claude > prompt and let them ask whatever they want about the project, its structure, specific modules and files.

❷ Next, I wanted to see what code it can generate.
I had a product details screen in the Store tab that I barely started with. ShopifyStore.swift (@Observable data store file) fetches minimal set of product attributes through GraphQL that Shopify’s Buy SDK uses and SwiftUI displays the data. This project was my first time using GraphQL thus I had just proof of concept that read product’s id, title, price and featured_image.

I prompted with

look into ProductDetails.swift and plan improvements to show multiple images in horizontal scroller and full product description

I did not save the actual output it gave me here but it was the most elaborate and detailed plan I have seen in my professional career. A screen and a half of step-by-step changes in several files it thinks it should do, including implementing local cache for the loaded product instances.

Thus the next prompt:

sounds good. now implement it.

It added necessary nodes in the GraphQL query, implemented caching in ShopifyStore file, wrote almost perfect SwiftUI with horizontal scroller using TabView with page control dots below. It wrote internal description view and added read more button to it if the text was longer than 500 chars, using @State and @Binding as it should. It also updated Storefront.Product dummy init in #Preview.

Outside of few minor stylistic code style finesse, this was utterly perfect.

❸ I originally had product price fixed in bottom right corner and for some reason Claude rewrote that to be inline, above the product description. So

make the product-price view to be fixed and slightly inset from bottom right screen edge, so it stays visible as content is scrolled

It implemented the requested changes and wrote this report:

👏🏻 The code compiled and was pretty much perfect.

❹ OK, now was the time for real test. Since I had product listing and details working, I needed cart / checkout / payment.

This is serious task.
It starts with simple UI code to add cart toolbar item but then also need add/remove/clear/pay cart management methods, decide where to keep the Cart instance, how to model it + write entire Cart UI from scratch to use all that data and functionality. As developer, you need to read Shopify docs, understand what you need to build cart / cart items, what to call to continue with payout.

My prompt:

create Cart View in Store tab. add toolbar item to access cart. Use Shopify Buy SDK to make the cart, add/remove items to it, include basic management functionality, prepare payment checkout.

Note that that I did not tell it exact cart management functionality to implement as I wanted to see what it would do.

The output here was far from ideal. UI part of the task was really good, I did not see any problematic SwiftUI code. It chose 22pt body-font tall SFSymbol item for cart which was too large but other than that, all was fine.

It modeled CartItem on its own, using productVariantId as its id which is fine. All the add/remove/clear stuff was good. It added ＋/− to adjust quantities, summary and total price calculations and button to Pay. It placed transient cart instances in the ShopifyStore and used Observable framework in the View to access it.

But then completely borked by writing the code that uses Storefront.Checkout model type which does not exists. Buy V3 SDK uses Cart, not Checkout, not sure if Checkout exists in V2. Hence 20+ compilation errors across everything it generated.

this code is not good, there is no Checkout type in Buy SDK, you should use Cart. look up this URL as docs: https://github.com/Shopify/mobile-buy-sdk-ios

It asked for permission to access that URL and went to correct its mistakes. This time it used all the correct types. It also adjusted GraphQL product fetching queries to load product variant nodes and populate the CartItem it wrote.

There were still issues though: the GraphQL handling code is horrible closure in closure in closure in… mess. This confused it pretty much and it took several prompts to fix almost all of it where I would prompt it with:

these code lines {pasted code directly} yield this error: {paste compiler err}

One by one, this was slowly resolved and one particularly nasty bit I fixed by hand.

There was several deprecation warnings which it did not manage to resolve so I manually did those too. Eventually it all compiled and worked perfectly. Products were added to cart, called correct API to generate payment checkout URL which lead to typical Shopify payment screen you have probably seen online.

Somewhere near the end of this whole back and forth I was close to zeroing out the initial $5 worth of credits. But it was enough to convince me that this is worthwhile tool to pay for. Despite errors and shortcomings, it confirmed what many have wrote: this is an amplifier. You need to know the domain in order to validate what it did and guide it towards good result. But it speeds things up immensely and does away quite a lot with the tedious parts of the work I do.

I have never been happier to pay $200/month subscription for anything.

p.s. I also used Claude to build me proper blog archives on this very blog. This is based on Hugo generator where I never had time to read the docs and figure out proper incantations to create archives per year. It did that perfectly, with very little input from me. I was just describing what I need and gave it a link to Hugo docs. It also found a source of the annoying problem when archives/index.html would display Jackyll code. I mean…seriously — get this tool.

Objective-C framework callbacks in Swift 6

Thu, 07 Nov 2024 08:16:00 +0000

After upgrading all my active projects to Swift 6 language mode, I was bound to encounter some head-scratching edge cases. One of the weirdest ones was this runtime crash:

Thread 5 Queue : com.apple.root.default-qos (concurrent)
#0	0x00000001021243f8 in _dispatch_assert_queue_fail ()
#1	0x0000000102124384 in dispatch_assert_queue ()
#2	0x00000002444c63e0 in swift_task_isCurrentExecutorImpl ()
#3	0x0000000105a895b4 in closure #1 in AppDelegate.setupObjCFramework(using:flowIdentifier:) ()

It does not happen when app is compiled and ran in Swift 5 language mode. It is not caught by Swift 6 compiler at build time. But it regularly crashed on app start (in AppDelegate) when a method in Objective-C framework that has a callback closure is executed. Code like this:

objcInstance.setupObjCFramework(using: configFile) {
	[unowned self] err, string in	
}

None of the callback’s code is executed thus it seemed like it crashes just before it executes the callback, meaning — it’s a bug in the framework. Or so I thought.

After a lot of searching, I found the answer in Apple developer forums.

The high-level summary is:
· Swift 6 has inserted a run-time check to catch a concurrency issue that Swift 5 did not.
· This isn’t caught at compile time because of a Swift / Objective-C impedance mismatch.

So crash is due to this compiler-inserted runtime check because:

There is no guarantee anywhere that callback will be ran on the same thread from where it was called (main thread in my case) which is actually true here - you can see that the crash was in thread 5.
There is no guarantee — as it is — that callback closure itself is thread-safe. That check force-crashes to tell you that it may theoretically cause the data race even if such scenario never happens in practice.

The simplest solution? Mark the callback Sendable so compiler knows that whatever is done inside is thread-safe:

objcInstance.setupObjCFramework(using: configFile) {
	@Sendable [unowned self] err, string in	
}

Ideally the callback should have been marked as such in the Obj-C framework itself (with NS_SWIFT_SENDABLE) but that’s unlikely to happen in practice as most of these frameworks are relics that are not maintained anymore.

Background (multipart) file upload from iOS app

Thu, 17 Oct 2024 14:28:00 +0000

Apple has great API for this purpose: URLSessionUploadTask. Almost at the very top, Apple says:

Unlike data tasks, you can use upload tasks to upload content in the background.

This is not by accident. File uploads are the least-loved feature of any app as no one wants to wait nor look at progress bars. Thus the proper way to do this is to encapsulate upload functionality into a module which is somewhat independent from the rest of the app and maintain an ability to be informed how far along the transfer is, did it finish or encountered an error etc. That module should do its job in background, without ever bothering the user.

File Uploader module

As example, here’s a barebone module called FileUploader which can be extended to support any number of functionality your app needs.

final class FileUploader: NSObject {
	typealias Percentage = Float
	
	typealias ProgressHandler = @Sendable (Percentage) -> Void
	
	///	Gives nothing if success or encountered error.
	typealias CompletionHandler = @Sendable (Result<Void, Error>) -> Void

This is the least we need to make this usable. You need to keep an uploader reference somewhere in the app and that’s all we need as start.

Next — this module uses local instance of URLSession which is configured for background-enabled transfers:

private let backgroundIdentifier = "\( Bundle.identifier ).background"

private var urlSessionConfiguration: URLSessionConfiguration {
	let config = URLSessionConfiguration.background(withIdentifier: backgroundIdentifier)
	return config
}

.background(withIdentifier:) is important because it offers a great piece of functionality:

If an iOS app is terminated by the system and relaunched, the app can use the same identifier to create a new configuration object and session and to retrieve the status of transfers that were in progress at the time of termination.

Thus even if background transfers are slow and app is terminated by the system before they finish, you have the ability to pickup the pieces and continue on. That of course requires equally capable backend but the possibility is there.

Now, we can create a local instance, using the delegate variant of the API:

// Creating our custom URLSession instance. We'll do it lazily
// to enable 'self' to be passed as the session's delegate:
private lazy var urlSession = URLSession(
	configuration: urlSessionConfiguration,
	delegate: self,
	delegateQueue: .main
)

We need the delegate form to receive progress reports and we enforce the delivery of those reports on the OperationQueue.main since the most likely purpose is to update some piece of UI.

The minimal set of steps to upload the file is:

Prepare the file at some local URL.
Prepare the URLRequest with all the proper headers to perform the upload.
Start the transfer task, making sure it’s not blocking any UI or other work in the app.
Wait for progress / result delegate callbacks to update tracking UI.
Cleanup temporary stuff.

I’ll tackle steps 1/2 later in the article; first we need to prepare our module. Input point into the uploader will be a method that receives file URL and URLRequest + progress and result handlers:

func uploadFile(
	at fileURL: URL,
	to urlRequest: URLRequest,
	progressHandler: @escaping ProgressHandler,
	completionHandler: @escaping CompletionHandler
){
	...
}

FileUploader needs to keep track of upload-task’s .taskIdentifier versus supplied ProgressHandler and CompletionHandler, which is easy to do:

private var completionHandlersByTaskID = [Int : CompletionHandler]()
private var progressHandlersByTaskID = [Int : ProgressHandler]()

The body of the method is very straightforward:

let task = urlSession.uploadTask(with: urlRequest, fromFile: fileURL)

progressHandlersByTaskID[task.taskIdentifier] = progressHandler
completionHandlersByTaskID[task.taskIdentifier] = completionHandler

task.resume()

Tracking the uploads

We need to handle two delegate callbacks:

extension FileUploader: URLSessionTaskDelegate {
}

First — progress report:

func urlSession(
	_ session: URLSession,
	task: URLSessionTask,
	didSendBodyData bytesSent: Int64,
	totalBytesSent: Int64,
	totalBytesExpectedToSend: Int64
) {
	guard
		let handler = progressHandlersByTaskID[task.taskIdentifier],
	else {
		return
	}
	
	let progress = Double(totalBytesSent) / Double(totalBytesExpectedToSend)
	handler(Float(progress))
}

Second is result (completion) handler:

func urlSession(_ session: URLSession, task: URLSessionTask, didCompleteWithError err: (any Error)?) {
	guard
		let completionHandler = completionHandlersByTaskID[task.taskIdentifier],
	else {
		return
	}
	
	if let err {
		completionHandler(.failure(NetworkError.generalError(err)))
		return
	}
	
	completionHandler(.success(()))
}

Note that this is bare minimum. There are quite a few other delegate methods which are used in more advanced or edge-case scenarios.

Handling all possible cases and scenarios is far from easy; if you get into trouble I highly recommend Apple Developer Forums and especially threads [1], [2] and [3] where Quinn “The Eskimo!” responded with elaborate details.

Preparing the URLRequest

I have set this as input parameter because it’s quite often unrelated to the upload itself. You might be uploading to a password-protected or OAuth2-access-token backend. Thus you will need to handle all of that before you attempt the upload.

The only upload-related consideration: is your backend accepting

raw binary files or
it expects multipart-form-upload, a remnant of the old web-form type of transfers.

In the first case you just need to supply proper MIME type for Content-Type HTTP header and you’re done. As example, if you are uploading a JPEG photo, it would be this:

headers["Content-Type"] = "image/jpeg"

For the latter — you need to specify what’s your boundary which is simple UUID string. More on this in the next segment.

headers["Content-Type"] = "multipart/form-data; boundary=\( boundary )"

Preparing a local file is highly dependent on which of these two options your backend expects.

Preparing local file as upload source

Background file upload only works with local file instances. You can’t use Data nor InputStream — it must be a file on the disk.

Second important point is that the source file can’t be protected in any way. If you attempt to background upload a file with URLFileProtection other than .none you’ll be greeted with API MISUSE warning in the Xcode console.

Thus in the case of raw binary upload, I recommend to alter the file protection of the local file. Or copy the original file into some temporary location and remove file protection from that copy. Whatever the case, you should be using setAttributes(_:ofItemAtPath:) API:

let fm = FileManager.default

let localFilePath = realFileURL.path()

try fm.setAttributes(
	[.protectionKey: FileProtectionType.none],
	ofItemAtPath: localFilePath
)

Upload imitating web-forms is more involved.
The HTTP body of the URLRequest in this case is part-string, part-binary where using Data would be my first choice. But as I already said, Data as upload source is not an option. So we need to fake it: write-out upload contents to a temporary file and use that as UploadTask’ source.

let boundary = UUID().uuidString
// prepare URLRequest here

// now prepare file source
let realFileURL: URL // real file we want to upload
let localURL: URL // temporary fileURL
do {
	guard let outputStream = OutputStream(url: localURL, append: false) else {
		throw OutputStream.OutputStreamError.unableToCreateFile(localURL)
	}
	
	outputStream.open()
	try outputStream.write("--\( boundary )\r\n")
	try outputStream.write("Content-Disposition: form-data; name=\"file\"; filename=\"\( realFileURL.lastPathComponent )\"\r\n")
	try outputStream.write("Content-Type: image/jpeg\r\n\r\n")
	try outputStream.write(contentsOf: realFileURL)
	try outputStream.write("\r\n")
	try outputStream.write("--\( boundary )--\r\n")
	outputStream.close()
	
	//	now changefile protection to none
	try fm.setAttributes(
		[.protectionKey: FileProtectionType.none], 
		ofItemAtPath: localFilePath
	)

} catch {...}

Note that boundary used here must be the same one you used to prepare the Content-Type header for the URLRequest instance.

In the end, when file upload is done, don’t forget to cleanup all these temporary files.

I skipped over many things as creating a robust file uploader is a lot of work accompanied by a lot of testing. But for occasional uploads in somewhat controlled environment — your app to your backend — this is likely almost everything that you’ll need.

Stress-testing Core Data

Sat, 29 Jun 2024 11:18:00 +0000

I don’t think I wrote many apps in the last 10 years that did not involve Core Data. Apps without Core Data:

have just a handful of screens with no shared data between them
are demonstration / help type of app, basically a glorified user manual

But if app has any kind of model graph / data shared across multiple views, I choose Core Data without hesitation. Its strengths are in handling of relationships, its transparently cached and batched data fetching, seamless notification on insert/update of entity properties. The list of functionality you get for free is impressive.

One aspect that Core Data is not known for is raw performance. Vast majority of apps don’t really need super high persistence performance, certainly not any of the apps I have worked on. But it’s something to keep in mind and I’m always checking few things on physical devices:

CPU usage, especially time spent in code blocks which “lock” one CPU core
memory consumption

CPU usage became less important since iPhones started shipping with at least 2-core CPUs (do you remember which iPhone that was?). But memory is always a challenge and worth optimizing for; it does not matter if all the Core Data work you do happens on background threads if the app consumes GBs of memory. This can lead to excessive memory fragmentation, background app termination etc.

Which is why recent performance tests published on Emerge Tools blog picked my interest. They compared Realm vs Swift Data, two persistence solutions I have no experience with, despite Swift Data being essentially the same as Core Data. Enter Helge Heß who updated the test suit with pure Core Data test suite.

The numbers he posted were frankly shocking, way beyond anything I have ever seen in my own Core Data usage. Granted — I never attempted to insert 100k or 1M objects in one commit but I understand this is performance stress test. Thus let’s forgo common sense for a bit and analyze the performance results, which I re-ran on iPhone 14 Pro:

===============
CoreData: 100 Simple Objects
===============
User instantiation: 0.0008
Create users: 0.0129
DB file size: 0.03 MB
Delete all users: 0.0003

===============
CoreData: 1.000 Simple Objects
===============
User instantiation: 0.0035
Create users: 0.0102
DB file size: 0.03 MB
Delete all users: 0.0009

===============
CoreData: 10.000 Simple Objects
===============
User instantiation: 0.0248
Create users: 0.0745
DB file size: 0.03 MB
Delete all users: 0.0059

===============
CoreData: 100.000 Simple Objects
===============
User instantiation: 0.2107
Create users: 0.8991
DB file size: 7.22 MB
Delete all users: 0.0867

===============
CoreData: 1.000.000 Simple Objects
===============
User instantiation: 2.2695
Create users: 39.7839
DB file size: 72.46 MB
Delete all users: 3.8762

The problematic part is huge jump from 100k to 1M: 1s went to over 40 seconds. 40× more!

The memory graph is terrifying with over 1GB peak usage:

Looking at the test code, first thing I did was isolate each test. I see in the code that each tests begins with fresh database creation but I still wanted to completely isolate each test run. Thus I removed (commented) out all but Core Data tests:

func runAllPerformanceTests() {
    for num in [100, 1_000, 10_000, 100_000, 1_000_000] {
        coreUsersPerformanceTests(with: num)
    }

    deleteAllDatabaseFiles()
}

and also delete the app from device after each test. Results I posted above are after one such isolated run.

Let’s look at the test suite:

func coreUsersPerformanceTests(with usersCount: Int = 100_000) {
    let db = try! CoreUserDB()
    
    try! db.deleteAll()
    
    var users = [CoreUser]()
    logExecutionTime("User instantiation") {
        users = (0..<usersCount).compactMap { _ in CoreUser() }
    }
    
    logExecutionTime("Create users") {
        try! db.create(users)
    }
    
    logExecutionTime("Fetch users named `Jane` in age order") {
      ...
    }
    
    logExecutionTime("Rename users named `Jane` to `Wendy`") {
      ...
    }
    
    measureSize(of: db)
    
    logExecutionTime("Delete all users") {
        try! db.deleteAll()
    }
}

After creating the test database, test will

create X User instances in memory
Insert all instances to one NSManagedObjectContext and then save that context
Execute one test fetch returning subset of objects
Update one property (name) then save it
Measure database size on disk
Measure how long it takes to delete all previously created objects from database, using batch-delete API.

Main time sync, per logged times, is step 2. So let’s look at steps 1 and 2, since they are essentially one import operation:

var users = [CoreUser]()
users = (0..<usersCount).compactMap { _ in CoreUser() }

try! db.create(users)

or if we unpack the create(_) method:

var users = [CoreUser]()
users = (0..<usersCount).compactMap { _ in CoreUser() }

let context = ModelContext(container)
users.insertWithAllDependencies(into: context)
try context.save()

Let’s start optimizing this.

First thing I added is context.reset() after the save(). We don’t use all of these objects after creating them, we are actually doing a fetch for the next step so it makes no sense to keep all these objects in memory. This one line created a noticeable dip in the memory usage:

But main issue remains that we create 1 million records and save them all at once. Since we already know that 100k import is fast enough, let’s split this 1M into 10 commits with 100k records each:

let importer: (Int) -> Void = { limit in
	var users = [CoreUser]()
	logExecutionTime("User instantiation") {
		users = (0..<limit).compactMap { _ in CoreUser() }
	}
	
	logExecutionTime("Create users") {
		try! db.create(users)
	}
}

let chunk = 100_000
if usersCount <= chunk {
	importer(usersCount)
	
} else {
	logExecutionTime("Total \( usersCount ) User instantiation + Create") {
		let limit = usersCount / chunk
		for i in (0 ..< limit) {
			print("Chunk count: \( i )")
			importer(chunk)
		}
	}
}

This yields marked improvement in time, dropping from 40s to 17s:

===============
CoreData: 1.000.000 Simple Objects
===============
Total 1000000 User instantiation + Create: 17.0897
190 users named `Jane`
Fetch users named `Jane` in age order: 0.1683
190 users named `Jane` being renamed to `Wendy`
190 users renamed to `Wendy`
Rename users named `Jane` to `Wendy`: 0.0617
DB file size: 72.70 MB
Delete all users: 2.7786

It’s more important what happens with memory usage, which peaks around 350 MB, a sharp drop from 1050 MB:

Even though this is impressive improvement, that import code is not really optimal Core Data; not even proper for Core Data.

There’s literally no sense to create ManagedObject outside ManagedObjectContext if you eventually want to save that object.
Further — Core Data’s primary good practice is to perform all operations related to it inside its own queue meaning we should do everything import-related inside perform or performAndWait methods.

let importer2: (Int) -> Void = { limit in
	let context = db.context
	context.performAndWait {
		logExecutionTime("User instantiation") {
			(0..<limit).forEach { _ in
				let _ = CoreUser(moc: context)
			}
		}
		
		logExecutionTime("Save users") {
			try! context.save()
		}
	}
	
	context.reset()
}

That is recommended way to do any Core Data piece of work. CPU and memory graphs reflect that:

even though raw numbers are very similar to previous approach:

===============
CoreData: 1.000.000 Simple Objects
===============
Total 1000000 User instantiation + Create: 16.1105

232 users named `Jane`
Fetch users named `Jane` in age order: 0.0678
232 users named `Jane` being renamed to `Wendy`
232 users renamed to `Wendy`
Rename users named `Jane` to `Wendy`: 0.0610

DB file size: 72.46 MB

Delete all users: 2.7570

Thus by using somewhat reasonable but still sizable chunks (100k records) of the original data set and employing Core Data best practices, we lowered peak memory usage 10× and shortened total time spent about 2.5× which is no small feat.

Updated tests are on GitHub.

This is pure stress test which has its merits; it can help choosing appropriate persistence solution based on what you are trying to solve. Keep in mind that Core Data was never designed for raw performance; it’s a super powerful object graph framework that also does persistence.

In real apps, I advise you to never do things like making import operations with 100k records. Not even 10k records. What would you do with 100k records import if it fails? How can you even reason around conflicts or failure to save with 100k records? There is no UI you can present that will be able to help a person resolving the issue, whatever it is. Even if it’s just pure background import with no user interaction at all — in case of any failure you will need to at least repeat the downloading, processing and saving of your data. It’s much less expensive to repeat 1k record import than 10k or 100k.

Be sensible.

I assume similar improvements could be done for SwiftData but I don’t work with it thus won’t attempt to improve it. I ran its original test which took way more time than Core Data, spending 148s (!) for 100k records import.

Strange issue adding SPM package as dependency on another package

Wed, 19 Jun 2024 10:10:00 +0000

Swift Package Manager dependency resolution mostly work logically:

① First you specify the dependency in any number of ways, here’s the most usual one:

dependencies: [
	.package(
		url: "https://github.com/radianttap/Alley",
		from: "3.0.0"
	),

② Then you reference dependent library by its product name:

targets: [
	.target(
		name: "Atlas",
		dependencies: [
			"Alley"
		],

Alley is simplest possible library - it has one target, called like the package, no sub-dependencies. There’s no confusion how to reference it. Most packages are like this.

But things are not always that simple. Let’s use Auth0’s iOS SDK as example, which is at this URL:

.package(
	url: "https://github.com/auth0/Auth0.swift",
	from: "2.7.0"
),

If this is added as dependency to an iOS app, it works as any other package — you do import Auth0 where needed and all is fine.

But if we add this package as dependency to another package (here called Backend):

targets: [
	.target(
		name: "Backend",
		dependencies: [
			"Auth0"
		],

we get this confusing error:

product 'Auth0' required by 
package 'backend' target 'Backend' not found.
Did you mean 'Auth0'?

Auth0 package is correctly resolved and checked-out, along with its 2 sub-dependencies. There’s no other package nor target called Auth0 thus I don’t really get what’s confusing SPM dependency resolver.

For whatever reason, we need to explicitly point where the library product is:

targets: [
    .target(
		name: "Backend",
		dependencies: [
			.product(name: "Auth0", package: "Auth0.swift")
		],

Why this? Let’s look at package manifest:

let package = Package(
    name: "Auth0",
    products: [.library(name: "Auth0", targets: ["Auth0"])],

package name is Auth0
library and target are also called Auth0
package URL is called Auth0.swift on GitHub

I admit I haven’t delved deep into how naming resolution in SPM works thus naively I can conclude that package.name is pretty much irrelevant and that resolver looks into ending part of the repo URL, which is Auth0.swift and uses that to reference the package.

I encountered the similar issue with a package used on another project. It’s called IPificationSDK but here’s how it is loaded:

.package(
	url: "https://github.com/bvantagelimited/IPificationSwiftDistribution.git",
	exact: "2.0.12"
),

and of course, this is how it’s referenced:

targets: [
	.target(
		name: "WrapperService",
		dependencies: [
			.product(name: "IPificationSDK", package: "ipificationswiftdistribution")
		],

I’ve seen a similar thing happen if you add binary-distributed library as package dependency. It’s actually the search for answer to that problem that lead me to this SwiftPM forum post which provided the solution.

It’s incredible to me that I have not encountered this .product(name:package:) nugget anywhere else — not in Apple’s videos or documentation guides nor any of the blog posts that are returned as top search results for these keywords. Every article out there provides examples with simple String values.

Apple definitely needs to hire more technical writers.

Hackintosh is (almost) dead

Sat, 16 Mar 2024 09:10:10 +0000

While I knew about and even tried various very early attempts to run macOS on non-Apple hardware, it wasn’t until early 2020 that I’ve built my first proper one. Then I built several more which are still seeing daily use.

I explained my reasoning why it was worthwhile to attempt it. The technology was mostly there thanks to a group of dedicated hackers and timing was just right:

But if ever there was a time to do it, it’s now.
Apple is transitioning to their own CPUs/GPUs over the next two years. Several years from now, I see myself purchasing whatever desktop Apple Silicon-based machine is there.

I also offered a prognosis which turned out partially true:

Many will tell you that buying Intel-based hardware from Apple is buying obsolete models. I don’t really agree with that since it’s a given that those Intel-based Macs will be supported for 7-10 years of future macOS updates.

It’s true that latest macOS 14 (Sonoma) still supports the latest generations of Intel Macs and it’s very likely that at least one or two major versions will still be compatible. But there’s one particular development that is de-facto killing off the Hackintosh scene.

In Sonoma, Apple has completely removed all traces of driver support for their oldest WiFi/Bt cards, namely various Broadcom cards that they last used in 2012/13 iMac / MacBook models. Those Mac models are not supported by macOS for few years now thus it’s not surprising the drivers are being removed. Most likely reason is that Apple is moving drivers away from .kext (Kernel Extensions) to .dext (DriverKit) thus cleaning up obsolete and unused code from macOS. They did the same with Ethernet drivers in Ventura.

Those particular cards were the key ingredient to many fully functional Hackintosh builds for simple reason: they worked out of the box with every single (so-called) iService Apple has: Messages, FaceTime, AirDrop, Continuity, Handoff - you name it. Everything worked. Despite the valiant efforts of OCLP crew to make workarounds, those cards can work in Sonoma only if you seriously downgrade the macOS security.

There was some hope that OpenIntelWireless could replace those cards due to amazing work zxystd did in the last 4 years. I mean, the WiFi speeds in macOS with Intel’s WiFi6 cards are nothing short of spectacular. But Apple’s continued cleanup and rewrite of their driver stack has pretty much killed-off any reliable support for Message and FaceTime despite iCloud sync still working great. zxystd describes the new mountain to climb:

From Sonoma, Apple drops IO80211FamilyLegacy, I build AirportItlwmV2 on the top of IO80211Family, but using some hacks, you can simply interpret it as me implementing a set of IO80211FamilyLegacy myself. This implementation may have side effects such as the iService not working etc. Since IO80211Family uses skywalk API instead of original Ethernet API (Also we can foresee that the Ethernet API will also be dropped in macOS 15), without these hacks we should follow the Apple’s API and rewrite the whole driver, that’s what I would never do.

In 14.4, Apple seem to have made changes in how USB subsystem works too. This was always a tedious challenge but if minor updates can almost brick the build it becomes a headache. Still…USB is a known problem with known solution thus it’s annoying but solvable.

WiFi with iServices is sadly not.

I’ve long held the opinion that it would not be CPU nor GPU changes that kill the Hacks — it would be lack of reliable WiFi drivers. And now, ~4 years later, Hackintosh hits a brick wall of no easy WiFi options available, at all. Given how much of the macOS useful features is dependent on presence of particular WiFi chips — a decision of Apple developers I really can’t understand — I can’t really consider builds without those features to call themselves Mac.

I did not come to this conclusion just by reading the forums.

I have a rag-tag build sitting on my desk for several months now. It was supposed to be a quick proof-of-concept Sonoma build with Intel AX200 WiFi/Bt, AMD CPU and GPU, NVMe SSDs - everything that modern Mac should work with. It’s everything that my current Hackintosh is, with SIP intact, incremental updates working on their own etc — a perfect Mac.

But pretty much since day one I encountered one problem after another. Things were so volatile and random that it was hard to believe, at times. Like —

One day Ethernet controller (Intel I225-V) would work great, the next day it would just hard-crash the entire machine. No freaking idea why. Tried multiple ways and custom drivers to make it work but nothing was perfectly stable.
WiFi works fantastic, iCloud is perfect but Messages/FaceTime wouldn’t connect at all. In either Monterey, Ventura or Sonoma. That same card worked perfectly on another motherboard with Monterey and Ventura, no issues with Messages / FaceTime at all. Again — no idea why.
Bluetooth would work great for days but if I turn it off and restart the machine, something would become so messed up that it starts being recognised as BCM_4350C2 chip instead of Intel AX200. Only a round-trip to Windows 11 would somehow bring the chip into a state that IntelBluetooth driver can work with it.
Sonoma 14.3.1 works great on this build. But 14.4 update won’t install. It starts booting the installer and just reboots back almost immediately.

Hence — Hackintosh is on its death bed. Some things will work for few more months or maybe even years, depending on what you use it for and whether lack of WiFi bothers you or not. But not for me. I can live without AirDrop, Continuity and Handoff but Messages and FaceTime must work. There’re also some other things Sonoma brings that are important to me thus I want to update to it. Coupled with described lack of reliability and fretting if next minor or major update would leave me dry — nah, not worth it.

I don’t really complain. I had a good run which helped me skip over the worst price/performance Mac lineup that I remember. There’re now plenty good choices within the current crop of M1 / M2 / M3 machines and I’ll be following eBay closely for a good used Mac mini / studio models. Or maybe even splurge on something new.

Lest I forget — if macOS Ventura works for you, stay on it! That’s still perfectly stable without a single issue across a variety of build options.

Just to clarify one thing, to preempt someone saying Apple did this on purpose to kill off Hackintosh: they didn’t. Apple never cared about Hackintosh scene, it’s entirely irrelevant to their business. They did what they should be doing, improving the macOS codebase. It’s always a good thing to remove obsolete and deprecated code thus Apple is doing the right thing for their product.

High-performance Core Data import

Tue, 30 Jan 2024 12:20:00 +0000

Let’s say you are writing an iOS client for Spotify’s API, specifically the search endpoint. Here you can get multiple entities, like Artist, Album, Track, Playlist and all of them are inter-related in that same JSON.
You might get particular artist instance as top-level result and/or inside album.artists or even inside track.album.artists. It’s quite possible that one same artist can appear in all of those places.

When searching repeatedly for various terms and parsing/importing each received JSON, it would be a disaster to insert the same artist as multiple records into Core Data store. Easy way to prevent this is by setting id as unique attribute. That path leads to lots of merge conflicts when attempting to save into the store and figuring out how to resolve them automatically (better UX but rather complicated in some edge cases) or bother your customers to choose (way worse UX, you should almost never do this).
It’s not a good path.

Another way to prevent this is to check if an artist with particular id already exists and then do an update of the other properties. Naturally, such check should be done for each JSON object. This is what Apple calls upsert in the SwiftData videos as it’s essentially an insert/update combined into one operation.

The least performant way is to do this for each record you encounter. Scenario of:

parse JSON object, possibly directly into new ManagedObject
do Core Data fetch for a record with given id
if it exists, populate its properties and remove the newly created object from step 1
if it does not, keep the object for later save

This will perform as many CoreData fetches as you have objects to import. Inherently it is super slow as for a 1000 JSON objects you will do 1000 fetches for 1 object and another one to perform save. iPhones/iPads have very fast SSD chips but they are still much, much slower than their memory chips. Thus the right way to do such import is:

extract id of the objects from the JSON
preload all existing records with those ids
do insert/update processing in memory
save

This will result in just a handful of fetches and one save. The more objects you process in a batch, the more performance benefit you get with this approach.

This is The Way!™

NSFRC’s sections considered harmful

Sat, 23 Dec 2023 11:14:00 +0000

Imagine a simple sports app model: League entity, with some id, name and displayOrder properties. It has a 1-many relationship to Event entity that has (among other attributes) id, name and of course — reverse to-one relationship back to League.

You write a simple FetchRequest for FetchedResultsController when you are loading events grouped per league, with order defined by League.displayOrder but the section name (title) is League.name.

To get the grouping with proper section titles, your sectionNameKeyPath on the Event entity should be league.name .

But to get the correct order per displayOrder you declare sortDescriptors of the FRC’s fetchRequest to be

NSSortDescriptor(key: "league.displayOrder", ascending: true)
NSSortDescriptor(key: "league.name", ascending: true)
...

This should be fine, right? Order of events will be correct and there should be no issues for Core Data to group per league’s name.

The resulting fetchedObjects array looks correct:

But the order of sections is not correct:

It looks to be sorted per section title. 😣

How bad this is..?

This is a serious issue since you naturally want to process the result per sections / events and feed some collection view, expecting proper order. After all — why would you group per league unless to display them per league, with proper priority order.

Even worse, if you use CompositionalLayout and thus use newer delegate methods like controller(_:didChangeContentWith:) you will naturally want to use given Core Data snapshot to rebuild diffable data source of your collection view.

func controller(_ frc: NSFetchedResultsController<NSFetchRequestResult>, didChangeContentWith snapshot: NSDiffableDataSourceSnapshotReference) {

	//	String==sectionIdentifier => sectionNameKeyPath or UUID (if nil)
	//	NSManagedObjectID of the changed object
	let cds = snapshot as NSDiffableDataSourceSnapshot<String, NSManagedObjectID>

	snapshotEvents(usingCoreDataSnapshot: cds, animated: false)
}

But the sectionIdentifiers of the Core Data snapshot are wrongly ordered:

and even worse — wrong set of itemIdentifiers is associated for each of them:

To make it clearer what’s wrong, here’s side-by-side:

Clearly first 6 events do not belong to “Championship” league and thus are associated with the wrong section.

This can hard-crash your app, depending on how you use this snapshot.

For example, with code like this:

let sectionIdentifiers = cds.sectionIdentifiers
for si in sectionIdentifiers {
  let secitem = ...
	snapshot.appendSections([secitem])

	let items = cds.itemIdentifiers(inSection: si).map {...}
	snapshot.appendItems(items, toSection: secitem)
}

you will get a crash with:

*** Terminating app due to uncaught exception 'NSInternalInconsistencyException', 
reason: 'Diffable data source detected an attempt to insert or append 1 section identifier that already exists in the snapshot. 
Identifiers in a snapshot must be unique. 

Section identifier that already exists:
EventsListDataSource.SectionItem.league(leagueId: 122, name: "Championship")'

Anything that can lead to hard-crash is severe bug. And I am now revisiting all the places I use sectionNameKeyPath and checking to see if intermittent crashes I get are caused by this issue.

How to get around this?

Both frc.fetchedObjects and cds.itemIdentifiers are in the correct order. Thus both can be used to recreate section/item hierarchy but I’m not aware of any easy way to rebuild sectionIdentifiers.

Re-implementing the FRC.sections iterator is fairly straightforward though, on case-by-case basis. Here:

let leagues = events.map({ $0.league }).unique()
for league in leagues {
	let leagueEvents = validEvents.filter({ 
	  $0.league.leagueId == league.leagueId
  })
}

So that’s what I use and completely ignore Core Data snapshot, for now.

Saving native Swift struct into Core Data's transformable attribute

Thu, 28 Sep 2023 16:40:00 +0000

When designing Core Data object graph, I spend copious amount of time thinking through each entity’s attributes and relationships. If I’m not careful, I can easily end-up with expansive graph containing many one-of leaf nodes. Analysing various graphs in the past, I noticed that many complex entities (even with dozen or so attributes) are really just a complex property of their 1-1 relationship pair.

Say you have some Event object that has an elaborate set of configuration options. That configuration object is always used and accessed as a whole with the particular Event instance. Thus it should really be an attribute and not a relationship which is much harder to manage.

Let’s see how we can use Transformable attribute to save and later restore an entire struct.

First, this struct — called MarketGroupsConfiguration in this example — must support Codable to serialize its instances into Data.

Model setup

This is the usual setup of the said attribute in the Core Data modeller from Xcode:

which translates to this declaration in the model class:

@NSManaged var marketGroupsConfiguration: MarketGroupsConfigurationBox?

Wrapper class

The custom class with *Box suffix is needed because we can’t directly save Swift’s struct — it must be NSObject subclass:

final class MarketGroupsConfigurationBox: NSObject {
	let unbox: MarketGroupsConfiguration
	init(_ value: MarketGroupsConfiguration) {
		self.unbox = value
	}
}

extension MarketGroupsConfiguration {
	var boxed: MarketGroupsConfigurationBox {
	  return MarketGroupsConfigurationBox(self)
  }
}

Our wrapper class must implement NSSecureCoding which is required for recent Core Data versions:

extension MarketGroupsConfigurationBox: NSSecureCoding {
	static var supportsSecureCoding: Bool {
		return true
	}

	func encode(with coder: NSCoder) {
		do {
		  let encoder = JSONEncoder()
			let data = try encoder.encode(unbox)
			coder.encode(data, forKey: "unbox")

		} catch let codableError {
			print(codableError)
		}
	}

	convenience init?(coder: NSCoder) {
		if let data = coder.decodeObject(of: NSData.self, forKey: "unbox") {
			do {
		    let decoder = JSONDecoder()
				let b = try decoder.decode(
				  MarketGroupsConfiguration.self, 
				  from: (data as Data)
			  )
				self.init(b)

			} catch let codableError {
				print(codableError)
				return nil
			}
		} else {
			return nil
		}
	}
}

Transformer

ValueTransformer implementation is pretty involved but official documentation has enough details to get us started.

@objc(MarketGroupsConfigurationTransformer)
final class MarketGroupsConfigurationTransformer: NSSecureUnarchiveFromDataTransformer {

	static let name = NSValueTransformerName(
	  rawValue: String(describing: MarketGroupsConfigurationTransformer.self)
  )

	public static func register() {
		let transformer = MarketGroupsConfigurationTransformer()
		ValueTransformer.setValueTransformer(transformer, forName: name)
	}

	override static var allowedTopLevelClasses: [AnyClass] {
		return [
		  MarketGroupsConfigurationBox.self, 
		  NSData.self
	  ]
	}

	override public class func transformedValueClass() -> AnyClass {
		return MarketGroupsConfigurationBox.self
	}

	override public class func allowsReverseTransformation() -> Bool {
		return true
	}

	override public func transformedValue(_ value: Any?) -> Any? {
		guard let data = value as? Data else {
			return nil
		}

		do {
			let box = try NSKeyedUnarchiver.unarchivedObject(
			  ofClass: MarketGroupsConfigurationBox.self, 
			  from: data
		  )
			return box
		} catch {
			return nil
		}
	}

	override public func reverseTransformedValue(_ value: Any?) -> Any? {
		guard let box = value as? MarketGroupsConfigurationBox else {
			return nil
		}

		do {
			let data = try NSKeyedArchiver.archivedData(
			  withRootObject: box, 
			  requiringSecureCoding: true
		  )
			return data
		} catch {
			return nil
		}
	}
}

Most of these methods are metadata required for ValueTransformer to work. The essence is inside transformedValue() and reverseTransformedValue () methods which deserialise and serialise our instance.

Lastly, somewhere very early in the app lifecycle, you must register this ValueTransformer type so it can be properly recognised by iOS SDK:

MarketGroupsConfigurationTransformer.register()

I usually do this right before Core Data container / model is initialised.

And that’s it!
As you can see, this code is easily adaptable to as many transformable attributes as you need.

Implement data detectors inside UILabel

Mon, 18 Sep 2023 14:23:00 +0000

UILabel has ability to render rather complex text through .attributtedText but is not user-interactive by default. Thus even though particular text can contain URLs or phone numbers, there is no native capability to tap on said URL and open a web view.

Curiously, most open-source components that aim to enable this are years-old, written in Objective-C. Here’s how you can re-implement this feature today.

First, we need an extension over String which will detect all the CheckingTypes we care about:

extension String {
	func detectCheckingTypes(_ types: NSTextCheckingResult.CheckingType = [.link]) -> [NSTextCheckingResult] {
		guard let detector = try? NSDataDetector.init(types: types.rawValue) else {
			return []
		}
		let s = self
		let matches = detector.matches(in: s, options: [], range: NSRange(location: 0, length: s.utf16.count))
		return matches
	}
}

There are about dozen types of data you can detect with this but I’ll focus on .link to keep things simple.

Now, when we have UILabel instance inside some UIView, we can check if there’s anything detectable. If yes, then populate .attributedText after highlighting the found term (using AccentColor is good choice) and attaching UITapGestureRecognizer to the label.

label.text = string

let detectedLinks = string.detectCheckingTypes([.link])
if detectedLinks.count > 0 {
	let attrString = NSMutableAttributedString(string: string)
	
	for match in detectedLinks {
		let matchRange = match.range
		guard let range = Range(matchRange, in: string) else { continue }
		let term = String(string[range])
		
		//	highlight link
		attrString.colorize(term: term, usingColor: .accentColor)
		
		//	handle tap on link
		label.handleInteractionWithCheckingType(match, inside: self.view)
	}
	label.attributedText = attrString
}

Let’s now implement handleInteractionWithCheckingType method on UILabel. First, some sanity checking — if label has no text/attributedText, there’s nothing to do here.

extension UILabel {
	func handleInteractionWithCheckingType(_ match: NSTextCheckingResult, inside view: UIView) {
		guard 
			let string = self.text, string.count > 0,
			let attrString = self.attributedText
		else {
			return
		}
		
		--[CONTINUES BELOW]--
	}
}

Now, re-run the matching and — very important — allow user-interaction on the label instance.

let matchRange = match.range
guard let range = Range(matchRange, in: string) else { return }
let term = String(string[range])

isUserInteractionEnabled = true

If we have a match, switch-over the CheckingType value and implement behavior you need. Here I’m

looking if the match is .link
making sure that matched term is actually a valid URL
checking if the person has tapped on the term itself

Only then we can present the URL in some appropriate way for the given app.

switch match.resultType {
	case .link:
		//	handle tap on links
		let tapGR = UITapGestureRecognizer {
			[weak view, weak self] gr in

			guard 
			  let view, let self, 
			  let url = URL(string: term) 
		  else { return }
			
			if self.hasInteractedWith(gr, over: attrString, atRange: matchRange) {
				// Show WKWebView with this URL
			}
		}
		addGestureRecognizer(tapGR)
		
	default:
		break
}

Finally, let’s see how to detect if the tap happened over the link and not some other text — let’s implement hasInteractedWith method.

extension UILabel {
	func hasInteractedWith(_ gr: UIGestureRecognizer, 
	    over attrString: NSAttributedString, 
    	atRange matchRange: NSRange) -> Bool 
	{

	--[CONTINUES BELOW]--

	}
}

UITapGestureRecognizer’s location(in:) method gives us CGPoint inside the label’s bounds. TextKit framework has all the tools we need to match that point with actual character in the label’s text string.

First, instantiate required TextKit objects and copy-over UILabel properties that influence its rendered size to the NSTextContainer:

let layoutManager = NSLayoutManager()
let textContainer = NSTextContainer(size: .zero)
let textStorage = NSTextStorage.init(attributedString: attrString)

layoutManager.addTextContainer(textContainer)
textStorage.addLayoutManager(layoutManager)

// configure textContainer for the label
textContainer.lineFragmentPadding = 0.0
textContainer.lineBreakMode = self.lineBreakMode
textContainer.maximumNumberOfLines = self.numberOfLines
let labelSize = self.bounds.size
textContainer.size = labelSize

Now, figure out the character index in the string that corresponds to the touch point:

let loc = gr.location(in: self)

let textBoundingBox = layoutManager.usedRect(for: textContainer)

let textContainerOffset = CGPointMake(
	(labelSize.width - textBoundingBox.size.width) * 0.5 - textBoundingBox.origin.x,
	(labelSize.height - textBoundingBox.size.height) * 0.5 - textBoundingBox.origin.y
)

let locationOfTouchInTextContainer = CGPointMake(
	loc.x - textContainerOffset.x,
	loc.y - textContainerOffset.y
)

let indexOfCharacter = layoutManager.characterIndex(
  for: locationOfTouchInTextContainer, 
  in: textContainer, 
  fractionOfDistanceBetweenInsertionPoints: nil
)

Finally, return true if the indexOfCharacter falls into matched term’s range:

return matchRange.contains(indexOfCharacter)

The main fact here is that calculations above are done in the gesture-recogniser’s tap handler. That means all of UIKit’s rendering is complete and there can be no errors in pinpointing where the interaction happened.

Add these 3 methods into your project and you’ll have the ability to trigger detection of any CheckingType available in iOS SDK.

Using NSFetchedResultsController’s diffable snapshot with UICollectionView’s diffable data source

Wed, 13 Jul 2022 10:30:00 +0000

Last several weeks, we (Radiant Tap) are working on a major app redesign for one of our clients. App is super-data-intensive, combining multiple different data sources into one complex bi-directional scrollable view. Here’s some samples of the design:

Important bits what’s in there:

First section is the horizontally scrollable set of ads, which are fetched from JSON file. Rarely changes but it can.
All the other sections are using data from Core Data store where some of them change very often, every 3-5s.
Second section is horizontally scrollable set of active sports driven by NSFetchedResultsController (FRC for short) which has no sectionNameKeyPath set.
Third section is horizontally scrollable set of matches (events) driven by another custom FRC, again with sectionNameKeyPath not set.
Then we have another FRC loading non-live matches with sectionNameKeyPath set to the sport’s name attribute (so the matches are grouped by sport). There can be 0 or more of these sections.
This is followed by another FRC with live-matches, again grouped per sport. There can also be 0 or more of these sections.

It’s very complex so far but it does not stop there since there’s quite a bit of additional state we need to maintain on top of displaying incoming data. So we have 3 semantically different UI-update triggers:

New ads (dis)appearing in the first section.
Sport/Event changes in Core Data’s context.
Auxiliary state changes thus even though actual underlying Core Data source did not change, the UICV still needs an update.

I’m describing all this to set the stage, to make it clearer why we did things the way we did them and why it did not always work reliably.
And what eventually did.

Modeling disparate data source into one snapshot

Natural choice here in modern iOS is to use UIKit’s compositional layout. Most examples you find online are using simple types like Int, String or UUID as SectionIdentifierType or ItemIdentifierType in the NSDiffableDataSourceSnapshot.

That is not really an option in the complex case like what we have here. You need much more specificity and customisation. enum with associated values is perfect tool for that and here’s (simplified) set of cases we ended up using for the UICollectionViewDiffableDataSource<SectionItem, GridItem> acting as UICV’s data source:

enum SectionItem: Hashable {
	case banners
	case sportspicker
	case featuredMatches(events: [Event])
	case topstandardsport(Sport, events: [Event])
	case toplivesport(Sport, events: [Event])
}

enum GridItem: Hashable {
	case banner(ad: Ad)
	case sport(Sport)

	case featuredMatch(Event)
	case featuredSelection(Selection, isAddedToBetslip: Bool)

	case eventHeader(Event)
	case marketHeader(Game, sectionIndex: Int, rowIndex: Int)
	case selection(Selection, isAddedToBetslip: Bool)
	case message(sectionIndex: Int, rowIndex: Int, message: String)
	case locked(sectionIndex: Int, rowIndex: Int)
}

All these types — Sport, Event, Game, Selection — are Core Data entities thus all are subclasses of NSManagedObject. Ad is a struct. The accompanying snapshot uses the same identifiers, which are typealias-ed for clearer code:

typealias GridSource = UICollectionViewDiffableDataSource<SectionItem, GridItem>

typealias Snapshot = NSDiffableDataSourceSnapshot<SectionItem, GridItem>

Why is this good? Having the full objects as part of the diffable data source makes vending cells and building the layout to house them very straightforward. For example, cell vending:

func cell(collectionView: UICollectionView, indexPath: IndexPath, item: GridItem) -> UICollectionViewCell {
		switch item {
			case .banner(let ad):
				let cell: AdCell = collectionView.dequeueReusableCell(forIndexPath: indexPath)
				cell.populate(with: ad)
				return cell

			case .sport(let sport):
				let cell: SportPickerCell = collectionView.dequeueReusableCell(forIndexPath: indexPath)
				cell.populate(with: sport.icon, caption: sport.name, isSelected: false)
				return cell

			case .featuredMatch(let event):
				let cell: FeaturedEventCell = collectionView.dequeueReusableCell(forIndexPath: indexPath)
				cell.populate(
					with: event,
					isStreaming: bettingContentManager.isEventStreamingOnTV(event)
				)
				return cell

With all this setup, now we need to configure UICV to use GridSource as data source, setup cell vending method and…build a snapshot:

gridSource = GridSource(collectionView: cv, cellProvider: {
	[unowned self] cv, indexPath, gridItem in
	self.cell(collectionView: cv, indexPath: indexPath, item: gridItem)
})

snapshot(animated: false)

So what about snapshot?

The simplest approach here we tried first:

func snapshot(animated: Bool) {
	if collectionView == nil { return }

	var snapshot = Snapshot()
	var sectionIndex: Int = 0

	//	ads
	snapshot = populateSnapshotWithAds(snapshot)
	sectionIndex += 1

	//	sports picker
	snapshot = populateSnapshotWithSports(snapshot)
	sectionIndex += 1

	//	featured matches
	snapshot = populateSnapshotWithFeaturedMatches(snapshot, sectionIndex: sectionIndex)
	sectionIndex += 1

	//	top standard matches (events)
	for section in frcTopStandardEvents?.sections ?? [] {
		snapshot = populateSnapshot(snapshot, withTopStandardSection: section, sectionIndex: sectionIndex)
		sectionIndex += 1
	}

	//	top live matches (events)
	for section in frcTopLiveEvents?.sections ?? [] {
		snapshot = populateSnapshot(snapshot, withTopLiveSection: section, sectionIndex: sectionIndex)
		sectionIndex += 1
	}

	gridSource.apply(snapshot, animatingDifferences: animated)
}

Watch for changes in the data / state. When they happen, call snapshot(animated: true)
That would build entire new full snapshot, for all sections/items.
For Core Data stuff, we simply iterate over each FRC’s sections and fetchedObjects arrays and convert them into SectionItem and GridItem instances, as needed
Call applySnapshot and let UIKit figure-out the differences and render them.

All changes including those from Core Data are simple to observe. For Core Data, laziest possible approach:

extension HomeDataSource: NSFetchedResultsControllerDelegate {
	func controllerDidChangeContent(_ controller: NSFetchedResultsController<NSFetchRequestResult>) {
		snapshot(animated: true)
	}
}

Looks super easy, right? This…actually works very well and in limited testing — “works on my dev machine” kind of testing — it yielded no issues, no crashes.

Core Data crashes and why they happen

Shortly after entering limited internal QA, we started receiving multiple crash reports per tester. They looked like this:

I knew from past experience what a crash in those UICollectionView.m lines meant; the return of dreaded NSInternalInconsistencyException crash, better known as attempt to delete item X1 from section Y which only contains X2 items before the update and similar exception messages.
DiffableDataSource is supposed to deliver us from it thus disheartening to see it roaring back like this.

There’s not much good posts on this topic to be found. One real gem is from Antoine van der Lee who dived deep into this and figured out the reason for the crashes:

During the transition from an old snapshot to a new snapshot, it could be that the data source is asking for a cell for a given index path that not yet exists in the collection of fetched objects.
The fetched objects in an NSFetchedResultsController are updated after the snapshot is applied but a cell can be asked before that transition finishes.
This mainly happens when a transition is animated.

Entire post is worth a detailed and careful read and boils down to this:

You should use that new FRC delegate method that delivers the snapshot of changes FRC has already digested.
Do not use FRC’s fetchedObjects when building your diffable data model since it’s populated after FRC reports snapshot changes.

Second point was confirmed once I naively tried the easy way out: keep my code as it is but use the newer delegate method:

extension HomeDataSource: NSFetchedResultsControllerDelegate {
	func controller(_ controller: NSFetchedResultsController<NSFetchRequestResult>, didChangeContentWith newSnapshot: NSDiffableDataSourceSnapshotReference) {

		let animateChanges = collectionView.numberOfSections ?? 0 > 0
		snapshot(animated: animateChanges)
	}
}

This yielded the same intermittent crashes:

Using FRC-provided sections and objects almost works. But in some edge cases it leads to inconsistent internal state in the UICV data source thus causing a crash. There’s no solution for it with the code approach above; it needs a complete overhaul.

The thing to understand here is that FRC does not have layout or cells to worry about so it’s free to update its sections and fetchedObjects properties whenever it sees fit. You can’t depend on them to be ready in time for your snapshot builder accessing them. You are opening yourself to race conditions which rarely happen but eventually for someone they do.
In our testing it turned out that we can have 100s or even 1000s of successful snapshot driven updates before encountering a crashing condition.

FRC internally works out the inserted/updated/deleted set of changes and the delegate method reports that to you but there are apparently no guarantees that you can use sections and fetchedObjects as soon as you get the delegate call. When you think about it — there must be some good reason you are given a set of NSManagedObjectIDs and not ready-to-use NSManagedObject instances.

Hence why Antoine’s cell-vending method uses NSManagedObjectID as input and then fetches full object from the NSManagedObjectContext when it needs to populate the cell:

let diffableDataSource = UICollectionViewDiffableDataSource<Int, NSManagedObjectID>(collectionView: collectionView) {
    (collectionView, indexPath, objectID) -> UICollectionViewCell? in
    
    guard let object = try? managedObjectContext.existingObject(with: objectID) else {
        preconditionFailure("Managed object should be available")
    }

    let cell = ...
}

We need to change our Section/Grid enum to use objectIDs and hope for the best. But first we need to see what exactly is Core Data giving us.

Demystifying Core Data snapshots

The snapshot’s type used by Core Data delegate method is NSDiffableDataSourceSnapshotReference and Apple says that you should use Swift-ified counterparts:

Avoid using this type in Swift code.
Only use this type to bridge from Objective-C code to Swift code by typecasting from a snapshot reference to a snapshot:
let snapshot = snapshotReference as NSDiffableDataSourceSnapshot<Int, UUID>

In the SwiftLee post, it is type-casted into ...<Int, NSManagedObjectID>. I found both of these to be wrong. Maybe something has changed since 2020 but the true type in my testing turns out to be:

NSDiffableDataSourceSnapshot<String, NSManagedObjectID>

where String value of sectionIdentifier is:

Some (random?) string when FRC’s sectionNameKeyPath is nil.
Attribute value returned as sectionNameKeyPath when key-path is not nil.

Here are examples logged in Xcode console:

[
"d69e6c783a242772974cfc99189691b88e9d37c3 : x-coredata://E43CC0BD-13BD-40F2-B354-BB660E18C80A/Sport/p27",
"d69e6c783a242772974cfc99189691b88e9d37c3 : x-coredata://E43CC0BD-13BD-40F2-B354-BB660E18C80A/Sport/p23"
]
...
[
"Football : x-coredata://E43CC0BD-13BD-40F2-B354-BB660E18C80A/Event/p735",
"Football : x-coredata://E43CC0BD-13BD-40F2-B354-BB660E18C80A/Event/p747",
"Football : x-coredata://E43CC0BD-13BD-40F2-B354-BB660E18C80A/Event/p752",
"Basketball : x-coredata://E43CC0BD-13BD-40F2-B354-BB660E18C80A/Event/p745"]

Now that we know what we are working with, let’s dig in.

Proper marriage of FRC snapshots with UICV diffable data source

First, we update the diffable data model to:

use NSManagedObjectID instead of full Core Data entities
use String sectionIdentifier we are receiving instead of Int sectionIndex (these have some internal use, specific to our layout)

With some other changes specific to our use-case, this was the end result:

enum SectionItem: Hashable {
	case banners
	case sportspicker
	case featuredMatches(events: [NSManagedObjectID])
	case topstandardsport(sportId: Int64, events: [NSManagedObjectID])
	case toplivesport(sportId: Int64, events: [NSManagedObjectID])
}

enum GridItem: Hashable {
	case banner(ad: Ad)
	case sport(NSManagedObjectID)

	case featuredMatch(NSManagedObjectID)
	case featuredSelection(NSManagedObjectID, isAddedToBetslip: Bool)

	case eventHeader(NSManagedObjectID)
	case marketHeader(NSManagedObjectID, sectionIdentifier: String, rowIndex: Int)
	case selection(NSManagedObjectID, isAddedToBetslip: Bool)
	case message(sectionIdentifier: String, rowIndex: Int, message: String)
	case locked(sectionIdentifier: String, rowIndex: Int)
}

Next — apply all recommendations from SwiftLee post, namely:

do not access FRC’s fetchedObjects directly
instead setup each FRC, set its delegate and only then call performFetch()
in the delegate method, call out your snapshot builder passing the snapshot received from Core Data
convert Core Data snapshot into your own and apply differences

func controller(_ frc: NSFetchedResultsController<NSFetchRequestResult>, didChangeContentWith snapshot: NSDiffableDataSourceSnapshotReference) {

	let cds = snapshot as NSDiffableDataSourceSnapshot<String, NSManagedObjectID>

	if frc == frcSports {
		snapshotSports(usingCoreDataSnapshot: cds, animated: true)

	} else if frc == frcFeaturedEvents {
		snapshotFeaturedMatches(usingCoreDataSnapshot: cds, animated: true)

	} else if frc == frcTopStandardEvents {
		snapshotTopStandardEvents(usingCoreDataSnapshot: cds, animated: true)

	} else if frc == frcTopLiveEvents {
		snapshotTopLiveEvents(usingCoreDataSnapshot: cds, animated: true)
	}
}

Key thing we found here is that Core Data snapshot you receive contains entire set of objects that satisfy the FRC’s predicate. It’s not some delta of few changed objects — it’s all of them. That is awesome since we don’t have to deal with merging of existing data and received delta.

Since we have multiple FRCs and some other additional data sources, we can’t just blindly call applySnapshot(...). Doing that will essentially remove all data and display this one section you just received. Correct way is to take full existing snapshot of your data source, delete the relevant section and then replace it with data from received Core Data snapshot.

func snapshotFeaturedMatches(usingCoreDataSnapshot cds: NSDiffableDataSourceSnapshot<String, NSManagedObjectID>, animated: Bool) {
	// start with existing snapshot
	var snapshot = gridSource.snapshot()

	// delete corresponding section
	snapshot.deleteSections(
		//target .featuredMatches section here
	)

	// this helps maintain correct order of UICV sections 
	let nextSection = snapshot.sectionIdentifiers.first(where: { ... })

	// convert CoreData snapshot into our snapshot
	snapshot = populateSnapshotWithFeaturedMatches(
		snapshot,
		with: cds,
		beforeSection: nextSection
	)

	// apply our updated snapshot
	gridSource.apply(snapshot, animatingDifferences: animated)
}

We also implemented some simple logic to maintain the order of sections. You can’t just appendSections each time you receive a set of data since your UI sections will constantly shuffle downwards.

func populateSnapshotWithFeaturedMatches(_ currentSnapshot: Snapshot, with cds: NSDiffableDataSourceSnapshot<String, NSManagedObjectID>, beforeSection: SectionItem? = nil) -> Snapshot {

	let eventMOIDs = cds.itemIdentifiers
	guard
		let sectionIdentifier = cds.sectionIdentifiers.first,
		eventMOIDs.count > 0
	else {
		return currentSnapshot
	}

	var snapshot = currentSnapshot

	let secitem = HomeDataSource.SectionItem.featuredMatches(events: eventMOIDs)
	if let nextSection = beforeSection {
		snapshot.insertSections([secitem], beforeSection: nextSection)
	} else {
		snapshot.appendSections([secitem])
	}

	// Here convert data from cds into 
	// GridItem instances added to secitem

	return snapshot
}

That’s…pretty much done. The rest of the work was carefully going over each FRC, check what its snapshot really is and build out the snapshot conversion into enums we are using.

Cell vending changed too - we take the NSManagedObjectID and ask the NSManagedObjectContext for the full object:

func object<T>(with moID: NSManagedObjectID) -> T? {
	do {
		let object = try moc.existingObject(with: moID)
		return object as? T
	} catch let err {
		return nil
	}
}

func cell(collectionView: UICollectionView, indexPath: IndexPath, item: GridItem) -> UICollectionViewCell {
	switch item {
		...
		case .sport(let moID):
			guard let sport: Sport = object(with: moID) else {
				preconditionFailure()
			}
			let cell: SportPickerCell = collectionView.dequeueReusableCell(forIndexPath: indexPath)
			cell.populate(with: sport.icon, caption: sport.name, isSelected: false)
			return cell
			
		...

As you can see, this is far from simple and easy. There’s lots of experimentation and verification to do. But the end result is a system that works really, really well.

Before compositional layout, an UI like this would be multiple nested collection views with flow layout — we had that and maintaining it was super hard and was never 100% crash-free. Now, having everything in one single UICollectionView is freaking amazing from performance aspect: everything scroll super smooth, memory consumption is very low thanks to Core Data efficiency and so far it looks to be crash-free 🤞🏻.

All of this is supported since iOS 13 so right now it’s pretty much guaranteed you can freely use it in just about any app.

Bitmask (bitwise) values in Core Data

Sun, 03 Jul 2022 09:30:00 +0000

OptionSet is great tool of the Swift language. It’s fantastic for modelling multi-option values like: blog tags, various kinds of flags and markers etc.

Here’s a typical (for me) use case: customise cell design where content can have label and icon, might have a badge, maybe disclosure indicator, some kind of background view with or without shadow etc. You can either create a separate UICVCell subclass for each combo or do them all at once and then supply a value with enabled options:

struct LayoutFlags: OptionSet {
	public let rawValue: Int
	public init(rawValue:Int) {
		self.rawValue = rawValue
	}

	static let label	 = Self(rawValue: 1)
	static let icon = Self(rawValue: 2)
	static let badge = Self(rawValue: 4)
	static let disclosure 	= Self(rawValue: 8)
	static let backView = Self(rawValue: 16)
	static let shadowBackView = Self(rawValue: 32)
}

let value: LayoutFlags = [.label, .badge]

Another implementation might be to model bitwise masks:

struct BIOMarker: OptionSet {
	let rawValue: Int64
	init(rawValue: Int64) {
		self.rawValue = rawValue
	}

	static let RAW = BIOMarker(rawValue: 1 << 0)

	static let HRM = BIOMarker(rawValue: 1 << 1)

	static let PLX = BIOMarker(rawValue: 1 << 2)
}

let value: BIOMarker = [.RAW, .PLX]

How can you save these values into Core Data store, which has no idea about OptionSet? Simple: you save/restore the rawValue which is Int or Int64 or anything else.

To avoid modelling the transformation manually, you can build on the idea I wrote about in 2017: use custom userInfo of the CoreData modeler to set actual type name you want to use, for (mogenerator) example:

attributeValueScalarType: BIOMarker

First we make OptionSet adopt CoreDataRepresentable protocol described in that post:

extension OptionSet where Self: CoreDataRepresentable {
	var coredataValue: Self.RawValue { return self.rawValue }
	init?(coredataValue: CoreDataBaseType) {
		self.init(rawValue: coredataValue as! Self.RawValue)
	}
}

Our OptionSet type needs to specify what’s the fallback value, simplest way is empty set:

extension BIOMarker: CoreDataRepresentable {
	static let coredataFallback: BIOMarker = []
}

Then using mogenerator or SwiftGen, you can parse the model and generate the code we need for entity attributes where such userInfo is set. This is the code we need generated:

var bioMarker: BIOMarker {
	get {
		let key = "bioMarker"
		willAccessValue(forKey: key)
		defer { didAccessValue(forKey: key) }

		if let primitiveValue = primitiveValue(forKey: key) as? BIOMarker.CoreDataBaseType, let value = BIOMarker(coredataValue: primitiveValue) {
			return value
		}
		return BIOMarker.coredataFallback
	}
	set {
		let key = "bioMarker"
		willChangeValue(forKey: key)
		defer { didChangeValue(forKey: key) }

		setPrimitiveValue(newValue.coredataValue, forKey: key)
	}
}

Code like this is very scriptable which is the reason I mention mogenerator or SwiftGen. Never maintain model parsing code by hand, you are certain to forget updating it at some point; it’s best to setup Run Script build phase that does this on each build.

OK — now that we have such values in Core Data store, can we build predicates to read data based on these values? Sure we can — SQLite has support for bitwise operators since 2001 so it’s easy to write a predicate to read all entities where HRM bit is set:

let hrm: BIOMarker = [.HRM]

NSPredicate(
    format: "(%K & %i) != 0", 
    "bioMarker", 
    hrm.rawValue
)

Coordinator pattern with UITabBarController

Sun, 29 May 2022 09:35:00 +0000

Leonardo Maia Pugliese recently published a blog post that picked my interest: Coordinators and Tab Bars: A Love Story. I always love to read how other people employ this useful pattern thus I carefully read through it.

The problem he is solving is this:

Imagine that you have a tab bar with two tabs and each tab is a navigation controller. The Home Tab has 2 levels deep and the Orders Tab has 3 levels deep.
The problem is to navigate from the second level deep view controller of home Tab to the 3 level deep Orders tab maintaining the hierarchical sequence of orders tab, this means that the return button should return to level 2 of level tab and so on.

In UIKit, event/data flow is achieved through UIResponder + a special set of overridable methods on UIViewController, like show(vc), present(vc) etc.

UIKit’s show() method has super simple logic. When called inside any UIVC, this method will:

check if current UIVC has parent - if yes, call parent.show(vc) and do nothing else
If no parent, popup the target UIVC (a rather crude fallback)

Sadly, UIKit falls way short of making true separation of concerns. Per example project from Leonardo’s post, to switch from second screen in Home tab to a third screen in Orders tab and to keep the Orders drill-down navigation hierarchy, UIKit forces you to do this:

let controllers = [
	OrdersViewController(),
	Orders2ViewController(),
	Orders3ViewController()
]
let target = tabBarController.viewControllers[1] as? UINavigationController
target?.viewControllers = controllers

Poor Home2ViewController needs to

create and configure 3 completely separate controllers to whom it has no actual relation
needs to know exactly where itself is located in the UIKit hierarchy and call specific properties after performing fixed type-casting

That’s just…horrible. Navigation remains the worst aspect of iOS SDK, regardless if you are using UIKit or SwiftUI.

To solve these issues, Leonardo correctly declares the app hierarchy independent of actual UIKit objects:

enum AppFlow {
    case home(HomeScreen)
    case orders(OrdersScreen)
}

enum HomeScreen {
	case initialScreen
	case doubleButtonScreen
}

enum OrdersScreen {
	case firstScreen
	case secondScreen
	case thirdScreen
}

This works for an example project. It can easily be extended into truly complex flows, screens that accept parameters (using associated values on cases) etc. Thus it’s good approach.

Further, he implements Coordinators to create and configure UIVC for each of these screens. There’s MainCoordinator which manages UITabBarController while each of the tabs are child Coordinator managing their own UINavigationController instance. Again — this is good implementation where each Coordinator is responsible to create and display its subset of UIVCs. For example, second screen in Home tab:

func goToHome2ScreenWith(title: String) {
    let home2ViewController = Home2ViewController(coordinator: self)
    home2ViewController.title = title
    navigationRootViewController?.pushViewController(home2ViewController, animated: true)
}

So far, this solves the first issue with UIKit navigation.

Where it falls short is the second problem: the implementation of Home2ViewController request flow transfer to Orders3ViewController is not good.

The solution used is the one that builds on Soroush’s original approach of using Delegate pattern to offload navigation (switching from one screen/view to another) from the view-controllers to coordinators. Simplified:

UIViewController will ask its Coordinator to switch to another UIVC
if the requested UIVC is in another tab, Coordinator will ask its parent Coordinator to do that

It’s a really simple approach but also very limiting one. Delegate pattern is great when you need to transfer something from point A to point B. It does not matter which points they actually are; the limiting factor is that there’s only two points. The pattern does not allow transfer to potential point C (or D or E). If you need that, you need to implement another Delegate pattern which handles transfer from B to C etc.

Navigating between screens may mean that you have to transfer data or flow between many points. In our practice, we regularly encountered transferring stuff from 5-6 levels deep to the top and then to completely different flow stack, to screen maybe 2-3 levels down. Delegating between all those levels leads to super rigid structure which becomes additional maintenance issue.

You can glimpse the problem in this code:

protocol FlowCoordinator: AnyObject {
    var parentCoordinator: MainBaseCoordinator? { get set }
}

protocol Coordinator: FlowCoordinator {
}

protocol MainBaseCoordinator: Coordinator {
    var homeCoordinator: HomeBaseCoordinator { get }
    var ordersCoordinator: OrdersBaseCoordinator { get }
    var deepLinkCoordinator: DeepLinkBaseCoordinator { get }
    func moveTo(flow: AppFlow)
    func handleDeepLink(text: String)
}

protocol HomeBaseCoordinator: Coordinator {
    func goToHome2ScreenWith(title: String)
    func goToFavoritesFlow()
    func goToDeepViewInFavoriteTab()
}

protocol OrdersBaseCoordinator: Coordinator {
    @discardableResult func goToOrder2Screen(animated: Bool ) -> Self
    @discardableResult func goToOrder3Screen(animated: Bool) -> Self
}

protocol HomeBaseCoordinated {
    var coordinator: HomeBaseCoordinator? { get }
}

protocol OrdersBaseCoordinated {
    var coordinator: OrdersBaseCoordinator? { get }
}

Usage of protocols is superfluous as the structure is rather rigid: Main is always a parent of Home and Orders and there’s fixed connection between each point. The flow-transferring methods do exactly one thing thus I’m not sure why all of these protocols even exist; there’s nothing I see they help to abstract. The data flows implemented further in the post would work the same without any of these protocols, as there’s fixed connections (using stored properties):

class MainCoordinator: MainBaseCoordinator {
    var parentCoordinator: MainBaseCoordinator?

    lazy var homeCoordinator: HomeBaseCoordinator = ...
    lazy var ordersCoordinator: OrdersBaseCoordinator = ...
...    
    
class HomeCoordinator: HomeBaseCoordinator {
    var parentCoordinator: MainBaseCoordinator?

    func goToDeepViewInFavoriteTab() {
        parentCoordinator?.moveTo(flow: .Favorites)
    ...
...

Further down, view controllers also store fixed connection to specific parent Coordinator, again creating rigid connection:

class HomeViewController: UIViewController, HomeBaseCoordinated {
    var coordinator: HomeBaseCoordinator?
    ...

I am confused what benefit all this scaffolding brings. If you opt to use fixed connections like this, you don’t need Coordinators nor protocols of any kind. Simply using embedded parent/child UIViewControllers and setting the equivalent properties will achieve the same thing.

The method call :

var parentCoordinator: MainBaseCoordinator?
...
parentCoordinator?.moveTo(flow: .orders(.secondScreen))

would work just the same with hypothetical Main VC:

var parentController: MainController?
...
parentController?.moveTo(flow: .orders(.secondScreen))

The main issue is that, with this approach, content UIViewControllers have direct connection to specific parent objects. It’s the same thing as what we already have:

let target = tabBarController.viewControllers[1] as? UINavigationController
target?.moveTo(flow: .orders(.secondScreen))

Content view controllers should not know nor care who created them nor where they are located inside app’s flow/view hierarchy. They should be self-contained, have specific purpose and some exit points. Content UIVC should not know what other object will handle .moveTo(flow:)

(One of the) benefits of Coordinators — separation of app flow from the screens belonging to the flow — can only be achieved if you completely isolate screens from the coordinators and from other screens.

UIViewController should not know nor care what its parent coordinator is.
Child Coordinator should not know nor care what its parent Coordinator is.
In both cases, child object should be able to communicate to their “parent” that flow needs to transfer to something else.

So, how to achieve that?

The key is to re-purpose the framework’s existing scaffolding. I already explained how show(vc) works its magic. The beautiful part is that we can create our own magic by re-purposing responder chain and adding additional methods.

My Coordinator library does this with few tricks which take less than 20 lines of actual code:

import UIKit

//	Inject parentCoordinator property into all UIViewControllers
extension UIViewController {
    private class WeakCoordinatingTrampoline: NSObject {
        weak var coordinating: Coordinating?
    }

    private struct AssociatedKeys {
        static var ParentCoordinator = "ParentCoordinator"
    }

    public weak var parentCoordinator: Coordinating? {
        get {
            let trampoline = objc_getAssociatedObject(self, &AssociatedKeys.ParentCoordinator) as? WeakCoordinatingTrampoline
            return trampoline?.coordinating
        }
        set {
            let trampoline = WeakCoordinatingTrampoline()
            trampoline.coordinating = newValue
            objc_setAssociatedObject(self, &AssociatedKeys.ParentCoordinator, trampoline, .OBJC_ASSOCIATION_RETAIN)
        }
    }
}

extension UIResponder {
	@objc open var coordinatingResponder: UIResponder? {
		return next
	}
}

extension UIViewController {
	override open var coordinatingResponder: UIResponder? {
		guard let parentCoordinator = self.parentCoordinator else {
			guard let parentController = self.parent else {
				guard let presentingController = self.presentingViewController else {
					return view.superview
				}
				return presentingController as UIResponder
			}
			return parentController as UIResponder
		}
		return parentCoordinator as? UIResponder
	}
}

This code creates new property called coordinatingResponder on all UIKit’s components: anything that’s based on UIResponder which means all views, controls and controllers. With that added, we can re-create our own show(vc) that works with AppFlow:

extension UIResponder {
	@objc func openFlow(_ flow: AppFlowBox, 
			keepHierarchy: Bool = false, 
			userData: [String: Any]? = nil, 
			sender: Any?
	) {
		coordinatingResponder?.openFlow(flow, keepHierarchy: keepHierarchy, userData: userData, sender: sender)
	}
}

I have re-factored Leonardo’s example project to use my Coordinator library and that special method to transfer flow.

Check the contents or any Coordinator or ViewController — there’s 0 references to parent anything. Whenever you need to switch flow to anywhere else, you just call openFlow() and pass the target flow point. Each Coordinator will override the method and perform routing as needed.

For example, inside HomeCoordinator:

override func openFlow(_ flowboxed: AppFlowBox, keepHierarchy: Bool = false, userData: [String : Any]? = nil, sender: Any?) {
	let flow = flowboxed.unbox

	switch flow {
		case .home(let screen):
			displayScreen(screen, userData: userData, sender: sender)

		case .orders:
			coordinatingResponder?.openFlow(flowboxed, keepHierarchy: keepHierarchy, userData: userData, sender: sender)
	}
}

If the flow transfer request is from some of its children, it routes to its private method that displays that screen. If the target flow is not its responsibility, it will pass the request to next coordinatingResponder, upwards the responder chain. Note that HomeCoordinator does not know what that next (parent) object is. It simply passes the request through the magic conduit. Someone will handle it. 😇

Responder chain in UIKit is truly wonderful concept. This particular implementation of Coordinator pattern is just one of its many uses.

Mac Studio is perfect Mac for app developers

Fri, 11 Mar 2022 18:00:00 +0000

Two years ago I lamented the gaping hole in the Apple’s desktop Mac lineup. I ended that post with:

I would be perfectly happy to pay $3,000+ for a machine with that [16-ish core] CPU housed in Apple-designed case and cooling. If only Apple offered it.

Few days ago, Apple released exactly what I asked for: Mac Studio is a very powerful workstation in 3.6L case. CPU can have up 10 (M1 Max) or 20 (M1 Ultra) cores paired with impressive GPU.

It’s unreal how much power they packed into such a small chassis. I knew they could do this. Apple designed custom PSU of about 370W that can power M1 Ultra and with SoC being the entire machine, 2/3 of the volume is used for whisper-quiet cooling solution. Perfection.

In the last two years, we have invested into 3 rather powerful ad-hoc Mac builds. I will wait for the proper ROI on all of them but in about 2 or 3 years our small agency will transition to Mac Studio(s). There is no doubt in my mind – these machines are amazing purchase for application developers and will easily last you 5+ years for any kind of app development you do. Anything.

Difference between default machines is significant thus I won’t recommend which one to buy — do the one you can afford. Both are more than capable. What I can advise is to not pay extra for SSD. This is desktop machine with multiple Thunderbolt 4 ports which means you can add as much super-fast external storage as you need over time. 40Gbps is more than enough even for 4x external NMVe RAID boxes. As for memory, I am using 32GB in all my machines and am nowhere near to be limited. But with memory being non-upgradable, I would opt for 64GB if possible; not the end of the world if not.

Apple is truly back in the pro market.

Async Operation for Core Data imports

Sat, 30 Oct 2021 10:20:40 +0000

I wrote about my Essentials snippers 4 years ago. I am still using them, slightly updated and modernised but they are still one of the first stops to choose what I need when I start a particular UIKit project.

One advanced feature in there is AsyncOperation which a subclass of Operation which will not set itself to finished until the asynchronous task you give it is done. OperationQueue and Operation were a staple of my code for a very long time, whenever I needed to be sure things are being done in proper order. It’s super useful and simple to use API in Foundation framework to handle Task management.

Concurrency of Swift itself has been greatly expanded in recent years, with Task / TaskGroup and especially with async / await pattern. Thus I’m not sure how useful AsyncOperation will really be, going forward. I advise all to read-up on modern concurrency patterns and API and choose what’s most appropriate.

Apple’s BlockOperation handles one or more blocks of synchronous code. But what if you have chained tasks where code inside each task is asynchronous? AsyncOperation overrides its internal state and prevents Operation from setting isFinished=true until you do it yourself, manually.

So to create true async Operation

we provide our desired block of code and
we must make sure that we call markFinished at the true end of the task

Developer is the only one that knows what “task is finished” means. I previously gave an example with networking code where markFinished is called inside the dataTask’s closure. I have since changed the internal working of the AsyncOperation but that example usage code still works.

Here’s another example.

When importing data from various web API endpoints into Core Data, I need to make sure Core Data store operations are done 1-by-1 to avoid data duplications. Doing insert/update/delete from multiples concurrent threads is super dangerous as you could end up in situation where you insert the same object multiple times. Cleaning that up from production devices is not fun at all.

Thus I have this simple implementation of SaveOperation:

final class SaveOperation: AsyncOperation {
	typealias ProcessingBlock = () -> Void

	override func workItem() {
		block()
		markFinished()
	}

	required init() {
		fatalError("Use the `init(name:block:)`")
	}
	
	private var block: ProcessingBlock

	init(name: String = "", block: @escaping ProcessingBlock) {
		self.block = block
		super.init()
		self.name = name
	}
}

Basically, you give it a block of code that must complete before the Operation is marked as finished. This code, for Core Data, is always synchronous since all fetches, inserts, deletes are done on same thread, including the saving of the ManagedObjectContext changes at the end of it all.

With this, this is how processing of received JSON is being done:

private(set) var processingQueue = OperationQueue()

...

processingQueue.maxConcurrentOperationCount = 1

...

processingQueue.addOperation( SaveOperation(name: endpoint.logName) {
	[unowned self] in
	let moc = self.vendManagedObjectContextForImporting()

	moc.performAndWait {
		do {
			[PROCESSING HAPPENS HERE]

			// eventually save into core data
			try moc.save()

		} catch let error {
			self.log(level: .warning, error)
		}
	}
})

It really is that simple. performAndWait make sure that everything is sync inside the block() and thus calling markFinished like this is OK:

	override func workItem() {
		block()
		markFinished()
	}

Go the F to sleep

Sat, 23 Oct 2021 13:09:40 +0000

In the AMD Hackintosh land, successfully configuring your build to perform sleep / wake is one of the “Holly shit! It works!” moments.
Even though Intel and AMD CPUs are largely compatible (with few very notable differences), their corresponding chipsets are different story. Until recently, Apple exclusively used Intel CPUs and their chipsets (to some degree). Thus it’s not surprising that OpenCore builds feature sleep / wake pretty much out of the box if you use the identical components as per your chosen SMBIOS value.

Same with many other aspects of computing: in recent Big Sur builds, my Z490+i7-10700K+RX-5500XT build started randomly showing black screen for a second or two before getting back to normal. While harmless in general, it was super annoying and seriously disrupted day to day work of my wife (she’s using that build). Originally I used iMacPro1,1 as SMBIOS even though the hardware build was pretty much replica of iMac20,1. Lô and behold — simply changing the SMBIOS to the latter made all these black screen problems disappear.
I am sure some other solution could be found with enough poking around the ACPI but as we will see – that’s a long and painstaking road.

AMD chipsets are a different story, since they use different device components and their respective configurations and firmwares. Especially with USB controllers: X570 chipset has 3 USB controllers in itself. Coupled with the fact that manufacturers can write significantly different ACPI for the same darn thing — for some reason MSI-made boards can’t boot Monterey beyond beta 3 — and you could find yourself in quite a mess.

For almost a year now, my own build using AMD 5900X running on ASRock X570 ITX board had sleep disabled. It’s such a glorious CPU, giving you 12 cores / 24 threads running at 3.7GHz (4.9GHz boost) and costing just ~€750 with the motherboard included (try speccing that config with Intel, I dare you). But sleep…sleep was simply “a bridge too far”.

Even after I mapped my USB, added USB power properties, switched from iMacPro1,1 to MacPro7,1 SMBIOS…nah, did not budge. Machine would turn off screen but would never actually enter sleep. What’s worse, it would lock-up so heavily that nothing responded anymore. Not even power button worked so the only way to turn it off would be pull the wall power. After some half-working attempts with HibernationFixup and some random SSDTs I found online, I decided to dig in deep and learn how ACPI sleep actually works.

ACPI spec is huge and not easy to dig into. First thing is defining the goal: what exactly I am after. In desktop machines, I want to achieve S3 sleep state, which means “suspend to RAM”. S4 is hibernation or “suspend to disk” which is very useful for laptops but for desktop machines it is not. S0 is fully awake state.

After reading through Power Management section and coupled with knowledge from previous attempts — the key to the sleep was proper implementation of _PRW method. Through implementations of Power resources for Wake method, devices tell the OS what sleep states they can be put into while still keeping the ability to wake the system. It also specifies what (if any) other power resources are needed for the device to properly wake up.

It’s always useful to look at examples. So here’s typical one taken from actual MacPro DSDT table:

Method (_PRW, 0, NotSerialized)
{
    If (OSDW ())
    {
        Return (Package (0x02)
        {
            0x69, 
            0x03
        })
    }
    Else
    {
        Return (Package (0x02)
        {
            0x69, 
            0x04
        })
    }
}

OSDW is ACPI method Apple uses to check if the active OS is Darwin (macOS). So we see that return value from this method is package of two elements: first argument is the same while second is 3 for macOS, 4 for others (Windows, Linux etc).

ACPI spec tells that Package format from this method means this:

Package {
   EventInfo                      // Integer
   DeepestSleepState              // Integer
}

DeepestSleepState is an Integer that contains the deepest power system sleeping state that can be entered while still providing wake functionality.

Okie, so this device can go into S3 sleep state for macOS and S4 for others. Looking across many other _PRW implementations in MacPro ACPI, the similar pattern is present.

OK, let us now look at DSDT for my ASRock X570 motherboard ACPI. It has ~20 _PRW implementations and in all but one case that second argument is 0x04. Here’s one:

Method (_PRW, 0, NotSerialized)  // _PRW: Power Resources for Wake
{
    Return (GPRW (0x08, 0x04))
}

Taking cue from Apple’s implementation, we should override this second parameter to be 0x03. How to do that in OpenCore?

We employ trickery that experienced iOS developers will know as swizzling: replace existing API with our own, providing custom implementation. We need to hot-patch manufacturer-provided ACPI and rename existing GPRW method into something else, say XPRW.

(1) In OpenCore’s config.plist add this dictionary under ACPI/Patch:

<dict>
	<key>Base</key>
	<string></string>
	<key>BaseSkip</key>
	<integer>0</integer>
	<key>Comment</key>
	<string>GPRW to XPRW Rename</string>
	<key>Count</key>
	<integer>0</integer>
	<key>Enabled</key>
	<true/>
	<key>Find</key>
	<data>
	R1BSVwI=
	</data>
	<key>Limit</key>
	<integer>0</integer>
	<key>Mask</key>
	<data>
	</data>
	<key>OemTableId</key>
	<data>
	</data>
	<key>Replace</key>
	<data>
	WFBSVwI=
	</data>
	<key>ReplaceMask</key>
	<data>
	</data>
	<key>Skip</key>
	<integer>0</integer>
	<key>TableLength</key>
	<integer>0</integer>
	<key>TableSignature</key>
	<data>
	</data>
</dict>

Thus with this, system provided GPRW method is now called XPRW.

(2) Create custom SSDT table with new implementation of GPRW:

DefinitionBlock ("", "SSDT", 2, "ATNV", "GPRW", 0x00000000)
{
    External (XPRW, MethodObj)    // 2 Arguments

    Method (GPRW, 2, NotSerialized)
    {
        If (_OSI ("Darwin"))
        {
            If ((0x04 == Arg1))
            {
                Return (XPRW (Arg0, 0x03))
            }
        }

        Return (XPRW (Arg0, Arg1))
    }
}

In cases where second argument (Arg1) is 0x04, replace it with 0x03 while passing the first argument (Arg0) as it was. In all other cases just pass to original method implementation.

I called this SSDT-GPRW.aml and included it under ACPI/Add in config.plist.

So…is it working? I am hesitant to claim with 100% certainty but so far — it is. With keyboard directly attached to USB port, with keyboard working as Bluetooth, both across multiple attempts. My USB ports usually have external USB disk, Glorious and Logitech USB mice, Blue Yeti USB microphone and powered USB hub in the LG 27GN950 monitor. Monitor display goes from RX 570 GPU over DisplayPort.

Build goes into sleep and wakes up when mouse is moved or keyboard key is pressed. There’s still possibility something could be problematic but I am hopeful. Fingers crossed.

Nope, you GTFO.

Tue, 19 Oct 2021 09:20:00 +0000

Radar or GTFO!

That’s an old joke in Apple developer circles which was meant to be cute but…really wasn’t. It was often remarked you shouldn’t be speaking to Apple developers about some bug if you don’t already have the bug report number at hand. You could still approach them, of course; it would usually end with some nodding on their part with advice to file a radar and let them know. Back when Apple was still an underdog, it was even some point of pride to publish your RDAR number. Like — “see, I did my part” to make it better for everyone.

That attitude was delusional back then; it’s downright insulting to ask for it today.

Even when Apple was an underdog they were still a multi-billion dollar company. They were losing money like crazy but they were still a huge company that had all that money to lose. This expectation that indie developers should invest their own time (=money) to work for free was ludicrous. But hey – that was the sentiment due to Apple wielding a lot of goodwill in its small developer community.

Apple is not an underdog anymore, they are the largest and most profitable company in the world. That goodwill largely evaporated in recent years due to Apple’s attitude and hostile actions towards 3rd-party developers.

Most importantly though — Apple never appreciated all that work. Despite all the talk you would hear from developer evangelism team or particular engineer’s occasional proactivity, Apple as entity has never done a concerted effort to appreciate all the free QA work they were getting.

That RDAR service was praised by every Apple employee I spoke to, as the best bug tracking service they have used. Maybe internally it was, I’ve never used it as such. From outside though — it was a horribly buggy, crash-prone web UI which was so frustrating to use that multiple people spent time to write Mac apps to workaround its issues. There were at least two public web wrappers / mirrors built around it, so people could publish what they reported so that other don’t waste time chasing the same issues.

It was so bad that there was an attempt to nudge Apple to do better, if they expect people to continue filing bug reports. There were many blog posts explaining how to file a bug report so it’s actionable by Apple engineers.
Few years ago, Apple did replace RDAR with Feedback Reporter which wasn’t much better. It took them a year to make it even remotely usable but it’s still slow today, it remains a chore to use.

So what happened if you actually persevered and filed a bug report? Usually: nothing. Literally nothing.

Open cases would linger unanswered for months or years. Maybe once a year you will get automated response to “re-check if the bug still applies to newer xOS version”. In some cases they would ask you to custom-build a project demonstrating the issue, since apparently description of the problem was not enough. Even if you make the project example, nothing guaranteed response nor resolution of the issue. I believe the number of cases yielding any useful result was abysmal.

Apple was and still is expecting people to do free QA work for them without any obligation from their side.

But the worst thing (to me, at least) is that every June, after WWDC, I would see breathless “call to arms” from non-Apple people to file feedback as soon as you can if you want “your bugs” fixed in time. If you want it done for major .0 release, make sure to spend your June/July filing issues you find. Install betas, test what you can, hurry up!

Can we collectively stop with this nonsense? 😖 Please!

Apple earned billions from the App Store in the last year alone, more than 99% of 3rd party devs earned combined. It’s their obligation to deliver reliable SDK they expect us to use. Because our apps are improving functionality and increasing desirability of their devices / platform.

Apple does not lack the means to do the correct thing.

Apple can and should hire 100s of people to just scour Stack Overflow, their own developer forums, subscribe to developer blogs, make lists on Twitter tracking outspoken developers.
These employees should make note of every issue that’s being mentioned.
Information should be accepted in any way or form: email, tweet, blog post, whatever.
They should hire 1000s or people to attempt to replicate the issues on their own.
Those employees should proactively contact people and ask them for more details if they are unable to replicate issues.

An approach like this would very likely make people feel appreciated and potentially willing to make an effort and do all the things that Apple expect for granted: make example projects, collect sys info etc.

An approach like this would also give Apple an immense pool of potential future developers and engineers. All such QA interns building projects will learn their tools, learn their APIs and will strive to either work for Apple or build apps for their platforms as 3rd party. There are few nicer initial points on your resume in this particular industry than “Software QA at Apple Inc” thus I have little doubt that Apple would have issues finding people to fill-in these positions. (As long as they don’t insist they live in Bay Area.)

This is not rocket science and I don’t propose anything radical. Many client-service-oriented companies do exactly this.

Design community learned long ago to say NO to spec-work, to not “work for exposure”, to reject various other attempts to extract work for nothing. I really hope that Apple dev community learns that lesson too: you don’t owe Apple anything.