I wanted the ability to tap and drag across cells to be able to select multiple items in the list at once. Tapping cells one by one can get tedious if you want to select a large number of cells after all. On its face this seemed like a simple ask, this is a fairly common UI pattern. However, this ended up requiring a fair amount of effort and custom logic to accomplish within SwiftUI’s frameworks. This is typical of SwiftUI, the default controls are very simple and easy to use, but extensive customization can be painful.

While I’m not advertising this as the best way to implement a list by any means, this post may be useful if you’re looking to accomplish something similar in SwiftUI. Surprisingly I ended up with something that I’m satisfied with.

If you’re just interested in the source code you can check it out here. Be warned it is a bit messy, but it is self-contained and you can compile and play around with it. Or, you can check out Lyrigraphy on the App Store to try the finished product in the lyrics screen!

System view

The default list implementation does have a multi-selection mode similar to what I’m describing. However, it doesn’t quite meet what I was looking for visually or functionally. First, the list must be in an edit mode which changes its appearance. Second, the draggable area is only on the left side of the list. While technically this could have worked, it wasn’t quite the experience I wanted for this important view in my app. So I decided to delve further into this challenge.

Approach

Since I would essentially need to implement this multi-row selection from scratch, let’s break down what the tap and drag gesture actually entails.

1. First a hold gesture needs to be made (~0.5s duration)
2. Until the user releases, a drag gesture is recognized
3. As the user drags across the screen, we need to update the pending selection of items and color them accordingly on screen using the coordinates of the drag
4. If the user is reaching near the top or bottom of the screen, start auto-scrolling the list up or down. There should be a timeout so that it doesn’t repeatedly jump the list.
5. When the user releases, we should add (or remove) items from the selection list and update the visual state accordingly.

As you can see there is actually a lot of requirements under the hood for this gesture. Without a system provided view, we will be doing much of the heavy lifting including boundary math with coordinates.

Implementation

These are the APIs that ended up being essential for my implementation:

1. DragGesture sequenced with LongPressGesture for gesture recognizers
2. highPriorityGesture for applying the gesture
3. CoordinateSpace and GeometryProxy to retrieve coordinates within the scroll view
4. Using PreferenceKeys with GeometryReader to pass coordinate data back up to the containing view
5. ScrollViewReader to control scroll state

It’s worth noting that you should not use a SwiftUI List view for this implementation. Instead use your own ScrollView with a contained ForEach block. A list comes with some nice styling defaults, but it really interferes with a lot of the custom handling required. As one example, it places padding in geometry space between each cell. You can achieve similar list styling with your own modifiers.

PreferenceKeys are at the core of the logic, allowing us to easily reference the exact coordinates of each cell. This allows live updates of the selected items as the gesture is being updated. Setting a custom CoordinateSpace ensures that the coordinates we reference are within the entire scroll view’s context, rather than what is currently on screen. This is important because we autoscroll when reaching the top or bottom of the screen, so the on screen coordinate space of items are not consistent.

We define a struct containing all the fields we need for each cell. We also store the global coordinates because we need to determine if the gesture is currently near the top or bottom of the screen.

struct LinePreferenceData: Equatable {
    let index: Int
    let minY: Double
    let maxY: Double
    let globalMinY: Double
    let globalMaxY: Double
    
    init(index: Int, bounds: CGRect, globalBounds: CGRect) {
        self.index = index
        self.minY = bounds.minY
        self.maxY = bounds.maxY
        self.globalMinY = globalBounds.minY
        self.globalMaxY = globalBounds.maxY
    }
}

The preference key simply wraps this in the outer view to create an array that we can reference. We aren’t guaranteed that this is in order, so we always reference the index of the LinePreferenceData for reconciliation.

struct LinePreferenceKey: PreferenceKey {
    typealias Value = [LinePreferenceData]
    
    static var defaultValue: [LinePreferenceData] = []
    
    static func reduce(value: inout [LinePreferenceData], nextValue: () -> [LinePreferenceData]) {
        value.append(contentsOf: nextValue())
    }
}

Then in each cell in our ForEach, we place a clear background that sets the PreferenceKey’s values. This is a clever hack, capturing the entire geometry space of the cell without affecting its appearance in the UI.

.background() {
    GeometryReader { geometry in
        Rectangle()
            .fill(Color.clear)
            .preference(key: LinePreferenceKey.self,
                        value: [LinePreferenceData(index: lyric.id,
                                                    bounds: geometry.frame(in: .named("container")),
                                                    globalBounds: geometry.frame(in: .global))])
    }
}

It is critical that the .coordinateSpace modifier is applied to appropriate element in your outer view. It must be set on the VStack inside the ScrollView. If it is placed on the wrong element it causes the geometries to be incorrect, and it is very difficult to debug. I ended up spending several hours on this, and the solution was moving the coordinateSpace designation up just one line.

To bring it all together, we need to configure the gesture. Most of this is straightforward, though we do have some business logic to find where the drag started to determine if we are selecting or unselecting with this drag.

var drag: some Gesture {
    LongPressGesture(minimumDuration: 0.5)
        .sequenced(before: DragGesture(minimumDistance: 0, coordinateSpace: .named("container")))
        .updating($isDragging, body: { value, state, transaction in
            switch value {
            case .first(true):
                break
            case .second(_, let drag):
                guard let start = drag?.startLocation else { return }
                let end = drag?.location ?? start
                
                if isDraggingSelected == nil {
                    let dragStartIndex = getStartIndex(from: start.y)
                    isDraggingSelected = dragStartIndex.map { viewModel.selectedLyricIndexes.contains($0) } ?? false
                }
                
                handleDragChange(start: start, end: end)
            default:
                return
            }
        })
        .onEnded { value in
            switch value {
            case .first(true):
                // Long press succeeded
                isSelecting = true
            case .second(true, _):
                // Drag ended
                updateSelectionRange()
                isSelecting = false
                isDraggingSelected = nil
            default:
                break
            }
        }
}

And finally, implement the method to handle update events to the gesture.

private func handleDragChange(start: CGPoint, end: CGPoint) {
    let minY = min(start.y, end.y)
    let maxY = max(start.y, end.y)
    
    // Clear the pending selection before recalculating
    pendingSelection.removeAll()
    
    // Find all lines that intersect with the drag range
    let selectedLines = lineData.filter { line in
        return !(line.maxY < minY || line.minY > maxY)
    }
    let currentLine = lineData.first { line in
        return end.y >= line.minY && end.y <= line.maxY
    }
    
    pendingSelection = Set(selectedLines.map { $0.index })
    
    if let currentLine {
        handleAutoScroll(currentY: currentLine.globalMaxY, index: currentLine.index)
    }
}

We use the ScrollViewProxy to trigger scrolling up or down. ScrollViewProxy only allows you to target specific elements, so I decided to scroll up or down 3 items from the current position (with bounds checking). We use a boolean state variable with a dispatch queue asyncAfter to isolate scrolling so that it doesn’t continually re-trigger.

There are some other small details not mentioned like coloring, gesture state, etc. But this is the gist of the implementation. It is very possible this implementation is not well optimized for a very large number of items, I was not designing for that use case in my app. The full code is a bit messy, but figured it would be worth publishing in case it’s useful to anyone to reference.

Appendix: a note on LLMs

As a side note, I also utilized LLMs throughout this process and saw both areas where they excel and struggle with this iteration process. Overall the models are familiar with SwiftUI, but sometimes require prompting to use the latest features. This is likely an aspect of a lot of open source code targeting older iOS versions. And of course with more difficult issues, it will frequently hallucinate out of the problem with non-existent APIs which you need to be careful of.

If you have a high level understanding of which tools to use, you can improve prompts by including specific APIs or design patterns you are trying to utilize. For example, “Use the @Observable macro instead of extending ObservableObject directly”. Directly linking to a specific Apple Documentation pages can also be beneficial. However, they do tend to struggle with more advanced logic regardless. Even newer thinking models like R1 were not able to debug some of the issues I encountered.

With a simple prompt describing my requirements and providing the existing view code, Claude was able to provide a solid high level approach. I started with very simple prompts like “How do I make it so that when you tap (and hold) and drag it allows you select multiple items at a time?”. Of course many, many details were wrong and it required tons of iteration. But with some follow up prompting, I was able to find my building blocks including some APIs I had not heard of before.

My general iteration steps were to:

1. Provide simple instructions to the model on my goal with my existing code
2. Review output, incorporate relevant functionality into my implementation
3. Re-prompt with new issues or bugs with the new implementation
4. Manually correct bugs and continue to iterate

A lot of its suggestions were valid at a surface level. But none of the models were very good at thinking through the overall functionality of a complex view, or debugging complex performance and logic issues. All the models (including thinking models) struggled to make any progress with esoteric SwiftUI bugs, or logical boundary math using coordinates.

Once I got to a high level of refinement, I had more luck manually scrutinizing the view and debugging. The models would give me seemingly increasingly random things to try, with high certainty in their incorrect theories. While you can prompt for assistance with high level debugging theories, it was not that useful for resolving detailed technical issues. To be fair, I found this task to be generally challenging as a human as well.

Also, using Xcode the LLM tooling is just much slower and tedious than other tools. My general workflow was just copy/pasting text between Xcode and the Anthropic console.

My goal was to selectively live update widgets when the underlying data model records are updated. The general flow of events I was envisioning was as follows:

1. The app subscribes to data model changes (local change data capture)
2. Filter changes to only those relevant to active widgets
3. Trigger reload of those widgets

Just interested in the sample code? Check it out here.

Widget Updates

Apple has provided documentation on how widget updates work under the hood; essentially your widget provides a timeline of events to render to the system. The system renders each timeline event statically, your view is not active when it is visible on the screen. APIs are provided to trigger reload of widgets when necessary. This prevents battery drain on the device, especially when there are many active widgets.

Because of this behavior, without intervention my widgets appear stale if the user edits the details of an object. They would have to wait for the system to request new timeline entries for it to refresh, not ideal. My goal was to keep the widget as up to date as possible without negatively impacting performance or getting throttled by system APIs. Thus my preference for tying into data model updates.

For context, my app exposes a single “kind” of widgets in various sizes. Users can configure the widget to display a specific song, or a random song. Most updates to the model are user initiated, but also could be remotely pushed by iCloud sync.

It’s worth noting that WidgetKit’s WidgetCenter API only allows you to trigger a reload of either 1. all widgets, or 2. all widgets of a specific kind. So you have limited granularity on which widgets to reload on demand. The more kinds of widgets you vend, the more flexibility you have. In my case, I could improve performance by separating the song widget into two kinds, “Specific Song” and “Random Song”. There’s also a UX tradeoff here, as more kinds of widgets crowds the list view when you add a widget to your home screen.

You also can’t query timeline events of widgets; my random song widget would always have to reload when any data record changes. This is because we can’t tell which record objects were placed into the widget timeline since they are randomly generated.

SwiftData Transaction History

Apple recently added transaction history API to SwiftData in iOS 18. This allows you to easily query chronological transactions that were made to your data store. This WWDC talk goes into some more details of how it works. I thought this API would be a great fit for my use case. I could consume each transaction to determine if a relevant widget should be updated based on its update.

The transaction history APIs allow to query transactions using a history token as a cursor mechanism. Notably, there is no async/await API to live subscribe to new changes occurring, other than to frequently poll the query API. To bridge the gap I realized I could wait on NotificationCenter notifications for NSPersistentStoreRemoteChange, which notifies for both remote and local changes to the Core Data database.

So to recap the approach before getting into the code:

1. Wait for NSPersistentStoreRemoteChange notifications
2. Poll SwiftData transaction history since the last history token
3. Filter events to those relevant to widgets
4. Reload relevant widget kinds
5. Delete old transactions, store new history token

Implementation

First, let’s start by adding a ModelActor for performing these operations:

@ModelActor final actor DataMonitor {
    func subscribeToModelChanges() async {
        for await _ in NotificationCenter.default.notifications(
            named: .NSPersistentStoreRemoteChange
        ).map({ _ in () }) {
            await processNewTransactions()
        }
    }

...

Now, add our logic for storing and retrieving the history tokens. For simplicity, we’re storing them as JSON serialized strings in NSUserDefaults as recommended by Apple’s documentation. Note that if we don’t have a history token, we’ll try consuming from the start of the transactions table.

func processNewTransactions() async {
    let tokenData = UserDefaults.standard.data(forKey: "historyToken")
        
    var historyToken: DefaultHistoryToken? = nil
    if let tokenData {
        historyToken = try? JSONDecoder().decode(DefaultHistoryToken.self, from: tokenData)
    }
    
    let transactions = findTransactions(after: historyToken)
    let (updatedModelIds, newHistoryToken) = findUpdatedModelIds(in: transactions)
    if let newHistoryToken {
        let newTokenData = try? JSONEncoder().encode(newHistoryToken)
        UserDefaults.standard.set(newTokenData, forKey: "historyToken")
    }
    if let historyToken {
        try? deleteTransactions(before: historyToken)
    }
    
    await maybeUpdateWidgets(relevantTo: updatedModelIds)
}

Now we fetch transactions from the store, this logic is very simple. Similarly, the logic for cleaning up old transactions is just deleting them from the ModelContext.

private func findTransactions(after token: DefaultHistoryToken?) -> [DefaultHistoryTransaction] {
    var historyDescriptor = HistoryDescriptor<DefaultHistoryTransaction>()
    if let token {
        historyDescriptor.predicate = #Predicate { transaction in
            (transaction.token > token)
        }
    }

    var transactions: [DefaultHistoryTransaction] = []
    do {
        transactions = try modelContext.fetchHistory(historyDescriptor)
    } catch {
        logger.error("Error while fetching history transactions \(error, privacy: .public)")
    }

    return transactions
}

private func deleteTransactions(before token: DefaultHistoryToken) throws {
    var descriptor = HistoryDescriptor<DefaultHistoryTransaction>()
    descriptor.predicate = #Predicate {
        $0.token < token
    }

    let context = ModelContext(modelContainer)
    try context.deleteHistory(descriptor)
}

With the transactions in hand, I now need to convert the DefaultHistoryTransaction objects to my actual model class (title SongArtworkViewModel). You can retrieve many details about the transactions, but in my case I just needed the object id field to determine if they’re relevant to my widget.

private func findUpdatedModelIds(in transactions: [DefaultHistoryTransaction]) -> (Set<UUID>, DefaultHistoryToken?) {
    let taskContext = ModelContext(modelContainer)
    var updatedModelIds: Set<UUID> = []
    for transaction in transactions {
        for change in transaction.changes {
            let transactionModifiedID = change.changedPersistentIdentifier
            let fetchDescriptor = FetchDescriptor<SongArtworkViewModel>(predicate: #Predicate { model in
                model.persistentModelID == transactionModifiedID
            })
            let fetchResults = try? taskContext.fetch(fetchDescriptor)
            guard let matchedModel = fetchResults?.first else {
                continue
            }
            switch change {
            case .insert(_ as DefaultHistoryInsert<SongArtworkViewModel>):
                break
            case .update(_ as DefaultHistoryUpdate<SongArtworkViewModel>):
                updatedModelIds.update(with: matchedModel.id)
            case .delete(_ as DefaultHistoryDelete<SongArtworkViewModel>):
                updatedModelIds.update(with: matchedModel.id)
            default: break
            }
        }
    }
    return (updatedModelIds, transactions.last?.token)
}

Finally, the logic of conditionally updating my widgets. The configuration intents can be cast to your specific configuration intent to retrieve their parameters. For my specific case, I want to reload if a random widget is active, or the specific song used was updated.

private func maybeUpdateWidgets(relevantTo modelIds: Set<UUID>) async {
    let configurations = try? await WidgetCenter.shared.currentConfigurations()
    guard let configurations else { return }
    let relevantConfigurationKinds = configurations.filter { configuration in
        let config = configuration.widgetConfigurationIntent(of: SongConfigurationAppIntent.self)
        guard let config else {
            return false
        }
        
        if config.mode == .random {
            return true
        }
        
        guard let entityId = config.specificSong?.id else {
            return false
        }
        
        return modelIds.contains(entityId)
    }.map { $0.kind }
    
    Array(Set(relevantConfigurationKinds)).forEach { kind in
        WidgetCenter.shared.reloadTimelines(ofKind: kind)
    }
}

With all the logic completed, I could then add a modifier to my app so that this occurs on startup.

.task {
    Task {
        let monitor = DataMonitor(modelContainer: ModelContainer.sharedModelContainer)
        await monitor.subscribeToModelChanges()
    }
}

Build and run and everything would work for sure. …Right?

SwiftData/DataUtilities.swift:1305: Fatal error: Unexpected class type: CodableColor

Womp womp. Unfortunately this has been similar to much of my experience with SwiftData. Hard to decipher fatal errors that you cannot safely catch. In this case my model class was quite complex including several @Attribute annotations with.transformable(by: ). I’m not sure specifically what was causing this issue, it was hard to reproduce it outside of my app. I ended up refactoring my data model significantly to simplify its structure, and this resolved this crash issue. I may write another follow up article on my data model refactor.

After simplifying the structure of my model, the History Transaction APIs worked as expected! The widget reloads itself when relevant changes are made as expected.

While working on this, I realized I also could just use the simple solution of always reloading all widgets whenever I receive the NSPersistentStoreRemoteChange notification. In actuality this is much simpler and in my experience does not result in system throttling because most updates are made when the app is in the foreground. But it may be different for your use case if you receive many updates to the model while the app is not in the foreground. And this transactions harness would also be useful for other use cases in the future like exposing app data to Core Spotlight.

If you’re interested in trying this architecture for yourself, you check out my sample code.

Takeaways:

1. For WidgetKit refresh granularity, it is better to vend multiple kinds of widgets
2. The SwiftData Transaction History APIs can be used in conjunction with the NSPersistentStoreRemoteChange notification to trigger off of new updates to your data model
3. SwiftData’s Transaction History APIs may have issues with very complex data models
4. This approach would also be useful for other problem spaces like exposing your SwiftData to Spotlight

Thanks for reading!

What I didn’t realize until recently is that you can also use these previews on a physical device. Including via wireless debugging, so your iPhone/iPad doesn’t need to be connected to your Mac. I specifically wanted to do this because of some keyboard weirdness in the simulator, but this is generally useful.

Unfortunately I ran into some provisioning errors when I tried to set this up.

"This app cannot be installed because its integrity could not be verified"

NSLocalizedRecoverySuggestion=Failed to install embedded profile

This StackOverflow post has some debugging tips. But my issue ended being solved by first running the full App itself on the device. Then previewing views worked as expected. There must be some provisioning profile bootstrapping that happens there, which I couldn’t find documented anywhere.

I think stretching outside your comfort limits and doing something new and uncomfortable can bring some personal growth. Being more introverted, it wasn’t my definition of comfortable to go solo on a weekend trip to another state to talk to strangers. Despite this, it was a positive experience that truly made me feel better about politics. I feel very strongly about politics, and it felt good to actually get out there and do something even if it was insignificantly small.

These were organized bus trips with 4-5 hour drives to each area. It definitely felt good to meet new people who are similarly politically engaged. The energy is great and it definitely takes a certain type of person to spend your weekend doing this. Especially living in the Bay Area and with most of my friend circles being people in tech, it was pretty refreshing to see the diversity in background of those volunteering.

Logistically, I surprised by the quality of the tech in some aspects of canvassing (the canvassing apps). But also surprised by the lack of tech in some aspects like assigning turf, rides, hotel rooms, and keeping track of folks to make sure they make it back in time. A lot of the on the ground organization seemed to be done with a menagerie of Google Sheets and post-it notes. Not an attack on the organizers at all, there’s a lot of hard-working volunteers making it all happen. But I just thought the process was interesting from a technology perspective. The canvassing apps provide all the tooling when you’re on the ground, but everything outside of that is mostly manual processes.

The canvassing apps MiniVan and PDI Connect (only used in CA apparently) were pretty decent. They each give you very specific houses and voters to try and contact for your shift. MiniVan uses Apple Maps and I found had much better consistency of finding specifically where houses were. PDI Connect uses OpenStreetMap and the locations were much less accurate. They both drain your battery quite quickly by using GPS constantly, so I definitely recommend a battery pack for canvassing.

As for the actual door knocking, it was pretty fun overall. You spend most of your time navigating the neighborhood to find the right doors to knock. You get a very specific on-the-ground feeling of the neighborhood you’re in that you just wouldn’t experience otherwise. Honestly, most people either aren’t home or don’t answer their door. The vast majority of people I talked to were quite nice. I talked to some very sweet people. Some people are uninterested and want to get back to their day (understandable!), but I hoped I was another data point to sway them to turn out. I really only had one negative experience the whole weekend.

The first few doors are kind of nerve wracking, but you start to get used to it after a couple. I equate it to jumping into the cold pool head first. You have to lower your inhibitions and realize the stakes are really low (no fear). Canvassing is a skill, I’m sure I would get better at it with more practice as well. I think you get better at engaging and having better conversations, it is a challenge to break through especially when the audience is uninterested. At this point in the campaign it is mostly a GOTV operation and I didn’t really have an opportunity talk substantive policy. But talking with actual voters helps you realize the common decency that is missed online.

There is a lot to be pessimistic about with regards to the election results. It can be tempting to believe that the ground game did not matter. But the reality of it is Harris performed much better in swing states than non swing states. The campaign operation and ground game did make a difference. And it mostly likely did actually matter, with Democrats holding on to senate seats in NV, AZ, MI, and WI.

It’s currently 712 days until the 2026 midterms. I hope to do whatever I can to most effectively volunteer in that election. And if it’s more canvassing, I’m well prepared!

If you’re just interested in the park reviews, you can check it out here. This post details the background of the project and some of the benign details of how I created the write up.

The preparation

This project started off with some research a spreadsheet to track and categorize each park. The city parks website does a good job of listing them out. And was actually recently updated with new images. But the spreadsheet made it a lot easier to document coordinates/addresses, notes, and to keep track of which parks we visited during the outing. I used numbers for this, and the iCloud collaboration tools worked well and allowed us to update it on the go with the iPhone app.

After all the spreadsheet was listed out, I spent some time researching the exact location of some of the smaller and lesser known parks. There were a few that were not well labeled on Apple or Google maps. I made POI suggestions where possible after doing some research on the correct locations.

We also did some experimentation with path-finding to find the most efficient path to visit all the parks. We did have a limited time window for my visit to the Seattle area so we wanted to be efficient with the limited daylight time. Both ChatGPT and Claude did not produce great results for this, though we could likely have gotten better results by asking it to write a path finding algorithm to solve for it. Ultimately, we decided to do manual routing by looking at a map with all the parks pinned on it. It was definitely not the most efficient path, but the time loss was not substantial as the city of Everett is not very large.

The adventure

On launch day we went straight from the airport to park visits. With 46 spots to visit the goal was daunting and we weren’t sure if we could complete the challenge in only 2-3 days. We definitely spent less time at some of the parks to meet our schedule. But we did take our time at other substantial parks. It wouldn’t be an enjoyable venture if we were just driving straight from place to place after all. We lucked out on the weather conditions, with it being peak Summer and no rain at all.

We also discussed how best to document this challenge. A video would be an option, but that seemed intrusive to need to film extensively during the day to capture the footage. I’m just not about that vlog life right now. So we decided to take some photos at each spot and do a write up of some sort afterwards.

It definitely was tiring going to so many parks in a short period of time. We had a break day to go see Bleachers at a music festival in Seattle in between which was a nice reprieve. We were exhausted at the end of each day but it was very rewarding at the same time. It was super satisfying when we finally met our goal on the 3rd day of visiting every park in the system. And while not all the parks were amazing stand-outs, it was still cool getting to see and experience new locations. I definitely want to re-visit some of these parks again in the future to more thoroughly enjoy them.

With the photos and notes taken, it was time to move on to documenting our memories!

The write up

For the first step of documentation, I made a significant number of corrections to Apple Maps location data so others can find the parks more easily. Some were missing, had incorrect names, or were in the wrong location. I also submitted the pictures that I took at each park. So if you look up any of these parks on Apple Maps you’ll likely see the same images as on this blog!

The next step was to start working on the blog page. This site hasn’t had a new blog post in over 4 years. While I modernized its deployment architecture a year or so ago with AWS Amplify, it hadn’t received significant attention. The Jekyll version and other dependencies were significantly out of date. While it sounded simple, this ended up causing a bunch of churn with plugin upgrades, theme updates, Dart Sass upgrades, etc. This was all menial tasks, but necessary to get the blog into better shape.

After this was taken care of, I moved on to implementing the functionality needed for the parks review page. I had a few requirements I wanted from this page:

• List all the parks in a paginated view
• Have a gallery image view for each
• Show where each park is on a map
• (Ideally) show where all the parks are on a map view

Pagination

This was the most straightforward. Just needed to migrate to jekyll-paginate-v2 to make use of the custom collections feature. This did cause some churn of various upgrade path rough edges to keep parity with existing pagination on my blog pages.

Images

The first step for the images was sorting through and tagging all the photos in my library from the parks. They were geo-tagged which made this easier, but still a manual process of going through and tagging each park. From there I exported them all to JPEGs in folders to start the process of hosting them on this site.

I didn’t find any fully featured gallery solution for Jekyll that would meet my needs well. So I decided to roll my own with Photoswipe. I used a fairly simple _include that wraps a specific set of images in a gallery.

But there were a few complications with this approach:

1. Image dimensions

Photoswipe requires you to tell the dimensions of each image. And I can’t hard-code it because some images were portrait and some were landscape. At first I just added a plugin which used ImageMagick to pull the image dimensions of each when the site was being generated. This quickly became very slow as it recalculated it for every single image each time the site was changed. So I pivoted and had Claude write a ruby script which precalculated it all and created a YML file listing all the image metadata. I also updated this script to create all the base scaffold pages for all 46 parks so I didn’t need to do that manually.

1. Image sizing

When you load the page, it loads thumbnails for all the images. But if we don’t properly resize those, it would just load the full images for each which would be slow (and costly). So to solve for this, I looked into solutions using the img srcset property which will dynamically load whichever asset dimension is needed. Luckily, there is already a great Jekyll plugin, jekyll_picture_tag which takes care of this. I installed it, wrapped my images tags with it, and everything worked perfectly!

…Except when I went to deploy and test my changes in AWS Amplify. Because the library uses a dependency called libvips which isn’t in the default Amplify build image, the whole thing crashes and burns. I could install libvips in the build steps, but this turns out to be very slow. Taking multiple minutes on each build iteration. So I decided to set out and create a custom dockerfile that has all the dependencies I need. In the end I open-sourced it, so it may be useful to others using a similar setup in Amplify. The Github readme has some instructions on how to use it.

The dockerfile took me much longer than I would have liked to get in a working state. But the end outcome is ideal because Amplify can still build my site and the build is quite fast. I also used a small code snippet to cache the generated resized images between builds so that it doesn’t need to re-render images that have already been sized properly.

Maps

For each park I wanted to include a screenshot of where it is on a map. The Apple Maps Web Snapshots seemed to fit the bill perfectly. I could have gone with the easiest option of scripting creation of the images I needed to include in my site. But instead I decided to create my own Jekyll plugin for it. Originally it was just a custom _includes but then I decided to refactor it to be a Liquid block. And at that point I had something that was in pretty good shape so I decided to open source it.

I did put in some more effort to clean up the code and write unit test coverage. For extra credit (and to just see where open source tooling is these days), I integrated test coverage and CI with CircleCI and Codecov. Overall this was pretty smooth except some small hiccups that I might write about some other time. This was also the first time for me to publish my own open source gem, which was easy to figure out.

I experimented with using Cursor and and Claude 3.5 Sonnet quite a bit while working on this plugin. It got me probably 60-70% of the way to most of the functionality I wanted, and the rest was just cleaning it up and productionizing it. It definitely has its limits, but was very useful for some of the boilerplate code that’s usually very tedious to work through for a personal project like this.

Once I had the plugin open sourced, I just pulled it into my site’s gemfile as a public repo and everything worked as expected! Then I started to work the interactive Apple Maps embed that lists all the parks in one place. This one was honestly more of a hack-job, but it does work. I considered putting more effort into it to include it in the Jekyll plugin, but it’s a pretty frontend project so I punted it for now. Currently it’s just some templated JS directly in that page and it does work for now.

Writing the content

With all the technical details complete, I had to finish up by writing the actual content. We had written ratings already for each park in the spreadsheet so I just had to reference that for each write up. I could have written more content about each park, but decided to leave it fairly minimal for now. I might add more depth in the future, but I’m eager to ship, having worked on this on and off for several months on nights/weekends.

Conclusion

In this end, this took an somewhat absurd amount of effort to create a page that is quite simple in functionality. But I also created some open source software that is may be of use to others. And my site’s setup is now modernized, making future updates easier. I also learned a lot in the process, and experimented with LLM coding tools like Cursor to make my work more efficient.

I hope others enjoy viewing the park write ups. And even if not, it’s still satisfying to have finished this project and have my adventure documented. There’s something to be said for finishing the project and actually shipping even if it’s mundane, and I’m glad to have done that. There’s plenty of things that I want to improve about the page, but for now it’s functional and out there! And it’s fully hosted by me with full creative control, not beholden to any social network or hosting provider :).

I really enjoyed visiting all these parks and experiencing something new. I can’t wait re-visit some of them later. And who knows, maybe I’ll tackle a similar challenge in San Francisco sometime.

Jared contains the ability to load .bundle plugin files to add additional commands. These bundle contain a principle class which conforms to a protocol and is loaded dynamically at runtime. In this instance, I was experimenting with a bundle whose class started a HTTP web server using Telegraph.

I originally noticed strange behavior because when reloading plugins. The application would crash upon reload, due to the server trying to re-bind the same port, even though I was stopping the server in the module’s deinit statement. Setting a breakpoint, the deinit was never called.

After unloading the server module, I ran an experiment by mashing the reload plugins button repeatedly.

Digging into Xcode’s Debug Memory graph, and filtering on filtering on leaked blocks, it’s clear that old copies of RoutingModules are sticking around in memory.

Looking closer into the pertinent part of the memory graph:

The route has a clear strong reference cycle between itself and an array, causing it to stick around. All modules do provide an array of routes. Narrowing down the pertinent code:

var routes: [Route] = []

init() {
    let reload = Route(name:"/reload", comparisons: [.startsWith: ["/reload"]],
      call: self.reload, description: localized("reloadDescription"))
    
    routes = [reload]
}

func reload(_ message: Message) -> Void {}

After some research, it was evident that the issue lied in the reference to a self method in the callback parameter. The purpose of the callback is to provide the routing module with the appropriate method to call when a triggering message is received. It is not meant to live beyond the memory scope of the containing class. However, because it was a strong self reference, it was causing any module to never be deallocated. The class contained a list of elements that depend on itself, so as far as ARC is concerned, the resource never reached a zero reference count.

This behavior is explicitly called out in the Swift documentation:

A strong reference cycle can also occur if you assign a closure to a property of a class instance, and the body of that closure captures the instance. This capture might occur because the closure’s body accesses a property of the instance, such as self.someProperty, or because the closure calls a method on the instance, such as self.someMethod(). In either case, these accesses cause the closure to “capture” self, creating a strong reference cycle.

As a simple solution, I simply provided the callback as a weak self reference instead:

let reload = Route(name:"/reload", comparisons: [.startsWith: ["/reload"]],
  call: {[weak self] in self?.reload($0)},
  description: localized("reloadDescription"))

The weak reference allows you to reference self, without keeping a strong hold on it. This prevents a strong reference cycle, and allows my Module classes to be deallocated appropriately. After changing to a weak self reference in all Routes, the issue resolved itself, and I’m free to mash that reload button without incurring a memory leak. Thus solving a long lived bug in my application.

tl;dr: You should be very careful when using self in callbacks. It is very likely that you should use a reference to weak self instead of a strong reference.

Music

• Melodrama - Lorde

• 1989 - Taylor Swift

• E•MO•TION - Carly Rae Jepsen

• Norman Fucking Rockwell - Lana Del Rey

• Pure Heroine - Lorde

• Gone Now - Bleachers

• Ghost Stories - Coldplay

• Ultraviolence - Lana Del Rey

• Every Open Eye - Chvrches

• Days Are Gone - HAIM

• How Big, How Blue, How beautiful - Florence and the Machine

• Nothing’s Real - Shura

• BADLANDS - Halsey

Videogames

• Persona 4 Golden

• The Last of Us

• Persona 5

• Shin Megami Tensei IV

• Tetris 99 / Tetris Effect

Movie

• Lady Bird

TV Show

• Lost

The last episode aired in 2010 so it counts

Best thing I’ve done all year. #HomeKit #homebridge pic.twitter.com/4uWfUkBkt0

— Zeke (@ZekeSnider) April 18, 2019

The Equipment

• Raspberry Pi 3
  • Alternatively, you can use a Raspberry Pi Zero with a headboard soldered on (or solder directly)
• 360° servo
  • Make sure you get a 360° servo.
• Jumper wires
• Screwdriver extension
  • This one is overkill for this use case, but I figure they’d be useful to have anyway.
• Command strip
• Wand grip
  • Note: I haven’t tested this one specifically because my blind already had a grip. I ordered a few of these and am planning on testing them with my other blinds.

(Note: the amazon links are affiliate links.)

The hardware

The original blinds

The specifics will obviously differ based on what type of blinds you have. My blinds are twist blinds, which conveniently have a removable grip on the bottom of the rod, with has a hole on the bottom. I noticed this, and thought it would be perfect for screwing to a servo.

screwing into the servo

You’ll need a screwdriver extension to properly screw into the servo through the grip. My extension was overkill on length, but got the job done.

now how to attach to the wall

I attached the grip back onto the blind rod, and we’re almost good to go. Except I needed to attach it to the wall, and still have the flexibility to remove it in case I need to manually slide the blinds. I’m also renting this apartment so I didn’t want a permanent solution like screwing into the wall.

modern problems require modern solutions

Command strips were a good solution for me. I’m sure this is super amateur hour, but it worked for my use case.

servo attached to wall

I then plugged in my raspberry pi to the wall (running raspbian), and wired up the servo to the pi using the wiring guide here.

The software

Because my ultimate goal was to connect to homekit, I installed homebridge, and set it up to run in the background. Then I stumbled upon the homebridge-minimal-http-blinds plugin, which allowed me to bind a blinds accessory to an http server. So then I set out to write a server that exposed the correct endpoints.

I ended up writing it in Node, and using pigpio to control the servo. You can see (and use) the source here. The nice thing about this solution is it allowed me to implement percentage based setting of the blinds.

The server’s implementation also includes rubber-banding on request. So for example, if the blinds are at 0%, you request 100% then request 20% after they reach 50%, they will immediately turn back. Newest request takes priority, and it checks which direction it should be turning on every iteration of the control loop.

After much tinkering via HTTP requests to determine the correct config parameters, I arrived at a final set of values. Then I setup my application to run persistently using systemd, and updated my homebridge config file to point at the new accessory. Afterwards it was all good to go.

I’m very happy with my final product and am currently working on implementing on the other blinds in my apartment!

Add user to run homebridge under
sudo useradd --system homebridge

Create directory for it
sudo mkdir /var/lib/homebridge

Own the directory permissions
sudo chown -R homebridge:homebridge /var/lib/homebridge sudo chmod 777 -R /var/lib/homebridge

Copy your home directory’s config (if you don’t have one already, edit it instead)
sudo cp ~/.homebridge/config.json /var/lib/homebridge/config.json

Copy your home directory’s persist directory (if it exists) sudo cp -R ~/.homebridge/persist /var/lib/homebridge/persist

Determine where homebridge is aliased
which homebridge

Edit the systemd service
sudo nano /etc/systemd/system/homebridge.service

Paste in the contents of homebridge.service from here. Make sure to replace /usr/local/bin/homebridge with where homebridge is actually installed.

Exit nano
control + x, Y

sudo nano /etc/default/homebridge
Paste in the contents of homebridge from here.

Reload systemd configs
sudo systemctl daemon-reload

Enable and start the service
sudo systemctl enable homebridge
sudo systemctl start homebridge

Check on its status
sudo systemctl status homebridge

If something is wrong, check the logs.
journalctl -u homebridge

At this point if there are any issues, live vicariously via google and stackoverflow.

🏝

Background

For the uninitiated, iMessage is Apple’s messaging platform that is only available on Apple devices. If you text another iPhone user from an iPhone, the bubble will be blue (sent via iMessage).

Apple has tried to lock down iMessage as much as possible, and there is no public API for common chat bot hooks. As far as I know, I was the first to attempt to write any sort of chat bot for iMessage. Because of how obtuse it is, I assume most would rather write for a platform that actually encourages development of bots, but I was in it for the challenge! iMessage is my favorite messaging service, and I wanted to build on it.

There are only a few hooks available to iMessage:

• ❌ iMessage Apps (introduced in iOS 10). These provide very limited hooks that would not provide a chat bot like is implemented in Jared. All input would need to be in the context of the message extension, as these apps cannot read messages, names, or any personal information. They also can only send messages with the user’s explicit consent.

• ❌ Siri Shortcuts (introduced in iOS 12). Shortcuts have interesting potential, but they are also limited. They can only be triggered manually, and user consent is needed to send messages with images. They cannot read conversation history.

• ✅ AppleScript support via Messages.app for the Mac.

The Messages.app on the Mac has existed before the introduction of iMessage. It originally only supported AIM, Google Talk, and Jabber accounts. It was just Apple’s instant messenger client. Of course it has evolved and now only supports iMessage, but the base code base has remained the same. For that reason (I’m assuming), it still (had) full AppleScript support.

AppleScript is basically a local RPC framework for automating actions on the Mac. Its syntax is very… strange (English like)? It’s not so much an elegant programming language, but it is good for its use as an automation language. There is also a technology called JXA which allows you to use AppleScript actions from JavaScript instead, but it is not very well documented and I haven’t spent much time with it. But I think all the AppleScript in this project could be replaced with JXA.

For my purposes, two pieces of functionality were key in the Message App’s AppleScript dictionary:

Message Handler

This is triggered when a message is received. It provides the content of the message as well information on the sender. From then we can do routing on it, and if needed…

Send Action

Send a message to a specified recipient. This even supports attachments, and sending to group chats making it extremely useful to me. These two pieces were all I need to implement my chat bot.

The first implementation

v1

The first take (which I have not open sourced because of how sloppy it is), was functional but not elegant. Everything was implemented in one AppleScript handler file. It did not call into any other languages or frameworks.

Installation

Because everything is in one file, it became quite bloated quickly. In addition, AppleScript syntax is very verbose and not well catered towards writing scalable software. It was really intended for small macro automations.

• Single threaded - Whenever the handler is processing a message, it is unable to handle new incoming messages. This caused messages to not get handled if they were routed at the same time, and errors to assert causing the whole system to stop functioning until it was manually restarted.
• Errors - If any error was thrown and not caught, it could cause an error dialog to pop, which shut the whole thing down as mentioned. These errors could be timeouts (spending more than 60 seconds processing), or just inconsistent system errors. As such, I devised a method that would automatically dismiss any error alerts, but this was not 100% effective either.
• Limited Scope - AppleScript as a language is limiting as it lacks many standard language functionality and frameworks. I was able to cut some corners by using some AppleScript helper apps that exposed things like REST calls, but this was obtuse and didn’t work for all the features that I wanted to implement.

And thus brought v2, a full rewrite…

The better implementation

v2

This (current) version uses a native app written in Swift that exposes an AppleScript interface. The Applescript handler in messages is very simple and just passes data to the Swift app. This solves several issues of the initial implementation.

• Multi-threading - All incoming requests on the Swift side are put in a background thread via a GCD Dispatch queue. This allows processing to take as long as needed for each message, and allows for other things such as sending delays.
• Frameworks - Swift is a well supported, native language. You’ll be able to find libraries (built in or not) for most things, and it allows for interop with C and Obj C, among other languages.
• Plugins - The original version had all routing in one AppleScript file, which became difficult to maintain after adding many commands. The Swift version added a plugin framework with a rules engine for routing. Additional commands could be added just by building them into a plugin module and placing them in a plugin directory. The plugins are loaded in via NSBundle modularization.
• UI - Because it is running as an app, Jared can now provide a cocoa UI for enabling/disabling the service, as well as configuration options.

The new UI

These improvements allowed for much more flexibility. Many bottlenecks were removed, and it also allowed for adding things like database persistence for various state parameters, background processing jobs for scheduling, etc.

A simple send script is called for sending outgoing messages. It is called by making an osascript shell call from Swift.

This solution was great, until Apple made a change in macOS High Sierra 10.13.4.

Wait where’d it go.. 🤔🤔🤔

They removed the option to specify an AppleScript handler in Messages.app. I would like to think I caused this, but more realistically an engineer at Apple probably discovered this menu option one day and asked why the functionality exists at all.

The message send action still exists, but now there is no way to receive the hooks for incoming messages, which brings us back a few steps.

Working around Apple

Third time’s the charm

In ~/Library/Messages there is a messages.db SQLite database that contains the contents of all message history. It gets updated when new messages are received/sent. Suprisingly, it is a standard SQLite database, and it is not encrypted. So, as a workaround to the AppleScript handler, we can instead query the database on a set interval (5s)? For all new records since the last query. This will allow us to batch process all new messages received.

In addition, there are lots of fields in the database that are available in the database, that were not available via AppleScript, such as read receipts, and more. Although it will be difficult/impossible to query on changes to fields that do not trigger update of a date field.

This solution works around the removal of the AppleScript handler preference, while still keeping most of the codebase the same.

This is not fully implemented yet, as I’ve been working on it on a branch which hasn’t been merged yet. Progress can be tracked on this issue. Credit to Github user mezeipetister for the idea of repeatedly querying the database. Unfortunately I’ve neglected this project too much, but I hope to complete this fix in the near future, so that we can get Jared working on Mojave 😀. I will likely write another update post once that is done.

PS: Private Frameworks

You may ask, isn’t there some private API call you can use to bypass AppleScript for sending messages. Well, there is in theory, but I haven’t been able to get any of them to work properly (read: at all). I’ve used class-dump to retrieve header files, and tried to use methods of the Messages private framework, but haven’t had any luck.

This is something I should probably spend some more time on, but it’s pretty tedious and unsatisfying. A hundred different things could be preventing the method calls from working, but because it’s a private API, it’s very difficult to diagnose it. If anyone has anyone to share on this, please let me know!

So there you have it, the complete story of Jared thus far. If you want to try it out, check it out on GitHub and give it a star. Hit me up by Twitter or email if you have any questions!