Daniel Gauthier

Identity Crisis!

Thu, 19 Nov 2020 00:00:00 +0000

Hi there! It’s been a while since I wrote anything. There are reasons for that, but they’re all rather nebulous and hard to pin down. That’s sort of what this article is about. It’s also a retrospective of sorts; a look back at the last year and a bit, which has been wacky and wonderful and horrible all at once. It’s about some career decisions I’ve made in that timespan, and how those have collided with and ricocheted off of the rest of my life, and where I’ve ended up for the moment.

Truthfully, this one’s largely for and about me, and I don’t think there’s going to be any sort of Going Indie-esque lesson or a perfectly relatable story to take from this one, but I would be absolutely thrilled to have you read along anyways — maybe you’ll see parts of yourself reflected in whatever it is I’m about to write. Onwards!

Setting the scene

In July 2019, I quit my job. I had been at that job for 3 and a half years, and I cared deeply about it and the people I worked with. I was in a leadership role and had been a big part of significant company growth and change over the years. And yet, I was wickedly anxious and deeply unhappy. There were a variety of complicated reasons for that, but I think the best shorthand we’ve got for what I was feeling is “burned out.” And when I got into a scary car accident at the end of June (everyone was okay, thankfully; the cars were not), my camel’s back gave out, and all the straw it was carrying went everywhere.

“The straw that broke the camel’s back”, in case that wasn’t abundantly clear.

So I left, without really knowing what I was going to do next. Part of me thought what I needed was to simply do nothing for a little while, but I just wasn’t able to stomach that idea – irrationally, I was too afraid of somehow missing out on my next big opportunity, or falling into some sort of perpetual pit of unemployment.

Part of me thought maybe I just needed a different job to shake things up and challenge myself in new ways. But after putting a ton of effort into several take-home projects for one prospective employer, only to be told quite plainly that my implementation was “poor,” I realized I was nowhere near the right frame of mind to be applying for jobs, and immediately cancelled the other interviews I had lined up.

Part of me liked the idea of picking up some freelance work, which would allow me to set my own pace and schedule. Through sheer luck and happenstance, I stumbled into a few flexible, long-term contracts pretty early on, and so…that’s what I started doing. I was now officially a freelance iOS developer!

But meanwhile, part of me also really wanted to commit time to building my own apps, and wondered if there was some reality that existed in which I could make some semblance of a living off of work that belonged entirely to me. So after a few months of focusing solely on part-time freelance work and my mental health, I endeavoured to “become an indie developer” at the start of 2020.

Doing the indie thing

This part is well documented, so no need to rehash most of it. Here it is in broad strokes: at the beginning of 2020, I established a 3-pronged approach (patent pending) to getting some independent work off the ground. I started participating in iOS/tech/design Twitter, I started writing some stuff for this blog, and I started building an app.

This was really great for a while. It was exciting to try to establish something of an online presence and see my writing gain a bit of traction, and the continued freelance work prevented me from going into full panic mode financially while also making it a lot easier than it might otherwise have been to carve out time for the personal writing and app development work I was doing.

Once the pandemic landed, I came up with a new idea for a silly little app, and decided to put the in-progress indie project on hold to pour my energy into getting that idea out the door. That idea became Oh Bother, and quite suddenly, a bunch of the things I had been pursuing with this indie work – some real press coverage and recognition online, some non-negligible download numbers, some pocket change, and ultimately, proof that I was capable of designing and building something that I was proud of and that people were into — all became realities.

That was pretty rad, and I’m so dang thankful to have had that experience.

Losing momentum

Here’s the thing about accomplishments: the warm glow that follows is fleeting, and inevitably, that nagging question — “What’s next?” — rears its head. Practically speaking, I thought what I wanted next was to keep working on Oh Bother and on the blog, and see if I could build off of the momentum and grow them each into more significant projects with wider audiences. That’s still my goal today, but a good chunk of time has passed now since I last did any writing or released any updates, so…what happened here? Where’d all that momentum go?

That’s a loaded question, but let’s try to sort it out. First of all, I’d be remiss not to mention a weird truth about humans, which is that it can be hard to stay motivated to work on something once you’ve received validation for it. By my own very modest standards, Oh Bother succeeded, which meant that after release, the onus was right back on me to set brand new goals for this thing. But when you hit your targets and receive a bunch of praise in the process, it can be tough to set new targets that you’re just as genuinely hungry to hit. It’s easy to get complacent and start wandering off toward some other shiny new project. Truthfully, I don’t think this has been a huge concern for me over the past few months — I still love Oh Bother and so badly want to make progress on it — but it’s definitely tricky to avoid this feeling entirely.

The bigger, often paralyzing issue I started to have after releasing the app was the question of how much of my time Oh Bother really warranted. I always thought of it as a pretty silly little project, but clearly my work had found some sort of audience, which left me really unsure of how much of myself to commit to it. There’s definitely a part of me that wonders if, after the surprise momentum the app built on launch, I should have put everything else on hold to focus on the indie work full-time. Ultimately, I never considered that as a serious option, because of my lack of belief in the app’s ability to maintain users’ interest, and because of my aversion to scrapping the freelancing stuff (a.k.a. the only stuff actually paying the bills).

So, this left Oh Bother as an evenings-and-weekends kind of side project. Totally viable in theory, but here’s the thing about side projects: in my experience, at least, they’re the first thing to get thrown out the window when life gets shaken up in any way. And while I grappled to figure out how much time I should be putting into this side project, everything around me was shifting just slightly as a new reality started to set in: in a few months, I was going to be a dad.

To be clear, this was not unexpected, and was quite thrilling. But I also knew my life was about to get turned upside-down in ways I couldn’t really understand or predict, and I felt my priorities start to shift out from under me. The months since I had left my last job had been all about experimentation and change and figuring out what I really wanted to do next, but with a baby on the way, it started to feel urgent that I “get my shit together”, so to speak. What exactly that meant was, and continues to be, vague and ill-defined, but ultimately, I wanted to feel settled and confident — at least for a time — in my career, in order to give myself the mental space to really focus on and appreciate this new chapter in my family life.

What’s next?

So I decided the lofty, long-term dream of making a living off of indie work would definitely have to wait a few years. I started dedicating more time to freelancing work as I tried to figure out if running my own little iOS consulting business was something I could settle into longer term, but found the more I leaned into it, the less happy I felt. I found that at its worst, freelancing meant doing work I didn’t really have ownership over, while missing out on all of the important social, educational, mental and financial benefits a great job can provide.

I needed a new plan. And although it probably wasn’t wise to be putting all this pressure on myself…I needed it pretty quick. The baby wasn’t going to wait for me. Suddenly, after months of me strolling along, casually wondering “Hmm, I wonder if I could turn these freelance gigs into a proper business!” or “Hey, I’m a pretty good writer, let’s spend a bunch of time on that!” or “Huh, maybe this indie thing could turn into something some day!”, or even “Wait, am I a designer?”, I had to turn all those thoughts into My Next Big Career Move.

And when you’re a bit neurotic and regrettably career-obsessed like I am, this career move pretty quickly starts to feel like a career- defining move, which immediately turns into a personal identity-defining move. And just like that, I found myself pretty frantically trying to figure out who I am and what on earth it is I even like to do.

Job hunting

The play here was simple, in theory: find a new job as an iOS developer. I’ve got lots of experience at this point, and I had a good story to tell about the independent work I had done in the time since my last full-time job, so the rational side of my brain was pretty confident I’d be able to get some interviews lined up and find the right job.

Unfortunately, I found myself feeling very unsure about what “the right job” actually was. My career up until now had consisted of jobs at startups, on fairly small teams, all of which I ended up leading in some capacity. I’m thankful for those jobs, and there’s a lot to be learned by taking full responsibility for a team or an app, but I’ve also never had much of an opportunity to be mentored or learn about my craft from more experienced peers. I’ve been a big fish in small ponds for a while now, and eventually, I realized that I wanted to try moving to a bigger pond — or at least, one with lots of bigger fish.

Here’s the thing about “big pond” jobs – they’re typically pretty tough to get. Successful companies full of talented people attract talented, successful people, which, as a job applicant at one of these companies, usually means two things:

You’re competing against a whole bunch of other very qualified folks.
The application process is…not trivial.

Long story short: I applied for a few of these jobs, and found the process to be intimidating, frustrating, and most importantly, really not aligned with my identity as a software developer.

Who am I?

Some backstory: I was never one of those kids who, you know, learned how to program when they were eight, and spent a bunch of their free time taking computers apart or building elaborate mods for their favourite games or whatever. I thought computers were interesting, and I eventually took a computer science course in high school, but I didn’t think too much of it, and only continued the following year because the music course I wanted to take ended up getting cancelled. I got the hang of it, and did well when I ultimately studied it in university, but it was more or less just school to me. I wasn’t a “great hacker,” like so many of my classmates seemed to be; I was just good at writing exams.

This is all to say that while I’d like to think I’m pretty competent at writing code at this point, I’ve never really been passionate about it for its own sake, and I’ve always felt like a bit of an outsider to the “computer science”-ness of it all. What’s kept me going in this field is the idea that code is a tool that can be used to create things that are beautiful and joyful and meaningful and empowering – not unlike a song or a book or a piece of art.

So while I am definitely a “software developer” on my LinkedIn page, I don’t think that really captures how I think of my work. I’m a designer and a writer and a teacher and, heck, even a marketer on some days, and one of my most strongly-held beliefs about our industry is that all this stuff is way more important than we give it credit for; the best software comes from teams of developers with diverse non-technical skillsets and equally diverse backgrounds.

Long story short: in applying for jobs, I don’t love being reduced to a timed LeetCode solution or an architectural decision in a contrived take-home challenge.

I won’t belabour the qualms with interviews – I’ve been on the hiring end of many, and recognize the challenge of crafting a good technical interview – but some of these things really started to throw me for a loop. I thought I wanted these jobs, and yet, I was being tested on things that, frankly, I didn’t care much about, and that, in my mind, had very little to do with what actually made me a good candidate. One company, two interviews in, suggested a whole list of study materials (“Cracking the Coding Interview”, etc.) to prep for interview three…and I just cancelled it. None of it felt like me.

With the stress of these technical interviews weighing on me, I seriously started to question whether this was the kind of work I wanted to pursue. The excitement and positive feedback around my indie work had everything to do with my creativity and product thinking, my design skills, and my ability to communicate effectively. Meanwhile, most of these interviews weren’t really interested in any of that; these were purely technical evaluations that stripped away everything that makes me uniquely effective as a product creator, and pitted me against a slew of other folks who I can only assume care a whole lot more about big O notation than I do.

Of course, this is all an emotional oversimplification; each interview process was different, and it’s quite possible — probable, even! — that in each of these cases, I was simply not the best candidate for the job. But in general, the misalignment between how I see myself professionally and how I was often being evaluated felt significant, and it really made me wonder whether software development is the field I’m actually “supposed” to be in. Would I be happier looking for design jobs? Am I better suited to some sort of “product owner”-type role, perhaps? Should I be seeking out professional opportunities to write or to teach? ShOuLd I jUsT bE aN iNdEpEnDeNt ApP dEvElOpEr??

Can someone just pay me to do bad drawings please?

Anyway, it was a stressful summer. And to bring this back around: all my indie work certainly suffered for it. Freelancing, job hunting, and impending parenthood — not to mention this little pandemic we’re having — left me intellectually and emotionally drained.

Epilogue

At the end of August, I finally received an offer from a company whose interview process felt quite a bit more aligned with my values and strengths than some of the others, and I accepted it. Amidst all my hand-wringing about struggling to find the “right” job, I was extremely lucky and relieved to have found this opportunity as quickly as I did. It’s very much a “big pond” job that I think will challenge me in a bunch of new ways and as more than just a code monkey, and I can’t wait to see where it goes. Ultimately, my professional identity is still “software developer,” and I’m feeling good about that. Landing an exciting job — effectively being told “hey, we value what you do and we want you here” — has a funny way of resolving career uncertainties and insecurities, for a while.

A couple weeks later, my daughter was born. Suddenly, the whole parenthood thing was real, and we had to figure it out on the fly. Everything about this was (and continues to be) strange and stressful and surreal and wonderful, and I’m more grateful than ever for so many of the people in my life — especially my little family.

A couple weeks after that, I started the new job. This was also right around the time the baby started to get suuuuper colicky (an imprecise term that just means “screams always, inconsolably, for no reason”). Suffice to say, the past couple months have been a hilariously overwhelming blur, but we’re starting to come out the other side, I think. Thankfully, my wife (like so many moms) is, quite literally, a superhero.

This year has been an absolutely wild ride. Everything has happened, and everything has changed. Inevitably, there’s lots I wanted to do this year that I haven’t — namely, the indie stuff that has ground to a halt since the summer — but I think the main reason I wrote this rambling piece is to remind myself of two things: 1, to be kind to myself, and proud of the stuff I have managed to do in this crazy year; and 2, to recognize and appreciate how lucky I am to have been in a position to do any of this stuff at all — in 2020, of all years.

I’m still really optimistic that once I settle into my new normal — hopefully in the next month or two — I’ll be able to ramp up the independent work again. I’ve got so much more I want to do with Oh Bother and beyond, and I’m feeling bullish on having barely scratched the surface of what I can accomplish on the indie iOS scene. I’m also as eager as ever to keep getting more involved with this community and build relationships with the ridiculous number of you that inspire me every single day. Let’s keep building cool stuff together.

I’ll be back soon – stay tuned! 📻

Going indie, step 10: Hang on tight

Fri, 19 Jun 2020 00:00:00 +0000

It’s been about a month since the initial release of Oh Bother, and after a surprisingly action-packed rollercoaster of post-launch buzz, the dust has finally settled. Last time round, I wrote about the development and launch of the app, and touched a little bit on how, by my modest standards, the whole thing felt like a success. Today, I thought I’d tell the more detailed story of how the app, through many strange and unexpected twists and turns, came to receive the attention it did. My goal with this article really isn’t to say “look at all these great things that happened!”, but rather, to shed some light on how they happened (hint: I pretty much accidentally stumbled into all of it), and what can be learned from how it all went down.

Chapter 1: In Which a Small Audience is Built

Truthfully, this story begins back in January, when I decided to get on Twitter, start writing a blog, and figure out if I could get anyone to listen to me. I’ve talked about this process lots before and won’t dwell on it now, but suffice to say: without this first step, the rest of this story would not have happened, at all, even a little bit. I’ll come back to this point later. On to the next chapter!

The day before the launch, I tweeted about it and attached some promo art:

That tweet took off in a way I hadn’t really seen since making a bad joke about VIPER. Aside from a healthy dose of dumb luck, I think there are a few key reasons this was able to capture some attention.

First, and perhaps most importantly: the promo art looked good! That’s kind of a silly thing to say — of course you want your promo art to look good — but I put some effort into making sure it felt polished and intentional, and I think it paid off. I bought some device templates that matched the clean, round aesthetic of the app, and carefully chose a small set of screenshots that highlighted both the app’s functionality and its unique design.

On top of that, I had come up with what I think is a reasonably snappy one-liner to describe Oh Bother — “a little app I built to help you and your housemates avoid poorly-timed interruptions when you’re working from home together” — and made that the focal point of the tweet. It’s a bit wordy, but let’s be honest: being wordy is kind of becoming my thing. Ultimately, I think it works because it describes a single, very specific (and hopefully relatable) problem, and because it emphasizes the idea that this is a small, handcrafted app made by one person.

I can try to justify the response to the tweet all I want, but at the end of the day, the main reason it took off is thanks to a few key retweets from some folks with much larger audiences than me. I’m super thankful and lucky that those people were jazzed about my work, and it’s made me eager to pay it forward when I see other indies trying to get their own inspiring little projects off the ground.

On launch day, I tweeted about the app again, as one does. I had big plans to put together some sort of video for the big go-live announcement, and spent a bunch of time messing around in Rotato and iMovie, but I couldn’t for the life of me come up with anything that didn’t look like it had been made in Windows Movie Maker in 2002. Making marketing videos is, apparently, not my forté. So I moved to plan B, and attached my App Store screenshot art to the tweet instead.

This tweet caught on fairly well for roughly the same reasons the first one did, though interestingly, the first tweet was still doing the rounds at this point, and I wonder if that didn’t actually take away from this one’s ability to attract the same amount of attention. Also, hilariously, I forgot to include a link to the App Store in this tweet, and of course the pre-release tweet didn’t have one either, so I had two somewhat viral tweets going around with no direct way for people to get to the thing I was trying to market.

All in all, these were a really exciting and expectation-shattering couple of days, but I do wonder if just a single tweet on launch day, with the nice promo art and a direct link to the app, may have driven more download traffic on day one. I guess we’ll never know ¯\_(ツ)_/¯

Chapter 3: In Which a 9to5Mac Article Appears

I didn’t bother (🥁) reaching out to any press leading up to launch. Though I’m sure there are plenty of counter-examples out there, cold emails have never felt to me like a great marketing tool if you don’t already have a reputation or some buzz around your product, and ultimately, I decided that for this small and somewhat experimental project, I would just focus on using Twitter for any marketing efforts.

Having said that, I did decide to throw a little press kit onto the app’s website — just in case! — and I’m glad I did. I included a high-res app icon, my App Store screenshots, a couple extra pieces of promo art, and some short, friendly blurbs about myself and the story behind the app.

Some way or another, a 9to5Mac writer came across that first tweet on the day before the launch, and left a comment expressing interest. I quickly got in touch, and was able to make his life easy by sending him a couple promo codes and pointing him to the press kit. Sure enough, less than 24 hours later, a great little article went up on 9to5Mac to coincide with the release.

Making an appearance on 9to5Mac, on launch day, was not at all on my radar as even the stretchiest of stretch goals for this app, and I’m super lucky and thrilled that things played out the way they did.

Chapter 4: In Which the App Somehow Ends Up on Product Hunt

At some point on launch day, amid a veritable deluge of tweets, someone mentioned to me that they had posted Oh Bother on Product Hunt. I had no plans to post on Product Hunt myself — again, I was really just focused on making a bit of noise on Twitter — so I said something like “Oh cool, thanks!”, and didn’t think much of it. I figured it would fizzle out pretty quickly.

Late the following day, someone tweeted at me with a link to the Product Hunt post saying “This is you!” Sure enough, Oh Bother had a few hundred upvotes and was near the top of the chart. Next thing I knew, Ryan Hoover was tweeting about my app, and I was scrambling to stake my claim as the product’s “maker” in order to add some more detail to the post.

At that point, it was largely too late for me to really move the needle on the post, but nonetheless, it was pretty neat to see people discovering and talking about the app without my involvement. In retrospect, I can’t help but think a polished, properly-timed, well-written post on Product Hunt might have generated a lot more interest on launch day.

Oops.

Chapter 5: In Which the App sort of Ends Up on Reddit Eventually

Launch day was a Thursday. By Saturday, I had figured out that this little app idea had more legs than I thought, and around noon I realized “Oh, don’t people post their apps on r/Apple on Saturday? Maybe I should actually think about doing that.”

I’ve spent time on Reddit here and there over the years, but I’ve never had an account or really gotten involved in any Reddit community. I created an account, headed to the Apple subreddit, read the rules carefully (I’ve heard Reddit mods can be even meaner than Stack Overflow mods), and posted something about Oh Bother as part of r/Apple’s “Promo Saturday”.

It was already pretty late in the day to be posting; to make matters worse, this was my first ever post on Reddit, so it had to be approved by mods. That approval took several hours, and my post didn’t actually become visible until late Saturday afternoon.

Despite my inability to do any part of this correctly, the post still ended up with a decent number of upvotes and spent some time on the front page of r/Apple. Perhaps you’re starting to sense a theme here: what if I had actually planned this part out properly?

Chapter 6: In Which a Very Exciting Email Arrives

The following Monday, I received an email from App Store Connect with the subject line “Your app, Oh Bother, may be featured on the App Store”.

This was hugely exciting, and equally unexpected. Getting featured on the App Store is something I had always dreamed about when I started building iOS apps, and although features in 2020 may not carry the same weight that they did in 2012, this still felt like an important milestone.

When your app is being considered for a feature in the App Store, the whole process from the developer’s point of view is automated; this email wasn’t a real person from Apple patting me on the back, but rather, a templated set of instructions on what I had to do to be considered, and a deadline. There are different types of features that require different actions, but mine was a pretty standard case of providing “Artwork for the Apps Tab”. The artwork had to be provided in a photoshop file, based on a provided psd template, and follow a whole bunch of other rules I didn’t understand like “Provide all elements as high-resolution scalable vector Smart Objects on individual layers” or “Evergreen art required”.

I use Sketch for all my design work, and do not own or really have any expertise at all in Adobe products, so the next 24 hours involved me downloading a free trial of Photoshop and giving myself a crash course on how to properly move my vector assets over (while also trying to design some really simple artwork that didn’t look half-bad).

It’s like the icon, but…with little thingies.

The end result was…fine, I think? I got an automated message the day after submitting that said the artwork was approved. It still hasn’t been used in the App Store yet (which, anecdotally, seems pretty par for the course — you never really know if and when you’ll actually get that bigger banner feature). But, the app did get some smaller “Apps we love right now”-type features in the US and Canadian stores in the couple weeks following the release, which were an absolute thrill to stumble across:

Chapter 7: In Which a Very Strange Email Arrives

On May 21st — a week after launch — my dad woke up to a very strange email that began like this:

Sorry, I just want to make sure you caught that last thing I said: this email was sent to my dad. It addressed him by his first name, and was sent to his personal Hotmail address.

???????????

To be clear, I’m 30 years old — this wasn’t some situation that was easily explained away by, I don’t know, my dad having set up my App Store account or something. My dad is many things to me, but I assure you he has nothing to do with the app or any part of my software development business.

So he forwarded the email to me, saying something along the lines of “uhhhh almost deleted this, not sure what it is, but you can sort it out!” Naturally, I was extremely skeptical. Why on earth did my dad get this email? What kind of an elaborate scam was this?

But the email was sent from an apple.com email address, and I matched it to what looked like a real person on LinkedIn. They weren’t asking for money, and I couldn’t really figure out how anyone could benefit from receiving a short video of my free app. Initially I responded by asking how they ended up with my dad’s contact info, and all I got was “The address was found in our internal system; maybe it was entered when the app was set up?” (It wasn’t.)

All of this defied logic entirely, and it remains a total mystery to this day. But I already had a screen-captured video pretty much ready to go from my botched earlier attempts at filmmaking, so I shrugged, fired it off, and waited to see what would happen.

Two days later, in comes another email: “The feature is now live! Please share with your friends and followers!”

And, sure enough, there it was:

I’m not sure when this became a nudity thing, but okay Apple.

This might be the weirdest thing that’s ever happened to me. And the difference between the precise, impersonal, automated App Store artwork request and “a guy from the social media team emailing my dad” gave me whiplash. But at the end of the day, my app was shared, by Apple, to 4.5 million people. Totally wild.

Chapter 8: In Which a Blog Post goes Viral

Meanwhile, on May 23rd, I put out the aforementioned blog post about the process of building and launching Oh Bother. It was fun to write and seemed to strike a chord with a few folks, which is always what you hope to see. Usually, my blog posts don’t make too much noise beyond a couple days of slightly increased traffic on the website, and this one looked no different at first. But Dave Verwer had other ideas!

That Friday, iOS Dev Weekly went out, and my article made the cut. Awesome! I had a pretty good idea of what to expect this time round, after my imposter syndrome article got the iDW treatment a few months back.

But then at some point, I actually checked in on my traffic and quickly realized that something else was going on. Sure enough, totally unbeknownst to me, my weird little blog about indie app development — that’s right, the one you’re reading now, with the long-winded articles and the bad drawings — was on the front page of Hacker News.

I braced myself. I’ve heard Hacker News commenters can be even meaner than Reddit mods. Thankfully, the mob spared me: I got a truly nutty amount of additional traffic, but almost everyone seemed to enjoy my writing and was generally pretty nice about it. My post even ended up making it into the Hacker News weekly newsletter that weekend. Once again, I wonder if there are things I could have done to be more prepared for something like this — I had to scramble to make a Hacker News account, tried to answer some comments, quickly got rate-limited for commenting too much, etc. — but at the end of the day, this was yet another unexpected channel by which people were finding and getting excited about the app, and I’m just grateful to whoever it was that posted my article.

Epilogue: Lessons Learned

I may not have thought this through.

It’s been an exciting, wacky ride, but it’s ultimately not worth a whole lot if there aren’t some takeaways I can try to apply next time round. So, here are some quick, bigger picture reflections on what I think worked for me here, and what I learned along the way.

First, let’s get back to chapter 1 for a moment. I realize there are certainly counter-examples out there, and I’m not suggesting this is the only way to launch a new thing and have people notice, but: I truly don’t think Oh Bother would have gotten off the ground at all if I hadn’t spent the previous few months engaging with the iOS community and building an audience on Twitter. The audience didn’t have to be huge — I think I had something like 400 followers when Oh Bother launched — but the fact that some like-minded folks cared to some extent about who I was and what I was building made all the difference here.

Something else that I think has worked well for me through all this is my insistence on making everything I create feel fun, personable and human. I’m not really interested in Oh Bother as some sort of standalone brand; rather, I want Oh Bother to be an app created by me, Dan Gauthier, and I want my personality to come through in the app in the same way I try to have it come through in my writing. There are definitely pros and cons here, but at this early stage in my “indie adventure,” I think I’ve benefited from being friendly, making people smile, and having people root for me when I put out new stuff.

On a related note: I’ve now seen firsthand how being the creator of multiple thoughtfully-made things — in my case, a blog and an app — can have a multiplying effect on the success of both. This blog is a pet project, with no lofty ambitions beyond continuing to be a place for me to write fun stuff. But it’s been really valuable in building that initial audience, and is now also responsible for driving a ton of traffic to the app. Likewise, the discovery of Oh Bother has led plenty of new people to my website, and some of those people have since really enjoyed a bunch of older articles. It’s a virtuous cycle — a very small one at the moment, but hopefully one that I can keep growing over time.

Now, despite all the good stuff I’ve been prattling on about, here’s something that might surprise some of you: Oh Bother hasn’t been downloaded that many times.

To be clear, my numbers have far exceeded anything I could have possibly expected when I pushed this little app out the door — I’ve had around 8000 downloads to date, and I was probably optimistically hoping for something like 500. But I think if a couple years ago, I had read a blog post like this about an app that had been covered in 9to5Mac on launch day, that had been tweeted about by the founder of Product Hunt, that had been featured in the App Store in multiple countries including the US, that had a whole promo video shared on social media by the App Store, and that indirectly ended up in iOS Dev Weekly and on the front page of Hacker News, I probably would have just assumed that app was doing some bonkers numbers.

Although I’ve known this to be true all along, and have written as much in the past, this experience has further brought into focus just how tricky it can be to find any sustainable success as an indie on the App Store. This was never meant to be a long-term or financially successful project, so it’s all just been a silly and largely enjoyable ride as far as I’m concerned, but it does make me wonder: were there any young devs out there who saw that App Store tweet, for example, and thought “Gosh, if I could somehow just get my app tweeted about by the App Store like this guy…that’s when I’ll know I really made it!”

Because, folks…suffice to say, I have not “made it.”

(Actually, for what it’s worth, given the number of people the App Store’s Twitter account is ostensibly reaching, that tweet did remarkably little for my downloads.)

And although downloads were never the goal of this particular project, this has nonetheless solidified an important idea for me that I’m not sure I fully appreciated before: splashy publicity does not guarantee App Store success. Like, not even close. Some of you App Store old-timers out there are rolling your eyes and thinking “yeah, duh,” but I think it bears repeating for folks who are trying to break in. As a community, we do a lot to celebrate wins like App Store features and viral tweets — as we should! — but while those wins can help, it seems to me they’re rarely a defining reason for real, sustained product success.

Next time round, I’ll have more of a plan in place to market the app on launch and beyond; I think I missed out on a bunch of easy downloads by ignoring folks outside of my Twitter bubble — press, Reddit, Product Hunt, etc. — who were clearly interested in the app. But I also have bigger questions about Oh Bother, and about any subsequent apps I build, which basically boil down to this: how can you tell whether you’re dealing with a marketing issue or an app issue? In the case of Oh Bother, is this app simply not quite compelling or useful enough to drive bigger numbers? (It is a very tiny app.) Or is this just a case where I could have done a lot more to really grab people’s attention? Or, is there something here worth chipping away at such that with steady improvements over time, this little app could somehow, eventually, find itself a stronger foothold in the App Store?

Find out next week in “Going Indie, Step 11: Solve the app store and become rich and famous with this one weird trick!”

Hey, you. Yeah, you! No, no— not you, I’m— I’m talk— yeah, you right there. Hi! Come hang out with me on Twitter and let me know what you think about the novel you just read. 🦆

Going indie, step 9: Launch an app

Fri, 22 May 2020 00:00:00 +0000

On May 14th, I launched Oh Bother — my first independent app in 7 years. I wrote a bit about my decision to build Oh Bother here, but now that my little app is actually out in the world, trying to make a name for itself, I thought it’d be fun to reflect on the whole process and on what comes next. Here we go!

The timeline

April 2

Initial commit! Had the idea, had the name, and had big ambitions to ship this thing in, like, two weeks tops.

April 4

Got the basic structure and aesthetic of the app sort of fleshed out with some fake data.

April 7

Nailed down the structure of the status update drawer, and the way that it opens and closes. None of the buttons actually did anything yet.

April 10

Very quickly threw together an icon in Sketch (I am not an icon designer). Shared it on Twitter, and hilariously claimed I was hoping to launch in a week or two. The UI was basically done! There wasn’t much left to do really!

Anyway, that icon ended up being the icon. I kinda like it ¯\_(ツ)_/¯

April 11

Finished building all the fun little interactions in the status update drawer — the wobbly buttons, the modal inputs, the status change animations. Was definitely following my own advice by getting this nice and polished early on 🤓 Pretty close to the final look and feel at this point.

April 16

Started implementing local data persistence, i.e. structuring and saving user status to disk. Also built those little in-app notification views, and the system to coordinate them.

April 20

Started building the push notification system, and got timed notifications working properly. Realized it was finally time to bite the bullet and stop avoiding the hard part: CloudKit 💀

April 26

Had iCloud syncing (not sharing) working pretty well, and built the basic onboarding flow as a much-needed palette cleanser.

May 1

Built the People screen, and finally had iCloud sharing working pretty well. This was the first time the app actually worked, and could be used for its intended purpose. Getting close!

May 5

Built the Extras screen, diving deep into the scary world of in-app purchases in the process. The App Store review folks ended up making me change this screen a few times. I’m still not entirely sure why.

May 6

Built the menu screen, which represented the final chunk of UI the app needed to be complete.

May 7-9

Tons of little tweaks, bug fixes and polish. My commits were way too big and irresponsibly spaced out before this point, and now all of a sudden I was pushing 10 tiny commits every day.

May 10

Finalized all the extra colour palettes and app icons.

May 11-12

Submitted for review!

…And promptly rejected.

I went back and forth with app review a few times, all because of weird in-app purchase issues that, honestly, weren’t really issues. At some point I think they were just rejecting me for the fun of it, because I eventually had to submit a formal appeal and say “uh…your rejection has nothing to do with my app. What’s the deal?”

May 13

Thankfully, the appeal was quick, my app was approved, and I scrambled to finish up the website and some simple marketing materials.

May 14

Launch day 🚀

Was it a successful launch?

Short answer: resoundingly, yes.

Longer answer: Success is subjective! Oh Bother has not made me rich or famous, nor was it intended to. (My next app will do that, I assume). I had a bunch of smaller things I was hoping to do with this app, and luckily, those things seem to have largely panned out.

First off, my primary goal was to get something created entirely by me into the App Store quickly. I was tired of thinking of myself as an “independent iOS developer” without actually having a single app in the App Store, and if nothing else, I knew it would be helpful for networking and for potential future job hunts to have at least one thing in the world to point to and say “that’s mine.” So, mission accomplished!

But more to the point, I wanted the app to be something I was proud of, and that, however small, reflected what I’m capable of as a developer, as a designer, and as someone who can see a project through from start to finish. I wanted to prove to myself that I could make something that people would be interested in, and maybe even inspired by. And, ultimately, I think I did! I’m proud of my quirky little app, and the design and attention to detail that went into it seems to have really resonated with some folks.

I’ve made a well-documented attempt this year to get involved in the online iOS community in the hopes of growing my network and learning from a pretty incredible group of people. To that end, I was also hopeful that building and showcasing an app I was proud of would open up opportunities to connect with more of the people I’m inspired by in this community. In this sense, Oh Bother was definitely a success; to put it crassly, sharing the progress and launch of the app more than doubled my follower count on Twitter, which is wild. But more importantly, I feel like I’ve started to form some real (albeit heavily internet-mediated!) relationships with a whole bunch of remarkably smart, generous and supportive people, and I’ve been absolutely floored by this community’s eagerness to lift each other up. Thanks y’all.

FInally, my stretch goal in all this was to build something that garnered enough of a positive response that I’d feel justified in continuing to put time into it after release. This project was all about cutting scope and getting something out the door quickly, but I’ve always loved the idea of actually having a project to maintain, and make decisions about, and add fun new features to over time. At some point during development, I off-handedly mentioned to my wife that I’d be thrilled if I could just make 100 bucks from this app, because that would tell me people were seeing some amount of value in the idea, and that it might be worth pursuing a while longer.

Well, dear readers, thanks in large part to your generosity, I’ve made 100 bucks! I’ve also received a ton of thoughtful feedback, and have received over 100 (mostly very positive) reviews on the App Store worldwide. Again, nowhere near rich and famous numbers (or even significant side-hustle numbers), but enough to give me the conviction to keep exploring this idea for a little while longer, and see if I can make anything more of it. There seem to be some folks out there who are actually using and enjoying this app (and who also aren’t related to me), and that’s truly an incredible thrill.

Oh, also, the app actually mostly worked and didn’t explode on launch day. So by that metric alone: Successful Launch 😎

What comes next?

There are so many great, obvious ideas that I think could make this product more useful:

iPad, Watch and Mac apps
Siri shortcuts
Custom contexts
Notification center widget
Calendar integration
etc, etc, etc…

… not to mention some really important additions like localizations and accessibility improvements. In other words, I’ve got my work cut out for me.

The question now is whether continued support and some added features over the next few weeks can move the needle on my download numbers. Because, unsurprisingly, after the excitement of launch, those numbers bottomed out pretty quickly. So far, I’m still encouraged by the slow trickle of downloads, and especially by the consistently positive reviews the app continues to get — that tells me the app might be sticking for at least a few users. But I’ll be honest — I’m still not personally convinced this is an idea that has real staying power. I do, of course, believe the app can be useful — we’re still using it at home! — but it’s also a little bit goofy. That silly simplicity is by design, and is definitely part of the app’s charm, but I don’t yet know if there’s really enough value here to keep people engaged long-term.

So, I’m going to keep excitedly chipping away at it for the next little while, with the lofty ambition of getting those numbers to start ticking upwards again. I’ll also be thinking about how I can not-too-aggressively morph the payment model to make sure that, on the off-chance the app does start to gain more traction, I can continue to financially justify working on it.

And if things just sort of fizzle out over the next few weeks or months, that’s okay! That’s what’s kind of fun about the aggressively time-boxed approach I took to building Oh Bother — I don’t feel like I’ve invested too much of myself into it, and so I’ve got space to experiment with it now and see where things end up.

In my article about imposter syndrome earlier this year, I wrote the following:

From the moment you decided to get into iOS development, your career has been coloured by this vague idea that true success in this industry is nearly or completely single-handedly building something that grabs people’s attention. At the end of it all, you don’t just want to be “[Your Name Here]”. No, at the pinnacle of this climb, you want to be known as “[Your Name Here], creator of [Your Brilliant and Beloved App]”.

Calling Oh Bother “brilliant and beloved” is definitely a stretch. But I’m having a blast with this app, and I’ll happily wear my “Dan Gauthier, creator of Oh Bother” name tag for the foreseeable future 🎈

If you haven’t checked it out already, you can find Oh Bother on the App Store here. Come find me on Twitter; I’d love to hear what you think about the app 🦆

Going indie, step 8: Take a hard left

Tue, 28 Apr 2020 00:00:00 +0000

Hi! 👋

It’s been a little while since I last wrote something on the ol’ blog. I’ve been hard at work on a new project over the past few weeks — the subject of this article, as it happens — and much to my everlasting chagrin, there’s only so much time in a day. So, the blog had to be put on hold for a few weeks. The good news is that I’ve now got lots to catch up on here!

So, what have I been up to?

Well, my indie journey took a bit of a turn right around the start of April, when I got a pretty silly idea stuck in my head. My wife and I both work from home now, thanks to COVID-19, and we’re finding that it’s pretty easy to step on each other’s toes, so to speak. If I’m taking a quick break from work to make coffee, for example, I’ll often accidentally make a bunch of noise, or try to strike up a conversation, forgetting that she might be in the middle of a phone call, or just really focused on a difficult task. Of course, with my brain being broken in the particular way that it is, I thought: what if there was an app for that?!

Now, before I go any further, I want to make something abundantly clear. The fact that we even have this “problem” to begin with is a reflection of how extremely fortunate we both are to a) not be living alone, b) have jobs that we can do from home, and c) have jobs that are at once relatively secure and utterly irrelevant, in the grand scheme of things, in this moment. This is a dumb problem, and honestly, I don’t really want to frame this app I’m about to describe as anything other than a fun, trivial little side project.

Nonetheless, a silly problem deserves a silly app to solve it, and so I started thinking about whether this was something I could feasibly build. Of course, as this whole blog has made clear, I’ve already got a significant indie project on the go, and conventional wisdom would suggest that you probably don’t want to make a habit of abandoning ideas-in-progress for whatever shiny new idea pops into your head.

Now there’s an idea…

But, I’ll be honest: freelancing work, writing and real life have been taking up a lot of my time, and I haven’t been making progress on the indie app work as quickly as I had hoped. I still think I’ll get the big app done at some point this year, but the idea of shifting gears for a few weeks in order to get a much smaller finished product out the door felt pretty appealing. I haven’t actually released an app independently since 2013, and I figure I can probably learn a lot from going through that process and seeing if I can drum up a bit of interest online. If nothing else, it gives me something recent I can point to and say “look, I’m capable of building cool things!”

So, I’m building this app. I’m not sure the idea itself has any real legs, but I figure the cost of building it is low enough that it’ll be worth doing, regardless of any response it does (or doesn’t) get.

Okay…what is it, exactly?

The app is called Oh Bother. Why? Because it’s all about communicating whether or not you want to be bothered, and because I like Winnie the Pooh.

It’s a rather simple app that helps you and your housemates avoid poorly-timed interruptions when you’re working from home together. You can set your status to either botherable or unbotherable — neither of which are real words. You can put your status on a timer, such that it flips automatically when time is up, and you can get notified when time is up, if you wish. You can also provide context for your status by indicating that you’re on the phone, or taking a nap, or going outside, or what have you.

Meanwhile, you’ll always have up-to-date info on your housemates’ statuses, synced automatically through iCloud. You can also set up notifications to let you know when a housemate’s status changes, which might come in handy if your housemate is busy, but you’re really eager to talk to them about the hilarious tweet you just wrote.

The app will be free, with an option to tip inside the app, and perhaps get a few fun cosmetic options as a thank-you hug. I haven’t quite sorted out that last part yet — that’s one of the things I’ve still got left to do before launch.

My goals in building this thing

My initial commit was on April 2nd, so I’ve been working on this on and off for close to a month. I can see the finish line now, but the process has been a pretty tricky tug-of-war between three goals that are quite at odds with each other: shipping quickly, shipping something that feels complete and polished, and learning some stuff along the way.

Ship quickly

On April 10th, I tweeted about this app for the first time , and said I was hoping to launch it “in the next week or two.” It’s now April 28th, and I’ve still got work to do, so…oops.

Despite this very unsurprisingly dragging on a bit longer than I had initially hoped, speed has been a priority throughout. This is intended to be a small side project, and I want to make sure the cost-benefit of building it isn’t skewed too far towards “cost.” To make sure of this, I’m building it largely with tools and frameworks I’m super familiar with — this app is 100% Swift & UIKit, with one small third-party library, Cartography, that I’ve written about before. I’m also leaning heavily on my own UI library, which I’ve built up over time, and that sits on top of UIKit and implements a bunch of reusable controls, custom transitions, etc. that match my aesthetic and coding style. In other words, I’m reusing everything I can!

Polish

Seeing as this is a small project I’m releasing for free, the biggest practical benefit I can hope for from a career/indie cred perspective is for this app to showcase some of what I’m good at. And in general, what I’m good at (according to me) is paying attention to detail and building things that are polished and thoughtfully designed.

Here’s the problem: polish takes time — sometimes, absurd amounts of time — and because it’s what I care most about, I am extremely susceptible to falling down nearly endless rabbit holes of tweaking and obsessing over tiny design details that regular users likely could not care less about.

So, building this app has definitely been an exercise in trying to find some balance here. There are lots of fun details in there that I’m proud of, but I’ve taken plenty of shortcuts that I’d love to spend more time on too.

Learn

Regardless of any “success metrics” an app release does or doesn’t hit, there’s always some value in building something if you can learn and improve as a developer along the way. Of course, learning takes time, so there was a balance to be struck here too. I would have loved to build a small app like this using SwiftUI, for example — and who knows, maybe that’s a project for another day — but I know that would have taken me a lot longer, and likely resulted in a less polished end-product.

So, I largely stuck with the tools I knew, with one big exception: I’ve never built an app using CloudKit before. Building this with Firebase likely would have taken me less time, but CloudKit is an important framework that represented a big gap in my knowledge, and this seemed like an easy, constrained use case to get started on.

Adding robust CloudKit syncing and sharing was definitely the hardest part of building this app, but I think I’m out of the weeds now, and have a good grasp on a framework I knew very little about just a few weeks ago. I may write a more technical article about my experiences with CloudKit soon, but in the meantime, I will simply say this: Gui Rambo’s CloudKit 101 was an absolutely massive help in getting my implementation off the ground. If you’re at all curious about learning CloudKit, I’d highly recommend starting there.

Cool, when can I get the app?

Update from the future: It’s available now! Check it out and let me know what you think 🎈

Going indie, step 7: Keep up!

Sun, 29 Mar 2020 00:00:00 +0000

Putting earth-shaking world news aside for a moment: the BIG news in our little iOS developer bubble over the past couple weeks has been the official addition of mouse and trackpad support in iPadOS 13.4. For various reasons, I think most of us love the idea of being able to use our iPad as a “computer” — with Xcode for iPadOS being the holy grail we’re all longing for — and this is a big step in that direction. On top of that, this is not your standard, run-of-the-mill mouse cursor; Apple has, in some subtle but significant ways, reimagined and redesigned the pointer on iPadOS, and the results are pretty exciting.

Naturally, iOS developers and designers far and wide are now scrambling to figure out what this means for them and their apps. There are some new APIs to learn, sure; but perhaps more importantly, there are now a whole new set of design considerations to take into account when building an iPad app, and we all kind of have to collectively figure out what exactly those are. Of course, Apple’s Human Interface Guidelines are a crucial starting point, but inevitably, there’s still a bit of a gap between written guidelines and effective third-party implementation. Twitter pal @_chuckyc got a bit of a conversation going to this effect, and then summed it up nicely here.

I’m not going to dive deeper into these brand new interactions at this point, because I’ve still got some work to do myself to better understand the impact all this will have on building apps for iPad. As for properly adding pointer support to the little app I’m currently building, I haven’t gotten much further than tacking “Add thoughtful pointer support” onto my ever-growing to-do list.

Which got me thinking: we sure are juggling a lot, huh?

Things were pretty different when, on a whim, I decided I wanted to “be” an iOS developer in 2012. For starters, there was one iPhone size and one iPad size, and I don’t think universal apps were a thing yet. There was no AutoLayout, no Storyboards, no Swift or SwiftUI. There were no app extensions, no Watch apps, no Siri intents and shortcuts, no 3D Touch. None of this “multiple scenes” business, no haptic feedback, no drag and drop, no dark mode, and of course, no trackpad and mouse support. I’m sure the list goes on and on — those are just a few things that spring to mind.

These are all wonderful tools and features that improve our lives as developers on the whole, and allow us to build ever-more-engaging and delightful ways for people to interact with our apps. But for the most part, they’re adding to, rather than replacing, existing tools and features, and I wonder: are these all piling up and making the barrier to entry for iOS development significantly higher? Or has this been offset by other improvements to the developer experience? Part of me feels like iOS development in 2020 is a whole lot bigger and scarier-looking than iOS development in 2012. On the other hand, maybe a new iOS developer doesn’t need to care a whole lot about the details of drag and drop, dark mode, or hover states, and in fact, a modern UI framework like SwiftUI is making app development more accessible than ever.

I kind of suspect the reality is closer to the latter, but if anyone out there is just getting into iOS development now…I’d love to hear what that experience has been like!

More to the point: designing and building a great, fully-featured app — one that takes full advantage of the impressive hardware and vibrant platform it’s built on top of — is really quite difficult, regardless of your experience level. I don’t think that’s news to anyone reading this blog, but I thought it was worth dwelling on for a minute. Not to lament the complexity we deal with — I’m hugely thankful I build software on a platform that has evolved and improved so rapidly, and has stayed so relevant, for so long — but simply to remind us all that there’s a lot going on here, and we don’t need to be instant experts on every additional feature and tool that gets thrown our way.

If you’re building an app on your own, all of the design and development complexity falls squarely on your shoulders. If you can write code and make your UI look “nice,” that’s a start, but it certainly doesn’t get you to the finish line — and with each iOS update, the race seems to get a little bit longer. In 2012, thanks to the combination of building on a younger platform and truly having no idea what I was doing, most of what I was thinking about was plopping views into Interface Builder, moving things around to make them look good, and hooking IBActions up to my app logic. Today, even an app that seems straightforward on its surface likely has me thinking about:

Designing layouts that nicely adapt to a wide array of screen sizes
Making sure my universal app is built according to best practices on both iPhone and iPad
Supporting Dynamic Type, and ensuring my layouts can handle it
Supporting a wide variety of important accessibility features
Using 3D touch in a useful way, without hiding important functionality behind it (though this seems to be on its way out)
Thoughtfully designing for dark mode
Properly handling both software and hardware keyboards
Supporting useful keyboard shortcuts
Adding haptic feedback (without getting carried away)
And now…appropriate hover states in my UI for mouse/trackpad use!

Depending on the app, it’s not unusual to also need to think about significant bolt-ons like Siri integration, Today widgets, Spotlight search indexing, Watch extensions, and the like. And of course, this doesn’t even touch on all the more technical complexity in writing code that interacts with networking services, that’s modularized and well-architected and testable, that keeps up with best practices in Swift, etc.

It’s a lot!

Again, I’m not at all suggesting this is a bad thing, nor do I think this is unique to iOS development. But I do think it’s worth taking a step back and recognizing the breadth of knowledge involved in designing and building a great iOS app, both for the sake of celebrating the effort that goes into the best apps on the App Store, and as a helpful reminder when the scope of what you thought was a simple project starts to feel a bit overwhelming.

While I may have a long list of iOS features that I’d love to integrate into my app eventually, I’m trying not to think of it as a checklist that needs to be completed in order for the app to be “finished.” Instead, it’s simply a ranked list of priorities. I realize I could probably spin my wheels for years trying to check off everything on that list, while constantly adding new things to the list as the iOS ecosystem continues to evolve. Instead, in this pre-release stage of development, I’m trying not to worry too much about keeping up with every shiny new tool or feature we get from Apple. There are a few existing features at the top of that priority list that I feel strongly about getting into version 1; anything beyond that can be chipped away at — and probably prioritized more intelligently — once I’ve got some folks actually using the app.

My lofty ambitions are absolutely to get to everything on that list eventually, and build my little idea up into a best-in-class app on the App Store. But, honestly, I get frazzled easily when I feel like I’m juggling too many ideas and competing priorities at once. So, for myself and anyone else who needs to hear it: focus on a few high priority items, iterate, and don’t worry too much about keeping up with the latest on UIPointerInteractions until you’ve got a working app to interact with 😬

Thanks for keeping up with my happy little blog. Stay home, wash your hands, and find me on Twitter here! 🦆

Going indie, step 6: Do it during a pandemic, I guess?

Sun, 22 Mar 2020 00:00:00 +0000

I’ll be honest: I didn’t accomplish a whole lot this week. As of right now, COVID-19 appears to be more or less causing the world to fall apart in a way that most of us have never really seen. It’s, uh…not great!

So it’s been genuinely tough to focus on much of anything. On the face of it, my week shouldn’t have been particularly disrupted by any of this — I work from home every day anyways, and thankfully most of the work I’m doing right now hasn’t (yet) been meaningfully impacted by what’s going on — but it turns out global pandemics are distracting and stressful all on their own. Who knew?

This is fine.

Nonetheless, the show must go on. From the sounds of it, we may all be practicing social distancing for quite some time, so it’s on me to make sure I don’t fall down an endless rabbit hole of hourly news updates and anxiety, and instead stay motivated to do the things I love to do and build the app that this blog is ostensibly all about.

So, this week, I thought I’d keep it light and write up a short list of things I’ve been doing in an effort to stay on track and prevent my brain from melting out of my ears. This list is presented in order from “frivolous and possibly unhelpful” to “earnest and well-meaning,” so feel free to skip ahead if you’re not particularly interested in the 25-year-old sitcom I’ve been binge-watching.

I promise I’ll get back to writing real, well-considered articles about indie app development next week. For now, stay safe out there, listen to the experts, and enjoy whatever nonsense I’m about to come up with 👇

Watch Seinfeld

In a time where the walls of our modern globalized world are falling down around us, our reliance on technology is absolute and unsettling, and the true implications of this pandemic feel altogether too big to wrap your head around, consider watching this self-proclaimed “show about nothing,” steeped in 90s nostalgia, full of humour that (aside from the poor handling of certain social issues that so much 90s comedy cringily veers into) holds up remarkably well.

This is such a dumb show, but it’s a nice bit of respite from the real world in 2020.

Play Alto’s Odyssey

A bunch of wonderful indie game developers have decided to make their games free this week as a small gesture to help us all deal with this wacky and stressful moment. I picked up Alto’s Odyssey this week, made by Snowman, a game studio in Toronto, and Harry Nesbitt, an artist and developer in the UK. It’s simple, it’s meditative, and it’s visually and aurally stunning. I’m not typically someone who plays many games on my phone, but this game has been a joy to pick up here and there over the last few days.

A couple other chill games I love that you can grab for free right now are Mini Metro by Dinosaur Polo Club, and A Short Hike by Adam Robinson-Yu. Check ‘em out!

Make good coffee

I’m a big coffee nerd, so this isn’t new behaviour, per se, but I’ve been trying to really appreciate the ritual of making and enjoying a great cup of coffee or two in the morning. It’s a good excuse to take a break from your screens, do something with your hands, and check in with your senses. Coffee is the best ☕️

If you’ve only ever thought of coffee as bitter wake-up fuel, but you’re bored and stuck at home and want a new hobby: it’s not hard or particularly expensive to massively up your coffee game! Order some whole beans from a good local roaster, get yourself an inexpensive manual burr grinder, a v60 and some filters, and you’re off to the races.

Play Pandemic (and win)

If you don’t know, Pandemic is a cooperative board game about a rather far-fetched scenario where the world is at war with a dangerous and highly contagious virus, and it’s your job to contain the outbreaks and find a cure before it gets out of hand.

Anyway, we thought it’d be funny to play last night, and I’m happy to report that we won handily. We can beat this thing, folks!

Actually, we played twice and lost pretty badly the first time, but that first one was just bad luck or whatever. Doesn’t count.

Listen to some good tunes

Music can be a great tool for both relaxing and getting focused, provided you find some stuff that tickles your brain in just the right way. Here are a handful of records I’ve been listening to this week to help me chill out, be productive, or both.

Fellow Twitter user @mattie tweeted about Slumberville this week, and I’ve been grooving to these lo-fi beats ever since.
For a similar but fuller, more jazzy vibe, I’ve really enjoyed putting Sweatson Klank’s new record on in the background.
If you’re looking for some more folksy tunes to get wistful and hopeful to, I highly recommend Walter Martin’s latest, The World at Night.

Get excited about news from Apple

It’s been a little bit weird and disorienting to scroll through Twitter this week and bounce wildly between sobering tweets about the world being on fire, and giddy tweets about the new Magic Keyboard and cursor support in iPadOS 13.4. My initial impulse was to wonder: is it somehow insensitive or unhelpful to be focused on relatively frivolous product releases from one of the world’s richest companies at a time when so many people’s finances and well-being are being thrown into disarray?

Ultimately, I’m confident the answer is no. I think it’s important and healthy to find things to get excited about as a community, and do our best to find some normalcy in all the uncertainty. I’m really jazzed about what looks to be a really thoughtful and well-crafted implementation of mouse/trackpad support on iPad, and I can’t wait to see where the iPad goes from here.

Let’s just remember how lucky we are to be able to keep doing and talking about this stuff for a living 🙂

Improve your approach to project & time management

Here’s an actual work-related thing I did this week: I could already feel my motivation and focus fading pretty quickly last weekend, so to try to get a step ahead of it, I made an effort to refine and improve the way I plan my time.

I ended up leaning into Notion pretty heavily, and for all my whining about not getting much done this week, it’s actually really helped to keep me on track, all things considered. Without getting too far into the weeds, the crux of what I’ve got set up is a kanban board that I’ll clean up and review every week, with a calendar view hooked up to it that allows me to easily schedule and adjust my tasks throughout the week. The bigger point is this: if you’re lacking motivation and having a hard time getting stuff done, now might actually be a good time to think a bit about your tools and habits, and see if you can’t leverage some new ones to give yourself a bit of a boost.

Be kind to yourself

Despite my best efforts — and despite being in the extremely fortunate position of not having had my world turned upside down by layoffs, business closures or illness — this week was still…a total mess. I slept like garbage, didn’t exercise enough, wasted an unbelievable amount of time staring at my phone, and got done about half of what I was aiming for. But, ultimately: who could blame me? We’re all still learning about this strange new reality, and it’s going to take some time to get the hang of it. Even if this week felt like a total write-off, don’t beat yourself up about it. Let’s be thankful for what we’ve got, stay positive wherever we can, help out those in need, and take another crack at it next week 💪

WHAT A TIME TO BE ALIVE. Let’s get through it together. Find me on Twitter and let me know how you’re doing 🦆

Going indie, step 5: Suffer from crippling imposter syndrome

Thu, 12 Mar 2020 00:00:00 +0000

Has this ever happened to you?

You’re an iOS developer. Maybe you’ve been doing it for a while, or maybe you’re new to the scene. Maybe you prefer to think of yourself as an “iOS engineer,” because it sounds better and no one seems to agree on whether there’s a difference. Whatever the situation: you’re feeling restless. You’ve worked on interesting projects before — successful ones, even — and you recognize that getting paid to do what you do is in many ways a privilege. Nonetheless, you can’t shake the feeling that none of the work you’ve done is truly yours. Much of your time has been spent helping others achieve their goals — and that’s okay! — but you increasingly feel like you’ve got some of your own goals to chase too.

You want to build something that belongs to you, you want to pour your heart into it, and frankly, you’d like to find some success doing it. “It’s time,” you proclaim boldly, “for me to build an app.”

You built an app or two on your own, back in the day. Oh, the naïveté of your youth! You tried to be smart about it and temper your expectations, but be honest: you were pretty sure that thing you built — you know, the one with the ball of mud code base, the baffling feature choices and the inscrutable UI — was going to be a hit. You shared it with your aunts and uncles on Facebook, sent a few bland emails to some app review websites, and sat back and waited for this thing to spread like wildfire.

It didn’t.

This time, though, maybe things will be different. You’re much older and wiser. You’ve got loads of real-world experience under your belt now, and, albeit from a distance, you’ve seen what it takes to have some success on the App Store in 2020. If all these other folks can do it…surely there’s space for you too?

Yeah, I’ll just put this…right…here…

From the moment you decided to get into iOS development, your career has been coloured by this vague idea that true success in this industry is nearly or completely single-handedly building something that grabs people’s attention. At the end of it all, you don’t just want to be “[Your Name Here]”. No, at the pinnacle of this climb, you want to be known as “[Your Name Here], creator of [Your Brilliant and Beloved App]”. Of course, rationally, you know there are loads of people who are living successful and fulfilling careers as employees at great companies, but a big part of you still feels that, as someone who can competently design and build software, you are uniquely positioned to create your own life’s work. That’s what you’ve been led to believe, anyway. And isn’t that the dream? Wouldn’t it be a shame not to try? You’re tired of deferring your dreams to your future self; it’s time to act!

So, naturally, you fire up Twitter.

You’ve been lurking on Twitter for years, but you’ve never tweeted much. A few times, you’ve toyed with the idea of actually trying to build some sort of “presence” on Twitter, but there are a few things that keep getting in the way:

You’ve never felt you have anything interesting to say that hasn’t already been said by at least a thousand other people desperately trying to build their own Twitter presence.
You’re already addicted enough to Twitter without chasing likes and retweets.
You basically believe that Twitter is bad for you and for society.

This has tended to manifest itself in the following way:

Every year or two, you work up the courage to tweet something clever.
Zero (0) people like your tweet — probably because you effectively have zero (0) followers.
You delete your tweet sheepishly and hope no one noticed you had the audacity to think you were clever enough for Twitter.

Now, though, you are not only older and wiser; you are emboldened by your decision to jump head-first into building your own app. You’re feeling a little bit reckless, in an intentional and exciting sort of way. And for better and for worse, anyone who’s anyone in the iOS community seems to be on Twitter. If you want a shot at making a name for yourself — at going from “[Your Name Here]” to “[Your Name Here], creator of [Your Brilliant and Beloved App]” — having a real presence on Twitter kind of seems like a must.

So, you start following more iOS folks, and you endeavour to start shamelessly yelling into the void.

*Crickets*

In the beginning, you’re feeling confident. You don’t have any followers yet, but you believe in your ability as an iOS developer, and you’re committed to this new idea that, actually, you do have something unique and interesting to say, damn it, and there are strangers out there who want to hear from you. You comment on an iOS celebrity’s tweet (who at this point, to you, is anyone with more than a few hundred followers)…and they like it! You feel seen. What a rush.

Sometimes you tweet, and no one seems to care, but you brush it off. “Just keep yelling,” you tell yourself. Slowly but surely, some followers of your own start trickling in. One day you tweet about something you’re working on — maybe it’s a sneak peek at your new app, or a blog post you wrote — and a few complete strangers go out of their way to comment on your thing in a kind and supportive way. “Thanks, [Stranger’s Name]!”, you reply. You make sure to use their name so that you come across as genuine. You feel validated. Hey, Twitter is fun!

One day you’re feeling a bit down, and out of nowhere, unprompted, someone tweets about some work you shared, singing your praises and encouraging others to check it out. Your mood flips. What a thrill! What a supportive community! You immediately want to get more involved and help lift up others. Your app is coming along, and it looks like there might actually be some people out here who care about what you’re doing. This is good! If you can keep this up, then with a bit of luck, you might just build up enough of an audience to give your app some traction when it finally comes out. You’re feeling hopeful.

Eventually, though, the novelty starts to wear off a bit. Realistically, you’re still miles away from having any sort of real iOS Twitter clout, the work required to get there seems like an unpredictable slog, and you start to feel a little bit uneasy about the whole thing.

For starters, it sure can be hard not to live and die by the reaction you get to your tweets. Unsurprisingly, you find that the sense of validation you get from a like or a retweet feels really good, for a minute, while the lack thereof can kind of hijack your mood, and make you question…[gestures broadly] everything. You feel this happening, and you try your best not to tie your self-worth so tightly to the whims of social media, but that sure is easier said than done — especially when it’s all tangled up with this big decision you made to build your own product and prove to yourself that you can grind your way to some level of success.

You give your head a shake. “I’m not here for an ego boost,” you think to yourself. You want to get to know some like-minded people! You want to learn from those who are a few steps ahead of you on your iOS development journey, and help out those who are a few steps behind! You want to put yourself out of your comfort zone a little bit to challenge yourself and grow as a person! That’s all true, and it makes you feel better, for a while.

But soon, your human nature starts to get the better of you in a different way. Naturally, you’re following a bunch of well-known and generally successful members of the iOS community, because you figure you stand to learn a lot from their experiences, and because it’s a good way to get involved in conversations that might expose you and your work to a bunch of other people in the community. Unfortunately, this can quickly turn into a remarkably efficient way to bombard yourself with reasons to feel bad about your career. “Hold on, that person with 4 great apps in the App Store is how old?” “Wait, that dude is making how much money working for that amazing company?” “You’re telling me this person has written several books, hosts 3 podcasts, organizes community meet-ups, regularly speaks at conferences, has sold two companies, has won an Apple Design Award, is politically active, volunteers at a shelter twice a week, is an ultra distance runner, has 4 kids and is really into sourdough, while I…play a lot of video games, I guess?”

Suddenly, you’re spiralling. You decide to be self-deprecating about the whole thing — “I have no idea what I’m doing, ha ha” — because it works pretty well as a defence mechanism, but meanwhile you’re more doubtful than ever about the amount of time you’re pouring into your app. What made you think this was worthwhile, anyways? What made you think you’re talented enough to pull this off? What are you missing out on by spending all this time on your silly pet project?

And then things really start to go off the rails. Since you feel like you’re playing catch-up with all these successful people you’re trying to get in with, the progress you’re making on your app never feels like enough. It becomes hard to manage your time and balance your priorities, and when you’re not careful, other important aspects of your life fall by the wayside.

At your worst, you start feeling jealous of all these people who seem broadly to have “achieved” more than you. Why them, and not you? “Oh right,” you remember, “I haven’t actually built anything yet. That might help.” But then: why haven’t you? You’re getting old; what have you been doing all these years? The thought scares you into making more progress on your app, for a while.

Meanwhile, Twitter starts to feel like a strange and rather disingenuous game. You can’t think of anything worth saying, but you know you can’t grow your audience if you don’t say things, so you spend way too much time scrolling through tweets trying to find one you can leave an intelligent comment on — hopefully just clever enough that a handful of people will click through to your profile and follow you on a whim.

As you scroll, and scroll, and scroll, you see not only the big fish, but the little fish too. You see what appear to be passionate, talented and well-meaning people doggedly dedicating hundreds or thousands of hours towards projects they’re excited and hopeful about, bravely putting themselves out there, trying every way they know how to drum up interest on Twitter and share the amazing thing they’ve built with the world. Often, you see these attempts fall flat — a handful of likes, an encouraging comment or two, and then nothing — and your heart aches for these people. You see yourself in them, and you shudder.

You look back at the big fish, only to see them complaining about how they too feel insecure about their work, feel like imposters, feel like they haven’t achieved everything they can or should, and you believe them. Ultimately, it makes you pause and wonder: does the treadmill ever stop? What are you actually chasing here? It’s not just Twitter fame, surely. It’s much bigger and nobler than money, right? But then…what is it, exactly? For a while, you honestly can’t remember, and your motivation tanks.

Woof.

And then you’re in the shower at the end of another long and harrowing day on the internet, staring blankly at the tiles, when out of nowhere, a lightbulb goes off: you’ve got a solution to that UX problem that’s been nagging you for weeks! It’s an important piece in the puzzle, and suddenly that bigger feature idea that was bouncing around in the back of your mind fits beautifully into the rest of the app. Your mind is racing with new ideas to explore as you jump out of the shower and clumsily dry your hands before pounding some stream-of-consciousness thoughts into the Notes app on your phone.

Nothing in your world is more exciting right now than building this feature, and you can’t wait to show it to your partner, your roommate, or, really, anyone who’s willing to listen. Building this thing, and seeing it come to life, is a pure and genuine joy. You excitedly share a sneak peak of your work on Twitter, and suddenly, you remember what this is really all about: what a privilege — and what magic! — to put every ounce of creative energy you’ve got into something you can truly feel proud of, to use these remarkable machines we call “computers” to build something out of nothing, and to share that something — big or small, polished or half-baked, silly or profound — with other humans. Creativity for creativity’s sake is a noble and timeless endeavour, and, at the risk of sounding a tad melodramatic: you’re just happy to have skills that allow you to participate in this uniquely human tradition.

The creator creates!

Two hours later, your tweet has zero (0) likes.

“What the actual f—”

Hey, thanks for making it to the end! Hope you enjoyed my ramblings. Find me on Twitter and let me know what you think 🦆

Mastering view controller transitions, part 3: Make them resizable

Tue, 03 Mar 2020 00:00:00 +0000

This week, I’m doing a set of 3 short articles that explore some more advanced, concrete ideas around custom transitions. I give some additional context in the first one, so you may want to take a gander if you haven’t already:

Mastering view controller transitions, part 1: make them reusable
Mastering view controller transitions, part 2: make them feel natural

As a quick refresher, here’s an example of the transitions we introduced in the first article, and that all this writing is based on:

Your browser does not support the video tag.

Okay, you’re up to speed! Let’s dive into the third and final goal.

Goal 3: I want my presented view controller to be able to easily define and adjust its own size

As I’ve mentioned in the past couple articles, it was really important to me in building these transitions that they were easy to reuse in different contexts. That means that if I’m building a simple presentation that slides in from the bottom, I certainly don’t want every view controller that uses it to be locked to one specific size — the size should depend on the content! — and I also don’t want to have to think too hard about setting the size appropriately every time I use my custom transition with a new view controller.

On top of that, I also quickly realized that it was important for me to be able to change the size of my view controllers while they were presented — as the content inside a presented view controller changed based on user input, I wanted the view controller to be able to grow or shrink to accommodate the content updates. (You can see this happening as tags and notes are added to the “Add game” view in the video above.)

Ultimately, we can accomplish all this (and more!) with the help of Auto Layout, a simple custom presentation controller, and the CustomPresentable protocol we’ve been using in the past two articles.

The first thing we’ll need to make sure of is this: our presented view needs to have its constraints set up such that they fully define the presented view’s height. In other words, there needs to be an unbroken chain of constraints and subviews stretching from the top edge to the bottom edge of the presented view.

To make sure that point is clear, let’s start by looking at a somewhat contrived example. Imagine we’re just trying to present a view that contains a big rectangle with a smaller button underneath. One way we might set up constraints is like this:

This is a valid set of constraints — if you installed these in a full-screen view, you’d get a rectangle and button at the top of the view as expected. But, these constraints don’t explicitly define the height of their superview, because there’s no bottom constraint; there could be any amount of space between the bottom of the button and the bottom of its superview, and these constraints would be satisfied.

Similarly, this is another valid set of constraints:

If you installed these in a full-screen view, the rectangle would fill most of the screen, with the button sitting at the bottom. But these constraints don’t explicitly define the height of their superview either, because the rectangle view has no height constraint; these constraints could be satisfied in a superview of any height, because the height of the rectangle will simply adjust accordingly.

What we need is this:

In this situation, the constraints will only be satisfied if the superview is exactly 198 points tall: 100 for the rectangle, 50 for the button, and 16x3 for the top, bottom and in-between spaces. Of course, if we tried to install these constraints in a full-screen view, the constraints would break, since an iPhone screen isn’t 198 points tall. But this is actually exactly what we want: our constraints now define exactly what the height of their superview should be, and we’ll be able to use that fact to ensure that our presented view is sized correctly.

Next, we’ll set up our custom presentation controller. The presentation controller is responsible for defining what the frame of the presented view should actually be. It’ll do this by defining a constant width that all presented views should have, and then using that to calculate what the presented view’s height should be, based on its content and constraints.

Luckily, UIKit makes it pretty easy to do this. We’ll need to override a function and a variable in our custom presentation controller to get this to work:

override func containerViewWillLayoutSubviews() {
  presentedView?.frame = frameOfPresentedViewInContainerView
}

override var frameOfPresentedViewInContainerView: CGRect {
  guard let containerView = containerView, let presentedView = presentedView else { return .zero }

  let inset: CGFloat = 16
  let safeAreaFrame = containerView.bounds.inset(by: containerView.safeAreaInsets)

  let targetWidth = safeAreaFrame.width - 2 * inset
  let fittingSize = CGSize(
    width: targetWidth,
    height: UIView.layoutFittingCompressedSize.height
  )
  
  let targetHeight = presentedView.systemLayoutSizeFitting(
    fittingSize, 
    withHorizontalFittingPriority: .required, 
    verticalFittingPriority: .defaultLow
  ).height

  var frame = safeAreaFrame
  frame.origin.x += inset
  frame.origin.y += 8.0
  frame.size.width = targetWidth
  frame.size.height = targetHeight
  
  return frame
}

Note: credit for the code above goes to Kyle Bashour, whose excellent article helped me figure this out 🙏

In frameOfPresentedViewInContainerView, we first figure out what the width of the presented view should be, based on our desire to have it inset 16 points from either side of the screen. The next part — setting a fittingSize and then calling systemLayoutSizeFitting — essentially amounts to us asking UIKit the following: given our target width, what’s the smallest height that the presented view could have that satisfies all its internal constraints? (In our rectangle and button example above, we’d get 198 as our targetHeight.) We then position the frame where we want it to be, give it the size we calculated, and return it.

When our presentation kicks off and the container view is about to layout its subviews, containerViewWillLayoutSubviews gets called. This gives us the chance to use frameOfPresentedViewInContainerView to assign a frame with the correct width and height to our presented view before it gets presented. When all is said and done, we get something like this:

Your browser does not support the video tag.

Just like that, we now have the ability to present a view controller of any size, as long as that view controller’s view defines its own height with constraints. However, we’re still missing a big piece of the puzzle: this doesn’t currently account for any changes in the presented view controller’s content after it’s been presented. A change in the layout of our presented view doesn’t automatically trigger containerViewWillLayoutSubviews, which means we don’t have a chance to re-calculate and re-assign frameOfPresentedViewInContainerView. No big deal; we’ll just have to trigger it ourselves.

One approach we can take to make this kind of dynamic layout update simple and reusable is to add this functionality to our CustomPresentable protocol — a protocol that our presented view controllers are already required to conform to. Let’s update CustomPresentable to look something like this:

protocol CustomPresentable: UIViewController {
  var transitionManager: UIViewControllerTransitioningDelegate? { get set }
  var dismissalHandlingScrollView: UIScrollView? { get }
  func updatePresentationLayout(animated: Bool)
}

extension CustomPresentable {
  var dismissalHandlingScrollView: UIScrollView? { nil }
	
  func updatePresentationLayout(animated: Bool = false) {
    presentationController?.containerView?.setNeedsLayout()
    if animated {
      UIView.animate(withDuration: 0.3, delay: 0.0, usingSpringWithDamping: 1.0, initialSpringVelocity: 0.0, options: .allowUserInteraction, animations: {
        self.presentationController?.containerView?.layoutIfNeeded()
      }, completion: nil)
    } else {
      presentationController?.containerView?.layoutIfNeeded()
    }
  }
}

Here, we’ve used the new Swift 5 feature that allows protocols to “inherit” from classes — enforcing that any class that conforms to CustomPresentable is a view controller. This then allows us to provide a default implementation for our new function, updatePresentationLayout(animated:), via protocol extension. This function simply marks our presentation controller’s container view as needing a layout update, and then performs the layout update, animating it if requested.

Now, whenever something happens in our presented view controller’s layout that requires a size change, we can call updatePresentationLayout(animated:) to update the presented view’s frame. In the case of our simple rectangle example, we can respond to the button tap like this:

@objc private func changeSizeButtonTapped() {
  rectangleHeightConstraint.constant = CGFloat(Int.random(in: 50...400))
  updatePresentationLayout(animated: true)
}

Here, we simply change the height of the rectangle to a random value, and then call updatePresentationLayout(animated: true) to perform the update. Here’s what that looks like:

Your browser does not support the video tag.

This is a simple example, but the exact same principles are applied in the more complex transitions shown in the video at the top. For example, when the “Notes” button is tapped to reveal the text input view, that text input view’s isHidden property is set to false; since it’s arranged inside a stack view, the stack view automatically reveals the view and adjusts its own intrinsic size; and then I simply call updatePresentationLayout(animated: true) to give my presentation controller a chance to resize the presented view based on these internal changes.

Note: Sometimes, the Auto Layout engine tries to update the layout of your presented view before the view’s frame has a chance to update, which will cause constraint conflicts if the views and constraints in your presented view no longer fit properly inside the old frame. A simple way to deal with this is to lower the priority of your bottom-most constraint to 999, which gives Auto Layout a bit of flexibility to properly sort things out when your layout is changing.

Wrap-up

Once you wrap your head around what the role of a custom presentation controller should be, there are a whole bunch of interesting things you can start do with it. In my custom transitions, my presentation controller is responsible for detecting the appearance of the keyboard, and adjusting the positioning of the presented view based on the keyboard’s frame. It communicates with the presented view controller (via CustomPresentable) to ensure that the current first responder is always visible between the top of the screen and the top of the keyboard. It also uses CustomPresentable to hide the status bar whenever the presented view is shifted beyond the top of the screen. You can see all this in action in the video at the top, as I start adding notes to my “Undertale” entry.

I’d love to share some of those implementation details another day; regardless, my hope at this point is that, having read this little series on custom view controller transitions, you now have all the tools you need to get creative and build your own fun, reusable, well-polished view controller transitions. It’s a tricky little API, but if you put a bit of effort into understanding it up front, it really does open up possibilities that otherwise might have felt overwhelmingly difficult or tedious to build.

So…go build something awesome! 🦸

For a working example of the techniques described here and in the other two articles in this series on custom view controller transitions, check out this repo on GitHub.

Thanks a bunch for following along. This is a relatively quick look at a pretty tricky topic, so if you need some help or have any follow-up questions, Let me know! Find me on Twitter here 🦆

Mastering view controller transitions, part 2: Make them feel natural

Thu, 27 Feb 2020 00:00:00 +0000

Mastering view controller transitions, part 1: make them reusable

As a quick refresher, here’s an example of the transitions we introduced in the first article, and that all this writing is based on:

Your browser does not support the video tag.

Okay, you’re up to speed! Let’s dive into the second goal.

Goal 2: I want my interactions to feel natural

Making interactions feel “natural” is a bit of a subjective thing, but for me, there were a few details I knew I wanted to get right when it came to dismissing my view controllers interactively. They’re all fairly obvious best practices when it comes to animating and interacting with views, but some of them can be a bit tricky to get right in the context of view controller transitions.

Keep in mind that an interactive transition can look like anything, really, and these tips aren’t universally applicable to any and all interactive transitions; rather, for the sake of example, these are focused primarily on “swipe down to dismiss” interactions, and the code samples are derived from my implementation of the “Tags” view being dismissed in the video above. My hope is for these to get you thinking about how you might add similar polish to your own transitions, even if they operate slightly differently than mine.

I also want to call attention to the fact that, while it might seem like a simple UIPercentDrivenInteractiveTransition could get us most of the way towards implementing my “Tags” view’s interactive dismissal, I ended up building my interactive transitions using my own implementations of UIViewControllerInteractiveTransition, rather than using or subclassing UIPercentDrivenInteractiveTransition. I had a whole thing written about all the issues I ran into, and why I made this decision, but it got a little bit out of hand and this post is already long enough as it is. So, although most of what’s in this post would apply in either case, just keep in mind that the code examples are based on a custom interaction controller. Maybe I’ll post about the trials and tribulations of adopting UIPercentDrivenInteractiveTransition one day; for now, let’s start looking at a few tips you might be able to use to make your interactive transitions feel great.

Use spring animations

When you’re animating the movement of views, don’t do this:

Your browser does not support the video tag.

Ew, yuck.

Instead, use spring animations. They make your animated views feel more like physical, real-world objects than they would with linear or easing curves, and are standard across iOS. Generally speaking, you can implement them with something like this:

let animator = UIViewPropertyAnimator(duration: 0.5, dampingRatio: 1.0) {
  // animate your thing
}

Or, if you’re old-fashioned, like this:

UIView.animate(withDuration: 0.5, delay: 0.0, usingSpringWithDamping: 1.0, initialSpringVelocity: 0.0, options: .allowUserInteraction, animations: {
  // animate your thing
}, completion: nil)

Next!

Take gesture velocity into account

For our views to feel like physical, real-world objects, we want them to have some momentum when we fling them around. To do this, we can take advantage of an oft-misunderstood parameter of spring animations: initialVelocity. This parameter is exactly what’s going to allow us to carry the velocity of our gesture into the animation that immediately follows, so that we don’t end up with something like this:

Your browser does not support the video tag.

Nope, don’t like this.

Unfortunately, there’s a reason this parameter is a bit misunderstood: it’s not quite as simple as grabbing the velocity from our gesture recognizer and plugging it in. While the gesture recognizer gives its x and y velocity in points/second, initialVelocity expects those values to be normalized to the total distance that the animation covers. So, when your gesture ends, and you’ve decided based on that gesture that the transition should be completed, here’s a condensed version of how you might set up your animation:

@objc func handleGesture(_ gestureRecognizer: UIPanGestureRecognizer) {
  guard let superview = gestureRecognizer.view?.superview else { return }
  let translation = gestureRecognizer.translation(in: superview).y
  let velocity = gestureRecognizer.velocity(in: superview).y
  // ...
  if gestureRecognizer.state == .ended {
    gestureEnded(translation: translation + interruptedTranslation, velocity: velocity)
  }
}

private func gestureEnded(translation: CGFloat, velocity: CGFloat) {
  finish(initialSpringVelocity: springVelocity(distanceToTravel: interactionDistance - translation, gestureVelocity: velocity))
}

private func springVelocity(distanceToTravel: CGFloat, gestureVelocity: CGFloat) -> CGFloat {
  distanceToTravel == 0 ? 0 : gestureVelocity / distanceToTravel
}

Not so hard!

Be smart about deciding whether to complete or cancel a transition

This one is somewhat related to the previous point: much like we should take velocity into account when performing our post-gesture animation, we should also take it into account when deciding which direction to animate in the first place. When the pan gesture is released, it might be tempting to simply evaluate whether the drag extended across a certain threshold: for example, if the gesture has travelled at least half the total dismissal distance, complete the dismissal, and otherwise, cancel it and animate back to the starting position. Unfortunately, this doesn’t end up feeling very natural:

Your browser does not support the video tag.

No, this certainly won’t do.

If the user flings your view down with some speed, they expect it to continue moving in that direction. So, you’ll want to add a bit of logic that looks something like this:

private func gestureEnded(translation: CGFloat, velocity: CGFloat) {
  if velocity > 300 || (translation > interactionDistance / 2.0 && velocity > -300) {
    finish(initialSpringVelocity: springVelocity(distanceToTravel: interactionDistance - translation, gestureVelocity: velocity))
  } else {
    cancel(initialSpringVelocity: springVelocity(distanceToTravel: -translation, gestureVelocity: velocity))
  }
}

This basically says that if there’s significant velocity in the dismissal direction, dismiss the view controller no matter what. Otherwise, only dismiss if the gesture has moved at least half the total distance, and there isn’t significant velocity in the opposite direction. I’ll note that 300 is a bit of a magic number here that you might want to tweak, but you definitely don’t want to just check whether the velocity is positive or negative; if the user stops their movement and lets go, it’s anyone’s guess whether the gesture’s final velocity will be slightly positive or slightly negative.

Make sure your interaction is always enabled

Nothing breaks the illusion of dragging physical objects around on a screen quite like suddenly and unexpectedly being unable to interact with an object you were just dragging around a second ago. Here’s what we don’t want:

Your browser does not support the video tag.

Woof.

Sure, it might seem like a bit of an edge case, and maybe costing your users a fraction of a second doesn’t seem like the end of the world, but this kind of behaviour can cause tiny moments of frustration and make it feel like there’s a bit of an unpredictable barrier between your users and the objects they’re trying to manipulate on screen. This was a bit tough to get right in my case, and I’m not sure this is the most elegant solution, but my basic approach is this:

Keep track of whether an interaction is in progress with an interactionInProgress flag. Set this flag to true as soon as a gesture begins, and only set it back to false when the cancellation animation finishes completely, i.e. the dragged view is completely at rest.
Only ever call viewController.dismiss() to begin the transition when the flag is flipped from false to true. End the transition only when the flag is flipped from true to false (by calling transitionContext.cancelInteractiveTransition() and transitionContext.completeTransition(false)).

This set-up effectively keeps your interaction “in transition” for as long as the user is playing with the dragged view — if the user lets go, but then grabs the view again as it’s animating back to its starting position, the interaction remains in transition throughout. This gives us the freedom to maintain the dragged view’s interactivity without having to worry about reporting the start and cancellation of the transition to UIKit over and over again (which can cause weird behaviour and crashes). How exactly you implement this pattern depends a lot on how your interaction controller is structured, so I’ll leave the details up to you!

Deal with scroll views

If you establish a swipe-down-to-dismiss pattern in your app, you want to make sure you don’t end up with cases where the user expects this pattern to hold, but it doesn’t. A common stumbling block arises when your presented view — the one you want to dismiss with a swipe — is entirely or largely made up of a vertical scroll view. (Remember, table views and collection views are scroll views too.) If the user swipes down on the scroll view, the scroll view consumes the gesture, effectively preventing the user from swiping to dismiss.

Your browser does not support the video tag.

This app is bad!

Of course, being able to scroll is kind of important too. So how do we reconcile these two conflicting gestures in a way that feels natural to the user? I think a nice solution is to simply decide which gesture handler to trigger based on whether or not the scroll view is scrolled to the top. In other words: if the scroll view’s vertical content offset is 0 or less, the swipe should be handled by the dismissal gesture; otherwise, it should be handled by the scroll view.

If you read my last post, you’ll know that a big priority of mine in building these transitions was to make sure it was easy to use them to present any view controller, from anywhere. So, from our interaction controller, how can we manipulate the gestures of a scroll view that may or may not exist inside a view controller that could be of any type?

Protocols!

In that last post, in my quest for reusability, I introduced a lightweight protocol that any view controller would have to conform to if it wanted to be presented in a custom way. Let’s add to this protocol:

protocol CustomPresentable: AnyObject {
  var transitionManager: UIViewControllerTransitioningDelegate? { get set }
  var dismissalHandlingScrollView: UIScrollView? { get }
}

extension CustomPresentable {
  var dismissalHandlingScrollView: UIScrollView? { nil }
}

We’ve added a read-only property, dismissalHandlingScrollView, and we’ve also used a protocol extension to give it a default nil value. This means that view controllers that conform to this protocol don’t have to specify a dismissalHandlingScrollView if they don’t have one, but those that do can specify one as follows:

class FilterSelectionViewController: UIViewController, CustomPresentable {
  var transitionManager: UIViewControllerTransitioningDelegate?
  var dismissalHandlingScrollView: UIScrollView? { self.tableView }
  // ...
}

Note that default protocol values have their drawbacks — for example, it means that when you’re conforming to CustomPresentable, it’s not immediately obvious that dismissalHandlingScrollView is a property you can or should implement — but I like that it minimizes the overhead of creating new custom presentable view controllers.

Since our interaction controller from last post was already initialized with a view controller that conforms to CustomPresentable, we now have access to any scroll view that might interfere with our dismissal gesture, and can handle it appropriately:

class StandardInteractionController: NSObject, InteractionControlling {
  private weak var viewController: (UIViewController & CustomPresentable)!

  init(viewController: UIViewController & CustomPresentable) {
    self.viewController = viewController
    super.init()
    prepareGestureRecognizer(in: viewController.view)
    if let scrollView = viewController.dismissalHandlingScrollView {
      resolveScrollViewGestures(scrollView)
    }
  }

  private func prepareGestureRecognizer(in view: UIView) {
    let dismissalGestureRecognizer = UIPanGestureRecognizer(target: self, action: #selector(handleGesture(_:)))
    view.addGestureRecognizer(dismissalGestureRecognizer)
  }

  private func resolveScrollViewGestures(_ scrollView: UIScrollView) {
    let dismissalGestureRecognizer = UIPanGestureRecognizer(target: self, action: #selector(handleGesture(_:)))
    dismissalGestureRecognizer.delegate = self

    scrollView.addGestureRecognizer(dismissalGestureRecognizer)
    scrollView.panGestureRecognizer.require(toFail: dismissalGestureRecognizer)
  }

  // ...
}

extension StandardInteractionController: UIGestureRecognizerDelegate {
  func gestureRecognizerShouldBegin(_ gestureRecognizer: UIGestureRecognizer) -> Bool {
    if let scrollView = viewController.dismissalHandlingScrollView {
      return scrollView.contentOffset.y <= 0
    }
    return true
  }
}

As you can see, resolving the scroll and dismissal gestures in our interaction controller is pretty simple. On initialization, we check to see if the view controller being presented has a dismissal handling scroll view. If so, we add a dismissal gesture recognizer to the scroll view, and specify that the scroll view’s panGestureRecognizer — the one that actually handles scrolling — should only be recognized if the dismissal gesture recognizer fails first. Finally, via conformance to UIGestureRecognizerDelegate, we set that dismissal gesture recognizer to fail if the scroll view isn’t currently scrolled to the top.

That’s all for now, folks. Using a few simple techniques, we now have an interactive transition that is not only highly reusable, but also feels pretty great to interact with. Hopefully a few of these come in handy the next time you’re duelling with interactive transitions! 🤺

For a working example of the techniques described here and in the other two articles in this series on custom view controller transitions, check out this repo on GitHub.

Thanks so much for reading my weird little blog. This is a relatively quick look at a pretty tricky topic, so if you need some help or have any follow-up questions, Let me know! Find me on Twitter here 🦆

Mastering view controller transitions, part 1: Make them reusable

Mon, 24 Feb 2020 00:00:00 +0000

Last week, I wrote a primer on how custom view controller transitions actually work. If you missed it and are relatively new to this stuff, or want a quick refresher, you might want to check it out here.

This week, I’m doing a set of 3 short articles that explore some more advanced, concrete ideas around custom transitions. This was originally intended to be one relatively straightforward article, but apparently I’ve got a lot to say about this stuff (or maybe I’m bad at editing 🤔), and I decided that putting out a monolithic 8000 word piece probably wasn’t the most palatable choice. So, each article will revolve around one goal I had in mind as I built some nice custom transitions into my own app, and will detail the solutions I came up with in trying to achieve that goal.

To get us all on the same page, let’s take a look at a couple of these transitions in action. You’ll see two different view controllers presented: the “Add game” view controller, and the “Tags” view controller. Both are presented using the same animation and presentation controllers, but they use different interaction controllers on dismissal — “Tags” can be quickly and easily swiped away, while “Add game” is a more deliberate interaction that requires the user to drag a certain distance before releasing, and that includes some decoration views as part of the interaction.

Your browser does not support the video tag.

There are some cool things going on behind the scenes here that all add up to what I think is a pretty nifty user experience. Let’s talk about goal number one!

Goal 1: I want a dead-simple way to use my custom transitions

This first goal actually isn’t directly relevant to the end-user experience, but is VERY relevant to me, the developer, who doesn’t want a total mess on his hands as he starts using his custom transitions in different contexts throughout the app. And, let’s be real: all technical debt seeps into the user experience eventually! So, let’s figure out how to make sure our custom transitions are easy to use and reuse.

As I mentioned last week, the “transitioning delegate” responsibility often falls on the presenting view controller by default. In the most naïve case, this means that every time you want to present something using a custom transition, you need to implement a bunch of delegate methods in your presenting VC, giving it responsibilities it probably shouldn’t really have. Furthermore, if you want to support an interactive dismissal gesture, you might end up implementing a gesture handler inside your presented view controller — its view is where the gesture is happening, after all — and then figure out some way to hook up your gesture handling code to the interaction controller that your presenting view controller owns.

There may be some hypothetical cases where this approach is passable — namely, if you know you’re building a very specific custom transition that’s only ever going to be used in one place. In my case, however, I knew I wanted to be able to present any view controller, from anywhere, using my custom transitions. In other words, I didn’t want to have to keep reimplementing gesture handlers and UIViewControllerTransitioningDelegate methods every time I wanted to use my transitions.

My solution starts with the idea that we should have a dedicated class to serve as the transitioning delegate for our custom modal presentations — we’ll call it ModalTransitionManager. As the transitioning delegate, it’s simply responsible for vending presentation, animation and interaction controllers when asked. It might look something like this:

class ModalTransitionManager: NSObject {

    private var interactionController: InteractionControlling?

    init(interactionController: InteractionControlling?) {
        self.interactionController = interactionController
    }
}

extension ModalTransitionManager: UIViewControllerTransitioningDelegate {

    func presentationController(forPresented presented: UIViewController, presenting: UIViewController?, source: UIViewController) -> UIPresentationController? {
        return ModalPresentationController(presentedViewController: presented, presenting: presenting)
    }

    func animationController(forPresented presented: UIViewController, presenting: UIViewController, source: UIViewController) -> UIViewControllerAnimatedTransitioning? {
        return ModalTransitionAnimator(presenting: true)
    }

    func animationController(forDismissed dismissed: UIViewController) -> UIViewControllerAnimatedTransitioning? {
        return ModalTransitionAnimator(presenting: false)
    }

    func interactionControllerForDismissal(using animator: UIViewControllerAnimatedTransitioning) -> UIViewControllerInteractiveTransitioning? {
        guard let interactionController = interactionController, interactionController.interactionInProgress else {
            return nil
        }
        return interactionController
    }
}

The only tricky thing to notice here is the way the interaction controller is handled. Since UIKit uses the return value of interactionControllerForDismissal(using:) as an indication of whether or not the dismissal should be performed interactively, our modal transition manager can’t simply create and return a new interaction controller here like it does with the animation and presentation controllers; if it did, UIKit would always assume a dismissal was happening interactively, and wait for interactive updates, even if the user tapped a button to dismiss the view non-interactively. This wouldn’t be an issue if the only way to dismiss our presented view controller was via an interaction, but in our case (and probably in most cases), it’s important that our users can dismiss with a gesture or with the tap of a button.

So, our ModalTransitionManager keeps a reference to an optional interaction controller, and the interaction controller itself knows if a dismissal has been triggered by a gesture via its interactionInProgress property (more on that in a sec). In this way, our ModalTransitionManager has the information it needs to either return an interaction controller, telling UIKit “yep, let’s do an interactive dismissal,” or return nil to say “no, just animate this dismissal non-interactively.”

Of course, our ModalTransitionManager needs to be owned by someone from the beginning of presentation until the end of dismissal so that it can communicate with UIKit as needed. To make sure of this, let’s write a CustomPresentable protocol that every custom-presented view controller will conform to, and that ensures that the presented view controller keeps a strong reference to the ModalTransitionManager:

protocol CustomPresentable: AnyObject {
    var transitionManager: UIViewControllerTransitioningDelegate? { get set }
    // ...
} 

With this in place, we’ve taken the transitioning delegate responsibility out of our view controllers, and moved it into a separate object that the presented view controller keeps a reference to, but otherwise doesn’t care about.

The second thing to address is implementing a gesture handler on our presented view that can control the dismissal interaction. Instead of doing it inside the presented view controller, we can move this responsibility into the interaction controller itself. First, we create a simple protocol that inherits from UIViewControllerInteractiveTransitioning:

protocol InteractionControlling: UIViewControllerInteractiveTransitioning {
    var interactionInProgress: Bool { get }
}

This enforces that any interaction controller we build must be able to report when an interaction has started; we used this property in our ModalTransitionManager above.

Now, we can build an interaction controller that’s responsible for handling gestures, and therefore knows when to set interactionInProgress to true:

class StandardInteractionController: NSObject, InteractionControlling {
    var interactionInProgress = false
    private weak var viewController: (UIViewController & CustomPresentable)!

    init(viewController: UIViewController & CustomPresentable) {
        self.viewController = viewController
        super.init()
        prepareGestureRecognizer(in: viewController.view)
    }

    private func prepareGestureRecognizer(in view: UIView) {
        let gesture = UIPanGestureRecognizer(target: self, action: #selector(handleGesture(_:)))
        view.addGestureRecognizer(gesture)
    }

    @objc func handleGesture(_ gestureRecognizer: UIPanGestureRecognizer) {
        guard let superview = gestureRecognizer.view?.superview else { return }
        let translation = gestureRecognizer.translation(in: superview).y
        let velocity = gestureRecognizer.velocity(in: superview).y

        switch gestureRecognizer.state {
        case .began: gestureBegan()
        case .changed: gestureChanged(translation: translation + interruptedTranslation, velocity: velocity)
        case .cancelled: gestureCancelled(translation: translation + interruptedTranslation, velocity: velocity)
        case .ended: gestureEnded(translation: translation + interruptedTranslation, velocity: velocity)
        default: break
        }
    }
    
    private func gestureBegan() {
        if !interactionInProgress {
            interactionInProgress = true
            viewController.dismiss()
        }
    }
    // ...
}

Of course, there’s a lot more than that going on in the full implementation, but this gives you the idea: our interaction controller is initialized with the presented view controller, and is responsible for installing and responding to the gesture recognizer, allowing us to set interactionInProgress to true before having UIKit kick off the dismissal, and making it trivial to get subsequent gesture updates through our interaction controller to UIKit.

Finally, this is all tied together with a simple UIViewController extension:

enum InteractiveDismissalType {
    case none
    case standard
    case input
}

extension UIViewController {
    func present(_ viewController: (UIViewController & CustomPresentable), 
                 interactiveDismissalType: InteractiveDismissalType, 
                 completion: (() -> Void)? = nil) {

        let interactionController: InteractionControlling?
        switch interactiveDismissalType {
        case .none:
            interactionController = nil
        case .standard:
            interactionController = StandardInteractionController(viewController: viewController)
        case .input:
            interactionController = InputInteractionController(viewController: viewController)
        }

        let transitionManager = ModalTransitionManager(interactionController: interactionController)
        viewController.transitionManager = transitionManager
        viewController.transitioningDelegate = transitionManager
        viewController.modalPresentationStyle = .custom
        present(viewController, animated: true, completion: completion)
    }
}

Here’s where we actually kick off the custom presentation. The caller can specify the type of interactive dismissal, which dictates which interaction controller is created. The ModalTransitionManager is created and assigned to the view controller we want to present — we need to hold onto it strongly in the transitionManager property, because transitioningDelegate is a weak reference — and then we present the view controller.

What does this all mean? It means that we can now present any view controller, from anywhere, and get all our desired animation and interaction behaviour, by simply making sure our presented view controller conforms to CustomPresentable:

final class CoolViewController: UIViewController, CustomPresentable {
    var transitionManager: UIViewControllerTransitioningDelegate?
    // ...
}

…and then calling our presentation method:

let coolViewController = CoolViewController()
present(coolViewController, interactiveDismissalType: .standard)

…and everything else works like magic. That’s a whole lot of complexity we no longer have to think about. Pretty cool 😎

For a working example of the techniques described here and in the other two articles in this series on custom view controller transitions, check out this repo on GitHub.

Thanks for reading! This is a relatively quick look at a pretty tricky topic, so if you need some help or have any follow-up questions, Let me know! Find me on Twitter here 🐦

Going indie, step 4: Wrap your head around custom view controller transitions

Wed, 19 Feb 2020 00:00:00 +0000

In the first few steps of this series, we’ve talked a bit about the idea that the success of any app — and especially a small indie project — often hinges on the quality of execution. An app that is thoughtfully designed and makes obvious the amount of care and polish that went into building it likely stands a much better chance of capturing some real interest than one that feels same-y or slapped together.

This week, I want to start looking at an aspect of UIKit development that plays a huge role in creating that feeling of polish and care, but that, in the past, I’ve found to be a bit of a pain to work with: custom view controller transitions!

So much fun!

In building my definitely-soon-to-be-critically-acclaimed indie app, a big goal of mine has been to try not to compromise on design ideas because of complications or inconveniences in implementation. One place UIKit makes it really tempting to compromise is in presenting and dismissing view controllers. Do you really want to have to figure out what makes subclassing UIPercentDrivenInteractiveTransition different from implementing your own class conforming to UIViewControllerInteractiveTransitioning…or would you rather just call present(_:animated:) and move onto the fun stuff?

Well, in the name of lofty design ideals, I decided that custom view controller transitions ARE the “fun stuff”, damn it, and I hunkered down and endeavoured to truly, totally, finally wrap my head around this whole clustercuss of classes and protocols. Although I’m not sure I’ll ever feel like I’ve quite reached the summit of this treacherous climb…I’ve built some cool stuff and learned a bunch along the way. Let’s get into it!

What this is, and what it is not

This is really just meant to be a primer on the roles of each of the entities involved in a custom view controller transition — there’s a lot to keep track of, and in trying to master this stuff, I personally found it really helpful to take the time to step back and fundamentally understand what each of the relevant classes and protocols are responsible for before jumping into building anything. This isn’t a step-by-step tutorial with code examples — there are plenty of those out there — but rather, an attempt to explain the basic building blocks of custom view controller transitions in a way that’s useful, easy to digest and quick to refer to when things start to get blurry. Basically, it’s what I wrote for myself to make sure I fully understood what I was doing, and wasn’t depending on anything that felt like magic.

Note from the future: I’ve written a series of 3 articles on some more concrete, advanced topics having to do with custom view controller transitions. If this article is a bit too simple for you, feel free to jump ahead! Here’s the first one.

Before getting started, I have one more important thing to say:

Read the documentation! It’s quite good!

Because custom transitions can feel pretty overwhelmingly complicated, and the docs are admittedly a bit dense, it can be tempting to skip them and just go hunting for a tutorial that’s going to hand you all the code you need. What I’ve found is that a lot of the tutorials out there do things quite differently from one another, and they often struggle to explain why exactly they’re doing things in a particular way, or how their implementation might be tweaked or extended to do different or more complex things. Apple’s own documentation might not give you a bunch of code you can paste directly into your project, but it will help you understand what the cuss is actually going on.

So, consider this to be a concise companion guide to Apple’s helpful but heavy documentation. It’s not a replacement, and neither is any tutorial you find on the internet. Actually, that’s true of pretty much any development topic, but I digress. Onwards!

The anatomy of a custom view controller transition

Note: I’m dealing specifically with custom modal transitions here; a lot of this is also applicable to customizing navigation controller transitions, for example, but that’s not really within the scope of this article.

Presenting view controller & presented view controller

This terminology isn’t unique to custom transitions, but it is important to get right, so let’s make sure we’re on the same page. Imagine you have a HomeViewController, and from there, you present a WarningViewController. HomeViewController is the presenting VC, and WarningViewController is the presented VC. Easy peasy.

Container view

In the context of a custom transition, the container view is a view that’s created and managed by UIKit, and that contains both the presenting and presented views during the transition. If your transition includes any custom views that aren’t part of the presenting or presented views, you’ll add them to the container view as well.

UIViewControllerAnimatedTransitioning

Your implementation of this protocol is known as an animation controller, and is responsible for actually animating the transition between view controllers. It has access to both the presenting and presented view controllers, which allows it to animate their view frames into place, or to manipulate other properties of the view controllers and their views. It also has access to the transition’s container view if needed. You could implement two animation controllers to handle presentation and dismissal separately, but it often makes sense to have a single animation controller that covers both presentation and dismissal animations, and that knows which direction to perform the animation in based on a simple isPresenting property.

UIViewControllerInteractiveTransitioning

A concrete implementation of this protocol is known as an interaction controller. An interaction controller is only necessary if you want to allow your transition to be driven by some sort of gesture. A simple example of this is a case where you want to be able to dismiss your presented view controller with a swipe, and have the view’s movement correspond with your finger’s movement. UIKit provides a specific implementation of this protocol — UIPercentDrivenInteractiveTransition — that, given continuous updates about the gesture as it’s performed, can automatically use your existing animation controller to figure out where your animated views should be throughout the gesture. You can also implement your own interaction controller to get more fine-grained control over the interactive transition. Either way, an interaction controller needs to be fed continuous updates on the state of the gesture, and is responsible for translating these into visual updates to the involved views. Like animation controllers, interaction controllers have access to both the presenting and presented view controllers, as well as the transition’s container view, giving you precise control over how the interaction impacts the various views on screen.

UIPresentationController

Every view controller transition — custom or standard — is driven by a presentation controller that’s responsible for managing the whole thing, from the start of presentation to the end of dismissal. A presentation controller has direct access to the presenting and presented view controllers and the transition’s container view, and knows about when presentations and dismissals begin and end. Although a custom presentation controller isn’t necessarily required to build simple custom view controller transitions, it’s typically needed when you want to add decoration views to the container view during transition (e.g. a dimming view: darkening the screen behind some sort of popup), or when you want some dynamic control over the size and positioning of the presented view (e.g. responding to changes in content or screen size).

UIViewControllerContextTransitioning

The transition context provides contextual information about the transition as it occurs. Remember how I said that both animation controllers and interaction controllers have access to the presenting and presented view controllers? This is true thanks to the transition context — both animation and interaction controllers implement methods that are called by UIKit and given a transition context to work with. The transition context provides access to the views and view controllers involved in the transition, along with details about the transition, such as what the frame of the presented view controller should be at the end of the transition, or whether the transition is currently being driven interactively. Interaction controllers also use the transition context to report the interaction’s progress and completion to UIKit.

UIViewControllerTransitioningDelegate

The transitioning delegate is really what ties together everything described above. Your transitioning delegate is responsible for vending the various objects that are needed to perform your custom transition: a custom presentation controller, animation controller(s) and interaction controller(s). In other words, it needs to know how to create or otherwise have access to each of these controllers. In simple examples, you’ll often see the presenting view controller playing the role of transitioning delegate, although creating a dedicated class is often a better approach. With a transitioning delegate in place, we can now instruct UIKit to use our custom transition by simply assigning the transitioning delegate to the VC we want to present, and setting the modal presentation style to custom.

So how exactly does it all fit together?

It’s tempting to want a single, “correct” answer to this question. How do I know if I’m doing it right? Unfortunately, like pretty much anything in software development, there are lots of different ways to actually piece together your custom transitions, each with their own set of trade-offs. Nonetheless, to provide a bit of clarity, let’s step through some simplified presentation and dismissal cases to start to get a sense for how the various entities behave, and how they communicate with each other.

Animated presentation

We want a WarningViewController to be displayed on-screen using a custom transition when a button is tapped in HomeViewController. HomeViewController conforms to UIViewControllerTransitioningDelegate, so we can use it as the transitioning delegate for our custom transition.

Our custom transition begins the moment present(_:animated:) is called. I’ve written a short, bad play about it, because it’s honestly a much more readable way to describe the flow of information than dryly describing every technical step 🎭

[Applause, curtains rise]

HomeViewController
Oh hey UIKit, can you help me present this WarningViewController?

UIKit
Yeah, let’s do it. Okay, says here you’re the transitioning delegate, so…do you have a presentation controller for me?

HomeViewController
Yep, here’s a FancyWarningPresentationController.

UIKit
Perfect, thanks. [Starts setting things up behind the scenes by creating the container view, transition context, etc.] Okay, I’m also going to need an animation controller to actually present this thing.

HomeViewController
Oh right, here’s a FancyWarningAnimationController you can use. I’ve made sure it knows to present rather than dismiss.

UIKit
Good, good. Do you have an interaction controller for me as well?

HomeViewController
Nah, let’s just present this one non-interactively.

UIKit
Sure! Let’s get started then. Hey presentation controller, FYI: we’re about to start the transition.

FancyWarningPresentationController
Got it. [Adds a dimming view to the container view.] Hey UIKit, can you make sure this dimming view fades in at the same time the rest of the presentation animation is happening?

UIKit
Yep, no problem. Also, where do we want the WarningViewController to end up on screen? The animation controller’s going to want to know.

FancyWarningPresentationController
Let’s just have it cover the bottom half of the screen.

UIKit
Works for me. Okay, animation controller? You’re up. Everything you need should be here in this transition context. Let me know when you’re done.

FancyWarningAnimationController
Roger that. [Beautifully animates WarningViewController into view.] And….done.

UIKit
Nailed it. Thanks everyone!

[End scene]

Interactive dismissal

Let’s assume a pan gesture recognizer is set up on our WarningViewController’s view to handle the dismissal interaction. Where the gesture handler is actually implemented isn’t terribly important, as long as it has a direct line to the interaction controller. As soon as the gesture begins, we call dismiss(animated:), and thus begins our second short play about an interactive dismissal.

[A clear, crisp fall morning. The old Mac startup sound plays off in the distance.]

WarningViewController
Hey, uhh…UIKit, is it? Weird question, but: can you dismiss me?

UIKit
Yeah, no problem. I see here that your transitioning delegate is HomeViewController — oh yeah, I remember helping them present you a while back. I’ll get in touch with them and we’ll have you dismissed in no time.

[UIKit picks up the phone and calls HomeViewController.]

HomeViewController
Hello?

UIKit
Hey, me again. WarningViewController needs to be dismissed, and since you’re their transitioning delegate, I’ll need a few things from you again.

HomeViewController
Oh yeah no problem! You still have that presentation controller I gave you, right?

UIKit
Yep, I’ve been holding onto that.

HomeViewController
Okay, here’s another FancyWarningAnimationController for you to use — this one’s set to dismiss. And, I know WarningViewController only ever dismisses interactively, so you should take this UIPercentDrivenInteractiveTransition as well — there’s already a gesture handler set up who knows how to use this.

UIKit
Brilliant! Okay, let’s make it happen. Presentation controller, we’re about to start the transition.

FancyWarningPresentationController
Sounds good. I’m going to fade out this dimming view — can you make sure the timing lines up nicely with the gesture?

UIKit
Will do. Now, animation controller, interaction controller, here are your transition contexts. Do your thing!

[FancyWarningAnimationController, UIPercentDrivenInteractiveTransition, and the gesture handler all huddle together. As the pan gesture progresses, the gesture handler reports progress to UIPercentDrivenInteractiveTransition, who works with FancyWarningAnimationController to figure out what the views involved in the transition should look like at the given progress level. As a team, they continuously update WarningViewController’s position to reflect the progress of the dismissal. It’s a sight to behold. Eventually…]

Gesture handler: And……DONE!

[FancyWarningAnimationController completes the dismissal animation and gives UIKit the good news. They all look at each other contentedly. Their work here is done.]

Wrap-up

That may have gotten a bit silly and oversimplified, but honestly, when you’re new to this stuff, it’s already a lot to take in, and I needed to wrap this up. There are a lot of moving parts here, they all interact with each other in less-than-obvious ways, and it can be hard to figure out exactly who should be responsible for what. As someone who is in the midst of building what could very well be my final full-fledged UIKit project, I wanted to make sure I had a really firm understanding of this whole view controller transitioning API, and could properly make use of it to build exactly what I wanted. I hope sharing some of that knowledge in a lighthearted way helped clarify some things for a few folks out there! If, on the other hand, you:

a) think this whole thing still seems wildly overcomplicated, and
b) are able and willing to build whatever it is you’re building with a promising, but young and somewhat janky new set of tools…

SwiftUI might be looking pretty good to you right about now 😏

Thanks for reading! This is a relatively quick look at a pretty big topic, so if you need some help or have any follow-up questions, Let me know! Find me on Twitter here 🐦

Going indie, step 3: Build your core interaction loop

Tue, 11 Feb 2020 00:00:00 +0000

We’ve got a great little idea for an app. Our project is all set up and ready to go. Get excited: the time has finally come to start building this thing!

…So where do we start?

This is actually kind of a tricky question. Here are a few options that might spring to mind:

We could just sort of…start from the beginning. We could simply imagine the first thing a user will encounter — account creation? — and build out organically from there.
We could start by architecting and building some of the underlying systems we know we’ll need in the app — networking, data persistence, etc — before working our way up to the app’s business logic and UI.
We could hold off on writing code, and instead start by diving deep into developing plans and designs describing exactly what the app should do and how it’s all going to fit together.
We could go full TDD and start by writing tests for the app’s core business logic! 🧐
We could start by building a quick and ugly prototype of our basic app idea, allowing us to test it out early and evaluate what might or might not work.

There’s probably some sort of argument to be made in favour of each of these — some stronger than others! However, none of the above feel quite right to me. When starting something new, I have three priorities in mind:

Validate. If there’s some reason this app idea isn’t going to pan out in the way I expect it to, I want to know as soon as possible. That means I want to spend most of my time initially exploring what’s essential about that idea and proving that it works, rather than on the supporting features I’ll eventually build around it.
Avoid wasted effort. I’ve got other important work on the go, and I’m getting paid exactly $0/hr to noodle away on my indie project, so I personally don’t have much of an appetite for work that I’ll ultimately throw away. As much as possible, I want the work I do from the outset to be high-quality and potentially shippable. It also means I want to avoid over-engineering solutions to problems I may not yet fully understand in the context of this particular app.
Build momentum. On day one, I want to be working on the stuff that really excites me. Keeping momentum up throughout an app development cycle is tough — I’m sure lots of us have folders full of half-baked, abandoned ideas we were once really jazzed about. By starting off doing work I know I love, I’ll feel creatively energized and make progress quickly. With any luck, this will lead me to new ideas I’m excited to explore and help keep the ball rolling in the future.

Guided by these priorities, I’ve taken a very particular approach to writing my first few hundred lines of code. While I don’t think there’s anything outlandish about it, it is a little bit at odds with some of the more typical approaches to building products I’ve taken with teams in the past. Regardless, it’s worked for me, and it might serve as a good starting point for you too. Let’s break it down into three parts.

Part 1: Identify your core interaction loop

If you google “core interaction loop”, you’ll see…nothing, really, because it turns out I may have accidentally made it up. Let’s talk about it anyways!

In game design [disclaimer: I am not actually a game designer and have no idea what I’m talking about], there’s this concept of a core gameplay loop: it basically describes the primary system or mechanic that players will interact with repeatedly, and that the rest of the game is built around. It’s a bit of a loosey-goosey term, but one way to understand it is as the thing that you really have to “get right” to keep people interested — if the core loop isn’t fun and engaging, no amount of world-building or tacked-on subsystems will make the game enjoyable.

When I say “core interaction loop,” I guess I’m just adapting this idea to the broader world of app development. Your core interaction loop is the fundamental thing that users will be coming into your app to do the majority of the time. It’s the basic, repetitive use case that props up the rest of the app, and that you know you need to really nail if you want your users to stick around.

As a dead-simple example, consider a weather app. Weather apps tend to have a handful of features outside of the core interaction loop: tracking multiple locations, sharing forecasts, advanced radar maps, etc. But unquestionably, the thing that any decent weather app has to get right is providing a simple answer to the question: “What’s the weather like today?”

Of course, not every app has such a clear and concise use case to zero in on. But, if you feel your app has a few candidates, consider which of them users will likely be performing most often, and which of them is closest to the heart of what you think makes your app unique and valuable. If you’re building a to-do list app, and you’ve invented some wacky, never-before-seen way to add new items to a list, consider that to be your core interaction loop.

Part 2: Identify what’s going to make it great

I’ve mentioned it before, but in case you missed it: there are a whole lot of apps on the App Store. Whatever your brilliant app idea is, how you execute it is going to play a huge role in whether you’re able to stand out from the crowd. And, nowhere is that execution going to be more impactful than within your core interaction loop.

So, what is it about your particular take on this interaction that’s going to make it a great experience for your users? Are there ways in which you want to allow your users to accomplish some task and get back to real life as quickly as possible? Do you have ideas on how to make a relatively complicated interaction surprisingly intuitive? Are you focused on crafting a delightful experience that makes your users smile? Figure out what your priorities are, and start thinking about ways you might design and implement your core interaction loop to reflect these priorities.

Part 3: Build it, and then polish it, and then tweak it and polish it some more

There’s this idea I hear bouncing around a lot that goes something like this: if the basic idea of your product is compelling and worth building, users will use it despite any flaws or broken pieces or ugliness. A similar approach sometimes comes out of “agile” development processes, especially in teams that tend to be more business-driven: “Let’s get to a basic MVP as quickly as possible, ship it, get feedback and iterate.” This suggests that maybe our goal from the outset should be to build the simplest possible version of our app, get it into people’s hands as soon as we can, and save the polish for later.

There’s definitely some wisdom in that kind of approach, and I’m not really willing to argue with it directly. However, I’ll say a couple things:

Call me an artsy idealist, but I’m personally always a bit bummed about building and shipping minimum viable products that, by definition, are incomplete, include disappointing omissions and are just…kind of hard to love.
Often, especially in smaller indie projects, what makes a product compelling and worth building actually isn’t the idea at all, but the impressive attention to detail, the personal touches, or the singular design. Rushing to build basic functionality might lead you to lose sight of the stuff that’s actually going to set you apart and attract users in the first place.

So, now that you’re finally ready to sit down and start creating your chef d’oeuvre, here’s my arguably unorthodox suggestion for what to do first: design and build the core interaction loop we’ve identified — that small but oh-so-crucial sliver of your app — and polish the cuss out of it. Build something that checks all the boxes you identified in part 2. Build something that looks and feels great, and that you’d be thrilled to release into the world tomorrow morning if the rest of the app magically appeared overnight. Build something you love! In my experience, the indie iOS community truly values the most thoughtful, polished and well-crafted apps; why not strive for just that from the get-go?

It’ll take time, and that’s okay. If you’re anything like me, you’ll be energized by diving headfirst into the heart of your app and seeing something special come to life early on. And crucially, by nature of this being a central piece of your app, you’ll come up with tons of peripheral ideas along the way as you gain clarity on how the rest of the app is going to fit into what you’re building.

There will be plenty of time to iterate and make changes later — what you build at this early stage almost definitely won’t ship exactly as-is. But with the care and effort you put into it right off the bat, much of what you build here should stick around over time and help define the structure and design of the rest of the app. In the meantime, what you’re building now acts as a high-fidelity prototype that should give you some real insight into how your basic idea feels to use, and help you decide whether you want to keep investing time and effort into it.

Note: something I’ve left open-ended here is the question of whether you should be building a complete vertical feature, i.e. whether, where applicable, you should be implementing networking or data persistence layers to support the core interaction loop you’re building. I’ll leave it open-ended for now — I think it depends somewhat on what exactly you’re building, and what you think is important or valuable about it — but I will say that in my particular case, I’ve stubbed out those lower-level layers, because they’re ultimately meant to be largely invisible to the user during the core interaction loop anyway. My suggestion: focus on user experience, and keep the scope of your implementation as narrow as you can.

So go make yourself a coffee, clean up your desk, put on some tunes and start building your dang thing. Get lost in it for a little while, have some fun, and build yourself a small but essential slice of app that’ll get you excited to build more. There’s no better feeling than seeing creative work you’re proud of come to life!

✨🧑‍💻✨

If you: a) think this article is full of great ideas, or b) think this article is full of terrible ideas, I’d love to hear from you! Find me on Twitter if you have any questions or thoughts 🐦

Going indie, step 2: Act like a chef

Mon, 03 Feb 2020 00:00:00 +0000

Last week, we figured out what it is we actually want to build. Now, armed with a killer idea, we’ve got one more step to take before we can really start thwacking away at the keyboard and creating our indie masterpiece.

There’s a great concept in cooking called mise en place, which basically says that it’s crucial to have all the required tools and ingredients neatly laid out in your workspace before you start making any food. By keeping things clean and decluttered, and by ensuring that everything you need is within arm’s reach, you give yourself the mental space to focus on the creative and skillful bits of the job and avoid dumb mistakes.

I love this concept. It makes cooking a whole lot more pleasant, and it can be usefully applied to a bunch of things that have nothing to do with cooking. Think of the difference between a clean, decluttered desk on top of which everything you need is neatly arranged, and one that’s full of old junk, where you can’t find the notebook you need, the desk lamp is flickering and your mouse’s battery level is at 3%. Which are you going to do better work at?

This post isn’t about cleaning up your desk. (Although, hey, never a bad idea.) Rather, I think there’s a simple but useful way to borrow this idea from the world of French cuisine and apply it to a brand new Xcode project.

Creating a new project is exciting as heck. Think of the unexplored possibilities! The boundless potential! Zero technical debt! It’s tempting to jump right in and starting pounding out what is, surely, the best code you’ve ever written. But if you ever want to become the Michelin star chef of indie app development you’ve always dreamed of becoming…consider first devoting a few minutes to your mise en place.

Of course, building an app is nothing like following a recipe. Unlike most cooks, we rarely know every tool and ingredient we’re going to need ahead of time. Nonetheless, putting some thought into setting up a project that feels tidy and includes a few go-to tools can help get the mundane and annoying parts of app development out of the way, and allow you to focus on doing your best creative work right off the bat.

What exactly your setup should look like is entirely up to you, and depends on what makes you feel comfortable and efficient. But, as an example, here are a few simple things I do with any new project I start to help me hit the ground running.

Tweak the template

When you create a new project, the files that are created automatically are full of comments. They’re helpful if you’re new to this stuff; otherwise, they just take up a bunch of space. Delete! I’m also not a huge fan of storyboards — not a value judgment, just a personal preference when I’m working solo — so I typically get rid of the storyboard file, and instead get my view controller hooked up by adding it to the window in my SceneDelegate. You do you.

Add SwiftLint

SwiftLint is a simple but indispensable tool for maintaining good habits when it comes to code style and convention. It’ll encourage you to keep your code clean and consistent, which I think is a crucial thing to strive for from the very first line of code you write — getting into bad habits early on will always come back to bite you down the road, even if the code is all yours. That said, it’s also important to be a bit pragmatic about style guides, so don’t be afraid to use SwiftLint’s many configuration options to fit it to your needs. I’ve got my own .swiftlint.yml file that I use as a starting point for any new project.

Set up third-party libraries

I’ll start this section with a caution: there are a lot of good reasons not to overdo it with third party dependencies, and I’d be especially careful not to prematurely add libraries you think might come in handy. That said, maybe there’s a simple library that you love using and that‘s generally useful to you in all your projects; if so, now’s the time to get it set up. At the moment, for me, that library is Cartography: a beautiful little DSL for setting up Auto Layout constraints programmatically. A lot of fun people have a lot of fun opinions on whether Auto Layout is bad, whether it belongs in code or in Interface Builder, and whether using a 3rd party library for constraints is misguided. Personally, I love Auto Layout, I’ve been building good chunks of my UI programmatically of late, and I’m a big fan of Cartography’s simple declarative syntax. In my own personal projects, it’s a no-brainer. Your mileage may vary; use the tools that make you feel comfortable and productive. (And, uh, maybe best saved for another discussion, but do try to make sure your dependencies are actively maintained, and that their discontinued existence won’t submarine your app.)

Note: For the first time ever, I’m using Swift Package Manager to manage dependencies instead of CocoaPods. And speaking of mise en place: as much as CocoaPods has been a fantastic tool for many years, I must say it’s a joy to be rid of some of the clutter that CocoaPods introduces into an Xcode project. Worth checking out if you haven’t already 👀

Add any personal tools

I also have a few of my own bits of code — mostly simple UIKit and Foundation extensions — that I tend to import into any new project I start. These are largely straightforward things like factory methods for creating commonly used UIKit objects, methods for applying good-looking shadows to views, shortcuts for adding and removing child view controllers to containers, etc. It’s nice to build up your own personal library of these sorts of tools and helpers that you can then modularize and easily take with you into any new project you start. If this isn’t something you’re already doing, consider this the next time you find yourself extending functionality, creating a new type or solving some sort of general problem: might some version of this piece of code be useful in a future project? If so, it might be worth spending a few extra minutes polishing it up for general use and popping it out into your own personal toolkit.

Get git going

Finally, once all this stuff is set up and ready to go, it’s time to commit your changes and push them to Github (or wherever you happen to be hosting your repo). Make sure you’ve got a good .gitignore file (here’s a good template) to avoid pushing unnecessary junk. Write the perfect commit message, and revel in the satisfaction of the first of many squeaky clean commits!

Admittedly, everything I listed above is, at least for more experienced folks, pretty straightforward. And to be clear, the point here isn’t that adding SwiftLint three commits in makes you tangibly worse off than adding it right away. The point is simply that on the whole, I think there’s real value in spending a bit of time up front thinking about what you’re building, and setting up your environment in a way that neatly accommodates the work you’re about to do. It’s only going to get harder to keep things tidy and intentional as your project grows in complexity; might as well start off on the right foot 🏃

That’s step 2 in the books. Isn’t this easy? We’ll have our indie hit shipped in no time. I’d love to hear your thoughts on this one: got any tools or tips for starting up a brand new project? Do you think any of this even matters? Find me on Twitter if you have any questions or thoughts 🐦

Going indie, step 1: Come up with an idea

Mon, 27 Jan 2020 00:00:00 +0000

Back in the early days of the App Store, a prevailing sense quickly grew that all you needed to become an overnight success was a great new idea for an app. I’m not sure that was ever really true, but certainly, it was easier then to stand out on the strength of a unique idea, and build a successful app around it, than it is today.

I think that idea of the App Store as a get-rich-quick machine still lingers to this day — I still often run into people who, upon learning what it is I do for a living, excitedly tell me about their great idea for an app, convinced that if only they could get someone to build it for them, it’d be an instant hit. The reality, of course, is that the App Store that launched in 2008 with 500 apps now has close to 3 million. It’s crowded out there, it’s hard to get noticed, and the way in which the idea is executed is a whole lot more important than the idea itself.

So then, what does make for a good “app idea” in 2020? As an indie app developer, how can you make sure you’re pursuing an idea that actually has a shot at gaining some traction in a crowded space?

😐

Actually, I really don’t know. Nevertheless, in starting up my current project, I’ve tried to stick to a few guidelines that I think will help increase the app’s chance of finding an audience, should it ever find its way onto the App Store. These aren’t scientific or foolproof; they’re just a handful of simple ideas I’ve chosen to keep in mind based on past experience, and on what I’ve seen in the iOS community recently.

Don’t try to take over the world

This one feels pretty obvious to me, but is worth mentioning nonetheless. You’re one person; aim small. You’re better off aiming to build a simple product that a handful of people will love, rather than some sort of globe-conquering social media platform. Focus on quality within a niche, rather than spreading yourself too thin building something overly ambitious.

Solve a problem you’re personally facing

There are two big benefits to building something that directly solves an issue you’re facing, however small that issue might be. One, you inherently have a great understanding of the problem you’re trying to solve, and therefore, what types of functionality are going to provide a lot of value. Two, the desire to solve a problem for yourself gives you an extra layer of motivation to help you keep moving forward when things get tough. Even if no one else ultimately uses the thing you built, at least you’re left with an app that’s useful to you.

Cut scope ruthlessly

If there’s one thing that always seems to hold true about software, it’s that it always takes waaayyy longer to build than you intuitively think it will. Even if you’ve got what feels like a pretty manageable, niche idea, always be thinking about how you can reduce the scope of what you’re doing and minimize effort — even if your instinct is actually to add more and more cool features as you explore the idea further. The nice thing about software is that you can always add those cool features via updates later. Getting the app across the finish line is always going to be hard, and you probably don’t want it to drag on months later than expected — especially since getting your app into users’ hands is the best way to figure out what kinds of additional features the app needs.

Make sure the core concept is easy to explain

At some point, in some way, you’ll have to convince people to give your app a shot. People are busy, and attention spans are short; being able to explain what your app does — and why it’s useful or different — in a quick and compelling way will help get users in the door. This can also help you gain clarity around what to actually focus on building initially — if it feels like the only way to explain your app’s value is to list off six loosely related features, you might want to consider narrowing your focus. (see “Cut scope ruthlessly” above!)

Keep monetization in mind

This is an area where I’ve still got a lot to learn, but I feel fairly confident saying this: if you intend to try to make some money with your app, it’s worth putting some thought up front into how you might go about it. Will it be a simple paid app? Free with in-app purchases? Will it use a subscription model? Will it be ad-supported? These are important to start thinking about early, because they can shape decisions around what kinds of features the app needs. For example, if you want to distribute your app for free, but provide a premium subscription option — a model that’s become quite common over the past few years — you’ll need to think carefully about which features are free, and which are premium; how are you going to make the premium subscription compelling, while also ensuring the free version is useful?

And there you have it: step 1 of my step-by-step guide to becoming a guaranteed overnight indie darling is complete. Is anything in here wildly off-base? Did I miss anything obvious? I’d genuinely love to hear from you on Twitter if you have any questions or thoughts 🐦

Going indie: Introduction

Sun, 26 Jan 2020 00:00:00 +0000

I’ve got a big idea for a series of articles I’d like to start writing. On its surface, the pitch is simple:

I’m going to show you, step by step, how to build a successful app as an independent app developer.

As you can see from this map, this is going to be quite easy.

…

The reality, of course, is that I have absolutely no idea how to build a successful indie app. I’ve never done it, and actually, if I’m being honest, it seems pretty hard.

But, that’s kind of the point. I’ll write these articles in real-time, as I attempt to build and ship my own wildly successful independent app, in the hopes that I’ll end up with a fun and compelling chunk of writing regardless of how that app turns out. If I defy the odds and manage to actually build something that finds some version of even moderate success, then I’ll have documented many of the steps (and missteps) I took to get there, which will hopefully be interesting and helpful to anyone else aspiring to do something similar. If I jump ship halfway through development, or release an app into the void and never get so much as a dime out of it, then my hope for this series is that it becomes a funny and honest look at how hard it can be to find success as an independent app developer in 2020.

More than anything, it’ll be a fun outlet for me to write about the ups and downs of setting out on my own and trying to build something worthwhile.

Here are a few initial goals I’ve got in mind for this thing:

I generally want to keep the articles pretty short and easy to read.
I want to write something about once a week.
I want a good mix of technical and non-technical stuff.
I want to keep things light and self-deprecating. You can go ahead and imagine that every article has this image featured prominently:

…because, despite now having built apps professionally for something like 8 years, I still feel like a dog in a tie on a day-to-day basis. I think that’s normal, especially when embarking* on a new project like this, and I think that’s okay — it means I’m still pushing myself and improving at the things I do.

Come along for the ride! I’ll post updates on Twitter. You can find me here.

* Just wanted to call attention to this dog pun. I’m off to a good start.

Daniel Gauthier

Identity Crisis!

Setting the scene

Doing the indie thing

Losing momentum

What’s next?

Job hunting

Who am I?

Epilogue

Going indie, step 10: Hang on tight

Chapter 1: In Which a Small Audience is Built

Chapter 2: In Which Some Promo Tweets are Crafted

Chapter 3: In Which a 9to5Mac Article Appears

Chapter 4: In Which the App Somehow Ends Up on Product Hunt

Chapter 5: In Which the App sort of Ends Up on Reddit Eventually

Chapter 6: In Which a Very Exciting Email Arrives

Chapter 7: In Which a Very Strange Email Arrives

Chapter 8: In Which a Blog Post goes Viral

Epilogue: Lessons Learned

Going indie, step 9: Launch an app

The timeline

April 2

April 4

April 7

April 10

April 11

April 16

April 20

April 26

May 1

May 5

May 6

May 7-9

May 10

May 11-12

May 13

May 14

Was it a successful launch?

What comes next?

Going indie, step 8: Take a hard left

So, what have I been up to?

Okay…what is it, exactly?

My goals in building this thing

Ship quickly

Polish

Learn

Cool, when can I get the app?

Going indie, step 7: Keep up!

Going indie, step 6: Do it during a pandemic, I guess?

Watch Seinfeld

Play Alto’s Odyssey

Make good coffee

Play Pandemic (and win)

Listen to some good tunes

Get excited about news from Apple

Improve your approach to project & time management

Be kind to yourself

Going indie, step 5: Suffer from crippling imposter syndrome

Mastering view controller transitions, part 3: Make them resizable

Goal 3: I want my presented view controller to be able to easily define and adjust its own size

Wrap-up

Mastering view controller transitions, part 2: Make them feel natural

Goal 2: I want my interactions to feel natural

Use spring animations

Take gesture velocity into account

Be smart about deciding whether to complete or cancel a transition

Make sure your interaction is always enabled

Deal with scroll views

Mastering view controller transitions, part 1: Make them reusable

Goal 1: I want a dead-simple way to use my custom transitions

Going indie, step 4: Wrap your head around custom view controller transitions

What this is, and what it is not

The anatomy of a custom view controller transition

Presenting view controller & presented view controller

Container view

UIViewControllerAnimatedTransitioning

UIViewControllerInteractiveTransitioning

UIPresentationController

UIViewControllerContextTransitioning

UIViewControllerTransitioningDelegate