Like when Apple said that all Apps needed to be originally written in their crappy language, and that you could not cross-compile to it?
That had literally nothing to do with the end user, and everything to do with trying to enforce a monopoly.
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.)
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.
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.
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.
Amazon should then be allowed to increase their prices on iOS to compensate for the difference. I would happily pay a little extra per-purchase to keep all my purchases under one account, using one interface, and would be happy to take advantage of Touch ID authenticated purchases across stores.
I still do not like the idea of purchasing on iOS outside my Apple ID. It is quite outside my comfort zone to purchase within an app using a different UI, trusting my details with a different provider, and so on.
Regarding handling returns: one of the main complaints I have heard from Android developers is the influx of emails they have from customers asking for refunds, and having to process those refunds. While I agree that it could be used as a promotional opportunity, many developers view it as an unnecessary burden.
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.
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.
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...
That word, monopoly. I don't think it means what you think it means.
What they were trying to enforce was a common programming language for all apps that they could improve in tandem with the OS, so they wouldn't be held hostage in the future to be backwards compatible to some popular runtime (like Flash once threatened to be for the Web).
P.S And "crappy language", really? As far as pragmatic languages lean on resources for native coding go, Objective-C is up there with the best of them. Not to mention the breadth and the maturity of the Cocoa libs.
Not as much as you think. Mono is a niche product too.
>and Java not used outside of Android? ROFL
He said "Java on mobile". Perhaps try to understand what you read before rolling on the floor?
Java mobile (or "end user" apps in general) are Android, some crapplets, and that is mainly.
If it weren't for development tools for Java devs (Eclipse, NetBeans, etc) and some internal enterprise monstrocities people are forced to use, there wouldn't be any Java desktop adoption either.
But that doesn't say the whole story.
Objective-C started as a small language, with a commercial compiler by Brad Cox and no backing by any major vendor. Since then it has only gone from strength to strength.
Before Apple, it was used by NeXT. The first major first-person-shooter (Doom) was done by Carmack on a NeXT in C and Objective-C. The first web broswer was written in Objective-C, by Tim Berner's Lee. Both have praised the environment and language.
Then, there was the OpenStep initiative, between NeXT and SUN, again using an Objective-C API, which, have it been seen to fruition, it would have given us a great UNIX desktop/workstation environment, like a cross between NeXT and Solaris, a decade before OS X and modern Gnome/KDE.
Then there's also the GNUStep project, a third party implementation of that OpenStep/NeXT idea, that also maintains an Objective-C compiler.
There are even ...Javascript ports of Objective-C ( http://www.cappuccino-project.org/ ).
And now of course, Objective-C is adopted by Apple after acquiring NeXT. They sure didn't feel it's a bad language and they have to move on -- instead they bet the whole company's development plans (and third party devs) on the language, and it paid off.
It's one of the most mature and development environments. And I've never seen anyone that programs in it (as opposed to "tried it for a week") badmouth it -- quite the contrary.
I also like how there are mutually incompatible object types (the C types vs the ObjC types) that you have to MakeLongAndRidiculousCallsToConvertAcross.
Going through the basic stuff on the "learn this language" sites was painful.
ObjC is the most programmer-hostile language I've ever seen that wasn't designed with that in mind.
It was a dick move, and thank goodness they got called out for it.
And yes, it was to try to enforce a monopoly.
The policy was changed and ultimately never enforced, but I always viewed it as a way to ensure that developers kept up-to-date.
And after having a client deliver us an Adobe Air app to "fix", I am so glad it didn't become a popular way to develop iOS apps.