<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Xcode on The Final Artefact</title><link>https://www.thefinalartefact.xyz/tags/xcode/</link><description>Recent content in Xcode on The Final Artefact</description><generator>Hugo</generator><language>en-gb</language><lastBuildDate>Mon, 24 Nov 2025 16:01:56 +0000</lastBuildDate><atom:link href="https://www.thefinalartefact.xyz/tags/xcode/index.xml" rel="self" type="application/rss+xml"/><item><title>Using Xcode Pre- and Post-actions to Observe Changes to Defaults</title><link>https://www.thefinalartefact.xyz/post/build-pre-post-actions-observe-default/</link><pubDate>Mon, 24 Nov 2025 16:01:56 +0000</pubDate><guid>https://www.thefinalartefact.xyz/post/build-pre-post-actions-observe-default/</guid><description>Because UserDefaults persistence is opportunistic, it’s often hard to tell when values truly flush and what changed between runs. In the article I set up an app group prefs watcher with fswatch, convert the binary plist to XML via plutil, and log a timestamped diff for every write—no breakpoints, no in-app logging. If you’ve ever wondered “what did my app really persist?”, this workflow makes it obvious.</description></item></channel></rss>