3 ms·
Apple said that, but never enforced it. So that piece of policy was more a fallback (i.e., "something we can point at if an app happens to do something we didn'
by interpol_p 13y ago
Apple said that, but never enforced it. So that piece of policy was more a fallback (i.e., "something we can point at if an app happens to do something we didn't anticipate"). And it was eventually removed (hence my comment about Apple lessening some of their control over time).
Most of Apple's decisions are about the end user, often to the detriment of the developer. Mandatory app review, Apple deals entirely with customers, unified in-app purchase interface.
By the way, when that policy was put in place Apple had no "monopoly" to "enforce". So it simply makes no sense for you to say that.
It had everything to do with maintaining control over their platform. Cross-compilation was not encouraged because it almost always means that the frameworks which cross compile maintain feature parity with older versions of the platform SDK. It means that end users don't see apps taking advantage of new features and frameworks.
Look at where Apple is now and tell me that was a bad decision — developers scramble to update their apps to incorporate the newest OS features, this leads to huge competition in design and polish amongst the best apps on the App Store. Ultimately the decision benefited customers and developers.
The policy was overturned largely because games became unexpectedly popular. And games don't need to use the latest OS features to deliver a quality experience. The rising popularity of Unity 3D also drove the decision. (You will recall that when the policy was publicised, there were hundreds of Unity developed games on the App Store. None were pulled and the policy was instead changed.)
- chinpokomon 13y agoLooking where Apple is now, that decision helped them, but I don't think you are making a case that it helped consumers. There are countless ways that Apple stifled competition when 3rd party applications compete directly with the applications Apple ships OOTB. The unified in-app purchase has benefits, but it also comes with strings attached. The 30% rake means that either users pay for the markup or developers must eat that overhead. By locking application developers out of rolling their own in-house solutions, consumers suffer. That decision may benefit consumers by presenting a unified interface, but it has everything to do with making Apple more money. If Apple really had it's users in mind, they could have simply created an API that provides the unified interface but allows developers to hook in their own back end processing. Better yet, allow in-app purchases that don't have the 30% markup. This will never happen because at the end of the day Apple is looking out for themselves, not the users of their devices.
- interpol_p 13y agoYour argument does not take into account the fact that a unified interface boosts consumer confidence and trust, which increases spending. It directly influences the quality of the end product — compromising on that is failing your users. Who cares if developers have to give up a cut? It's a level playing field: every developer gives up 30%, so prices standardise with that in mind. If developers rolled their own and there was a proliferation of mis-matched payment methods throughout the App Store (based on whatever each developer thought got them the most money), then I doubt consumers would be spending as much as they do today. Even Google Play requires developers selling digital goods to use Google's in-app purchase API (of which they get a 30% cut). The decision helped Apple as much as it helped customers — happy customers pay more money and pay again. So it is in Apple's interest to be as pro-consumer as possible in order to make the most money. The 30% fee is the same as what Google takes. At the time it was introduced, it was substantially less than other publishers (I heard numbers in the 50-70% range). Even then, Apple does a lot of work for their 30%. For example, they handle your international tax contributions (Google Play does not), they handle customer returns (Google Play does not). As a developer that has sold directly and through in-app purchase, I have never felt that the 30% was much of an ask. If you sell on Steam you'll pay around the same cut, almost all other App Stores have standardised on 30% since the App Store.
- fpgeek 13y agoNo one here is arguing that Apple shouldn't offer a standard in-app purchase option. As you describe, there are substantial benefits. The issue is with the way they mandate it, even in situations where it is actively harmful. Amazon (to take the most notorious of many examples) doesn't need Apple's help to build consumer confidence and trust. In fact, including Apple in Amazon's transactions makes them more complicated and less trustworthy (consider what could happen if there's a hiccup in associating your Kindle account and your Apple ID). And the 30% cut isn't anywhere near a level playing field for them, since they compete with the one company that doesn't pay it (and have similar costs for acquiring the digital content they sell). You also misunderstand Google Play's policy on digital in-app purchases. Google doesn't require all in-app purchases to go through their IAP system, just the ones that unlock application functionality (so you can't evade the 30% cut of app purchases by rolling your own IAP). This is qualitatively different from Apple's policies as a simple glance at the iOS vs Android Kindle, Nook, Kobo, Amazon MP3 (and on and on) apps will demonstrate. Finally, I'll add that Apple handling returns isn't necessarily a benefit. It means iOS developers can't offer more generous return policies than the standard one, something many have used to good effect on Android.
- fpgeek 13y ago> Most of Apple's decisions are about the end user, often to the detriment of the developer. Mandatory app review, Apple deals entirely with customers, unified in-app purchase interface. Please explain to me how Apple effectively blocking users of Amazon apps from having the in-app stores (ebooks, mp3s, etc.) they have on Android is in the user's interest. When you're done with that, do the same for Apple's effectively blocking in-app links to Amazon's web stores. From where I'm sitting, that's all about protecting Apple's interests their competing stores, interests of their users be damned.
- ceol 13y agoConjecture: End users can be confident everything that they purchase in an app is tied to their iTunes account. Purchasing an Amazon e-book using the Kindle app means the end user — who is not the most tech-savvy — needs to have an Amazon account and they need to be aware that anything purchased in the Kindle app (and only the Kindle app) doesn't get associated with their iTunes account, which is a different behavior than every other app on the App Store. Of course, the 30% cut that Apple wanted to take most likely had something to do with it, but there is a good reason to forbid developers from implementing their own in-app purchases.
- fpgeek 13y agoIf Apple didn't have this restriction, it wouldn't just the Kindle app, of course. It would also be Nook, Kobo, Google Books, Amazon Cloud Player, Google Music, HMV, ... Superficially, this sounds even worse, but this is exactly the situation on Android. I've never heard of an Android user being confused by it, so I suspect this behavior far more intuitive than you think. On the other side of the ledger, I've heard of more than a few users (including tech-savvy ones who were previously familiar with the relevant history) being confused about not being able to buy books in the iOS Kindle app. Separately, you didn't address Apple's prohibition of links to the relevant web store / website through which the store can be reached. At that point the purchase isn't even in-app (and the relevant purchase flow is exactly the same except that the user has to remember how to get to the website on their own), so...