Sorry, Jim, but this widely reported story is completely FUD from a competitor who makes their own iPod and ebook devices. There is nothing new here to see at all. This is the same exact policy that magazine publishers have pissy about and have been trying to end-run around since the iPad first came out and Apple first published the App Store guidelines.
If you support in-app purchases for additional content, you must have the option to buy them via the regular App Store mechanism (in other words, via the user's iTunes username/password). You are certainly free to also support purchases outside of the iTunes/App Store ecosystem by going out to a website, but you cannot do this from within the app itself. This has always been the case.
Amazon has, from day one, worked around this in their Kindle App for iOS. In the Kindle App, when you tap the Kindle Store button, the Kindle App itself closes and Mobile Safari opens and sends you to a (nice) mobile-formatted website where you can browse and make purchases. It looks and works basically like an app, but it is running inside Mobile Safari, and the user can tell (via the "app switching animation") that they were switched into their web browser. When you make these purchases, they automatically show up in your Kindle App once you go back into the App, so the user-experience is still quite seamless. This method has always been, and still is, just fine with Apple.
Sony was trying something similar, but different. In their app, when you hit the Sony Ebook Store link, it took you to their store within the application itself. This is different because then Sony can use the iOS SDK to make the store look and work like a native app, rather than a "mobile web page". Apple says, and has always said, this is a no-no, and they've already rejected tons of Apps from magazine and newspaper publishers for exactly the same thing. If you want to use the SDK to sell stuff right within your App, then the supported method is via the iTunes App Store. You can certainly do both. You are welcome to support in-app purchases via iTunes, and also allow the user can click a button which launches Mobile Safari and takes you to a web store. But you can't do it the way Sony wanted to do it. They knew this well in advance. This is a transparent PR shot at Apple from a competitor.
The reasons may seem simple enough... Apple wants a cut of those sales. And that is certainly true, and is probably a huge motivating factor for this policy. But it is certainly not the only reason for this policy. Apple sells the applications directly and they are expected, at least to some degree, to support them. Forcing all in-app purchases to go through the iTunes store gives Apple the power to control the user-experience over what the users buy. Just like Best Buy wouldn't allow a vendor to come into their stores and set up a kiosk where they sell goods that Best Buy couldn't control or even look at ahead of time, Apple won't allow anyone to sell things "in their store" without letting Apple have the power to pull it. Without this policy, since Apple would have no control over the add-ons, they would be unable to ensure that the user is actually getting what they're paying for. If you think that a huge proportion of Apple's millions of customers wouldn't call AppleCare to complain, rather than the app maker, when they have a problem, then you're living in a dream world. Just like J River often gets questions about supporting random open source filters and wacky DACs that no one has ever heard of before, if some App Developer was slinging porn, viruses, malware, or just plain junk via in-app purchases that Apple couldn't "pull", they would still get the support calls and the PR black eye. (I can see the headlines now, "Apple allows App Dev to sell Porn to Children!") Not only that, but you could write the code in a completely insecure way. Sending credit card numbers across the internet completely in the clear, using crappy and easy-to-break encryption, and all sorts of other bad behavior. Because it wouldn't be in a browser, where you (should) know how to look for the HTTPS and the other browser-based security features (which Apple controls because they make the only web browser engine for the device), the vendor can't trick you into entering your credit card info into an insecure form.
Secondly, without this policy, you could write an application that violates all the rules of the SDK and just have these features turned off until the user "buys" the add-on. It would be a way to end-run the "no emulation" rule of the SDK (because the add-ons could substantially change the "product" that Apple sold you in the store). Since Apple doesn't have control over the in-app purchases, they couldn't stop you from completely end-running the rules. Now, you may think the rules are junk and you want a completely free and clear "wild west" market. If so, fine. Jailbreak your phone or buy an Android phone. That isn't what Apple is selling. They are selling a "safe" and at-least-somewhat curated ecosystem.
Third, and I think this is actually most important in Apple's eyes... They want the user to ALWAYS understand which username and password to enter when the phone asks them if they want to buy something. It is absolutely essential to the user experience in Apple's eyes that there is ONE PLACE and ONE PLACE ONLY that you go to change your credit card number. There is ONE username and password that enables "App Purchases" from the user perspective. When you buy something on an iPhone or iPad, unless you do it in a web browser, you absolutely know where the billing is coming from, who to call if there is a dispute, how to change your address, and everything else. The rule is simple. From a user perspective, when you are inside an app other than Mobile Safari, the app cannot EVER ask you for a credit card number, and it can't EVER sell you anything unless it is via the iTunes username/password mechanism. Period. This is absolutely not the case with Android and Cydia.
If you want to get around this, do it on the web. You can do whatever you want on the web. In Apple's eyes, anything that happens in Mobile Safari is "the web" and is "unmoderated" (the "wild west"). Anything that happens in a native app other than Mobile Safari is something else entirely. You may think this is a stupid distinction, and maybe it is, but that is and has been the rule all along. There is nothing new to see here.
