Well, a PopOver widget is not something that gives any unique advantage to Apple. It can be replicated in a week or so by a third party.
Now, a serious API, like say only Apple getting use of the accelerometer, that would be something. This is not the case here.
But again, expecting all APIs to be public from day one is idiotic. APIs should only be made public if they are stable and ready to be supported for the future.
It could be replicated by a third party, but thanks to Apple policy, using such a third-party component could be grounds for removal from the Apple App Store.
What Apple can do and what it should do are not necessarily the same things. While it can establish privileged APIs, it should not. While it can attempt to support outside developers as a hardware company while also competing with them as a software company, it should not.
If it is easily demonstrated for this particular API, it may be present and less obvious elsewhere, including a serious API. The only way to know for sure is to inspect the code.
Nonsense. I'm using WYPopoverController[1] in some of my apps and they're a-ok. On the component's page they even have links to apps in the App Store that use it[2].
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.
What. No. Developing your own third-party UI components, even components that look and feel like Apple components, is not grounds for removal from the App Store.
Now, a serious API, like say only Apple getting use of the accelerometer, that would be something. This is not the case here.
But again, expecting all APIs to be public from day one is idiotic. APIs should only be made public if they are stable and ready to be supported for the future.