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