The general question in all of these articles is: “Can an average guy become a successful iPhone developer?”. The answer depends on how you define success, and on that topic I can speak from my own experience.

If, to you, success means making a million bucks overnight you will most likely be unsuccessful. To me, success is defined as the return on my investment (both in time and money) on the project. In my previous article, I mentioned making somewhere around a hundred dollars a day on iLaugh. However, I didn’t mention how much I invested in the project.

The first version of iLaugh and its subsequent revisions took me very little time to create. I estimate that I invested between ten to twenty hours of my time to create iLaugh 1.0. At my asking rate of $100 per hour, that represents a $1,000 to $2,000 investment. The server running the first iteration of the iLaugh API cost me about $100 per month to maintain.

If you look at the numbers for iLaugh from previous months, I make over $3,000 monthly (for a total of over $8,000 so far). Thus, I consider it a success.

Many people, in response to my previous article, said that I too, was one of the lucky ones, albeit on a smaller scale. And while that may be true, considering the low quality of that first iteration of iLaugh, a more carefully crafted app would likely have done better.

I believe the potential for success is relative to the investment put into anything.

If you look at the familiar success stories, many of them involve reinvestment and good marketing. For instance, Tapulous hit the jackpot with their Tap Tap games. Being good friends with one of their employees, I know exactly how much work goes into their production.

Perhaps one of the most talked-about success stories is Trism. Its developer, Steve Demeter, made an insane $250,000 in just two months. What I believe is the key to Steve’s long-term success, is that instead of buying a fancy sports car, he reinvested his money into founding a sustainable business.

Part of reinvesting, and a facet of development often ignored, are things that a typical developer can’t do. Most importantly: design, copywriting and marketing. These are things that will most likely have to be outsourced. Developers are reluctant to do that, because it’s very costly, but in the end, ignoring it is going to cost them the popularity of their application.

I view iLaugh 1.x as a catalyst towards bigger and, hopefully, even more successful endeavors.

In fact, I have already put a big part of my (in comparison to the numbers above, quite mediocre) earnings into the second iteration of iLaugh. I’ve hired a bunch of people much more talented than I am in their respective fields, and iLaugh 2.0 is coming along really nicely. It will be entirely different and nearly incomparable to the first iteration. There are some very cool things coming.

So, responding to my initial question: “Can an average guy become a successful iPhone developer?”. Yes! An average developer can be successful in the App Store. But it takes hard work, a lot of time, money, and perseverance.

The latter tend to blame the App Store for the failure of their application(s). Granted, the App Store is a harsh market which has both its advantages and its flaws. But, in my humble opinion, a good craftsman never blames his tools.

The App Store has trends that can be analyzed, and if you’re going to be developing for the iPhone, you need to learn how to adapt. I have learnt this first-hand through experimentation, and have learnt many valuable lessons along the way.

Last September, while working on a much bigger iPhone game, I thought it would be cool to create a quick one-trick application for viewing jokes. I never envisioned that iLaugh would become my most lucrative app that would keep me going while I develop the aforementioned game.

The Y-Axis shows daily revenue in US dollars.

Let’s leave the end of the graph (Feb-Apr) aside for a minute, we’ll get back to it.

You can see the initial release spikes, typical of the App Store, and then a very depressing downwards trend right after release. For the second release, 1.1, I upped the price from $0.99 to $1.99. Which slightly lowered the initial spike revenue. But at that stage, I had a much more mature app which unfortunately, due to lack of effective marketing stagnated at a sub-$20 daily revenue.

But in February, I made pretty much the best decision I have ever made. That, of course, was to release a Lite version. I initially thought it would be a nearly cost-free way to get some free advertising for the premium version. The main reason I put ads inside the Lite version was actually not to create revenue, but rather to give users a reason to upgrade. But, other than that, the Lite version was an identical, fully functional copy of the premium version.

As you can see, it did a pretty decent job of advertising the premium version. Since the mid-Feb release of iLaugh Lite, daily revenue for iLaugh has been much higher than it previously was.

Fortunately, iLaugh Lite became quite popular on the iTunes App Store, and while never entering the global top 100, it has charted as high as #29 on the Entertainment chart, and has been in the top 40 entertainment apps nearly since its release.

While this did have some unexpected consequences, like bringing my entire server down due to excessive traffic which brought the iLaugh service down and forced me to upgrade to a better server, the benefits were pretty clear.

This graph shows daily iLaugh Lite downloads.

This equates to about 100,000 monthly downloads.

Here’s a graph that shows the web-service traffic this generates (since each joke is fetched from my server, this gives me a pretty good overview of the actual usage of the app). Unfortunately, I only started using this particular analytics package on March 2nd, so that’s when the graph starts.

To date, iLaugh has served over 6 million jokes, and it’s going at about one million per week.

So far I left out one pretty important thing: ad revenue. But one always leaves the best for last, right? So here goes:

As the installed user-base for iLaugh Lite grows, so does daily ad revenue. Currently, I’m seeing pretty good numbers. I have around 6 million monthly ad impressions, and as you can see in the above graph, I’m seeing around $100 daily ad revenue.

While these aren’t mind-shattering numbers, I think they give a pretty good overview of what one can achieve as an average developer for the iPhone platform.

When you upload an iPhone application to the App Store through iTunes Connect, you’re presented with a few screens of information to fill in. First, there’s the screen where you put the Application’s description, category, and any other textual information about it.

Then there’s the screen where you upload the binary, the icon(s), and screenshots. And lastly there’s a screen to set the price. Unlike what I thought would be the case, you cannot chose a specific price. You get to chose from several price groups. A price group has a price in US Dollars, and a price in different currencies usually of a similar value. (For example, a $0.99 app in Switzerland is CHF 1.10)

At the top of this page, there is a little warning message that says you need a contract with Apple if you’re going to put up non-free apps. I did not pay too much attention to it, and the rest of the process seemed to go smoothly, eventually leading back to a page where I could see my app was “In Review”.

I was still slightly confused about this contract message, and decided to find out what it was about. I asked a few fellow developers, and found out that Apple would not sell my app until the contract was taken care of.

In iTunes Connect, there is a section on contracts, with a link to create a new contract. A contract is made of three parts; Contact Details, Banking Details and Tax Details.

• Contact Details

  This is very straightforward. I just had to fill in my full contact details. (Including physical address.)

• Banking Details

  This is slightly more complicated. I’m with one of the smaller Swiss banks, and I wanted to use this account for my App Store revenue.

  One of the things Apple requires is a SWIFT code. Luckily, I’m with a Swiss bank, and these tend to be very professional. I just had to give my bank a phone call, and I had my SWIFT code. However, after reading a recent topic on the MacSB mailing list, it appears to be very common for many of the smaller banks in the US and other countries not to have SWIFT codes. In which case you’re screwed and you’ll have to open a new account with a bank that has a SWFT code. (Apple recommends Bank of America.)

  Another thing required by Apple is the IBAN. International Bank Account Number. My bank informed me that they printed these on all the bank statements they issued. However, I didn’t have any bank statement around. It wasn’t too hard getting this number. Switzerland has a standardized way of building these numbers from your CB Number (Clearing Banquaire - this is what we call Branch IDs) and your account number. A handy little script I found on the web would take this info and convert it into an IBAN. (I later found one of my Bank statements, and the IBAN generated did indeed match the one on the statement).

  Apple also asked for the Branch ID (I put my CB number for this) and account number, and another number called the SIC / Short Code. I researched it a bit, and it looks like I didn’t need it. I just left that field blank.

• Tax Details

  This is where it gets nasty. Note that this is not an Apple thing, this is government tax regulation. Apple provides an online version of the government form W-8BEN. It seems I am not obligated to fill this form in, but if I don’t, Apples keeps another 30% of my revenue as anticipated taxes. This, with the 30% commission they take from every sale, leaves me with only 49% of my gross sales. (70% * 70% = 49%)

  This form is extremely cryptic, and I filled it in to the best of my knowledge. This, however, wasn’t enough for Apple. The form complained about missing information. It’s only then that I realized that Apple provides a handy tip sheet explaining how to fill the form in, and what are the most common answers.

  With this information, I was able to understand and fill in most of the form. Except for one field: Taxpayer Identification Number. Since I’m not a US resident (although I’m eligible for citizenship by blood, and plan to apply soon), I did not have this information. Apple’s tip sheet luckily had a small paragraph regarding this. An EIN (Employer Identification Number) would do. To get an EIN, I had to download another form entitled SS-4.

  This form was even more cryptic than the previous one. It is obviously made for more traditional companies, and had questions asking how many employees I have in different field, how much wages I paid them, where and when my company was incorporated, and a bunch of other tax-related questions. It also asked a few things I couldn’t fill in, such as my SSN (Social Security Number - I don’t have one). I phoned the IRS (Internal Revenue Service) - the government entity I had to submit the form to - and it turned out this field wasn’t necessary. In response to the question “Check one box that best describes the principal activity of your business”, there of course wasn’t anything about technology. I had to tick “Other (specify)” and enter “Royalties”.

  There is three way you can submit the form. Firstly, you can do it the traditional way of mailing it by post. But this would take a minimum of 4 weeks. Second way would be by fax, but this would also take at least 1 week. The third way is actually pretty clever. You fax while you’re on the phone.

  Problem: my phone and my fax are on the same phone line. Meaning I can’t do both at the same time. I do have a cellphone, but phoning oversees for a good half hour at least from a cellphone would be so outrageously expensive it didn’t make any sense. Luckily, I though of a brilliant idea, and opened a Skype Out account. The audio quality wasn’t very good, but at least it worked. After another hour of phoning, I finally had my EIN and could submit the W-8BEN form to Apple.

Everything seems to be in order as of now. My app is still in review, but expect it in the app store soon.

Part Two: Asymmetrical Cryptography

Asymmetrical Cryptographic Keys are a great way to secure you app, because the code used to generate serials is not included in your app, thus removing the risk of a keygen. Using a private key, you sign (or encrypt) some of the user’s details. You then use this singed data as the key to your software, either in the form of a serial, a file, or even an image with the data embedded. You then verify that the signature is valid using the public key in your app.

Example

Start off by generating a set of private and public RSA keys. You can do this by using the following in Terminal.app:

openssl genrsa -out private.pem 2048
openssl rsa -in private.pem -out public.pem -outform PEM -pubout

You can use different size keys. Using a shorter key, such as 512 will make your software more vulnerable to brute-force attack, but has the advantage of making the signature smaller (Which is useful if you wish to display it in the form of a Serial Number).

I believe I used the following set of keys. The keys are also included as files in the source code of this example (available at the bottom of this article).

-----BEGIN RSA PRIVATE KEY-----
MIIEpAIBAAKCAQEAwKhjrkHmaupDGERSHdgZuSwBWBr4kufBGz0Dk5sn3PR3ZtaP
Vrv6+5Mdz1gAEBYbUVH3m+4+dHcwol5xNckKBT8M5Zy6GPoV9dBUS/1wQBzgdTzf
jvV4uE9S0pofQWw3faZ904tTOjbM0qUko2nd7yyjYBhh/m1ABEFHuL62BvRp13na
vv6534OqqeExEb9VD3K9+Rr4+YQVRUpqZSz2xwhqfLgAzFVQ9bmSG8yTVKmF/vQA
t+N8ThN2WO5qYtCbPawkmIpwvUCTXkxAiiTPNOiU3G1vwtzBoma9TL6dgGmhq6P7
0KBcQNGUEpA2PFC7MEBeNyVyiMIOAvrkHjY/VQIDAQABAoIBABUNET9EMiIykLxB
Etvx9fWWylrPL6QVsLMCOrbROEzbZYSWIzlt9uGwVIyIaBFZ6Qg8tZqTML3XHDhR
q3seCXtDRWx9cJQ0F1wxtFRNUAuhXCFTUnYzekphWIJslse2RGX1YEBSM/jjbgQC
SXuVoMt2jC9+2o5Lb7hHTcfxBsDBmZpghArT5seTOwDOOhTULqoh2wgZYB2IpgTI
UV2CPpAqRVECRnPNdE5UcNIeHc7g4aji5BO0G0u8uM4RUffuRcLaPymuxpU9vwd1
gjVaG6BF/2odW7GEBU3FNLUtvr9MxT+HC+hwOJUuk8NWxU7DqMdyiwSs7W3Nnx7R
5RPvj8ECgYEA34DZjy5EMm7QyPZA6DvAZv6RIecFEwEkwFG+mQgoCy4VfLikkwzC
bI8M8fc6Xiix7ZTjSmvuHt1D4HSRHMOVYgDzY0A5+F+8X657mN5TwNlYMOUkDX3I
rNwc3cRVqtLZYGX0H7cR6eEomGJ7fA9gKuTpaXI0IJz5DsqsgTaGvfECgYEA3Ktr
Q53i52jnssL9c3JsxQO+I/2fWKgo3bZeBI/5zLsz3itVjFjMVldrIK1QZWXI4z7l
dPYwh6qCa1unsizuuzeAhW6NcuUjGPBlBqlo/a9WfOo16ExPXBoH3PH2DXz/YS+D
DOp4Wl8ePhO7C46t3zmGahchysx3kCGkAmNkA6UCgYEA0upvZNUOemFlGiB5RC8O
9KMLJukyOqr7mZoKubOexl4o3NgKRtLlrziXyMe8Bxt0PXYhwBt2TR4Vbf3S60gO
8rte86yqiB8gT1MDRFGazATPWuUCTtECzU2y1/ztsxTjGjtcU4mZmBJpEtTtHzgL
Uq9PLbkeRCCeUD0m6ZEhOqECgYB85jFyNh1F6aSrE56tB2j1Iicu69CTN6rZwuz4
HB3BeXvkFhb3txMBE7244yAMJE5OAT2Ss/3H7AShi2EhgjklkkaWP3qkO3lgFkC4
Qo8Ad4u2bEJS105bzQgCUJl6DPPnKCM+3j98tzXA4R4PbpSPMloYFju0M4LA+6l/
CI6FWQKBgQCWr4Py/GBhgoYOlY/f41NzOfsttwcCBum3uPbiPq6gM/AQQRjzdUmK
QRgG9XXs/33KUMiU+/15hK8ShrOWRSx+zHdgeMhVmuYJdEeygANI9dkonJ3+Olth
77beMQrKIY9kw4bVRFtLWhxfAHXvnksnBg79PX05joVvoHFgVxuwlg==
-----END RSA PRIVATE KEY-----
-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwKhjrkHmaupDGERSHdgZ
uSwBWBr4kufBGz0Dk5sn3PR3ZtaPVrv6+5Mdz1gAEBYbUVH3m+4+dHcwol5xNckK
BT8M5Zy6GPoV9dBUS/1wQBzgdTzfjvV4uE9S0pofQWw3faZ904tTOjbM0qUko2nd
7yyjYBhh/m1ABEFHuL62BvRp13navv6534OqqeExEb9VD3K9+Rr4+YQVRUpqZSz2
xwhqfLgAzFVQ9bmSG8yTVKmF/vQAt+N8ThN2WO5qYtCbPawkmIpwvUCTXkxAiiTP
NOiU3G1vwtzBoma9TL6dgGmhq6P70KBcQNGUEpA2PFC7MEBeNyVyiMIOAvrkHjY/
VQIDAQAB
-----END PUBLIC KEY-----


Next, we will create the generator. We will start by concatenating the details (full name and email address) into a single string:

First Last+email@address.com

Then, we will use RSA to sign this string using the private key generated above:

lFZpwJ6GPLXz8sDez033RIxJsN072lOEa0qF+8hQ5KCcZEPQqSBU4MKbW+UJxIfSmKMOBYnVfy/wwAoSxTtqn2JIuAPEJvsTlb0mGH5u7mpxH+FDj2TicoBKephWv7UXP9k10OPA45247+j/u4yKT1UZcq7WjChQ3JoE3wBtEoFucQm8vLk/VqvNaBM1TyNEgwT8FmrKlbK1FNUI8nQ0QOEJ9P8oMAblkWE5kALZZqWnAs6xE7c73sex73t5FvxYRqRDzRDzkjTwK0anXCv8dmeLvnaaHAFcfD5llx09oa89q+wzWucE7V1TsPRYKH1sZsSz5G2xTt2pZrjIoTw5ew==

Note: for this sample app, I explicitly turned off creating newlines in the base64 signature.

The code used for this generator is:

-(IBAction)generate:(id)sender
{
    NSData *privateKeyData = [NSData dataWithContentsOfURL:[NSURL fileURLWithPath:[[NSBundle mainBundle] pathForResource:@"private" ofType:@"pem"]]];
    NSData *publicKeyData = [NSData dataWithContentsOfURL:[NSURL fileURLWithPath:[[NSBundle mainBundle] pathForResource:@"public" ofType:@"pem"]]];
    NSString *details = [NSString stringWithFormat:@"%@+%@", [name stringValue], [email stringValue]];

    SSCrypto *crypto = [[SSCrypto alloc] initWithPublicKey:publicKeyData privateKey:privateKeyData];
    [crypto setClearTextWithString:details];

    NSData *signedTextData = [crypto sign];
    NSString *string = [signedTextData encodeBase64WithNewlines:NO];

    [serial setStringValue:string];

    [crypto release];
}

As you can see, I used Septicus Software’s great SSCrypto framework for this task… It makes things so much easier… Unfortunately it doesn’t support base32 or DSA, which would both have helped make more human-friendly keys.

The other piece needed is the validator, used in your software to validate serial numbers. Include only the public key in your app, and use RSA to verify the key.

-(IBAction)validate:(id)sender
{
    NSData *publicKeyData = [NSData dataWithContentsOfURL:[NSURL fileURLWithPath:[[NSBundle mainBundle] pathForResource:@"public" ofType:@"pem"]]];
    NSString *details = [NSString stringWithFormat:@"%@+%@", [name stringValue], [email stringValue]];
    NSData *number = [[[serial stringValue] dataUsingEncoding:NSUTF8StringEncoding] decodeBase64WithNewLines:NO];

    SSCrypto *crypto = [[SSCrypto alloc] initWithPublicKey:publicKeyData];
    [crypto setCipherText:number];

    [crypto verify];

    if([[crypto clearTextAsString] isEqualToString:details])
        NSRunAlertPanel(@"Result", @"Good serial!", @"OK", nil, nil);
    else
        NSRunAlertPanel(@"Result", @"Wrong serial!", @"OK", nil, nil);

    [crypto release];
}

Important Note: In this sample code, I included both the generator and the validator in the same application. I included the private.pem file in the bundle. You should never do this. If the private key is ever leaked, it compromises the whole security of your application.

Making it safer

You can easily make it more secure by combining this technique with the technique explained in Part One. Instead of simple concatenating the details as I did here, you could use all the techniques applied in Part One, such as using a hash instead, or doing ROT13 on it, or rearranging the order of the characters.

Another thing you should do is to hardcode and obfuscate your public key. Having it as a file in the bundle makes you vulnerable to key substitution. (Basically, a cracker would replace the public key in your app by a different key they created using a private key they know, thus making their licenses valid instead of yours.)

Form Factors

While you may not realize it at first sight, this has become one of the most common methods in Mac shareware, thanks to the open-source framework AquaticPrime. AquaticPrime uses this technique behind the scenes, by embedding the signature in a plist file. AquaticPrime is a very easy way to use this. Unfortunately, if you decide to use AquaticPrime.framework in your app, it is very easy to replace the .framework file with a malicious one that will always claim your licenses are valid.

To date, as far as I know, there isn’t any HackuaticPrime.framework yet, but this might one day become a problem with AquaticPrime gaining popularity thanks to it’s extreme simplicity of implementation.

Update: Devon in the comments suggests implementing a hash check of the framework, which is a simple way of checking the framework’s integrity. Of course, there are still ways to get around it, but this makes it one step more difficult.

Another common form factor for Asymmetrical Cryptographic Keys is custom URL schemes. That’s actually a very clever and convenient way of doing it. To register, the users get to simple click on a link which looks like this: (All the user sees is a nice “Click here to register” link)

myapp://name:email:key

Another clever, but controversial form factor is Agile Web Solution’s 1Password License “Cards”.

And of course, if you find a way to make short base32 signatures (I hear DSA makes short signatures), you can even use longer Serial Numbers.

AHJ53-5HGJZ-8DG8R-284DF-56FJB-74FH4-FJUEH

Sample Code

The code used in this article can be downloaded here.
As always, licensed under MIT license. If you do use it, mention it in the About Box or readme.txt.

Part One: Serial Numbers
The next part will be coming soon.

Part One: Serial Numbers

Serial numbers are the simplest, most practical option. However, they are also the least secure. It consists of taking at least one of the customers’ details, and creating a serial number from it. The serial number is usually tied to either the customer’s name, or his email address, preferably both.

For example, let’s say the customer’s name “First Last” and his email address is “email@address.com”. The first step would be to strip his name and email address of any non-alphabetical characters, concatenate it and convert it to uppercase. (I put the email address first, because it’s less recognizable) Here’s what we get:

EMAILADDRESSCOMFIRSTLAST

Now map this string onto a XXXX-XXXX-XXXX-XXXX-XXXX key. If there are any character leftovers, just discard them. If there aren’t enough characters to fill all the Xs in, leave them as something constant. (they don’t have to be all the same, but they have to be the same for each position all the time. You could for example say you’re mapping it onto an QRST-ABCD-IJLK-EFGH-MNOP key, and leave unfilled spaces as is)

EMAI-LADD-RESS-COMF-IRST

Then, we’d apply ROT13 on it.

RZNV-YNQQ-ERFF-PBZS-VEFG

Lastly, we could replace any swearwords in the key by some random other constant text, just in case.

Another example, using a similar method: Using the same customer, here’s what we’d do. Take his details, concatenate and salt them:

First Last+random salt+email@address.com

Then, MD5 the result and add another salt:

salt+0fb61d4a0f894c63d3ddbd8388404b6c

Next, SHA1 the result:

28a8275bdcbca542f567efef9cc4db2150c38900

And finally, uppercase it and map it onto a XXXX-XXXX-XXXX-XXXX-XXXX serial:

28A8-275B-DCBC-A542-F567

When you have decided on a serial scheme, implementing it is easy. Upon registration, you take the buyer’s name and email address, and generate a serial from it. He then has to input this serial into you app, along with his name and email address. All you have to do in you app is take the name and email address he gave you, generate a serial from it, and check it against the serial he gave you.

Making it more secure

For security reasons, one important step to take is obfuscating how you create those serials, in case anyone tries to create a keygen for you app. The easiest way is adding dummy maths code in the middle of the code where you work out your serial. It will not affect your serial, but it will show up in the assembly code in case anyone tries to gdb your app (more on that in another blog post I have planned).

Another quick thing you could do is shuffle the characters a bit on a set pattern to make them less obvious.

For example you could use this pattern:

ABCD-EFGH-IJKL-MNOP-QRST

becomes

TMLN-DQGA-ISPC-BEOK-FJRH

Stand-alone serials

Sometimes, your serials cannot be tied to any of the customer’s data, for example for retail sales. In that case, you’d need a different serial scheme. You need to choose certain characteristics / rules that make a serial valid. It could be as simple as checking that the 19th character is a W.

Here’s a set of example rules you could use:

• The ASCII value of the first character of all five blocks of four characters have to add up to 100.
• The last character of all five blocks of four characters have to be vowels.
• The first character of either block 3 or 4 has to be E.
• The ASCII value to the third character of every block have to be even numbers.

In your apps, just check the serial against the rules, and if it’s correct, you can assume it is a correct serial.

For your generator, you can have a pre-made list of valid serials, and assign them to a customer or print them on a retail copy when needed. The problem with this method is that you can eventually run out of valid serials. In which case you would have to generate a new batch of serials, or reassign already used serials to a second customer.

Another (better) way of doing stand-alone serial numbers is splitting the serial number in two, and basing the second part on the first part. [thanks to tomasf from the #macsb IRC channel for this method]

For example, in a serial number ABCD-EFGH-D07A-A959-F269, separate the first eight characters from the rest of the serial:

ABCDEFGH

Salt it:

saltyABCDEFGH+123

MD5:

d07aa959f269104ab28e2a748c415c5c

Map it onto XXXX-XXXX-XXXX:

D07A-A959-F269

And check it against the second part of the serial. In this example, the serial is correct.

Part Two: Asymmetrical Cryptographic Keys
The last parts will be coming soon.

To all those who are heavy Warcraft III players, this is for you. This tutorial will show you how to set up an autorefresh bot, so that you do not have to open and close slots manually every time you host a game. (it can be very tiring)

Download The Software

To start you need to download this windows (.exe) autorefresh: Click here
(This fileis a zip archive. Since it’s missing the extension, you might have to change its same to something.zip and then unzip it.)

Next you need to download the mono framework: Click here (warning: big download: ~50MB)

Installation

Mount mono’s disk image and install the framework using the installer package inside.

Now check wether you have X11 by searching for it in the /Applications/Utilities folder. If you already have it, you can skip to the next section. Otherwise, you need to install it from the Mac OS X install disc. Insert your Tiger disc. You then need to scroll down:

Open “Optional Installs”

Now check only the X11 row and proceed with the installation

Setting up

Unzip Warcraft3AutoRefresh.zip and open the folder you just unzipped. Now open Terminal.app (you can find it in /Applications/Utilities) and type “cp ” (do not forget the space after “cp”) and then drag Warcraft3AutoRefresh.exe to the Terminal window.

Now, type ” .autoref.exe” and press return (don’t forget the space before ”.autoref.exe”)

You can now exit Terminal. Open X11 (you can find it in /Applications/Utilities). Go to application menu and choose “Customize Menu…”

In the window that pops up, click add, then double-click on the new item’s “Menu Name” column and set it to something like “AutoRefresh” (it doesn’t actually matter what it is, it’s your choice). Next edit the “Command” for it and set it to “mono .autoref.exe”.

Usage

Now everything is set up, well done! Now, when you want to use autorefresh, just open X11, and choose “AutoRefresh” from the Applications menu. (Obviously, it will only work when you’re hosting a game on BNet)

Update: download link for autorefresh fixed, thanks VoltmanEXE!
Update 2: forgot to mention that the downloadable file for the autorefresh is a zip archive. Since it’s missing the extension, you might have to change its same to something.zip and then unzip it.

The key to becoming a good rich successful Mac shareware developer.

We all want to be rich, don’t we? This is a guide on how to become a successful (ie. rich) mac developer. This is the process I used in my own app, Exces. It worked really well for me.

What you need

To start off, you need a good decent application idea.
An important point to keep in mind is that you must focus on you target market’s needs, not yours. If you’re making an app that prints receipts, no one gives a damn that you own a shiny receipt printer, it’s gotta work with normal A4 Inkjets as well.

Also, when writing your cool new app, pay very close attention to the interface. The UI is what your users will see and work with.

The Fun

Alright, that was the boring common sense part, here comes the fun!

Here’s where you start investing. Being rich is about taking risks. Taking the risk to put money into your unfinished app. You might lose that money, but if it’s a success, it’s totally worth it. Look at Wil Shipley and imagine yourself owning that same bright red sports car.

Alright, so you’ve decided to be a true brave Gryffindor and to take the risk? Start by getting yourself a good graphic designer. *poke* *poke*. But be warned, don’t start throwing up slugs when you see the number of zeros after the price! Now’s the point of no return, when you pull out your credit card and make the first real investment. I’ve emphasized the word “credit” because it’s a good option to borrow credit if you don’t have any of your own cash to spend. In fact, that’s what I did.

You might ask yourself what you need this designer guy for. Well, most important of all, you need him for an icon. I cannot stress enough how important the icon is. It’s probably the most important thing about your app. It’s the app’s public identity.

Nearly as important as the icon is the website. This is where users will read about your app, and in the end hopefully buy your app.. Get the designer to create that too. Go for a stylish but simple site, but definitely stay clear from getting inspiration from big company’s sites. They’re multi-billionaire companies, it’s all right for them to have sites with thousands of pages. But for you, small ISV (independent software vendor), it’s not. Huge complicated sites will scare customers away.

A few simple rules for your site

• If you need more than one click to get from the homepage to your product’s page, you gotta rethink your site

If you do not use a custom webstore:

• If the buy link is not clearly visible on every page related to your app, you gotta rethink your site

If you do use a custom webstore:

• If it takes more than two steps to buy your product, you gotta rethink your site (I can’t recommend potionstore enough. It’s got everything a micro-ISV needs in a store, and it’s SIMPLE!)
• Make very sure that it’s clear what the customer’s buying and how it all works. Keep it as simple as possible and do not follow big sites like Amazon’s example

Time to whip out your credit card again! You need hosting now, and a domain name. When you start you don’t need a 100% super-reliable host - yet. Go for something cheap, you can always change after a few months.

Release time

Right, everything ready for release?

What we need is some hype. Blog about that secret app of yours that’s coming out soon. Make a heavily hyped private beta (What I mean by that is making a private beta, but advertise it a lot so that people will be contesting for the few private beta-tester places. Ahem, do I need to point the finger? Disco and Flow, for instance, did this.) Set up a pre-ordering system. Another good idea is to get yourself interviewed by the Mac press.

If you succeed, you’ll have a lot of buzz and excitement around your app. And then… release your app! Add your app to MacUpdate, VersionTracker and so on. Send your press release to all major mac sites (find an already-made mail list for mac sharewares). Get your app reviewed by the press as soon as possible.
If you’re lucky, you’ll make up for the past months’ investments in the first few days.

After the first huge wave of noise and sales has calmed down, after a few weeks / months, get your app into promos such as MacZOT! or MacHeist. This will create continued interest in your app. Release updates from time to time, and post ‘em to MU / VT, they’re a big traffic income.

A big tool in helping you get traffic and attention is digg, use it.

From now on, everything will work out from itself, while you can enjoy your brand-new Lamborghini.

 —  — 

Conclusion

The key to becoming a rich mac-dev is to have good marketing for your good app. Simple, ay