Fiddler installs a virtual machine on Mac to run. There is no http proxy like Fiddler running natively on Mac. 

Objective C tutorial

It's a combination of object oriented programming, managed runtime and C programming language.

Methods are invoked like this
output = [object method];
output = [object methodWithInput:input];
Methods can return a value

id myObject = [NSString string];
id means anyType not known at compile time
All objective C object variables are pointer types so instead of id above we could have written NSString*

Nested messages are those where the output of one method or message call is the input to the other. It is written as
[NSString stringWithFormat:[prefs format]];

Method names can be split:
-(BOOL) writeToFile:(NSString*)path atomically:(BOOL)useAuxilaryFile;
and invoked as
BOOL result = [myData writeToFile:@"/tmp/log.txt" atomically:NO];
writeToFile:atomically is the method name

Code inside square brackets means you are sending a message to an object or a class.

property accessors are camel-cased for set as in setCaption and no mention of get as in caption

Instead of object and method notation in the square brackets, you can use object.method;

 Objects are created by assignment and allocation
NSNumber* value = [[NSNumber alloc] initWithFloat: 1.0];
NSString* string2 = [[NSString alloc] init];
[string2 release]

Interfaces are defined as :
@interface Photo:NSObject {
            NSString* caption;
            NSString* photographer;
}

@end symbols ends the class declaration.

Dealloc method is called to free up memory

Reference counting is done on objects. You manage local references. If you create an object with alloc or copy, send it to autorelease the old object and retain the new one. You can use keywords such as autorelease, release,  retain and super dealloc.

You only need to release that which you alloc.

Logging is done with syntax like this:
NSLog( @"The current date and time is: %@", [NSDate date] );

The nil object is the functional equivalent of NULL.

Categories are one of the most useful features of Objective-C. It lets you add methods to an existing class just like C# extensions.
For eg: to add a method to NSString to determine if the contents are URL, you could specify:
@interface NSString (Utilities)
- (BOOL) isURL;
@end;
Utilities is the name of the Categories.

In this post, I will be talking about web requests and responses in Objective C for an IPhone app. The framework provides NS APIs to make URL Requests such as NSMutableURLRequest and NSURLConnection. Both GET and POST methods can be made with these. However, CFNetwork library is even more easier  to use for this. The caveat with most helper methods is that their quirks have to be understood The approach to use NSURLConnection is quite straightforward. However, setting and detecting proxies with this framework isn't as convenient as say in the ASI framework. In fact, ASI framework can not only detect the proxy settings and configurations, it can also specify another or with a .pac script file.  ASI wraps the CFProxySupportTool. Unlike the WinInet in Windows, the way to retrieve the proxy settings from iOS is via the high level wrapper APIs.

Here's an example:

   NSMutableURLRequest *request =

    [[NSMutableURLRequest alloc] initWithURL:

     [NSURL URLWithString:@"https://test.openapi.starbucks.com/v1/oauth/token"]];

    

    [request setHTTPMethod:@"POST"];

    

    NSString *postString = @"grant_type=client_credentials&client_id=your_client_id&client_secret=your_client_secret&scope=test_scope&api_key=your_api_key";

    

    [request setValue:[NSString

                       stringWithFormat:@"%d", [postString length]]

   forHTTPHeaderField:@"Content-length"];

    

    [request setHTTPBody:[postString

                          dataUsingEncoding:NSUTF8StringEncoding]];

    

    [[NSURLConnection alloc]

     initWithRequest:request delegate:self];

    

    

}

THe Xcode framework has MVC patterns similar to anywhere else so that different views can be navigated through controller actions. The actions can be invoked from the controls on the UI so this follows a well known pattern. Additionally the model can keep track of all object states. It can be persisted locally on the device if SQLLite provider is used. Otherwise, model can also be persisted as files. Cloud based storage for model could be possible via iCloud Service.
The controls can be dragged and dropped from the toolbox to the emulator. This is a very visual designer way of describing the page. And we can set various properties on the page as well. In addition, the same controls can be dragged to the controller to show what is associated with the actions. The Objective C framework let us use the objects directly. For example, a button can be dragged to the controller to describe what action is associated with it. The simulator to code connection is tracked with a line so it's easy to follow and to drag and drop.
In our case where we want to design a user interface to make web requests and responses, we could rely on the ASIHttpRequest library. That code can directly be included in your application and it makes GET and POST request easier than the native support. The form on our user interface can help with making the request while the response will simply be echoed out to the screen. This single page interface is sufficient for this kind of a request response view.  This doesn't mean we can't add more pages. Different pages can be added via different views and workflows to navigate between the views can be specified through the controller. The framework allows you to run the app in universal mode so that it can be used directly with both iPhone and iPad without customizing for any one. In addition, there are ways to sign and package your application so that it can be published to the app store.
As a way to test the application with full web request and response, there is a test project created with the source. This can be used to incrementally add features via test driven development. It is nevertheless important to have tests run on the code prior to publish even if this is strictly not followed. At the time of publish, while the code may not change, there may be additional changes coming in via picking out images and themes for the application. Hence, trying out the app from the app store will surely be recommended.

IPhone applications are written with XCode and IOS SDK. The apps are written with the building blocks provided by the framework. The language is Objective C. Creating a hello world application with a one page is easy because you choose the templates, pick the controls and write the associated controller logic. You can test the app in the simulator that comes with XCode.
Publishing an app is also easy using the following steps. Apps are published through the App store. You provide the app and the digital certificates. The App is then compiled and submitted to the App Store. You need the following : identity which is a unique id for an app, a distribution certificate and a private key  that is generated in the app store, a distribution provisioning profile, icons and loading screens. 

In the previous post, we talked about a browser plugin or a provider specific dedicated app for trying out REST APIs. However, they are either browser tied or API service provider tied. In

this post we talk about the system requirements for a Fiddler mobile app. We specifically target the IOS SDK as an example.

When I develop the application for a Fiddler UI on iPhone, the following are the requirements from IOS SDK:

1) single user for single device - This means that only the current user has the ability to capture traffic. The features are tied to the device and not the user. There is no login for the

application. Moreover, the application is a different instance on each device for the same user
2) ability to change proxy - This means that the application works with only the proxy for the local device. Ability to change proxy for the duration of the application is critical to the  traffic capture. By replacing the proxy with our own, we will be able to listen in on the traffic.

3) The notifications corresponding to switching in and out of applications by the user, so we can resume where we left off or operate in the background.

4) The ability to persist captures to disk so we can load them again. In the case of mobile device, we may not want to let the user save and reload captures since such action can take a lot of space. However, the ability to save captures for the current session internally is important.

5) The ability to persist cookies for the user so that his or her settings may be remembered.

6) The ability to cleanup persisted files and settings so that the application can start as if from a clean state. This also means install and uninstall should work correctly.

Developing Fiddler on the mobile application requires writing an http proxy that sits between the http server and http client and listens on the http traffic. An API explorer on the other hand can be a browser plugin that only works for the session that the user is on. Here we don't need to change the proxy on the client for the duration of the application but just the requests and responses.
Applications can be written native to the mobile device or available via the browser from mobile supported sites. The mobile supported sites shouldn't have client side scripting solutions as this may leak the client id and secret required for authentication.  The application makes webrequests and receives webresponses so it only keeps track of this.
Also, the web application regardless of the mobile device can have four components on the landing page. These are API browser, composer, history and response viewer.
Optionally, the application could sign in the user to the API providers site so that the user's profile and applications information could be retrieved. This is useful for pure client side scripting since we now rely on the username password credentials to access the APIs.
Signing in the user not only lets us use the clients credentials for authorization such that we don't have to use our own client id and client secret for the app but also limits access to the APIs to registered users.
Lastly, the application will require permissions to make web requests and receive web responses. This can be granted explicitly or implicitly by way of installing the application.
The applications on Mobile platforms such as Android, IPhone and Windows Phone could differ from each other only in the look and feel but the functionalities could remain the same across the devices.