From al3x.net:

The thing that bothers me most about the iPad is this: if I had an iPad rather than a real computer as a kid, I’d never be a programmer today. I’d never have had the ability to run whatever stupid, potentially harmful, hugely educational programs I could download or write. I wouldn’t have been able to fire up ResEdit and edit out the Mac startup sound so I could tinker on the computer at all hours without waking my parents. The iPad may be a boon to traditional eduction, insofar as it allows for multimedia textbooks and such, but in its current form, it’s a detriment to the sort of hacker culture that has propelled the digital economy.

I’m a fairly young person, yet I realize these sentiments are shared in every generation. “My kids won’t have the same great experiences I had because of this new technology. They won’t know the joy of riding a horse on the open range because of this newfangled mechanical carriage!”

Your kids are going to have the wonderful experience of opening up an interactive textbook on their iPad and learning about how their cells work. Or tapping on a circuit design simulation application and dragging components into a circuit to create a ripple adder. Or posting to their virtual reality homebase that because of the new GenomeEditor 3000 (with presets!!), their kids aren’t going to have the fun of tinkering with their genome. So the “think of the children!” argument isn’t going to sway me. You can leave those up to Fox News.

The new paradigm of a simplified, consumer electronics computing experience isn’t going to catch on overnight. Look on the bright side though. By the time the only computers left are the ones abstracted away enough to where you can’t edit the startup sound, we’ll be retired or, fingers crossed, dead.

How can we fix this?

UIPasteboard of course!

Apple introduced an excellent and oft overlooked addition to the iPhone SDK when it gave developers the same power that they have on the desktop for sharing large chunks of data between applications. But Zac, you say, you of all people should know you can’t share data between apps…they’re sandboxed! Not true! Think of UIPasteboard as those little paper airplanes you used to send notes in back in school. No sandbox can hold UIPasteboard…

Method 1

This first method is fairly straightforward and easy for small data sets: Keep custom pasteboard filled with data you’d want users to import into your paid app.

UIPasteboard *sharedPasteboard = [UIPasteboard pasteboardWithName:@"com.mydomain.myapplite.sharedpasteboard" create:YES];
sharedPasteboard.persistent = YES;

By executing that on launch and keeping your sharedPasteboard up to date, you’ll always be able to request that from your paid app and auto-discover data from the lite version. The nicest thing about this method is most people won’t notice you did anything. Maybe you want users to notice your work…but sometimes the best features are the ones users don’t notice.

Method 2

This is for apps that have lots of content to put on the pasteboard and updating it all the time wouldn’t necessarily be so great. It’s a little weird but bear with me.

First, make sure you app can respond to the MyAppLite-export:// scheme. The parameters to this don’t really matter, but you could use them to specify some subset of data to export. You could also make this a little more generic and perhaps a little more secure by specifying a pasteboard name to the URL.

When MyAppLite is launched using this scheme, the users is presented with an “Exporting…” screen or something of the sort while MyAppLite puts everything requested on a special, one time use, pasteboard. After the pasteboard has been filled, MyAppLite opens MyApp-import://NAME_OF_PASTEBOARD. Now the paid app knows where to look to get all the necessary MyAppLite data off of the temporary pasteboard.

Security Concerns

Method 2 definitely has some security risks which possibly could be worked around. For one, if someone finds out your schemes they can read users data from a lite version and overwrite data in the paid version. With some obfuscated keys, this might not be much of an issue. Also, you wouldn’t want to send passwords or sensitive data using this method. That kind of data should be stored in the keychain anyway that is already available across your apps.

I hope this gives you some ideas on how to transfer data with UIPasteboard. I’ll try and post some sample code illustrating some of these concepts soon.