This is my first post in a series of hopefully somewhat frequent blog posts on programming, Swift, Japan, iOS app development, server-side development, and other topics.

Self Intro

First, a self-introduction. I’m an expatriate from the US living and working in Tokyo as an iOS developer. I work on a common kind of iOS app that involves a lot of dressing up JSON and making it look nice. I like languages like Japanese, Swift, and Go.

My background is actually completely unrelated to computer science and development. Rather, my focus in college was Japanese studies. Because I was a humanities major, I have confidence in my writing skills. I think the divide between humanities and math/science is artificial and people aren’t often completely suited for just one over the other. Also, I believe that Japanese is a lot more complicated than Swift or any other programming langauge. Programming languages are artificial, written-only, made to serve a specific range of purposes, used by fewer people than many human languages, and haven’t been around as long as human languages. Conversely, human languages have rapidly changed over long periods of time and are (mis)used in a variety of crazy and unexpected ways that exceeds the diversity of programs out there.

Goals for 2020

Areas to Study

I plan on studying a few main areas, some of which I have some experience already, and some of which I have very little.

SwiftUI and Combine

These are priority number one for me. SwiftUI is the future for iOS development. Also, the app I work on professionally will be able to use SwiftUI as soon as the end of this year (which involves cutting off support for iOS 12).

Some think it’s too early to study SwiftUI because it will have many changes. While I agree that it might not be necessary to study it as quickly as possible, I believe that the earlier I start learning deeply how to use SwiftUI, the more time I’ll be able to acrue using it, becoming comparatively more experienced. The more experience I have with SwiftUI, the better I’ll be at it.

I actually started studying SwiftUI and Combine last year at WWDC, making two half-finished apps. This year, I plan on finishing at least one of those apps and making a another one or two, possibly for the iPad. I hope the overall APIs and naming for SwiftUI stays the same for the next few years, while the number of features increases and the bugginess is fixed…

REST and GraphQL APIs with Rails and Go

I’ve always been very interested in networking, this year rewriting the network layer in my work’s app, getting rid of Alamofire and implemented client-side OAuth authentication from scratch with retrying, refreshing, and a cancellation API. I would like to work more on caching as well, and URLSession has some useful-looking APIs for this. Now that I finished, I really feel like client-side API work is ripe for abstraction, and that’s where GraphQL seems ideal.

I’ll need some tools to make server-side APIs, and Ruby on Rails and Go are the ones I’ve chosen to learn first. I don’t love Ruby or Rails (because of the lack of type-safety and the tight coupling with databases). I’ll put that out there. That said, Ruby on Rails is an easy and efficient way to get more into backend development and it’s the most actively used language and framework used for web development at my workplace.

I really like Go. It’s type-safe and compiled, but /really/ fast to build. People normally don’t use large frameworks with Go, instead picking and choosing the right packages and architecture for their application (often split up into different packages and microservices). Go helps balance out my natural instinct to explore a bunch of ways of implementing a feature, trying to find the way that’s just right. Instead, Go eschews complex language features, and Go developers prefer their code to be simple and a little repetitive rather than clever and beautiful.


Like any other year, I have a lot to learn. Being a Senior Engineer, I realize how much I just don’t know yet, and how far I have to go.