Reliably enable debugging features for yourself. Hide them from your end users. Stop using #if DEBUG. TLDR: Use a custom Profile that includes a certificate. Install that on devices you want to enable debugging on. By detecting if that profile has been installed on the user’s device, you can enable/disable debug features that are impossible for your users to find. At my work we use TestFlight to distribute beta builds for internal and external testing. This a great, because once you certify a build as “ready for production”, you can just release it – it’s the exact binary that you’re going to ..read more

Learn: how to write a property wrapper that avoids boilerplate for your asynchronous callback code. The Solution Code Want to skip to the answer? Variables marked with this property wrapper will be destroyed after they are read once. Use with caution! @propertyWrapper struct ReadableOnce<T> { var wrappedValue: T? { mutating get { defer { self._value = nil } return self._value } set { self._value = newValue } } private var _value: T? = nil } Now lets see how we got here. Avoiding multiple invocations of a co ..read more

Most of the time, a crashing app is the very last thing you want. Obviously. But sometimes you really do want your app to crash to enforce correct usage of your APIs. What’s worse than a crash? Crashes are obviously bad – it’s disruptive to your user, they might lose data or work in progress, it makes them feel frustrated and less likely to open your app again, and it just smells like bad quality. But there’s something worse than a crash: undefined behaviour. Our programs are carefully thought through, and crafted so that the right input data is manipulated, used for calculations, stored, outp ..read more

Being a developer is hard – and being an effective developer demands that you juggle many responsibilities at the same time – from writing and reviewing code to mentoring others and communicating with stakeholders. How are you supposed to be good at all of these things? Each one is hard even just on its own! The answer – build good habits. Then you don’t have to actually remember to do the things, you just stick with your habits. So here are some habits that I believe can make you a more effective developer. Practice these, and you will be the most valuable member of your team. 1. Read Reading ..read more

Does you use the Agile methodology at work? What do you think of it? Do you think it helps you be more productive? I suspect your answer to that question depends on a number of factors, but the key determiners are likely the role assigned to you by the Agile framework, and the details of how Agile has been adopted by your company. Why Agile is Supposedly Better Than Waterfall Waterfall has a fatal flaw – although thorough planning and a long-term roadmap are useful in organizing a coherent project plan and achieving a big goal, you’re stuck with this plan once you’ve started. Projects planned ..read more

How to do code review that enforces high standards while avoiding common problems on your team. Code review is the hardest part of being a developer. Seriously. Whereas most of our work is between you and a computer – a machine you just have to operate correctly and indicate clear intentions to – code review is a thing between humans. And like it or not, those humans are squishy, opinionated, emotional creatures. And those traits make code review a challenge. In principle your goal in a code review is simple: examine another person’s code and make sure their pull request (“PR”) is “good enough ..read more

Let’s say you’re working on a big project – your final paper for a class at school, or a report for your boss. The project is long and complicated, you chip away at it over a period of months, and go through many many revisions of editing.  Then you save your last copy, Big Project Final Version and hand it to your trusted friend to look over. They find 100 more little typos, so you fix those, then Save As: Big Project Final Version 2.  Just to be safe you read over it one more time, and decide you actually want to go back to what you had before in a few places. Hmmm… how exactly was ..read more

An iOS developer probably has a similar day to most other kinds of developers – it includes reading and writing code, discussions with teammates, and maybe some meetings. But what exactly does that look like? Well here’s a rundown of a typical day for me (if I’m not working from home): 7:00 – Alarm goes off. Get up, eat breakfast and make coffee. 7:30 – Leave the house. Head to the train station and start the commute. I live pretty far from work, but taking the train allows me to make use of the travel time and avoid sitting in traffic. I also bicycle from the train station to my office, so I ..read more

Recently I’ve been spending a lot of time thinking about self improvement. Some of this has been about creating better habits and making better or healthier decisions in my personal life, and most of this has been concentrating on work – how do I become a better developer, a better leader, a better professional. But as I’ve been going through this, I’ve found that on the basis of aiming for self improvement, you first accept that there are things to be improved. And when you make this acknowledgement, not all the feelings that come out are positive, growth-y, or productive. Starting Somewhere ..read more

Happy New Year, folks. The new year is a time for reflecting on how the last year has gone and how the next year might be better, and so like many of you I’ve set myself some goals. These are goals that are supposed to help me improve some aspect of myself or my life, and by writing them here I hope to provide some inspiration for you, or at least some accountability for me. These aren’t entirely programming-related, so this post diverges from what many of my other posts are about, but if you take a more holistic approach to work and life, you will already know that these things aren’t really ..read more