Apple Dev Search: A search engine for Apple developer blogs

2026-03-24T00:00:00+00:00

This isn't new, but I'm convinced it's useful and think it needs a boost. Also, it might be a slight antidote to LLMs helping themselves to all our content.

appledevsearch.com</a> is a search engine; it searches blog posts written by people who develop for Apple platforms. Hopefully the uses are obvious: pick just about any topic you can think of to do with iOS and macOS development and someone will have been writing about it.

Sure, you'll have regulars that you read, but you can't follow everyone! When you land, there's a list of the latest articles from whoever's been writing. But there's also a great depth of past material – just waiting there until you need to find out about a particular topic.

At the time of writing it's searching 14989 articles across 674 blogs (including this one).

I built it a few years ago, so it's been around for a while. Frankly I'm kind of surprised that more people don't use it – I find it fairly useful myself. I hope people still read! Possibly it doesn't help that I changed the domain at some point (it used to be iosdevsearch.com).

Of course, you could use a generic search engine, but I bet you'd get more noise than you do with this.

The blog list comes from the iOS Dev Directory</a>, so if you write and you're not listed there, then you should go and sort that out. Dave has some recent comments about the directory</a> too.

A note: there are a bunch of blog categories in the directory. Apple Dev Search indexes just one of them: development blogs, which is material written by individuals. Of course there will be other good stuff in other categories too, but I was finding with company blogs in particular that you end up with a lot of content marketing. We don't want that.

Build, run and debug iOS and Mac apps in Zed instead of Xcode

2026-03-14T00:00:00+00:00

This article will get you building iOS and Mac apps in the Zed editor, with a proper build / run / debug cycle, on devices and the iOS simulator. With the help of a new tool I've developed, this makes Zed genuinely usable for building apps for Apple platforms. This is something of a first from what I can tell.

Out of the box, Zed comes with a Swift extension which handles plain Swift projects, but it doesn't understand Xcode projects.

But with a little setup, you can have a real development process:

Code completion and navigation that understands your project</li>

Build Xcode projects just as fast as Xcode</li>

Run iOS apps on the simulator and real devices</li>

Run Mac apps</li>

Debug your apps on the simulator, devices and the Mac</a></li>
Run tests right from your code, just like in Xcode</a></li>
Use SwiftUI previews (after a fashion)</a></li> </ul>

Why Zed? I've been using the Zed editor for writing iOS and Mac apps for a while now. I won't try and convince you to use Zed; suffice to say I find pretty much any other modern editor is better than Xcode for actually writing code. So I've been through AppCode (used it for years although it often didn't work properly; now decommissioned), briefly looked into VSCode (meh), used Fleet for a bit (it didn't quite know what it was about, and now it's been canned), and now Zed. </blockquote>
Used in the real world</h2> This isn't just an article about what you could do in theory – I built my new app, DelayDrop</a>, mainly in Zed. It's a pleasure to work in a genuinely good code editor, and switching into Xcode for things like previews really isn't an imposition.
DelayDrop is an iOS and Mac app for sending anything to your other Apple devices – even if they're locked, off or elsewhere – in two taps. It beats AirDrop because your other device can be anywhere in the world; and even if it is nearby, you're still winning because you don't have to get up and unlock it.
And if that sounds like a plug for DelayDrop, that's because it is!
Get started</h2>
Open your project's folder in Zed.</li>
Open a Swift file. Zed will offer to install the Swift extension. Do that.</li> </ul>
Now after a minute you should have basic syntax highlighting. Most of your imports won't work yet though – so you'll see unresolved symbols, and code completion and command-clicking to navigate around will be pretty limited.
Install xcode-build-server</h2>
This enhances the language server so it understands your project, which gives you code navigation and completion and fixes syntax highlighting. (I didn't write this tool.)

🔧 brew install xcode-build-server</code></li>
🔧 Run xcode-build-server config -scheme MyScheme</code> in your project directory (there are also arguments for workspace and project if you have multiple candidates)</li>
🔧 Do a build in Xcode</li>
🔧 Restart Zed</li> </ul> You should now be able to command-click symbols to navigate around, and code completion should work. (This can be a little slow at first.)(This created a buildServer.json</code> file in your project directory. You probably won't look at it again, but it's good to know it's there. See xcode-build-server's repo</a> if you want to know more.) Install xcede</h2> I wrote xcede</code> to help build, run and debug Apple platform apps from the command line. We'll use it for our Zed tasks. (It's also a debug adapter; we'll get into soon.) 🔧 Follow xcede's installation instructions</a>, then restart Zed. 🔧 brew install xcbeautify</code> This is optional, but your build logs will be much easier to read. 🔧 Now in your project's root folder add a config file xcede.yml</code> (you have options</a>: [.]xcede.yml|yaml|toml|json</code>). Something like this: scheme: MyApp # device, sim or mac: platform: device # not required for Mac apps: device: "Tarquin's iPhone 19" # Faster builds: xcede uses Xcode to build your project via Applescript. # If you don't like this idea you can leave it out and xcede will # use xcodebuild instead. That's quite a lot slower, but it works just # as well. buildwithxcode: true # There are many more options, including profiles (groups of settings) - # which make it much easier to switch between different devices and # simulators for example. Also options for file naming, location and # format (toml, json). See `xcede help`. # # Note that these options are available on the command line too, like # `xcede --scheme MyApp`, but a config file works better for our # purposes. </code></pre> Now try out xcede</code> from the command line: xcede build</code></li> xcede run</code></li> or both at once: xcede buildrun</code></li> </ul> Create Zed tasks</h2> You probably know by now that building and running aren't really concepts in Zed: they're just examples of tasks. Zed's idea of a task is very generic: it's just a way to run a command in a shell. You define tasks yourself (although some are created automagically by language plugins). 🔧 Add this to your global tasks file: { "label": "SwiftBuild", "command": "xcede build", "allow_concurrent_runs": false, "reveal": "no_focus", "hide": "never" }, { "label": "SwiftRun", "command": "xcede buildrun", "allow_concurrent_runs": false, "reveal": "no_focus", "hide": "never" } </code></pre> Now run each of your tasks. You should get nicely formatted build output, and Zed should launch your app and show its console output. 💡 You can command-click the file location on errors and warnings in the build log to jump to their location in code. 💡 Do you log with Apple's unified logging system (oslog)? You need some extra settings to show that; see xcede help</a> for details. 💡 Running Mac apps? Make sure you read that section of the xcede help</a>. Add keyboard shortcuts for your tasks</h2> Notice we save files first, because who saves manually? (Also, you'll want to choose your own key bindings of course.) "cmd-b": [ "action::Sequence", ["workspace::Save", ["task::Spawn", { "task_name": "SwiftBuild" }]] ], "cmd-r": [ "action::Sequence", ["workspace::Save", ["task::Spawn", { "task_name": "SwiftRun" }]] ] </code></pre> Note this is only one way of organising things. I use global tasks, defined once, and an xcede.yml</code> for each project. You might prefer something different, say project tasks instead with all settings as command line arguments. Or some other variation. It's up to you. </blockquote> Bonus: Basic Swift package support</h2> If you open a Swift package rather than an Xcode project, your global build and run tasks will still work. You don't need xcede.yml</code> for this. xcede just runs plain swift build</code> and swift run</code>, so if you need anything more elaborate, define a project task. Debugging</h2> 🔧 First you need to configure zed to use xcede's DAP wrapper. Add this your zed settings file (Settings → Open Settings File): "dap": { "Swift": { "binary": "/path/to/xcede" } } </code></pre> 🔧 Now define a debug task. Like our build and run tasks, this works globally and isn't project-specific – the project settings come from the config file. { "label": "SwiftDebug", "adapter": "Swift", "request": "launch", // This says we want xcede to manage the process. // You could pass the path to an executable here, and that // would just launch lldb on that executable, as if you // weren't using xcede. "program": "xcede:", // This will build your app first, and is optional. "build": "SwiftBuild" } </code></pre> Now start the debugger (Run → Start Debugger) and choose your task. Set some breakpoints and make sure it works! You should be able to step through your code, see variables' values and the call stack, and do all the usual things. Aside: what's going on here? If you're interested: the DAP (debugger adapter protocol) layer sits between the IDE and lldb. It provides a standard way for the IDE to talk about debugging: without this, IDEs would have to implement a different protocol for every debugger they talked to. Communication looks like this: IDE (Zed) → lldb-dap → lldb. When launched without arguments, xcede runs as a DAP server. This adds another layer, so then communication looks like this: IDE (Zed) → xcede → lldb-dap → lldb. Mostly xcede passes commands straight through to lldb-dap, but it adds some useful functionality: With lldb-dap</code> there's no obvious way to attach to a process on a device without hackery with python scripts. xcede takes care of that for you.</li> Even so, attaching kind of sucks because you'd have two separate manual steps to do: first launch the app, then attach with the debugger. Also, its console output would be in a separate zed terminal panel. What I wanted was launch-like behaviour (like you get in Xcode). lldb can do that with a macOS executable, but not on devices/simulators. xcede takes care of the launching, and merges the app's console output into debugger output as you'd expect. Plus it uses xcede.yml</code>, which is convenient.</li> </ul> </blockquote> Running tests</h2> Open some test code and you should see runnable triangles in the gutter next to your tests. Out of the box these work for Swift packages but not Xcode projects, so let's take care of that. 🔧 Add this to your global tasks file: { "label": "$ZED_CUSTOM_SWIFT_TEST_CLASS test", "command": "xcede", "args": ["test", "$ZED_CUSTOM_SWIFT_TEST_CLASS"], "tags": ["swift-xctest-class", "swift-testing-suite"] }, { "label": "$ZED_CUSTOM_SWIFT_TEST_CLASS.$ZED_CUSTOM_SWIFT_TEST_FUNC test", "command": "xcede", "args": [ "test", "$ZED_CUSTOM_SWIFT_TEST_CLASS", "$ZED_CUSTOM_SWIFT_TEST_FUNC" ], "tags": ["swift-xctest-func", "swift-testing-member-func"] }, { "label": "$ZED_CUSTOM_SWIFT_TEST_FUNC test", "command": "xcede", "args": ["test", "-", "$ZED_CUSTOM_SWIFT_TEST_FUNC"], "tags": ["swift-testing-bare-func"] } </code></pre> 🔧 Add a setting or two to xcede.yml</code>: testtarget: MyAppTests # Depending on how you've arranged things, you might have a separate # scheme for your tests, in which case define this: # testscheme: MyAppTestScheme </code></pre> That's it. Click those triangles and run some tests! 💡 If you're using Swift Testing, annotate your test structs/classes with @Suite, otherwise Zed won't see them as runnable. 💡 You can run all tests in your target with xcede test</code>. You could create a task for that. (If your scheme contains tests for multiple targets, you can override the xcede.yml</code> setting like this: xcede test --testtarget ''</code>) How this works: The runnables you see in Zed are created by the Swift plugin. Each one has an associated tag, and also sets variables $ZED_CUSTOM_* for things we need to know – test class and test function. The plugin also defined tasks to execute these runnables using swift test</code>; here, we're replacing the plugin's tasks with versions that use xcede instead. Note that you haven't lost the ability to run Swift package tests – if you've opened a package rather than an Xcode project, xcede will see that and run the appropriate swift test</code> command. </blockquote> UI Previews</h2> Here's a brief video with no sound: </video> Wait, that's just an Xcode window behind a Zed window!</h4> Yes indeed. Xcode helpfully updates the preview whenever you save a file. Changes are a bit slower to appear, but it's actually quite usable and it's nice staying in Zed when the situation allows. Bonus points: preview a different file without leaving Zed</h4> If you were watching carefully, you'll have noticed that I switched to working on an entirely different app screen part way through the video. I did that with a small shell script that I've named xcode-open-file</code>: #!/bin/sh osascript <<END tell application "Xcode" open POSIX file "$1" end tell END </code></pre> and a Zed task: { "label": "Open current file in Xcode", "command": "xcode-open-file", "args": ["$ZED_FILE"], "hide": "always", "reveal": "never" } </code></pre> which of course I created a key binding for. That's it!</h2> Maybe it looks like a whole bunch of moving parts, but don't be put off – most of it is one-off setup. After that, each new project you work just needs an xcede.yml</code> config file. Here is xcede's documentation page</a>. For bug reports or to discuss possible enhancements, you can engage with the project at the xcede Codeberg repo</a>. @lxmn@mastodon.social

On iOS scenes, and why your UIApplicationDelegate method isn't being called 2020-11-20T00:00:00+00:00 So, you're being a good modern iOS developer and adopting scene support in your UIKit app. You've implemented application(_:configurationForConnecting:options:)</code>, but it's not being called consistently. What's going on? Is it a bug in iOS? In fact, things are probably behaving as they should, but this isn't well documented and can be super confusing. Even once I started to realise what was going on, it took quite some time to get to the bottom of it all. It's all to do with scene restoration. What happens when your app starts</h2> When your app starts up after a previous launch, iOS wants to restore its windows so the user feels like they're picking up where they left off. To do this, iOS saved the configuration details of each of your app's scenes last time the app was run. When the app is launched again, it reads the saved scene config and recreates those scenes. This happens even on the iPhone, where you only have one window. Here are the various permutations at launch time, assuming you've implemented application(_:configurationForConnecting:options:)</code> for some custom behaviour: Case 1: App launched for the first time ever</h3> The app doesn't know what type of scene to put in the window, and calls application(_:configurationForConnecting:options:)</code> to find out. So far things are as we expect. (If you don't implement this delegate method, it just falls back to the first suitable entry in your Info.plist's</code> scene manifest, if it has one.) Case 2: New window created</h3> An iPad user creates a new window. The app doesn't know what to put in this window either. This is the same as case 1. Case 3: App relaunched</h3> The OS wants to restore your windows. To do this, it has remembered the scene configs of the windows you had open last time. Surprise! It knows what scenes to put in the windows, and doesn't ask your app delegate. It just goes ahead and creates the scenes using the remembered configs. For the poor developer thinking in terms of a window being created when the app starts up, this is confusing. But if you think in terms of windows being restored at startup, not created – even when there is only one – it starts to make sense. How to forget saved windows</h2> During development, you might want to reset things so your windows are forgotten and your delegate method is called on next launch. To do that: for iOS, delete the app</li> for Catalyst, delete the app's container</li> </ul> Restoring content</h2> This is all about restoring scene types. To be most useful to the user you might want to restore windows' content as well. Your starting point for this is NSUserActivity</code> and the various state methods on your UIWindowSceneDelegate</code>. Good luck.

Wait, that's just an Xcode window behind a Zed window!</h4>
Yes indeed. Xcode helpfully updates the preview whenever you save a file. Changes are a bit slower to appear, but it's actually quite usable and it's nice staying in Zed when the situation allows.</p>

Apple Dev Search: A search engine for Apple developer blogs

Build, run and debug iOS and Mac apps in Zed instead of Xcode

On iOS scenes, and why your UIApplicationDelegate method isn't being called

Restoring content</h2>
This is all about restoring scene types</em>. To be most useful to the user you might want to restore windows' content</em> as well. Your starting point for this is `NSUserActivity</code> and the various state methods on your UIWindowSceneDelegate</code>. Good luck.</p>`

Apple Dev Search: A search engine for Apple developer blogs

Build, run and debug iOS and Mac apps in Zed instead of Xcode

Get started</h2> Open your project's folder in Zed.</li>

Install xcode-build-server</h2> This enhances the language server so it understands your project, which gives you code navigation and completion and fixes syntax highlighting. (I didn't write this tool.)</p>

Wait, that's just an Xcode window behind a Zed window!</h4> Yes indeed. Xcode helpfully updates the preview whenever you save a file. Changes are a bit slower to appear, but it's actually quite usable and it's nice staying in Zed when the situation allows.</p>

On iOS scenes, and why your UIApplicationDelegate method isn't being called

Restoring content</h2> This is all about restoring scene types</em>. To be most useful to the user you might want to restore windows' content</em> as well. Your starting point for this is NSUserActivity</code> and the various state methods on your UIWindowSceneDelegate</code>. Good luck.</p>

Wait, that's just an Xcode window behind a Zed window!</h4>
Yes indeed. Xcode helpfully updates the preview whenever you save a file. Changes are a bit slower to appear, but it's actually quite usable and it's nice staying in Zed when the situation allows.</p>

Restoring content</h2>
This is all about restoring scene types</em>. To be most useful to the user you might want to restore windows' content</em> as well. Your starting point for this is `NSUserActivity</code> and the various state methods on your UIWindowSceneDelegate</code>. Good luck.</p>`