Second development update on FOIA Phone, an app for records requests from your pocket.

FOIA-phone-part-2.md

FOIA Phone (Part 2)

By Daniel Lathrop
2025-09-30

So it's been 10 days or so since I started work on FOIA Phone. I'm still not at the working prototype stage, so the MVP is not imminent. Even so, I'm pretty pleased with the progress I've made, which can be seen over at Github.

New tools in the toolbox

A lot of that has been banging dusting off my knowledge of Swift, which I hadn't used in a while, and learning so new frameworks and libraries.

One of those is Apple's SwiftData framework. I won't say it makes dealing with models in an iOS app Rails-level or Django-level easy -- definitely some warts -- but I give it a solid B+. Since it's a first-party framework and you get CloudKit integration for basically free, that was good enough to win me over.

Basically it just lets you stuff any (decodable from JSON) class or struct instance into your database (SQLite/CoreData underneath). So to your code it just looks like objects all the way down.

Another fun discovery was ViewInspector by Alexey Naumov which makes unit testing of SwiftUI views way more ergnomic. As in, you can test the views without launching the app and getting it into the state the app expects. Great, right?

Anyhow, I highly recommend it.

What's done?

Quite a bit.

Models Written

Honestly, I probably have too much going with the models, but I created themm to make sure my app is structured for future integration with MuckRock and FOIAMachine. I see value in it, so I'm making sure my models can map fairly easily to theirs ... even if it's not the very fastest way to get to production. I suspect some of it will eventually be "dead code" that gets refactored.

This is basically "done except for whatever I have to add in when I realize I missed it." Not expecting a ton.

App Structure Figured out

The main "action" in FOIA Phone will be a list of FOIA Requests (FPRecordsRequestsView) showing their current status with some sorting and filtering goodness. The bare bones version of this -- just a list bound to the data -- is now working. Plus it has a "New" button (not working yet).

That navigates to a detail view (FPRequestDetailView) from which to edit or create requests. This is implemented using the SwiftUI NavigationSplitView, which should actually make the app fairly iPad friendly down the road. The detail view is just a stub right now -- albeit one that successfully binds the request data back and forth.

Once those two are done we'll be at the "working prototype" stage, with three other views to write before the MVP is ready:

• FPLetterWriter will take the information from the FPRecordsRequest and allow the generation and editing of a records request. This view will allow you to send the request. The MVP will just create a nicely formatted email. Future versions will get fancier. This will require the most business logic by a LOT.

• FPAgencyDetailsView will allow you to enter information about the agency you're requesting documents from and re-use that information in future requests. An agency directory -- particularly one backed by exernal data -- is not part of the MVP, but it is definitely on my mind.

• FPUtilitiesView is where everything else will go. Right now that's: custom request templates, user settings, a csv export and the list of Agencies. Honestly, pretty basic and agency.

The other big things to tackle for the MVP are:

1. the actual letter generating and sending business logic. I'm tempted to use the LLM from Apple's Foundation Models rather than an actual templating language.
2. creating letter templates/exemplars/prompts for 50 states, DC, FOIA and whatever else. The level of hardness or easiness here is related very much to how I approach #1.