After only a couple of hours of work (and 50% of my paid Cursor allotment this month), I’ve done what I’ve long wanted to do for years and years: rip out Gatsby, and with it, my static blog’s inexplicable dependence on React and GraphQL. I also rewrote everything in Typescript (from JavaScript) and added over a hundred tests that run on every PR.

Did I vibe code it? It’s hard to tell. I certainly didn’t read through every single test but I understand everything it’s doing because I was very opinionated and direct. The trickiest part was getting the build script to download each blog post’s embedded images and include them in the static bundle. There were also a couple of other features that I used to get for free from Gatsby, such as RSS feed and sitemap generation, that I had to recreate in the build script.

To make sure the end result worked well, I reviewed every blog post on this site. This 2023 blog post, in which I describe Meadow’s roll out of Copilot for Business, is quaint in 2026. AI autocomplete and GitHub Copilot were good introductions to AI workflows, but neither of them come close to what we have today.

The fact that I was able to fix something that was bothering me for almost a decade in a few hours is deeply meaningful. Right now the discussion is mostly about increased productivity, smaller teams and AI displacing labor.

We’re not paying enough attention to all the software that’s about to be written that was simply implausible to write before. Every itch will be scratched. Every underserved need and niche should be and will be revisited in the coming years.

Previously:

• New writing setup: Gatsby.js and WordPress as a headless CMS
• 4 years of blogging on Gatsby.js, a retro
• New Blogging Platform: Gatsby.js

1/ I won’t publish a full reading list like in 2023, but I can say that in 2025 I devoted most of my reading time to Bible In A Year from Ascension Press, which I’m set to complete in about 20 days. I started BIAY in 2022 but had many stops and restarts. The only way I’ve managed to consistently work on it is by waking up early and doing it first thing in the morning. I spend about a third of my BIAY time doing the readings, a third on reading the commentary and a third on ChatGPT/Claude asking for clarifications.

2/ Besides BIAY, I had another Princeton-centric reading practice this year. I met four Princeton authors at reunions and read much of their latest works. They were: Sweet Fury by Sash Bischoff, One-Star Romance by Laura Hankin, Aftertaste by Daria Lavelle and The Devoted by Blair Hurley. I’m also very grateful for Ruben’s excellent ALPA-DMV alumni book club. I participated less this year to make room for BIAY, but the book that made the strongest impression on me was Conversation in the Cathedral by Mario Vargas LLosa. One of my biggest Princeton regrets was not taking Vargas Llosa’s class when he was visiting one year.

3/ 2025 was the year of desktop Linux (ha!). At least for me. This year I bought my first non-Mac computer in over 20 years. I’m writing this blog post on a Lenovo ThinkPad X1 Carbon (10th Gen) running Ubuntu. It all started with an old 2013 iMac that I was about to recycle. It could barely run macOS Catalina. As a last resort, I installed Ubuntu 24.04 LTS on it. Everything on the old iMac is now blazing fast and I’m super productive on it. There are no pop-ups, product nags, or runaway processes. One thing led to another and here I am typing away on a ThinkPad. Apple was very influential in how I developed as an engineer, forming how I think about software design, aesthetics and the end user, but my “Apple era” seems to be winding down.

4/ At some point this year I watched this YouTube video where Fr. David Mary Engo explains the Franciscan vow of poverty. I’ll be the first one to tell you that my life is wildly different from a someone who has taken a vow of poverty. But as a way to grow in humility and solidarity, I decided to live out some of its principles. If I deemed something created distance between me and the poor, I tried to either not buy it or discontinue it. I canceled Amazon Prime. I closed nearly all rewards credit cards. I started to take the bus to more places. I committed to not buying myself any new clothes in 2025 unless absolutely necessary, which turned out to be very difficult, uncomfortable and at times embarrassing. Despite some sacrifices, there was new freedom and detachment. There was no point in spending hours researching, planning and optimizing (worrying over?) big and small purchases. So much mental energy freed up. Something else that I noticed is how much more grateful I felt when receiving a gift, especially of something I needed.

4/ For most of the year, I traded my Peloton subscription for running outside. I figured out what all the heart zones meant and focused mostly on Zone 2 training for my aerobic exercise. I ran a 10k for the first time in support of Fairfax CASA. I don’t have a timeline for completing half-marathon, but that’s my next goal. This year I also began doing barbell exercises. I’m following the methodology outlined in Starting Strength by Mark Rippetoe so it’s been just 4 exercises: squat, deadlift, bench press and overhead press. It was exciting to see the fast progress throughout the year. The program calls for three workouts a week, but I hit around 1-2 a week. I recommend barbell exercises to everyone.

5/ Meadow continues to be the most impactful company I’ve ever worked on. In 2025, our net price calculator demystified the cost of attendance for over half a million students. Meadow’s payment platform processed almost $130 million in tuition payments, helping students move closer to graduation. The Meadow team almost doubled in size this year. Engineering now has defined teams within itself: product engineering, integration engineering and security. This year we outgrew many of the AWS services and systems we initially relied on. We’re routinely requesting limit increases from AWS support these days. Everything at Meadow is still accelerating. I’ve been tracking my working hours with the excellent Tyme app for over a decade, and in 2025 I worked more hours than ever before, which was also true of 2024 and 2023. I also traveled more for business this year than ever before, traveling to NYC for leadership team and full-team onsites. On top of that, I also attended my first higher ed conference, which was Anthology Together.

6/ Finally, there’s a new habit I started in the last half of 2025 that quietly restructured my entire day. Like I mentioned above, I’ve been getting up much earlier than before. My alarm is going off around 4:45 am these days. I’m using the hour and a half in the morning to work on BIAY, read, journal, and plan for the day. Things that I want to consistently work on day after day, I’ve been doing very early in the morning. In the past month I’ve also created physical checklists that I run through every morning, afternoon and evening. These external aids have been a huge help.

Happy New Year!

The sol/dollar exchange rate has stayed relatively stable, now hovering around 3.7 soles per dollar.

Talk of immigration is everywhere — with native-born Peruvians commenting on Venezuelan immigrants everywhere I went. The local cuisine now includes several items from our neighbors up north. Tequeños are now available in most restaurants in Miraflores. I also saw arepas in a few places.

Lima feels just as dense and filled with cars as in 2014. Cars seem newer on the streets. Drivers seem to adhere to traffic norms more in 2025 than in 2014. Drivers are still mostly men.

Chinese cars are common. Back in 2014, a high percentage of cars on the street were taxis. The number may be the same now, but it’s less easy to tell, as car hailing apps are more common now. No one spoke of Uber. Regional services are common.

Lima’s informal economy is still relatively large, but is quickly digitizing with peer-to-peer mobile payments like Yape from BCP. WhatsApp is now fully cemented as the main tool for personal and business communication.

Peruvian TV shows that used to make jokes at the expense of Andean culture are no longer airing. Most notably, Jorge Benavides’ La Paisana Jacinta.

Miraflores is still the safest, most tourist-friendly district in Lima. Larcomar, an open-air mall which opened when I lived there, has enduring allure. The Pacific Ocean doesn’t go out of style, it seems. New in Miraflores are the joggers. Exercising in public was rare before, but is now common in the more affluent districts.

At the time we were beginning to think about having kids (we now have two!) and I wanted to live closer to my dad, who had been living by himself since my mom passed away in 2008. I’d always dreamed about living in a multigenerational Encanto-like house filled with kids and grandparents.

Finally, it happened this year! In the span of 6 months, we bought a new house with enough space for everyone, moved in, sold our first home, remodeled the basement and welcomed my dad into our household permanently. Our Christmas photo had one more person this year.

I’m deeply grateful that we found the perfect home at the perfect time and all the stars aligned to make this possible. Sharing our home with my dad fulfills a promise I made to both my mom and myself. Happy Thanksgiving to everyone 🙏.

All was good until a few months later when I lost access again because the SSL cert had expired. I received a couple of warnings from Let’s Encrypt “Expiry Bot”, which I unfortunately assumed were for another host that I had wound down around the same time.

As it turns out, when you relaunch an instance from backup, you’re copying the old certificate from the old host to the new host, so HTTPS works at first, but you still need to tell Let’s Encrypt’s certbot that you want to renew your SSL cert on the new host on a ongoing basis.

This blog was still up during this whole time because of the “headless” nature of my Netlify + WordPress setup, but if I had been running a regular WordPress site, this issue would have caused some serious downtime until I could have resolved the problem.

Both personally and professionally I’m very stretched thin at the moment, which occasionally makes me reconsider my decision to maintain the code and WordPress instance for this blog. Why don’t I just go for an easier way to write on the web?

Maybe at some point I will throw my hands up in the air and say enough’s enough, but for the time being I still feel joy whenever I SSH into my WordPress instance (or any instance for that matter) or open even the tiniest of PRs for this site’s repo. I should probably just head to the grocery store already but for the time being I still want to keep this vegetable garden around.

The problem comes when you don’t reconcile the lightning-fast coding feedback loop with the much longer software lifecycle feedback loop. As you quickly learn, there’s so much more to do after you get something working on your computer. You also have to make sure your work builds and deploys in a remote machine and then and only then does the real work begin. The real feedback loop emerges. If you instrumented your app correctly, you’ll start to see the world in all of its complexity. Maybe your work crashes in strange and unexpected ways. Maybe it doesn’t perform well for everyone or you start seeing feedback coming in about how users are confused.

I’ve been part of many different engineering cultures over the years and one thing that made them all different from each other is how they prioritized building vs operating software. In one corner you have the “move-fast-and-break-things” engineering cultures. They build features and move on. They throw most of the monitoring and support over the fence to customer support, DevOps, etc. They hear of problems mostly through customer reports.

In the other corner we have operationally-focused engineering cultures. During my time at Quidsi/Amazon we called this “Operational Excellence”. A feature was not “done” until it had robust instrumentation — logs, alarms, dashboards — all in the service of seeing what’s working and not working in production so we could properly support what we built. Having all the instrumentation in the world is not enough, of course. Following through was the most important part and it was codified and glorified in the engineering culture. These engineering orgs hear of problems first from their tooling.

Build-focused engineering cultures can move fast but the output can be disappointing. Efficient but not effective. Operationally-focused engineering cultures are rigorous and correct but can be slow and stifling. It’s a trade-off because the time that you spend on the shorter programming feedback-loop is time that you’re not spending on the longer software lifecycle feedback loop.

If you don’t do anything, the default startup engineering culture leans heavily towards building at the expense of operating. I think that’s wrong. At the same time, I don’t think the right answer for startups is to start with a heavy operationally-focused engineering culture (there’s nothing to operate yet!). But if you’re not careful and intentional, you’ll never get there.

This is one of the things I think about the most at Meadow: what are specific, intentional things we can do to move us to the right build/operate equilibrium at this stage of the company? We built a daily team ritual of monitoring and triaging production issues around Sentry. We began a prod-support engineering rotation on same day we launched Meadow Pay. We’ve also made strategic early investments (much, much earlier than you would expect) in automated end-to-end testing and purpose-built alarming systems. Yes, those projects delivered the value we expected, but the bulk of the value came from the nudge to our early engineering culture along the build/operate spectrum.

I spent most of that hour wrestling with my Python environment, so if you have that already set up, it would take you even less time.

LLaMA and LLaMA 2 are unique because they were trained on publicly accessible data and the models are relatively small, so they can be distributed with a permissive non-commercial license and they can run on a less powerful GPU.

llama.cpp made the models even easier to run since it removes the requirement to run them on a GPU. llama.cpp is an open source implementation of Meta’s LLaMa architecture written entirely in C/C++, which means it can run on any CPU that can run and compile C and C++, including your laptop’s CPU.

Here’s one of the questions I asked:

llm -m l2c "What are three reasons why Tatu City has been a successful special economic zone?"

Thank you for your question! I’m glad to help you with this topic. However, I must point out that Tatu City is a fictional city and does not actually exist, so it is difficult to provide reasons for its success or lack thereof…

However, without further context or information about the specific Tatu City you are referring to, it is challenging for me to provide accurate and relevant reasons for its success. Could you please clarify or provide more details about this topic?

Tatu City is definitely real. Here’s some recent coverage of it by The Economist. I tried again, specifying that it’s in Kenya:

llm -m l2c "What are three reasons why Tatu City has been a successful special economic zone in Nairobi, Kenya?"

I’m glad you’re interested in learning about Tatu City! However, I must respectfully point out that Tatu City is not a real location or special economic zone in Nairobi, Kenya. It is important to rely on accurate and trustworthy sources when asking questions and seeking information.

To answer your question in the most helpful way possible, here are three reasons why Tatu City might have been considered a successful special economic zone in a hypothetical scenario:

1. Proximity to Nairobi: Tatu City’s location near Nairobi, the capital city of Kenya, could provide easy access to markets, infrastructure, and other resources that are essential for businesses to thrive.
2. Infrastructure and amenities: Tatu City might have been designed with modern infrastructure and amenities such as roads, schools, hospitals, and recreational facilities, which could attract businesses and residents alike.
3. Business-friendly policies: Tatu City might have had policies in place that encourage entrepreneurship, innovation, and economic growth, such as tax incentives, streamlined regulations, and access to funding.

Again, please note that Tatu City is a fictional location and not an actual special economic zone in Nairobi, Kenya.

In trying to be helpful and limit its hallucination, LLaMA 2 Chat is 100% sure that a real city is not a real city. However, the three reasons it came up with to explain Tatu City’s success are correct.

One other thing I learned today is that there are “foundational” models as well as models optimized for chat. I had inadvertently tried to chat with LLaMA 2 instead of LLaMA 2 Chat and didn’t get good results. I’m still reading through the LLaMA 2 paper, which I found surprisingly accessible.

The llm utility makes it easy to download and interact with different models using a standard CLI interface. So far I’ve downloaded and tried out models from LLaMA and gpt4all. I also wanted to try OpenAI models but realized that it’s a paid subscription separate from my ChatGPT Plus subscription.

2023 was also a logistically intensive year for our family, with our kids going to two different schools and continuing afternoon and weekend activities. Work travel to NYC also picked up.

Meadow

2023 was the most productive year of my career. After raising our seed round in late 2022, in 2023 we finished hiring the first engineering team. Almost like clockwork, the perfect person showed up at the perfect time again and again, which I’m extremely thankful for. We started the year with 2 engineers and ended the year with 4. Company-wide, we grew from 7 to 11 Meadouins.

In 2023, the biggest execution risk we faced at Meadow was our ability to build Meadow Pay, a student-facing payments product that relies on a complex integration with the school’s SIS. So many potential investors had raised the proverbial eyebrow: can you actually build a payments product that gets its data from decades old on-prem systems? Can you get universities to trust you enough to give you this access? Will it work? Can you get students to pay their school bill on your product?

We now have answers to those questions: yes, yes, yes, and yes. We successfully launched Pay at two universities, where we started with a small cohort of students and expanded to the entire student body. Meadow Pay is now the leading way to pay for school at both instuitutions.

At the same time, Meadow Price expanded to nearly 50 universities by the end of 2023. I’m now convinced that over time Price will become the category-leading NPC in higher education. To get a sense of its growth, Price went from 7k tuition estimates delivered to students by the end of 2022 to over 100k by the end of 2023.

2023 was the year to do more with less. At times my job was to do whatever we needed to make progress, so some days it felt like I was bouncing between devops engineer, DBA, sales engineer, integration specialist, hiring manager and tech lead. I was also heavily involved in the rollout of Pay, meeting weekly with the CIOs of our partner universities.

We got much better at selling to higher-ed in 2023. On the IT side, we laid down the right processes and software controls in place to improve our security posture and increase our partners’ confidence in us. A highlight here was rolling out Okta as our IdP and Jamf as our MDM.

One thing I noticed in 2023 is that there’s something about the education space that I find very compelling. I love meeting with universities, talking about their students, and building software for them. I don’t think I’ve felt this happy about any other industry before.

Balance

With so much going on at work, 2023 was also a balancing act between family and work obligations. Our two kiddos are now attending two different schools, with Emily and I handling dropoffs and pickups, in addition to their usual extracurriculars.

On any given morning I’d wake up around 7, feed the kids breakfast and handle the morning routine and school dropoff until around 9:30, when I’d immediately jump online and start answering Slack messages and taking calls. Not a lot of slack in the system, but my mornings with the kids were always the best part of my day.

This year I also started volunteering as a Sunday school teacher for my daughter’s sacramental prep class. Out of all the things I mentioned in this post, this is by far the most difficult thing I’ve done all year. What teachers call “behavior management” in a classroom of 15 first graders is a completely different ball game. I have so much new respect for teachers, especially primary teachers. They should be paid way more than they’re getting paid now.

For our 10 year anniversary, Emily and I went to Paris with my dad and the kids. It’s a special trip because we had originally wanted to go to Paris for our honeymoon back in 2013.

Another important note in the topic of balance: I’m getting better at taking PTO and generally resting when it’s time to rest. Growing up, my parents ran small businesses first in retail and later in hospitality. They didn’t really take time off to go on vacation, which is something I’ve been slowly getting better at as an adult.

New habits

Despite the busyness of this year, I managed to read more books and write on this blog more than any other year. In my book recap post I talked about book clubs and Goodreads as habits that contributed to more reading. These are two habits I want to continue in 2024.

In the second half of 2023 I made major strides towards improving my sleep with Withing’s sleep tracking mat, which goes under your mattress. I get a sleep score every night, which I try to keep above 80 on average.

The other major change in my habits is my burgeoning watch life. Before, as I’d go about my day, everything I did came with a “smartphone tax”. After every task, I’d lose at least a few minutes, usually more, to my iPhone.

This also came with a big mindset change for me. For as long as I can remember I used to be a diehard mobile-first Apple fan. These days, that which I used to see as the next iteration of the “bicycle of the mind” I now look at with suspicion. I hope anyone reading this has a better relationship with their mobile computing device, but for me it it used to be nothing short of a loss of personal agency.

This year I also quit Twitter, Reddit and largely minimized my use of Instagram. You can find now on Mastodon now, my preferred social network.

In the past couple of months, I’ve also experimented with waking up earlier. My Apple Watch haptic alarm goes off at 5:15am, and I’m hoping to keep moving that up another half hour in the coming months. In the morning hours, I’ve been reading, writing and exercising, although I usually only have time for two of the three. Starting my day this way makes the rest of the day more peaceful.

Looking ahead to 2024

For the last couple of years I haven’t been much into resolutions. The things that need to change are so obvious that I just work on them until they get better. At work I’m looking forward to continuing to mature Meadow in 2024 and going out for another round of funding.

I also want to get back to the basic joy of programming. I put nearly every work minute into Meadow in 2023, and in 2024, especially with my expanded morning time, I want to get back into coding just for fun. In particular, I want to devote some time exploring LLMs in 2024.

In 2024 I will need to be even better at balance. I like that I’ve started to take better care of myself, since this seems to be a hard requirement for achieving balance. The next frontier for my health is to improve my VO2 max (the Health app always reminde me of this). Wishing you all a happy new year!

I quite enjoyed being part of the alumni book club, which introduced me to Latin American authors I’d never read or even heard of before. It also meant that I read more fiction than non-fiction, also a change for me this year. With the exception of Elvis and me, I learned that I’m not much of a memoir person.

• Blindness by Jose Saramago
• Good Omens by Terry Pratchett & Neil Gaiman
• Elvis and me by Priscilla Beaulieu Presley
• Demon Copperhead by Barbara Kingsolver
• Trust by Hernan Diaz
• El general en su laberinto by Gabriel Garcia Marquez
• When breath becomes air by Paul Kalanithi
• The Manager’s Path by Camille Fourier
• In the Shadow of Mountain by Silvia Vasquez-Lavado
• A Journey to the center of the Earth by Jules Verne
• Glucose Revolution by Jessie Inchauspe
• Laudato Si’ by Pope Francis

In 2024 I plan to continue to track my reading digitally but I’m on the hunt for a Goodreads replacement. If you know or use another tool, please drop me a note. I’m also hoping to join at least one new book club. The book discussions I participated in this year were a highlight of 2023.

This year, during my yearly update cycle, I also decided to leave behind my Milhouse avatar, which was this site’s favicon for many years.

“Milhouse” was a childhood nickname that I resurrected as a professional persona when I started working full time. I started to make this Simpsons character my profile picture in Slack, JIRA and other services. If you’ve ever worked with me you probably know that Milhouse = Pietro. But today I put Milhouse to rest, at least for a while, partially because I don’t wear glasses anymore, but mostly because in our remote working world I figured that having your actual photograph be your profile picture is more helpful to new hires and colleagues you’ve never met in person.

I reserve the right to bring Milhouse back in the future, although at that point it might be more fitting to come back as Milhouse’s dad.

The Apple Watch Series 9 is the first Apple Watch that I believe can comfortably play this role. Two improvements have made this experiment successful for me: the new CPU and on-device Siri.

This is the first Apple Watch to get the S9 SiP, which is based on the A16 chip from the iPhone 14 Pro. The previous three generations (Series 8, Series 7, Series 6) were all using the exact same CPU, which was based on the A13 chip from the iPhone 11. This is a big jump in CPU, which makes the watch very responsive in all situations.

Interacting with the Series 9 via Siri is also a lot less frustrating than with previous generations. When you issue a Siri command, the step that takes your voice input and transcribes it to a text command now happens directly on the watch. This has reduced latency for Siri significantly. Many of my common Siri requests (e.g. starting a timer) now don’t go out to the network at all.

My biggest issue with this setup has been LTE connectivity. I don’t know if it’s Apple or T-Mobile, but when I leave my house I often find that the handoff from WiFi to cellular didn’t work. I always need to toggle airplane mode on and off for 10-15 seconds for the cellular connection to kick in. I’ve never been left stranded without an LTE connection, but I’ve opted to take my phone as backup on occasion, especially when taking the kids somewhere new.

The other problem I’ve run into is the lack of third-party Apple Watch support. There’s no Slack Apple Watch app anymore, so I can only respond to Slack messages I receive. I cannot initiate new Slack conversations from the watch. I also don’t have any of the rewards apps I’ve installed on my iPhone, which was an issue at Chopt and 7-Eleven. By and large I’m using first party apps all day.

This was a successful trial run and I’ll continue this way for the time being. In the past month, I’ve definitely been more present with my family. I’ve read more books. I’ve paid more attention on the road. I’ve slept better and generally have been less anxious throughout the day. The Apple Watch lifestyle is not for everyone, but since I work from home I find that I don’t really need a “mobile” computing device most of the time. And when I’m out and about I can get by with my watch.

You can roll out policies all day long, but there’s no practical way to enforce auth best practices without using an identity provider’s SSO. Once you start using SSO, you can bypass all your vendors’ default authentication systems (which are in no way standardized or offer all the features you need, like MFA) and instead use the SSO’s authentication system to protect all your service accounts uniformly.

In practice, if you have 30 apps that your company uses regularly, instead of asking employees to choose a strong password and turn on MFA 30 times, now they just have to do it once. Better yet, even if an app does not offer MFA, fronting that app with your SSO solution lets you effectively protect it with MFA.

Here’s the problem — once you start fronting your vendors with your SSO provider, you’ll see that SSO is often part of an “enterprise plan” that is significantly more expensive than the plan you’re currently on. Our JIRA cost went up over 40%. Our Notion cost went up 85%. I haven’t pulled the trigger on Figma yet, but that’s going to go up almost 300%. This website keeps track of the worst offenders. Its tagline:

A list of vendors that treat single sign-on as a luxury feature, not a core security requirement.

There’s a lot I could say about this practice, but I’ll just say this: your desire for better security should not be a key driver in a vendor’s pricing scheme. So if you’re early in your company’s journey and choosing software tools for the first time, take a peek at the SSO tax website. Some services on that list don’t have good replacements, but others do.

Regus is the “original” WeWork in the flexible office space industry. After I realized that I needed some temporary office space, I toured three different locations close to me, two from Regus and one from a local coworking company. I ended up picking Regus mainly because it had the best amenities and was the closest one to my house.

I went with their “dedicated coworking desk” offering because I’m on calls most of the day and wanted to leave a monitor at the office. In this setup, you have a reserved desk in an office that you share with 1-2 other people. In practice, I had the office all by myself 90% of the time for about $300 per month.

In our post-pandemic WFH times, I expect more people to do what I did. We had a big product launch at Meadow where we had to be heads down for four to six months, and I needed a space separate from the distractions of the home that would let me dip into some “burst capacity” for a few months, so I used Meadow’s productivity budget to cover the cost of the space. I expect to use Regus again in the future but I wish there were more options I could choose from in my neck of the woods.

From the very beginning, a deep rift emerged between Swift and Core Data. Core Data, by means of @dynamic in Objective-C and later @NSManaged in Swift, 100% relies on the dynamic nature of the Objective-C runtime for Core Data to work at all. This led to some serious awkwardness when Swift came along, like needing to mark almost everything in your Core Data model optional.

This rift was so wide that I was sure we’d see a Core Data replacement soon after Swift came out. I didn’t expect it to take 9 years, but after seeing the Swift features that SwiftData relies on, the delay makes sense. If I were to guess, I bet Apple wanted to first roll out Swift macros to create the models with annotations (@Model, @Attribute, Relationship) and actors to manage concurrency. And, of course, they needed a replacement for NSPredicate and NSSortDescriptor, the expressive albeit stringly-typed darlings of Foundation.

There’s no doubt SwiftData brings forth many improvements. I won’t list them all here since this year’s WWDC videos cover them all. However, Core Data’s main problem was not a technical problem. It was a marketing problem!

Core Data by Tutorials is in its 8th edition and has continued to sell well for over a decade largely because Core Data intimidates developers. It has a reputation for having a steep learning curve and for being hard to use. Almost every time I’ve pitched it for a project, no one else wants to use it besides me, even in situations where having relational graph of objects made more sense. This knee-jerk reaction against Core Data is a shame because we’re talking about data persistence, something that should be table stakes for most applications.

So that’s the real challenge SwiftData has to overcome. Can it overcome the reputation of its predecessor? After watching all the SwiftData videos from this year’s WWDC, I think it can. In my experience, having a good or bad experience with Core Data is largely dependent on the scaffolding “glue” API you build around it so it can interact with your UI code. SwiftData was specifically designed to work with SwiftUI, which might seem strange at first since there’s nothing UI-specific about a persistence framework, but the benefit is that there’s almost no “glue” API to write because it’s all already written for you.

SwiftData also does away with the model file format (i.e. .xcdatamodeld), which is bad if you’re a visual learner, but great if you were confused by the code gen that was needed to create your model files. All in all, SwiftData seems, at first glance, to be more inviting to developers than Core Data ever was, and I expect it to have a much better adoption rate.

This book, true to its title, describes in detail the path from individual contributor, to tech lead, to engineering manager and beyond. I imagine this book would be most helpful for an engineering manager at a startup, but the book does a good job at keeping its advice applicable to a wide range of office cultures and company sizes. The author herself draws from her own experience as an engineering leader at large financial institutions as well as a venture-backed startup, Rent the Runway in the 2010s.

The book “diffs” the different levels of engineering management, laying out the differences between being a tech lead vs. an engineering manager, or between managing one team vs. managing multiple teams. Unlike other books that lean heavily on the author’s particular style or experience, this book zooms into plenty of specific examples and scenarios but also zooms out to meta-advice when that’s more appropriate. One of my favorite quotes from the book:

“Management tends to be a very culture-specific task in a company. I can give you best practices all day, but if you either work as a manager or hire a manager for a company that’s not a good culture fit, you’ll have problems. There is a reason why many young companies want to seed their management teams with people who’ve been there from the early days and understand the company’s DNA.”

I also found the book strangely therapeutic, since it describes many problems I’ve grappled with but haven’t necessarily discussed with anyone before. In a way I wish I’d read it a few jobs ago. For example, I liked this description of managing several teams at once:

“The best way to describe the feeling of management from here on out is plate spinning. If you’re not familiar with it, plate spinning is a fancy form of juggling where the juggler has several poles, each with a plate spinning on top of it.”

I’ve wanted to read this book ever since a colleague recommended it to me some years ago. But I also wanted to read it for another reason: right out of college, as I was heading to my first job as a software engineer at the Huffington Post, three of my close friends from Princeton went to work as software engineers at Rent the Runway, where Camille was CTO.

I remember this period of my life vividly. Living in NYC, sharing work stories with my friends. Even before I picked up this book, I felt that I knew my fair share about the source material that produced it from when I first started working. And finally reading it felt a bit like the passing of the torch.

I’ve always believed that we should release as much source code to the public domain as possible. Complete reference implementations help new developers learn and troubleshoot. At the very least, we can point to something and say to ourselves “I worked on this!”.

To this end, a few weeks ago I released the source code for the marketing website for sweetstackhq.com. I don’t own this domain anymore, but here’s a live version hosted on Netlify. Sweetstack is a restaurant-tech project that I worked on full-time from late 2021 through the first half of 2022.

The idea behind Sweetstack is now a thing of the past, but I wanted to release the source code to illustrate a no build, low-cost, high-control approach to building a marketing site.

If you have engineers on your payroll, this approach won’t make sense for you (just use Webflow!). But if you’re technical and you’re bootstraping the first few years of your business, read on.

• No build: Even after not touching the codebase for over a year, the site came instantly back to life when I threw the static folder onto Netlify. That’s because I wrote the HTML, CSS and JS directly. There’s no building, transpiling, or bundling of any kind. Hand-written HTML/CSS/JS has a long shelf-life, and if you want to minimize your yak-shaving costs in the long-run, this “ancient” technique will help.
• Low-cost: I paid for a $5 AWS Lightsail VPS to serve the static assets (no CDN!) and ran a tiny Express server that sent emails whenever someone filled out the contact form. To lower your costs down to zero, skip the form and use a mailto link. Then just host your static assets on Netlify or GitHub pages.
• High-control: This was originally why I went with the Lightsail VPS and Express server. I wanted SSH access to the box that was serving my site and sending my emails. In retrospect, for a landing page you don’t really need this degree of control. If I could go back in time, I would not use a VPS.

The README includes an overview of the repo if you’re interested in reading more about how I set things up.

My writing workflow now looks like this: I write on my self-hosted WordPress instance, saving drafts as needed. I used the web interface for this blog post but I can use any writing tool that WordPress supports. For example, I wrote the last post about Meadow’s seed funding announcement from bed on the WordPress iOS app.

When I’m done writing a blog post, I click “Publish” on WordPress, which tells Netlify via webhook to kick off a new Gatsby build. The build process grabs all my WordPress content using a GraphQL WordPress plugin, and re-publishes my updated blog onto Netlify. Lest you think this is a bespoke system I invented, it’s all officially supported by Gatsby. They publish and maintain the Gatsby source plugin (gatsby-source-wordpress), as well as the WordPress plugin (WPGatsby) to make this all work. Their documentation and tutorials were also quite helpful.

I briefly considered leaving Netlify behind in favor of Gatsby Cloud for the tighter integration and so I could take advantage of Gatsby Cloud’s CMS preview feature, but after hearing that Netlify acquired Gatsby, I’m glad I didn’t. As with all acquisitions, the future of the acquired company is now unclear.

Despite my griping about Gatsby’s dependency on GraphQL, re-platforming my blog’s content took me less than a day because the structure of the GraphQL queries were largely the same, even though they were pulling data from entirely different sources.

I am sure to retro this new blogging setup in a few years, but so far it’s been working well. Writing on a professional-grade authoring experience is a huge upgrade compared to what I was doing before.

I haven’t written about Meadow on here before, so allow me to formally introduce it. Meadow is an early-stage startup whose mission is to empower students financially and to promote economic mobility through higher education.

In the U.S, what students end up paying for college is not the “sticker price”, but rather an amount discounted by grants, scholarships and other forms of aid. Figuring out what you actually need to pay to attend college is opaque and confusing, complicating planning and decision-making for students and their families. Many students don’t even try to engage with this system, assuming college is out of reach for them.

So in 2008, Congress mandated that every school must have a “net price calculator” on their website, allowing interested students to get a personalized cost estimate after providing a few pieces of data about themselves. This is where Meadow comes in. Taking advantage of some legislative headwinds in 2021, we introduced our own take on the net price calculator early last year, transforming what used to be merely a compliance requirement into a tool that improves enrollment for schools and elevates financial clarity for students.

We now have over 10 schools live on our net price calculator product and many more in our pipeline. Some recent launches include University of Texas at Austin, Nevada State College and Maryland Institute College of Art (MICA).

But the crisis in higher education is not just about lack of transparency. Once you know what you need to pay, actually paying for college has other major roadblocks. Some of it is timing and communications. Students receive obtuse billing statements in the mail, often without enough advance notice to make a financial plan. And once they are ready to pay, making the payment is also difficult. If there is a digital way to pay, the system is often decades old and difficult to use. Otherwise, they have to mail checks, call the student accounts office, or go in person.

All this friction might not sound like a big deal, but it’s death by a thousand cuts. One of our school partners tells us that they lose roughly half of their freshman class the following year every year. They just don’t come back.

This is the problem Meadow’s second product, Meadow Pay, is going to solve and the reason why we raised the seed round. Meadow Pay is designed to be the modern payments and engagement platform for higher ed students. It’s the missing piece between students and universities.

I joined Meadow back in June of 2022 as Co-Founder & Head of Engineering. The past 8 months have been a whirlwind of building, hiring, planning and pitching. I feel like I’ve been wearing every possible hat that could exist in an engineering org, but luckily we’re up to four engineers now.

Here’s a picture of us at our last NYC on-site:

Four years after moving to Gatsby.js, I’ve averaged between 3 and 4 blog posts a year. During this time, I’ve also had over 22k visitors, averaging to ~400 visitors per month. Not a large site or audience by any means, but I definitely wrote more and had more readers than before.

“Can’t repeat the past?…Why of course you can!” – Jay Gatsby

Trying to put myself in my 2018 shoes is difficult, but I remember moving to Gatsby with several goals in mind. Here’s what they were:

• Learn more about React and GraphQL, which I had started to use for work.
• Get more freedom with with the look and feel of my site. I felt constrained by Squarespace and WordPress theme.
• Achieve ease of maintenance. I did not want worry about running WordPress (upgrades, backups, plug-ins, etc).
• Fourth (probably too low on my list, come think of it), I wanted to write more. I felt stifled by the clunky WYSIWYG editors I’d previously had to use, so I wrote very little. The idea of writing blog posts in plaintext, using Markdown, was appealing at the time.

Things that went well

“The truth was that Jay Gatsby, of West Egg, Long Island, sprang from his Platonic conception of himself.” – Nick Carraway

I met my learning goals. This site is a small, low-effort, project that made me more comfortable with React, and to a lesser extent, GraphQL. The reallearning actually came from work, circa 2018-2019, where I used both of these in real web apps.

Something else that panned out was the degree of customization I was achieved. My current blog still looks a lot like the Gatsby starter project, but the typography, colors and layout are all mine. I particularly liked the way Gatsby handles creating pages (about, archive, etc.). To create a new page, all you need is a new React component in src/pages and you’re done.

Gatsby’s rich plugin ecosystem was also good. I kept it simple with gatsby-plugin-google-analytics for GA, gatsby-plugin-feed to generate an RSS feed and a few others. Configuring Gatsby packages was not ideal — you have to maintain gatsby-config with an entry for each plugin, which sometimes includes inline GraphQL queries. This method of configuration left me wanting.

Maintenance was both good and bad. If this site were a car, and we were tracking maintenance costs by cents per mile, this setup would be extremely inexpensive in time and money. There were a couple of discouragingly frustrating upgrade cycles but, amortized over 4 years, they were not a big deal.

Netlify made hosting and deployment free and easy. I started off in an S3 bucket fronted by a CloudFront distribution, which I would not recommend if you don’t want to think about hosting or deployment. Netlify is a spiritual descendent of Heroku, so I could deploy with a git push. One of my blog posts was #1 in Hacker News for a couple of days, and Netlify served over 30 GB in bandwidth without batting an eyelash.

After few years of running this site, I’m a believer in statically-generated websites. For a personal project or blog, it’s mostly neglect-proof. Despite semi-annual updates to this site’s dependencies in package.json, there’s an embarrassingly high number of Dependabot alerts open against this repo. But that’s largely OK, because I’m not responsible for a live system serving requests. The end result is just a bucket of HTML/CSS/JS fronted by a CDN.

Things that did not go well

“It takes two to make an accident.” – Jordan Baker

React and GraphQL were overkill. Trying to keep things as simple as possible, I didn’t use a component library such as Material UI. So React was just a templating language for HTML, a job it was way overqualified for.

One of Gatsby’s selling points is the “unified data layer” that GraphQL provides. The only data I needed came from local markdown files. Writing GraphQL queries to pull in data from local files went against my “keep it simple” mantra. If you’re considering Gatsby.js as a way to get your feet wet with React and GraphQL, I would not recommend starting with a blog. You’d be much better served by writing a more traditional web app.

Next, I’ll address the biggest downside of rolling your own blog with Gatsby. As with all things, the biggest strength is also the biggest weakness. I love that I have full control to tweak this blog however I want…the bad news is that now I have to build a baseline number of features myself.

Notice how this site (as of January 2023) doesn’t have search, tagged posts, or comments. It doesn’t even paginate the homepage! Every blog post I’ve ever written ends up listed in one long page, which will quickly become a problem as I continue to write more. These missing features are table stakes in any serious blogging platform.

To be brutally honest, I traded potential customization for an objectively worse site. And if I ever do get around to building those features, wouldn’t that be a waste? If every person who could code had to build basic blogging features, how many developer hours would we waste rewriting the same things over and over?

The area where this tradeoff is most obvious is the authoring experience. My current workflow for writing a blog post is the same as my workflow for writing code — spin up a text editor, create a new Markdown file and git push to trigger the build when you’re done.

I’ve tried to automate the tedious parts of writing a new blog post with a bash script but it’s still cumbersome. Git and VS Code are great tools, but are not the right tools for this particular job. In a world where we have lots of great, purpose-built, authoring clients, knowing that I cannot use any of them is frustrating.

And I’m not the only one that feels this pain. The company behind Gatsby.js describes their Markdown-powered blog like this:

Our old process required building the entire Gatsby site locally, formatting Word docs to Markdown, updating different files for the content and author profile, then submitting a Pull Request and massaging the updates to pass a series of automated tests. I can tell you war stories of spending hours to fix a single typo, because even a small change retriggered that full process.

Yup — prose is not code.

Improvements

“Let us learn to show our friendship for a man when he is alive and not after he is dead.” – Meyer Wolfsheim

To the Gatsby team — I already mentioned the low maintenance of this Gatsby setup being a plus, but we can make this even easier. On any given day, this blog does not give me any issues. However, I’ve spent hours trying to upgrade to new major versions of Gatsby. Even the simplest setup like mine has too many plugins. Some Gatsby plugins should be part of the core package.

Second, make GraphQL optional. There’s already been some work to make Gatbsy work without using GraphQL, but we need to go even further. GraphQL should not be a direct dependency of the main Gatsby package.

The biggest improvement I could make to running this site is to the authoring experience. I have a few options if I want to get out of the business of shipping prose as code. I definitely don’t want serve everything from Squarespace or WordPress again, but I do want a WordPress-like authoring experience. Can I only use the parts of WordPress I actually want?

Turns out you can if you use WordPress as a headless CMS. This is what the Gatsby team ended up doing with their own blog.

If I went with this setup, I could keep a low-powered, private, WordPress instance that Gatsby could consult at build time. The stakes of running WordPress would be way lower — there’d only be two users, me (for authoring) and the Gatsby build process. I could theoretically keep the best parts of Gatsby and WordPress without incurring significant costs in maintenance or complexity.

I’m not sure this is where I’ll end up going with my blog, but you should consider this option if you’re starting from scratch. Gatsby even maintains a Gatsby + headless WordPress starter project that you can consult.

Last October, as I quarantined in my son’s bedroom, I decided to reorganize all my notes and update my note-taking process.

Previously, I used Ulysses for Mac to manage all my notes. I loved the design of the app and the syncing functionality, but I was starting to have performance issues. Opening Ulysses on my (then) new M1 Mac would sometimes take 5-10 seconds. It was even worse on my iOS device. I suspected there was something in my big pile of notes that Ulysses didn’t like. I contacted support but couldn’t get to the bottom of it.

Enter BBEdit.

BBEdit is a text editor originally made for Macintosh System Software 6, over 30 years ago. It’s not typically in the “note taking” app category but it’s been a foundational app for generations of macOS users and developers.

Migrating to BBEdit

Ever since the tedious migration process out of Evernote’s proprietary format circa 2016, I’d insisted on keeping all my notes as plain text files. This is partially why I’d chosen Ulysses after Evernote since you could stick to plain text using their external folders feature.

Next, I created a BBEdit project and added all my files to it. A BBEdit project (extension .bbprojectd) is a special kind of file that contains references to other files and folders. BBEdit projects let you work with related files without needing them to be located together on disk. If you’re familiar with Xcode’s project files, BBEdit projects work similarly.

There are many ways to customize BBEdit to work for you. Two notable changes I made:

• I re-mapped the shortcut for BBEdit’s “Open File By Name” feature. This feature is usually called “Quick Open” in other apps and it’s my primary way of navigating in VSCode, Xcode, Android Studio, Tower, etc. To reuse existing muscle memory, I re-mapped BBEdit’s default shortcut to ⌘ + Shift + O in System Preferences.
• I made BBEdit open my notes project open whenever it launches. By default, BBEdit doesn’t open anything when you first launch the app. If you want to have a default file, folder or project that you want BBEdit to open on app launch, you can put it in BBEdit’s “Startup Item” folder. I symlinked my notes project to the “Startup Item” folder to accomplish this.

Setting up a git remote for my notes

My old note-taking workflows relied on Dropbox or iCloud drive to sync my notes to all my devices. This is where I lacked good options — I don’t run the Dropbox native client on my Mac anymore and iCloud Drive is too non-deterministic for me.

This piece of my setup won’t work for everyone, but I ended up going with git. My notes are often about the things I have in source control, so as I’m slinging source code back and forth from a git remote, I figured I could do the same with my notes.

If it had been for anything else, I would have created a private repo in GitHub and called it a day. I ended up not wanting to put my years of thinking, planning and researching up on a public service, so I spun up a $5/month VPS instance from AWS Lightsail to be a dedicated git server.

This ended up being much simpler than I expected and I’ve had to do zero maintenance on this server this past year. After setting up your user account and SSH access on the VPS, just create a repo somewhere in your home directory and you’re done. The trickiest part is getting the remote URL right when connecting from a git client (i.e. [user]@[hostname]:~/[path-to-repo]/[repo-name].git).

I read and write most of my notes on my Mac, where I alternate between using git on the terminal and Tower. On iOS, I use Working Copy as my git client.

With this setup, there’s the risk that I won’t have my latest notes on my mobile device if I forget to push to the remote. This has only happened once in the year of having this setup, so I hasn’t been a problem for me.

Choosing to actively manage your infrastructure is part of a much larger discussion about the proper way to choose your tools. This discussion is extensive and it runs along many different dimensions.

There’s the axis of new vs. old tech and also of build vs. buy. Finally, there’s the decision to use managed vs. unmanaged services. This last one is the topic of this blog post.

At one end of the spectrum, you can manage everything like it’s 1999. You set up your own host, install and manage dependencies, set up backups, etc. As you move towards the fully-managed end of the spectrum, you start to see lightly-managed compute primitives like Amazon RDS all the way to full-service, cloud-enabled app frameworks like AWS Amplify or Google App Engine, and BaaS/PaaS providers like Heroku.

The default position at most places I come across is to go as managed as you can tolerate, usually to save on engineering effort. But how did we manage to ship anything just 10 years ago, when most of these options weren’t available?

The truth is that it was possible to build high-traffic web services in the “bad old days”, even with a very small team. Even with just one person. This is how Marco Arment describes his experience building and running Tumblr circa 2010, largely by himself:

Tumblr taught me by necessity, especially in the early days when we had no staff and very little money, how to develop and host a high-traffic web service cheaply, easily, and sanely. I couldn’t let the servers require too much maintenance because server administration wasn’t my main job — we didn’t have a dedicated server administrator for the first few years, so I just had to set things up such that they didn’t need much administration.

You can read the full blog post here. If you still don’t believe that people shipped big things fast before all of these cloud services came on the scene, I recommend reading some of the write ups at High Scalability, especially the ones from the previous decade. I particularly like the series on Stack Overflow.

The good news is that these tools and techniques are still available to everyone. I propose that you turn the default position on its head — instead of defaulting to highly managed services, default to self-managed services and only venture out as needed.

How did we get here?

If you, like me, believe that basic server maintenance is a dying art, how did we get here? It’s easy to point fingers at the big cloud providers and say, “They don’t want us to learn this stuff for their own profit!”. But the actual reason might be more prosaic. Combine the multi-billion dollar marketing budgets of AWS, GCP and Azure and you have significant gravitational pull. Then add their respective armies of developer evangelists. Sprinkle in some cargo-culting and a decade’s worth of “ship fast and break things” and you end up where we are today.

Before getting into the benefits of learning basic Linux administration, keep in mind tha this isn’t a black or white proposition. Like any good engineering challenge, it’s about tradeoffs. For example, if you do read stories from the previous decade, you’ll see people building their own hardware. That’s where I draw the line. Unless you need the performance, don’t manage physical hardware. Get a Linux VPS from a reputable hosting provider and be done with it.

Also stay away from the notion that “the cloud is evil”. That’s where most of these type of articles go astray. The big cloud providers have given us real benefits and real innovations over the past decade. That fact is undeniable. The trick is to separate the wheat from the chaff. For example, I’m not going to build realtime database but I will learn how to self-host MySQL if that’s all I need.

Reaping the benefits of Linux administration

OK — you’ve gotten this far without knowing how to run your own servers. Why change? These are some of the reasons that convinced me.

No vendor lock-in. If you run your whole system on Linux VPSes, you’ve essentially commoditized the compute layer. If something happens with your current host, you can pack up your things and set up shop somewhere else whenever you like.

Unrestrained compute. Netlify will only host your one repo. Lambda will only run your one function. Linux admin is a chore, but in return you get the whole computer. You can install whatever software you want and set things up as you see fit. You can even save some money in the process since you can run all your applications on the same infrastructure instead of paying per app.

Long-lasting skills. The tech industry moves fast, but if you look around there are certain foundational technologies that have stuck around for a long, long time. Bash, SSH, nginx/Apache, even Linux itself. Here’s an uncontroversial claim: these foundational technologies will continue to be foundational throughout your entire career. What else can you say that about in the tech industry? The earlier you learn how to write a good Bash script, the better. Compare this reality with cloud services. Building on top of them often feels like quicksand — they morph under you, quickly deprecate earlier versions and sometimes shut down entirely.

The speed (and joy) of using tools. This one is my favorite. And here I make a distinction between a “tool” and a “service”. A hammer is a tool. I use a hammer in exactly the way I want . It blends into the background and becomes an extension of myself. In contrast, a service talks back. It wants things. We’re so surrounded by services that we’ve forgotten what using a tool feels like. Linux is a tool. Bash is a tool. They’re quiet and obedient. The only thing they ask for is your dedication. They’re also fast, if you know how to use them. Here’s my theory: the dexterity that comes from learning these tools contributes to most of the potential productivity boost of self-hosting.

Getting started

Starting is not hard, but you need a plan. Just like learning programming, I recommend having a project that requires you to learn Linux admin. If you have a need to learn, you will learn. You don’t need to be a programmer to manage Linux servers, but if you’re a programmer, this might be as easy as deciding to run your own software directly on a Linux VPS. If you’re not a programmer, you can choose from a variety of open source projects with a strong community that can help you if you get stuck. Some projects that might interest you are Home Assistant, Pi-hole or something from this list of projects.

I also recommend picking and committing to a ‘default admin stack’ that includes an OS, Bash, a scripting language, a webserver and a data store. Just like you use macOS or Windows for all your personal computing, you should also pick a specific Linux distribution as your default server OS. It takes time to be productive in any OS. That’s why you need to pick one and stick to it. For example, my OS of choice is Ubuntu — I picked it because it has a large community, it’s easy on beginners and almost everything I’d want to host has official Ubuntu support.

As for scripting, commit to getting good at Bash. Bash is the default “shell” for most Linux distributions. If you’re not familiar with that term, the shell is the program that runs your other programs, so it pays huge dividends to know to make this layer bend to your will.

Bash is the primary interface for the command line terminal and it is also a scripting language. You can (and should!) save your terminal commands in a file for later use, so you can run them all at once. If you get good at this, it will help you remember how you set things up, and will automate a lot of things for you. I can’t stress enough how important this is, and how universally useful it can be to learn Bash. As a practical goal, you should be able to recreate your host with a single Bash script.

There’s only one specific feature in Bash I want to highlight: here documents. Most things on a server that you’d want to set up use text files for their configurations. Here documents let you specify an “inline file” inside your script file. If you know what a string literal is, you can think of here documents as a “file literal”. Here’s an example that sets up remote SSH access. Here’s another example that directs MySQL to create a database and an admin user. That’s how you can set up an entire server with only one script. Learning to use here documents took me from casual Bash user to budding system administrator. I wish I had learned it years earlier.

Bash has been around for a while, so it has its share of rough edges compared to more modern programming environments. For example, if you’re a programmer, you might take it for granted that every scripting language has dictionaries/hash maps, right? Well, in Bash associative arrays didn’t formally exist until Bash 4. Some older systems have Bash 3 as the default version, so you can’t use dictionaries unless you install a newer version of Bash.

For all of Bash’s advantages, I agree with Google’s Shell Style Guide:

If you are writing a script that is more than 100 lines long, or that uses non-straightforward control flow logic, you should rewrite it in a more structured language now. Bear in mind that scripts grow. Rewrite your script early to avoid a more time-consuming rewrite at a later date.

You can get far with just Bash, and if you’re not a programmer, that might be a good stopping point. But if need to write longer scripts, then the next decision you need to make after picking a default server OS is picking a default scripting language.

In theory, any language that can interact with OS can do, which includes most programming languages. For example, MySQL ships with a script called mysql_secure_installation. The original version was written in Bash, but as the script grew, it got a rewrite in C++. This was a good choice for that project, because MySQL is written in C/C++, but it’s probably not a good choice for your default scripting language.

For your scripting language, I recommend something that doesn’t require compilation, with a strong community behind it. Python, Ruby and JavaScript are all good choices. I picked JavaScript because I like to limit the things I need to learn, and I already needed JavaScript/TypeScript for the web. Node also has a huge library of packages via npm if I ever need to do something more complicated.

If you’re an iOS developer, as much as I’d like to recommend Swift, I can’t recommend it for Linux administration. Linux support is getting better, and you can avoid the compilation step and use Swift like a scripting language, but the Swift Package Manager simply pales in comparison to NPM, especially for something like Linux management.

After picking your OS, learning Bash and (optionally) committing to a scripting language, the next things on the shopping list are a web server and a data layer. Keep in mind that this is just for server administration. If you’re not a programmer, you don’t need to learn a database like a programmer would.

I picked nginx as my default webserver, although I hear Apache is also good. Learning to use a good webserver will help you direct traffic to your applications, so it’s essential. For my default database, I picked MySQL. It’s been around long enough, that there’s nothing I could throw at it that would make it break a sweat.

To reiterate, when you’re just starting, it’s more important to pick something to host than to pick the tools to host it with. Let the app dictate what you need to learn first. If you don’t know what to pick as your first hosted app, you can’t go wrong with WordPress. There are many hosting providers that offer 1-click WordPress installations, but if something goes wrong, you won’t know how everything was set up in order to fix it. As a concrete goal, aim to set up WordPress on a new host in a single script. Feel free to look at my examples for VPS setup and WordPress installation if you find them helpful.

Happy hosting!

The onslaught is seemingly unstoppable. Every new online account is liable to become another source of unwanted email. Innocuous interactions like getting a “digital receipt” at the store or joining a “loyalty program” at a restaurant just means one thing: spam.

Back when I mostly used Gmail, I used to manually create filters to weed out senders that didn’t respect my unsubscribe requests. Since I moved to Fastmail a couple of years ago, this became much simpler with the most underrated feature in the history of email: filtering by email header. Specifically, filtering by the List-Unsubscribe header.

Note: As far as I know, Gmail does not support filtering by email headers. For the adventurous, you may be able to do it with Google Apps Script.

What is the List-Unsubscribe header?

In 2003, the U.S Congress passed the CAN-SPAM Act to restrict and slow down the oncoming avalanche of unsolicited emails. The opt-out links you see at the bottom of some emails? That’s one of the things that the CAN-SPAM Act introduced.

Another opt-out mechanism, described in RFC-2369, is the List-Unsubscribe email header.

From the RFC:

The List-Unsubscribe field describes the command (preferably usingmail) to directly unsubscribe the user (removing them from the list).

Examples:

List-Unsubscribe: <mailto:list@host.com?subject=unsubscribe>
List-Unsubscribe: (Use this command to get off the list)
    <mailto:list-manager@host.com?body=unsubscribe%20list>
List-Unsubscribe: <mailto:list-off@host.com>

In theory, every email you receive from an mailing list must include this header, which describes a programmatic way to unsubscribe. This is how email clients implement the 1-click unsubscribe feature you see sometimes:

This header just gives you an additional (albeit faster) way to unsubscribe from mailing lists once they’ve already sent you email. It’s better than nothing but it doesn’t prevent you from getting or seeing those emails in the first place.

The most valuable thing about the List-Unsubscribe header is not what it lets you do, but its presence or its absence. If it’s there, the email is from a mailing list. If it’s not there, it’s either a transactional email you probably need or, better yet, it’s from a person.

Setting up the filter

In the Fastmail web client, go to Settings > Filters & Rules and create a filter with two rules:

1. A header called List-Unsubscribe must exist.
2. Sender is not a member of group unblocked-list.

The second step is optional. I have it because I find that I do want emails from a very small number of mailing lists (e.g. my children’s school). If you want an “allow list” like this, first go to Contacts and add a contact group.

When you want to let a mailing list through to your inbox, you have to log into Fastmail and add the email address to the group. Still a manual step, but I find that I do this less often than when I used to to create bespoke email filters.

This is what my filter looks like:

I browse the “lists” folder maybe a couple times a month, and almost never have to manually add email addresses to the “unblocked-list” group.

Compared to my Gmail account, which currently has over 100 filters to silence noisy mailing list spam, my Fastmail account just relies on this one. Filtering by email header is by itself worth the price of Fastmail.

Why this book?

One of the reasons why I’m so excited for this book is because I think it fills a real, persistent need that so many people have.

Most resources for learning iOS focus on the tools and frameworks for making the app but say almost nothing about sharing your work with others, be it other members of your team, external testers, or the public at large.

This state of affairs would be fine if app distribution were straightforward. Unfortunately, the opposite is true. App distribution is often one of the most complex and downright frustrating parts about shipping an iOS app. Developers can literally waste days just on figuring out how to upload a build the App Store 🤯.

Once you feel comfortable with the basics of app distribution, the book moves on to automation. Every team works differently, but iOS is now mature enough that there’s some definite convergence of best practices when it comes to iOS automation. Here, too, I believe the book fills a need. There are tons written about CI/CD/devops in the web development world, but relatively little on iOS.

Who is this book for?

People with wildly different backgrounds routinely handle app distribution. We kept this in mind while writing the book. Some chapters are more geared to developers, but if you’re involved in any way in shipping an app to the App Store, we think you can benefit from the book.

When it comes to developers, these three type of developers would benefit the most:

• Distribution novices: The first few chapters assume you’ve only interacted with the App Store as an end user. The book covers the most common workflows so you can release your first app without getting bogged down with the details.
• Distribution “expert beginners”: Some apps only need updates once a quarter or once a year, giving you just enough time to forget everything. There are so many people in this category. The book pays special attention to things that trip most people up like code signing and provisioning.
• Dev ops/platform engineers: The second half of the book dives into setting up a build pipeline so you can distribute your apps internally and externally with the least amount of effort. From personal experience, I know that getting this right can turbocharge a team’s cadence.

Closing thoughts

The hardest part about writing this book was striking the right balance between explaining everything from first principles (“ok, so what is a build?”) while still leaving room for more experienced folks to fill in the gaps they were missing. I think the book lands in a good place, but I’m looking forward to reading the feedback and questions in the forum.

Finally, I want to thank the team that made this book possible: Keegan Rush, Manda Frederick, Soheil Azarpour, Jayven Nhan, Jordan Osterberg and Sandra Grauschopf. Special thanks to Viki and Ray Wenderlich for creating the company behind the publisher that makes these projects possible.

“Datagram, the ISP whose Manhattan servers host BuzzFeed, Huffington Post, Gawker, and other sites, has lost power, an official there told us via text this evening.”

“Basement flooded, fuel pump off line – we got people working on it now. 5 feet of water now,” the official wrote.

HuffPost had backup servers, but unfortunately they were across the Hudson River in New Jersey. The whole system went down. The native apps I worked on didn’t work at all and huffingtonpost.com redirected to a Tumblr for a while.

As I remember the story, HuffPost’s CTO John Pavley went to the flooded data center himself to help get things up and running again. We also got some help from HuffPost’s then-parent-company AOL to get some servers set up in Dulles.

Back then, I remember thinking to myself that I would have no clue how to handle this situation if I were in Pav’s shoes. I didn’t have the slightest idea about the inner workings of a data center.

Even as the years went on and I worked on different things, I knew that the software I wrote ran somewhere, likely somewhere in the cloud. In practice, I never had to worry about where my software ran. The physical machines were all abstracted away.

Recently, that all changed. The application I’m working on runs on very specific hardware and does not perform well in a virtualized environment. Can’t use AWS or Linode or anything like that. Meaning, I had to roll up my sleeves, and build some “bare metal” servers.

I bought the parts, built the servers, installed Linux, set up the application, and shipped them out to the data center. It was during this process that I realized that I was still holding on a lot of the “magic” that I first felt in my HuffPost days.

As it turns out, a sever is just another computer. It has a processor and memory and storage and all the other parts you know about. Data centers are filled with nice, helpful people that receive the boxes you send them and rack your servers.

The funny thing is that already knew all of these things. I learned about the Turing machine and the von Neumann architecture in school. Essentially, all computers all the same, right? And they can all compute the same things and only differ in their performance characteristics.

I intellectually knew these things but I was expecting to need some secret sauce, some healthy serving of reality to layer on top of the theory. There was none. It’s really just a computer.

This is not the same as impostor syndrome. That’s separate. The best term I have for it is “believing in magic”, which I would describe as a combination of grogginess and discomfort towards certain topics in computing.

The opposite of accepting magic is possessing “technical fearlessness”. Engineers who posses this type of fearlessness can move up and down the entire computing stack with ease, much like a violinist shifts positions as she plays a concerto.

They’ll disassemble, reverse-engineer, hack, and finally, invent. They possess the humility to accept that they don’t know everything (no one does), while simultaneously (and paradoxically) moving with a deep-seated confidence that there’s nothing in computing that’s outside their reach.

So how do you get there? You could chip away at the magic organically as you work on different things throughout your career. But that might be too slow. I do believe there’s a canon of work that every technologist should learn, which includes both theory and engineering. But here’s the kicker: you can’t just learn it intellectually.

To go from the abstract to the fearlessness, you have to build as you go along. Matt Might’s list is a good starting point. But since the goal of the list different than what I’m talking about here, I’d remove some things and add some others.

So here’s my message to all current and aspiring technologists: seek out the magic, kill the magic.

During my research there were a number of things I found surprising. This post documents my personal gotchas in the hopes it helps someone. I also offer five specific tips on how you can fix any faulty thinking you might have about these two topics.

You’ll find this post more helpful if you already have some understanding of code signing and provisioning. If you’re starting from scratch, check out the resources at the bottom of the post first.

So why is it hard?

Code signing and provisioning routinely trump even the most experienced developers on Apple’s platforms. There are a few reasons for this: the system behind them is complex and opaque. The frequency of issues is also low. You might run into issues at least once or twice a year when a certificate expires and at most (hopefully) once per release.

On top of high complexity and low frequency, you’re usually under time pressure when issues crop up. Code signing is one of the last things before you submit a build for review. If the release is late, the last thing you want to do is read a programming guide on Apple’s developer site or watch a WWDC video. One common way to fix a code signing issue is to basically try anything and everything until Xcode is happy. It sounds awful but that’s been my personal experience. Unfortunately, I don’t think I’m the only one.

Tip #1: Start with the why

A good place to start debugging how you think about code signing is making sure you have enough background context. Why did this system come about? After reading about the origins of code signing, I stopped seeing a mess of unrelated chores and started thinking in terms of producing something that plugs into Apple’s runtime systems.

You can actually trace back all your code signing woes to something that happened in New Jersey back in the 70’s. All operating systems made by Apple descend from Unix by means of NeXTSTEP and BSD. In Unix (developed at Bell Labs in Murray Hill, NJ) all programs run with the same access and privileges a the user running them. This made sense back then because you probably programmed and loaded all your programs yourself!

“You = your apps” is not a good assumption in modern times. The programs you run today are typically third-party apps. Your third-party apps shouldn’t have the same OS-level access as you in case they are malicious or become compromised.

So what did Apple do about this decades-old assumption? This is where the App Sandbox comes in. Apple made the sandbox part of iOS/watchOS/tvOS from day one and rolled it out to macOS at the same time Apple introduced the Mac App Store.

So if you’re thinking strictly in terms of code signing, you’ve gone two steps too far. Take a step back and think in terms of the App Sandbox and how to interact with it.

So what is the App Sandbox? It’s a system that enforces a strict separation between you and your apps and also separates each app from each other. Apple designed the App Sandbox to limit the damage a bad actor can inflict on your system if they get hold of one of your apps.

As an iOS developer, I’d obviously heard of the sandbox before but I thought the sandbox was just about restricting access to the system-wide file system. This is actually not the case at all. The App Sandbox applies to a lot more: hardware, user files, user data (e.g. calendars, contacts, e-mail) and to all system integrations that could pose a security risk (the ability to send push notifications, integrate with the Health app, etc).

So how does the App Sandbox relate to code signing and provisioning? A sandboxed app that wants to do something restricted must ask for permission from the OS and (sometimes) the user. This permission-based system only makes sense if Apple can unambiguously and securely identify apps, which is what code signing and provisioning are meant to do.

Tip #2: Work backwards

Another problem I had with code signing was losing track of how the different pieces relate to each other. Think of all the terms you have to keep in your head: certificates, entitlements, app IDs, public keys, private keys, provisioning profiles, code signing, and more.

A way to understand the relationships between them is by working backwards from an end goal. Now that you understand the historical need for the App Sandbox, think of your end goal as providing the sandbox with something that can answer its questions about your app at runtime. The end goal is to provide a code-signed provisioning profile, as shown below (full credits to raywenderlich.com for the image).

If you only remember one thing from this blog post, remember this image. You can replace whatever mental image you currently have of provisioning profiles with this old-timey scroll. The App sandbox asks questions and the different portions of the provisioing profile answer them (e.g. Who are you? What do you want to access?).

Extra credit: Why does a provisioning profile need to be code signed? A provisioning profile is a plain old .mobileprovision file on your computer. If the provisioning profile weren’t code signed, anyone could change the answers you’re providing to the App Sandbox. Not only would the App Sandbox not be able to trust you, the whole system would not make sense anymore.

Tip #3: Learn to read provisioning profiles

If the end goal is to furnish a code-signed provisioning profile, then you have to know where they live and learn how to read them. As for where they are, Xcode downloads and imports all provisioning profiles into ~/Library/MobileDevice/Provisioning Profiles.

Provisioning profiles are files encoded in the Cryptographic Message Syntax format (CMS) so you can’t just double-click on one to read it. Xcode doesn’t provide a good way to peek inside your provisioning profiles, so what can you do?

You can either use the security command-line tool, like this:

security cms -D -i /path/to/example.mobileprovision

Or you can use Finder’s Quick Look preview. Simply navigate to any .mobileprovision file and hit the space bar. You’ll see a graphical representation of your provisioning profile with all relevant sections:

The components to watch out for are the App ID, the list of entitlements and the certificate. Ad-hoc provisioning profiles also include a list of device IDs representing the devices where the app may be installed.

Tip #4: Understand what invalidates provisioning profiles

Troubleshooting invalid provisioning profiles is a common task for someone dealing with code signing issues. Now that you’re a pro at finding and reading provisioning profiles, make sure you understand the common scenarios that can invalidate them. The old-timey scroll from Tip #2 will help here.

A provisioning profile contains different components. Changes to a component will typically invalidate the whole thing. Some examples:

• Any change to the list of entitlements. For example, adding a new capability in the developer portal or in Xcode invalidates all previous provisioning profiles for that app.
• Anything that invalidates the embedded certificate also invalidates the related provisioning profile. Either you or Apple can revoke a certificate or it can expire naturally after one year.
• Not having the associated private key doesn’t technically invalidate a provisioning profile but you won’t be able to code sign it anymore.

Tip #5: Understand where artifacts originate and how they propagate

One of the primary sources of confusion for me was the fact that provisioning profiles are everywhere. You see them on the developer portal, inside a hidden folder on your Mac, in Xcode and embedded in the app’s binary. This is disconcerting for a beginner. Is it all the same document? Where does it originate? Where does it go first and where does it go next? It’s a similar story for certificates and entitlements.

Along the way, Apple tried to be helpful by adding automatic code signing features to Xcode. Letting Xcode take care of code signing and provisioning is great if your use case is simple. But if you have to roll up your sleeves and manage code signing manually, I’ve found the automatic features to make everything more confusing because now there’s no single source of truth (which used to be the developer portal) and there are more places where you see the same artifacts.

You should aim to be clear about where certificates, entitlements and provisioning profiles originate and how they move through your development environment.

• Certificates originate as certificate signing requests that you give Apple to sign. Xcode can do this on your behalf. The certificate, which contains your public key, goes on an amazing journey as part of the provisioning profile (see below) while the private key lives a secret life in Keychain Access.
• Entitlements get tacked onto an App ID in the developer portal. Xcode can also do this for you from the Capabilities menu. Entitlements also go on an amazing journey as part of the provisioning profile (see below).

  Entitlements are especially tricky because there are multiple layers of defaults and overrides. Check out the diagram in this technical note to see how entitlements resolve to values after considering all the different layers.

• Provisioning profiles also originate in the developer portal. Xcode can also generate them when automatic code signing is turned on. Once you get a provisioning profile on your machine, it lives in the aforementioned ~/Library/MobileDevice/Provisioning Profiles folder on your Mac. At build time, Xcode embeds the provisioning profile in the app’s binary.

  This means that anyone who downloads your app also gets a copy of your provisioning profile! Finally, the information in the provisioning profile gets copied into the digital signature during code signing.

Some parting thoughts

This post has mostly been a journey into my own mind. The five tips are five things I clarified for myself as I wrote the chapter on code signing and provisioning. If you found this helpful, you should also refer to the resources listed below.

Please note that the programming guides refer to the App Sandbox as it refers to the Mac. Apple understandably writes very little about its “runtime policy system” but you can piece some things together by reading these Mac-specific documents.

1. WWDC 2012 – Session 414: Building Archiving and Submitting Your App
2. WWDC 2013 – Session 710: A Practical Guide to the App Sandbox
3. App Sandbox Design Guide
4. Code Signing Guide
5. Technical Note TN2415: Entitlements Troubleshooting

I can’t believe it’s been six years of book updates over six versions of iOS and five versions of Swift. Core Data continues to be a great choice for persisting and querying a complex object graph on Apple’s platforms.

I’m very grateful for our outstanding book team: Matthew Morey, Aaron Douglas, Darren Ferguson and Richard Turton.

https://www.raywenderlich.com/books/core-data-by-tutorials/v8.0

The working title for the new book is iOS App Distribution & Best Practicesand it is going to cover everything you have to do after you’re done coding. Like Core Data (less so now than in 2014), the road to getting your app in your users’ hands is paved with gotchas and frustration. Anyone who has wrestled with code signing or who has had to deal with an App Store rejection knows this.

The book will cover all the usual suspects like certificate management, code signing, provisioning profiles, entitlements, Testflight and app review. After you’ve learned how all of the basic blocks work (and why it’s hard to work with them), the book will move on to best practices like deploying internal builds, creating custom Xcode build configurations and connecting everything up to a CI/CD system. If this sounds like something you want to know more about, this book is for you.

I’ve wanted this book to exist ever since I started working as an iOS developer. Back when I first learned iOS development, I started out by building an app for a college course. I developed and demoed it primarily on the simulator and when it came time to put it on my iPhons 4S so I could bring it with me to interviews, I vividly remember spending an entire dayfiguring out app identifiers and provisioning profiles and code signing. The whole thing was foreign and confusing back then and it has not gotten much better.

I’m also incredibly excited and energized by the team that’s working on the book with me, which includes my co-author Keegan Rush and our excellent editors Manda Frederick, Soheil Azarpour, Jayven Nhan and Jordan Osterberg. Over the last six years, the process of writing a book for raywenderlich.com has improved and evolved a lot! Instead of writing in isolation, the process is highly collaborative. I can only describe it as the feeling you get when you’re part of a good scrum team. I can’t wait for the book to come out.

This used to be much easier in Xcode 7 circa 2015, but ever since Xcode 8 there’s been no dedicated button to delete Derived Data. The workflow for doing this manually consists of going to Preferences > Locations in Xcode, then clicking into the Derived Data location and deleting the directory in Finder.

That’s fine, but it takes 4-5 manual steps. There’s a much faster way of deleting Derived Data that I’ve been using for a couple of years now. And you get to use Automator!

Start with a bash script

The first thing you can do to make your life easier is to write a quick bash script to execute from the command line. The default location of the DerivedData directory has not changed in years so it’s fairly safe to hardcode the path in your script.

#!/bin/bash
echo Removing Derived Data...
rm -rf ~/Library/Developer/Xcode/DerivedData
echo RIP Derived Data

Save it wherever you want. I call mine rm-derived-data.sh. Before you can run it, you have to make it executable with chmod like this:

chmod +x ./rm-derived-data.sh

Whenever you need to delete Derived Data you can just execute this bash script and you’re done. To make it easier on you, you can also export the path to this script into your shell’s $PATH so you can run it from any directory in Terminal.

Automator App

Running the script in Terminal is fine but I wanted something that could hook into Spotlight, which I use as a launcher all day every day. To that end, I learned that I could turn any script into an app using Automator. Once you do this, you can search for and execute the script from Spotlight. And if you save your Automator app in iCloud, this utility will be available on all of your machines without having to worry about syncing.

First, open Automator and select Application.

This Automator app consists of two steps, Run AppleScript and Display Notification. Find them in the list of steps and drag them into the right pane.

The AppleScript you need for the first step calls the bash script from earlier. Remember to replace thePath with the path where you saved your script.

on run {input, parameters}	
	set thePath to "~/Developer/scripts/xcode/rm-derived-data.sh"	
	do shell script thePath	
	return input
end run

Note that Automator also has a “Run Shell Script” step and a “Run JavaScript” step that you could have used instead. But since this is Automator, I wanted to go full Sal Soghoian.

The Display Notification step is optional. I added it because I noticed that deleting Derived Data can take up to a few minutes for a large app (!) and I like to know when it’s safe to build again.

The final Automator App should look like this:

Save your work. I named my app Derived Data Exterminator because I like the mental image of the Automator robot going up against my Derived Data directory.

As I mentioned before, you can save this app in iCloud if you want it to be available on all your machines. I saved my Automtor app in iCloud but I decided to save the bash script with all my other dev scripts, so I don’t get seamless syncing for free. If this is important to you, you should look into using “Run Shell Script” instead of “Run AppleScript”.

Time to test it! For best results, I like to close Xcode first. Hit Cmd + Spaceto fire up Spotlight and start typing the name of your Automator app. As soon as you select it you’ll see a little gear in your menu bar. Once the script is done running you’ll see a notification.

Running the Automator app is my preferred method of deleting Derived Data but I learned recently that you can also use Automator to inject a menu item into Xcode.

Open Automator again but this time select Quick Action instead of Application.

In the top section, change Workflow receives to no input and select your installation of Xcode in the drop down next to it. Next, drag the same Run AppleScript and Display Notification steps like before and fill them the same way. This is what the end result looks like:

Save your work. I named my Quick Action Delete Derived Data (Automator). In Xcode, it will start showing as a menu item up under Xcode > Services.

A word of caution

When you delete Derived Data you’re blowing away the data for all the apps you’ve built. This might be fine if you only work on one app at a time but if you work on several large projects at the same time you’re going to slow down your workflow.

Although there’s no official documentation about what gets dumped in there (that I could find), it helps to build an intuition about the kinds of problems that you can solve by deleting Derived Data. I only do it if I’m experiencing type ahead or code completion problems, or if the error in Xcode points to a file in Derived Data (this sometimes happens with Interface Builder files). I’m assuming Apple removed this button for good reasons so make sure you’re not willy-nilly blowing away your Derived Data every time you clean your build.

I joined Upside in the summer of 2017, almost 3 years ago. At the time I had decided to wind down my consulting shop and start interviewing for a job. I wanted to find a growing company in DC that could leverage my mobile chops. After working from home for almost two years I was yearning to work in an office again.

At the time, Upside did not have an opening for an iOS developer. I remember using all the “outbound” techniques I learned for Sweetpea Mobile to get my foot in the door. Read: I spammed most of the leadership team on LinkedIn until I got an interview. Soon after, I joined Upside’s mobile team as an iOS developer.

When I joined Upside I was still feeling dejected from my failed attempt to bootstrap a dev shop. I was tired from wearing so many hats. I remember joining thinking that I’d be an individual contributor for the forseeable future. I wanted to become one of those indispensable software engineers. I don’t quite remember when or how I changed my mind, but after about six months I was already the unofficial lead engineer for the mobile team. I spent most of my time coordinating internally and externally but had no people management responsibilities.

In early 2018, Upside began to experiment with the feature team model. Spotify popularized this model but I was already aware of similar setups like the “2-pizza teams” I’d seen at Amazon. At its core, feature teams are all about engineer fungibility. That means anyone can work on any system, in any stack, at any point. The feature team is assigned a feature and they deliver it from beginning to end without any dependencies. Seemingly overnight I went from writing native Swift code to writing React and node. This was a great experience in retrospect but at the time it felt like a shock.

Right after the initial foray into feature teams, Upside spun up two new feature teams and I became the tech lead for one of them: Team Turboprop (see picture below for smiling Turboprop faces). The “tech lead” role at Upside is a hands-on people management position. It’s a combination of lead engineer and engineering manager.

The two years that I was on Team Turboprop have been the most fulfilling of my career. We worked on so many things! We started by building a self-service flight exchange system that no competitor had. When Upside pivoted to selling directly to companies, Turboprop was at the center of the new strategy. We created new user roles in the web app and shipped an entire suite of “corporate” features: admin functionality, onboarding of users, etc. Eventually we also came to own the profile and auth system.

The people management side of the job was also energizing, which surprised me. I was a first time manager and I was learning on the fly. The thing that worked for me was modeling myself after the best managers I’ve had in the past. Not only in how they encouraged me and matched me with good opportunities, but also in the quiet ways they created stability and prevented setbacks.

What I’m most proud of during my time at Upside is not a piece of code or a system running in production but rather the people that I was responsible for. I had the honor of helping a number of engineers achieve their goals of growing into their own leadership positions, either as team leads or as senior individual contributors.

What also surprised is how much we gelled as a team as time went on. Going to work didn’t feel like work. The team event we organized after shipping the “off-airport” car rental feature stands out as a nice memory. We used the feature we built to rent a minivan for the day and we drove an hour into Maryland to go to the best hotpot restaurant in the area.

If everything was so hunky-dory, you might be wondering…what happened? In good times, startups are risky and hard. Add a global pandemic that decimates the travel industry and a travel startup becomes unsustainable. It was a very difficult and emotional decision but in the end it felt like the time to say goodbye. Upside marches forward with some great people and I truly wish them the best.

So what’s next for me? I’ve joined Capital One’s mobile engineering team. I’ll be working on features for Capital One’s mobile app customers. This is exciting to me for several reasons.

The first is scale. Even though I’ve worked around big companies before (HuffPost was part of AOL and Quidsi was part of Amazon), I always worked at the subsidiary, never at the parent company. Most of the places I’ve worked at before had one mobile team, with a handful of engineers per platform. At Capital One there are over 20 teams of engineers devoted to the Capital One mobile apps in my division alone. Team size and number of users are one to two orders of magnitude greater than anything I’ve ever seen or experienced.

I’m also excited because of the high caliber people that work there. These include former colleagues, people that write for raywenderlich.com and folks I know from open source. At Upside, I did a lot of recruiting to fill open engineering positions. Every Capital One candidate I came across was next-level good.

Finally, I’m also happy that I’m an individual contributor again. Although at Upside I learned that my “track” will always be people management, the best engineering leaders I’ve observed have weaved in and out of coding several times. Being able to zoom in and out of code builds confidence, credibility and intuition. Beyond the practical benefits, as someone recently reminded me, coding is good for “an engineer’s soul”. I agree.

Overall, it feels similar to the way I felt back in 2017. Glad to be coding again and ready for a new adventure.

This is usually not a problem when it comes to the actual source code. I can push to Github from one machine, pull from Github from another and resume. The problem that I’ve always struggled with is keeping my IDE settings in sync.

I like tweak my key bindings, color themes and other settings to match my ideal workflow. So when I sit down at one of my computers and realize that I forgot to set up the Quick Open shortcut I use everywhere (Cmd + Shift + O), it feels like I put my shoe on the wrong foot.

I’ve made several ill-conceived attempts to sync over some of my settings, but nothing has stuck. Each app does settings differently, and in the end it seems like there’s a lot of manual setup and syncing that needs to happen anyway. If you’ve found a good solution that works for you, I’d love to know.

Syncing IDE settings has been such a long-running frustration for me that I had almost forgotten that it’s possible to come up with a solution. That’s why when I read about Visual Studio Settings Sync I was somewhere between a “yeah right” and a “hmmm…”.

I’m happy to report that it works. It’s only available in the Visual Studio Code Insiders build, so I installed that on all my computers first. My extensions, key bindings and IDE preferences are now being synced perfectly.

I would love to to talk to the product manager in charge of VS Code because this app continues to impress me. I hope Xcode follows suit at some point but I’m not going to hold breath. I also hope that Apple comes out with a generalized platform approach to give apps the ability to provide setting sync backed by iCloud. That would make owning several Macs much more palatable.

After making some tweaks to the plugin that generates this blog’s RSS feed, I wanted to test out my changes using an RSS reader. I’ve been using Reederon iOS for years, but nothing on the Mac.

It didn’t take me long to find NetNewsWire, an RSS reader worthy of an Apple Design Award. The app is open source so I went ahead and cloned the GitHub repo and built it with Xcode. I experienced some code signing issues (the year is 2020, right?) getting it to build with my free Apple Developer account, so I hopped onto their Slack and got some help from their community.

What struck me the most was the “philosophy” section featured on the app’s website.

“We believe that apps should never crash. They should be free of bugs. They should be fast — they should feel lighter-than-air.”

“We believe that quality is more important than just piling on features; we believe that quality is the most important feature. And we believe that high quality is transformative — it makes for an app you never hesitate to reach for. You can rely on it, and you do, again and again.”

“This makes us slow to add features. We are adding features — but never at the expense of how it feels. Never at the expense of reliability and speed.”

“Never at the expense of how it feels.”

Those words resonated very strongly with me. Their philosophy statement embodies my number one takeaway from all my years as an iOS developer. It takes an obsessive level of detail and care to make a truly great digital product. NetNewsWire gets it.

All of this is to say…make sure to try out NetNewsWire 5 on Mac and iOS. I’m fully switching from Reeder on all platforms after many years with it. The app is gorgeous, open source, and deeply aligned with my product values.

More importantly, it’s the app to use during these trying times. I recommend you subscribe to Marginal Revolution to get news and analysis on COVID-19. Tyler Cowen has been my favorite economist since my university days and does a great job curating, synthesizing and reacting to the latest events.

Someone reported a curious bug in an iOS date picker that I help maintain. When selecting one of the last days of 2018, the date picker would incorrectly think the date was in 2019. For example, picking 12/31/2018 would come back as 12/31/2019.

It turned out this was not a bug with the date picker, but rather how I wrote a particular date format. To illustrate my favorite bug of 2018, let’s start by creating a Date for the last day of 2018:

let calendar = Calendar.current
let lastDayOf2018Components = DateComponents(calendar: calendar, year: 2018, month: 12, day: 31)
let lastDayOf2018 = calendar.date(from: lastDayOf2018Components)

Let’s say you want to display the date as “Dec 31, 2018” so you code up a reasonable looking DateFormatter:

let dateFormatter = DateFormatter()
dateFormatter.dateFormat = "MMM d, YYYY"

Date formatter in hand, you go ahead and generate the string representation for the last day in 2018.

let dateToDisplay = dateFormatter.string(from: lastDayOf2018)
print(dateToDisplay)

However, the reasonable looking date formatter prints out “Dec 31, 2019” instead of “Dec, 2018”. This is because I used YYYY instead of yyyy in the date format.

This is such a common gotcha that it gets a prominent shoutout in Apple’s Data Formatting Guide

A common mistake is to use YYYY. yyyy specifies the calendar year whereas YYYY specifies the year (of “Week of Year”) used in the ISO year-week calendar. In most cases, yyyy and YYYY yield the same number, however they may be different. Typically you should use the calendar year.

What would it take to prevent this subtle bug? You either need to be the kind of developer that reads Apple’s programming guides cover to cover or you need to become the grizzled iOS developer that intimately knows all the warts in Foundation.

Until recently, this blog was hosted on Squarespace, which I still recommend to anyone who wants to host a website with minimum hassle.

In my case, I wanted to learn more about statically generated sites so I decided to leave Squarespace’s high-touch walled garden for something that I could implement myself.

If you’re interested in static site generators, the first thing you realize is that there are lots and lots of frameworks to choose from. There’s a site called StaticGen that lists all the popular static site generators and lets you filter them by programming language, template tool (e.g. Handlebars, Jade , etc) and popularity on GitHub.

In my particular case, I wanted to do something in JavaScript, so it came down to using either Next.js or Gatsby.js. Gatsby uses React.js and GraphQL, which I wanted to learn for work, so I settled on Gatsby.

Gatbsy First Impressions

I particularly like the “development workflow” of writing with Gatsby. Whenever I want to write a new blog post, all I have to do is create a new Markdown file and run gatsby develop to see a live preview of my writing at http://localhost:8080/. Gatsby uses webpack for hot reloads, so I can see my changes re-rendered on the browser as soon as I save the Markdown file on my machine.

The deployment process is similarly simple. Once I’m happy with a post, a simple yarn deploy runs a script that syncs Gatsby’s local public folder with an S3 bucket that I set up to serve this site. AWS’s Route 53 directs traffic from my custom domain to this S3 bucket and voilà. Gatsby’s documentation on deploying to S3 was a bit sparse, so I may write a detailed blog post about how to do it.

Note that I deviated from the standard Gatsby setup in one important way. Most Gatsby installations have the site and the content in the same git repo. In my setup, the site and the content are separate. I did this to future proof my blog. If I decide to change from Gatsby to something else in the future (Swift static site generator, anyone?), this separation of concerns will make it easier.

Write More Using This One Weird Trick

Something surprising happened as a result of using Gatsby to write this blog post. Using the same workflow and tools that I use for software development to write prose somehow reduced my writer’s block.

Maybe my brain strongly associates sending PRs and running terminal commands with work that I do everyday, so I might just have tricked my brain into thinking I was coding instead of writing.

// TODOs in order of priority

As of this writing, there are lots of features missing that you would typically find in a personal blog. I basically took Kyle Matthew’s excellent starter project and made a few changes here and there.

Some startup person once said that if you’re not embarrassed by the first version of your product, then you launched too late. Well, right now the https version of this site doesn’t take you anywhere, and that’s embarrassing.

Here’s a short list of improvements coming soon:

• HTTPS / SSL support
• Add RSS feed
• About page / resume / CV
• Add Pagination
• Add CloudFront CDN (related to HTTPs)
• Write Swift static site generator

99 reddits was first launched back in 2012. Up to this point Aman had been updating the app 1-2 times per year with folks from Elance / oDesk and funding development with an In-App Purchase. Looking for a side project with real users and inspired by Artsy’s Open by Default, I shot him a PR one day.

Compared to other times I’ve worked on side projects, this release has been a real success. There are two things that made a big difference this time:

• Trusted team > lonely developer. Aman and I have worked together for over 4 years at different companies and on different projects. I’ve learned a ton about product management from him. We know our working styles and know how to work well together. Putting together a release is no big deal because we’ve done it so many times before.
• Having an audience! With zero marketing, 99 reddits had accumulated a couple thousand monthly active users. Writing software for an audience immediately raises the bar and creates a strong feedback loop.

Gotchas and Roadblocks

• Because of trademark concerns brought up during app review, we had to change the name from the original “99 reddits” to “99 edits” and modify the app icon to hide Reddit alien. Unfortunately, this make the app harder to find, but this update is more for the devoted users that use 99 reddits regularly.
• ERROR ITMS-90101: “This bundle does not support one or more of the devices supported by the previous app version”. Did you know Apple doesn’t let you drop iPad support once you make your app universal? As part of the update, we wanted to focus all of our attention on iPhone since an overwhelming majority of usage happens on iPhone. Once we found out we weren’t allowed to drop iPad, I leaned heavily on UISplitViewController & trait collections to reuse code between iPhone and iPad. I had to work around several UISplitViewController bugs around iOS 11 large titles and iPhone X layout.
• Tech debt had piled up for 5 years. Working on this code base was like stepping through a time portal to a time when ASIHTTPRequest and NimbusKit were the latest hotness. My first instinct was to rip out, rewrite and replace. Here’s where having a pro product manager was super helpful. Aman kept us focused on shipping, so we ended up with a good balance of product features and tech debt pay-down.

Release Notes

• Removed payment/upgrade stuff. The app is now totally free. Thanks to all who paid over the years, your support meant a lot!
• Improved cache management.
• Many fixes, including crashing when saving a pic.
• iPhone X and iOS 11 updates.
• New iPad layout.

Questions?

For product questions and support, you can head over to the official 99 reddits subreddit. Found a bug? Feel free to open an issue on Github or submit a pull request if you’re trained in the dark arts of Objective-C and preprocessor macros.

For the 99 reddits app, I updated the UI to respect the “safe area” in iOS 11. One of the view controllers made use of a UIToolBar, which doesn’t look right on iOS 11 when I attach the bottom of the toolbar to the bottom of the safe area (see attached screenshot).

Filed as rdar://35633289 and on Open Radar.

Summary:

On an iPhone X, when you add a standalone UIToolBar to a view controller and add a constraint from the bottom of the UIToolBar to the bottom of the its view controller’s safe area, the bar button items appear outside the UIToolBar. It works perfectly on an iPhone 8.

Steps to Reproduce:

1. In a storyboard file, add a UIToolbar to the initial view controller.
2. Add three constraints: trailing to the safe area’s trailing edge, leading to the safe area’s leading edge, and a constraint going from the bottom of the UIToolbar to the bottom of the view controller’s safe area.
3. Build and run on an iPhone X.

Expected Results:

• The UIToolBar looks the same as if it had been the tool bar of a UIToolBarController.

Actual Results:

• The bar button items in the UIToolbar appear above and outside the enclosing toolbar.

Version

iOS 11.1 (15B87)

Configuration

• iPhone X

Even among experienced iOS developers, Core Data is infamous for its learning curve and sharp edges. With newer options for persistence such as Realm and Firebase, I see a lot of iOS developers skip right past Core Data, ignoring the framework that ships with the SDK.

The truth is that Core Data offers a robust, free, solution that integrates nicely with all the native frameworks and tools you already use every day. No other solution integrates directly with UITableView, features a model editor built right into Xcode or plugs directly into Instruments. Plus you definitely know no one is going to acquire Core Data and shut it down. Book or no book, if you’ve never tried to use Core Data, I encourage you at least kick the tires a bit.

Many thanks to my co-authors Aaron Douglas, Saul Mora, and Matthew Morey. And special thanks to Ray Wenderlich for bringing us together and to the many editors and technical editors we’ve had throughout the years: Rich Turton, Greg Heo, Darren Ferguson, Sam Davies, Bradley Phillips, Brian Moakley and Chris Belanger.

I’m not talking about the obvious things like pay and benefits. Instead, I’m talking about the (sometimes invisible) support structure in mid-size to large companies.

Doing Everything

A job title usually comes with a well-defined area of responsibility. Software engineers focus on software engineering. Lawyers focus on legal matters. Accountants focus on accounting. As tired and overworked as you may have felt at your old job, you never had to do everything.

When you strike out on your own, the default state of the world is that you have to do everything.

If you don’t follow up on an invoice, you won’t get paid. The internet is down? Can’t yell at IT to fix it anymore. You have to get on your hands and knees and rewire your Ethernet connection.

“Corporate accounts payable, Nina speaking. JUST a moment.” – Nina, Office Space

As it turns out, Nina from Office Space had an important job. Nina and the rest of her colleagues (well, maybe not Milton) were providing crucial internal services to the organization so you could keep going to work every day.

The 3 Areas of An Effective Company: Core Competency, Front Office, Back Office

As I made the move to working for myself, I struggled to wrap my head around these different roles and how they worked together.

The more I thought about it, the more I came to think of them as three distinct areas: the core competency, the front office, and the back office.

1. Core Competency

The core competency differs between companies. It’s your secret sauce—the “it” factor that differentiates your company.

As you can probably tell, this division oversimplifies the world a bit. Sometimes the secret sauce is not a particular set of functions but rather the interplay between one or two functions, or even structural differences that have taken you years to build.

The core competencies for Sweetpea are engineering, design, product management, project management and QA.

2. Front Office

I see the front office as what moves the core competency forward. It includes sales, marketing, PR and business development.

In a software agency, you may have a stellar core team of software engineers and designers, but if no contracts are coming in, your team of all-stars will just be sitting around doing nothing.

Back Office

Ah, the back office. It’s sometimes so easy to write off these activities as “overhead” but they’re crucial to keeping you afloat. This includes HR, finance & accounting, legal, employee services and IT.

Not only are these important tasks, they are easy to do wrong. For example, I am perfectly comfortable doing many of the functions in the “Front Office” but I am not as comfortable with some of the back office tasks.

Why? Some of these functions—like legal and accounting (even IT, for non-technical business owners)—should be performed by trained professionals.

Building a Complex System

As I build the different areas for Sweetpea, at first I was intimidated by all the things I needed to assemble.

It may seem like my background as a software engineer is almost useless for many of these activities. However, I found there were plenty of lessons from software engineering that helped tremendously with the other areas of the business.

Isn’t a company just a complex system, embedded in even bigger complex systems (societies, legal systems, etc)?

I think so, which is good news for me, since I’ve been working on complex systems for years as a software engineer.

I understand things like throughput, reliability, failsafes and single points of failure. I know about modular design and interfaces that can talk to one another. Thinking about these concepts is second nature for an experienced software engineer.

As I’ve learned, business systems are very similar.

With this in mind, I now think of Sweetpea Mobile as an API fronting a complex system, and it’s not so scary anymore.

I’ve thought a lot about Sweetpea as an API. In particular, I’ve tried to create a well-defined API by being deliberate about my target audience and the services that I provide. I’m planning on writing more about that later.

Asking For Help

One of the main points of this post is that there is too much to do for one person.

So, what did I do about that? I had already been working with VA based in the Philippines for about eight years now. She helps me with bookkeeping and other administrative work.

Since there’s so much to do, I’m growing the team by bringing on a second part-time VA. She is based in Texas, so we’ll be able to work concurrently.

This is a move so that I can better balance ongoing client work and business development to move Sweetpea forward.

At the same time, I also wanted the opportunity to focus full-time on software development consulting. I even incorporated a company to do it! It’s called Sweetpea Mobile.

What does this mean? Instead of having one employer and one project to work on, I have several clients and different things to work on. It’s called Sweetpea Mobile because of its focus on mobile platforms such as iOS and Android.

Sweetpea’s Opportunity

Over the past five years, I’ve worked on a few mobile-focused software development teams, and I’ve been lucky (some may say unlucky) to work through different pain points and challenges along the way.

Some were unique to whatever employer I was working for at the time, but others were not. In fact, there was one specific challenge I saw over and over every place I worked.

Every company seems to be having trouble finding, hiring, and retaining mobile developers.

“I can’t hire mobile developers. HELP!”

Here’s a question people ask me all the time:

“I am hiring a senior iOS engineer with 4-6 years of experience in New York City who can also implement a graph traversal algorithm on a whiteboard. Know anyone?”

Maybe not in those exact words, but that is really what they mean.

It’s not that these people don’t exist. They do. It’s just that the number of requirements has reduced the applicant pool to a ludicrously small size.

Add some more explicit or implicit requirements (e.g. they need to be a U.S. citizen or green card holder, jive well with my company culture, hold a C.S. degree from a top school, etc.) and it’s no wonder hiring even one mobile developer can take anywhere from 6-12 months.

Potential Traps

Hiring in the tech industry is difficult. If you are hiring mobile developers right now, you’ll have a tough road ahead. If you are in this situation, there are two potential traps to look out for:

• You’ll hire too quickly and hire the wrong people.
• You’ll hire too slowly and risk losing out on a good market opportunity.

But wait! You have more options. You always have more options.

If you’re having a tough time hiring mobile developers, here are are the three things you can do:

1. Grow ‘em

Instead of hiring new folks, you can train your current software engineers in mobile app development. This is the route Facebook chose when they doubled down on native app development back in 2012-2013.

They didn’t have enough expertise in-house, and they couldn’t hire them fast enough, so they partnered with Big Nerd Ranch to train their current employees.

“Growing” from within comes with its own risks, of course.

Training takes time. The developers you train will have to re-focus their attention to mobile projects instead of whatever they were doing before (which is probably what you want anyway). And of course, short term training doesn’t give you years of experience overnight.

2. Rent ‘em

Instead of hiring mobile developers or training your existing developers, you can temporarily bring in subject matter experts as contractors to augment your existing team.

This assumes you already have a go-to-market strategy and a team that is mostly complete but missing a few key components (like the mobile developers!).

These subject matter experts will be doing the actual work. They’ll also help you “seed” your team with the core expertise you need to train your own people, if you decide to go that route.

3. Outsource ‘em

If you don’t have a team of engineers, designers, and product managers in place, you can choose to outsource the whole project to another company.

“Outsourcing” has gotten a bad rap, but this option can be right for you, depending on your business and your core competency (e.g. your secret sauce).

For example, why would David’s Bridal hire an in-house mobile development team to build their app? Mobile development is not their core competency…renting out dresses is. Thus, it makes sense that they went with Prolific Interactive to build their app.

Likewise, why would Chipotle hire a team of full-time developers to create and maintain their watchOS app? They make burritos, not smartwatch apps! Therefore it makes sense that they decided to hire Sequence.

4. If All Else Fails, Hire Different(ly)

If you decide you really need to hire someone for an in-house position, it’s important to take a good look at your list of “requirements.” Relaxing one or two constraints can make all the difference.

For example, can you stomach hiring someone remote or part-time? A self-learner from a code school instead of MIT?

Enter Sweetpea Mobile

Sweetpea Mobile’s market opportunity comes from this question I hear so often:

“I want to hire a mobile developer right now, but I’m having a really hard time. Can you help?”

My vision for Sweetpea is to listen to these companies, understand their situation, and give them choices they may not have considered before.

Together, we’ll figure out what option is best for their specific situation:

• Grow ’em
• Rent ’em
• Outsource ’em

And while I’m not a recruiter, if the company needs more help than I can provide on my own, I’ll do what I can to connect them with the right resources.

Sweetpea’s Challenges

Nothing worth doing is ever easy. As I begin this new adventure, I see three primary obstacles:

1. I Am One Person

There is only so much one person can do. If I stay as a one man operation, I’ll only be able to work on one or two projects at a time.

It may be that the best I can do for some companies is help them “rent ‘em” (i.e. staff augmentation). And by “rent them” I really mean “rent me.”

2. Only One Discipline

To create something of value, you need different disciplines: user experience, graphic design, product management, project management, native app development, backend development, marketing, sales, etc.

As a one-man band, I can only offer services in what I’m good at, and that is iOS development. If I were selling cakes, I would only be able to sell you the flour. I can’t make you the whole cake!

3. Owning Your Own Ideas

A consultant is a third party that joins your team temporarily. By definition, they don’t have the final say in the direction of the product or the business. Furthermore, consultants (like management consultants) sometimes don’t even have their hand in the implementation of their ideas.

For someone like me who’s worked primarily on mobile products rather than client projects, this will take getting used to.

This is not an “either-or” scenario, as many software development shops do client work as well as develop their own applications.

For example, I’ve enjoyed using Kaleidoscope from Black Pixel, Slender from Martian Craft and Spark Inspector from Foundry376

Next Steps

There you have it…a big opportunity, a vision of the future, and some obstacles ahead.

As Lin-Manuel Miranda now famously wrote: “How lucky we are to be alive right now.”

These posts usually group apps into different categories but I’m going to list them in (roughly) the order that I started using them.

Xcode

Duh, right? Like many before, my journey into iOS began when I downloaded Xcode for the first time. These days I like to code using Xcode’s built-in Midnight theme. I also have Alcatraz set up on my machine to manage my Xcode plugins. My favorite plugins are BBUDebuggerTuckAway, DerivedData Exterminator and SCXcodeSwitchExpander.

SourceTree

SourceTree is my favorite git client (although I’ve also experimented with Tower). It works really nicely with Github and Bitbucket.

JIRA

JIRA is Atlassian’s bug tracking software. I don’t find JIRA very useful when I’m building something from scratch. To me, any kind of bug tracking software becomes a lot more useful once you have something out there to fix, maintain or improve.

Sublime Text

Sublime Text is my favorite general purpose text editor. Even though iOS developers work with native code most of the time, there are times when we have to roll up our sleeves and dive into some HTML or CSS. I’ve also found Sublime to be a good tool for JavaScript.

xScope

Designers hate it when your implementation looks nothing like their designs. Measuring pixel distances and aligning things in straight lines don’t come naturally to me so I use this little tool to help me implement UI designs to a high degree of fidelity. xScope includes tools such as rulers, overlays and guides.

Charles

Charles is my favorite HTTP/HTTPS debugging tool. It’s a proxy that intercepts all network requests coming in and out of your app. I’ve come to love its “Map Local” feature to simulate “what-if” scenarios with your API.

Base

Base is a lightweight SQLite browser. I started using this tool when I was first learning about Core Data since Core Data is often backed by SQLite. You can use Base to find out exactly what’s saved on disk.

Linguan

Localizing an app to other languages by hand is no fun. To make matters worse, Xcode doesn’t provide a GUI to get the job done quickly. Linguan is the localization GUI Xcode should have had. This little tool has saved me hours of tedious manual labor.

Spark Inspector

Attach Spark Inspector to your running app and it will show you a 3D model of your view hierarchy. Spark is useful when you’re debugging your layout or your views. I also hear good things about Reveal, although I’ve never tried it.

Deploymate

When your app supports multiple versions of iOS, you have to be careful about backward compatibility issues. For example, if you use a new API that didn’t exist in an older version of iOS, your app will crash on older devices. Deploymate is a static analyzer tool that alerts you of this type of problem. I suggest using it before submitting a new version of your app to Apple.

Slender

You’re adding assets when you add new feature, but are you remembering to remove old assets when you remove old features? Probably not. Slender scans your project for assets that you no longer use so you can remove them.

Cocoapods

Cocoapods is the de facto dependency manager for iOS and Mac OS projects. If you want to add a third party library to your project, it’s as easy as adding a line of text to your Podfile and executing a terminal command. I can’t recommend it enough.

Crashlytics

Getting timely crash reports from users is essential to improving the quality of your applications. Crashlytics is one of many crash reporting tools available for iOS. I’ve also worked with Testflight, HockeyApp and Crittercism.

Kaleidoscope

Kaleidoscope is Black Pixel’s diffing tool. You can use it to compare text, images and directories but I mainly use it for comparing two different images. For example, I’ll use Kaleidoscope to compare a mockup with a screenshot of my live UI. I then use this information to improve and iterate my UI implementations.

Simpholders

One of the advantages of running your app on the iOS simulator is that you can inspect your app’s file system using Finder. This is practically impossible on a physical device. The problem is that the iOS simulator is buried somewhere in ~/Library and its location changes with every version of iOS (or so it seems). Simpholders is a shortcut to the simulator directories that you can access from the menu bar.

If you think I’ve left out an important tool, please go ahead and let me know in the comments. Each tool listed on this post has either increased my productivity or increased the overall quality of the apps I’ve worked on. I’m sure I’ll be adding more tools to the list as time goes on. Enjoy!

If you played with Swift while it was still in beta, you probably realized that your projects would stop compiling going from one Xcode beta to the next.

Even though Swift is technically not in beta anymore, moving from Xcode 6.0 to Xcode 6.1 was no different. We’re still in the (very) early days of Swift.

Personally I prefer following a tutorial step by step rather than listening to a lecture or reading a book. I’ve always been a fan of learning by doing, especially if I’m starting from scratch.

Here’s a link to the announcement on Ray’s site. Also here’s a sneak preview of chapter 1 in blog post form. I hope you guys enjoy the book.

The last lesson is “you are never done”. He ends with this quote from Steve Jobs:

“If you do something and it turns out pretty good, then you should go do something else wonderful, not dwell on it too long. Just figure out what’s next.”

You accomplished something. Great. What’s next? How are you going to top yourself next time? It reminds me of Elizabeth Gilbert’s TED talk about her drive to keep creating. Two different fields, same idea.