Category Archives: Developer

FastTasks version 1.18 released! 💥

FastTasks v.118

I’ve just posted an incremental update to my free system utility, FastTasks. The update fixes a bottleneck in the launch code that caused FastTasks to take excessively long to load. I’ve also added the System Uptime, which you can also refresh with the new keyboard shortcut, ‘command-U’.

FastTasks saves you having to role up your sleeves and get mired in the exotic world of Terminal’s command line for a number of common tasks. FastTasks v1.18 offers you system info down the left side of the panel, all of which can be updated by the shortcuts displayed on the panel, and access to some common Terminal commands on the right.

If you haven’t tried FastTasks yet (or got tired of the slow launch times with the old version), this is a great time to grab a free copy of v1.18 as I’ll soon be replacing the app by FastTasks 2.0, a paid-for app with a whole new interface and extra functions. Nevertheless, support for FastTasks 1 will continue and bug fixes will still be forthcoming as necessary. Grab it while you can, folks! 🙂

Download FastTasks v1.18 from here…

Note: FastTasks requires OS X 10.6.8 or higher


Advertisements

run Terminal commands from any app

In this post I’m going to show you how you can select a piece of text in any app and have it run in Terminal simply by hitting a hotkey. The trick is especially useful for running commands you find on websites (like this one!) in a browser like Safari or Firefox.

This 20-second clip demonstrates running a command from a Firefox browser and another one from TextEdit, but you can also do it from an AppleScript editor window (and indeed any app that has selectable text), which can be useful for testing the formatting of your ‘do shell script’ commands and the like:






The first thing you’re going to need is to create an Automator workflow, add an AppleScript action and insert some code. Really? Nah, just kidding. I did it for you. 🙂 Just download, unzip and double-click the .workflow file to install the completed Service:

Download Run in Terminal.workflow.zip

Click through the various dialog boxes and choose ‘Install’ on the last one* (note for Snow Leopard users: the service will open directly in Automator; just do ‘command-shift-S’ to name it and save it).

Screen Shot 2014-05-09 at 12.10.58

All you need to do now is set the hotkey. Open  > System Preferences.. > Keyboard | Shortcuts and click ‘Services’ in the sidebar. Scroll down the window till you see the ‘Run in Terminal’ command. Click on the far right to add a shortcut of your choice. The one I used in the video is ‘command-option-control-T’ (‘T’ for ‘Terminal’ helps me remember the shortcut).

To use the Service, just highlight any Terminal command by triple clicking it and pressing your hotkey. Try this one,

cd ~/Desktop; ls -alF

which lists all the visible and invisible files on your Desktop, as a test.

You can also get to the Service from both the contextual menu (right-click > Services) and the application menu bar at the top (e.g., Safari > Services).

As a bonus, try out your new Service on the Terminal command in this post, and now you’ll be able to run Terminal commands even from Quick Look previews in Finder!

Enjoy! 🙂


how to correct the external monitor resolution

apple_display
A problem that’s been bugging me since at least Mountain Lion is that sometimes when I connect my external monitor to my Macbook Pro, the display resolution is incorrect. The problem is pretty annoying as it often occurs on wake if the MBP goes to sleep even when the external monitor hasn’t been disconnected.

There are a number of solutions to this problem, and I’ve used them all. Some are less irritating than others, but in this post I’ll give you a run down of the options.

1. The old fridge magnet trick
As I often use a tiny magnet to put my MBP display to sleep while keeping the lid open, normally putting the magnet on and then taking it off again will cause the displays to reset. But this method is annoying both because I’m often connecting to external monitors away from home and because I often misplace that tiny magnet! The other problem with this method is it doesn’t always work… 😦

2. Put the external monitor to sleep with a Hot Corner
Go into System Preferences > Mission Control, and set one of the Hot Corners to ‘Put Display to Sleep’ (not ‘Start Screen Saver’). When your mac wakes up and the monitor is in the wrong resolution, move the cursor to the Hot Corner, wait a couple of seconds, and move the cursor back to the centre of the screen.

3. Activate ‘Detect Displays’
Ok, two ways to do this. The manual way is that you open System Preferences, hold down the ‘option’ key and hit the ‘Detect Displays’ button at the bottom of the window. Note that you won’t see this button unless you’re holding down the ‘option’ key. After the display resets properly, quit System Preferences. My main beef with this method is it’s totally disruptive to my workflow, so much in fact that it makes me angry every time I use it!

Fortunately, you can lower the inconvenience with the second way, which is an AppleScript that does the same thing automagically.

Update Jan 2015:
Partly in response to this problem, I’ve written an app called DisplayDroid which detects when a monitor is connected or disconnected and automatically runs a script in response. The script below is built into DisplayDroid as one of the presets that you can choose!
Find out more about DisplayDroid…

try
tell application "System Preferences" to quit
end try

delay 1
tell application "System Preferences"
activate
reveal pane "com.apple.preference.displays"
end tell


tell application "System Events"
tell process "System Preferences"
set frontmost to true
try
key down option
delay 0.2
click button "Detect Displays" of window 1
delay 0.2
key up option
on error
key up option
end try
end tell
end tell


tell application "System Preferences" to quit

You might want to save this in your scripts menu or make it into a Dock-able app for convenience. Don’t forget you’ll need to allow the AppleScript editor permission to use Assistive Devices.

4. A free screen utility
Unhappy with a GUI scripting solution, I started researching how to change the displays in Cocoa or from the BASH command line so that I could avoid the overhead of System Preferences popping open and closed, which is an ugly solution at best. I didn’t get far in my research before I found that someone else had already beaten me to the punch, and had even offered the code up for free. Y’gotta love the heroes of the programming community! Download the free RDM.app, which lets you change the screen resolution on any of your monitors from the status bar on your desktop. Move it from your Downloads folder into your /Applications folder. I’ve even got it in my login items for maximum convenience!

RDM

Although the app is probably slightly slower than the Hot Corner solution when I’m at home, I like it because I regularly connect my mac to all sorts of other monitors and projectors and the mac doesn’t always choose the best display. The RDM.app lets you slide through the available options much more efficiently than the System Preferences panel, too. Big respect to Paul Griffin at http://www.phoenix-dev.com for this!

5. Trash old prefs
No matter how well or otherwise any of these techniques work, the question remains: why is the resolution setting being forgotten in the first place? I haven’t nailed this down as a cert yet, but ever since I did this to solve a different problem, my monitor’s been behaving itself, too.

1. Go to

Hard Disk/Library/Preferences/System Configuration

Now make sure you’re at the right place because there’s another ‘System Configuration’ folder at /Library/System Configuration, and you definitely don’t want to be messing with that one. Also, this is the Library folder at the root of your hard disk and NOT your user account library (i.e, the path is /Library, not ~/Library). Check that path. Here it is again

Hard Disk/Library/Preferences/System Configuration

2. OK, click on that folder, and copy it over to your Desktop. Now go back and delete it from /Library/Preferences (or hold down ‘option’ while you drag to do a ‘move’. I prefer the first way; it’s safer, if slower).

3. Restart and test.

Hopefully, if you’ve been venting at the ears like me over the external display problem, one or more of these options will help lower the frustration!

🙂

Related Posts:
DisplayDroid from Applehelpwriter



Featured Picture: apple_display by 3DEricDesign

how to master Cocoa & Objective-C

master cocoa & objective-c

It’s been quiet on Applehelpwriter this month, largely because we’re all waiting for OS X Mavericks to come out, and I’ve been rather busy helping out with the beta testing. I’ll have plenty to tell you when the public release finally comes around, but for now I’m under strict orders from Apple’s NDA (Non-Disclosure Agreement) to keep schtumm.

Xcode 5 was released for Mountain Lion last week, and that brought up a couple of questions about how to develop competency in creating apps for Mac OS X. I wrote something about this sometime ago, but the truth is I’ve been through a bit of a learning curve myself since then. So, while we wait for Mavs (10.9) and explore the new features of Xcode 5, this seems like the perfect time to share some of my coding experience. Although this might seem a little diaristic, the aim of this post – like pretty much all others on APH – is purely tutorial. 🙂

So, let me go back about a year or so. I’d been working my way through the 4th edition of Aaron Hillegass and Adam Preeble’s widely-acclaimed ‘Cocoa Programming for Mac OS X‘ quite nicely till I hit the ‘challenge’ at the end of Chapter 5. Although I’d followed all the previous chapters quite carefully and with little trouble, the challenge seemed totally beyond me. Indeed, as I read and re-read the earlier material, I couldn’t see anything in the book that would help me solve the core problem of the challenge.

The challenge said: “when the user types in a string and clicks the button, change the message text to display the input string and the number of characters“.

the challenge

Building the interface was easy, but at that time I had no idea how to go about measuring the string length (despite the mention offered on the next page about the -(NSUInteger) length method.)

After struggling with the problem for some while and not being able to resolve it, I came to an impasse: either I moved on to the next chapter, hoping that I’d learn more and be able to solve this challenge at a later date, or I gave up on the book completely. I wrestled with this for a while, until eventually deciding that I needed to postpone going any further into the book ( a different strategy from ‘giving up’!), and instead learn more about the underlying programming language behind Cocoa, namely Objective-C.

I should point out at this point that the authors are quite clear at the beginning that you really should know your way around Objective-C before tackling Cocoa, but since the early chapters – and even the chapter that reviews Objective-C itself – are fairly light, I fell into the mistake of thinking that I could get by with what they provided, a little background knowledge, and some judicious internet browsing to fill in the gaps.

Alas, that was far from the truth. I put aside the Hillegass book and turned instead to Stephen Kochan’s primer on Objective C, the excellent ‘Programming in Objective-C 2.0‘. In fact, I’d already read a couple of chapters of this in the past, (that’s the “little background knowledge” I mentioned in the last paragraph), but it was clear that I needed to work through it in far more detail if I hoped to master Cocoa.

Kochan begins his book by saying you don’t need to know C to read it, and indeed it’s true (in retrospect…) that he does a good job of surreptitiously teaching your the heart of the C programming language under the guise of teaching you Objective-C. When I say “surreptitious” that’s not a criticism: Objective-C is an extension of the C programming language, and in fact it isn’t really that much different from it once you re-orient your idea of what a program is and how it works. It’s kind of like those black and white gestalt pictures in psychology ( you know, “do you see a rabbit or an old lady”?). Once you switch your perspective, it becomes fairly clear, but until then though, the other point of view can seem as obscure as mud.

Well, I got through about six or seven chapters of Kochan and again got stumped. It occurred to me then that despite his claim that you didn’t need C to learn Objective-C, I…well…needed to learn C before I could learn Objective-C!

So I embarked on a mission to first learn C, which I did through a couple of excellent books: first, with Dave Mark’s ‘Learn C on the Mac‘ and then with the classic ‘The C Programming Language‘ by Kernighan and Ritchie (K&C). If you have trouble finding a reasonably priced version of this venerable book in hardcopy, do as I did and try your local public or university library, both of which are sure to have it. In my earlier post, I also suggested you look at ‘C for Dummies‘ (another book I was reading concurrently with my first attempt at Kochan back then), but in retrospect, that book doesn’t cover enough ground and takes too long to cover what it does deal with, so I think now I’d say give that one a miss.

In any case, six months after working my way through the Dave Mark and the K&C books, I approached Kochan again, and found myself working through it like a hot knife through butter. After that, I finally went back to Hillegaas. And guess what? Not only did that challenge at the end of Chapter 5 seem trivial in Objective-C, I actually knew how to solve it even more efficiently in C without even using Objective-C at all!

(Even more efficiently? Well, only to computer programmers, who count spaces as ‘characters’, does the string “This is only a test” have 19 characters. To normal people, it’s only got 15. An early lesson in K&C will teach you how to count the characters without including any white space. 😉 ).

Now I said this would be a tutorial, and indeed it is, for the moral of the story is an old one: learn to walk before you run. Do not believe the many claims that are often touted that you can learn how to create great apps for Mac OS X (or iOS) just by reading a book or two on Xcode or Cocoa (or anything else). Instead, get your foundations sorted out before you start trying to tackle Cocoa or even Objective-C.

And that means: learn C, the ‘grandfather’ of all modern OOP languages, which will not only make the rest of the learning curve a relatively easy glide, but will equip you with a far deeper understanding of what you’re doing and a far greater ability to tackle harder problems. You’ll learn how to create more complex apps than you ever could have with just a superficial knowledge of the ‘higher-level’ languages. Like the tortoise and the hare, it might seem like you’re the slow coach at first, but before you get to the end of the track, you’ll find you’re leagues ahead of the competition. 🙂



Related Posts:
Get the free utility app from Applehelpwriter

FastTasks – free download

FastTasks dog opened


I’ve been planning this ever since I first wrote a shell script along the same lines. All it needed was a nice interface, and that’d be something I could use almost everyday. Well, it only took me 8 months to get round to it, but here it is. 😉

FastTasks main window

Download FastTasks»

FastTasks allows you to achieve a number of things that you would normally have to roll up your sleeves and do in Terminal or AppleScript.

The window consists of two columns: left-side for info, right-side for actions. Here’s a detailed breakdown of functions with possible uses.

–Left-side (Info):
OS X Version:
Displays your current OS Version and build number

Startup Disk:
Displays your boot volume
I sometimes forget which particular volume I’m booted into, so this is vital info for me and anyone who’s regularly booting in and out of different installations.

Router IP:
The IP address of your network router
This can be useful for troubleshooting or if you need to access your router’s Admin page.
Just select the address and paste it into Safari’s search bar.

Local IP:
Your node on the local network
Useful to copy and paste if you need your local IP/ network node.

External IP:
How the rest of the world sees you
Very useful if you’re using proxies and want to check whether they’re working.

Installed Ram:
Just a courtesy reminder, but the real value here is the summary of usage stats underneath. These are pretty good approximations to what AM shows on my 10.8, but there are discrepencies on some versions of OS X between what ‘top’ shows and what Activity Monitor shows. FastTasks uses the same information that you’d get if you used the ‘top’ command in Terminal.

By the way, there’s a refresh button (keyboard shortcuts shown) for both the memory usage and network addresses, as the displays do NOT update continuously. Using the refresh buttons does not CHANGE anything on your system: They just update the display to reflect the current state of the system.

–Right-side (Actions):
Show hidden files:
Reveal or hide the hidden files and folders in the Finder whose names begin with a period
This is probably the most useful function of the app as it provides a dead easy way to hide and unhide system files without messing around in Terminal.

Show User Library:
Reveal or hide the User Library in the Finder
Likewise, this hides or unhides the ~/Library folder in Finder. This is ‘hidden’ in a different way from files that begin with a period, and its setting can be manipulated independently of that setting, so you can have the User Library showing, but ‘hidden’ files still hidden.

Flush DNS Cache:
Flush the cache that resolves internet domain names into IP addresses
Flushing the DNS cache can sometimes help resolve problems when you can’t access certain websites. Depending on what system you’re running, you may or may not see a ‘Requires Admin password’ warning next to this button. If you see the warning, then when you press the button the system will ask you for your password. The password request is from OS X and it goes to OS X: It’s not called, seen or stored by the app itself.

Free Memory:
Purge the RAM of inactive memory
Again, depending on what system you’re running, you may or may not see a ‘Requires Admin password’ message. On Snow Leopard, this requires the Command Line Tools supplied with Xcode, so if you see a message telling you to install Xcode, you may have to live without it (availability of Xcode for Snow Leopard these days is a bit hit and miss). You’ll also see the information on the left-side refreshed under ‘Usage’ when you use the free memory function and it successfully completes.

NOTE: on some systems where both Flush DNS Cache and Free Memory display ‘Requires Admin password’, note that after supplying the password for one of those actions, the user will be able to perform the other action without authenticating for a period of around 5 minutes (unless the sudo timeout setting has been altered by an Admin user).

Lastly, at the bottom of the window you’ll see a tiny plea to donate if you find the app useful ;). Note that the underlined text ‘Applehelpwriter’ and ‘Donate’ are hotlinks that if clicked will launch Safari and load a tab with this site and a Paypal donate page, respectively.

I hope you enjoy using FastTasks. Please read the provided Licence and User Guide that are in the download. Thanks! 🙂

Download FastTasks»

how to change all Desktop backgrounds



With Lion came the welcome ability to have individual background wallpapers for each Desktop. However, what Apple forgot to add was an option to easily make all the Desktops have the same background image when you want it that way.

There are a few workarounds, but probably the simplest – once it is setup – is to use this little script I wrote for some ASC members. It should take you about 5 to 10 minutes to set this up if you follow the procedure carefully.

1. Open TextEdit, and choose TextEdit > Preferences.
Change the settings from ‘Rich Text’ to ‘Plain text’ for New Documents. Close the Preference pane and chose File > New.

2. Copy everything in the box below and paste it into the TextEdit file you just opened:

#! /bin/bash
#script to change all desktop backgrounds

echo -n “Drag and drop an image file here then press ‘return’ or
press ‘control-c’ to cancel…”
read -e WLPR;

function change_wallpaper
{
defaults write com.apple.desktop Background “{default = {ImageFilePath=’$WLPR’; };}”; killall Dock
}
change_wallpaper

3. Save the file to

/Library/Desktop Pictures

with the name ‘ChangeAllDesktops’.

IMPORTANT: Make sure you remove the ‘.txt’ file extension in the name field AND uncheck the option at the bottom of the Save box that says ‘If no extension is provided, use .txt’.

Note that you will need to press the ‘authenticate’ button when prompted in order to save anything into the ‘Desktop Pictures’ folder. Type your password in the dialogue that pops up.

4. Open Terminal.app.
Make the ‘ChangesAllDesktops’ file executable by copy/pasting this into the Terminal window:

sudo chmod a+x /Library/Desktop\ Pictures/ChangeAllDesktops

Press ‘return’ and type in your password. The password won’t echo to the screen, so type carefully.

5. Make Terminal the default app for the file
Open a Finder window. Click on your hard disk icon in the sidebar (if you can’t see it, go to Finder > Preferences > Sidebar and check Hard disks under the ‘Devices’ section). Navigate to the Library/Desktop Pictures folder and right-click on the ‘ChangeAllDesktops’ file.

Select Open with and then Other…. In the window, navigate to Terminal.app in /Applications/Utilities. It will be greyed out, so change “Recommended Applications” to “All Applications” in the menu at the bottom of the window. Do not check “Always Open With”. Choose ‘Terminal.app’ and ‘OK’.

6. Make a shortcut for Desktop Pictures
Drag the folder ‘Desktop Pictures’ to the Finder sidebar to make a convenient shortcut. Now when you want to change all Desktop backgrounds at the same time, click in ‘Desktop Pictures’ in the Finder sidebar, run the ‘ChangeAllDesktops’ file, and drag an image from the (already) open Finder window into the Terminal window that appears.

Press ‘return’ and your desktops are all changed! 🙂



Related Posts
learning the Terminal — Part One
learning the Terminal — Part Two

learning the Terminal – Part Two



In the last post, we learned how to see all the contents of a folder – invisible and visible files – in the Terminal. However, most of us prefer working in the GUI, so this post is going to show you how to work a bit of Terminal magic to easily turn on and off your invisible files and folders in Finder and the desktop.

Open Terminal, and type or copy/paste the following to the command prompt:

defaults write com.apple.finder AppleShowAllFiles TRUE; killall Finder

(note that all commands in these posts should always be assumed to be case-sensitive).

Press Return.

Now switch out of Terminal and have a look at Finder or your desktop. You should see some ‘hidden’ files now in a sort of greyed-out 50% opacity (files like .DS_Store). If you can’t see such files, go back and check that you typed or copied the entire command correctly.

Assuming you can now see your invisible files in Finder, switch back to Terminal. Press the up arrow key on your keyboard. Notice that the last command you typed reappears.

That’s a handy trick to remember. You can move between your previous commands with the up arrow and down arrow keys to save time re-typing or modifying commands.

In this case, we want to use the last command again, but we also want to modify it. Use the left arrow key to move the cursor back to “True” and then use delete to remove “True”. Leave the cursor where the letter ‘T” was and type FALSE. Make sure the semi-colon ; is still there.

Press Return — you don’t need to move the cursor to the end of the line as you would with a word processor. You can hit Return no matter where the cursor is in the command line and it will execute (or try to) whatever is typed on the whole of the command line.

Now, if you switch back to Finder or the desktop, you should see that all your hidden files have disappeared again.

OK, now that we have tested these commands to check that they work, let’s do something a bit more useful with them.

Switch back to Terminal. Type

^FALSE^TRUE

and press Return.

Wow! Did you see what just happened? You substituted the word “FALSE” from the last command with the word “TRUE” and executed the entire command. In other words, you just made your hidden files visible again! Go and look at the desktop and you’ll see that your invisible files just returned. Try it again. Switch back to Finder and type

^TRUE^FALSE

to replace the word “TRUE” in the last command with the word “FALSE”. Hit Return to execute it.

Using the pattern ^error^correction is a great way to both correct commands you type incorrectly and to run two commands one after the other that have only one term or option different.

Back in Terminal, hit the up arrow to bring the last command back onto the command line. This time, I want you to hit control-A on your keyboard. Notice that this brings the cursor to the start of the command line, which is what we want as we’re going to type in a new command before the “defaults…” part.

With the cursor at the beginning of the line, type

echo

and a space. Then type a double quotation mark right next to the ‘d’ of ‘defaults, so the beginning part looks like this

echo “defaults…

(the ellipsis or ‘…’ is used here just to show that the command continues and should not be in your actual command line)

On the keyboard, press control-E.

This takes the cursor to the end of the command line (remember: control-A to go to the start, control-E to go to the end).

Type another double-quotation mark right after the word ‘Finder’ so the ending looks like this

… ; killall Finder”

Now hit the spacebar once, and type a double right angle-bracket

>>

Hit the spacebar again and type

.bash_profile

The entire command should look like this:

echo “defaults write com.apple.finder AppleShowAllFiles FALSE; killall Finder” >> .bash_profile

Now press Return. Type

^FALSE^TRUE

and press Return one more time.


What did we just do?
To see what you did, type

emacs .bash_profile

As you can see, after testing those two commands on the command line, we’ve now sent them to the .bash_profile file, saving us the job of typing them out again (and possibly making an error when we do so). However, we can’t leave the commands like that – if we do, then they will run every time we log into the Terminal. Rather, we want to use these commands to define functions, just like we did last time with ‘show’ and ‘up’.

To do that, press control-L on the keyboard, then use the down arrow key to bring the cursor to the beginning of the first line with a ‘defaults’ command on it.

Press Return. Press the up arrow once, then type

function hide_all

Press Return and in the new line created type

{

Use the down arrow key to move the cursor down to the line below the “Defaults…FALSE” line and press Return.

In the new line created type

}

Then press Return. Type

function show_all

Press Return and type

{

Use the down arrow key to move the cursor below the “Defaults…TRUE” command. (If you can’t go below the last typed line, then on the keyboard press control-E to move the cursor to the end of the line, the press Return).

Then type

}

Check that the whole thing looks like this:




Once you’re satisfied, hold down the control key while pressing first the x and then c keys. Press y when prompted to confirm the save. You should be returned to the command line. Type

exit

to logout. Then press command-W and command-N to close and reopen Terminal.


What did we do this time?
We just made some new, easy-to-remember commands to show and hide our hidden files in Finder and the desktop. On the way, we learned how to append commands to files using the >> function, as well as how to move the cursor to the beginning and end of a line using ‘control-A’ and ‘control-E’ respectively. We also learned how to recall previous commands on the command line using the arrow keys and how to correct or modify previous commands using the ^error^correction pattern.
Wow, you’ve come a long way in two short tutorials!

To test out what you just did, type

show_all

then press Return.

Switch to Finder and there’s all your hidden files! To make them invisible again, switch back to Terminal and type

hide_all

then Return.

From now on, whenever you want to see your hidden files, just use the show_all command in Terminal. Hide them again with hide_all. 😀



SUMMARY
control-A – places the cursor at the beginning of the command line (also works in emacs editor)
control-E – places the cursor at the end of the command line (also works in emacs editor)
control-L – on the command line, this clears the screen (equivalent to the ‘clear’ command); in emacs, this places the caret inside the editor allowing you to edit (=insert point)

up & down keyboard arrows – moves through history of commands

^error^correction – replaces the term after the first ^ with the term given after the second ^ in the previous command, then executes the entire command

echo – sends the following string or command to the specified file (if no file is specified, the string will output back to your terminal screen. In other words, if you type echo hello, the Terminal will print “Hello” on the next line; hence the term ‘echo’! )


Related Posts:

learning the Terminal – Part One
learning the Terminal – Part Three
learning the Terminal – Part Four
how to change all Desktop backgrounds
Fasttasks – a utility for ten common terminal tasks

how to become an Apple app developer

Developing apps for iPhone, iPod, iPad, and Mac OS seems like the California gold-rush of the 21st century — the press are full of reports of the riches to be had in this amazing land, stories of “little people” making “big bucks”. Anyone can be an app developer, they say, but what’s the truth behind the hype, and how do you actually learn how to do it?

Last I heard, there were currently something like 600,000 apps on the Apple App store (for iPhone/iPad) and some 100,000 or so on the App store for Mac OS. Apple have paid out (i.e., passed on customer payments after taking their 30% cut) literally billions of dollars to developers. That’s a lot of cash! The question is, can you get a slice of it too?

In theory, there’s no reason why not. As I’ll detail below, the route to becoming an app developer is not particularly hard, nor is it particularly costly. But that doesn’t guarantee success. Anyone can write a book, but writing a killer book that’ll sell like Harry Potter is not so easy, and writing a killer app that will sell like Angry Birds is every bit as difficult.

The analogy holds for success in both cases: you need a great idea, you need to execute it well, and you need to market it properly. Did I mention those 600,000 apps on the App store? How, exactly, are you going to make your fortune if your app is buried in a pile like that? Well, I’ll save ideas and marketing for a future post. In this one, I want to focus on the things that we know we can achieve and only have to depend on ourselves for: developing the skills needed to turn that great idea into an actual piece of software that will run on Apple machines.

Learn the language
If you want to write a killer novel, the first thing you have to do is learn the language that you want to write the novel in, be it French, Chinese, or English. If you want to write a killer app, the same goes. Visual Basic? Visual C++? Java? Yes, that kind of thing except…if you’re developing for iOS (the iPhone/iPad operating system) or Mac OS (Mac computer operating system) you have to learn the Apple language, not any of those common ones associated with lesser machines!

So what is the Apple language? It’s called ‘Objective-C’, and it runs in a programming environment called ‘Cocoa’. You’ll need to learn ‘Cocoa’, but in order to learn that you’ll need to learn ‘Objective-C’, and to learn that, you’ll need to learn the basics of the standard (Ansi) C programming language. Oh my!

And once you’ve got a hold on all that, you’ll then need to learn Xcode, which isn’t a language or a programming environment at all, but a very sophisticated development tool (in fact, Xcode is itself an app!), in which you do all your Apple programming. You’re probably now thinking that it’d be easier to write that next Harry Potter novel and are already hunting around for the back of an envelope to start scratching down your ideas, but wait…

I know it sounds disheartening, but there is some good news. After all, it can’t be that hard if so many other people are doing it, right? (Well, actually, yeah it can, there’s a lot of dedicated programming geeks out there!). But look, I’ve been down this road too, and while I haven’t produced any killer apps (still waiting for that great idea…), I have gone from knowing next to nothing about programming to being able to put together an application that does what I tell it to and doesn’t crash my system.

(OK, not entirely true that I didn’t know anything about programming: in the 1980s, I once learned how to get a monochrome computer screen to print “Hello World” in BBC BASIC, which basically involved nothing other than typing >Print “Hello World”; it seemed so ridiculously pointless in 1982 that it turned me off programming for the next thirty years! Other than that, I’m a newbie 🙂 ).

And the good news gets better: most all of the documentation you need to learn how to be an app developer is available free from Apple. Truly, and I mean this with no trace of irony, it is hugely generous of Apple to put the amount of free material they have online for anyone to use. Want to be a Windows developer? Find your local bookstore and start shelling out one heck of a lot of $$$!! The cynical, of course, will say that Apple only do the giveaway to benefit themselves; others might say that giving away free training justifies their 30% cut.

I think of it as a symbiotic relationship: would-be developers who aren’t in computer science departments or big companies could never afford to buy all the material. Likewise, Apple could never have built an App store with such a huge number and wide variety of programs to Wow! their users if they had only had universities and commercial software developers to rely on. This way, both the little people, that’s me (and — I’m assuming — you), and Apple get to win.

I’ll tell you how to get started in a minute, but before I do let me point out that the ride is not entirely free. There’s probably a point at the beginning and certainly one at the end where you will need to lay out some of your hard-earned. So let’s deal with that now.

What you need
Right off, you’re going to need a Mac computer. Sorry, if you don’t already have one, you’re going to have to buy one; a low-range Macbook Air or Mac Mini will do, anything that can run OS X Lion. You can’t develop Mac apps on your iPhone or iPad, I’m afraid (but it does work the other way too: you don’t need an iPad or iPhone to develop apps for these devices. More on this below).

And what about if you have a good-spec PC? Yes, you could get a Mac emulator (VMmare) or mess around with OSx86, but frankly, these options are likely to cause you more grief than they’re worth; you could end up with apps that don’t build properly, and/or which breach Apple’s licensing conditions.

I’m not saying don’t do it, that’s your choice; I am saying your chances of successfully building an app, making it stable, and getting it accepted into the App store by Apple are significantly reduced if you go that route. Given the price of a basic Mac Mini on Ebay, you could well end up spending more money (as well as time) trying to avoid buying a Mac than just buying a cheap one.

The other expense you might need to lay out for is a basic ‘Intro to C’ book. There’s plenty of web offerings, but really a good ‘idiots’ book like the Dummies or Absolute Beginners should be enough and has the benefit of being reasonably likely to get you to the level of proficiency you need in the shortest amount of time. After that, you learn the rest for free (Objective-C, Cocoa, Xcode) from Apple. At the end of the process, when your app is built and you want to submit your app to the App store, you’ll have to register with Apple for a licence as an app developer and vendor; current cost $99.

Take the first step
“Sign me up”, you say, “where do I start?” The first thing to do is to sign up to Apple’s developer community: this is free (don’t confuse it with the Developer Program or Licensing, which costs $99 and which you don’t need till you’ve built an app you want to upload to the App store).

Once you’re in the Developer Community, download Xcode 4, Apple’s development environment (a different thing from a programming environment, but don’t worry, you’ll get the hang of all this terminology easily enough once you start reading the docs). This is a 4GB monster of a program – bigger than your average operating system, so make sure you have the space – and it is also free. Xcode comes with free iPhone and iPad simulators and in itself, this is a piece of software that’s probably worth a couple of thousand dollars. So smile: you’re already making a profit even though you bought that Mac Mini! This is also the reason why you don’t need, and in fact can’t use, your own iPad or iPhone to test your apps: everything has to be done in Xcode, and this monster app only runs on Mac OS X.

Once you’ve downloaded Xcode, you can play around with it if you want, but unless you’ve worked with an IDE (integrated development environment) before, it’s pretty complicated, so it’s best to wait till you work through the tutorials. It’s not the kind of software you can learn through serendipitous exploration.

Instead, go to the documentation resources and start with the tutorial Your First Mac Application.

By the time you get through this, you’re going to realise why you need to learn Ansi C, Objective-C and Cocoa. So put Xcode away for now, and start on the path of learning to speak Apple’s language. When you get there, just add 1 great idea + 1 great marketing strategy, and you’re on your way to California!



The short guide:

1. Get a Mac
2. Learn C, learn Objective-C, learn Cocoa, learn Xcode
3. Come up with an idea for a great app and plan it out carefully
4. Build and test your app
5. Pay the licensing fee and submit your app to Apple
6. Once it’s been through the review process and accepted, implement your marketing strategy
7. Watch the millions role in and retire.
😀

%d bloggers like this: