Mostly the party was a fun opportunity to gather, make some cheeky jokes at the expense of ourselves and our friends, and lament on the trends we feared would be in…

Here’s my list of trends. Some are personal, some are a little bit of a reflection on society.

OUT: Cellphones in the bedroom

Doomscrolling, distractions – some form of these showed up on many peoples’ lists at the party. My practical version: stop bringing cellphones into the bedroom. Remove the possibility for late night scrolling keeping you up too late, or starting your day with the dread of the state of modern politics.

Practically, this has meant plugging our phones in overnight right outside our bedroom door. We get up, we silence the alarms, and we crawl back into bed for a short snooze. But eventually I do get out of bed earlier than I have been, and my phone isn’t always the first thing I gravitate to anymore, once I am up (but, again, it’s only been a week. Hopefully habits won’t die too hard).

IN: Buying flowers for no reason

You don’t need a reason to tell someone you love them; you love them, and that’s enough of a reason in and of itself. Surely, then, we don’t need a reason to express that love in a physical and tangible way that delights and brightens one’s day and space.

In that regard, I would propose that buying flowers for your partners, your dates, your friends, is IN for 2026. You don’t need a reason, you don’t need a corporate holiday marred by overpriced flowers, you just need love in your heart, and a desire to express it.

As a couple, we buy flowers with some regularity, and this more just a reminder to continue doing that, and to perhaps inspire friends to as well.

OUT: GitHub

2025 saw a lot of tumultuous activity in the United States, for immigrants, minorities, and the under-privileged, at the behest of the latest administration. Spearheading much of the fearmongering and violence is Immigration and Customs Enforcement (ICE). GitHub, acquired by Microsoft in 2018, have had their fair share of controversy alongside their parent company, including partnering with weapons manufacturers. But with the recent role of ICE in the state of affairs in the US, GitHub’s contract with ICE, and the pludering of GPL code for Copilot, it’s time for a change.

This past fall I made the move to sourcehut, migrating all of my projects, deleting the code from GitHub, and leaving directions for visitors to my larger projects. Drew DeVault, the founder of sourcehut, has his quirks, but he’s firm on privacy, and the value of free and open-source software.

Sourcehut may not be the right move for you, but I promise you there’s a tool that suits your needs out there:

• The Zig programming language moved to the non-profit Codeberg
• Tangled offers decentralized git hosting and collaboration
• Fossil is a weird one, focused on simplicity and self-hosting

IN: Women’s Sports

Women’s sports in North America are seeing a boom. The Professional Women’s Hockey League had their inaugural season in 2023-2024, and has since expanded from 6 teams to 8, including the Vancouver Goldeneyes. If hockey’s not your sport, the Northern Super League also kicked off this year, a professional women’s soccer league recognized by the Canadian Soccer Association.

The gameplay is elite, the women are pros, and as the two leagues get their footing, tickets are significantly cheaper than any mens’ leagues in the city.

• This winter check out the Vancouver Goldeneyes at the Pacific Coliseum on the PNE Fairgrounds.
• When the NSL picks back up in April, find the Vancouver Rise in Burnaby at Swangard Stadium

IN: Personal Blogging

Everybody should have a blog. Not a tumblr, not an premium X account with a 10,000 character limit. The Internet has as much breadth as it has depth, and I implore you to share your own

Publish a blog and let me hear your thoughts. Writing pushes you to understand topics better, and has numerous other benefits. Talk about what you love, what you fear. Show me your poetry or impress me with your personal progress.

Here are a couple blogs I follow diligently, and some recent posts from them I found interesting. Download an RSS Reader and follow your favourites:

• the writer’s room shares her writing and thoughts on her daily life. Check out her recent queer cosmic horror short story
• Jenn is a mystery to me, but she writes endearingly about all sorts of things, including tech, culture, and her dead, deadbeat gay dad
• Dead Moms Book Club writes about her life, her grief, her aspirations. Another Mother’s Day presents a vulnerability I felt in my core.

OUT: The Algorithm

Jenny Odell, in How to Do Nothing: Resisting the Attention Economy writes about her Twitter feed:

Scrolling through the feed, I can’t help but wonder: What am I supposed to think of all this? How am I supposed to think of all this? I imagine different parts of my brain lighting up in a pattern that doesn’t make sense, that forecloses any possible understanding. Many things in there seem important, but the sum total is nonsense, and it produces not understanding but a dull and stupefying dread.

The Algorithm is everywhere, and it’s designed to capture your attention to commoditize it and sell it to the highest bidder. It’s an unfortunate symptom of much of the free Internet, that driving engagement drives ad sales and boosts revenue, and revenue is king.

In 2026, we are casting out the Algorithm and instead embracing RSS and mailing lists. RSS allows you to follow all the interesting people, blogs, news, etc. without needing to be exposed regularly to the whims of The Algorithm.

I have a feed of bloggers, indie devs, and friends that I have curated and can check in on once a day to see if there’s anything new or of note to me posted by them recently. RSS allows me to aggregate these sources and peruse them simply, at my leisure, without needing to traverse bookmarks or keep a hundred tabs open.

My RSS reader of choice is IconFactory’s Tapestry for iOS, which also presents me a chronological feed of my Mastodon timeline.

Find creators, writers, comedians, intellectuals elsewhere. I guarantee you they’re posting somewhere outside the walled gardens of social media, where you can follow them on your own terms.

Joan Westenberg writes a little bit more about ditching big tech in favour of the open web, and how the algorithm has transformed how we form opinions.

To a better year

Every year is an opportunity to invite self-reflection, and consider what’s important to us. 2026, for me, is going to be about dedicating time to the things I love that bring me joy, and pulling myself away from the platforms and media that don’t.

Grow UP! is an in-person game jam hosted locally in Vancouver, that partners with local non-profits to bring awareness to their causes through game jams. I first heard about it during Full Indie’s annual summit, and attended their November iteration.

For their November iteration, they partnered with 2 non-profits:

• Our Social Fabric is a non-profit fabric store that sells donated fabrics and fibre arts supplies, helping keep ‘waste’ fabric out of the landfill. They’ll sell to anyone with an interest in sustainable sewing supplies, including the fibre arts and slow-fashion communities.
• SPEC Repair Café is a monthly event hosted by the Society Promoting Environmental Conservation, inviting the public to bring their items in need of repair for free support in mending, repairing, and fixing their items. From bikes, to clothing, to computers, they offer free support in cooperation with the City of Vancouver to help keep waste out of landfills.

An aside: the City of Vancouver has recently cut funding to the SPEC and various sustainability and arts programs by the way of Ken Sim’s ‘Zero means Zero’ budget cratering funding for a wide array of social services, to support a zero-percent property tax increase and a $50 million budget increase for the Vancouver Police Department. Let city councillors know how much this sucks via their website.

A week prior to the event, they announced the theme this time around would be mending, and, to me, that immediately screamed “sewing”. The first night of the event, Friday, was focused on brainstorming and team building. We did a group brainstorming project, where everybody was contributing to an ideas board, what exactly “mending” meant to them. Once there were lots of ideas percolating, people started to group up to begin collaborating.

I proposed an idea based on my understanding that fabric scissors, for cutting fabrics and textiles, are fragile and prone to nicks when used to cut things other than their intended use. What if we had a game where the goal was to carefully cut and sew patches over holes, trying to ensure you didn’t damage your scissors, while moving speedily to complete the repair? This idea eventually evolved to be the basis of Sew Far Sew Good.

I ended up with a team of ~7 in total, including 3 programmers, 2 2D artists, a producer, and an SFX artist. Initially, it sounded a bit like there might be too many cooks, but our devs were either new to gamedev (me) or new to the tooling, meaning we’d be focused on building something fairly small scoped, and hopefully wouldn’t trample on each other’s work too much. Our 2D artists, producer, and SFX artist also found themselves collaborating with multiple teams, or working on their own games on the side, and I think that made for a nice balance, where everybody could find time to contribute to Sew Far Sew Good, and otherwise focus on their own thing.

Overall, the weekend went by quickly, with our team regrouping Saturday morning to kick off game development. By early Saturday, we hadn’t actually fully settled on a game to build… Those of us that arrived earliest started familiarizing ourselves with the tooling of Godot, and just generally working on what we wanted, not fully committed to collaborating. When our producer showed up, they brought up some of the ideas we had had the night before, and suggested we settle on one that seemed approachable, tightly scoped, and fun enough to play. A new Godot project was created, and we were off.

My focus in the game was on the character’s movements. I worked on keyboard controls, as well as programming the animations one of our artists delivered. Looking back, the work was really simple in the end, and the code reflects that. But with it being my first real foray into Godot, it took me most of Saturday to get just a basic character walking animation working!

This screenshot constitutes most of Saturday’s work! As you can see, besides some other variables being set by signals elsewhere in the code, it isn’t very complex at all. But bumbling through this was a fun challenge perfectly sized for my absolutely beginner Godot skills.

The team managed to get a solid demo by Saturday night, and most of Sunday was spent refining, and expanding. We added a couple more shapes to our game, we cleaned up the menus, and I worked on an algorithm to generate sewing points around the patches to randomize the gameplay a little bit.

By the end of Sunday, I’m proud to say, we had a fully playable + complete game! With 3 different shapes, and an overall accuracy report at the end of the game.

Overall, I’m really satisfied with what we accomplished. We managed to scope out a simple game perfectly sized for the weekend and skills that we had as a team. We collaborated effectively, finding things for everybody to do, and helping each other when we got stuck on a tricky bit of code, or tough interaction.

Despite feeling a bit overwhelmed at the start of the weekend, by Sunday I was getting really comfortable with Godot. It’s been an incredible tool, and was so easy to learn thanks to their detailed documentation.

You can play the game here.

Poem 1 (Sakura Award)

cherry petals  
find a home in my hair  
where do I belong?

Poem 2

Six feet underground
Are the cherry blossoms
Still blooming?

Why 5-Pin Bowling?

I started working on the first version of the Bowling Companion (its original name!) in January 2015. I was in my 2nd year of university, and was going to have to start applying to co-op positions for that summer. I was looking for my niche, something that I could build that would be unique, that I had a need for, and that I would be passionate about building. I had been bowling most of my life at that point, and realized that there wasn’t really a good option for 5-Pin Bowling scorekeepers on Android. Actually, I can’t remember if there were any at all! So I set my sights on building the first.

The 5-Pin Bowling Companion: The Java Era

Version One: Functional, but Ugly

I built the first version of the app over the course of about a month. I focused primarily on the functionality – things like data storage, score calculations, and statistics. Back then the Bowling Companion was written in Java, with XML, Views, and SQL. Every screen the app contained was a separate Activity, statistics were collected and calculated in an AsyncTask within the StatsActivity, and the UI was not quite fleshed out…

One thing that was good enough about this first version though? It helped me stand out among other co-op candidates, and I landed my first internship as an Android developer thanks to being one of the only ones with actual Android experience!

Version Two: More Functional, Less Ugly

Once I finished the first version, and had it functional, I made the most logical decision – scrap it and rebuild it from scratch!

I figured at that point, I had learned so much in the past month, from what APIs were available, to how to better structure my code, that I had already built up so much technical debt, and the performance was likely so poor I could easily make major improvements. So I copied the existing code over to a new folder, and created a new Android template from scratch.

Since the app was mostly working the way I wanted it to at this point, I focused on the design. You can see there are some pretty significant changes in the look of the app from v0.1 to v0.2.

Version Three: The Initial Release

Once I had the app looking pretty well how I wanted to, trying out this new “Material” thing Google was toting, I decided that I had, once again, come so far in my learning, it was time to scrap it and start all over once again. This time around, I focused on performance, functionality, and code structure.

I referred to the past implementations a lot, but starting from scratch again allowed me to easily make the changes I needed to, without having to worry about compatibility with what I had already written. Much of the underlying code, like the database, remained the same, but the entire structure of the app changed. I moved from Activities to Fragments, and pulled a lot of the scoring logic out of the activities into utility functions.

This rewrite would eventually become the first version launched, on April 1st, 2015.

Early Lessons from the Early Days

1. Kill your darlings. I wanted to be proud of this, I wanted to share it with a community I was a part of, and I wanted to provide something useful. The first version of the app, while functional, was not a delight to use! Redesigning it on top of the existing code would probably have taken me much longer, and I might not have gotten that first version out for months, with a lot more technical debt.
2. Think about your data model. The biggest mistake I made in these early days was being far too restrictive with the SQL constraints and datatypes. It made refactors difficult, when I better understood how I should be formatting the data and defining relationships. Some features were impossible for a while until I restructured the database! Taking the time to think about your long-term data model, and leaving yourself some wiggle room in the future can be extremely useful, before you lock yourself into something that becomes impossible to build on top of.

Rewriting in Kotlin

In February 2018, not too long after Google announced official support for Kotlin in Android Studio, I decided to rewrite the Bowling Companion in Kotlin. I experimented with the language a bit before diving in, and found that I really liked a lot of its early ergonomics especially when compared with Java. At this point I just recently graduated and was returning to working at Shopify on their native (at the time) Swift app, and I liked that Kotlin reminded me a lot of Swift.

The rewrite would end up taking me about 7 months, starting in February, with the first Kotlin version being released in September 2018. I don’t fully remember the process, but I do remember that I did not do it component-by-component, instead opting to fully rewrite the app from scratch and convert it all at once. Probably not the best idea, especially since up until this point I had never written a single unit test for the app, but it was hardly the app’s first rewrite! But the Bowling Companion has always first and foremost been a playground for me to explore in, and this was just another exploration.

In writing this blog post, I found the first couple commits, which I think are pretty comical – the first commit, a complete deletion of the entire Java source code, and the second commit, a “Hello World!” Kotlin template. Then, in September, the 3.0.0 Release of the Kotlin rewrite.

The months following that release I was plagued with crash reports from BugSnag. Mostly IllegalStateExceptions, but there was quite a variety. I chased those bugs down and fixed what I could. I don’t have a ton of recollection of this time, I’m mostly just looking through GitHub Issues to jog my memory.

Taking a Break

In 2020, I ended up mostly taking a break from working on the Bowling Companion. There were few, if any, bug reports or feature requests coming in, and I had picked up some other projects. I was mostly content with where the app was at. I had removed the ads and Google analytics, as I in my mind I didn’t want there to be any burden to maintain it – the app was completely free and detached, and therefore I offered it as-is. I would work on it when I wanted to, on my own terms.

The last version I ended up releasing of this iteration of the app was 3.2.0, in August 2020, targetting SDK 28.

Approach for iOS

In 2022, I started working on the first version of the Bowling Companion for iOS. Mostly I was looking for a new native iOS Swift project to work on, while I was working with React Native in my job. I had recently learned about The Composable Architecture, had some experience building with SwiftUI, and decided to go all in on both for this app.

With how old the Android app had become at this point, I knew I wanted to match its featureset, but I wouldn’t be using its design for any inspiration. I relied on SwiftUI’s default styling primarily, and built an all new UI for the app. This also gave me a chance to rethink the structure of the app from a UX perspective, moving some content to top-level tabs, but leaving the hierarchical nature of Bowlers > Leagues > Series > Games as the primary way users would interact with the app.

Overall, the Bowling Companion for iOS would take me just under a year to build. It wasn’t until March of 2023 that I settled on the name “Approach”, and the first version of the iOS app would release in September 2023.

Jetpack Compose and building Approach for Android

During the process of building Approach for iOS, Google announced that they would be removing unsupported apps from the Play Store, and any app that wasn’t targeting at least SDK 32 (I think) would become unavailable to new users. Of course, as mentioned above, the Bowling Companion only targeted SDK 28, and quite a bit had happened in the ~4 years since its release.

Some of the major hurdles I encountered when thinking about how to address this were:

• Kotlin, and especially Kotlin’s Coroutines, had undergone a major version update with breaking changes
• Views were no longer the default recommended by Google, and Jetpack Compose was now preferred
• The Charts library I was using, MPAndroidChart had not been updated in some time and was likely abandoned.

Once again, I would lean on my trusty tool, the rewrite. This would now be the SIXTH time I had written the Bowling Companion from scratch, leaning on years of lessons and inspiration, to create what I think is by and far the best version of the app that’s ever existed.

This rewrite ended up taking just over a year to complete, and Approach for Android was first released in September 2024, with feature parity to the iOS app!

Current State of Affairs

As of writing (April 2025), Approach is two native apps, for iOS and Android. Features are generally built in parity, and released in unison!

The iOS app is built with TCA and SwiftUI. It supports iOS 17 and 18. There are 138 modules, including 36 feature modules, 15 repositories, 19 services, and 34 libraries.

The Android app is built with Jetpack Compose, MVVM, and follows Google’s recommended (as of 2025) layered architecture. It supports SDKs 26 and higher, and targets SDK 35. There are 92 modules, including 20 core modules, 36 feature modules, and 36 feature UI modules.

In total, in the repository there have been 3,986 commits to main, averaging just over 1 commit per day! From a clean clone, cloc reports 65,526 lines of Swift across 902 files and 66,347 lines of Kotlin across 901 files. In total, it reports 161,776 lines of “code”, but that includes SVGs, some generated localizations, and some template files.

See you in another 10 years! Maybe I’ll be talking about Kotlin Multiplatform, Skip, or something as of yet unreleased!

Advent of Code

Every year since its inception I’ve participated in Advent of Code, an annual advent calendar of coding challenges that get released throughout the month of December, with the eventual goal of completing each day and saving Christmas.

Challenges are released each night at 12AM Eastern Time, meaning that I get them at a cool 9PM Pacific. Most nights I hope on a call with some friends and we chat about past challenges and when we’ll encounter certain theories or formulas that have been the hardest challenges in past years.

This year, I ended up with a total of 40/50 stars (challenges solved) at the end of December.

Of all the challenges this year, I think the one I had the most fun with was Day 14, simulating the movement of robots, and finding when they arrange themselves in a Christmas tree shape. You can find my code here which was to basically just continue the simulation and search for a bunch of robots lining up in a row. How I actually solved it realtime though was printing every state of the simulation to my terminal and just using Cmd+F to search for an unlikely number of robots in a single row – I think it was ~10 or so, and it took me straight to the state that output the tree! I ended up 324th overall that day, one of my best performances this year.

Hot Chocolate Fest

Every January in Vancouver Hot Chocolate Fest begins. Their website is always a little difficult to navigate, and it’s never easy to find nearby participating cafés with good flavours. So this year I gave myself a fun little challenge – 3 days to build a better app than they had. Here’s the final result.

First, scraping the data. The website is annoying to navigate and, so too, was the data source. I ended up scraping 2 pages – the first for the vendor names and details of the hot chocolates they were selling, and the second for the vendor locations from a custom Google Map.

With the data scraped and cleaned up into convenient JSONs for me to read, I began building an interface. I chose SwiftUI simply because I have familiarity with it, it’s quick for bootstrapping, and I wanted this done fast. I also chose SwiftData for the little data I wanted to store alongside the scraped data. This ended up being a mistake – I’ve never used SwiftData personally, and it wasn’t intuitive to map the data I had to the storage format I wanted/SwiftData expected. In the end, I switched over to Pointfree’s Sharing library, which simplified things a lot.

The end result was a simple little app that listed all the vendors and flavours, with a search by name, or a filter by allergens, as well as a map with details of the vendors and offerings. Unfortunately, Hot Chocolate Fest only lasts 1 month and I started this project halfway into the event. Hopefully I can dust it off next January and use it then!

NaNoWriMo

As I do every year, I attempted to complete NaNoWriMo this November. The goal of NaNoWrimo (National Novel Writing Month) is to write 50,000 words over the course of a month, averaging 1,667 words per day, on one’s way to finishing the first draft of a novel.

I’ve always loved writing, though I generally stick to much more short form writing, but I still aspire to write a novel someday. NaNoWriMo humbles me every year, as I realize just how much of a commitment it is, and, more than that, how hard it is to write something good!

I do enjoy the few writing sessions I get out of it each year though. I generally have some semblance of an idea going in, and then after a few days I lose interest in that idea and move on. I’m still searching for the novel idea that’ll make me want to keep writing.

Approach

Approach is the 5 Pin Bowling app I build for iOS and Android. This month I didn’t spend to much time on it, instead preferring to focus on Advent of Code, but I did finish a few small tasks.

Adding High Series of X Statistics

One of the most useful things about Approach is the statistics it offers, reporting on a variety of aspects about your bowling and you’re improving or where you need to focus your game. These statistics can be charted as a series of points, or accumulated over time to a singular value.

Approach has a system for calculating the statistics, which queries the user’s games, and passes the games to a set of objects which perform calculations based on the properties of the game, and return the final statistic values. This makes it fairly quick and simple to add new statistics into the app.

This month, a user noted that there’s a “High Series of 3” statistic, tracking the highest total series the user has bowled for a series of 3 games. But often leagues are 4 or even more games, and there was no way to measure improvements in those leagues.

Therefore, this month I added a number of statistics for “High Series” of 2 up to 20 games.

Advent of Code

December 1st marks the beginning of Advent of Code, a month-long coding challenge that releases a new puzzle at midnight EST each night, where coders all over the world attempt to parse the puzzle and determine a solution as quickly as possible.

I’ve been doing Advent of Code since it first launched in 2015, and I’ve built up a small library of helpful utilities over those years. However, they’re all written in Python because I used to use Python a lot more back in those days, for work or personal projects. But I rarely write Python at all anymore. In fact, the last time I wrote any Python was actually during last year’s Advent of Code. I’ve found that it leads to me spending too much time remembering the intricacies of Python’s list comprehension, or the syntax and tools of my own library.

This year, I’ve decided to attempt to solve all the days using Swift, my preferred language of choice. I spent some time in November converting my personal CLI tool for running the challenges from Python to Swift, and have also converted a number of my personal utilities over to Swift as well.

I post all my Advent of Code solutions on GitHub, and this year will be no different!

I’ll have more of a write-up on how it goes at the end of the month!

Vancouver Writer’s Fest

This month was Vancouver’s annual Writer’s Fest, and I finally decided to attend some of the events. I always take a look at the festival’s events and am never really in too much of an active writing mood, but this year I decided to make sure I made it more of a priority and to go to at least one event.

In the end, I actually ended up going to 4!

The most useful was, I think, Night Class: A Workshop with UBC School of Creative Writing, where various UBC professors of their creative writing department came to give very condensed lectures and then a short writing prompt. My biggest takeaway from this event was one of the professors (I think it was Whitney French, though I might be misremembering) talked about for her to really get into writing, she had to figure out how her brain worked. For me, I definitely have trouble choosing and focusing on a single task. What works for me when I’m coding is that I let myself pick up and drop tasks very quickly – short, little bursts of intense focus, and then drop it and switch to something new, until I find something that really catches me and I can dedicate time and deep focus to it. Sometimes I have to pick up and drop the same thing multiple times before I can really take off with it. I’ve never applied this style of thinking and working to my writing. I always try to pick one project and see it through for a while before I drop it and never return to it, usually even dropping writing altogether for weeks or months at a time. I’m going to try some different approaches this November to see if I can coax some better writing out of myself this month.

NaNoWriMo

Speaking of November, NaNoWriMo is kicking off next month, an annual challenge to write 50,000 words and finish the first draft of a novel. It’s much less about writing anything of substance, and mostly just about volume – writing and building the habit of writing!

I’ll be doing little to no coding for the next month (if I can keep myself honest…) and I’ll be focused on writing instead.

Approach

Approach is the 5 Pin Bowling app I build for iOS and Android. This month I focused on iOS and data management.

Automatic Backups

Approach for iOS uses GRDB, a framework for working with SQLite from Swift that makes it really simple to query your SQLite DB with strong typing and robust error handling and concurrency. Perfect for Swift.

Unfortunately, one issue I’ve had with GRDB is figuring out how to safely and effectively sync the database to iCloud. Approach doesn’t charge any money or have a premium plan (yet) and I’m not quite willing to front the costs for a fully fledged backend sync, so it’s gone without any sort of cloud syncing up until now. There’s an option for users to export their data to keep it safe, but I’m not sure you can rely on non-technical users to do that (especially the aging demographic of bowlers).

My solution? I eventually realized that SQLite conveniently works out of a single file. All the data is stored there, and we can move or copy that file easily to create a backup! So all I had to do is use GRDB’s built in backup command to copy the database to another file, then I could sync that file to a folder in the user’s iCloud (as long as they’re signed into an Apple account).

Backup syncing will be enabled by default, but users will be able to disable it and delete the files from their iCloud if they can’t spare the room. It’ll backup with some regularity, and we’ll make sure the backups don’t get too stale or take up too much room. That’s all still a work in progress, but coming soon!

Imports from Android

I had a user reach out mid-October and ask why they couldn’t get their data to import correctly from the exported file from their Samsung phone, onto their new iPhone. The reason was that I had never actually built support for this! Let’s understand why this was the case, and how I built support for it.

iOS Data Format

When using GRDB’s automatic encoding and decoding for records, column names end up matching exactly how you define the corresponding variable (for example, a League belongs to a Bowler through the bowlerId foreign key, which is GRDB will write the column name). You can overwrite this default by explicitly defining CodingKeys on a Codable record, but I opted to use the default behaviour.

Another default, enums are encoded as their String representation, so the enum League.ExcludeFromStatistics has two cases, include and exclude and the SQLite values reflect that:

Android Data Format

Approach for Android uses Room, the de facto data storage solution for the platform. It has slightly different defaults.

When defining your models, you can easily override the column names directly inline, otherwise they will match your variable definition. This led me to mix the Kotlin standard camelCase with SQLite standard snake_case names, appropriate for each platform. A League’s bowlerId property in the Kotlin model would be reflected as bowler_id in the SQLite table column:

In Kotlin, enum class values are usually defined in UPPERCASE, and the value stored in SQLite reflects that:

Supporting Imports

With these platform differences in mind (among others), I couldn’t simply swap out the underlying DB file when importing, so I had to take a slightly custom approach.

First, I let the user pick the file from their filesystem. iOS will give you a URL as a result, and I start by copying that file to a temporary location (that I clean up at the end of the process) so the system can’t lock my access or delete it out from underneath me while I’m trying to process the file.

Next, I look at the file extensions and headers and try to determine what sort of file is being imported. When exporting, Approach for iOS uses GRDB’s backup function to cleanly write to a fresh SQLite DB File. Room doesn’t expose this as easily, so instead I zip up the sqlite and sqlite-wal files and give the user a single zip file. That means when importing I need to know if I’m dealing with a SQLite file or a ZIP file and act accordingly. Other files are unsupported and the app will report an error to the user.

Once I have the primary SQLite file, I open it with GRDB and try to perform a few reads to see if I can determine the format. GRDB uses migrations and a grdb_migrations table to track which migrations have been applied. I know that I can import any Approach for iOS file that has no newer migrations than the current app has – any older and GRDB will automatically handle the migration, any newer and the database is in a format we can’t understand. Room uses a hash value to define its DB versions, so I can inspect those.

For any supported iOS DB versions, I just copy the file to Approach for iOS’s DB file location and let GRDB handle the import/migration. For supported Android DB versions, I perform a series of queries and writes to ensure all the data gets copied over correctly. These queries will have to be kept up to date as the database format evolves over time, but that’s a trade-off I was okay with!

Once the DB file has been prepared, we attempt to open it and if it all succeeds, we let the user inspect the app and validate everything imported correctly – there is always an option to revert.

Unfortunately, I didn’t make the cut this year.

Instead, I share my poems with you:

Poem 1

"Your time will come" they say
as if we couldn't be
cherry blossoms in march

Poem 2

Children dying, crying
for mothers. Don't they know
the cherries are blossoming

Hopefully this will be a monthly thing. Lots of development happened this month, so there’s a few things to write about. Expect shorter entries in the future.

Approach

Approach is the app I built for iOS and Android. I spent a lot of this month focused on the Android version, rebuilding a feature that had been cut as part of my rewrite to Jetpack Compose over the past year.

Teams

Originally built in, I think, 2016, as a way for people to record scores for more than 1 person at a time, I opted to cut Teams from the MVP for the 4.0.0 release of the app this past August. Instead, I made it possible to pick multiple bowlers at once from the home screen and start recording scores for them. But the feature was half-baked – users complained they weren’t sure how to see scores for more than one bowler at a time, they made mistakes recording and it was unclear how to go back to previous bowlers, and mostly they just didn’t know the feature existed. Discoverability is hard.

Throughout August and September I completely rewrote the Teams functionality, returning it to its former glory as a top-level Tab in the Overview.

Users can now create teams by selecting any number of bowlers, and record a new league series or tournament for all members of the team simultaneously. Teams also now have their own stats, for all the series the user’s recorded under the series.

Swift 6

For the iOS version of Approach, I made 2 overall improvements. First, I migrated the app fully to Swift 6. Mostly this was made incredibly easy with the work done by the Pointfreeco team and their migration of The Composable Architecture, which the iOS version uses.

Halloween Icons

Finally, as a treat for the iOS users (and a trick for the Android users, who bought phones that don’t support custom icons), I designed 3 new app icons:

Narrow

This season, instead of 5-Pin Bowling, as I usually do, I’ve opted to join a Lawn Bowling league. As a result and mostly as a joke, I’ve started a small Lawn Bowling app I’m calling Narrow. It’ll act partially as an opportunity to learn a bit of SwiftData in an environment where I can play around with it, and it will mostly simply record your ends and keep a record of your games.

So far it consists of just a short list of leagues, and you can create a date entry for a game, and add bowlers’ names to your game. Mostly I’ve been trying to workout how to get SwiftData to best interact with the Composable Architecture, as well as resisting just scrapping SwiftData altogether and returning to GRDB.

For 2024, I’d like to set a new theme: Birds.

Birds have been among my favourite animals for years, and after getting more into photography with my first DSLR in 2018, I’ve wanted to focus my hobby. Loving nature so much, I tried to get out on hikes with my camera whenever possibly, and now I want to explore photography a little differently. So this year I’ll do that by trying to capture some birds!

As any hobby, I want this to be for me first. But I’m looking forward to sharing my photos, learning more about how to identify birds, and building a new personal birding journal.

See you out there 👋