If you’ve got an M1 Mac you might have noticed that when you run Xcode in native
Apple Silicon mode, when building for the simulator it’ll use the
This is good, except if you’ve got a lot of legacy dependencies that haven’t
been updated to support XCFrameworks. Most binary dependencies out there still
assume SDK =
iphonesimulator means ARCH =
x86_64, which will result in
One simple fix is to simply run Xcode in Rosetta. This will make it act just
like you’re still on an Intel Mac, and the Simulator will build for
However doing this means you miss out on some of that legendary Apple Silicon
To workaround this, you can basically force your project to cross-compile
when using the
iphonesimulator SDK to the
FINAL FANTASY XIV is an MMORPG for Windows, macOS, and PlayStation. The Mac
version is essentially an identical build of the Windows version, except it
runs in a customised version of Wine. The launcher
/ patcher for FFXIV is pretty famously disliked, and for Windows users there’s
a very good custom one, but
unfortunately it doesn’t work for Mac.
So I made my own.
One of the more interesting challenges in doing so was dealing with how the
FFXIV Launcher passes arguments between the launcher and the main game
executable. In this post, I’ll do a deep dive into my journey of discovery to
reimplement this logic in Swift.
It’s now been almost exactly one year since Apple Music was announced, so I
thought I’d give a bit of a retrospective of that time.
I inadvertently kicked up a big stink two months ago by pointing out how slow
Swift was, which was version 1.1 at the time. Apple has since responded
with a new beta version of Xcode which includes a shiny new version of Swift,
version 1.2. Since it promised to:
… produce binaries that run considerably faster, and new optimizations
deliver even better Release build performance.
I thought it would be prudent to re-run my tests and see just how much Swift
has improved, if at all.