Whether they have removed apps that use is irrelevant. That they can at any point remove them because of their policies but don't should not be lauded, it just creates an air of confusion that they can use to their benefit as they see fit.
Perhaps I was modded down to oblivion because what I said was too obvious, and therefore not adding to the discussion?
The fact remains that there are plenty of documented examples of Apple tossing apps from its App Store for reasons that amount to little more than corporate whim or gatekeeper prerogative, or for no adequately explained reasons at all.
Should Apple ever decide that its popover API is ready for prime time, it could yank all apps that do not use it and demand that the Apple popover be used instead. I seem to recall something similar happening with third-party apps that improved upon the native camera API, but my memory may be suspect.
>The fact remains that there are plenty of documented examples of Apple tossing apps from its App Store for reasons that amount to little more than corporate whim or gatekeeper prerogative, or for no adequately explained reasons at all.
Which is totally unrelated to the discussion about the private API, and if you can replicate a widget provided in one. Which you can.
I thought the inferred relation was clear in his original argument. If Apple makes their private API public, it is then possibly infringing. That's the difference between making an alternate implementation for a private API and something that doesn't exist; there is a higher likelihood that the private API will be made public than that an entirely new API will spring forth that covers the same area. It's already written, just not public.
Not only already written, but usable on [some] iOS devices. When developers can be affected by things that Apple might do in the future, that affects their behavior in the present.
As for myself, the terms for Apple's developer program and its App Store alone are enough for me to prefer to develop in HTML5+javascript or in Android-flavored Java over Objective C for iOS. When you have only one route between you and your money, and one person standing on it, you're going to have issues eventually.
It isn't just true for Apple. When PayPal locks your account, you don't want that to bring your business to a screaming halt, so you open up alternate payment processors, like Stripe, Google, Amazon, Rixty, etc. But unlike that competitive market, there is no alternative to Apple's App Store available to non-jailbroken devices. That is a chokepoint that gives the one holding it dangerous amounts of power over you. Any solo coder or dev shop that gets their revenue exclusively from Apple's ecosystem has a banhammer of Damocles hanging over them at all times. They can't afford to take any risks like that, so they have to dance to Apple's tune, even when there is no strict obligation to do so.
The extra revenue from Apple's customers might be worth it to them. I'd rather have more freedom of choice.
>If Apple makes their private API public, it is then possibly infringing.
No, it's not. From list views to buttons to menubars and keyboards, almost all iOS widgets (private to Apple or usually public) have alternative third party implementations. Nobody is going after them.
You are actually supposed and encouraged to create your own versions of widgets - Cocoa is especially good for that, and there are even instructions in the Apple Developer Network for how to customize views and such.
Doing their own popup widget wont get them into trouble, period.
