Suppressing Xcode Warnings On A Per File Basis

I’m a fanatic about fixing warnings and errors in my code. Whenever I see one I tend to fix it right away which helps make it easy to see new ones when they pop up. However, there are occasions when you just can’t fix them. For instance, you might be using an open source bit of code without the time, knowledge, or commit access to fix a warning. In such cases a lot of warnings in a foreign piece of code can make your own hard to find due to the deluge of yellow icons all over the place. Well, fear not. There is a way to turn off warnings on a per file basis in Xcode.



Turning off warnings on a per file basis is super simple. All that is required is a compiler flag. Here’s the step by step process.

      1. Open the Project Navigator in Xcode
      2. Click on the Project icon at the very top of the navigator
      3. In the resulting detail pane select the target that you are working with
      4. Select “Build Phases”
      5. Expand “Compile Sources”
      6. In the list locate the file that you’re interested in
      7. Double click the column under the “Compiler Flags” column next to your file
      8. Add a -w to the resulting dialog
      9. Click “Done”
      10. Build your now warnings free project

Compiler Flags are extremely useful in certain situations. Not least among these is turning off ARC on a per file basis. To do so for a file simply add the -fno-objc-arc compiler flag.

Do note that suppressing warnings in your code base should be used judiciously. Be sure that you have a very good reason for doing so. With great power comes great responsibility.



Peer Reviews for the Solo Coder

Developing software in a solo environment has its pros and cons. On the upside you have complete reign over the code base (no problems with ownership here), freedom to follow specific designs and an ability to express your creativity. On the other hand, the very nature of the activity can be your down fall; tunnel vision and shortsightedness can eclipse all of your efforts.

There is a way out of this quandary and its called peer review. The mere mention of “peer review” can strike fear and foreboding into the hearts of developers. But, like it or not, this egoless programming practice has the power to deliver.

Outside input can lead to an increase in production quality and ultimately product appeal. Here’s a few ways to get outside input and ideas if you’re flying solo:

  • Direct communication with friends. Friends that you’ve made through previous jobs, ventures, or virtual contacts made real are great sources of input. When in the same industry they can provide a unique perspective. If it has been a longtime since you’ve touched base then invite them out for lunch, or better yet a beer, in order to reconnect.
  • End Users. The end users of your product are an extremely valuable source of feedback. While a user may not be privy to the nitty gritty code details they will have an opinion about what is good or bad about your interface. Running a public or private beta will give you the chance to gather valuable feedback and roll it into a product before going live with it. For iPhone development take a look at TestFlight which is an awesome service for distributing beta builds and getting feedback from your test team.
  • User groups. There is a good chance that there is a Cocoa developer group that meets regularly in your area. A few places to start would be CocoaHeads, NSCoder Night, and if you’re in Austin CocoaCoder. Getting out and mingling with other developers is a great way to cultivate ideas, get feedback and make a few friends. Try giving a short presentation to the group on some code or a technique that you’ve been working on. Not only will this give the group a chance to discuss a topic but it can help you validate ideas or to open up new avenues of thought.
  • Virtual community. Participation in online forums, email lists, IRC channels, and of course blogs can be another source of outside input. While readily available the quality of this sort of feedback can tend towards the inflammatory. Be sure to research your questions and always interact per the guidelines of your chosen group. Oh, and be sure to don your flame retardant suit before dipping your toes in.

Whatever avenue you pursue to gain outside input it has the ability to not only improve on your own designs but to also increase your creativity. New ideas yield more new ideas and so on. So, if you’re feeling like you’ve hit a brick wall or that you need a second opinion try getting some outside input.


Developing From Multiple Machines

There has been some discussion recently on Twitter regarding developing from multiple machines. I work this way and it can be liberating. While in the office I typically work from a Mac Pro with a 27″ display. Ah, screen real-estate. But, I like to be mobile so I also work from a 15″ Mac Book Pro. When I’m ready to head out of the office for a while the last thing that I want is to worry about setting up my dev environment. I just want to grab the laptop and sprint out the door. Likewise when I return I want everything ready to go on the desktop. Keeping development environments synced between the two can be a real pain. That is unless you make use of “the cloud”.


My office setup.



I can hear you asking, “Isn’t this what version control systems are for?”. Yes. I am a big fan of version control and have used numerous systems over the years. Currently I use Git. I love the fact that I don’t need to be connected in order to work against the repo like I do with Subversion or Perforce. In addition, I think that the self contained nature of Git lends itself to this type of setup. I’m not so sure that a system like Perforce would fair so well. In a team environment version control is a no questions asked must have. In fact you should always use version control, even if you work solo like I do.

However, in order to keep everything in sync between machines I use Dropbox. Everything goes into the Dropbox folder. Source code, assets, Git repos, project files. The whole enchilada. Everything except for build directories which are regenerated with a simple build. The size of your project, especially assets, can be an issue when syncing over a slow network so keep that in mind. Fortunately, if both machines are on the same network then Dropbox will detect it and use the LAN Sync feature which will sync files over your local network vs the cloud. Unless you don’t have much code or you have managed to max out your referrals with Dropbox you’ll probably need to spring for one of the paid plans. Typically I like to keep all of my projects under a single top level directory. But, I like to keep that directory in my user space. As such I had a major aversion to moving everything over to the Dropbox folder. A simple symlink from the Dropbox folder to my preferred space solved that issue.

I’ve run into two caveats with this rather simplistic setup. First is not to have the same project open under Xcode at the same time on different machines. Otherwise strange and potentially harmful behaviors can and do occur. This means that when I leave the house I need to be sure that Xcode on the desktop is shutdown and vice versa. A small but important point. Second, remember that everything is synced immediately all of the time. So, if I’m working on a large Photoshop file, for example, from a coffee shop with a slow connection this could be an issue (especially with a severe -S habit). In such a case I might temporarily turn off Dropbox syncing until I can get to a faster network or back to HQ. Not ideal but I’m usually working on source files which sync quickly. If you desire more control over what is synced and when then this Stackoverflow post outlines a way to use Dropbox as a Git bare repo rather than just going all in on the syncing fire hose. Additionally, you may want to disable Growl notifications for Dropbox since they can get annoying after a while. There have also been some recent security concerns with Dropbox. I suppose that your level of trust in them and your comfort level with others potentially seeing your code will dictate whether or not you use a setup like this. For me the benefits outweigh the downside.

Even with a great automatic code syncing environment in the cloud you shouldn’t rely on it as your sole source of backup. Keep using your version control systems hopefully hosting offsite somewhere. I also use the great online backup utility Arq to regularly backup my important files including my development environment. In addition, I periodically create a sparse image of my entire hard drive using SuperDuper. That’s at least four copies of my code three of which are offsite. There is also a copy on my alternate machine ready to go. I sleep pretty well at night.

Xcode 4 has brought major changes but one of my favorites are the built in code snippets (maybe I’ll share mine sometime). However, there is no built in way to sync them between machines which can be frustrating and a major hassle when using a setup like this one. If you run into this then xcodesnippets is for you. It’s a simple ruby gem which packages up and organizes your snippets for easy transport to other machines. Unfortunately, there is no online syncing built in so you need to copy the snippet bundles over manually but otherwise it works great. It does seem however that using the magic of symlinks and Dropbox you might be able to setup some auto syncing of snippets even without such a tool. If you try this then please let us know how it works out.

I love the ability to run out the door with my laptop in hand without having to worry about having everything ready to go. It is. Likewise when I’m in the office I love being able to fire up Xcode on the Mac Pro and get to work immediately. As developers we spend all day in our environment and as such it is a very personal thing. So, this type of a setup may or may not work for you. Whichever the case please share your experiences and what works in your world.

Happy coding.




Command Line Fu (Part 2)

This, part deux, continues part 1 of Command Line Fu.

Do This Over There

Spinning up and running a server somewhere on the internet is extremely easy these days. From Amazon EC2 to Slicehost having a remote machine running 24/7 is well within the reach of most devs. It also makes system administrators out of us. The powerful ssh command can help tame your network of servers so that you can spend a little extra time with friends and family. Most people think of ssh as a secure telnet (remember telnet?) but it’s oh so much more than that.

One of my favorite uses of ssh is in remotely executing commands. Here’s what one looks like:

$>ssh username@myserver.com 'apachectl -k restart'

That’s it. Simply put your command in quotes at the end of the ssh command line. The command is executed from your local machine but runs on the destination server. String 10 of those together in a script and you can restart your entire web server farm from your local machine by executing a single script. The ease and automatic nature of this hinges on setting up ssh for auto login.

You can take it to the next level by combining scp with ssh remote command execution. Consider having a stable of scripts that help you manage your servers all kept centrally on your local machine. When the need arises scp one of them over to the target machine and then use ssh to remotely execute it. Keeping all of those scripts locally reduces admin headaches by having copies distributed all over the place.

As an added bonus you can use ssh to securely tunnel out of wherever you happen to be. For example, you find yourself sitting in a strange coffee shop wanting to check your email without having to worry (note pop3 sends your email password in plaintext every single time it checks for new mail). You can easily divert your email over a secure connection so that anyone that happens to be monitoring network traffic doesn’t see your secrets.

$>ssh -f username@myserver.com -L 2000:mailhost.com:110 -N

The -f argument backgrounds ssh, username@myserver.com is your username at your servers hostname, -N tells ssh to not try executing this as a command on the remote machine. The -L argument is where the magic happens. In the args to -L 2000 is the port on your local machine, mailhost.com is your mail servers host name, and 110 is the port on the remote mail server machine. Now simply switch your email client to connect to localhost on port 2000 as your mail server. Now all of your email traffic for that account is secure from the point of your localhost to your server (your server forwards the request out to the real server from there). This technique works with just about any ports that you want to tunnel using your server as a middle man.

Interactive History

After working at the command line for any length of time you invariably need to re-execute some command again. You can either re-type it, often tedious, scroll through previous commands, takes forever, or you can search for it and just hit enter. Searching the command history is easy. Just hit CTRL-R at the prompt and start typing any part of the command. Search results will pop up:

(reverse-i-search)`sq': sqlite3 db/data.sqlite3

From this point you can hit Enter to execute the command or Right Arrow to put the command at the prompt so that you can edit it. If you have many similar results then you can continue hitting CTRL-R once you have a result to cycle through all matches.

Bashing History

Searching with interactive command history is handy. But, we can take it to a whole other level. Bash allows you to refer to previous commands and arguments withing those commands via a simple shorthand. Once you grok the shorthand you’ll be zipping through previous commands.

$>apt-get install git
Permission denied
$> sudo !!
sudo apt-get install git
Reading package lists... Done

The “!!” refers to the previous command in the history. So, executing “sudo !!” puts sudo in front that previous command. How many times have you executed a command only to re-execute it as sudo? Now it’s easy to do, eh? Here are some more variations to refer to previous commands:

!-2            # Refer to the command 2 back in the history (!-3, !-4, etc)
!find          # Previous command that starts with 'find'
!?find?       # Previous command that contains 'find'
!! -la         # Previous command adding -la as an argument
!!:1           # Refers to the first argument of the last command
!!:3-5        # Refers to arguments 3, 4, and 5 of the previous command
!!:0           # Refers to the command (no arguments)
!!:-2         # Refers to the command and the first two arguments

As you can see there is a lot of power there in referring to the previous command and arguments. Say, for example, you’re creating a tar file and realize that you have added an unwanted file (file2).

$> tar -xvf backup.tar file1 file2 file3 file4 file5
-- Ooops. Didn't want 'file2' in the list --
$>!!:-3 !!:5-7
tar -cvf backup.tar file1 file3 file4 file5
a file1
a file3
a file4
a file5

By using a simple shorthand the previous command was quickly executed sans the undesired argument. With a little practice this speedy but somewhat cryptic command structure becomes second nature.

So there you have it. My list of Master Command Line Fu tricks. Study them. Practice them. Before you know it you’ll pick that rabbit out of the hat while everybody sits out there wondering how the hell you did it.1

1. Gordon Gekko: “The richest one percent of this country owns half our country’s wealth, five trillion dollars. One third of that comes from hard work, two thirds comes from inheritance, interest on interest accumulating to widows and idiot sons and what I do, stock and real estate speculation. It’s bullshit. You got ninety percent of the American public out there with little or no net worth. I create nothing. I own. We make the rules, pal. The news, war, peace, famine, upheaval, the price per paper clip. We pick that rabbit out of the hat while everybody sits out there wondering how the hell we did it. Now you’re not naive enough to think we’re living in a democracy, are you buddy? It’s the free market. And you’re a part of it. You’ve got that killer instinct. Stick around pal, I’ve still got a lot to teach you. ”

This post is a part of the iDevBlogADay group of Indie development blogs. Thanks to @mysterycoconut for managing such a great site.


Command Line Fu (Part 1)

Almost every developer needs to get out to the command line once in a while. Some of us almost live there. So, here are a few tips and tricks that I’ve picked up over the years. May they help speed you along to your final command line destination.

Find Exec

Have you ever wanted to execute a command against every file in a directory? Or every file that matched a search? Well then, find with exec is your friend. For example, say we wanted to change the permissions on every file within a directory.

$>find . -type f -exec chmod 744 {} \;

The first argument, the ‘.’, tells find to start the search from the current directory. The ‘-type f’ says to look for only files. The -exec option tells find to execute the following command against every search result. Each result is substituted in the place specified by the {}. The ‘\;’ terminates the command. So, basically this command quickly executes a ‘chmod 744’ against every file found in the current directory. You could also add a ‘-name *.sh’ in order to further limit the search to all files ending in a ‘.sh’.

$>find . -type f -ls

This version of the command (the one with the -ls) simply shows you what files will be operated on as a result of the find. It is good practice to run this command first using all the same options except replacing the -exec with the -ls. The -exec option can be particularly destructive so know what what files you are operating on. Performing a ‘rm -rf’ as a result of a find against the root filesystem will send your day in the wrong direction. So, use the -ls version of the command first to see what files will be used.

Right Sed Fred

“Who’s sed? Sed’s dead baby. Sed’s dead.”1 Forgotten maybe but not dead. Sed stands for “stream editor” and it’s one of those old school neckbeard command line utilities that should be in your arsenal. Sed is prefect for picking through large amounts of text and twisting it to your will. Take this over simplified csv file as an example:

$>cat numbers.csv

With sed you can do crazy cool stuff like the following:
# Delete lines
$>cat numbers.csv | sed -e '2d'

# Print or add lines (prints current line)
$>cat numbers.csv | sed -e '1,2p'

# Substitute text
$>cat numbers.csv | sed -e 's/one/zero/g' | sed -e 's/,/:/g'

The -e on the sed command line tells it to accept what follows as the command. You can also write entire files of sed commands but I never do this. Instead I tend to chain successive commands together using the unix pipe in order to get what I’m after (see the Substitute text example).

The sed command takes the following structure: [address[,address]]function[arguments]. Where [address] can be a line number or a regex style pattern. Here’s a few more examples that use variations of addresses:
# Add the following text after lines where the pattern is found
$>cat numbers.csv | sed -e '/one/a\

# Insert the following text before lines where the pattern is found
$>cat numbers.csv | sed -e '/four/i\

# Read in the file abc.csv and add it after lines where the pattern is found
$>cat numbers.csv | sed -e '/four/r abc.csv'

# Delete lines 2 through 4
$>cat numbers.csv | sed -e '/four/r abc.csv' | sed -e '2,4d'

# Delete the lines found between the two patterns
$>cat numbers.csv | sed -e '/four/r abc.csv' | sed -e '/four/,/e.f/d'

And that’s just the beginning of the power of sed. Getting comfortable with the basic commands and structure of sed can allow you to whip out some minor change or pick through some complicated text in a flash. It’s a quick and powerful tool sitting there on your command line just waiting to be utilized. Man up the man pages (man sed) and check out some of the other cool stuff sed can do.

Before we leave sed here are some powerful sed one liners:

sed -e '$='                              # Count lines (similar to wc -l)
sed -e 'G'                               # Double space a file
sed -e 'n;d'                             # undo double spacing
sed 's/^M$//'                            # convert DOS newlines to Unix format.
                                         # (Press CTRL-V then CTRL-M to get ^M)
sed = numbers.csv | sed 'N;s/\n/     /'  # Number the lines in the specified file
sed -e 's/^[ \t]*//'                     # delete leading whitespace from each line
sed -e 's/[ \t]*$//'                     # delete trailing whitespace from each line
sed -e '/^$/d'                           # delete blank lines


Awk is the pretty cousin to sed. When you have any semi-well formatted data with a known separator awk is your man (or gal). Awk’s power lies in printing various portions of columns of data. Strictly speaking they don’t need to be real columns of data but rather just have a known separating character. For example:

$>echo "one two three" | awk '{print $2}'

Awk’s default separator is conveniently the space. The ‘{print $2}’ is the awk command and tells it, in this case, to print the 2nd column of data as separated by a space. You can also change the separating character with the -F option:

$>echo "one,two,three" | awk -F, '{print $2}'

In this case the comma was specified as the separator. Whatever character immediately follows the -F will be used as the separator. Like sed, awk can make use of addresses to select which rows of text it operates on.

$>cat numbers.csv | awk -F, '/four/ {print $2}'

$>cat numbers.csv | awk -F, '/four/,/seven/ {print $2}'

In the first example, the line with the word ‘four’ in it is selected and the second column is printed (‘five’). In the second example, the lines between the one that contains word ‘four’ and the line that contains the word ‘seven’ are selected and their respective second columns are printed (‘five’ and ‘eight’). You can also have awk read a file directly rather than using cat.

$>awk -F, '/four/ {print $2}' numbers.csv

However, I almost never do this since it limits my ability to chain commands together which is where the real power in sed and awk lie.

To round out awk here are some powerful awk one liners:

awk '{print $NF}'             # Print the last field of each line
awk 'NF > 3'                  # Print each line with more than 3 fields
awk '{print $2, $1}'          # Print the first two fields in opposite order
awk '!/regex/'                # Print only the lines which do not match the regex
awk '/regex/{getline;print}'  # Print the line immediately following the regex

Knock Out Blow

Sed and awk work together to land a powerful one, two knock out blow. Together they can chew through even the most thorny text munging problems. For example, I recently needed a script to determine the process id (pid) of a running process so that I could kill it. Easy with sed and awk at your side.

PID=`ps -aef | grep "unicorn master" | sed -e '/grep/d' | awk '{print $2}'`

What’s going on here? The ps command is listing all processes. This is piped into the grep command which picks out the one that I am looking for (the awesome unicorn ruby http server). The ps and grep together print out something like this:

root 19092 1 0 Feb10 ? 00:00:03 unicorn master -c /etc/unicorn/sites/test/unicorn.rb -E production -D
ubuntu 22562 7121 0 15:42 pts/0 00:00:00 grep --color=auto unicorn master

The pid I want is right there, 19092, but how do I get at it? Easy. Pipe the output into sed to delete the line picking up our running grep command (sed -e ‘/grep/d’) and then pipe that into awk to print out the second column of text, our process id.

$>ps -aef | grep "unicorn master" | sed -e '/grep/d' | awk '{print $2}'

As you can see with sed and awk at your side crunching through nearly any text is possible. And it’s all done right there on the command line.

In the next installment I will move away from sed and awk to explore remote command execution, command looping, and some powerful kung fu master techniques to utilize your command history.

1. Zed is dead.

This post is a part of the iDevBlogADay group of Indie development blogs. Thanks to @mysterycoconut for managing such a great site.


Asking for App Reviews

For quite some time I’ve had a dialog in Mathemagics to prompt the user to rate and review the app on the AppStore. In the fast paced world of the AppStore a user may come across your app in the store, download it, use it and never have a need to return to its page on the AppStore. Consequently a potentially happy user of your app never lets you or anyone outside of their close friends know how much they like it. Politely asking the user for a review has been a great success for Mathemagics garnering it 262 written reviews and 1568 ratings thus far. The vast majority of the reviews are quite positive and generally come with a 4 or 5 star rating.

I believe one key to this success is that the dialog asking for a review is non-invasive to the users current actions. It pops up at the end of a successful game, congratulates them, and politely asks for a review on the AppStore. If the user chooses to review the app they are taken immediately to the apps page on the AppStore. If they choose not to rate the app the dialog goes away never to be seen again. Polite and non-invasive.

When the Mac AppStore first launched many apps had a difficult time getting user reviews. In fact, still today many apps don’t have any ratings or reviews. In the trial-less vacuum of the AppStore reviews and ratings give potential customers something to anchor their buying decision on. After Mathemagics for Mac gained enough ratings to start showing an average rating the apps ranking increased by an average of about 10 spots and has stayed there. I attribute this partially to the apps positive AppStore reviews and its star rating.

Considering the success of asking for a review in the iOS version of the app it was a natural for me to add a request for a review in Mathemagics for Mac. However, I took it one step further. Not only does the app ask for a review at a certain point but it will also ask a user who has previously reviewed the app to update their review if they have not done so for the current version of the app. Tracking this is done quite easily by saving off in NSUserDefaults the current version of the app that a review was requested for and whether or not the user clicked through to the AppStore or if they declined. Using this info you can popup a dialog requesting either a new or an updated review (be extra careful to only do this once per app version). At the same time I also added a preference which allows the user to turn off all review requests if they so choose. Remember, polite and non-invasive.

The code to launch the Mac AppStore from a Mac app is quite simple. Here is my version of it:

[gist id=”775603″]

You will notice that the AppStore is opened twice. The first attempt opens the Mac AppStore application if it is not already open. After a short delay the apps Mac AppStore URL is opened a second time which finally opens the apps page. You may need to play with the delay in order to find something suitable for you and yes, be sure to use the URL for your app. That is unless you want to open up the page for my app then that’s just fine be me 🙂

This post is a part of the iDevBlogADay group of Indie development blogs. Thanks to @mysterycoconut for managing such a great site.


How to Find an iPhone Developer

Several times a month, and sometimes per week, I seem to get approached from out of the blue by someone looking for an iPhone developer to work on their project. It may be an individual with an idea, a business, or some other organization. Often these are referrals from friends or acquaintances that I know or have worked with in the past. I’m always honored and humbled to be asked to work on a project but invariably I have to turn them down.

The primary focus of Blue Lightning Labs is the development of our own products. Currently we are in the enviable position of not needing to seek outside work in order to keep the doors open. Now, this is not to say that if the right opportunity came along it wouldn’t be considered. It would. But, primarily the focus is inward on developing products in-house. Contracting out to work on a project for someone else is a tough and noble cause. Many developers prefer it to the all-in highly risky make-or-break business of developing your own products. So, my intent here is to provide ideas and resources for those folks looking for the very best iPhone developers to work on their projects.

  • Start Early

After college I worked for a few years as a Physics Engineer at a large corporation. One of the managing engineers had a great sign on his desk. It read, “A lack of preparation on your part does not constitute an emergency on mine”. Don’t wait until the last minute to find a developer. Start early and take your time to find the right person or firm. Otherwise it will cost you. Figuratively and literally.

  • Get Involved

The iPhone developer community is great and it is flourishing. Many devs get together locally once a month as part of a Meetup group or other local development group. Seek out those groups. Attend meetings, ask questions, learn something about product development. Get to know people one-on-one. This can lead you down the path of finding the right guy or gal to work on a project with you.

  • Don’t be a Douche

Nothing turns off developers quicker than some new media social networking ninja guru trying to get you excited about the next great trend in fart apps. The stereotype of an anti-social developer may be true in some instances but let me tell you, we can all smell social media ninja’s a mile off and instinctively avoid them. Be genuine.

  • Attend Conferences

There are some great iPhone and Mac related conferences out there these days. Some of them are 360iDev, Voices That Matter, NSConference, and of course WWDC. New and experienced developers alike attend en masse. Just remember that devs attending these conferences are there to learn and have a good time. You’ll get a lot further approaching a developer after hours by buying them a beer than you will giving the hard sell in-between conference sessions.

  • Be open

We’ve all signed NDA’s. They have their place and I think most developers respect that. But, don’t expect to get very far with a good developer without letting loose a few details to give them an idea of project scope. When you’re talking about your project most developers will be mentally tallying it’s feasibility, pain points, cool technical aspects and the like. And don’t worry so much about someone stealing your idea. It’s the execution of the idea that as value. An honest developer will respect your idea not to mention the fact that most developers have a stack of their own ideas that they already don’t have time to implement.

  • Development is hard work

A good and experienced developer is going to command a premium. If you find someone willing to work for the same wages as a fast food employee then you might as well donate the funds to a worthy cause. Software development requires an odd mix of attention to detail, creativity and tenacity. It is mentally challenging and an experienced developer is worth paying an honest rate. You might be able to negotiate a reduction in rate in exchange for a percentage of all proceeds from an app. But, these days most devs know that only the lucky hit the AppStore lottery. So don’t expect someone to work for free in exchange for a piece of the pie unless you have a one in a million idea and even then I wouldn’t count on it.

  • Referrals

I started this post mentioning all of the inquiries I get for development work. This is, in fact, still one of the best ways to find a developer. If you have absolutely no contacts in the iPhone space then start developing some by trying some of the approaches mentioned above. The first, second or even tenth dev you approach may not be interested or have time. But, they may have a friend who is. Keep trying.

  • Hired Guns

All of this work and massaging in order to cultivate a relationship with an individual may not be to your liking. If that’s the case then check out the site They Make Apps. There you’ll find a lot of developer with different skills and experiences.

So, there you have it. A few tips on how to approach and find an iPhone developer for your project. In short, be genuine, be persistent, and get involved.

This post is a part of the iDevBlogADay group of Indie development blogs. Thanks to @mysterycoconut for managing such a great site.