Aweigh

• 

  App Gallery

• 

  iOS App Icon

• 

  App Screenshot

Inspiration

I realized that the Washington State Department of Transportation (WSDOT) API was completely open to public use. I originally worked on a TRMNL implementation of the schedule, and realized during the extensive research that it could be made into an iOS app. I was not a fan of the UX of the official iOS app, so I decided there was a place for it in the market.

What it does

Aweigh is an app for the Washington State Ferries system that displays real-time ferry locations, traffic cameras, schedule data (delays, annotations), service alerts, etc. WSF is the largest ferry system in the United States. Many people rely on it for daily commutes, including driving their cars on. It works on iPhone and Apple Watch, with iPhone Duo and iPad on the way.

How we built it

I started by researching the WSF API for a TRMNL e-ink display, using a Raspberry Pi to save responses every few minutes for about a month. Those recordings helped me understand how the data changes during real service disruptions. After finishing the TRMNL widget I realized I could use what I learned to make a first-class iOS app for the system. Optional tips are handled with RevenueCat.

Challenges we ran into

The hardest part was handling all the combinations of delays, annotations, service alerts, and cancellations while keeping useful information readable at a glance. The source data can also conflict, and canceled sailings sometimes disappear from the official schedule entirely. Those cases require extra handling to display intelligently to the user.

Accomplishments that we're proud of

I turned my API research and data-collection tools into a Cloudflare backend that serves Aweigh. In my observations, the official API commonly takes 1–2 seconds to respond and sometimes takes as long as 15 seconds, so reducing how much users have to wait became a significant part of the project.

I'm also pretty proud of the UI. I spent a lot of time getting the design of the flipboards and their haptics just right. The Apple Watch version also took hours of revision to get perfect on every possible screen size, and I think I struck a good balance between information density and readability.

What we learned

Making an app that integrates well with a transit system is deceptively difficult, and making sure it always looks as good as possible in all possible states takes a very long time. I had a basic prototype of the app working within 48 hours, but dealing with all the possible annotations and researching how the API responds in cases like delays, tidal cancellations, etc. was intense.

What's next for Aweigh

Platform-wise: I'm currently working on an iPad and iPhone Duo version. I eventually want to get it working on Mac and Vision Pro as well.

Feature-wise: I want to use the custom server I made with Cloudflare to predict delays and distribute that information to users. Drive-up wait times aren't consistently available in the official data, so Aweigh includes a beta that estimates them with an on-device model reading the Edmonds terminal cameras. I'd like to expand it to more terminals, which could help commuters and visitors decide when to arrive. Both depend on the data I've been collecting for nearly five months.

Built With

• cloudflare-workers
• core-ml
• python
• revenuecat
• swift
• swiftui
• typescript
• uikit
• watchos