twocentstudios

Introducing Eki Bright 2.0

Sun, 18 Jan 2026 16:16:39 -0600

Eki Bright 2.0 is available today.

Eki Bright app icon

Eki Bright is the fastest way to access station timetables for the Tokyo metropolitan area.

The original design for the Eki Bright app evolved out of the initial use case of configuring Widgets, but steadily grew to support searching, nearby stations, DIY routing, and Live Activities.

For Eki Bright 2.0, the goal was to optimize the app for how I’d actually been using it and how its users had told me they use it.

Home screen evolution from v1.0 to v2.0

The main focus is now nearby stations, which I found to be 95% of my usage over the year since its first release. In many cases, you’ll see the exact station timetable you want in less than a second after opening the app. Other nearby stations are a quick scroll at your resting thumb position, and order based on view history and distance from your current location.

Nearby stations screen with scrolling

From here, it’s super easy to start a new DIY route by tapping your departure train time, then tapping the route icon of your arrival station.

Creating a DIY route by tapping departure time and arrival station

The route bar from v1.x has moved to the native tab bar accessory, which automatically expands and collapses.

Route bar in the tab bar accessory

DIY routes now have a full screen view in Eki Bright 2.0. You can see the full route and transfers, and view all stops along your route.

Full screen route view with expanded stops list on the right

It’s easy to compare adjacent departure times. For example, to check whether the next departing local train will actually reach your destination after a later departing express train.

Comparing local and express departure times, the express arrives 7 minutes earlier than the local that departs 3 minutes earlier

Eki Bright remembers your most used route patterns and suggests them on the route screen based on your current location. After a few trips, you don’t need to manually create DIY routes anymore.

Suggested routes based on location and history, departure times updating live

The Live Activity now updates more reliably in the background throughout your trip.

Live Activity on the lock screen

My personal favorite new addition to Eki Bright 2.0 is the station relative direction arrow indicators on the station detail screens. This makes it much easier to orient yourself with the correct direction of a railway at a glance.

Station detail with direction arrow indicators in relation to the center station

The station detail screen now shows train frequencies during different periods of the day.

Train frequencies by time period

The bookmarks and search screens have been separated out into their own tabs. I doubled down on native iOS 26 UI and UX (for better or worse).

iOS 26 liquid glass tab bar with native accessory for the route view

In the search tab, you can now search railways.

Railway search in the search tab

Speaking of railways, the railway detail screen shows the full polyline of the railway.

Railway detail screen before and after with full polyline

I think Eki Bright is the fastest and best way to get around Tokyo for everything but route planning. Local timetables give a serious edge to how fast you can find your next train.

Shinkansen Live - Developing the App for iOS

Thu, 25 Dec 2025 07:41:42 -0600

In my last post I introduced the motivation and feature set of Shinkansen Live, my latest iOS app. I encourage you to read that one first to learn about what the app does.

Shinkansen Live app icon

In this post, I’ll discuss a few of the interesting development challenges I faced during its week of development from concept to App Store release.

Overall development strategy
OCR and parsing the ticket image
Live Activities
Animations
AlarmKit
Localization
Dynamic Type
VisionKit Camera

Overall development strategy

I created an Xcode project myself with Xcode 26.1 (later switching to Xcode 26.2), then added the TCA package.

Then, I set off to work using Claude Code with Opus 4.5. I started by having it lay out the SwiftUI View and TCA Feature without any logic. Then I built out the rest of the infrastructure around getting the input image, doing OCR, parsing the output, and displaying the results. I’ll go through more of the history later on in the post.

Early view layouts during initial development

OCR and parsing the ticket image

The most difficult part of getting this app to production was the ticket OCR & parsing system. This system went through the most churn over the week, partially due to expanding scope and partially due to my expanding understanding of the problem space.

My initial thought during the prototyping stage was to target only the “ticket” screenshot from Eki-net you get after purchase. It looks something like this:

Example Eki-net ticket screenshot

In theory, it’d be reasonable to limit the app’s input space to app screenshots from Eki-net (JR-East) and SmartEX (JR-central). Even including web browser screenshots wouldn’t be that much more burden on an OCR-based system. But later on in the project when I’d decided I was happy enough with the prototype that I wanted to target a production release on the App Store, I started thinking about how it would make marketing much harder to say “only works on screenshots” and not physical tickets.

OCR via VisionKit alongside manual parsing has a lot of upsides:

Free for user & developer
Fast
Multilingual
Privacy baked in
No network usage
Relatively mature: less risk of accuracy churn

In theory, multimodal LLMs can handle OCR and understanding more variations of tickets layouts and bad lighting. In fact, while I was writing the parser, I used Opus 4.5 to read the test ticket images in order to create the ground truth test expectation data.

My issue with prototyping with LLMs further was that they had essentially the opposite pros and cons as the VisionKit system:

Unknown, but some ongoing cost (meaning I’d need to come up with a monetization strategy before release)
Unknown which level of model would correctly balance accuracy, cost, and speed over the short term.
Requires network access
Requires sending photo data off device (not hugely private, but still)
Different outputs for the same input

What I didn’t explore directly was using the Apple Foundation model at the parsing layer. The current Apple Foundation model in iOS 26 has no image input API, but I could perhaps prompt it to take the raw output of the VisionKit model and try to make sense of it. My instinct is that this would be a waste of time, but still worth keeping on the table.

Overall strategy

While working on this, I honestly wasn’t thinking strictly in terms of prototype & production. From the first spark of idea I had an understanding of what the overall UX flow of the app would be. It was mostly getting to an answer of “is this feasible to productionize in a couple days?” while still being flexible on the scope of what production-ready meant.

That meant that I started by adding my ticket screenshot to the project, giving Claude my overall strategy, and having Claude create the OCR & parser system that output results directly into the UI.

OCR prototype

The first prototype parser supported just the two screenshots I had of Eki-net tickets (one from the morning of my trip; another from a similar trip a few months ago).

The implementation set up a VNRecognizeTextRequest in Japanese language mode, read out the highest ranking results into several lines of text ([String]), then fed that to Claude’s homegrown parser that pulled the ticket attributes out of that glob of text mostly using regex.

Since the input was from a perfectly legible screenshot, there was no issues with the VisionKit part nor the parser.

OCR for real Shinkansen ticket images

As soon as I tested the system on a real Shinkansen ticket in a photo, the system fell apart.

I searched through my personal Photo library for as many Shinkansen tickets as I could find. I googled for more. I started with 4 images (and later in development I ended up with about 10 images).

At first I was simply trying to naively patch out the parser with Claude. To do this, I set up a unit test system where I’d do the VisionKit request for each image once and write the resulting [String] data structure to disk. Then each unit test would read that data in, run the parser, and compare the expected ticket structure to the test result.

Unintuitively, the standard Swift Testing unit test setup was actually the less efficient way to iterate on this. Claude was having a lot of trouble reading the detailed test failure information after it ran xcodebuild in the command line. Each build & run & test iteration needed to boot up a fresh simulator, install the app, run the test, then tear down the simulator.

Instead, a built a @main App-based test harness that:

temporarily disabled the real UI.
ran the test code on onAppear.
printed the test results via print statements.
called exit(0) when finished.

For quickly prototyping, iterating, and understanding the scope of the problem space, this solved all the issues with the Swift Testing setup. The same booted simulator was reused on each run. DerivedData and build artifacts were reused, so builds were fast. Claude had no trouble reading print statements from the console output.

I let Claude run in its own loop for a while to see what it could and couldn’t improve with the parser based on the limitations of our system.

Claude found several underlying limitations with the VisionKit setup that were unsolvable at the parser level.

For example, concatenating all the text recognition objects into [String] was done somewhat naively by comparing y-coordinates. If the y-coordinates of objects were within a certain range, they were assumed to be on the same line. When the ticket was tilted, this strategy was interleaving text.

Additionally, some numbers and letters were just flat out being interpreted incorrectly. A 37 was read as a 30. CAR was read as CDR.

Off running on its own, Claude was trying to special case as much of these failure cases it could to get the tests passing.

Example test ticket image that produced the Japanese-only VisionKit parsing output shown below

CC制
東
3月18日（
はくたから5り考
¥3,380
新幹線特急券
京
→
8:41発）
軽井
（9:4着）
7号車
3番B席
R001
2025.-3.18東京北乗FN7（2－）
50159-01
沢
0

Comparing some of the fields, you can see the OCR output taken naively is not great:

The departure time is there but the arrival time is 9:4 instead of 9:43.
The arrival station’s 軽井 and 沢 are split up and should be 軽井沢.
The departure station’s 東 and 京 are split up and should be 東京.
The train name and number are a mess: はくたから5り考 instead of はくたか 555号

Using spatial data

The OCR part of the system was trying to abstract away the spatial parts from the parser. Looking at the raw data, my intuition was that the spacial data could be useful within the parsing layer. Instead of passing [String] between layers, I was now passing:

struct TextObservation: Equatable, Sendable {
    let text: String
    let x: Double
    let y: Double
    let width: Double
    let height: Double
}

Each field parser within the parsing system could decide for itself how to use the spacial data. This is especially useful considering how important anchor values are. For example “発” (indicating a departure time) and “→” (indicating the station to the left is the departure station).

This improved things a bit for 5 ticket images, but after adding another 5 and going all in on English ticket support, there were plenty more edge cases to consider.

Transforms

Only after seeing some wonky positioning of the text boxes in my loading animation (see below), I realized that I wasn’t accounting for the image transform properly when converting the input UIImage to CGImage as input to VNRecognizeTextRequest.

extension CGImagePropertyOrientation {
    init(_ uiOrientation: UIImage.Orientation) {
        switch uiOrientation {
        case .up: self = .up
        case .upMirrored: self = .upMirrored
        case .down: self = .down
        case .downMirrored: self = .downMirrored
        case .left: self = .left
        case .leftMirrored: self = .leftMirrored
        case .right: self = .right
        case .rightMirrored: self = .rightMirrored
        @unknown default: self = .up
        }
    }
}

Levenshtein distance

Like our previous example of CDR instead of CAR, VisionKit was reading strings like TOKIO instead of TOKYO. For these parts, I figured calculating Levenshtein distance from known strings was the right strategy. The Shinkansen system is large but not so large that I couldn’t ingest the station name values and the other known strings like JAN, FEB, etc.

One strategy I haven’t tested yet is using VNRecognizeTextRequest.customWords with the full dictionary of station names, etc. to see if that eliminates the need for using Levenshtein distance at all.

English and Japanese mode OCR

For some background, tickets can be printed in an “English” variant that includes a mix of English and Japanese text. If you buy from a ticket vending machine and complete the purchase in English mode, it’ll print an English ticket. Similarly, if you buy from a human ticket vendor at the counter, they will print your ticket in English variant if you speak English to them.

Example of an English variant Shinkansen ticket

At the VisionKit layer, I was first using VNRecognizeTextRequest in Japanese-mode only.

I tried expanding a single instance to include both English and Japanese text. But checking the raw results, a dual language setup severely impaired its abilities.

For a while, I had a dual parsing system that would check for a few English strings, and if any were found, it would assume the ticket was an “English ticket” and run a separate English VNRecognizeTextRequest and return those results. This didn’t work well for a few reasons:

The Japanese VNRecognizeTextRequest was surprisingly bad at reading numbers compared to the English one.
Deciding at the VisionKit layer which text results should come from the English request didn’t make a lot of sense conceptually if I wanted to keep the majority of the logic in the parser layer.

Therefore, I decided to run both the English and Japanese VNRecognizeTextRequests on every input and provide all the results to the parser.

struct BilingualOCRResult: Sendable, Equatable, Codable {
    let jp: [TextObservation]
    let en: [TextObservation]
}

I was also previously discarding the confidence score (0.0...1.0) that VisionKit provides with each observation. This score was actually different in the parallel observations for English and Japanese in some cases, especially number recognition. I added the confidence score to the output so the parser could use it.

struct TextObservation: Equatable, Sendable, Codable {
    let text: String
    let x: Double
    let y: Double
    let width: Double
    let height: Double
    var confidence: Float
}

Unparseable fields fallback UX

At this point in the development of the parser, I was pretty certain reading photos of tickets was never going to be reach 100% accuracy for every field.

I took a break from working on the parser to implement editing for every field in the ticket UI. This meant that users could manually recover from parsing errors and omissions.

Editing screen with editable ticket fields

Not needing to reach 100% accuracy in the parser while still ensuring the user gets value out of the system as a whole opened up a more reasonable strategy for the parser.

Defense-in-depth parsing system

After tweaking more and more of the VisionKit layer, I had to regenerate the VisionKit output test data for each test ticket image, and then essentially rewrite the parser layer.

This time, the strategy was to:

Pass in the full English and Japanese results including relative x and y coordinates to each field.
Create a sub-parser dedicated to each field of the ticket that needed to be parsed.

Within each sub-parser, my strategy was to start with the best case scenario of input data quality, then step-by-step keep loosening the guidelines to account for more unideal cases that had come up in the test data, then finally falling back to returning nil for that field.

OCR testing system

Claude iterated on the field parser implementations for an hour or two, one at a time, checking the test output to ensure there were no regressions along the way.

At a certain point all the tests were passing and as much as I wanted to keep finding test data and tweaking the parser, I knew I had to move on.

Live Activities

During development I had to keep reminding myself that the whole point of this endeavor was to have a slick (read: useful) Live Activity.

Live Activity in Dynamic Island compact, expanded, and lock screen views

My design process was quick and to-the-point:

list out all the Live Activity contexts: lock screen, dynamic island compact leading, compact trailing, minimal, and expanded.
consider all the ticket info I had available from the parser output.
consider all of the above for the “before” and “during” trip phases (if I knew I had more accurate control over Live Activity update timing, I might have divided these phases up even further).

In lock screen and expanded contexts, you can mostly display everything you want. The challenge is in aesthetics and visual hierarchy like in any design.

Lock screen Live Activity showing trip details

When dealing with the compact and minimal contexts, you really do only have the equivalent of about 6 very small characters to work with, and 2 lines if you want to push your luck. If you try to fill the entire available space of the Dynamic Island on either side, you’ll lose the system clock which is no go for my use case.

Compact Live Activity in Dynamic Island

When I thought about it, the most important of all the contexts was the compact leading and trailing in the before trip phase. This is when the information is most needed at a glance.

I stacked in departure time and train number in the compact leading. This information is used to decide when to go to the platform and which platform to go to.

I stacked the car and seat number in the compact trailing. These are used to decide where to line up on the platform and of course where you’ll sit.

View guidelines and tips

Designing for Live Activities is painful. There are significantly more constraints to the SwiftUI View system than in normal app contexts. Most are undocumented. Some quirks can be teased out in the SwiftUI Preview if you’re lucky. Others only appear on the simulator or a real device.

I have a couple guidelines and tips I follow for Live Activities.

Use non-semantic font sizes for compact and minimal

The system ignores Dynamic Type settings in the compact and minimal Dynamic Island contexts. Using point sizes directly gives more flexibility while designing in the very limited space.

In the lock screen and expanded contexts, there’s limited Dynamic Type support (4-levels total), so it’s still worth using semantic fonts as usual (e.g. .headline, .title3).

For dynamically updating times, prepare to spend a lot of time in trial and error

Maybe someday I’ll write a full explainer post on which countdown-style Text fields are supported. In short, if you want dynamically updated fields in any part of your Live Activity, your formatting options are limited and underdocumented.

A couple configurations I used:

// `44 min, 23 sec` or `1 hr, 52 min`
Text(attributes.departureTime, style: .relative)

// Centers `Departing in N min, M, sec` due to `.relative`'s implicit `maxWidth: .infinity`
HStack(spacing: 4) {
    Text(String(localized: "widget.departing-in", comment: "Footer label shown before departure"))
        .frame(maxWidth: .infinity, alignment: .trailing)
    Text(attributes.departureTime, style: .relative)
}

// Linear progress view with no label
ProgressView(timerInterval: attributes.departureTime ... attributes.arrivalTime, countsDown: false)
    .progressViewStyle(.linear)
    .labelsHidden()
   
// `60:00`
Text(
     timerInterval: (Date.now)...(Date(timeIntervalSinceNow: 60*60)),
     pauseTime: Date(timeIntervalSinceNow: 60*60),
     countsDown: true,
     showsHours: false
)

As noted above, any Text using: Text(Date(), style: .relative) will expand to fill its full width.

It’s frustrating just thinking about this again. I basically just banged my head against the wall until I landed on a design I felt embarrassed but comfortable shipping.

Clamped width custom Layout

I use this custom Layout judiciously in the Dynamic Island.

It makes the underlying view’s frame collapse to fit its ideal width, but clamped to a maximum value.

I want the compact or minimal context to be as narrow as possible. I want short input text to result in a very narrow Dynamic Island layout. I want longer input not to expand beyond a certain width; and even more, I want to use the minimumScaleFactor modifier to further shrink the text size once that maximum width is reached.

private struct SingleViewClampedWidthLayout: Layout {
    var maxWidth: CGFloat

    func sizeThatFits(proposal: ProposedViewSize, subviews: Subviews, cache: inout Void) -> CGSize {
        guard let subview = subviews.first else { return .zero }
        let idealWidth = subview.sizeThatFits(.init(width: nil, height: proposal.height)).width
        let width = min(idealWidth, maxWidth)
        return subview.sizeThatFits(.init(width: width, height: proposal.height))
    }

    func placeSubviews(in bounds: CGRect, proposal: ProposedViewSize, subviews: Subviews, cache: inout Void) {
        guard let subview = subviews.first else { return }
        subview.place(at: bounds.origin, proposal: .init(bounds.size))
    }
}

private struct ClampedWidth: ViewModifier {
    let maxWidth: CGFloat

    func body(content: Content) -> some View {
        SingleViewClampedWidthLayout(maxWidth: maxWidth) {
            content
        }
    }
}

extension View {
    @ViewBuilder func clamped(maxWidth: CGFloat) -> some View {
        modifier(ClampedWidth(maxWidth: maxWidth))
    }
}

Updating in background

Live Activities can usually only be updated via remote Push Notification. But if your app gets a chance to wake up and run in the background, it can also issue updates to the Live Activity.

One of the few reliable ways to have your app woken up in the background regularly is to use significant location updates from Core Location. In order to have your app get background time you need to:

Be approved by the user for Always Location Services permission.
Be approved by the user for WhenInUse Location Services permission AND one of the following
- Have an active Live Activity OR
- Start a CLBackgroundActivitySession (that essentially creates a default Live Activity)

In the case of Shinkansen Live, I have two phases for the Live Activity:

before the train departs
after the train departs

The time of that change over is pretty reliably scheduled. But Live Activities have no update schedule like Widgets do (for some reason).

To update the Live Activity after the train departs I could:

Have the user tap a button in the lock screen or expanded Live Activity that triggers an intent to wake up the app in the background and update the Live Activity.
Hope the user opens the app on their own.

Both of these options are unideal, so instead I ask for WhenInUse Location Services permission and start a monitoring for significant locations. One of these will be fired not long after the train departs (within about 1km or 5 minutes). That trigger will open the app in the background, update the Live Activity based on the current time, then go back to sleep.

Persisting the trip

There’s an edge case I wanted to handle with the Live Activity lifetime.

If the system kills the app in the middle of a trip, the Live Activity in theory should continue uninterrupted since it’s an App Extension. But in the case of Shinkansen Live, I’m expecting to update the Live Activity while the app is backgrounded. This means there’s a potential flow where:

The app is in the background with the Live Activity running.
The app is killed by the system.
The Live Activity continues to run.
The system cold launches the app in the background.

At this point, I could decide to query the Live Activities framework to see if there’s a Live Activity running and if so, restore the ticket model layer and UI. However, I prefer not to treat the Live Activity as the source of truth for the model layer.

I added support with the Sharing library to persist the ticket model automatically on changes. On the above flow, I use the persisted ticket model to restore the UI and Live Activity and AlarmKit state, ensuring the ticket data is still valid.

Handling dismissal

One final bit of UX that’s not mission critical but is very user friendly is to respond to user-initiated Live Activity dismissals from the lock screen. If the user swipes from right to left on your Live Activity, the system dismisses it. When your app next runs, it will receive an update from Activity.activityStateUpdates stream (if you’re monitoring it).

If the app detects a user-initiated dismissal, I consider that their trip has ended, clear the ticket, and go back to the app home screen. There’s an argument that it’d be safer to simply toggle the Live Activity, but since my app’s only purpose is to show a Live Activity, I don’t think it makes sense to build in more complexity to keep multiple states.

Animations

The focused nature of this app allowed me a bit more breathing room to experiment with custom screen transitions and multi-stage animations.

Root level transitions

At the bare minimum, I usually try to use a default opacity transition for root level views when they aren’t covered by system transitions like a navigation push or sheet presentation.

For Shinkansen Live, I added a little bit of extra scale effect to the usual opacity transition of the initial screen, both on cold launch and when returning from the trip screen.

For the trip screen, I first animated the card down from the top with some scale and opacity, then fade in the other sections with some scale.

Scanning animation

The most fun was doing the scanning animation. Once the selected image is downloaded and displayable, I animate it in with a bit of 3D effect. Then I use the coordinate results of the text observations to animate those boxes onto the image.

This animation serves a few purposes in my opinion:

Visually expresses to the user what the app is actually doing.
Buys time for the parser to do its job.
Feels fun and playful in a way that is motivating for users to want to go through the trouble of submitting their ticket image.

My final bit of (self) user testing made me realize that even though I’d built in a way to update ticket values that were missing or erroneously parsed, I had no in-app UI for actually doing the field checking. Depending on their input source, the user would have to hold up their physical ticket next to the app’s virtual ticket to double check the fields. Or if they’d used a screenshot, they’d have to flip back and forth between Photos app.

As my last big task, I added support for showing the original image inline with the ticket in a modal overlay.

This setup uses matchedGeometryEffect and was a nightmare to work through. In the end it’s not perfect, but the speed conceals some of the jankiness. matchedGeometryEffect has a lot of undocumented incompatibilities with other modifiers, so it was just hours upon hours of reordering modifiers and building and running to check what had changed. I came out of the experience with little new demonstrably true observations I can share here, unfortunately.

Card dragging

Whenever there’s a card-looking UI on screen, I want it to be interactable even if there’s no real gesture that makes sense.

I created a custom drag gesture with rubberbanding that allows the user to drag the ticket a little bit in any direction. When released, it snaps back with a custom haptic that mirrors the visual.

AlarmKit

AlarmKit is new in iOS 26 and I thought it might be a good fit for Shinkansen Live’s use case.

Alarm setting in trip screen and full screen alarm notification

The integration was mostly straightforward, but it added another layer of complexity to the reducer implementation to ensure that it was added, changed, and removed for all the relevant cases:

Arrival time exists or doesn’t exist.
Arrival time is updated manually by the user.
System time is too close to arrival time to set an alarm.
Journey is ended by the user before arrival time.
Live Activity is dismissed from the lock screen.

And more.

Permission dialog

A last minute annoyance with AlarmKit was testing localization: I found a bug where the localized text for the AlarmKit permissions dialog was not being used on iOS 26.0. But the bug was fixed for iOS 26.1. And no, the bug nor the fix were mentioned in any official SDK release notes.

Localization

One of my favorite usages for coding agents is doing Localization setup. Note I’m specifically not talking about LLMs doing the actual translation, but instead:

doing the initial conversion from inline strings to string keys e.g, loaded.end-journey-button.
adding localizer comments to each string key e.g. Button to end the current journey.
maintaining default values for when string interpolations are required e.g.

Button(
    String(
        localized: "loaded.arrival-alert.status.minutes-before",
        defaultValue: "\(mins) min before",
        comment: "Status showing minutes before arrival (for menu items)"
    )
) { ... }

The initial conversion uses a custom markdown document with some basic rules. It takes about an hour for the first run and then a few more passes with a human in the loop to ensure the xcstrings file is clean.

Dynamic Type

The app still lays out pretty well with most levels of Dynamic Type. I only use semantic font qualifiers. All content is in a scroll view that’s usually fixed.

Landing screen with various Dynamic Type sizes

Trip screen with various Dynamic Type sizes

VisionKit Camera

I’m using VNDocumentCameraViewController as the integrated camera view for scanning. The UX is a little weird because there’s no way to limit the input (output?) to one photo. The result is the user can take a bunch of photos of their ticket before they tap “Done” and the app will only read the first.

Project stats

By the numbers

Development time: ~6 days including App Store materials
Lines of Swift (excluding tests, static data, etc.): 8,388

Daily Devlog

Dec 16, 2025 — Initial layout & OCR foundation
Dec 17, 2025 — Live Activities, AlarmKit, failure states
Dec 18, 2025 — Bilingual OCR, loading animation, app icon, localization
Dec 19, 2025 - Parser rewrite, settings view
Dec 20, 2025 — Polish, persistence, supported formats view, App Store prep
Dec 23, 2025 — Ticket image modal, App Store materials, v1.0 Release

Conclusion

Part of the appeal of this idea is that the scope could only creep so much. I honestly didn’t leave much on the TODO list for a version 1.1 besides endless optimization potential for the parser.

As usual this post was brain-dump style. If there’s any part you connected with and would like me to explore further, feel free to give me a shout.

Shinkansen Live: Scan Your Ticket, Get a Live Activity

Wed, 24 Dec 2025 05:53:39 -0600

Today I’m releasing my latest iOS app: Shinkansen Live or 新幹線ライブ in Japanese.

Shinkansen Live on the App Store

Shinkansen Live app icon

The concept is simple: you scan your Shinkansen ticket or receipt and you can see the details of your trip in a Live Activity on your lock screen and Dynamic Island.

Scan flow in 3 panels: scanning, ticket, lock screen

Here’s a quick screen capture of the main flow:

Motivation

I took a quick Shinkansen trip from Omiya (north Tokyo) to Karuizawa (Nagano) last week to do some co-working with my friends Jens and David. I had pre-purchased a reserved seat with the Eki-net, JR-East’s Shinkansen app (on iOS, it’s a web app wrapper). Similar to when I have a physical ticket (but somehow worse?) I found myself opening the app repeatedly to check my ticket’s listed attributes for:

departure time: in the 30 minutes or so lead up, before I’d entered the gates.
train number: to cross reference and check the platform I should leave from.
car number: when it was time to ascend to the platform and look for where on the platform I should line up.
seat number: when the train pulled up and I was boarding.

Both of my train apps Eki Bright and Eki Live have Live Activities support that I use frequently. I only ride the Shinkansen a few times a year, but while riding up to Karuizawa that day, I wondered, couldn’t I just OCR the Shinkansen ticket info from screenshot and stuff it into a Live Activity?

And so as soon as I arrived at Sawamura Roastery in Karuizawa, I got to work on prototyping a new app. My goal was to have a prototype by the ride home. With some extra polish it ended up taking a few more days of work.

Co-working vibes at Sawamura Roastery in Karuizawa

Features

The structure of the app is essentially a landing screen, a processing screen, and a trip-in-progress screen. The Live Activity requires its own multiple states and layouts of UI. For polish, I needed an error screen, an about screen, and a screen explaining what ticket formats are accepted.

Supported input formats

Landing screen showing input options

My initial scope was just handling screenshots from Eki-net (JR-East’s app) and SmartEX (JR-Central’s app), and in retrospect this probably would have better line to draw in the sand for version 1. However, I added support for scanning physical tickets too since the app seemed like it would be too specialized without physical tickets, probably the majority use-case.

And so, you can scan your physical ticket with the camera, choose a screenshot from the Photo Library, paste an image from the system pasteboard, or create an empty ticket if you want.

OCR and parsing

Scanning a ticket with OCR in progress

As of version 1.0, the app uses on device VisionKit to recognize text in the image and custom algorithm to do error recovery and parse out the relevant attributes from the ticket. I’ll discuss the development aspects of this decision in a future post, but for now, I’ll say that the merits of using OCR over multi-modal LLMs are that OCR is very fast, maintains privacy, and is accurate enough for a V1.

Trip in-progress

Trip in-progress screen showing ticket details

Once the ticket is scanned and parsed, you land on the trip screen for the remainder of your journey.

I recreated a facsimile of the legendary Shinkansen ticket. While doing research into ticket formats, it was surprising to see how different the information layouts are depending on where and by what means they are purchased, but the aesthetic is generally the same.

For the case of physical tickets, parsing is imperfect, so I wanted to ensure users could recover from minor errors like a missing time or train number. Therefore, all fields are user editable by tapping.

Editing screen with editable ticket fields

I also include the input image that a user can reference in an expanded view. This makes it easier to double check values and fix mistakes.

Live Activity

Live Activity in Dynamic Island compact, expanded, and lock screen views

Finally, the whole point of all this is to have a functional Live Activity. The Live Activity has a before and during layout. Before departure we show the departure time, train number, car number, and seat number (for reserved seats). During the trip, we show the arrival station and time.

Due to a technical limitation with Live Activities, I use Location Services to monitor for significant location changes in the background, and use that to wake up the app and update the Live Activity when the departure time has passed. On the technical side, this means I don’t need to run a push notification server or do any other networking from the app.

Arrival alarm

I’m a chronic sufferer of a disease called Scope Creep (this is a joke), so I couldn’t help but add an optional arrival alarm feature. This feature uses the new iOS 26 AlarmKit framework.

Alarm setting in trip screen and full screen alarm notification

Animations and transitions

I spent a unreasonable amount of time working on the animations and transitions for this app. Since there’s comparatively not a lot of screens or unique transitions to handle, it felt like a good opportunity to push the limits and make the upload experience more delightful. After all, there’s not a ton of benefit to cost when you consider needing to download an app, and then screenshot or photo your ticket in order to get that slight benefit of not needing to unlock your phone or take your ticket out of your pocket. Hopefully some fun animations add to the motivations to get over that mental hump.

Scanning transitions and animations

Image popup transition

Outlook

Shinkansen Live is free on v1.0 release. I have no idea whether the App Store listing will get views, whether the listing will convert to downloads, whether the idea will resonate with people to try, and whether any one-time users will keep the app on their devices and remember to use it. I don’t use the Shinkansen enough to estimate this well.

Regardless, I’m glad the app exists now. I hope it saves at least a few people that little extra friction in an otherwise smooth Shinkansen journey.

Comprehensible Later: A Read-it-later App for Language Learners

Sat, 15 Nov 2025 05:57:31 -0600

This post is a short retrospective on Comprehensible Later, my working-title for a read-it-later iOS app prototype I worked on last week. Although it’s currently in private beta on Test Flight, I want to share the motivation and technical challenges I ran into while working on it.

Share Extension presented from Safari, main app article list, and article detail screens

TLDR: Comprehensible Later is an iOS app for saving articles natively written in a language you’re learning, with automatic translation via LLM to a simpler version of your target language. The goal is to give you more interesting things to read at a level you can understand without needing to pause to look up every other word.

Original level and simple level for a Japanese article

Original level and simple level for an English article (from this blog)

What is Comprehensible Input

Comprehensible Input is part of a language acquisition framework first introduced by Dr. Stephen D. Krashen. The framework states that language is separately acquired and learned. Acquisition happens by ensuring ample input (reading or listening) with the important caveat that the input is comprehensible at the learner’s current level. Learning happens through comprehensive study of rules and vocabulary. From this summary:

When we receive comprehensible input, the conditions are met for our brain to be able to use its natural ability to acquire language, without having to do anything else. There’s no need to study, review vocabulary, or practice anything. Watching and reading itself results in acquisition.

In some senses, this method seems intuitive, not in the least since almost all children acquire language skills before they begin formal teaching. In a second-language context, graded readers – books written for various non-native language levels – have existed for over a century. Wikipedia even has a simple English language variant for many common articles. I’ve occasionally used the modern Satori Reader service for Japanese graded texts.

But I think the important part is recognizing exactly how basic you need to make some input in order for it to be understandable, especially at the absolute-beginner level. In a since-removed introductory YouTube video from the creator, he shows a session of an instructor sitting with a zero-level beginner student, pointing at vivid images in a travel magazine and gesturing heavily while explaining the contents very slowly in the target language as the primary means of bootstrapping.

Language is so multi-dimensional that it’s incredibly time consuming – both as a creator and a consumer of materials – to get the exact level of material that is both comprehensible but challenging enough to increase your overall ability. Then add another dimension of motivation: as a reader, how do you find materials with a subject matter that’s interesting to you and will keep you motivated to push through word-after-word, page-after-page, day-after-day?

This led to a hypothesis:

Graded readers are usually close to the correct difficulty to facilitate learning, but do not have an audience wide enough to support a variety of interesting subject material.
Native materials cover an infinite range of interesting topics, but are infeasible to read until the latest stages of language acquisition.
One of the most commonly accepted use-cases for LLMs is text summary and translation.

What if we used LLMs to translate any native article on-demand to the user’s exact target language level?

The barriers to this being feasible are:

Can an LLM properly translate from e.g. Native Japanese to JLPT N4 level Japanese in a “natural” way – where it is simultaneously challenging, comprehensible, and accurate?
Can the translation happen fast enough to fit within a user’s desired language-learning workflow?
What additional resources are required to facilitate language learning? In-line dictionary lookup? An SRS system? Customized word lists?
What unique points are there to each target language that increase the interface complexity? For example, for Japanese learning, should we include furigana for all potentially unknown kanji?
Does it also make sense to allow translation from e.g. Native English to simple Japanese (if the target language is Japanese)?

Specification for the prototype app

I’ve used 2025 frontier LLMs to write and translate simple versions of text before, so I’m confident it’s either possible now at a minimally acceptable translation quality or will be in the very near future.

What I wasn’t confident about is whether it’s cost prohibitive or time prohibitive to use the highest quality reasoning models to do the translation.

In retrospect, I should have spent at least a little more time doing bench testing on the API versions of various models on a wide array of sample articles. Instead, I took the less (more?) pragmatic route of jumping into the implementation for an app prototype that I could start using ASAP in context, as well as distribute to a few friends.

My initial thought was that my main source of content would be blog posts and news articles I come across from my everyday feed scrolling. But I also felt I should support translating raw text too, like that from social media posts.

I considered a Safari Extension to replace existing text on a webpage with the simplified translation, similar to how the built-in translation function in Safari works. But my gut-feeling was that this would be too limiting for language learning use cases. Even reading a text at a simpler level of a target language still takes enough time that it would be better to ensure the user doesn’t feel obligated to read everything at once. Additionally, this wouldn’t work for native text outside of Safari.

My next thought was a Share Extension. Share Extensions are old iOS technology, but still highly used and useful. In a share extension I could display the translated article content in a dedicated modal and have full control over its presentation and layout.

However, I also wanted to support the read-it-later use case. Personally, I stumble upon articles when doing feed scrolling sessions when I have a few minutes on the train but don’t necessarily have the time to read the whole article, even in English, at that time. I use Instapaper for read-it-later for English articles and I felt this would be a similarly useful use case to model my app after.

With that in mind I got to work on the actual prototype with the following initial spec:

A native app that:
- keeps a list of articles imported from URLs or as raw text.
- has a detail view that shows both the original and translated versions of the text.
A share extension that:
- immediately processes the shared URL or text and displays it in the share modal.
- allows the user to optionally save the translated text in the app for later.

Note that as of iOS 18.4, there’s actually another option for the interface: TranslationUIProviderExtension. iOS users can replace Apple’s Translation app with another translation app, meaning the Translate menu tooltip can open a third-party app. I have mine set to DeepL. Due to the limitations I’ll discuss later (namely, translation processing time), it doesn’t make sense yet to implement Comprehensible Later as a Translation Extension.

Implementation

I worked through several iterations of a detailed implementation spec with Claude and Codex then set them off to work getting the foundations of the app in place. This wasn’t exactly vibe coding because I specified technologies and packages to use up front and guided their output along the way. But I was still aiming to have the agents create the clay that I’d be molding in a distinct second phase of development.

Packages

The key packages that would make this closer to a weekend prototype and not a months-long project were:

swift-readability - wrapper for Firefox’s reader-view parsing library for stripping down a full page HTML to its essential content.
AnyLanguageModel - use any LLM API with Apple’s Foundation Models SDK interface.
swift-markdown-ui - display the full Markdown spec in SwiftUI (note: I later replaced this).
Demark - convert HTML-to-Markdown.
Ink - convert Markdown-to-HTML.
sqlite-data - SQLite wrapper for local article storage and observable data layer for the app.

Data flow

The initial data flow for articles imported via URL was the following:

Input URL
    ↓ URLSession
HTML Data
    ↓ String(data:)
HTML String
    ↓ Readability
Clean HTML
    ↓ Demark
Markdown
    ↓ AnyLanguageModel
Translated MD
    ↓ swift-markdown-ui
Display

The initial flow for raw text:

Input Text
    ↓ AnyLanguageModel
Translated MD
    ↓ swift-markdown-ui
Display

However, due to limitations with the swift-markdown-ui package, the final version of the prototype uses this flow:

Input URL
    ↓ URLSession
HTML Data
    ↓ String(data:)
HTML String
    ↓ Readability
Clean HTML
    ↓ Demark
Markdown
    ↓ AnyLanguageModel
Translated MD
    ↓ Ink
HTML
    ↓ WebView
Display

With the bones of the app architecture and dependencies in place, I began testing and optimizing the data flow.

Readability

I found a small bug in the Readability Swift wrapper where the baseURL parameter was inaccessible to the URL-based initializer Readability().parse(url:options:). This prevented relative image tags from getting properly resolved to a full address. For example, on my website image tags look like /images/example.jpg and are resolved by my browser automatically to be either https://twocentstudios.com/images/example.jpg (the real server) or http://localhost:4000/images/example.jpg (my local machine).

Luckily, the baseURL parameter was accessible in the Readability().parse(html:options:baseURL:) initializer. As a workaround I simply needed to fetch the page data myself with URLSession.

Demark

Demark has two different HTML->Markdown parsing implementations: heavy-and-accurate or fast-and-inaccurate. Since the HTML is getting pre-processed by Readability in advance of being passed to Demark, I’m using the fast-and-inaccurate version that doesn’t load the full page in a headless WKWebView.

AnyLanguageModel

As of iOS 26, Apple’s local Foundation model is slow, not-ubiquitously available on devices, and (arguably) barely functional for most use cases, especially mine. Within a few years I expect it may be useful. Similarly, my impression is that any other MLX-compatible models runnable on an iOS device are not yet accurate or fast enough for my use case.

Therefore, I grabbed both an OpenAI and Gemini API key and wired them up to AnyLanguageModel for testing. I ran a few trials with the top-tier, mini, and nano variants and decided on defaulting to the mini variant as a compromise between speed, cost, and accuracy. Specifically, Gemini Flash 2.5 is the current default, but I suspect I could spend several weeks creating and running benchmarks across the dozens of closed and open models.

AnyLanguageModel made it easy to build a user settings-based model switcher with very little code adjustments required on my side. Technically, Gemini ships an OpenAI-compatible endpoint so I could have kept even more of the same codepath. During debugging, I realized that AnyLanguageModel wasn’t passing through the instructions parameter to OpenAI, so I submitted a quick PR and Mattt had it merged and version bumped by the next day.

In a later mini-sprint, I added a full settings screen that allows switching model provider, model, target language, target difficulty, adding custom translation instructions, and even fully rewriting the system prompt. Of course, I would never include all these settings in a production app, but it’s useful for my trusted beta testers to tinker if they so choose.

The translation settings screen

By default, my (simple) system prompt is:

Faithfully translate the native-level input markdown text into the target language with the target difficulty level.

Be creative in transforming difficult words into simpler phrases that use vocabulary at the target difficulty level. Combine or split sentences when necessary, but try to preserve paragraph integrity.

The output format should be standard Markdown including all supported markdown formatting like image/video tags. Preserve all structure from the input (paragraphs, lists, headings, links, images, videos). DO NOT ADD COMMENTARY.

Target language: \(targetLanguage)
Target difficulty level: \(targetDifficulty)
Additional notes: \(additionalNotes)

I’ll discuss my impressions of the effectiveness of this prompt a little later on.

Something I noticed almost immediately during testing was that requests were taking at minimum 30 seconds and sometimes over 60 seconds to complete. It didn’t really depend on model size either. I found the same performance characteristics for both OpenAI and Gemini APIs direct from first-party servers. I thought it might be the streaming API or perhaps some configuration in AnyLanguageModel I was not in control of, so I switched back to the single-request version. It didn’t help. I also began testing the same prompt and inputs from the API sandbox pages like OpenAI’s playground and Google’s AI Studio and saw basically the same results.

Although the slow translation speed is a pretty substantial blocker, I felt like, at least temporarily, I could work around it in the UX by leaning into the read-it-later nature of the app. I added support for Apple’s Background Tasks API so there was a greater chance that articles added early in the day would be ready to read by the time the user opened the app.

App UI

With the translation flow in place, I began shaping the app UI.

The list of articles was simple enough. I held off on adding lots of important, but not urgent, contextual actions like archiving and deleting from the list view.

I did add both “import from pasteboard” and “import from free text” buttons to the toolbar.

The article list view showing toolbar buttons for importing from pasteboard and free text

The import URL/text screen

I spent more time on the article detail view. Initially, it displayed the title, import state, and translated article. My focus for adding actions was to facilitate debugging primarily for myself and secondarily for my beta testers. This meant buttons for copying the original article text, copying translated article text, deleting an article, opening the original link, and retrying the translation (with different settings).

After some initial usage, I realized I wanted to see the original text and the translated text side-by-side so that I could compare the language usage by sentence and paragraph.

Article detail view with options to display original and translated text

Supported actions for article detail

Debug info viewer

However, the most time-consuming and impactful change was the markdown display system. This was a tough decision, but I think ultimately necessary for the first version.

Originally, I was planning to use swift-markdown-ui to display the translated markdown text in SwiftUI. This implementation was basically plug-and-play, rendered exactly as I wanted, supported images out of the box, and was performant. However, the one fundamental and unsolvable issue is that SwiftUI Text only supports paragraph level copy support and does not support character-level or word-level selection. For language learning, I absolutely need the ability to select a word and use the context menu tooltip action “Look Up” or “Translate” or “Copy” buttons. swift-markdown-ui would not be able to support this and I needed to research other solutions.

I spent nearly a full day researching and experimenting with other Markdown solutions. My second preference was to convert Markdown to AttributedString either natively or with a package, then display the AttributedString in a SwiftUI-wrapped UITextView with selection enabled but editing disabled. However, both the native and package versions of AttributedString initialization failed at properly respecting whitespace, newlines, and supporting images. My estimation was that it’d take significantly more time for me to grok the full Markdown spec, all the underlying packages, and then implement the required patches than I was willing to spend for a prototype.

Therefore, I pivoted to using a browser-based target view instead. iOS 26 was blessed with WebView, a modern SwiftUI-native implementation of the UIWebView and WKWebView UIKit views before it. With a WebView as the new target, I used Ink to convert the LLM output Markdown back to HTML, added a barebones stylesheet, and loaded these contents. I don’t love using a WebView for this use case since it’s comparatively heavy, has plenty of rendering quirks (like occasional white background flashes), and requires a full screen layout. But at the moment it’s the least-worst option.

Unfortunately, the slow translation speed meant some of the complexity of creating a fully-featured Share Extension was in vain; it didn’t make sense for the user to wait 30-60 seconds for the share extension to load a preview of the article content like I’d originally planned.

My initial vision was to load a one-page preview of the translation as quickly as possible. Then, I’d allow the user to tap a button to continue viewing the full translation in line. Or at any time they could tap a button to save the article URL (or raw text) to the main app to read later. I was planning on having an “open in app” button too, but as far as I can tell it’s not supported to open an app directly from a Share Extension.

I kept the full functionality of the share extension intact in case I can solve the translation speed issue in the future. But as another workaround, I added an Action Extension. An Action Extension appears in the bottom section of the system share sheet. Like a Share Extension it can also present custom UI, however since I already have a Share Extension I made my Action Extension have no UI and immediately save the URL to the app.

iOS share sheet showing both the Share Extension and Action Extension for quickly saving articles

Share Extension with translation complete

Import flow

App Extensions can share data on device with the main app using an App Group. When the user indicates they want to add the URL or raw text to the app, the Extension serializes an Article model to a json and writes a new file to the App Group. The main app monitors the shared App Group directory for new files. When it detects a new file, it adds the Article to the app’s SQLite database. If the Article already finished translation, it will include the translated markdown and no further processing is necessary. Otherwise, it will be queued for processing.

I chose not to share the SQLite database between the main app and the extensions because, since the app and extensions are separate processes, there are myriad issues with using SQLite in this way. Since data sharing is one way (from extension to app) there’s no need to introduce that complexity.

Adding articles from the main app instance skips the file encoding/decoding step and simply writes a new Article to the database.

The processing code is admittedly a bit fragile, but in testing has worked well enough that I haven’t felt an immediate need to rewrite it. It uses an enum Status stored alongside each Article in the database in order to manage the translation queue, including failures. SQLiteData supports observation, so both the article list view and the article detail view are always up to date on an Article’s status.

Localization

Localizing a prototype would be something I’d never consider doing before the advent of coding agents. The actual act of translation between a base language and another language is insignificant compared to the amount of additional tooling and operational complexity of introducing localization keys, adding comments, handling interpolation, handling pluralization rules, handling error messages and other strings generated deep in business logic, and handling the indirection involved in looking up the values for the keys. The new xcstrings file’s autogeneration definitely helps ease the burden. But it’s at least an order of magnitude more work in my opinion.

All that said, coding agents can automate enough of this work that I added full localization support for Japanese for one of my beta testers who wanted to try the app for converting English to simple English. I’m still cognizant of the ongoing support complexity full localization adds to a prototype, but for now it’s not a decision I regret.

Various screens with Japanese localization

Impressions so far

What I’ve learned so far is that the prompt needs to be more customized to each target language and should probably go as far as including an allow-list of words to use, especially for the most basic target difficulties.

I’ve found the models have a hard time with native Japanese news articles. Something about the language is just so dense that my first prompt attempt does not push the model to simplify enough.

Similar to what I’ve found with even commercial apps like Instapaper, a large percentage of sites now have enough paywall or otherwise reader-hostile javascript that it’s not enough to fetch a simple URL directly from the source. I’m not ready to handle the endless, unforgiving work of handling all the edge cases of the open web, so URL fetching is going to be best effort for the foreseeable future.

The Readability library itself is not perfect at parsing out text from pages that aren’t obviously written as “articles”. This isn’t all that different from the built-in Safari reader mode which isn’t universally supported across the entire web.

Seeing some of my blog posts in super-simple English was really fun. One of my ongoing goals is to write simpler without giving up my voice, so seeing how an LLM breaks up my sentences and phrases and clauses is enlightening (of course, not at all related to the use case the prototype was built for).

For Japanese, there’s some unpredictability on how the LLM deals with kanji. Usually it includes kanji as is, but sometimes it will add the reading in parentheses directly after for literally every word. For example, “果物（くだもの）を食べる（たべる）”. Native ruby/furigana support would be ideal, and possibly easier using HTML than AttributedString.

What’s next?

Comprehensible Later is on Test Flight in private beta with myself and a few friends. I’m planning on collecting feedback and evaluating the app’s potential for wider release. It could take another generation or two of LLM. It could take as long as waiting for local models to improve. Or the entire concept could be flawed. I’m not sure yet. But that’s what the prototype is for.

Regardless of the result, it was of course a good learning experience to see what it’s like to build a read-it-later service for iOS in 2025.

Vibe Coding a Rental Apartment Search Management App

Mon, 18 Aug 2025 12:46:25 -0500

I’ve been apartment hunting here in the Tokyo-area with my girlfriend. We’ve been sending links to various rental property listings back and forth in LINE (messaging app) and emailing with brokers. In a chat interface, it was hard keeping up with the status of each of the properties we’d seen, we wanted to see, we’d inquired about, etc. Classic project management problem.

Example SUUMO property listing page slightly edited for clarity

I decided to skip the step of putting each property into a shared spreadsheet and jump straight to vibe coding a web app with Claude Code. I’ve never worked on a full-stack TypeScript app before, and my impression is that LLMs are most proficient at it, so that’s what I went with.

Finished desktop interface for Bukkenlist

My goal was to create a shared space where we could keep track of the status of listings, add new ones easily, do calculations like 2-year amortized cost, keep a notes and ratings field for each of us, see all the salient points of a property at a glance, and archive properties that we decide against or are already taken.

After a day of work, it supported scraping SUUMO listings and worked on mobile and desktop web. Another 2 half-days of work and it supports 4 listing sites, maps, expired listings, and English/Japanese localization. I called it Bukkenlist 物件リスト.

App progression from end of day 1 (left) to final polished version (right) - there's not much visual difference

This was “vibe coding” in the customary definition of “not looking at the generated code at all”. I see the code scrolling past in the terminal window but I’m letting Claude commit it after I check that the rendered result looks and works as intended in the browser window. For this project, I’m playing the role of product manager and QA engineer. However, I did make the decisions about using SQLite for storage, the schema, and the deployment strategy. And I helped Claude dig itself out of holes in the way only an engineer can.

The TL;DR: In 2 working days I produced a completely functional web app with much better usability than the spreadsheet it would compete with. Using an AI tool like Claude Code aimed at professionals, it’s hard for me to imagine someone with no coding background being able to get to the same finish line I did. But with the existing cadre of no-code AI tools, perhaps this would be a perfectly scoped project.

The full development process

I have a Claude Code $100/mo Max subscription. I used the pattern of using “plan mode” with Opus aggressively to ensure proper context gathering and then “accept edits” mode with Sonnet to execute the plan. These were long sessions, so I actually blew through my usage limits once or twice with 1 or 2 hours remaining (with my usual Swift projects I hadn’t hit the Max limit for Sonnet before). At those times, I switched over to the nascent OpenAI Codex CLI (with a $20/mo Pro plan) to see how it did. Everything about Codex still feels months behind Claude Code, but it did handle some of the tasks I threw at it well enough.

Day 1

Learning from some past experiments, I decided this time to be more intentional with my initial getting-started prompts. I didn’t dump my entire vision for the app onto the model and have it create a full product requirements doc and phase-by-phase development plan. I thought staying in the loop would ensure the best chance of success and even minor scalability.

SUUMO listing scraping was the most risky part, so I had it start by creating some infrastructure around fetching and parsing the HTML for a few example listings and comparing the results with the values I’d plucked out by hand.

Console showing results from the initial SUUMO listing parsing

Only after the parsing seemed relatively robust did I have Claude create the initial structure of the Express.js backend and React frontend. It used VITE but I only sort of know what role that plays. The first renderable version was a text field for the SUUMO URL, a submit button, and then a list of the keys and values parsed out.

First working interface with URL input field and parsed listing key/values

Then it was time to add persistence. This was the part where I should have first decided on hosting, got that set up, then decided on the most low maintenance storage solution. Instead, I chose SQLite, which I’ve been interested in lately and have already deployed successfully on Fly.io.

With my engineer hat on, I made the initial decision to have Claude go with a mixed schema-less approach, storing a generous amount of metadata about each property in named columns, but then having a dumping ground JSON column with all the parsed key/value data. Hard to say whether that’s made my life easier or harder while adding new listing sources. For a personal project with 2 users, I think it was a fine decision. For a real production site, I can already tell it would be a nightmare to maintain.

# Final schema of the `scrapes` table
     cid  name           type     notnull  dflt_value  pk
     ---  -------------  -------  -------  ----------  --
     0    id             INTEGER  0                    1
     1    url            TEXT     1                    0
     2    property_name  TEXT     0                    0
     3    scraped_data   TEXT     1                    0
     4    created_at     INTEGER  1                    0
     5    status         TEXT     0                    0
     6    archived       INTEGER  1        0           0
     7    kiyoko_notes   TEXT     0                    0
     8    chris_notes    TEXT     0                    0
     9    kiyoko_rating  INTEGER  0                    0
     10   chris_rating   INTEGER  0                    0
     11   source_site    TEXT     1        'suumo'     0
     12   color_id       TEXT     0                    0
     13   latitude       REAL     0                    0
     14   longitude      REAL     0                    0
     15   expired        INTEGER  1        0           0

From there I had Claude build out the master/detail list in desktop mode. It had little trouble putting together a passible design.

Initial master-detail interface showing property list and selected property detail

I added delete and refresh support since those were helpful in manual testing. Refresh should re-run the scraping and parsing and replace all the fields with the freshly parsed content.

Then it was kind of the fun part: pushing around the fields in the UI to make it more pretty and readable.

Next I had to add image carousel support which was surprisingly easy. I prompted Claude to do some extra research for best practices before deciding on a solution.

Reorganized UI with image carousel

I added deterministic unique color generation for each property based on its unique ID mapped to a hue value 0-359 in HSV. I use this technique often in projects as a nice touch to make resources easier to identify.

Properties with unique color IDs for intuitive identification

I can’t sightread Japanese as fast as I can English, so I had Claude add full UI localization in both English and Japanese to the entire app and have it save the preference in local storage. This helped speed up QA of parser errors going forward.

English/Japanese localization toggle

I wanted to highlight the at-a-glance parts each property that were especially important to the two of us, so I added those in big font next to the image carousel.

First version of the at-a-glance property details

From here it was a lot of polish. I felt like I was in full product manager flow-state, just picking off the next obvious change in the UI and prompting Claude to have a go at it.

The whole point of the app was to facilitate our apartment search process, which ultimately meant appending our own information to listings. I added an open-ended status field to track things like “requested viewing” or “viewing on 8/24”. I added an open-ended notes field for each of us, then a 4-level rating system. In the notes field, we’ve been adding merits/demerits. The rating system is an easy way to clearly communicate our enthusiasm towards each property and see it at a glance in the sidebar.

First version of the notes and rating system for each (hardcoded) user

A cool feature I’d very loosely prototyped with a single ChatGPT query a few days previously was an “amortized cost” field, calculated from several fields. There are so many disparate fees for each listing (monthly rent, management fees, security deposit, key money, parking fee, etc.) that it’s hard to do an apples-to-apples comparison of how expensive properties actually are. It’s elementary school math, but just annoying to do.

It was pretty simple to add this field: parse out the semantic values, multiply the monthly costs by the lease term, add the one-time costs, then divide by the lease term to get the overall monthly cost.

Amortized cost calculation for true monthly expense comparison

I was on the fence about whether to build out a full user table and authentication system. It may have been worth seeing whether Claude could have one-shotted multi-user support. Instead, I opted for a simple password auth and full editing support for any field. I’m pretty happy with this solution and proud of myself for not going overboard on the spec. It’s much easier to share a single password than deal with a create account flow on multiple devices or while on the go. I set some strict rate limits for password attempts and page requests in general and know that if the site gets hacked and trashed somehow it’s not a huge deal.

Simple password login screen to gate the whole app

It was finally time for deployment! I was definitely procrastinating on this, but I wanted to get it online before I went to bed.

Looking into some of the common free hosting services that target JS, I realized Vercel was serverless and I’d need a different solution for the SQLite storage. I could have tried Turso for SQLite hosting, but signing up for 2 services felt like too much complexity. I went back to Fly.io since I have some experience with them and an existing account and all the CLI stuff installed.

Claude was happy to set up all the deployment stuff and mostly one-shotted it. The big issue came with my underlying scraping implementation. Scraping was based on Playwright which needs to spin up a full Chromium instance and that takes 10+ seconds on a 2 GB machine. I have aggressive suspension set for my Fly.io instances which means this heavy startup cost needs to be paid every time a new listing is added. I also didn’t want to pay for a full 2 GB machine on Fly.

I started another vibe spike to replace Playwright with Puppeteer and a lighter Chromium fork based on this guide from Vercel. With a lot of trial and error (including rewriting the parser), I got the memory requirement down to 512 MB at the cost of 30+ second scraping.

At this point, I took a step back and thought about whether I actually needed a full Chromium-based scraper. After all, I’d never actually verified whether these sites were doing enough JS rendering to require it. I don’t have a lot of experience with scrapers and this project was an attempt to fix that. I had Claude do yet another spike with some initial research as to what the most common tools were for low-resource scraping and it chose JSDOM. After rewriting the parser yet again, it turned out this worked fine and was super fast and easily deployable to a tiny 256 MB machine.

If I’d have tried deploying immediately after finishing the very first version of the scraper, I’d have had a much easier time. But I also realized I wouldn’t have had much invested at this point, and my motivation to continue may not have survived this deployment slog. An interesting paradox! In theory I would have saved hours, but in practice I may not have shipped anything. It’s also possible I would have chosen a different deployment service that affected my choice of persistence solution, etc. Decision ordering really matters, and I’m trying to get better at it. But also, LLMs make spikes, backtracking, and rewrites so low-cost/low-effort that as long as you’re willing to ignore sunk costs and your motivation survives you can end up with much more optimal solutions in the long run.

App successfully deployed to production at the end of day 1 (Japanese interface)

My first commit was 4pm on Saturday and my last commit before going to sleep was 6am Sunday. I’d (re)watched 3 seasons of Silicon Valley in the background. I sent my girlfriend a link and the password and went to bed.

Day 2 & 3

I woke up a couple hours later and made pancakes and got a message from my girlfriend with links to listings from 2 other services. So it was time to add support for more listing sources!

I had Claude do a refactor of the scraper in preparation for adding multi-service support. Again, this was vibe coding so I had no idea how well it did, but I trusted it. This took about an hour. I gave it a link to a new listing and had it run its scraping parsing iterative procedure to write an initial version of the parser. According to the git logs it took about an hour to write the two new scrapers and a guide for itself for writing future scrapers.

Multi-source support showing listings from different rental websites

I realized the two of us would need to use my new site from our iPhones, so I added mobile support. This was way way faster than I expected. It took a bit more Claude coercing the next day to get it fully optimized, but the first attempt was definitely usable.

Initial mobile interface with separate property list screen (left) and property detail screen (right)

Sunday was a half-day. On Monday, I put in another half-day optimizing the mobile layout, adding another source, adding listing expiry support, maps support, and deep linking support.

Maps support was actually the most difficult single-feature I’d vibe coded for the whole project. Scraping the coordinates for a listing wasn’t too bad, but deciding on the maps provider and implementation was difficult.

At first, I was planning on rendering out a static map image on the backend during property add because it seemed simplest and lowest cost. But since I already have an Apple Developer account, using the MapKit JS API was free so I went with that.

Turns out that Claude had a pretty awful time integrating the MapKit JS library. This is where I ran into a lot of frustration with vibe coding and not having any idea how React works, how JS library loading should work, how environment variables work on the client side, how JS library token authorization should work, and more. I was in thrashing mode with Claude, watching it implement “fixes” that seemed dubious even to me, a JS novice, and inevitably did not work at all.

I had to get a lot more hands on and spent a long dev cycle restarting the dev server, deploying to production over and over, copying and pasting browser console logs, and adding and removing secrets from the Fly.io admin page.

In the end, we got it working, but it’s hard for me to say why Claude struggled so hard with this particular task and how I could have approached it differently.

Map showing the property location and its relationship to closest station

Iteration loop workflow

For my overall development experience, the local build and serve process was more effortless than iOS, but I found Claude’s new background Bash processes feature frustrating.

Claude would write some code, start a background server, test the code by making some calls to the server, make some code changes, then not realize that the server needed to be restarted and get stuck in a “why isn’t the output changing” loop. I’d need to keep an eye out for this and intervene.

After a while I took control of starting/stopping the dev server in a separate terminal window, but Claude would ignore this and keep trying to do its own thing. If I was working on this full time I would certainly spend some time making this flow more efficient. I dealt with the paper cuts.

Final thoughts

We still have at least a few weeks left in the apartment hunting process. The less we need to use this app the happier I will be.

For the time investment, I’d consider this app overkill. It’s useful individually, but for a production app it wouldn’t work as scraping is presumably against the TOSes. The parsing is sloppy. There’s no user account system. There’s no sharing system. There’s no base SaaS functionality. Even individually, it would have taken a lot less time to simply enter the key fields into a spreadsheet manually.

But this was a good experience seeing how feasible vibe coding is for someone with my background. There were several points in the process where I hit that beautiful flow state and really loved it. But there were also stretches where Claude was thrashing and I was losing my patience. Or when I was the tool of the LLM clicking boxes in admin panels or doing visual QA while it was doing the interesting architecture and coding tasks.

One thing’s for certain: I never would have attempted a project like this without an LLM agent. If I did, I probably would have lost motivation after finishing the first scraper. I probably would have used a technology I already knew even if it was not the most prudent choice in 2025.

I’d like to try some of the more “batteries included” vibe coding environments (e.g. Lovable, Bolt, Replit, V0) to do a similarly scoped project in the near future. I’m most comfortable with Claude Code at the moment because I’m used to the freedom + sharp edges combination. But it’s hard for me to imagine a non-programmer or even a junior programmer being able to dig themselves out of the holes I found myself in a few times. There’s just a lot to know still to get an MVP designed, developed, and deployed.

I can see how using a vibe coding environment with less freedom but more well-paved integrations could prevent dead-ends and thrashing and bad developer experience. Maybe within the year both Claude Code and the vibe coding platforms will have converged into providing decent enough support for users of any background.

Reintroducing Technicolor: Binge Watch with Friends Over Space and Time

Fri, 25 Jul 2025 09:00:00 -0500

Although it’s still in beta, I think it’s a good time to reintroduce my web app side project called Technicolor.

Technicolor beta app icon

Technicolor is a chat app tailored for watching TV shows with friends asynchronously. I’ve found it to be a great way to stay in touch with friends in other cities/states/countries.

The current version of Technicolor is a native SwiftUI app available on iOS 17.4+ devices and macOS.

Technicolor app overview showing dashboard, room interface (redacted), and media inspector screens

How it works

Technicolor is a multi-player experience.

Gather some friends: Technicolor is optimized for IRL close friends. A group of 2-4 friends is most optimal.
Choose a TV show to watch: The best picks are shows that you can imagine generating a lot of reactions or hot takes, but choosing the right show is more art than science in my experience so far. Technicolor doesn’t embed/include media, so all members must have access to a streaming service or file-based media.
Create a Room: Each episode discussion lives in its own chat room. Technicolor uses TMDB as its media metadata provider.
Watch the episode on your own schedule: Each Room member watches the episode and leaves comments tagged with the timestamp. If you watch first, you lay the foundation for discussion. If you watch later, you’re often replying to existing comments. It’s a unique experience each way.
Mark as watched: Tap the “Mark as Watched” button to alert other members via push notification that you’ve finished watching so they can read your comments.
Read and reply: Respond to comments from other members. Keep the discussion going for as many turns as you’d like.
Move onto the next episode: Technicolor is media-aware and has helpers for quickly creating a Room for the next episode in the current or next season.

Main features

Navigate your watchlist in the Dashboard

Technicolor Dashboard showing active rooms organized by TV show

Manage your watchlist on the Dashboard screen. The dashboard intelligently manages active Rooms so you have quick access to episodes you need to watch and those you need to read comments for.

Rooms are grouped logically by TV show and members.

Technicolor also supports movie watching groups. All movies watched by the same members are grouped in one section.

It’s easy to create the next episode by tapping the more button and choosing “Create Room for S03E01”.

Create Room for next episode popup

Leave comments in a Room

Room interface showing timestamped comments (redacted)

Comments in a Room are grouped into mini-threads by timestamp.

There’s a custom control for selecting a timestamp by tapping and dragging like a video scrubber.

Tap the info button to see a quick overview of metadata about the episode via TMDB.

Episode info screen showing metadata from TMDB

Start a new show

There’s a flow for adding your first Room for a show. Search for a TV Show, Movie, or enter a custom title. Then select which friends you’ll watch with.

New Room search screen showing Breaking Bad search results

Friend management

Technicolor has a full mutual-friend management system. You can only create new Rooms with users you have a mutual friendship with (or are already in an existing group with).

Me screen showing friendship management and settings

Invites

In this beta phase, Technicolor uses an invite system to control new user sign-ups. A user can create unlimited invite codes to invite their IRL friends.

Invite screen for generating invite codes and checking redemption status

Limitations

Async-only

This native-first version of Technicolor follows a few other variants I’ve created and used over the years (see the History section below).

In earlier versions, Technicolor could operate as both a live-streaming, synchronous client in addition to a async client. I found that live-streaming support, although kind of cool, didn’t really make sense in the timestamp marked format. Normal chat apps work fine since everyone is synced and reading/writing comments in real time. There’s also not much reason to keep the history around since everyone has already caught up on the comments.

For this reason, and to keep implementation complexity low, I’ve left out Websocket support. Optimizing the UI and UX for asynchronous makes things much simpler to use, explain, and maintain.

Apple platforms-only

Most of my friends are iOS/macOS users, and since I am an iOS specialist, I’ve decided to only target Apple platforms for now.

I’m considering a web version for the future to include my Android/Windows friends. But at the moment, it’s already a lot to fill out the feature set and polish the UX for a non-revenue-generating side project.

The future of Technicolor

I’m planning to do beta testing with my close friends for a while until all the primary flows of the app feel production ready.

I still have plenty of unimplemented ideas that could improve the commenting-while-watching flow.

There should be a timer mode that automatically counts up while the episode is running, so you don’t have to choose timestamps manually as often.
The TMDB episode detail screen should also load the list of actors and characters in an episode for easy reference. Bonus points for being able to @-mention a character/actor in the chat box with autocomplete support.
I’ve implemented subtitle fetching support on the backend, but haven’t thought through exactly how to surface this info in the app. You could optionally attach a line from the subtitles to a new comment. Or subtitles could automatically appear in line near timestamps automatically.

I have reservations about releasing a social network to the general public due to the amount of moderation required. Technicolor is closer to a private chat app than a social network. And with its current user relationship model it’s probably safe enough and niche enough that bad actors can’t wreak too much havoc. But I’d still probably need to implement message reporting, an admin dashboard for moderation, and some more safeguards around spamming. Being iOS/macOS-only also helps ensure that spam is less prevalent than it otherwise might be.

I could keep the invite system to both limit the growth rate, prevent abuse, and contribute to successful user onboarding.

I’d probably need to harden the backend API a little more, maybe put Cloudflare in front of it. The Fly.io instance currently goes to sleep when there’s no activity to save money, so I could choose to keep it on. The machine specs are very weak, so I could beef those up as well to ensure my users see the theoretical speed of Swift on the server.

A brief history of Technicolor

I first wrote about Technicolor back in 2013 in a post about my side projects.

Original Technicolor web app dashboard

Original Technicolor room interface

The short version is that I moved from Chicago to New York and still wanted a way to watch TV shows with my Chicago friends. We’d still regularly get on video calls for live stream watching, but for other shows we started emailing each other with timestamped comments. These emails started to get unwieldy, and I posited that a simple web app could improve the watching experience while also facilitating episode management outside an email client.

The first version was implemented as a Ruby on Rails app deployed to Heroku and vending HTML and simple JavaScript. It was browser-only and not well-optimized for mobile devices (at the time, I didn’t own a dedicated TV set and watched most shows on my computer).

After the initial short development period, Technicolor worked well enough that I didn’t need to do much active development. Additionally, the code I wrote as a hobbyist Rails/JS-dev had already reached the point of complexity where it was no longer easy or safe to make even minor changes.

In late-2017 I moved to Japan and was motivated again to revive the side project as mobile first. I also wanted to explore a different backend architecture that was type-safe. I briefly started an Elixir backend, and although I already had a little experience with it, it soon became clear that it was too bespoke, especially for a side project I only had occasional time to devote to.

Swift on the server was starting to get some buzz, and some exploration with Vapor made it seem like there were theoretical merits to having a unified language for back-end and front-end development.

I started chipping away at development again (while still using the legacy web-app version), but I fell into side-project hell where each time I’d have the motivation to work on it, I’d spend the entire day updating Vapor, migrating Swift, changing hosting providers, or converting to the latest SwiftUI APIs. There was very little forward progress.

I also fell into various scope-creep traps. Adding the invite system. Adding full mutual friendship support and blocking. My previous episode data provider TVDB switched to a paid-only API, so I descoped that and moved to a Room system that had no media linking.

Heroku’s free tier was discontinued in 2022, and with it the legacy version of Technicolor went offline.

Coming off some headwinds with my last rewrite experience, I finally decided to check the status of my codebase after over two years of dormancy. As I suspected, Claude Code made quick work of updating all my iOS code to my preferred architecture and the latest APIs. Unfortunately, the Vapor framework was a lot further behind the Swift 6 migration than I’d hoped, but still has reasonable support for most bread-and-butter web app capabilities.

I got somewhat lost in the scope creep flow state, tearing through the implementation of all the features that had been rotting on my TODO list for a literal decade. On the user-facing side, I’m especially proud of the very streamlined dashboard layout and the push notifications support (the impetus of the mobile-first rewrite in the first place). On the development tooling side, I’m proud of having a comprehensive server-side test suite and a custom release wizard script that prepares and submits both iOS and macOS versions of the app.

Tech stack details

As mentioned above, Technicolor’s backend is written using the Swift Vapor framework. It’s hosted on Fly.io. The client is an iOS target written in Swift and SwiftUI and supporting iOS 17+. There’s technically a native macOS target via Mac Catalyst, but it actually looks and functions worse than the “Designed for iPad” version, so I’m probably going to deprecate the Mac Catalyst version.

~~I’ll do a deeper dive into the tech stack in a future post because I think there’s at least a few interesting and unique points to the architecture.~~ I go into the technical details in the next post: Full-Stack Swift: The Technical Architecture of Technicolor.

Eki Live - Zero-Touch Assistant for Navigating Tokyo's Railways

Tue, 03 Jun 2025 07:27:00 -0500

I’m excited to announce my latest app Eki Like or 駅ライブ in Japanese.

App icon for Eki Live v1.0

Tokyo-area residents can download it on the App Store.

Eki Live tracks the train you’re currently on and shows the current/next station on your route.

The main interface is a Live Activity:

Live Activity on the lock screen and Dynamic Island

But there’s also a more detailed view inside the app:

Home screen of Eki Live (English version)

The unique point of Eki Live is that it’s designed as a zero-touch app:

The app runs silently (and lightly) in the background throughout the day.
When it detects you’re on a train, the app automatically determines which railway line you’re on and which direction you’re headed.
The app starts a Live Activity that appears on your lock screen and Dynamic Island (on supported iPhones).
When your trip is over, the Live Activity automatically disappears.

All this happens with zero user interaction.

I’ve been using the app during the last few months of development and I think it’s kind of magical. Please give it a try and send me your thoughts at support@twocentstudios.com.

If you’d like a deep dive into Eki Live, why I made it, its limitations, and what I’ve got planned for it next, please keep reading.

Limitations

Eki Live relies primarily on Apple’s Location Services framework – which itself relies mostly on GPS data. Therefore, Eki Live has very limited operation on underground railway lines. This often includes the many stations that are covered or partially underground, as well as tunnels and dense city-areas.

For efficient background standby operation, Eki Live uses a Location Services API called significant location changes. The app stays asleep in the background like all other apps on your device, but is awoken by the system when your device moves some distance from its previous location. When awoken, Eki Live briefly checks whether the device is moving at train-speeds, and if not, it goes right back to sleep. This means that Eki Live will wake up and find your current railway at minimum a few hundred meters after you’ve departed your origin station and sometimes longer. The detection time can be random depending on several factors (whether the system is already using your location, your battery level, etc.).

When GPS accuracy drops significantly, Eki Live will report stations as Nearby instead of Next or Now. When no new GPS coordinates have been delivered by the system in over 60 seconds, Eki Live will switch to reduced accuracy mode with hatching and a low signal indicator shown in the Live Activity and in the app.

Reduced accuracy mode is triggered when no GPS coordinates have been received in 60 seconds or more

As of v1.0, Eki Live will dismiss itself once you’ve stopped moving at train speeds for a period of about 10 minutes. This is only a temporarily limitation and will be improved. If you’re feeling impatient, you can swipe left on the Live Activity on the lock screen to dismiss it.

Similarly, Eki Live will usually handle above ground transfers within a couple hundred meters of the transfer station, but it depends on how divergent the new railway line is from the previous one. This is also a limitation I think I’ll be able to improve in the near future.

Differentiating between railway lines that run parallel is difficult for Eki Live’s tracking algorithm without more input than just GPS. At the moment, Eki Live will use data about which stations you’ve stopped at versus which you’ve passed to determine which of up to several parallel railways you’re currently on. But this can take as much time as it takes to get to a few stations. If you’re feeling impatient, you can always tap Eki Live’s Live Activity to open the app and tap another railway candidate.

You can open the app to manually select your current railway if it's not the top candidate; in this example the Meguro-line

Eki Live does not currently differentiate between local and express trains for railways that have them. However, Eki Live will sometimes show stations as Passing instead of Now when it has high confidence a station will be passed and not stopped at. This depends on many cars the train has and which car (front or back) you are currently occupying.

Finally, there is an undocumented hard-limit on the number of Live Activities an iOS app can start during a period of time while the app is in the background. As of iOS 18.4, the limit is 10 times per 24-hour window. This means that Eki Live will only be able to start 10 Live Activities per day from the background. In practice this should be an incredibly rare occurrence. But if it does happen, the workaround would be to open the app, which would start the Live Activity directly on device.

My mission from version 1.0 onward is to overcome these limitations one-by-one to make the app fulfill its promise of being truly zero-touch on any railway.

Privacy

The goal of Eki Live is to improve your ease of navigation around Tokyo. Eki Live does not and will never have ads or sell data to third-parties.

Eki Live does not send any raw location data (i.e. latitude, longitude) off device (I have no interest in knowing where you are or where you’ve been).

The only exception to the above is a technical detail due to an Apple API limitation, which I will explain below.

In order for the app to start a Live Activity automatically while the app is not open, it must send data to Apple’s push notification server (APNS). APNS then forwards the data back to the device.

When Eki Live is running in the background and determines which railway line you’re on, it sends (as an example) the following information to a twocentstudios.com server:

{
  focusStationPhaseKey: 'focusStationPhase.upcoming',
  focusStation: 'Jiyugaoka',
  laterLaterStation: 'Gakugei-daigaku',
  laterStation: 'Toritsu-daigaku',
  railway: 'Toyoko Line',
  railwayDestinationStation: 'Shibuya',
  railwayHexColor: '#DA0442',
  isReducedAccuracy: false
}

The above information is packaged up without any parsing or logging and forwarded directly to APNS. It has only the information required to populate the first state of the Live Activity that will start on your device. The device address keys for APNS are generated anonymously by the operating system and are also not logged or associated with you in any way.

Only the first set of data must be relayed through APNS in order to start the Live Activity. After the Live Activity successfully starts, it is updated directly on the device without any external server communication.

I hope this superfluous server-based workaround for the ActivityKit API will be eliminated in the future.

If for some reason you want to opt-out of any server-based communication:

Deny background Location Services permissions (please still permit “when in use” Location Services permissions)
Open the app manually each time you’d like to start tracking a journey.

All static data for stations and railways is included when downloading the app and is stored locally on your device. All location-based searching happens locally.

Battery impact

Eki Live is carefully designed to minimize battery impact.

I’m acutely aware that iOS users are extremely protective of battery life, and apps that run in the background are rightfully treated with great suspect.

Eki Live has two states:

idle in the background
tracking a journey

In short, in my testing, Eki Live has the following battery impact:

While idle - an unmeasurably small amount of battery impact.
While actively tracking a journey - about the same battery impact as listening to a song on bluetooth headphones locally in the Music app.

If you’re looking for more detail, I’ll clarify exactly how Eki Live affects battery life below.

While idle in the background, Eki Live uses zero processing power. It may or may not use some resident memory (an attribute managed by the operating system alongside all other backgrounded apps).

When iOS detects your device has moved some hundreds of meters, it will wake up Eki Live for a few seconds to provide location data. Eki Live will quickly check whether your device is moving at train speeds. If it’s not, it goes right back to sleep.

If the device is moving, Eki Live switches into tracking mode.

In tracking mode, Eki Live processes new GPS coordinates up to one coordinate per second while moving, and fewer while stopped at stations. Processing involves a few local SQLite database queries and some math operations. When the app is open, the map is updated as new GPS coordinates are received. When the app is closed, the app will only send updates when the contents of the Live Activity change (e.g. the station phase changes from “soon” to “now”).

The processing work described above still has some room for optimizations, so future releases will include battery life improvements.

Eki Live and ambient computing

Eki Live is an experiment in ambient computing. Ambient computing is technology that blends into the environment and uses context to respond to human behavior without explicit commands. In the case of Eki Live, the app uses iPhone sensors to determine whether it’s on a train and integrate the sensor data with map data to determine which railway you’re on.

My friend Sergio and I were at lunch talking about smartphones and apps several years ago. He said something that, at the time, didn’t totally make sense based on how limited iOS was outside of the app ecosystem. Paraphrasing him: “People don’t want to open apps. I should be able to get 90% of what I need from an app without opening it.”

In the long early years of iOS, push notifications were the only way for an app to escape its bounds and integrate into other parts of the system UI. I was skeptical of Sergio’s sentiment at the time because it felt impossible to achieve. Push notifications are somewhat one-dimensional in what kind of user value you can deliver.

In the more recent era of iOS, there are many more integration points for apps into the system UI: Widgets, Live Activities, App Clips, Shortcuts, Spotlight, etc. Each of these carves out a new niche and bridges the gap between app UI and system UI.

Outside the iOS world, there’s been an influx of consumer hardware experiments that push ambient computing in some way: wearables like the defunct Humane pin; voice assistants like Alexa speakers; and robot vacuums to name a few. Mixed reality wearables may eventually become ubiquitous and escape the app-centered philosophy still core to the OS of the Apple Vision Pro.

All this is to say that Eki Live is my own skeptical experiment into escaping the app-bounds. As an app dev, the easiest delusion to fall into is “people want to open my app”. Eki Live is the first app I’ve tried to design around users getting value from the app without needing to open it or even remember it exists.

The key phrase in that last sentence is “user value”. Showing users exactly what they want before they know they want it is very very hard. And to me, it’s annoying when it’s not right. For example, the “context aware” Widget Stacks built into iOS are hopeless. For all but the most obvious use cases it’s impossible to predict what people want to do with 100% accuracy. The only reason I started working on Eki Live was based on probably having the ability to predict when someone was riding a train and then being able to present the UI automatically in a non-obtrusive way that still provided enough value.

And, from a development perspective, it was not easy to connect all those dots. As of version 1.0, the dots are still somewhat loosely connected (as detailed in the Limitations section above):

The app waking up in the background is limited by the accuracy of the Core Location APIs to quickly report significant location changes.
The app being able to accurately detect your current railway line is based on the accuracy of GPS and the density of other railways in the area.
The amount of information the app can show is limited to the space allotted to Live Activities on the lock screen and Dynamic Island.

If all these parts worked flawlessly, you would always have an indicator of the current/next station inconspicuously located in view. But what is the value in that?

Why do train passengers need to see the current/next station?

Put simply, when riding a train, you need to know what station you’re at so you can decide whether or not to get off the train. By nature, the current/next station information is only relevant for a few minutes at a time, and thus your awareness of it as a rider needs to be continuously updated.

Something I noticed during my alpha testing of Eki Live is that there’s a psychological aspect to needing to know where you are at any given time. This might affect certain people more than others. Whether it’s a nagging feeling of “oh no, did I miss my stop?” or something deeper about being moved through space in a way that humans only began to experience in the last couple hundred years, I still feel it’s difficult to completely give up my awareness as a passenger in a train, car, etc. Although this phenomenon may be real and may drive retention, it’s probably not enough of a top-of-mind motivator for someone want to download the app.

There are a few train native ways to stay updated on the train’s current location or otherwise know when to get off the train (I’ll ignore app-based tools for the moment).

Door-adjacent live-updating signage

Most train cars have a full color LCD or at least dot-matrix screen near the doors that shows the current or next station on the line:

Next station information in an LCD screen above the door on a JR Line car

However:

The screen cycles through several different information sets like all stops, platform maps, delay information, etc., so the exact information you need may be unavailable at the moment you need it (when quickly deciding whether to exit the train before the doors close).
The screen cycles through ~4 languages/scripts, so it may be unreadable to you for short periods.
The screen may not be visible from all standing/sitting positions, especially on crowded trains.
The text on the screen may be too small to read from your position.
Dot-matrix screens are particularly low-information density and hard to parse.

Audio announcements

Announcements for the train’s current location are made over the loudspeakers in each car. They usually include an announcement for:

The next station as soon as the doors close at the current station.
The approaching station within a couple hundred meters.
The current station as the doors are opening.

Depending on the line, these announcements are made consecutively in Japanese and English. They sometimes include a list of the connecting railway lines at a station, which side the doors will open on, a reminder of the rules of riding the train, or non-automated, urgent information about delays or accidents.

Audio announcements are useful, but also have weak points:

Audio announcements are push-based not pull-based (i.e. not on-demand) – you need to pay attention at the right time or always be passively listening.
Audio announcements can be difficult to hear in noisy cars.
Audio announcements are inaudible when listening to music or spoken-word content on headphones.
Non-automated announcements (live from the conductor) can be especially difficult to understand.

Platform signage

When pulling into a station, the station’s name and its one or two adjacent stations are often written in various locations along the platform. Generally, whether or not you can see one of them as a rider is random depending on which train car you’re in, your relationship to a window facing the platform, and whether there are other passengers (on the train or waiting on the platform) blocking your view.

Platform signage on the opposite wall of the platform at Bashamichi station

Timetable

If you somehow have access to the train’s timetable and the train you’re riding stays true to that timetable through your arrival station, you could use your watch to know approximately when to get off the train.

My other train-related app Eki Bright actually facilitates this method once you’ve selected your destination in the app. It shows your arrival time next to the current time as a Live Activity.

Eki Bright's Live Activity showing a 15:11 arrival time at Naka-meguro station after setting up a DIY Route in the app

Any number of popular navigation apps (Google Maps, Apple Maps, Jourdan Norikai Annai) will show you all kinds of information about your journey, both within the app and in other parts of the system via Live Activities, widgets, notifications, etc.

However, the main downside to all of these apps is that you always need to explicitly tell the app that you’ve started a trip, where your destination is, and which specific departed train you’re riding. Or if you just want to see your current location on a map, you need to open the app and wait for the GPS to kick in.

If you’re just taking a quick trip or you’re on a route you know well, it’s usually not worth the hassle to open a navigation app to search for and select your exact itinerary, especially if you’ve already departed.

Where Eki Live shines

Eki Live is especially useful for those everyday, routine rides. You don’t need to remember to open an app. You don’t need to bother selecting a route. It just appears when its relevant and disappears when it’s not. It adds another layer of security and awareness, especially when you’ve got your headphones in and are locked into reading an article or manga, watching a video, scrolling endlessly, or deep in a mobile game. It only needs a few pixels of otherwise unused screen real estate.

Tourists may also find Eki Live useful, but I haven’t explored this use case fully. In theory, having another tool that automatically shows information about what railway line you’re riding could help tourists from getting lost. But especially with Eki Live’s current limitations on underground operation, thinking about another app may be a distraction.

Roadmap

The first thing on the roadmap is to get a general feel for whether this idea connects with people:

Is the value-proposition presented in a way that makes people curious enough to download the app, set it up, and see it working as designed with their own eyes?
Do users start to rely on it enough to complain about its limitations?

This means marketing the app well enough to fill the top of the funnel.

Assuming the above two points check out and the app concept is worth pursuing further, I’ll be working on two concurrent high-level goals:

Improve usability: add more ways for users to customize the app if they so choose - snooze automatic tracking for some period of time; better support manually triggered tracking; add station arrival alarms; show more information in the app about the current railway; show estimated arrival times.
Improve the tracking algorithm: improve the train alighting detection; improve the differentiation between parallel railways; underground railway detection.

I’d also like to incorporate some of the research done for Eki Live into Eki Bright as I originally intended. But that is lower priority until the concept of Eki Live is thoroughly proven or disproven.

Wrap up

I’m really looking forward to receiving feedback from everyone that tries out Eki Live. There are so many unique ways people get around Tokyo. Hopefully Eki Live can find its niche.

Core Image Labo - Open Source iOS App for Core Image Experimentation

Tue, 25 Feb 2025 09:22:00 -0600

I wrote an iOS app called Core Image Labo for experimenting with Core Image filters. It was a “weekend project” in service of a more fully-featured upcoming video-shooting app. I decided to clean it up and release on the App Store and as open source with an MIT license.

Open source on GitHub - Core Image Labo
Available on the App Store - Core Image Labo

Marketing screenshots for Core Image Labo's v1.0 release

You first set up a global input image (or use the default), and optionally a global background/target image (these are used for composite and transition filter types, respectively).

Then you can add any number of CIFilters from the list of supported filters. I was most interested in filters with numerical inputs you could control via sliders, so that’s what I’ve implemented first.

The other input types are slightly more complex (but very much reasonable) to model in UI like CIVector and CGAffineTransform, and I don’t personally need to experiment with any of those filters at the moment, so I’ve held off on implementing support for them for v1.0.

Finally, there are some simple tools for exporting the filtered image you see in the preview and a JSON file containing values for the filters used.

I made an icon using Figma’s vector tools. Lately I’ve been using Blender to make icons in 3D, but I’ve been realizing that 3D-rendered images actually require some de-rendering to make them more illustrative and easier to read in the small pixel format of an app icon. For this side project, it was a lot faster to start from a 2D vector and render with simple shapes and color fills.

Core Image Labo's app icon created in Figma

There are already a few very robust tools for working with Core Image on macOS. Writing code helps me learn though, and it was nice to have my own sandbox to experiment with to (re)learn Core Image. I figured it might be useful to some other devs to have an open source base to work from in case they’re doing something unique that isn’t supported by the other commercial apps.

If you’re a dev working with Core Image, give it a go and contribute a feature or a bug fix if you can.

8-bit Nails - Pixel Art Nail Diary

Mon, 17 Feb 2025 06:22:00 -0600

This week I released 8-bit Nails. It’s a light-hearted app for nail painting enthusiasts to express their creativity through pixel art and document their manicures.

Download it on the App Store.

Marketing screenshots for 8-bit Nails on v1.0 release

After you or a loved one gets their nails done IRL, jump into 8-bit Nails and create a matching set of nails with your own vision in pixel art style. Manicures can be simple or elaborate, and using your creativity to translate them into pixel art style is a fun challenge.

The drawing tools are simple, but there are a few built-in helpers to selectively copy an individual nail across to other nails. You can customize the nail on each hand.

8-bit Nails includes helper tools to eliminate the boring parts of painting

The system color picker is available, and the already used colors are easily accessible as a dynamic palette. And undo and redo functions are available for each nail.

The color picker

After you’ve finished pixel-fying your nails, they appear in the diary tagged with the current date. You can look back to see each of your nails over time.

The main screen shows a diary of your nails with most recent at the top

There’s also a full screen viewer when you want to show off your work in person.

View your nails in full screen

And finally, there’s a special shareable image version with an auto-generated background color. Save this to your camera roll or send it to friends.

An example shareable image

Background

My girlfriend is a nail enthusiast. She gets her nails painted every couple of weeks. I liked seeing what new designs she had and a budding idea came to me of having a painting app to keep track of them. While prototyping, I realized having a full suite of drawing tools and brushes was way too complicated and intimidating. But arbitrarily limiting the drawing resolution created a fun constraint, made it easier to paint on a smartphone-sized touch screen, and ensured that there was a soft-limit on the time it takes to get to the finish line.

I finished a prototype version over a weekend, got it on Test Flight, and sent her an invite before the holidays. Over time, I’ve slightly improved the tools, fixed a few bugs, and added a few nice-to-have helpers. It was fun to see how both her and I interpreted her nails differently in pixel art style. Only after a couple rounds, I think each of us has gotten better at translating the pixel art style. Some of the more complex 3D designs she’s gotten IRL have been especially fun to try to paint in the app.

When I started developing the app, I wasn’t planning on taking it beyond something for the two of us. But as I chipped away at features and slowly noticed how popular manicures were with those around me, I decided it’d be worthwhile to put the finishing touches on the app and release it publicly on the App Store.

There are already a slew of manicure-related apps on the App Store. All fall into the category of games, photos for inspiration, or hyper-realistic painting simulators. Most are targeted towards young girls.

Similarly, there are plenty of pixel art apps. On the casual side, there are paint-by-numbers apps. On the tools side, there are full pixel art suites with layers and other complex tools.

I’m curious to see whether a cross between the two categories will find an audience.

Development

On the technical side, I’m using SwiftUI and no external frameworks. Since my original goal was a personal app, the code reflects that.

Data for all nail sets are saved to one file. The data is saved as matrix of color values and drawn live in a SwiftUI Canvas View. Currently, the canvas is hard-coded to 10x16 pixels, but the code supports any resolution.

I use the system color picker. Undo/redo is implemented as a stack of nail data for each nail in the set. I wanted to experiment with some custom transitions so I didn’t use any sheet or NavigationStack views this time; all views are layered in a ZStack.

If the app starts to get traction, I’m planning on cleaning up the codebase. I realize with my last app Eki Bright I probably leaned a little too hard on the side of a clean codebase. If I want to continue on the indie dev path, I’ll need to keep optimizing for coding practices that facilitate a sustainable business, which means more up-front research, more marketing, more monetization, and more failing fast. All things that spending excess time in the codebase takes away from.

I think it’d be fun to add a widget that shows your latest nails on your home screen. And allow customization of the nail shape. Besides that, I’m going to wait to see what real users are looking for.

Eki Bright - Tokyo Area Train Timetables

Sat, 27 Jul 2024 09:02:00 -0500

My latest app is called Eki Bright or 駅ブライト in Japanese.

Eki Bright app icon

In short, it’s an app for quickly accessing offline station timetables and train timetables for railways in the Tokyo metropolitan area including Kanagawa, Chiba, and Saitama prefectures.

The station timetable screen for Bashamichi station on the Minatomirai Line

In this series of posts I’ll talk about:

This post - the motivation behind the app and the solution I’ve begun to explore
Eki Bright- Developing the App for iOS - the high-level implementation details

Tokyo-area residents can download the app from the App Store.

Eki Bright is currently closed source due to data licensing issues, but I’d like to open source it as some point once I get that aspect figured out.

Background

I’m a public transit (specifically train) fan. And Tokyo is easily one of the best cities in the world to get around by train.

Due to the large market, there are already plenty of full featured transit apps – Google Maps, Apple Maps, Navitime, Jorudan, etc. And I’m a heavy user of all of them, especially Google Maps.

However, after many years of use, I started to find some pain points.

I got to know my daily trips well enough that I no longer needed to know all of the below information for each trip:

Which station I needed to walk to
How long it would take to walk to the station
Which railway I needed to use
Which platform I needed to wait at
Which train type I needed to get on
When the target train type would depart

I’d memorized 1-5, and only needed the departure times in order to optimize my trip.

All of the other information requires opening Google Maps, waiting for it to load, entering a destination, occasionally entering an origin, waiting for the route data to load, scrolling, choosing the top result, scrolling.

Then there were the times that I’d want to check departure times assuming I’d leave in half an hour. In that case I’d also have to manually enter a departure time or manually change the train in the helpful selection dropdown on the route page (surprisingly, a feature still not available on the web app).

Adjusting the exact train within a chosen route is an essential step in using Google Maps' routing

There were also times where I knew more than Google Maps. For example, I know that on weekends, I can sometimes take a local or express train from Bashamichi station to Minatomirai station to catch a limited express train. This little maneuver can save 10-15 minutes into Shibuya. But this information is not easy to access with the Google Maps interface.

Sure, for the most common situation I could head out from my apartment at whatever time was natural then wait on the platform for however long. But if I could see the next departures board at the station before I left my apartment, I could optimize my time better.

Thus, the idea of Eki Bright was born.

Goals

My north star for this app is, like I mentioned above, to have the same information I’d have while standing on the platform looking at the next departures board.

The main principle required for that use case is simple: speed.

Every feature is evaluated against getting the amount of time it takes to see the departure timetable for a station optimized to near zero.

Offline data: no server roundtrip is required to fetch a station timetable, saving seconds on each tap, especially in slow network environments often expected when outside or underground. (The only reason this is even feasible is because trains in Japan are so rarely late.)
Bookmarked stations: the vast majority of trips are taken from the same stations: near home or work or a third place. Letting the user choose these and putting them on the home screen eliminates a step in getting them the information they need.
Nearby stations: for the next minority of trips, the user wants to see timetables for stations nearby their current location. This is trivial with location services (GPS).
Search: as a catch all for the remaining trips, stations can be found by text search (in romaji, hiragana, katakana, or kanji).
Widgets: for bookmarked stations, users can see timetables without even opening the app. The home screen or lock screen makes it trivial to see departure times at a glance.

Nearby and bookmarked stations on the app home screen

Widgets make station timetables available at a glance

My anti-goals – things I specifically did not want to include for fear of overcomplicating the interface and muddying the value proposition – are:

Routing (i.e. inputting an origin and destination and calculating which trains to use)
Covering every city in Japan (or anywhere else in the world)
Covering other modes of public transit (e.g. buses)

Features I feel could potentially fit into the ethos of the app, but aren’t a high-priority:

Showing any information on a map
Live-updating departure times
Platform number information
Stair/elevator locations on the platform in relation to a train car

One feature that wasn’t 100% in line with my north star but turned out to be so useful as to be prioritized for first release: train timetables. Tapping a departure time in the station timetable shows the full path of that particular train as a train timetable. This is useful for two reasons:

Seeing your estimated arrival time at any destination on that line.
Seeing which stations that train stops at, in the case you’re not totally familiar with the local, express, etc. designations for that railway.

train timetables show which stations a particular train will stop at, and at what times

I have many more ideas on how I can make this data alone even more useful to users without further complicating the app.

One example of UX optimization for speed

A conceptually-murky yet concretely defined station in the app usually serves two directions unless it is a terminus.

I made a decision early on for a bookmark to represent the combination of a unique station and a direction. The reasoning being that it’s quite common for a passenger to only ride one direction from a particular station. For example, from my local station Bashamichi, I’m always going inbound into Tokyo from my house and never outbound back towards Motomachi.

It would significantly slow me down if every time I had to select “inbound” or “outbound” each time I wanted to view the timetable for Bashamichi station.

As the designer, I could put both timetables on one screen, however that would crowd the screen with useless (to me the user in my particular scenario) information.

In the case where I do use both directions somewhat equally, it’s perfectly reasonable to have two bookmarks for the same station.

I consider this well designed for the bookmarks use case. But for nearby stations and text search results users still need to select which direction they’re going before the app can display the correct timetable.

My original design presented a station detail screen in this case. It showed no timetable data yet. The user had to select one of two (or one) direction first in order to view the timetable.

This configuration almost immediately felt wrong during use. On one hand, users were less likely to make a mistake and misread the timetable for the opposite direction. On the other hand, it felt so slow having an intermediate step presented in order to see the timetable.

The deprecated Station Detail screen, looking alright but adding time and cognitive overhead

For the first release, I made two revisions to the UX:

I removed the station detail screen. After selecting a search result, the user would now be dropped directly into the timetable for the default direction for that station.
I added a quick swipe between that station’s direction’s timetables. Now users could quickly flip between the two directions with conceptually fewer steps.

Swipe between directions of a station or tap the segmented control at the bottom

Again, optimizing for speed.

I could go further and silently save which direction for any given station the user last viewed. I could also redesign the station detail screen to be more useful to all use cases, whether that be quickly viewing either timetable or just getting metadata about the station of interest. Either way, I don’t want to compromise on the speed of getting a user to the information they’re looking for.

Data

In my prototyping phase I did a dive into potential data sources, both online and offline, paid and free.

In the current self-funding phase of my business, I heavily preferred not paying for data. This keeps my indefinite overhead low and means I have more flexibility in pricing in an already crowded and mature market.

The Association for Open Data of Public Transportation aggregates and publishes data for transit systems across Japan. They also run a hackathon/contest for websites and apps built with their sourced data. This seemed like a reliable enough source for the data at the foundation of the app.

Prototyping

I hacked together a widget that ingested the aggregated timetables for Bashamichi station (my most used station) on a weekday and showing them in a widget.

One of the first widgets I hacked together

The goal at this point was to evaluate how well this implementation solved my hypothetical pain point. I used it for a couple weeks and, yes, I did feel it was a pretty useful supplement to my go-to Google Maps. I could swipe over on my home screen on my way out the door and see whether I need to hustle out to make the next limited express or whether I could take my time.

Productionizing

At this point I had to decide whether to leave this as a scratch-my-own-itch project, or whether it had potential as a full featured app I could offer of the App Store and support indefinitely. This isn’t an easy decision!

In the end, at my level of business knowledge and sophistication, I made this decision from a selfish perspective:

How much did I personally want to use the most ideal version of this app?
How interested were my friends in the concept?
How motivated was I to work on this concept for weeks or months? Could I get it to the finish line?
How capable was I of doing the design on my own?
How much revenue did I need from the app to make it worthwhile?
How many monetizable features could I implement while still committing to simplicity and speed?
What other ideas was I more motivated to work on instead?

Making sense of the data

I was by no means an expert on the intricacies of the vast Tokyo area train network. I’ve done my fair share of rides in the 6 years I’ve lived here, but vast majority of those rides were the same trains going to the same stations, with extracurricular trips being a novelty I quickly forgot the details of.

Learning not only the train system as it exists in the real world, but also as it exists modeled in my chosen dataset was a process. A couple fun concepts I had to wrap my head around:

How to model time, especially across midnight and logical day spans
How to choose a weekday, weekend, Saturday, or holiday schedule
How to internally and externally deal with train directions and destinations
How to deal with the one-off case of the one circle line (Yamanote)
How all these concepts were most naturally expressed in Japanese
How to deal with searching via multiple Japanese character sets
How to generalize train types like local, express, etc. over disparate railways
How to display colors and associate them with railway concepts

A peek into the SQLite database that powers Eki Bright

Internationalization

My initial thought was that it’d be reasonable support both English and Japanese localizations at first release. Especially considering my dataset has pretty good English support.

However, after getting into the details of the design, I realized it’d be a lot more pragmatic to optimize the interface for Japanese at first. Although I’m keen to help the low Japanese-proficiency community in Tokyo, realistically, the vast majority of my users will be comfortable enough with Japanese.

In the next phase I’ll focus on getting internationalization complete on the interface layer of the app, then focus on the data layer. It will require some design thought because a lot of the time even English speakers will want access to both the English and Japanese station name, train type, etc. when out and looking for their train.

Icon

Creating the app icon was the last step for Eki Bright. My intention for much of development was to create an anthropomorphized train character with a happy disposition, similar to the vampire rabbit mascot Count Biki.

Step zero was buying a magazine with lots of various train photos.

Luckily, train enthusiast magazines are not difficult to find in Japan

Step one was sketching some trains, then iterating heavily on character designs.

My somewhat embarrassing sketchbook (blue pen/good sketches are by my friend Kazuyo)

Step two was 3D modeling.

3D design work in progress

Which unfortunately ended up with me throwing in the towel regarding the character and pivoting into a more traditional icon.

The final icon

Although a cute character would be great, I realized it wasn’t a huge loss. Realistically, the app design is extremely utilitarian. A cute character on the book cover wouldn’t really reflect the contents very well.

In the future, assuming a healthy adoption of the app, I’d love to do a full redesign that emphasizes playfulness alongside usefulness and a streamlined UX. At that point, I think it’d be reasonable to revisit the app icon design.

Monetization

Monetization on the App Store is still a mystery box to me. The entire market is relatively mature closing in on two decades on existence.

At first release, I decided not to implement any in-app purchase or subscription at all. My focus up front is testing the market and ironing out the rough edges.

I think there are 3 valid monetization paths (or some combination):

Themes: offer themes for the app and/or widgets that are each unlockable as a one-time purchase.
Subscription: make the app functionality severely limited outside a subscription: no nearby stations, no train timetables, only one bookmark/widget. Charge a low monthly/yearly rate to cover the ongoing development costs and data renewal costs.
One-time purchase: assume prospective users understand the value, and that I can cover my long-term costs by adding new users. The upside is pricing simplicity.

One reason I’m not focused on monetization yet is that I’m not confident I can fill the top of the funnel.

Getting anyone’s attention is often an insurmountable problem, especially when most people already have an okay-ish solution to the problem I’m trying to solve.

Does anyone have space on their phone for another widget or app? Do they want to build new muscle memory and decide to open app A or app B depending on the situation? Is it a daily-use app that justifies an ongoing payment?

Although I implemented tips in raw Store Kit for my last app Count Biki, and it’ll theoretically be less development this time around, it still requires enough work that could be better spent on marketing, especially while the top of the funnel is so small.

All that’s to say that for now I’m going to focus on finding a reliable process to get users into the top of the funnel (the ever-reliable VC startup playbook, haha).

Conclusion

I’m of course happy to see this little app make its way out into the world, and hopefully shave of a few seconds or minutes for train-hopping Tokyo residents. I’m a little biased, but I’ve found myself reaching for Eki Bright before Google Maps for a majority of my trips, even when multiple transfers are involved.

It may simply be a naive sense of control Eki Bright gives me when bouncing around timetables, but regardless it’s surprisingly entertaining (rather than burdensome) to do my own simple route planning on the fly. And knowing I’m getting the absolute fastest trip from A to B.

For developers, see you in the next post for all the fun development details.

twocentstudios

Introducing Eki Bright 2.0

Shinkansen Live - Developing the App for iOS

Contents

Overall development strategy

OCR and parsing the ticket image

Why OCR? Why not multi-modal LLMs?

Overall strategy

OCR prototype

OCR for real Shinkansen ticket images

Using spatial data

Transforms

Levenshtein distance

English and Japanese mode OCR

Unparseable fields fallback UX

Defense-in-depth parsing system

OCR testing system

Live Activities

View guidelines and tips

Use non-semantic font sizes for compact and minimal

For dynamically updating times, prepare to spend a lot of time in trial and error

Clamped width custom Layout

Updating in background

Persisting the trip

Handling dismissal

Animations

Root level transitions

Scanning animation

Ticket image modal animation

Card dragging

AlarmKit

Permission dialog

Localization

Dynamic Type

VisionKit Camera

Project stats

By the numbers

Daily Devlog

Conclusion

Shinkansen Live: Scan Your Ticket, Get a Live Activity

Motivation

Features

Supported input formats

OCR and parsing

Trip in-progress

Live Activity

Arrival alarm

Animations and transitions

Outlook

Comprehensible Later: A Read-it-later App for Language Learners

What is Comprehensible Input

Specification for the prototype app

Implementation

Packages

Data flow

Readability

Demark

AnyLanguageModel

App UI

Share Extension and Action Extension

Import flow

Localization

Impressions so far

What’s next?

Vibe Coding a Rental Apartment Search Management App

The full development process

Day 1

Day 2 & 3

Iteration loop workflow

Final thoughts

Reintroducing Technicolor: Binge Watch with Friends Over Space and Time

How it works

Main features

Navigate your watchlist in the Dashboard

Leave comments in a Room

Start a new show

Friend management

Invites

Limitations

Async-only