iOS 5 By Tutorials ebook

Blog Archives

Freelance iPhone Developer, One Year Later

A year or so ago I wrote a blog post about starting out as a freelance iOS developer. A lot has changed since then. I have no shortage of work and I was able to recently bump up my hourly rate to €150. Because of this, my fiancee and I can afford to take a three-month vacation in Australia soon and I don’t intend to do any work while we’re over there. Of course, I worked hard to make this possible.

If you pay peanuts, you get monkeys

Every day I get inquiries from potential clients, much more work than I could possibly handle. Some of these inquiries are quite unrealistic, but the 150 Euro per hour price tag is quite effective in scaring off the dreamers with a hundred bucks and an idea. (It’s also basic economics: If you can’t keep up with the demand, raise your prices.)

My hourly rate may seem high but one thing I learned over the past year is that I’m a really good developer and that I’m worth it. Asking for big money obviously drives away a lot of potential clients, but the clients that I do get are serious about what they want, their projects are interesting, and they understand what it takes to make a quality product.

As any creative professional can tell you: “The more you pay me, the more you can expect of me, and the harder I will work to make the end result really wonderful.”

Inspired by this excellent rant, I also decided to take on only the really hard projects, the ones that are too hard for other developers. Simple apps are boring — I need challenges that allow me to make the most out of my skills!

How to find work

I received an email today from a fellow freelance developer who found himself in the same spot I was in a year ago:

“I was wondering if you had any more luck finding work via internet resources since your post was written? I figured I’d look around at a couple of the big freelancing sites and see what I can find, but I think it’d be so much better if it was more personal.”

There are two things I did that made all the difference. First off, I started blogging. There’s always a need for good information about any topic in your field, so if you write quality posts you’ll build up a name for yourself and people will come to regard you as an expert.

With a blog full of quality material, you’re no longer some anonymous developer but someone who has already demonstrated his skills. It makes it easier for clients to trust that you can actually deliver.

Putting some of your own code on Github is another way to pull that off. I have created some open source components that people find useful, and that gets my name out there too.

The biggest thing I did, however, was to write for www.raywenderlich.com. That is a popular site with tons of great tutorials and my contributions seem to be appreciated. I also wrote a 750-page ebook called The iOS Apprentice that is sold through Ray’s site, and contributed to the ebook iOS 5 By Tutorials.

A lot of this is hard, unpaid work, but it pays itself back in building up your reputation. I’m probably not as well known in iOS circles as Matt Gemmell or Marco Arment, but I’m working on it. ;-)

Not what you know, but who you know

The second thing is to get in touch with other developers. Networking is a great way to get referrals for jobs. Many developers have too much on their plate so they’d be happy to pass on work to other developers they know and trust. Some will also subcontract out certain parts of their projects.

There are many ways to network. You can get in touch with other developers that are local to you through groups such as CocoaHeads and meetings such as NSCoder Night. If no such group exists in your area, you might consider setting one up yourself.

You don’t have to restrict yourself to just meeting iOS developers, of course. Mobile developers, web developers, designers, start-up founders, these are all useful people to get to know.

Face-to-face networking is probably best, but on the internet there are plenty of places to get in touch with other developers as well: forums, blogs, IRC, Facebook, LinkedIn, you name it. Hanging out with your peers has never been easier…

Just Say No to Splash Screens

The client briefs that I receive often contain the requirement that “the app should display our logo when it starts”. In other words, a splash screen. Unless you’re making a game, I think adding a splash screen to your app is a bad idea, and here is why:

Splash screens make your app appear to start up slower. When the user launches an app, he expects to be able to interact with it immediately. If you show a splash screen first, he has to make a context switch from what he expected to see (the actual app) to your logo and back again when the app is done loading and its real interface finally appears.

Instead, if you do what Apple recommends in the HIG—show an empty version of your UI, without any content—then the perceived app startup time is actually shorter and users are happier as a result. Anything you can do to make your users happier is something you should do.

All iPhone and iPad apps contain a launch image, Default.png, that is shown when the app is being loaded by the operating system. Unfortunately the temptation is big to put a logo in this image. Don’t, as that is not what it’s there for.

Here is the launch image of an app I recently completed for a client. Boring, but effective.

A typical Default.png launch image
Splash screens are about you, not about the user. You probably like your logo very much and I’m sure it is pretty, but here is something you need to realize: the user doesn’t particularly care about you or your logo. You, on the other hand, should care very much about the user.

Most people just want to get on with things and if your app helps them do so, great! But if the app gets in their way, it only takes three taps to uninstall.

If your app is a novelty app designed to promote your brand, then remember that unless the app delivers some kind of value, people won’t be using it for very long and they won’t get much exposure to your message. Focus on the value, not on the brand.

Forego the splash screen and find a better way to integrate your branding in the app’s user interface. Give people a good experience to associate with your brand, rather than shoving it into their faces.

The launch image is rarely shown anymore. Now that almost everyone has OS 4 with multitasking on their iPhone, apps resume where they left off the next time they are opened. This means the load image, i.e. your splash screen, is only shown for a brief instant the very first time the app is used.

The launch image also appears if your app is re-launched after it was truly terminated, which occasionally happens when there is not enough free memory to keep all suspended apps around. Most of the time, however, when the app loads the user sees a snapshot of where he last left off.

Showing your splash screen only now and then makes for a very inconsistent experience. Putting a logo in the launch image might have worked on the slower models when there was no multitasking yet, but no more.

Don’t get too clever! If your app launches really quickly—and it should!—then the load image is only visible for a second or so, especially on the fast iPhone 4. Hardly long enough to make an impression.

To “solve” this problem, some apps use a timer that keeps the splash screen visible for a few seconds more before it fades into the main interface. How silly is that? You are not doing the user any favors by purposely slowing down the launching of the app.

Let me say it again: the app is not about you, your brand or your logo, it is about the user and the goal he wants to accomplish.

If your app is a game, then it makes sense to show a “Loading…” screen but for any other apps, do the right thing and put a blank version of your UI in the default load image.

Developing Software is Expensive Because It is Hard

If you have an idea for an app and are looking to get it developed but you have no programming experience yourself, it might be wise to learn a bit about the difficulties of developing software so you can avoid the common pitfalls:

  • not getting the app you want,
  • paying more than you budgeted,
  • not getting your deliverables on time.

There is a reason why software takes a long time to develop, is expensive to make, and often isn’t very good: programming computers is hard!

It’s easy enough to learn the basics of programming. There are only a handful of building blocks and by themselves they are easy to understand. However, knowing how to combine them into a larger application is the real trick and that takes many years to master.

If you’ve never programmed before, or never went beyond the trivial programs you had to write in school, the difficulty of the task may be hard to appreciate. In this article, I’ll try to give some insight into why writing software takes so much effort and why it fails so often, and some tips on how to avoid disappointment. Continue reading…

Life as a Freelance iPhone Developer

Four months ago I quit my job to become a full-time freelance developer. I set up my website, registered the business, and set out to find work. My current interest is in iPhone and iPad software so that is the kind of work that I looked for.

It wasn’t hard to find iOS-related development jobs because currently there is a huge demand for mobile developers. However, I found it challenging to find jobs that pay enough to make this endeavor worthwhile.

I have been programming for a long time but I still am a bit of a newbie when it comes to being a freelancer. As an employee I have worked for big, medium-sized and small companies, including a startup that went bankrupt after I had been working my butt off for three years. In between, I have worked for myself for several years as an independent shareware author, writing my own software product and selling it from my own website. Now I’m self-employed again, writing apps for the iPhone and iPad on a freelance basis.

In this blog post I’d like to talk about my experiences so far, in the hope that it will be useful to other aspiring freelance developers, and maybe to pick up a few tips from more experienced contract developers – any advice is welcome! Continue reading…

How to Recognize Bad Software Developers

There is a lot of bad software out there and that upsets me. Software is going to be everywhere. It’s already in your TV, washing machine, microwave oven, car, mobile phone, and hundreds of other places. Most of it is pretty low quality.

I want to live in a world where software — or anything that uses software — is dependable, safe, and a lot less frustrating to use than it is today. But writing software is hard and a lot of developers are way out of their league.

Here is a checklist on how to recognize bad developers. You do not want to hire people who exhibit these symptoms!

Bad developers…

…make overly optimistic promises. Software development is hard and it almost always takes longer than expected. Of course you want to release as soon as possible but an unrealistic plan won’t get the project done any sooner.

…claim to fully understand your specifications without asking questions. Trust me, there are errors and omissions and unanswered questions in your specs. You don’t want the developer to make assumptions, you want him to ask for clarifications.

…start programming right away without understanding the actual problem to be solved. The developer is not an expert in your field, so it will take him a while to learn about it. Expect to explain stuff. A good developer will try to understand what he is going to build before he starts building it.

…write code quickly (but badly!) to try and impress you. Unfortunately, the bad developer can only deliver quickly by skipping corners. Those skipped corners will come back to haunt you near the end of the project, causing delays that undo any gains from a quick start.

…will do exactly what you say, without any critical thinking on their part. So you have to take them by the hand and micro manage them the whole time.

…keep adding features that you did not ask for because the developer thinks they are cool.

…use open source code without respecting the license, putting you at risk legally. Code-reuse is a good development practice but there are limits to how far you can take it.

…don’t deliver on time because weird bugs keep popping up. These weird bugs are the result of the cowboy coding at the beginning of the project. It’s impossible to fix these bugs properly because by now the code is a mess and the bugs are entangled deep within it.

…write code that is totally unmaintainable, which makes building the next version of your app an even worse ordeal.

…may not actually be able to program what you asked for and will be forced to abandon the project halfway through, after you’ve spent countless hours and a large chunk of money on it. The next developer you hire will probably have to start all over.

These days it is easy to get into programming. Anyone with half a brain and a text editor can put together a website with some HTML and PHP. But that does not mean that person truly understands what he is doing. In my experience, the craft of software development takes at least 10 years to learn and much longer to master.

If you want your project to be a success, take the time to find and hire someone who has put in the effort to learn what it takes to write good software. They may charge more but in the end you’ll be a lot happier for it.