Tusker is divided up into two main parts: the app target itself and a separate framework which encapsulates everything that deals with the Mastodon API. I recently added a Swift Package to the app for uninteresting reasons. But, because the package is used both by the framework as well as the app itself, this caused a surprising number of problems.

As my luck would have it, just a few weeks after I published my last post on this topic, the iOS 15.4 beta came out which broke that hack and once again made my scroll indicators invisible in dark mode.

I recently started building a new iOS app and found myself with a need to parse HTML in order to extract some information. My goto tool for this in the past has been SwiftSoup. In this app, I have to deal with larger documents than I’d used it for previously, and unfortunately, its performance leavse something to be desired. Much of the issue comes from the fact that I only want to extract the first paragraph of a document, but SwiftSoup always needs to parse the entire thing—for large documents, potentially a lot of unnecessary work^[1]. And, as far as I could find, there are no streaming HTML parsers written in Swift. One I did find, however, was CloudFlare’s lol-html. It’s specifically designed for speed and low latency, exactly what I want. But it’s written in Rust.

Update: Since this post was published, the situation has changed and the workaround presented here is no longer valid. See the follow-up.

Here’s a stupid bug I ran into recently: if you’ve got a WKWebView in an iOS app and it shows something that’s not a normal webpage^[1], the scroll indicator appearance switching doesn’t work. What I mean by that is, while the indicators appear correctly (with a dark color) when the system is in light mode, they do not take on a light color when dark mode is enabled. This renders the scroll indicators invisible against dark backgrounds, which can be annoying if you’re using the web view to display potentially lengthy content.

Last time I wrote about programmatically toggling natural scrolling on macOS and building a menu bar app to let me do that quickly. It works very well, but there’s still a little bit of friction with having to click the menu bar icon—or, more accurately, forgetting to click it and then scrolling backwards and realizing you forgot. As I mentioned at the end of my previous post, one obvious way to extend it, now that the ability to programmatically set direction is in place, would be toggling it automatically based on what’s currently connected. This turned out to not be terribly complicated, but dealing with IOKit was somewhat annoying, so I thought I’d write it up.