The C64 emulator that was pulled from the App Store by Apple for leaving a BASIC interpreter intact has now returned, though we presume it's minus the Apple-offending code. But while it will no longer run your own code, it will run some old-school C64 games, including eight for free with the app, and more coming with in-app purchases. It's got everything you'd expect from an emulator, including original sound and graphics, an auto-save, and the option to play in fullscreen portrait or landscape.

In fact, the only thing it doesn't have is an interpreter, but of course you know why that is by now: Apple doesn't want anyone running code on their devices that they haven't approved through the App Store. The app sells for $4.99 right now, and they expect to release the in-app purchases sometime this December, with no price announced yet.

Big news coming down the pike today for App Store developers. Apple has finally relented on a sticking point in the developer agreement, allowing in-app purchases for free applications. Finally, developers can distribute a free trial version of their applications, unlocking features from directly within the app as users request them (and pay for them). Until now, developers had to deliver two applications, with two unique identities, and no simple way to share data from the trial to the full version. (Yes, you could have used servers and shared keychains, but that's burdensome and kind of pointless.)

What this news means is that developers can unify into a single application. One project to maintain and support, one place to consolidate reviews, one application sandbox for a single set of application data. Earlier today, Mike S. mentioned Gas Cubby and Gas Cubby Lite -- now there could be only one version of the app, with an 'upsell' inside to go from the light to full feature set.

Expect to see these free-to-paid apps hit the store within the next few weeks. Apple will likely be deluged with new apps to review based on this news. Visit the App Store Resource Center for more details and check your e-mail account for the developer news that went out to all iPhone devs today.

Q&A: Readers ask: "How will this affect the no reviews situation for free apps." Good question. Apple is going to need to sort that out. Since in-app purchases are registered to an iTunes account and associated with an application, it shouldn't take much work to limit reviews to those who have purchased something in a free app. We'll have to watch for this to happen because as things stand now, if you download an app, you get to rate it and developers know that free apps are thoughtless review magnets.

"How will you deliver binaries?" All the functionality must already be built into the app. StoreKit allows you to unlock those features when users pay a fee. You can download data or extend a web based service but you can't download additional executable binary components.

"Will I have to buy this twice for myself and other members of my family?" No, not if you both sync to the same iTunes account. It works the same as with applications. One app that has bought an upgrade extends to all apps for that same account. Each time your app launches, developers will check with App Store and restore any purchases that have already been made. So if you buy your upgrade on an iPhone, that upgrade will propagate to your iPod touch when it checks in.

"Will this help in anti-piracy measures?" Definitely. StoreKit allows developers to validate receipts, ensuring that unlock codes are only sent to paying customers. Add a hash-check algorithm for the current device and developers have better control over who gets to use their applications.

"What about promo codes?" I think Apple has learned its lesson about free apps/promo codes. I'm betting that they've already thought about a way to distribute in-app purchases via promo codes.

"What about people who have already bought apps?" Admittedly, this news is currently best suited for new products than existing ones. Devs who have built in shared keychains already have a slight leg up but for the time being you'll likely want to at least consider a new product that leverages this ability rather than trying to retrofit.

As for people who have already bought a paid version whom you want to support while migrating to a free demo/in-app purchase model, you're likely going to encounter trouble until Apple irons out its policies and its solutions. Again, I expect Apple to provide some sort of solution shortly.

And why all this trust in Apple? Any move that benefits developers ends up benefiting Apple in the end. This was a smart move on Apple's part, it's a good move for users, and for developers too. And it still has a long way to play out so keep watching for Apple's next steps.

"Who are the biggest winners here?" It's the people who have been putting out free and ad-support apps. They now have a way to turn off those ads and to solicit donations. In-app purchase doesn't have to be about buying and unlocking features. It provides a real solution for free apps to monetize, and for Apple to transform a huge part of their store into a paying model.

"Can free app devs charge an in-app purchase for nothing (i.e. donation)? Can the user repeat purchases or pick the amount?" Apple provides several kinds of purchase types and those purchases can be applied in multiples. For example, you can buy 5 hit point boosters or make 5 donations of $1. So yes, that model does work for donations.

"Can devs now charge for updates?" Not unless those new features are added as unlockable items. Again, this is something that Apple will likely address given the great demand for exactly that. Expect to see new App Store terms of service should that happen because the current one uses a "buy once, use and upgrade forever" model.

"What kinds of limitations should I think about?" TUAW reader Scott Kveton suggest the following in the comments for this post. He writes, "The key is keeping the app under 10 MB so it can be downloaded without wi-fi. A lot of developers can just 'unlock' functionality but when you get into actually delivery potentially large(ish) content to the device that's not possible. It also opens up the possibility to make the apps that much smaller on initial 'purchase' and then download content on the fly."