I’ve been using Jekyll as my static blog generator for a few years now but noticed a minor annoyance a few days ago; whenever I use footnotes¹, the return arrow (↩︎) is converted into an emoji (↩️) on iOS and in some RSS readers. Obviously this isn’t desirable and so after a bit of digging I was able to find a fix.

Firstly, this isn’t an issue with Jekyll but with kramdown which does the Markdown conversion. Thankfully, there is a config option in kramdown 1.8.0 and above² that lets you specify the text you want to use for the footnote return link and you can set it as unicode to stop it being converted to emoji. Just add the following to your _config.yml file:

kramdown:
  	  footnote_backlink: "↩︎"

Regenerate your site and you should find that the emoji arrow is now back to a ↩︎.

After selling WallaBee last year, I changed my company name to Dodo Apps Ltd. Now that I’m publishing my own apps again (in addition to my freelance work), it seemed time for me to make a few changes to my website.

Today I’ve updated bendodson.com so that my client work and my self-published apps are now in separate sections¹. I have also created a new site at dodoapps.io to advertise my own apps that are currently available in the App Store².

I am currently available for freelance work from February 2016. For more details, please contact me.

I’ve been using Interface Builder in more projects over the past few months due to the benefits of AutoLayout. This has led to me shifting more standard UI code (i.e. colors, borders, shadows, etc) into Interface Builder via the User Defined Runtime Attributes¹. However, this doesn’t work for the CALayer properties shadowColor and borderColor as they expect a CGColor rather than a UIColor.

To fix this in a recent project, I created a very basic CALayer extension (in Swift) that adds UIColor accessors so you can set them via the User Defined Runtime Attributes as so:

You can get the extension on GitHub.

After a slight delay in recording, Episode 5 of The Divide is now available. As a New Year treat, this show is a 2 hour special all about Star Wars. We discuss the original trilogy, the prequel trilogy, some of our favourite Star Wars video games and comics, and then dive into Episode VII, ‘The Force Awakens’ (there are numerous spoilers but we confined them all to the last half hour or so and there is a big warning before we start). We also discuss one of my favourite oddities in the re-release versions, the addition of CGI rocks to Episode IV:

You can get The Divide from these fine outlets:

• iTunes
• Overcast
• RSS (for other podcast readers)
• The Divide website

Don’t forget to leave a review on iTunes and follow us on Twitter via @PodcastDivide

Over the years, I’ve received a lot of emails offering me the chance to work on an exciting new project for free in return for some equity. This is an excerpt from one I got yesterday:

We are currently developing a [redacted] site with some developers who are dragging their heels and would like to to jump ship. They are more web developers and not used to app coding. They have been working for free in returning for an equity share in the company.¹

We have pitched to a few venture capitalist who like the idea but need to see a minimum viable product out in the market place.

Is this something you would entertain… work for free now but get a percentage of the company?

I write back to (nearly) every email I receive so I used my standard “sorry, I don’t ever work on an equity basis as per my website” reply. However, it’s starting to irritate me just how many of these emails I get per day, the fact they don’t read the clear disclaimer on my contact page, and the mindset that they must have to think that someone is going to work for free for a potential kickback later. Hopefully this post will clear up why I, and most other iPhone developers, will not work for free on your project².

Short version: We have mouths to feed the same as anyone else.

Long version: There is a huge amount of paid work available to freelance developers and it pays incredibly well³. Some might say that developers are risk averse and so of course they’d choose paid work over the risky equity venture but that isn’t really true — being a freelancer is already incredibly risky with the fact you have to find work and hope that the client does pay on time and as agreed. That said though, choosing equity over money is one step too far on the risk ladder; the chance of it succeeding is very small and you’ll end up working on it for much longer than you anticipated.

For example, lets say you’re a developer charging around £500 a day for your services. To get a project to MVP status, you’re likely going to need to work for 1-2 months so you’re looking at around £10-20k of lost revenue. At this point, you need to make back at least that sizeable amount of money in order to break even. However, as the MVP continues, there will be bugs and new features to be added and you’ll be expected to add them for free; after all, you’ve been doing it for so long by now and if the project needs to switch developers then it’ll most likely die and you’ll end up with nothing. You will keep working for free until the project does eventually fail; you might get some small amount back but the real likelihood is that you’ll end up with nothing but a portfolio piece and the realisation that you should have filled the last 6 months with paid work.

This isn’t hypothetical; whilst I don’t ever work for equity, I’ve worked on a freelance basis on projects who did have other developers working for equity. They were hardly ever available after the project launched (as they needed to work on other projects to put food on the table) and when they were available they did a poor job as they were doing it in their spare time and they’d lost any passion they had for the business. The project folded after 9 months and they got around £1500 for their troubles.

Even if a project does succeed and you do own a portion of the company, it is still going to be a very long time until you see any monetary reward for that. A company only pays it’s shareholders when it is profitable and most startups aggressively use any money they make to grow further; it will likely be years until you get anything. Of course, they might sell to another company and you’ll get a big windfall payment⁴ but that is highly unlikely.

The biggest issue I have with ‘CEOs’ saying “work for free now but get a percentage of the company” is the hypocrisy of it. They are putting all of the risk of the business on the developers shoulders and bearing very little of it themselves. Most of these people with nothing but an idea are working in a full-time job and continue to do so during the life of the project as they don’t need to do much during development; if it fails, they don’t really lose much whereas a developer loses everything.

My one piece of advice for other freelancers and for people looking to hire them is “if the project owner isn’t willing to use savings or a loan to pay for a developer, then they are showing that they think the project is too risky”. When I built WallaBee, I insisted that all contractors were paid at market rate⁵ and did so with loans and money from my own freelancing⁶. If you are trying to get an app built and you don’t do the same, you will not succeed.

This is why I do not work for equity. It isn’t just the fact that I’ll lose money, it’s that I don’t want to work for a business that treats professionals in this way⁷.

Ever since I sold WallaBee, I’ve been splitting my time between client work¹, my Xbox One, and doing small apps that help improve my life in little ways. Today, Apple finally approved² my first self-published app in a long time, Pocket Rocket:

I save most articles that I want to read at a later date with Pocket but I hate their mobile apps. Tapping an article will load their own reader view³ and it’s an extra step to jump to Safari. In addition, their apps aren’t updated for split screen support or new device sizes and so the experience is pretty poor. With Pocket Rocket, I wanted to do one thing; have my Pocket queue load up and then when you tap on an article it should load in Safari. I prefer using Safari as then you get to see the article as intended and with content blockers most pages load quickly. I got the basic version working within in an hour and it worked well enough for my needs; then, when I got the iPad Pro, I realised this could be a useful app for other people as it dramatically improves the reading experience especially when used in split screen mode.

Pocket Rocket is completely free with no ads or tracking⁴. It runs on any device capable of running iOS 9 and is a fully adaptive so it looks great no matter what screen-size you have. Due to this adaptability, it works in all split-screen modes on applicable iPads and that is the way I tend to use it. You can swipe on an article to archive or delete it upon reading. There is also a settings panel so you can choose whether links open in Safari or via an in-app browser (with the option to enable a reader view⁵ on launch if you want).

You can get Pocket Rocket for free on the App Store.

I’m very proud to announce that my first Apple Watch app for a client has gone live in the App Store; Natural Cycles.

Natural Cycles is a popular iPhone and Android app that allows you to track your fertility or plan a pregnancy. It can tell you when you are fertile, when you are ovulating, when your next period is due, when you are pregnant, and the progress of your pregnancy. I was hired as a freelance Swift developer to build an Apple Watch app that would be bundled in with their big v2.0 update and would allow viewing and logging of this critical information. The app allows you to see your current fertility level, body temperature, and progress of your period as well as viewing messages from Natural Cycles. In addition, you can quickly update your current body temperature and menstrual flow within the app:

As well as the core Apple Watch app, I also added support for Notifications and Glances making for an even quicker way to view your information:

My favourite feature, however, is the addition of full text Complications so you can see your current body temperature and fertility status on your watch face:¹

The project was quite difficult (but rewarding!) for a few reasons. Firstly, the design was very ambitious when watchOS severely limits the amount of customisation that can be performed. Secondly, the iOS app was a Cordova app² rather than a native app which meant I had to write a JavaScript plugin and set up some build scripts in order for the native Swift watchOS code to be able to speak with the iPhone. There was also a requirement to make the app as easy as possible to update (i.e. updating the iOS app shouldn’t break the watchOS app) and so I built everything such that the phone takes care of all logic and a lot of the UI so the watch app can be altered without going through the App Store review process.

This was a really exciting project to work on and I’m very happy with the end results. You can download Natural Cycles from the App Store or learn more on their website.

Episode 4 of The Divide, a podcast I co-host, has just gone live. This week, we discuss the routes we all took to becoming software developers. We take a look at how the programmer market is evolving while sharing our experiences of how we learned to code and we close with some musings and tips on where new coders might start to learn how to join the digital gold rush. Chris also shares a harrowing tale of how Captain Janeway wouldn’t look at him…

You can get The Divide from these fine outlets:

• iTunes
• Overcast
• RSS (for other podcast readers)
• The Divide website

Don’t forget to leave a review on iTunes and follow us on Twitter via @PodcastDivide

I’ve been re-watching Star Wars¹ this weekend in preparation for The Force Awakens and a special episode of The Divide we are recording after Christmas. When it got to the Death Star briefing sequence towards the end of A New Hope, I was reminded of an excellent video that came out after the original iPad announcement with a mashup of that sequence and Steve Jobs voiceover. I had a quick look for it and couldn’t find it as for some reason it had been removed from YouTube². After much searching, I eventually found a copy online but I’ve extracted it and saved it here to avoid it disappearing again in the future:

I absolutely love this video and wish I knew who created it.

I’ve been working on a tvOS app for a client recently which has led to a lot of time spent building to both the Apple TV hardware and simulator. Whilst the simulator is very good for basic testing, the simulated remote can be a bit tricky to use and so I was very pleased to discover today that the physical Siri Remote can be used with the Apple TV Simulator on El Capitan. All you have to do is pair your Siri Remote to your Mac and it’ll work in the simulator just like it does with the real thing.

The full set of steps are as follows:

1. Unpair your remote from your existing Apple TV (if applicable) by holding down the menu button and volume up button for around 5-10 seconds whilst the Apple TV is unplugged or otherwise out of Bluetooth range¹.

2. Open up the Bluetooth settings panel in OS X; you should see a device with no details other than a mac address. Pair it.

3. Profit! Your Siri Remote is now paired and can be used in the simulator.

I have a 1080p external monitor plugged into my iMac 5k and so if I run the Apple TV simulator on that in fullscreen mode it feels almost exactly like using the real hardware. This could be a good stop gap for those on a budget as you could just buy a Siri Remote for testing rather than the whole Apple TV². You should always test your apps on real hardware of course but this is a useful trick nonetheless.