I’ve recently made changes to this site. It was a lot of changes. This post goes through the changes I’ve made. These changes include the software running the site, where the site is hosted, and the domains I’m using.

Blogging Software

The blogging software I previously used was Jekyll. It was nice because I would write the blog posts in Markdown.

I like this because it was free and Jekyll allowed my blog posts to be portable. But this portability added friction to my posting process. This has all been working fine. But I’ve wanted to streamline how I get posts onto the site.

Currently, I will write the post in iA Writer, export the Markdown to a text editor (like Nova or BBEdit), commit the changes to Github, push them up and wait. It’s a bit of a Rube Goldberg Machine.

I almost always make a typo or two during this process and need to push up additional changes.

This process got more complicated on the iPad. I’m not sure if it’s the text editor I’m using there, but I always end up with formatting issues with the post front matter.

I started looking into blogging software that would allow me to streamline things. I like using iA Writer and want to continue to use it. I’ve used Ulysses in the past to write blog posts and could always move back to it.

iA Writer will publish directly to a few blogging services. Those blogging services include Ghost, Medium, Micro.blog, Micropub, and Wordpress. Ulysses also supports Ghost, Medium, Micro.blog, and WordPress.

I looked into Micro.blog, WordPress, Medium, and Ghost.

I wanted to use Micro.blog. I like supporting (more) indie developers. I tried to use it, but I did. I imported all my old posts (once I made modifications), but I wasn’t happy with the themes and didn’t want to modify/create my own.

WordPress is good, but I’ve used it before. I tried setting up a site and had trouble importing the posts. I wasn’t interested in doing everything by hand. I gave up.

I looked into Medium for about a minute. I want to use my blog site with a custom domain and Medium doesn’t currently support custom domains. Medium keeps flipping back on forth on whether they support custom domains. Medium also drives me nuts with the paywalls. Medium looks great and has a great editor. However, the lack of custom domain support is a non-starter for me.

Ghost was interesting to me. I’ve never used it before and wanted to look into it. The Jekyll migration/import process was non-existent. I did find an old script online that created a JSON file to import, but it only included the titles and dates (which was helpful). I then had to go through and paste the post content. It was a pain, but it gave me a chance to update my links. I also got to read through all the old posts again. The editor is the most like Medium’s available, it may be slightly better.

I ended up going with Ghost as the blogging software for the site. The editor is great. I like the themes. Best of all, I can publish (a draft) directly from either iA Writer or Ulysses.

Hosting

I’ve been hosting the site and blog using either Netlify or Github Pages for years.

About a year and a half ago, I moved the site from Github Pages to Netlify. I forget why I moved. There may have been a Jekyll plugin that I wanted to use that Github Pages didn’t support, but I could be wrong.

Once I decided on using Ghost, I had to decide where to host the site. I looked at a few options. Ghost Pro, Do it yourself (DYI) using DigitalOcean and DigitalPress.

Ghost Pro is probably the best option, but it’s pricey. If I want to use the theme I’m currently using (Attila) I would have to go with the Creator plan. I like my site, but I don’t want to pay $25/month for it. That’s steep.

DigitalOcean is a nice way to host sites. It looks easy enough to set up and configure a Ghost site. They have a 1-click install. I’m not sure I want to maintain the server and install updates.

DigitalPress is a service that kept popping up when I was looking for Ghost hosting. They aren’t US-based, but I can live with that. The pricing is much more reasonable. For about $7/month (after the EUR to USD conversion), I get hosting and automatic updates. DigitalOcean was $6/month and I needed to handle the updates myself. DigitalPress even has free hosting options.

I’m currently going with DigitalPress. It was easy to set up and get running. I’ve been using it for about a week, but I have been impressed.

Domain Name

As a part of all this, I’ve switched domains from ryan.grier.co back to www.ryangrier.com.

I started the site/blog out on www.ryangrier.com in 2001. That’s over 20 years ago. It feels nice to get back to using that domain name. I thought ryan.grier.co was clever, but I had to explain to people that it was .co and not .com.

I am now handling the DNS entries through CloudFlair (again). They have a lot of nice features and helped me get the domains all pointing back in the right directions.

In Conclusion

Getting these changes in place was a lot of work. I’m hoping it was all worth it. I think that it will streamline the posting process and allow me to write more posts.

I have a feeling that in a few years I’ll change everything again. Knowing me, I’ll make a change in a few weeks. 🤣

I shipped the first version of Beer Style Guidelines on Jun 26, 2015.

I’ve been supporting the app in an on and off fashion since then. There was a two-year hiatus when I didn’t ship any updates to the app. That’s over seven years of updates and support on an app I’ve never made a dime on.

I think it’s had a pretty good run.

I want to work on other things. I’ve had a handful of other ideas that I’ve put on hold because I wanted to stick with Beer Style Guidelines. I’m not sure I want to do that anymore.

I don’t homebrew beer anymore. I haven’t in years. Life just got in the way and it got hard to carve out the time to make beer.

I currently have two updates in the works.

The first update will re-add all the style guides I’ve added to the app over the years. This will mean Beer Style Guidelines will have seven guides.

I should have this first update out in the next week.

The second update is much larger. I would like to add a macOS app. I’ve wanted to have a macOS app for Beer Style Guidelines for a while. I’m going to add a Mac Catalyst version of the app and get that working nicely.

For now, I think I’m going to see if I can get the macOS update out sometime this Summer. That will likely be the last major update to the app.

I’m not sure if I’ll continue to add new guides each year. I think that will depend how I feel about the app when the new guides come out.

I’ve started looking at my pile of app ideas that I put on hold. I’m thinking of trying out something small. No details yet, but I’m excited to work on something new.

WWDC 2022 was this past week and it was great. I didn’t get to watch enough sessions. There are a ton that I want to watch. I’ll slowly chip away over the next few months.

I’ve been lucky enough to attend Apple’s WWDC in person several times. I’ve been to WWDCs in 2012, 2014, 2015, and 2018. I “won” a ticket in 2019, but we transferred it to a teammate so that he could experience WWDC in-person.

My first WWDC was in 2012 at the Moscone West in San Francisco. I had never been to California before. Everything was new and interesting. The entire trip was amazing and a little overwhelming. I loved every second of it. That same year, I attended Google I/O (also in Moscone West), but WWDC was different.

My last WWDC was in 2018 at the San Jose McEnery Convention Center in San Jose. I liked the WWDC being in San Jose. It gave a new vibe to the conference. Selfishly, I was able to explore a new city experience some new things.

Being at WWDC in-person beats any other experience. There’s a level of focus you’re able to give to the conference and all the amazing tech Apple has announced. You are there to focus on the conference and it’s easier to tune out other things. Flying across the country can be a hassle, but I think that bit of distance helps with the focus.

When I watch WWDC remotely, I don’t get that same level of focus. Things will come up at work and home. Slack dings, dinner needs made, kids need to go to practice, dogs need walked, etc. At home, the list of distractions is pretty long, especially when it’s not essential work.

I say all this as someone who’s been very productive as a fully remote employee for the last six years. I can handle one week a year being in-person with other folks and totally focused on the new Apple tech.

I do enjoy the pre-recorded session videos. They are very well produced and succinct. Sometimes I thought in-person sessions were trying to fill the full time slot allotted. Now, the videos contain exactly what they need to. No less, no more. And they look great.

I think the format for this year’s WWDC may be the future of the conference. Inviting a number of people to Apple Park for some in-person video watching and the rest of the conference being remote.

I’m not sure if I’ll ever get back to take part of WWDC in person. I would love to. But I realize that I’ve been lucky enough to attend a handful of times.

As long as Apple invites people to attend in-person, I’ll keep trying.

This is the final post in a series on adding UIKeyCommands (keyboard shortcuts) to an iOS app. In this post, we’ll cover how to add menu bar items to a macOS Catalyst app using UIKeyCommands.

This will not be a full tutorial on how to add menu items to macOS Catalyst apps. Instead, this post will demonstrate that you can use the same keyboard shortcuts created in part two and create menu items.

In macOS Catalyst apps, your UIApplicationDelegate class (usually AppDelegate) will configure the menu bar. This is handled in the func buildMenu(with builder: UIMenuBuilder) method (documentation). In this method, you can add and remove menu items and sub menu items.

You can download the corresponding sample app here (the branch is part-3-catalyst). I slightly refactored the code that creates the UIKeyCommand to be a class level variable on the two view controllers. They can now be easily accessed like: TableViewController.showTableAlert.

Use the existing UIKeyCommand objects in a UIMenu initializer and then added to the builder object in the buildMenu method (from above) like this:

    let menu = UIMenu(title: "Show",
                      identifier: .show,
                      options: .displayInline,
                      children: [TableViewController.showTableAlert,
                                 DetailViewController.showDetailAlert])
                                 
    builder.insertChild(menu, atStartOfMenu: .file)
    

This little block of code adds the “Show Table” and “Show Detail” menu items. When you run the app, it will look like this.

Resulting menu

That’s it. That’s really all there is to it to take existing keyboard shortcuts and add them to a macOS Catalyst app as menu items.

UIKeyCommand object are incredibly versatile in the situations we’ve gone over in this series. They can be added to both simple and more complex apps. They can also be used in macOS Catalyst apps to provide menu bar items.

Other Posts in the Series

Part 1 • Part 2

In the first post in this UIKeyCommands series, we went over the basics of UIKeyCommands and adding keyboard shortcuts to an app. Adding keyboard shortcuts to a real app can be a little more complicated, but not much.

First, some background

My latest update of Beer Style Guidelines has these keyboard shortcuts reenabled. A long time ago, I had keyboard shortcuts enabled within the app. At that time, I didn’t have a clear understanding of how they worked. This lack of understanding meant that the keyboard shortcuts didn’t quite work the way I expected them to (or at all sometimes).

I became frustrated with my lack of understanding and I just disabled the keyboard shortcuts. I didn’t have a lot of time to investigate and figure out what was wrong. But I was determined to figure it out. Recently, I had purchased an iPad Air (4th Generation) and an Apple Magic Keyboard. This gave me the kick in the butt to get the keyboard shortcuts working again.

Getting the keyboard shortcuts working wasn’t a lot of work. I just lacked an understanding of how to put it all together. I hope to impart some of that wisdom in this post.

Beer Style Guidelines has a Split View Controller view architecture.

Split View Controller Wireframe

In my first iteration of keyboard shortcuts, I had two or three commands. They were all triggered from the Detail View Controller (the large part of the screen). I wanted to add more keyboard shortcuts, but I was paralyzed with not knowing how to proceed.

Ok. So, what was holding me up? I wasn’t sure which view controller in the app I needed to implement the keyboard command. Did I need to add them all to my Split View Controller class? Did I need to implement the commands in one view controller or the other, based on a user’s focus?

I started by adding the commands to the split view controller class. But it turns out that isn’t the correct answer. The correct answer is that you implement the keyboard commands wherever you need them, and let the Responder Chain take care of the rest.

Responder Chain? What?

In iOS, there is this thing called the responder chain. The responder chain is how iOS (and UIKit) determine how to handle events. This chain starts with the first responder and then traverses the rest of the chain looking to handle the event. In the case of UIKeyCommands, UIKit will traverse the responder chain and collect the UIKeyCommands for the current scenario.

This WWDC video (Support hardware keyboards in your app) does a fantastic job of explaining all of this. It’s also super short. I only discovered the video after I figured out how this works.

You may have noticed that the UIApplicationDelegate class (usually called AppDelegate) is a subclass of UIResponder. What you may not have noticed is that all UIViewControllers and even UIViews subclass UIResponder.

Back to UIKeyCommand

Getting back to where to implement the keyboard shortcuts. I ended up implementing the keyboard shortcuts for the list view (search, change guide, etc), in the list view controller. The keyboard shortcuts used in the detail view controller (like toggle favorite, next/previous section, etc) were implemented there.

Like in part one, I’ve created a sample app to put this into practice. This sample app uses a Split View Controller and implements keyboard shortcuts where it makes sense. The sample app only has a few keyboard shortcuts.

The list view controller has two keyboard shortcuts and so does the detail view controller.

You may notice something strange about these keyboard shortcuts. Both have the “Show Info” keyboard shortcut. I did this as a test more than anything. I wanted to see what would happen if there are duplicate keyboard shortcuts. Likewise, I also wanted to see where this was called from when triggered. I discovered that found that the keyboard shortcut in the detail view controller usually wins. I think that’s because it’s the first responder in the chain that responds to this command.

This may feel a bit overwhelming. But it’s not very difficult. The sample app should give you a better idea of how easy it is to implement keyboard shortcuts in a split view controller.

There’s one more post in this series. Next time, we’ll stray away from iOS slightly to use UIKeyCommands to add menu items to a macOS Catalyst app.

Other Posts in the Series

Part 1 • Part 3