It seems that making a good Mac app is a bit of a lost art (even Apple seem to be struggling). Given that, I’d like to highlight some of the apps that actually get it right. These are all proper, native apps— not Chromium instances in a trench coat.
I have no financial association with any of these apps— no sponsorships, no affiliate links. Just some genuine recommendations for apps that I find useful.
In 2016, the FBI asked Apple to create a backdoor that would allow access to an iPhone belonging to a perpetrator of the San Bernardino terrorist attack. Apple, famously, refused.
We have great respect for the professionals at the FBI, and we believe their intentions are good. Up to this point, we have done everything that is both within our power and within the law to help them. But now the U.S. government has asked us for something we simply do not have, and something we consider too dangerous to create. They have asked us to build a backdoor to the iPhone.
Specifically, the FBI wants us to make a new version of the iPhone operating system, circumventing several important security features, and install it on an iPhone recovered during the investigation. In the wrong hands, this software— which does not exist today— would have the potential to unlock any iPhone in someone’s physical possession.
The FBI may use different words to describe this tool, but make no mistake: Building a version of iOS that bypasses security in this way would undeniably create a backdoor. And while the government may argue that its use would be limited to this case, there is no way to guarantee such control.
This open letter embodies a type of corporate courage that is rarely seen. Apple took a stand to meaningfully guard the security and privacy of its customers.
Recently, Apple announced changes that will be included in this fall’s OS updates aimed at combating the spread of Child Sexual Abuse Material (CSAM). I suggest reading the whole announcement, titled “Child Safety,” yourself. In the announcement, Apple outlines their three-pronged approach:
“How did we get here?” has been a recurring thought for me as I watch current events in American politics unfold. The political polarization in the country is as bad as it’s been in recent memory, and things feel like they’re accelerating more than slowing down. It seems as though the only thing that people can generally agree on is just how divided we are.
So, how did we get here?
It’d be absurd to claim that our current disfunction stems from just one cause, but I do think that the changes in how we communicate with each other have been a major contributing factor. I’m talking about social media, of course, as cliché a subject as that may be. I’ve thought a lot about just how toxic politics usually are on social media, where tribalism is rampant and anger is the default emotion.
I’d like to share a hypothesis on why politics on social media are so toxic. Not an answer or a solution, just some of my thoughts.
Whenever I am setting up my development environment on a fresh macOS install, one of the first things I need to do is configure Git to work with my GitHub account. Looking up all the steps required to do so continues to be an absolute pain each time. I’m writing this post to collect this information in one place, and publishing it in the hopes that someone else may find this useful.
This guide will cover the following aspects:
Update: GitHub CLI now supports authentication with gh auth login, which I would recommend using instead of the below instructions.
First, you’ll need to configure your name and email address in Git. If you’ve enabled the GitHub setting to keep your email address private, make sure to use your @users.noreply.github.com address here. I prefer to configure these settings globally, but you can also do this on a per-repository basis (omit the --global flag).
git config --global user.name "Your Name"
git config --global user.email you@example.com
When you try to push to a GitHub repository or clone a private repo, Git will prompt you for your credentials. If you aren’t using two factor authentication, then you can enter your GitHub username and password as usual. If you are using 2FA (you probably should be), then you’ll need to generate a personal access token.
One of macOS Catalina’s multiple contributions to improving the security of the Mac is a change to the way that screen recording works. The system now requires that the user give applications permission to record their screen, similar to how applications must request webcam or microphone access.
I’m glad that this is being addressed. Allowing applications unrestricted access to the contents of your screen is both a privacy concern and a security risk, yet apps previously required neither the user’s approval nor their knowledge. The change in Catalina is a good idea… in theory. In practice, the implementation is a complete mess, and a source of headaches for developers.
The first problem is documentation— or rather, lack thereof. As far as I can tell, the only official developer documentation for this security feature is this segment of the “Advances in macOS Security” WWDC panel. The WWDC video library is nice to have, but it’s not a suitable replacement for comprehensive documentation.
Recently, I've been learning SwiftUI. I like it a lot, but the current documentation leaves a lot to be desired. One particular place where the documentation is lacking is for the style modifiers for controls, such as BorderlessButtonStyle.
Button(action: {}) { Text("Click Me") }
.buttonStyle(BorderlessButtonStyle())The issue here is that the documentation doesn't show any images of what the various control styles actually look like when they are displayed on screen. This led to a lot of trial and error when I was trying to build interfaces that looked a specific way. So, I've gathered screenshots of what each style looks like on macOS.
Following the macOS Mojave release last year, which introduced dark mode to the Mac, iOS 13 will include its own system-wide dark mode feature when it launches this fall. This was of great importance to iOS app developers, many of who will be updating their apps to support dark mode. But I think there's something that's being left out, and that's the web.
Anyone who uses dark mode can testify as to how jarring it is to come across an application that only supports a bright color scheme. It's especially blinding in low-light environments where dark mode is often used. The same applies to webpages.
To avoid this visual clash, websites should start including a dark color scheme, just like native applications are doing— especially with how much the gap between the two has shrunk. I think this is a substantial user experience improvement for those who have dark mode enabled.
For this website, I decided to use the static site generator Eleventy. There’s a lot to like about Eleventy, such as its support for a variety of templating formats. I’m using mostly EJS for the page structure and Markdown for written content.
I was finding that Eleventy wasn’t robust enough to handle assets like stylesheets the way I wanted, so to resolve this I decided to use gulp.js. The main task compiles and minifies my SASS files and minifies any JavaScript files as well.
One of the nice features of Eleventy is a built-in server which automatically updates whenever template files change. It makes local development a lot easier. I wrote a corresponding gulp task so that any asset files are also rebuilt whenever they are edited.
Finally, to make everything work well together, I have the following scripts defined in my project.json file.
"start": "gulp && (eleventy --serve & gulp watch)"
"build": "gulp && eleventy"