I’ve been hearing a lot of interest in iOS development work from startups looking for either a consultant or a full-time employee. At the same time I do not know very many iOS developers who are available to work (including me, currently).

If you’re an iOS developer interested in getting a contract or job, you can contact me by leaving a comment to this post. I will not make any of these comments public, so no one will see them but me. I’m basically using the comment system as a messaging system here. To be clear: no one will see your comment but me (for this post only). Please include some evidence of your skill as an iOS coder, and your email address so I can reply. I won’t share any of this information with anyone else unless I explicitly ask you first (and get your approval, of course!).

If you’re a startup looking to hire people, you can also contact me the same way. Be aware that there is much more demand than supply right now, so I can’t promise anything.

The problem

I’ll mention the bad news up front, which is that there is no really good solution to this problem. In security, it’s basically a war between hackers and researchers. (I like to think of these guys as two sides of research, but I’m not sure if others would agree.) When it comes to this specific problem, the hackers are winning. Or, to be more fair to researchers, the setup of the problem is so skewed in favor of hackers that it may be essentially impossible to defend against them completely.

Why do the hackers win this one?

A hacker can get your binary, and can run your binary. A clever hacker can disassemble, inspect, and even modify your code, although they don’t have access to the source, so it’s harder.

But, no matter how you implement things, your code will be sending some string to the server, and it has to compute the authentication code (the HMAC). In order to compute the HMAC, it has to pass around a private key. All the hacker has to do is locate the point in code when you send out the network request, and work backwards from there to find the origin of the HMAC, and from there find your private key and hash function. Once they locate these, they can execute your hash function with your private key to sign any message they like. They win.

However, going to all this work is a real pain, and requires a rare skill set for the hacker. So there are some very practical methods you can use, which I’ll list below, which will make life harder, and probably completely deter, many would-be hackers.

Good solutions we can’t use

Before saying what we can do in iOS, in my research for this post I learned about two techniques to help solve this problem in other contexts. I like these ideas because in these cases the researchers are winning, and I think each of these is a very interesting idea.

Non-iOS solution 1: Trusted platform module

A trusted platform module (TPM) is a small piece of hardware that can be included with a device to provide certain security functionality. The main feature we would care about is device integrity. Basically, a TPM keeps a hash computed from the system device setup and OS/low-level software. If any of those are altered (such as an iPhone being jailbroken), the TPM will detect it. So a platform can be created where no apps can run without approval from the TPM. In this context, it becomes much more difficult for a hacker to extract anything from your code, because they can’t run it. If someone were implementing this system, they might as well protect against users copying binaries, which would also disallow disassembly.

However, iOS devices do not have these protections.

Non-iOS solution 2: Secure password verification

This is a very cool idea. You can write a function BOOL PasswordIsCorrect(NSString *password) that will correctly return YES or NO depending on if the input string matches a secret password. This much is easy. The cool part is that you can write this function in a way that keeps the password secret, even if a hacker has the source code for the function.

How can this work? Like this:

The background is to choose any large prime for p, then any value r < p, and then compute encryptedPasswordInt = PowerModN(r, realPasswordInt, p). To use more standard mathematical notation, we’re doing something like:

y = r^x (mod n)   (x is secret, done ahead of time)
z = r^q (mod n)   (q is user-provided password)
y == z ?

They will be equal iff the password was correct. Here, x is the real password int, and q is the user-provided candidate password int. y is called encryptedPasswordInt, and z is called encryptedCandidatePasswordInt in the code.

This is considered secure because the discrete logarithm problem is considered hard. I say “considered” because it hasn’t been proven either way. For example, it would be great if someone could prove there did not exist a polynomial-time algorithm to solve the discrete logarithm. Of course, it would also be great if I were a billionaire with a yacht and I could solve the Riemann hypothesis in my sleep. Actually I don’t really care about yachts that much. That’s more of a “nice-to-have” one.

So, that technique works and has a bunch of research behind it. For example, check out these lecture notes or just search for “obfuscating point functions.”

Now for some methods you can actually use. Sorry it took me so long; I thought these detours were very interesting.

Method 1: Encrypt your private string

The first thing you should do is encrypt your private key string. At this point some readers will be thinking “Oh hey I know this great routine I can write called rot13. I love rot13.”

Do not use rot13.

Every time you use rot13, a kitten explodes. Rot13 is not an encryption method. It is a way to tell other programmers that you are a security newbie. It’s ok to be a newbie, unless of course you’re in charge of security at my bank.

In general, most encryption techniques that are easy to think of have been broken. If you want to be safe, use a community-accepted technique like AES. iOS comes with some powerful, though poorly-documented, security libraries that you can take advantage of here.

Method 2: Obfuscate your strings, independent of encryption

Now, you have your encrypted password, and you need to decrypt it at runtime. So you also have a decryption key. How have we really improved the situation? A hacker can still figure things out from just your string literals. Well, now he has to guess which two strings are the keys, and which decryption technique to apply, which is already much more work.

You can make things even harder by:

• Using English phrases as the decryption key for your private key. This way, if a hacker sees a list of extracted string literals, it’s harder for them to guess which one is your decryption key.
• Store a series of short, separate string literals in your code, and combine them in a random order to get your decryption key. This makes it even harder to guess your decryption key from a list of string literals.

Method 3: Obfuscate security symbol names

Next up, hackers can often extract symbols from your binary. Things like class names may be available to them. If you have a class named PrivateKeyHelper, you’re advertising to them where to look in your code. You can keep your code readable but place misleading symbols in your code by clever use of #define’s in your header files. For example, near the top of PrivateKeyHelper.h, do this:

Your code will look the same, but the linker will never see the symbol PrivateKeyHelper, only ComponentNode (or any other boring non-security symbol you choose). Do this for all function/method and class names that reek of security.

Method 4: Write your own key decryption function

The above method works whenever you have all the source, but fails when you’re using a library you didn’t build, including any third-party security library. There are a few very common decryption functions you are likely to use. A clever and determined hacker could look for calls from your code to these common functions. To fight against this, you could write your own decryption function. Again, don’t use rot13 (remember the kittens?), but something more serious.

Method 5: Use function pointers to make security calls

If hackers can follow a deterministic control flow through your code, they can still find your decryption function by working carefully backwards from your network request. But you can fight even this. If you don’t call your functions directly, but rather use a function pointer, then it will be harder for a hacker looking at disassembled code to follow the control flow. If you do this, try to fool the compiler into thinking that multiple values may be used for the function pointer, so it doesn’t optimize away the obscurity.

Method 0: Don’t worry

Lastly, and most importantly, all of this post could very easily fall into the category of “premature optimization.” Unless you have a lot of users or a lot of user money already invested in your app, I think this stuff should be a low priority. Why? Because the majority of apps only have a small number of users, and it’s unlikely that anyone is going to put in serious effort toward hacking your app. Of course, your priorities are up to you, but I thought I would mention this in lieu of Knuth’s warning about the root of all evil.

(Thanks to Susan Hohenberger Waters for some help with this topic!)

One talk in particular stood out, and there’s no question in my mind that this is single best talk at this year’s WWDC. It’s called Writing Easy-to-change Code: Your Second Most Important Goal as a Developer by Ken Kocienda. If you have an Apple ID to login, then you can watch the video from this page. To get this out of the way, the most important goal is to ship products, and that’s not what the talk is about. The talk is a motley collection of simple, great ideas that outline a powerful philosophy of programming.

Why this Talk is Good

The thing about this talk is, if a younger version of me watched it, I wouldn’t have been that impressed. Why? Because everything Ken says is common sense. You hear the idea, and you say to yourself, “well yea DUH of course.”

So I want to defend why this talk is actually very good. Because there are a ton of programming ideas that sound good, and seem to make sense – but in the end, only a few of them stand the test of time. I can now say I’m becoming an older programmer, having been at it for over 25 years now. I’ve been doing this a long time, and I’ve had some time to very seriously test out a number of philosophies.

And the points that Ken makes are both time-tested truths, and at the core of what is good about good code.

The title of the talk is “easy-to-change code.” And if you think about it, this one simple moniker really captures the main idea behind so much of the evolution of programming. We want code to be readable, maintainable, debuggable, feature-addable. If code is easy-to-change, all of these other properties need to be there as well (e.g. if your code isn’t readable, I would not call it easy-to-change). Moving from non-object coding to object-oriented thinking; using an actor model for parallel processing; adopting standards for interfaces on many levels; test-driven development: all of these ideas are essentially designed to help us make code easier to work with / easier to change. So this is an example of one simple idea being at the center of a lot of useful ideas, and, although you might not see it directly in the talk, a lot of the ideas presented are at the core of a set of other, related ideas that naturally would follow if you sat down to ponder all the consequences.

If I write any more, this post will be longer than Ken’s talk. I have to add the qualification that I disagree with maybe 5% of what he says, but I’m probably wrong about that 5% Go check it out!

Some background: A few months ago I had the opportunity to contribute to the Pulse news reader app. This is a great app for reading news, blogs, facebook updates, and twitter in one place. Among other honors, the Pulse team just received an Apple design award at WWDC 2011 — these guys know what they’re doing. The particular tool being released allows you to easily get line-by-line, nanosecond-resolution timing data for your code. As usual, it’s an open source tool under the Apache 2 license. Here’s the post.

ssh is an extraordinarily useful shell tool for logging in to, and getting a shell on a remote machine. You generally use it like this:

At which point, you’re prompted for a password. Which brings me to my first useful tip.

Skipping password entry

It turns out that you don’t have to type your password every time you use ssh if you’re always talking to the same remote host. You can do this securely by setting up a public/private key pair on your machine, and then giving your public key to the remote machine. After setting this up, the remote machine can confirm that ssh-using party knows your private key, without you having to type anything.

There are two big steps to accomplish this: (1) make sure you have a public/private key pair, which may already be done for you; and then (2) let the remote machine know about your public key.

Make sure you have keys

You might already have a public/private key pair, in which case you can skip this step. Check to see if you already have them:

If you need to generate a key pair, execute this command:

You might need to hit enter once or twice to get that command to complete – no passphrase is fine, the default settings are fine. Associating your email address with a key is optional, but can be useful to you or others for knowing which user is associated with this public key.

Letting the remote know your public key

If your remote account is set up correctly, executing this one-liner from your local .ssh directory will finish everything up for you:

If you don’t see any error message after that, it succeeded! Good work. Buy yourself a fancy drink. And one for me, while you’re at it, I’m thirsty here.

If it doesn’t work, ssh in to the remote machine, and make sure the .ssh directory exists. If not, create it, and try to send the file again (same scp line as before). If you’ve created the directory, and have permission to write to it, that should work. Anytime you ssh into that machine from now on, it won’t ask you for your password. Nice!

(Edit: Commenter @Adam helpfully pointed out that there’s a more official way to do this, using the ssh-copy-id command (ref). Unfortunately, this command is not installed by default, but can be obtained by installing homebrew and typing brew install ssh-copy-id. The scp command I give above is sort of a brutish, simplified version of that. Thanks for the tip!)

Dealing with a broken connection

For some strange reason, if you’re using ssh and the connection is broken, it basically seems as if your terminal is frozen. It just doesn’t respond to commands. But there is a way out. Just hit the enter, tilde, and period keys, in that order (tilde = shift+back-quote of course).

Why does that work? You can read more about this in the man ssh pages, under escape characters. Or, within ssh, hit enter, tilde, question-mark, to see a quick summary of what other meta-commands are available.

There’s also a way to address this problem more preemptively. You can edit ssh’s config file, setting the ServerAliveInterval to 10, or any positive number (I recommend something close to 10, though). This value indicates the number of seconds without hearing anything from the server before an encrypted ping is sent to check that the connection is still alive. The default value is 0, which means no such pings are ever sent. Here’s the details of how to set this up:

To read more about ssh config options, type man ssh_config from your bash prompt.

Syncing with server code

The last thing I want to mention is a bash script I use for keeping my local machine’s git repository synchronized with my server code. If you have a lot of server code, it might make sense to use a dedicated git repository for that code. I’m talking about a different situation – I have a lot of iOS code, and there’s about 200 lines of php code I need to run a very simple server. In this case, I’d rather have a single git repo on my machine, and keep a copy of the php files on my server. I use sftp to keep the files synchronized. The above scp command that eliminates the need for passwords in ssh also works for sftp, so it becomes easier to use sftp from a bash script.

Here’s a copy of a script that pulls in all php files from a given remote directory, into the current directory:

I hope that’s helpful!

If you don’t care about the why and just want to get your hands on some working code, skip ahead to The Code section below.

The Problem

I’m building an iPad game, and my app will be sending high scores to a server. If I built a simple REST interface for adding new high scores, it could be easy for a dedicated player to make up a fake high score. For example, let’s suppose I send an HTTP GET request to this url to tell the server to add a new high score:

http://myserver.com/newHighScore?name=Gilgamesh&score=100

Users can perform packet sniffing on network traffic using tools like Wireshark. Suppose our player, Gilgamesh, really really wants to have the all-time high score. If he sees this protocol, he could just open his favorite browser and type in a url like this:

http://myserver.com/newHighScore?name=Gilgamesh&score=3240923409

At this point, there’s not much my server can do. I can look at the user agent string, but that is also easy to fake. I could add a sort of password as an extra parameter:

http://myserver.com/newHighScore?name=Gilgamesh&score=100&password=supersecret

but this is still easy to crack with packet sniffing.

So how do you prevent malicious users from sending fake messages as if they were your app?

The Solution

I’m glad you asked! Because, luckily, there is a whole subfield of cryptography dedicated to this question. If you’re curious about diving into this general subject, I suggest you start with the wikipedia page on message authentication codes. If you just want to get your iPhone app working securely, read on:

The technique this code uses is called HMAC, which stands for hash-based message authentication code.

This is how it works: I have a message, which is a string. I’m not going to encrypt it, but I want to send it in an unfakeable way. To do this, I’ll compute a hash of the message, along with a private key (another string), and send that along with the message. If you’re thinking of hash tables, then, yes, this is sort-of halfway similar, but not exactly. I am using a hash function which takes a possibly-complex object and gives me a simpler object as output. For hash tables, we want the output to be “randomly distributed” in a certain sense. For use as an HMAC, we want a hash function to be irreversible. The point is that, if someone knows the output of your hash function, it’s very hard for them to compute the input.

And there are a bunch of hash functions designed with that goal in mind. Some of them are called MD5 (“message digest 5″), SHA1 (“secure hash algorithm”), and SHA2, which is actually a set of hash functions. Check out wikipedia’s MD5 pseudocode to get an idea of how hard it might be to reverse the output of one of these guys. (This page is also fun.)

One thing I want to point out is that malicious users can fake a message identical to one you’re already sent. If your API is idempotent (i.e., sending the same request twice has no additional effect), then this is fine. Otherwise, you will want to add some new piece to the message, making it harder to fake. For example, the client could receive an additional string from the server, called a nonce, and have to include that in the hash input. If your nonces are always different, a malicious use could no longer fake the same message.

The Code

I’ve added a small NSString category to the moriarty library to provide HMAC strings. This is how you can use it:

If you need to send complex data, I suggest using JSON along with Stig Brautaset’s JSON framework library. You can have an NSDictionary or NSArray of strings, numbers, and other arrays/dictionaries, and easily encode this as an NSString by calling [myObj JSONRepresentation];.

What does the server do with this? If you’re using php, here’s how to verify the authentication:

You can get NSString+HMAC.{h,m} by downloading moriarty; free to use, Apache 2 license.

Or, you can just copy the code from here. As you can see in the m file, this is basically a convenience wrapper around a library that is included by default in iOS (but is difficult to learn how to use).

May your messages be safely authenticated!

Why small source files are good

Here are two principles to code by:

1. Your code should be simple to users, and
2. Everyone, including you, is a user.

I could write a whole post about these ideas, but let me just summarize by saying that anyone working on your codebase, including future you, cares a lot about how simple things are. When each individual idea in your codebase is succinct and transparent, things are easy to modify and update, and bugs are harder to create and easier to squash.

File size is not a perfect predictor for code simplicity, but it’s a darn good heuristic.

Use categories on your own classes

Instead of having one header and one implementation (h,m) file for your UIViewController subclass, I suggest splitting the main pieces of functionality out into their own files, as categories of your class.

For example, suppose we’re writing a tetris clone for the iPad. (Don’t actually do that, btw. You might get sued.) Let’s have a primary view controller called TetrisViewController. It would be easy for this file to become huge, so we can split different aspects of gameplay into separate pieces, such as this:

• TetrisViewController.{h,m}
• TetrisViewController+Tutorial.{h,m}
• TetrisViewController+Animations.{h,m}
• TetrisViewController+Network.{h,m}

Since the class is officially declared in TetrisViewController.h, this is where all the instance variables are declared. Any code specific to tutorials, animations, or network play goes in its respective category file. The goal is to partially encapsulate that functionality in its own file, while logically speaking, those methods will have full access to all the variables of the class. A good rule of thumb is to group methods together when you are likely to be editing them together; you want to minimize the need for file-switching while programming.

Template code

Let me fill in the details of how these files might actually look.

Within the category implementation, you’re free to call any public method on the original view controller, and any methods (including category-private ones) within the category. Note that you can’t call private methods of the original class from the category, at least not without a compiler warning. In practice, I’ve found that this is not a problem. If the categories are separate enough ideas, the methods you need to call from a category will most often naturally be public methods. In some cases where this was not true, I found it made sense to make a previously-private method public to solve this. The small number of times when I did this have all made sense in retrospect, in the sense that the newly-public methods did not break encapsulation.

The header file of the original class doesn’t need to know anything about the category files. The implementation file needs to import them so you can call them. I find it useful to think of these as sort of hooks into the original class. Ideally, you only add about one line of code to the original class per public category method. In other words, you want your code impact on your main m file to be very small when you add a category like this.

Here’s an example of how your main implementation might look:

One last thing: it’s definitely more work to retroactively pull out categories from a huge view controller, so I highly recommend trying to split out categories as you code, as opposed to after you’ve got huge files. I hope that’s helpful!

CArray is useful when:

1. You’re working with C data types — pointers or primitive types or structs thereof;
2. speed is a problem; and
3. you don’t want to use cocos2d or a similar library.

CArray can play nicely with NSObject pointers, but it isn’t designed to hold strong pointers (i.e. it won’t call retain on them for you).

Speed

Suppose you’re willing to work with C, C++, or Objective-C, all of which play nicely with iOS. Which of the following function calls is fastest?

The C call is basically always faster than the other two. I could write a whole blog post (easily) about the speed of these three. It gets complicated, but the simple version is that the C++ and Obj-C calls are often comparable in speed (reference), and the C call could be anywhere from 20% faster to twice as fast (reference, see the comments).

Sometimes you may be working with mostly-dumb (i.e. needing very little encapsulation) pieces of data, such as floats or CGPoints (which are structs, not NSObjects). If you use NSArrays, you need to wrap these types in NSNumbers or NSValues. Just the wrapping and unwrapping takes time, in addition to the method call overhead vs straight C function calls. In this situation, CArray is faster by eliminating the overhead.

The root of all evil

Now is a great time to mention one of my favorite Donald Knuth quotes:

Premature optimization is the root of all evil.

I’ve seen a lot of code, and in at least 99.99% of it, the work it takes to replace object-oriented calls by straight C calls would have destroyed readability and maintainability without touching noticeable app speed. Almost all the time, it’s just not worth it. Every once in a while, when Friday the 13th falls on an equinox during a leap year, it’s worth it. That’s when you consider something like CArray.

You’ve been warned.

How to use CArray

CArray can also work nicely with pointers. For example, we can give an array a releaser function that it calls on elements as they are removed.

Even though CArray is so low-level, it’s fairly powerful. It’s also easy to memory manage if you follow the conventions that every CArrayNew is paired with a corresponding CArrayDelete; or CArrayInit paired with CArrayRelease if you want to handle the memory allocation yourself.

Getting CArray

CArray is now part of the moriarty library. Open source, Apache 2 license; free for use in personal or commercial products, including for redistribution (see the actual license for details).

To get the code just click on “Downloads” from moriarty’s github page. Unzip the downloaded file, and copy over CArray.{h,m} into your Xcode project.

PS

Long after writing this code, I learned that cocos2d already has something extremely similar. I basically rewrote ccArray from cocos2d. (Honestly, I’m sure things just like this have existed since the beginning of C. It’s a ridiculously common use case.) Now, there is some contention about the speed of ccArray in cocos2d. For example, this post argues that it’s unfair to count the NSNumber wrapping time against NSMutableArray. Well, technically that’s true. But if you have some time-critical code dealing with arrays of floats, the CArray approach is going to be much faster than the NSMutableArray approach overall (reference). So, in the end, I think the wrapping & unwrapping time is important, although maybe some people won’t want to think of that as part of NSMutableArray’s performance.

There’s also questions of NSMutableArray’s cleverness. I don’t know the implementation details, but based on others’ performance measurements, NSMutableArray does intelligent things under the hood. I don’t know what it does. For some operations, like inserting a new first element to the array repeatedly, NSMutableArray is much faster than CArray. But, if you’re in a position where you need something faster than NSMutableArray, then you need to understand the time complexity of each CArray operation so you can use it optimally — meaning, avoid slow thing like inserting elements at the beginning.

I added this last bit just to basically cover my butt and say “hey guys, I know about cocos2d’s array stuff. Yep, it’s similar.” Also CArray has fast custom sorting, duplicate-elimination, and binary search (which I don’t think ccArray has right now). Holla.

The problem

The problem is that speed is meant to be manipulated outside of animations – you set it up before you start the animation, not during. If you try to change the speed of a CAAnimation while it’s happening, your app will barf (in the debug logs). If you change the speed of your CALayer, your app won’t barf, but your animation will jump. I think what’s happening is analogous to the reason the functions sin(x) and sin(2x) will be different-speed versions of each other, yet if you suddenly switch from one to the other, you can easily get a discontinuity (aka a jump):

A solution

I spent a while thinking about ways to address this. I was very tempted to figure out how far into the animation the view was, then mess with other CAMediaTiming properties to place the speed-changed animation at the right offset to continue seamlessly (basically match up the phase shifts of sin(x) and sin(2x) to eliminate the jump). I think this approach can be done. But!! Fearless readers, do not tread down that path. Bitter, bitter experience has taught me many a time, the priceless adage:

Simple code is better.

Messing with phase shifts is never simple. So, I opted instead to forego Core Animation’s repeatCount mechanism, and simply restart the animation after each cycle. This way, if I want to alter the speed, I can very easily do it between cycles. Technically, the speed won’t change the instant you want it to, but if the cycles are short, the user won’t notice the difference.

And, to follow another of my favorite adages (tongue in cheek here):

Why write 10 lines of code, when you can write 30 in a more reusable fashion, and a blog post too?

So of course I made a reusable class to handle this situation for anyone facing the same challenge.

It’s called DynamicRepeatAnimation; you use it like this:

The code

This code is more specific than a lot of what’s in the moriarty library, so I decided to just leave this class attached to this post, and not cross-listed anywhere else. Open source, Apache 2 license. Here’s the source:

And, for the curious, a code listing:

This is a very easy-to-create class once you know Quartz, so there’s not much to explain. I just thought it would be useful, so I added it to moriarty (free to use, open source under Apache 2 license). I think the header file explains it pretty well: