swift posts

Subscribe to just swift posts via RSS.

Replicating Safari's Link Preview Animation

In iOS 13, Apple replaced the Peek and Pop force touch system with new context menus and previews[1]. These new previews have a fancy animation for when the appear, in which they expand out of the content and onto the screen. Back when I first replaced the previews in Tusker with the new context menus (over a year ago, shortly after WWDC19), I wanted to replicate the behavior in Safari for links and mentions in post bodies. At the time, there was pretty much zero official documentation about the new context menu APIs, so I decided to wait for either Apple to publish docs or for someone else to figure it out first. Now that WWDC20 has come and gone, and I’ve been working on it a little bit at a time for over a year, I finally have a fully working implementation.

Writing a JavaScript Syntax Highlighter in Swift

For a project I’m currently working on, I need to display some JavaScript code[1], and because I’m a perfectionist, I want it to be nice and pretty and display it with syntax highlighting. Originally, I was planning to use John Sundell’s Splash Swift syntax highlighting library (both a “(Swift syntax) highlighting library” and a “Swift (syntax highlighting) library”). It can already render to my desired output format, an NSAttributedString, and it has an interface for defining new grammars, which I thought would make it relatively easy to extend to support JavaScript. After getting started, it quickly became apparent that it wouldn’t be quite so easy. In addition to writing all the code to parse JavaScript, I’d have to go through the Splash codebase and understand a decent amount about how it works. This grew uninteresting pretty quickly, so I decided I would try just writing everything myself. My highlighting needs were fairly simple, how hard could it be?

Simple Swift Promises

Recently, I’ve been working on cleaning up the networking code in Tusker, my iOS client for Mastodon/Pleroma and I briefly played around with using the new Combine framework as well as the built in URLSession.DataTaskPublisher helper. Combine, much like SwiftUI, uses Swift’s incredibly powerful type system to great advantage because it’s a Swift-only framework. It’s quite efficient, but because there are so many generic types and implementations of different protocols, the API (in my experience) isn’t the most pleasant to work with. I was thinking about other asynchronous programming schemes and the one that came to mind as being the nicest to use was JavaScript’s Promises. It has a fairly simple API, so I started wondering how much work it would be to build something similar in Swift. Turns out: not that much.

Faking the Mongo Eval Command

One of the changes in MongoDB 4.2 was the removal of the eval command. While a reasonable security measure, this is rather annoying if you’re building an app for interacting directly with a Mongo database. If you want to be able to run commands directly on the database, you now have to go through the mongo shell. This seems straightforward, but actually getting the data back into a format that’s usable is a bit of a hassle.

Mocking HTTP Requests for iOS App UI Tests

I recently decided to start writing User Interface tests for Tusker, my iOS app for Mastodon and Pleroma. But I couldn’t just write tests that interacted with an account on any real instance, as that would be far too unpredictable and mean my tests could have an impact on other people. The solution to this problem is, of course, mocking. The core idea is that instead of interacting with external things, your program interacts with mock versions of them, which appear to be their real counterparts, but don’t actually perform any of the operations they claim to. This allows for very tight control over what data the application receives, making it much more amenable to testing.

Unfortunately, if you search around, some of the most common solutions on the internet recommend using the environment variables (one of the only ways of sending data directly from the test to the application under test) to insert the mocked response into the app. Meaning, for every API response you need to mock, you would have an environment variable that contains the response data. This isn’t a great solution, because it leaves whole code paths untested (everything after the request URL would be generated). It would also mean that there’s no way of testing things like what requests are actually made by your app.

The solution to this problem is to actually run a local HTTP server that functions as the API server. This way, the app can communicate with the web server exactly as it would in the normal operating environment, but still have strictly controlled data. Of course, actually doing this isn’t quite so straightforward.