Once you have implemented the ability to open a files in another app using the UIDocumentInteractionController (as described in the previous post), it doesn't take that much effort to enable printing. You essentially only need to implement two further methods in the UIDocumentInteractionController delegate protocol. (The following assume that you have already implemented UIDocumentInteractionController as described in the previous post.)
The additional codes are:
- (BOOL)documentInteractionController:(UIDocumentInteractionController *)controller canPerformAction:(SEL)action
{
    if (action == @selector (print:) &&
        [UIPrintInteractionController canPrintURL: controller.URL]) {
        return YES;
    } else {
        return NO;
    }
}

- (BOOL)documentInteractionController:(UIDocumentInteractionController *)controller performAction:(SEL)action
{
    bool __block success = NO;
    if (action == @selector(print:)) {
        UIPrintInteractionController *printController = [UIPrintInteractionController sharedPrintController];
        printController.printingItem = controller.URL;
        [printController presentAnimated:YES
                       completionHandler:^(UIPrintInteractionController *printInteractionController, BOOL completed, NSError *error){
                           if (completed) {
                               success = YES;
                           } else {
                            NSLog(@"The print job did not complete.");
                           }
                       }];
    }
    return success;
}

The first method tells the UIDocumentInteractionController whether certain actions can be performed in respect of the document. The default response is 'NO'. In this case, we are telling the controller that printing is supported.
The second method is called by the controller when it wants its delegate to perform a particular action, such as printing action here.
Both of these methods make use of a class called UIPrintInteractionController, which handles the printing for you. All you need to do (as done above) is to pass it the document's url.

It is relatively simple to get another app (a third party or one of Apple's apps) on the iPhone or iPad to open a file. The magic is mostly done by Apple in the UIDocumentInteractionController Class.
This class is part of the UIKit framework, which is included by the default xCode project setup so there is no need to link any additional framework.
This is what you need to do in terms of code:
1. Make your relevant class file conform to the UIDocumentInteractionControllerDelegate protocol and define a variable
Assuming your class is called ViewController, then in the ViewController.h file:
        @interface ViewController : UIViewController <UIDocumentInteractionControllerDelegate>
        {
            UIDocumentInteractionController *docController;
        }
2. Add the following methods in ViewController.m:
        //- set up the UIDocumentInteraction controller and set its delegate to self so we can handle the callback events
        - (UIDocumentInteractionController *) setupControllerWithURL:(NSURL *)fileURL
                                               usingDelegate:(id <UIDocumentInteractionControllerDelegate>)         interactionDelegate {
   
            UIDocumentInteractionController *interactionController =
            [UIDocumentInteractionController interactionControllerWithURL:fileURL];
            interactionController.delegate = interactionDelegate;
   
            return interactionController;
            }
       
        //- the key instance method here is the presentOptionsMenuFromBarBUttonItem
        //- it is assumed here that there is a BarButtonItem called _btnActions
        - (void)showOptionsMenu
        {
            NSURL *fileURL = [NSURL fileURLWithPath:@"THE_FILE_URL_PATH"];
            docController = [self setupControllerWithURL:fileURL
                                   usingDelegate:self];
            bool didShow = [docController presentOptionsMenuFromBarButtonItem:_btnActions
                                                             animated:YES];
            if (!didShow) {
                    UIAlertView *alert = [[UIAlertView alloc] initWithTitle:@""
                                                        message:@"Sorry. The appropriate apps are not found on this device."
                                                       delegate:nil
                                              cancelButtonTitle:@"OK"
                                              otherButtonTitles: nil];
                    [alert show];
            }
        }
3. Add a method to invoke the above when you want to show the apps that you could send the file to
In this example, a UIBarButton is wired up to the following IBActions:
    - (IBAction)ActionButtonClicked:(id)sender {
        [self showOptionsMenu];
    }
That is it. When the button is clicked an action sheet will appear (all powered by the Apple's UIDocumentInteractionController class) that shows the apps (if any) that you could send the file to.

You can optionally implement the following delegate methods:
- (void)documentInteractionController:(UIDocumentInteractionController *)controller willBeginSendingToApplication:(NSString *)application
- (void)documentInteractionController:(UIDocumentInteractionController *)controller didEndSendingToApplication:(NSString *)application
- (void)documentInteractionControllerDidDismissOpenInMenu:(UIDocumentInteractionController *)controller

The ability to export a PDF document, created using data generated through the app, can be a useful feature to have in an app.  There are a number of ways to create the PDF:
(i) External way - the PDF document can be created with the help of a server. In this case, the app simply send the data (suitably structured) to a server which generates the PDF file using some server side script. Once the file is generated, it can be sent back to the app for further actions, such as forwarding it via email to someone. Indeed, the server could send the file directly to whomever.
(ii) Internal way - the PDF document is generated within the app on the iPhone or iPad (without involving an external server).
Which way is better depends on your requirements. The involvement of a server is sometimes necessary if you need to combine external data to create the PDF document. An external server may be more efficient if the document is complex or large.
This note is about the internal way.
Generating PDF directly on the iPhone and iPad
PDF document can be created in iOS. The Quartz 2D drawing engine is developed with PDF document creation, display and parsing in mind. The process of creating a PDF document is perhaps not as obvious as other things in iOS, but it is certainly not difficult and you can create nice looking document just by knowing a few things.
There are two ways to generate a PDF document on iOS:
(i) Use Core Graphics functions; and
(ii) Use UIKit framework.
The UIKit framework is certainly much easier to use that calling Core Graphics functions, but the latter could be more flexible and powerful. Again, the better approach depends on your requirements and it can be matter of personal taste.
This is an excellent online tutorial: Generate PDF programmatically in iPhone/iPad SDK. It shows you how to draw lines, border, text and image.
For those who like to write even less code and leverage the graphical user interface of Interface Builder, you can use UILabel to display text on the PDF document. Here is how.
A Simple Example
This example creates a landscape page with an image on the left and some text on the right hand side.
1. Create a UILabel object in Interface Builder. i.e. simply drag a UILabel object onto the view controller in Interface Builder.
2. Create the setter and getter for this label in the class files of the view controller using the standard @property and @synthesize technique, i.e.
        @property (strong, nonatomic) IBOutlet UILabel *textLabel;
        @synthesize textLabel = _textLabel;
(Remember to connect this to the actual UILabel in Interface Builder. As an aside, it is quite easy to forget to do this, at least I often do. This is why I prefer to let xCode creates the @property and @syntheize code automatically by using the 'control click and point' technique. Another advantage of this approach is that xCode will add the relevant memory management code automatically too - one less thing to do).
3. Enter the following codes in viewDidLoad:
    // defines the path for the saved pdf file
    NSString *docDirectory =
        [NSSearchPathForDirectoriesInDomains(NSDocumentDirectory, NSUserDomainMask, YES) lastObject];
    NSString *pdfPath = [docDirectory stringByAppendingPathComponent:@"pdfFile.pdf"];

    // set the size of the page (the page is in landscape format)
    CGRect pageBounds = CGRectMake(0.0f, 0.0f, 792.0f, 612.0f);

    // sets the size and position of the image and text
    CGRect imageBounds = CGRectMake(30.0f, 50.0f, 500.0f, 375.0f);
    CGRect textBounds = CGRectMake(550.0f, 50.0f, 182.0f, 375.0f);

    // create an UIImage object using a photo named "sampleImage.jpg"
    UIImage *theImage = [UIImage imageNamed:@"sampleImage.jpg"];
    // set the text
    _textLabel.text = @"Lorem ipsum dolor sit er elit lamet, consectetaur cillium adipisicing pecu, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum. Nam liber te conscient to factor tum poen legum odioque civiuda.";
   
    // create and save the pdf file
    UIGraphicsBeginPDFContextToFile(pdfPath, pageBounds, nil);
    {
        UIGraphicsBeginPDFPage();
        [theImage drawInRect:imageBounds];
       
        [_textLabel drawTextInRect:textBounds];
       
    }
    UIGraphicsEndPDFContext();

4. One final step. Select the UILabel in Interface Builder, and in the Attribute Inspector, make sure that the attributes are set with the following values:
    Lines: 0   (setting to zero means that it is unbounded)
    Line Breaks: Character Wrap
    Font: System 14.0  (you can use other size or font)
    Text Color: (use default or pick a color)

Run the code in the Simulator and the PDF file will be saved inside the app's Documents folder. You can then add code to email or do whatever you want with the PDF file.

Drawing an NSString directly to the pdf context is more flexible, but an advantage of using UILabel as describe here is that it allows you to change the font, size, style, color, etc graphically in Interface Builder. This can be quite useful when you want to knock up something fast. Doing similar using NSString requires more coding and, as far as I know, you cannot simple things like 'bolding' the text without using Core Text and NSAttributedString (which is not that friendly to use). Again, the better approach to use depend on your requirement.

Scenario: You have created a popover view using iOS storyboard. The popover view is triggered by the clicking of a 'button' on the UINavigationBar or UIToolbar. Once the popover view appears, you can click outside of the popover view to dismiss it. But if you click the 'button' again, another popover view appear on top of the existing one. To dismiss the popover views, you need to click outside the popover view twice to dismiss it. (Indeed, more popover view will appear if you click the 'button' again.) Not a nice behavior to have.

Disable the 'button'.
You need to disable the 'button' when the segue is triggered and re-enable it when the user's click outside the popover view.

1. Create two accessors using the usual @property & @synthesize approach.
Under @interface,
    @property (strong, nonatomic) IBOutlet UIBarButtonItem *btnSettings;
    @property (strong, nonatomic) UIStoryboardPopoverSegue* popSegue;
Under @implementation,
    @synthesize btnSettings = _btnSettings;
    @synthesize popSegue = _popSegue;
(Remember to link up the actual button to the IBOutlet in Interface Builder.)

2. Make the viewcontroller confirms to the UIPopoverControllerDelegate protocol
    eg. @interface ViewController : UIViewController <UIPopoverControllerDelegate>

3. Inside the method (void)prepareForSegue:(UIStoryboardSegue *)segue sender:(id)sender
    if ([segue.identifier isEqualToString:@"NAME_OF_YOUR_SEGUE"]) {
        //- for this purpose alone, you don't really need a popSegue property, but having a reference
        //- to the popover segue is useful
        self.popSegue = (UIStoryboardPopoverSegue *)segue;
        //- this gets the reference to the actual UIPopoverController which you need to set the delegate
        UIPopoverController *pc = [_popSegue popoverController];
        //- setting the delegate to self
        //- this is important, otherwise the method under (4) won't be called and your button will remain disabled!
        pc.delegate = self;
        //- disable the button to prevent creating another popover
        [_btnSettings setEnabled:NO];
    }

4. Implement the following method in the UIPopoverControllerDelegate protocol,
    - (void)popoverControllerDidDismissPopover:(UIPopoverController *)popoverController
    {
        //- renable the setting button
        [_btnSettings setEnabled:YES];
    }
As the name suggests, this method gets call whenever the user click outsdie the popover view.

By default, popover view is dismissed when the user clicks anywhere outside of the view. Depending on your context, this may or may not be a desirable UI behavior.
You can make the popover view modal. Doing so prevents the user from clicking outside the popover view to dismiss the view. Of course, under this approach, you need to provide a mechanism to dismiss the popover.

The following assumes that we have a view (whose class is viewController) where a 'button' is located, and on clicking this button a popover view appears. This popoverview's class is popoverViewController.
1. Inside @implementation of the popover viewcontroller class file,
    - (void)viewDidAppear:(BOOL)animated
    {
        self.modalInPopover = YES;
    }
Note: self.modalInPopover must be in viewDidAppear. It won't work in viewDidLoad. Setting this property to 'YES' makes the view modal.

2. Create a protocol
Inside the popover view controller .h file, before @interface,
    @protocol PopoverViewControllerDelegate;
Under @interface, create a property,
    @property (nonatomic, weak) id<PopoverViewControllerDelegate>delegate;
After @end,
    @protocol PopoverViewControllerDelegate <NSObject>
    - (void)PopoverViewController:(PopoverViewController *)controller didClick:(BOOL)clicked;
    @end
Next, synthesize the delegate. Inside the controller .m file, after @implementation,
    @synthesize delegate;

3. You need to create a button that the user can click once they are finished doing whatever they need to do inside the popover view. This can be a button that triggers further actions such as saving some information that the user has entered or a 'cancel' button. But you need to provide a button as this allows you to link it to the mechanism that dismisses the popover.
Assuming that it is a 'Done' button, you could have a method like this in the popover view controller class file:
    - (IBAction)btnDone:(id)sender {
            [[self delegate] PopoverViewController:self
                                      didClick:YES];
    }

4. You need to obtain a reference to the popover segue so that you can dismiss the popover.
Under @interface of viewController.h,
    @property (strong, nonatomic) UIStoryboardPopoverSegue* popSegue;
Synthesize this property in viewController.m,
    @synthesize popSegue = _popSegue;
Inside (void)prepareForSegue:(UIStoryboardSegue *)segue sender:(id)sender,
    if ([segue.identifier isEqualToString:@NAME_OF_YOUR_SEGUE]) {
        self.popSegue = (UIStoryboardPopoverSegue *)segue;
    }

5. Finally, you need to implement the protocol inside the viewController class.
Import the header for PopoverViewController,
    #import "PopoverViewController.h"
Make this class confirms to the PopoverViewControllerDelegate protocol, by adding <PopoverViewControllerDelegate> after @interface, such that it looks something like:
    @interface ViewController: UIViewController <PopoverViewControllerDelegate>
Add the protocol method insider @implementation
    - (void)PopoverViewController:(PopoverViewController *)controller didClicked:(BOOL )clicked
    {
        if ([self.popSegue.popoverController isPopoverVisible])
        {
            [self.popSegue.popoverController dismissPopoverAnimated:YES];
        }
    }

Under Apple's App Store Review Guidelines, there is sometimes no choice but to use Apple's in-app purchase mechanism. Assuming you are dealing with a situation where there is a choice, what are the considerations you should think about. Here are a few you may like to consider.

• Price. You can only choose from the list of prices provided by iTunes. You cannot make up you own price. This tends not to be a serious issue as there are quite a few pricing 'tiers' you could choose from. However, this may mean that you need to align the pricing of your products with the pricing tiers offered by Apple - i.e. forcing you to set your pricing strategy to fit the Apple’s framework.
• Commission. A commission will need to be paid to Apple and currently is 30% of the price. This is not insignificant.
• Other transaction costs. One other costs that are not quite obvious (in the sense that it is difficult to quantify) is the potential effect of exchange rates if you sell the products outside your home country as most developers do. Admitted, I have not researched the detail mechanics adopted (if it is even published) but potentially there could be multiple exchange rates conversion by the time the money hit your bank account. It is quite likely that each of the conversion is performed with Apple’s best interest in mind; the corollary is that the conversion is not likely performed in your favors. This could all costs you money.
• When do you get your money. Under the present practice, Apple only forward payment to the developer once the amount has reached a certain threshold. At the moment, it is around $US150. And keep in mind that this is the amount payable to you so it is not the same as the total sale amount, i.e. this is net of Apple's commission. This may not be an issue if your sales volume is large, but it is something to keep in mind. In any event, the point to note is that there can be delay between the sale of your product inside the app and you seeing your money in your bank account. In operating a business, the timing of cash flow is an important issue.
• Customers' record. Apple's system will supposedly keep track of the items purchased by each users. However, it is unclear what happen in situation in which people changes phone or install the app on another device. Anyhow, we consider that it is best practice that the vendor also keep track of the items purchased by each person/device (of course, the extent of the tracking required would depend on the nature of the contents sold), meaning that you will need to implement your own database solution.

We were (and still are) struggling with this issue in an iOS app project. This project, which is still in its infancy, would eventually involve the sale of various music related contents including possibly sheet music (i.e. musical scores), music files and other related elements. What we are trying to work out is whether we can sell contents in the form of sheet music and music files in an iOS app without using Apple's in-app purchase mechanism (the Apple Mechanism)?

We have nothing against the Apple Mechanism, which definitely has its advantages. However, for reasons that will be become more apparent below, using the Apple Mechanism does not seem to be practical in respect of the present project.

Apple's App Store Review Guideline (the Guidelines) currently  contains the following relevant guidelines: (based on version accessed on 10th February 2012)
11.2 Apps utilizing a system other than the In App Purchase API (IAP) to purchase content, functionality, or services in an app will be rejected
11.3 Apps using IAP to purchase physical goods or goods and services used outside of the application will be rejected
11.13 Apps that link to external mechanisms for purchases or subscriptions to be used in the app, such as a “buy” button that goes to a web site to purchase a digital book, will be rejected
11.14 Apps can read or play approved content (specifically magazines, newspapers, books, audio, music, and video) that is subscribed to or purchased outside of the app, as long as there is no button or external link in the app to purchase the approved content. Apple will not receive any portion of the revenues for approved content that is subscribed to or purchased outside of the app.

The practical application of these guidelines are not entirely clear. The following practical explanation is found on stackoverflow.com:

• Digital goods, upgrades or subscription: Your only choice is Apple's In App Purchase.
• Charity donation: You must redirect the user to a website using Safari, you CAN'T use a UIWebView inside the app.
• Physical goods: you CAN'T user Apple's In App Purchase, you need to use a website or any other method, for example the new PayPal Library.
• Personal donations: (like the famous "express your gratitude and buy me a cup of coffee") you are again in item (1) and NOT on item (2).

This seems fairly accurate. This would suggest that the contents in question must be sold using Apple Mechanism. This consequently would mean we must use the Apple Mechanism in our project. However, after stumbling across an app by VirtualSheetMusic.com I am less sure. That app is quite similar to the features that we have in mind (although the type of the music is different). Importantly, they are are not using Apple Mechanism. If they could get their app approved without using Apple Mechanism, it gives us hope that we could too.

What I am trying to understand is why their app got approve? What distinguishes it from the guidelines noted above?

Admittedly, one possibility is that their app was approved before this current guideline. I have no idea as I don't know the history of the guidelines (but I am aware that it has changed and will change from time to time). Nor do I know the history of their app, but it seems that their app has been on the app store for awhile (inferred from the fact that it is currently version 2.7).

One possible distinguishing factor seems to be contents that could be used both within the app itself and also used outside the app.

These are the characteristics of the contents that we are considering in this project. The sheet music and music sound files in question can be consumed outside the app. More specifically, it is envisaged that the users could purchase these contents inside the app and outside the app (e.g. through a web site or by more traditional means like a physical shop or by fax, etc). Once they have purchased the contents, the users could access the sheet music and music sound files from within the iPhone/ iPad app, as well as from their computer, or possibly in the future even other devices. From an implementation perspective, it seems more efficient to adopt a purchase and payment mechanism that exists outside the app so that we can have a single mechanism rather than multiple mechanisms, which would raise technically complex issues of trying to synchronizing all the data.

That contents used both within the app itself and also used outside the app may be able to be purchased using a non-Apple Mechanism could well be consistent with the Guidelines. Guideline 11.2 says that we must use the Apple Mechanism to purchase content, functionality, or services in an app. Guideline 11.3 says that we cannot use Apple Mechanism to purchase physical goods or goods and services used outside of the application. But if the contents can be used both inside the app and also outside the app, what is Apple's position? This is unclear. Although, it seems that in this situation we may be able to use either Apple Mechanism or something else. This appear consistent with the VirtualSheetMusic.com example.

Further, this would seem consistent with the broad approach described in Guideline 11.13. Under Guideline 11.3, we are prohibited from linking "to external mechanisms for purchases or subscriptions to be used in the app" and we draw attention to the fact that this is talking about using the content inside the app here.

The overall impression seems to be that contents consumed within the app must be purchase using the Apple Mechanism. Whereas contents that have an external elements may be able to be purchase using a non-Apple Mechanism.

However, a concern is Guideline 11.4, which says that "[a]pps can read or play approved content (specifically magazines, newspapers, books, audio, music, and video) that is subscribed to or purchased outside of the app as long as there is no button or external link in the app to purchase the approved content." This clearly means that we could access the externally purchased sheet music and music files within the app, but does this means we cannot provide a means to purchase these items within the app? Does this only apply to magazines, newspapers, books, audio, music, and video? If so, may be sheet music can be purchased within the app?

I first came across this thing called Custom URL Scheme when I was going through the Facebook SDK, which uses it to reopen the app after the user has finished signing-in using mobile Safari during the Single-Sign-On (SSO) process. This is such a useful technique. To launch your app all you need to do is to define a Custom URL Scheme and use this scheme in the browser to trigger the launching of your app.

Defining the Custom URL Scheme (in xCode 4.2)
1. Go to you app info.plist. Add a new row and choose "URL types" as the key (if it doesn't already have this key - by default, it is not there unless you are editing someone else app which already have a URL Scheme defined).
2. Expand 'Item 0' and add in 'URL identifier' from the list.
3. Provide a value for this URL identifier. It can be anything. Although the convention is to use the reverse domain name style, e.g. com.absoluteripple.appname. (I am unclear as to the significance of this identifier as the URL scheme can be used to launch the app with or without this identifier as far as I can tell from my limited testing.)
4. Add another row, and choose 'URLSchemes' from the list. Now, the important bit. Provide the name that will become your custom URL scheme. If you put down 'myappname', then the url scheme will be 'myappname://'.
5. That is it.

Triggering the Launch of your App
Now that you have defined a custom URL scheme, you can use it to launch your app. This is just like any other url and you should (as far as I know) be able to use it like any other url. i.e. instead of 'http://', you use 'myappname://' (or whatever your scheme is). Whereas http:// opens a webpage, myappname:// opens your app. Try it out. e.g. if you type 'myappname://' in the mobile Safari it will open you app (after you have complied your app and put it on the iPhone/ iPad first of course).

Even More Useful:  It can be Used to Send Instructions to your App
Just launching the app is good but not that interesting. You can actually use it to pass variables to your app. How you use those variables is entirely up to you and your imagination. The point is that you can use this to get the app to do certain things. e.g. going to a specific location in your app and display certain information. And all this from an external url link.
The magic happens because of the following method (in the UIApplicationDelegate Protocol):
    - (BOOL)application:(UIApplication *)application openURL:(NSURL *)url
          sourceApplication:(NSString *)sourceApplication annotation:(id)annotation
This method gets called by iOS whenever the app is launched in response to your custom URL scheme.
A particular interesting variable is the 'url'. This is the url that you use to launch the app. As said above, this is just like any url, so it can have component paths. e.g. myappname://your/path/12345
So by structuring the component paths appropriate based on the needs of your app, you can send your app certain instructions and so get it to do things from an external url.
Notice also, you can tell which application is initiating the launch of your app with the values in 'sourceApplication' which is the bundle ID of the requesting app. You can also use the 'annotation' to to pass in information. This a property-list object. This opens the way for another app to communicate with your app.

Note: For iOS4.2 or before you need to use:
    - (BOOL)application:(UIApplication *)application handleOpenURL:(NSURL *)url
        (this is now depreciated)

Is the App you wish to launch installed?
From another app you can use [[UIApplication sharedApplication] canOpenURL: [NSURL URLWithString:@"YOUR_CUSTOM_URL_SCHEME"]] to determine whether the app you wish to launch is installed. This results a bool value.
So the code would look like:
    BOOL isAppInstalled = [[UIApplication sharedApplication]
                        canOpenURL: [NSURL URLWithString:@"YOUR_CUSTOM_URL_SCHEME"]];
    if(isAppInstalled) { // launch the app }
    else { // do nothing or send user to app store to download the app }

Is it possible to tell whether an app is installed from a browser? Don't know how or even if this is possible.

Useful Reference:

• code samples for common URL schemes

Recently, there are some noise in the media that iPhone and iPad apps are retransmitting user's address book information to external servers without the user's explicit permission.
We take user's data privacy very seriously. Any of our apps that access user's address book will only do so through the direct actions of the users. Address book information accessed by the app (such as in the Easy Party app), or personal information entered by the users in our apps, are only used within the app itself. Our apps have never and will never send the user's address book information to external sites or servers without seeking first clear and explicit permission from the users.