I am very excited to announce that after almost four and a half years of development, Tusker, my iOS app for Mastodon is now available on the App Store!

If you follow my blog or follow me on the fediverse, you’ve no doubt heard me talk at length about it before, so I’ll spare you the details here. Suffice it to say that Tusker is a completely native iOS app that supports many of the latest features of both Mastodon and iOS.

This is not the end of development, there are still lots of features I plan to add—including push notifications and the ability to edit posts. If you’re already in the beta via TestFlight, you’re more than welcome to remain there. It will continue to get beta updates with new features and bugfixes ahead of the App Store releases.

I recently got nerd sniped by this tweet from Zhuowei Zhang about playing the Bad Apple video in the Dynamic Island on the iPhone 14 Pro. His original implementation used a webpage and the media session API, and this worked, but the system plays an animation when the artwork changes, so the framerate was limited to 2 FPS. Not ideal for watching a video. So, I wanted to see how much closer to watchable I could get.

This post isn’t going to be a detailed guide or anything, just a collection of some mildly interesting things I learned.

I’m very excited for the project I’ve been working on all year to finally be public. LiveView Native is a library that lets you build native apps backed by Phoenix LiveView. I’ve been developing the iOS client which is backed by SwiftUI.

Using LiveView Native lets you avoid duplicating business logic on the frontend and save time on implementing dedicated APIs for native apps. The iOS client can be integrated into any existing app by using a single SwiftUI view, so it’s easy to adopt it for just a single screen at a time.

You can find the documentation^[1] for the Swift package here, including a step-by-step tutorial which walks you through building a complete app with LiveView Native.

We’ve also developed a simple chat app which was used by the attendees of ElixirConf this year, and serves as a complete example of a LiveView Native app.

I’m very excited to see what people build with it.

With iOS 16, Apple switched on TextKit 2 for UITextViews. But, if you access any of the TextKit 1 objects on the text view, it will automatically fall back to a compatibility mode. All of the work I did to mimic Safari’s link context menu animation was, of course, using the TextKit 1 APIs, so it was blocking me from fully adopting TextKit 2. So, here’s how to update that code.

A while ago I wrote about some trouble I had getting Xcode to cooperate with my efforts to bring my app file size back under control after adding a new Swift Package dependency. Well, I’m happy to say I finally have: the most recent TestFlight build of Tusker has a 6.7MB install size, down from 25MB.

Ultimately I did take the route of turning my framework into a Swift Package. I revisited it because I noticed in another project that local packages inside the same folder as the main project worked perfectly fine. The only difference I found was that the project where it worked used only an .xcodeproj, whereas Tusker used an .xcworkspace. So, I deleted the (for unrelated reasons, no longer necessary) workspace and found that, after quitting and relaunching Xcode, the local package worked perfectly fine.

I briefly started writing a feedback report, but upon further testing I found that xcworkspaces in general weren’t the problem—a new project and workspace worked fine. So, I gave up trying to reproduce it and assumed there was just something weird about the 3.5 year old workspace.