Terry Blanchard

As I write this, I’ve been working on an iPhone application that is very reliant on Internet connectivity. One of the challenges I encountered early in the development of this application was debugging the HTTP requests I was making and the responses I was getting back from the server. One of the requirements is that all communication was performed over HTTPS which clouded my debugging even further.

Meet Chuck, or Charles as the more formal and official name goes. Chuck is my new best friend. Yup, we’re so close that I can call him Chuck. We’re tight.

Charles is a web proxy, HTTP Proxy, and HTTP Monitor that runs on your Mac. Your web browser (or any other Internet application) is then configured to access the Internet through Charles, and Charles is then able to record and display all of the data that is sent and received.

In Web and Internet development you are unable to see what is being sent and received between your web browser / client and the server. Without this visibility it is difficult and time-consuming to determine exactly where the fault is. Charles makes it easy to see what is happening, so you can quickly diagnose and fix problems.

This is great for running your application on the iPhone simulator on your Mac. You can download a free-trial, but trust me on this, you’ll be buying the full version for $50 and thanking me later.

I was curious to know how some of the competing applications worked. While I can build and run my application in the iPhone simulator and use Charles to debug it, I couldn’t help but long for that same insight into other competing applications that I had on my actual iPhone.

Was there some way to have Charles work with my physical iPhone instead of the simulator so I could monitor it’s HTTP traffic?

Oh, hells yes!

It’s actually very easy to configure. Here’s all that you need to make this happen:

• Your Mac with Charles installed and running
• Your iPhone with the applications you’d like to monitor
• Both your iPhone and Mac with Charles must both be on the same WiFi network

That’s it! Got that? Good, let’s configure it. First, we’ll configure Charles:

1. From the Help menu, choose Install Charles CA SSL Certificate… This will allow you to debug and monitor HTTPS traffic.
2. If you are debugging or monitoring an SSL connection (or HTTPS request), you will need to configure this in Charles. From the Proxy menu, choose Client SSL Certificates…



3. Ensure that Enable SSL Proxying is selected. One of the great things about Charles is that you can use wildcards when choosing what SSL sites you would like to monitor. In the above screenshot, I am monitoring all HTTPS traffic on any .com domain.
4. Run the Network Utility application and make note of your AirPort wireless IP address:

Now that your Mac is setup with Charles and the HTTP proxy, we need to configure your iPhone to use that Mac as it’s Web Proxy. But first, we need to install the Charles CA certificate on your iPhone.

1. Open up Safari and navigate to (iOS 4) http://charlesproxy.com/charles.crt or (iOS 3) http://charlesproxy/iphoneconf. When you are prompted to install the Charles certificate, tap on the Install button.



2. Open up your iPhone Settings application and tap on Wi-Fi settings. Tap on the blue disclosure indicator of your local Wi-Fi network



3. Scroll down to the bottom of your Wi-Fi settings and tap on the Manual segment control in the HTTP Proxy settings.
4. Enter in the IP address you wrote down from your Mac running Charles. In my case, when I ran Network Utility I had the AirPort IP address of 10.0.1.33. I put that IP address in my proxy settings as well as the default port Charles runs on, 8888:



5. To verify your settings, open up Safari on your iPhone. As soon as you make an Internet request, Charles will prompt you on your Mac with a mesage box like the following. You want to click on the Allow button.

That’s it! Now fire up that application you’ve always wondered about.

Written by Terry Blanchard \\ tags: Charles, Debugging, HTTP, iOS, Proxy, SSL, Web, Xcode

“How can we automate our build number in this project? Perhaps a python or AppleScript?”

I get this question a lot. I contract out my development services to companies who need Mac, iPhone, or iPad software designed and developed. Many of these companies have lots of Windows developers on board full-time and contract out their Mac work so I understand that all-things Mac are new to them.

But this question always comes up. Always.

While they’re already thinking about some elaborate scripts to automate this process, I hold up my hands and say, “It’s already covered.”

I decided to blog about it because most people don’t know the name of the tool and can’t “Google” for it without stumbling across scripts to accomplish this task.

Apple includes a command-line tool called agvtool which handles my versioning needs. It’s not perfect, but it does what it needs to do and when used in a corporate environment with a build system, it’s fantastic.

What is it? In a nut shell, it’s a very focused “Find and Replace in Files” command-line tool. It searches through your program’s Info.plist file as well as the project .pbxproj file and updates them. You can even have it commit it’s changes with version control if you’re using Subversion or CVS.

The real number that needs to be constantly updated is the build number. Normally, the marketing version only changes at the beginning of a new branch or feature set. agvtool will help you out with both tasks. First, let’s tackle getting your project setup so you can display the following string in your iPhone About screen:

Version: 1.0 (Build 1)

The agvtool refers to the “1.0″ part as the “marketing version” and “1″ in the Build parenthesis as the project version. To update the build number we simply issue the following command from the project’s root directory which contains the .pbxproj and Info.plist files

agvtool bump -all

This command will change all of the build numbers, or project versions in agvtool speak, to:

Version: 1.0 (Build 2)

Want to change the marketing version to 1.1?

agvtool new-marketing-version "1.1"

Now our About box says:

Version: 1.1 (Build 2)

Cool, huh? Okay, so here’s how you setup your project to take advantage of this nifty little tool. First, we have to tell Xcode that we want to use agvtool for our versioning needs. From the Project menu, select Edit Project Settings. Ensure Configuration is set to All Configurations and Show is set to All Settings. Navigate down to the Versioning section and make the following changes:

Lastly, we need to update the Info.plist file. You need to set two values in, your Marketing Version is the Bundle versions string, short. If you don’t have this option in your plist file, select an item in the list and click on the + off to the far right. You can then select it from the list. The Bundle version is the build number. Set this value to match the one you placed in the Project Settings option for Current Project Version.

Now, whenever you’re ready to build an official release, just run:

agvtool -usesvn bump -all

The -usesvn parameter is optional. For an official build, you’ll want to commit the files that were changed by agvtool.

Then call xcodebuild.

Earlier in the article I mentioned that agvtool isn’t perfect. Here’s what I mean by that comment. For an automated build, having a command-line tool is fantastic. However, if you run agvtool while you have the project open in Xcode, you get this:

Since agvtool went and changed the .pbxproj file while you had it open in Xcode, you get this. Simply click on “Read From Disk” and you’re back in business. More of an annoyance than a show-stopper.

Written by Terry Blanchard \\ tags: iOS, Mac, Versioning, Xcode

You can’t just open up your editor of choice to modify the /etc/hosts file on your Mac. You can open the file without any problem, you just can’t save it.

To do this you must have super user privileges. Just being an Administrator isn’t enough. Fortunately, there’s a way to temporarily get super user privileges using the SUDO command. So I fired up Terminal and typed in:

Ruh-roh. It wouldn’t let me save the file. Crap. I’m not a Unix guy and VI makes my skin crawl and head hurt, but I was able to use sudo vi /etc/hosts and save the file.

So why couldn’t I get any of the GUI apps to save it?

Turns out, that you need to sudo the actual executable which is inside the TextEdit.app bundle. So the command I issued is this:

Voila!!

If you happen to own TextMate, then you can save yourself a lot of typing and heartache. TextMate installs a Terminal command called “mate” that allows you to perform the above sudo command. Just type:

BBEdit also has this capability:

TextWrangler as well:

Voila, again!! When you go to save your file, you will be prompted for your password.

Written by Terry Blanchard \\ tags: BBEdit, Development, Mac, SUDO, TextEdit, TextWrangler, VI

I hit a really odd bug last night. I mean, really, really odd. One of those bugs that keeps you up until 4am and you go to bed defeated. I came into the office today and had another engineer sit with me as I went through my code explaining what I was doing hoping that a second set eyes and another brain could bring some clarity.

No luck.

Everything looked good, but this very odd crash was still occurring. We were both scratching our heads. The weird part was that the program ran perfectly on the iPhone and in the simulator, as long as I didn’t have the debugger attached. The other engineer tried the build on his machine and everything worked as it should and he was able to run the Xcode debugger.

I decided to completely remove and reinstall Xcode and the iPhone SDK. Normally, you just drag a Mac application to the Trash Can and you’re good. Xcode is a little different. There’s a ton of different folders, tools, SDKs, simulators, etc scattered around the Hard Drive.

So how do you remove everything?

Fire up Terminal and type:

Type in your password and go grab a coffee. The Uninstall process takes quite a bit of time as it analyzes every package on your machine. However, it will find and remove all Xcode and iPhone SDK components. I highly recommend you to restart your Mac before re-installing Xcode.

Written by Terry Blanchard \\ tags: Development, iOS, Mac, SDK, Xcode

I use WordPress as my blogging platform and I absolutely love it. It’s so well done and makes blogging a joy. I’ve tried other platforms and spent more time fixing it, fretting over why the upgrade brought my site down, traversing database tables, and wishing it would do something that it doesn’t.

As most of you know, I’m also a Mac Boy. Me loves me the Apple products. WordPress has an iPhone application that allows me to write posts, upload photos, edit pages, and manage comments on my blog right from my iPhone. I use it for quick posts or to start a draft post with bullet points of high-level ideas so I can flush it out later. One of the coolest features I expected to use the iPhone application for was comments. What a perfect way to constantly monitor and reply to comments from my phone whenever I get a chance. I download the application and I like it. But it’s missing one major feature. Yup, the one I want the most. Replying to comments! I can delete comments, mark them as spam, but I can’t reply to them. Say, what!

I go to their website to request this feature and notice that this is an Open Source project with links to their development section. I’ve been developing software for close to 25 years and I have never participated in an Open Source project. As a professional software engineer, I’ve been very fortunate to work for some of the finest software companies around and their source code is fiercely guarded intellectual property kept under strict lock and key.

Open Source projects take a completely different approach. Instead of hiding the source code, they make it freely available. Anyone can download and build the source code. Anyone. The spirit behind this approach has a few key points. One in particular applied to me in this case. Opening up the source code and allowing anyone to work on it invites other with a desire to help and improve the product simply because you can, and you care. This described my situation to the letter and I decided to do something about it.

Why fill out a form asking the developers to add my reply to comments feature when I could contribute and make it happen myself? I’ve decided that I’m going to do exactly that. I’m not going to bitch and complain, I’m going to contribute.

I have lots of questions, lessons to learn, and I hope this turns out to be a great learning experience. I’m going to write about the contrast in experience as it happens. Things that immediately spring to mind:

• In a corporate environment you typically have technical leads or architects that are responsible for the structure of the code. They understand all aspects of the code at the lowest level and as well as why it was designed the way it was at a high level. They typically do the code reviews before an engineer checks in their code. Who does this in an Open Source project? Who owns it? Does it just evolve organically?
• How does the code/product get qualified or verified for integrity and quality? Who does this?
• I can understand how bugs or defects are handled. The product is suppose to do X and it doesn’t or it crashes. That’s pretty defined so I can understand how this can happen in a community environment. How are new features defined and implemented?

If you use the WordPress for iPhone application and you’ve got a hankerin’ for the Reply to Comment feature, post a comment. I’m working on it.

Written by Terry Blanchard \\ tags: Development, iOS, Open Source, WordPress