Newsletter Senior

🦅”Avoid the App Store”  by Jonathan Heyman

There is a terrible amount of risk for everyone that wants to build apps and publish them in the App Store: you need to build the app and submit it to know if it’s allowed. This means you have to at least have a functional prototype that demonstrates how the app works to reviewers and hope that they approve it. Then, even if think you’re following all the guidelines, Apple may reject your app at their sole discretion. They may say they’ll hear appeals, but they can easily maintain their decision and shut you out of the process.

This happened to Jonathan Heyman. Remember the Wordle clone wars? Well, he decided he wanted to build a Swedith version of Wordle, and publish it in the App Store. He then got rejected and attempted to change the behavior of the app enough that it couldn’t possibly be confused by other people as a Wordle clone. It didn’t work and Apple provided very little feedback.

I’ve grown resentful over the past few years because Apple outright lies about the purpose of the App Store and how it works. Apple execs have gone on the record stating that the App Store is there to curate apps in such a way that it’s beneficial for the end users. However, there is plenty of evidence that this is not true. From the hundreds of scam apps that will charge you a fee for no functionality, to the fake 5-star reviews, to the draconian restrictions like the ones Jonathan faced. I won’t even expand on the fact that all of the process is opaque. You don’t get clear rules or consistent behavior out of Apple reviewers.

I’m bringing this up because it’s important that you remember that we serve at the behest of the king. It’s your responsibility as a senior developer to explain to others that this isn’t the App Store paradise everyone envisions. It’s a walled garden where Apple has absolute power over other businesses and their revenue streams.

Junior Newsletter

🐓 “I launched my first app, what now?” by iDeviceSlash

Launching an app, regardless if it’s a simple app or not, is a ritual that is more and more necessary as time goes on. One of my mentees mentioned that they had applied to 25 companies and had almost 0 interviews… but after they published their app, they landed 5 interviews in the space of two weeks.

But, after you publish your app to the App Store, what then? It depends. If your purpose is to try and make a living as an indie developer, then unfortunately publishing your app to the App Store is only the first step in an arduous journey. Even if your purpose is just to add an app to your résumé, the next steps are still the same: market it. 

In this linked thread, there’s some excellent advice to iDeviceSlash’s question about what to do after they launch to the App Store, but the general consensus is that you need to get users and to get users you must be noticed. My personal recommendation would be to build a small website for the app and a Twitter account. Start grinding and finding customers. Worst case scenario, you now have an excellent topic to bring up during interviews. Many interviewers would be interested in hearing about your experiences trying to make it in the App Store.

Newsletter Solo learner

🐥 “How can you size a multi-line label” by Mike Sanderson

Programming is inherently difficult. Sometimes that difficulty stems from external factors: pressure to deliver from a manager, the state of a codebase that you didn’t build or life getting in the way. Most of the time, though, the difficulty in programming is intrinsic. Programming problems are difficult and every now and then they are untractable. You must take the algorithm as is and absorb the complexity because there is no simpler solution to it. 

This is excellent Twitter thread by Mike Sanderson explains why it’s literally impossible to “correctly” size a multi-line label in UIKit (or any framework whatsoever). It shocked me that I hadn’t ever asked why AutoLayout seemed to have so many difficulties in self-sizing multi-line labels. I’ve known it’s a very annoying problem for a long time, but I hadn’t found an explanation that’s clear.

Again, I want to emphasize that you should read on these kinds of issues and internalize the fact that they’re hard. It may take you years to understand it and that’s ok. It’s not your fault, it’s programming’s fault.

Newsletter Tutorialer

🐣 “I have this idea for an app…”  by Apple Engineers

If you’re somewhat unfamiliar with WWDC, get ready to have your mind blown. Apple hosts a yearly meetup called WorldWide Developers Conference, where thousands of Apple engineers get together and explain many different topics. These topics range from the very basic (which we’ll see in a second) to compiler optimizations that will make your head spin. 

Today I bring one such video presented by Jessie Pease and Tanu Singhal, titled “I Have This Idea For An App”. What a wonderful name 😆. If I had a quarter for every time I heard that phrase…

Anyway! It’s a fantastic, guided introduction into the world of App development. You’ll get a tour of Xcode, build a sample app and learn from the best: Apple engineers. 

Check the tutorial here:

Newcomer Newsletter

🥚That is like such a boring book by Foone

An incredibly funny image found by user Foone. Neopets is a virtual pet software that’s old – 1999 old. I’m certain I played it sometime in the early 2000’s, but I stopped playing for one reason or another. Anyway, Foone finds an explanation of the algorithm Neopets used (uses?) to figure out whether a Neopet will want to read a book or will get bored with it. That’s kind of funny, right?

The algorithm is so simple, I though I’d share it. What I hope you see from this post is that programming isn’t all about complicated algorithms, efficiency and what not. Programming is about providing value and most of the time providing value means you ship whatever you have, even if it’s an algorithm so simple anyone can understand it by reading a few paragraphs.

You can provide value as a programmer, even if you’re just starting out and can only barely sum two integers.

Newsletter Senior

🦅 SwiftUI and Domain-Specific Languages by Jeff Verkoeyen

I’ve been wary of SwiftUI for a while. During my time as an instructor at Lambda School, I designed our SwiftUI lesson (alongside the great Dimitri Bouniol). Some people, like Dimitri, have gone all-in on SwiftUI and I know for a fact they enjoy it and see it as the future of iOS development. However, there’s always been something that I just don’t like about SwiftUI. For years I thought it was its opaqueness: you’re supposed to blindly accept that a List will be magically transformed into the correct UI depending on platform.

This excellent thread by Jeff Verkoeyen helped me crystallize my thoughts on SwiftUI. The reason I have been wary about SwiftUI for all this time isn’t about SwiftUI, but about Apple. When it comes to UI, Apple is lacking a clear direction for developers. For example, let’s say I want to build an iOS and macOS app… should I use UIKit alongside AppKit? Should I use SwiftUI which is new and has valid limitations compared to UIKit/AppKit? Should I use Catalyst? Should I just forego all of that and let the user run the iOS app on the Mac if they’re on an M1?

I guess I just don’t understand why Apple decided to build SwiftUI and until I don’t understand it, I can’t really feel comfortable going all in on it. If you can help me understand it better, I’m all years 🤷‍♂️

Read SwiftUI’s limitations ➡

Junior Newsletter

🐓 What to do at the interview by Amy Nguyen

When preparing for an interview it’s important to remember that the interviewer is trying to find out how you think. I understand it’s a stressful situation, even if your interviewer is making everything they can to make you comfortable. Sometimes it’s easier to relieve stress if you’re already coming in with a plan.

Enter Amy Nguyen clearly explaining how to behave yourself during an interview. The advice given is excellent. Best of all is the fact that she clearly has a path to follow. I’ve been on both sides of the interview process many times, and you should remember you’re in a conversation. Let me know what you’re thinking, even if it’s obvious and it isn’t going to lead anywhere. Explaining your thought process to the interviewer is sometimes much more important than actually solving the issue at hand, be it a CS-type problem or walking through some code.

This is great prepping material for your next interview.

Read the advice ➡

Newsletter Solo learner

🐥 Preparing for painless UI testing by Jean Mainguy

Concepts become more important as you go on your journey because problems grow more and more complex. You go from following tutorials to trying to build your own solutions and, hopefully, you’re failing spectacularly. I say hopefully because you’re at a point where failing has very little consequences. Yes, it will bruise your ego – and believe me, no one values their ego more than me 😆

However, some concepts sound way more complicated than they are, such as dependency injection or mocking. This example by Jean Mainguy (that’s a great last name!) shows you how simple it can be preparing for UI testing using dependency injection.

Mock the code ➡

Newsletter Tutorialer

🐣 Getting better vs Feeling better by Jason Fried

I don’t think I’ve ever explained clearly what each section in this newsletter is all about. A tutorialer, to me, is someone who’s made the concrete decision to become an iOS developer. It could be that you decided because it’s a great job, or because it’s interesting to you, or just because you need to find out if this is something for you and committing is the only way to do it.

Following tutorials is the easiest way to get better. You have to do things to improve your skills. However, setting a concrete goal is difficult. What does it take for you to move from tutorialer to self learner? Is it a number of tutorials? Is it learning this concept or that concept?

Jason Fried sets an excellent goal when learning something: feeling good about doing it. I like how clear and subjective it is. The more tutorials you do, the more comfortable you’ll be doing things on your own. My advice to you would be to make sure to create a new project and apply whatever you’ve learned from the tutorials in your own way. If you followed a tutorial on localizing SwiftUI, build a simple to-do app and just localize it yourself.

When you start doing this and feeling good about the result, that’s when you’ve made it over the tutorial hump.

Keep moving! ➡

Newcomer Newsletter

🥚 “What did your journey look like?”  by Reddit

Making the decision to become a software engineer is difficult, no matter your background. The most important thing you can do is realize that it will not be easy. The concepts are difficult to understand, there’s a million different pathways, and even though you’re likely to receive a lot of support from the community, it’s entirely up to you to continue.

Sometimes I think it’s useful to remind yourself that you’re not the first person to decide to become a developer. I found this Reddit thread asking “What did your journey look like to get your first iOS job?” really empowering. The experiences shared are from all over the place: hobbyist programmers coming to iOS, people switching careers, others going through college or bootcamp.

Your journey may take months or years. Sometimes that’s up to you and sometimes it’s up to life, but I can tell you that becoming a developer is an incredible reward. The job is usually mentally stimulating, it is definitely well-paid, and it’ll unlock a ton of different other options in tech.

Hit reply and let me know if your journey is similar to those in the Reddit thread. I’m always happy to learn people’s backgrounds – it’s partly why I write this newsletter.

Read about other people’s journeys  ➡