[deleted]
How Apple Cheats
161–170 of 235 posts
Re: How Apple Cheats
#162I am surprised that this is so shocking to the author. Stuff like this is expected and only logical, as wrong as it may be. Apple has been desperately trying to tie people into their eco-system and every move the company makes is a step in that direction whether it may be immediately obvious to other people or not. Also I should mention that I believe Apple is probably not the only company that promotes the use of it…
I like how your rant about "trying to tie people into their ecosystem" has absolutely nothing with the situation here, which is the fact Apple's apps use some harmless private APIs before they finalize them to a degree to make them public. Tell me, what other "expected and only logical" things did you encounter while reading the article? I'm sure there's an alien invasion conspiracy theory in there somewhere.
Bleh. Come on, this is just apologist. So much spin here about how "it might not be production ready, so of course they're just 'testing' it internally before making it widely available".
Except...
As noted elsewhere, "it's a trivial component, almost akin to a tooltip".
And iBooks, one of the apps, was introduced in January 2010, and requires iOS 4.3 or later.
People who, with a straight face, claim that Apple has needed nearly four-and-a-half years (more, really, since there was pre-release testing), and since iOS 4.3 to make sure a "trivial component" was ready for the public are really grasping at straws.
Re: How Apple Cheats
#163I would not consider the default applications on the iphone "apps" even. They are written by Apple to provide a certain functionality and that is what they do. They can use any API they need. Why should they not use private API? I would not consider iBooks to be somehow different from say the phone or system preferences "app". They are there because they are provided by the system.
You need to download iBooks, it does not come pre-installed.
Re: How Apple Cheats
#164Earlier quoted context omitted.
The difference may be that Microsoft used the private APIs to give itself (and select partners) advantages over competitors while being a monopoly. I don't know if Apple is using those APIs to give themselves an advantage over competitors but they certainly are not a monopoly as Microsoft is.
One of the conditions of the apple app store, the single entry to any customer's smartphone, is that you don't directly compete with any apple app. What more do you really need to know ? If this isn't abuse of monopoly power, then what is ?
Have you not seen google maps, amazon's kindle app, the many weather and stock apps, Instagram for taking and sharing photos? I can't think of a native app that doesn't have competition.
Re: How Apple Cheats
#165Earlier quoted context omitted.
It's a local monopoly. An iOS user won't just switch to Android. Not overnight, at least.
iOS users do switch to Android. You don't see it all the time because users (in the US at least) are stuck in 2 year contracts and phones are an expensive purchase. But they do. Does Honda have a "local monopoly" on sedans because Civic drivers don't usually switch to a Kia Forte overnight?
Not quite, because "sedans" is not the relevant market. It isn't that you can't buy a Kia the next time you go to buy a car, it's that once you own a Civic you have to put Civic replacement parts on it. So then you get the relevant question, does Honda have a monopoly on any Civic replacements parts? Some parts (e.g. brake pads) may be produced by third parties in competition with Honda, so for those parts the answer is no. For other Civic parts not made by anyone else, the answer is yes.
So to get back to Apple: They don't have a monopoly on smartphones, they have a monopoly on iOS app stores.
Re: How Apple Cheats
#166Like others, I'm fairly convinced that this is simply not enabled because Apple haven't done the necessary amount of work to ensure that the UIPopoverController on an iPhone is stable, API-compliant, and well-tested. Specific use-cases under their control can be extensively tested, and it may be the case that e.g. iBooks only uses a subset of the functionality. More to the point, there's nothing to be gained from thi…
What I find confusing is why the API would be acceptable on an iPad and not on an iPhone. It seems unlikely that Apple would be willing to devote the resources to testing the element on one and not the other, or that the software behind the two implementations is different enough that testing would not carry between the two. And, if that were the case, surely it would have been easier to just not release the API at all?
Rather, it sounds like someone at Apple decided that popover widgets provide a poor user experience in small form factors unless they are carefully designed, so they disabled the API on the iPhone to discourage careless use. Obviously, the same restriction would not apply to Apple... which is unfair but understandable, given that "We know design better than you" is basically Apple's value proposition.
Re: How Apple Cheats
#167Earlier quoted context omitted.
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, i…
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]. [1] https://www.cocoacontrols.com/controls/wypopovercontroller [2] https://itunes.apple.com/us/app/cookapp/id771313730?mt=8&uo=...
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.
Re: How Apple Cheats
#168Earlier quoted context omitted.
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 futu…
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, i…
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.
Re: How Apple Cheats
#169Earlier quoted context omitted.
No, the point is you have no argument in addition to no authority. It's normal to require one or the other.
My argument is, since you insist that I don't have any, that since Apple has total control of an ecosystem they themselves created that there might be an anti-trust issue there along the lines of Microsoft when they decided to include 'mediaplayer' with every windows install when and if an Apple app competes with a 3rd party supplied app. Whether or not I'm a subject expert or not has no bearing on that. I suspect th…
Microsoft including a media player, meant that >95% of desktop PCs had a Media Player from microsoft, thus there was no 3rd party market for Media Players. But microsoft did more than merely include a Media player with regards to IE. They embeded the media player into the operating system so you could not remove it. You had no option but to get it.
Lets say there was a device that allowed you to pay tolls from your car in bitcoin. GM including a version of that in their cars would not dominate the market. It would diminish it, but not devastate. But lets say GM sold 80% of the cars in the world. Even then, including the device wouldn't be a violation of anti-trust.
Through the early 90s, MS did this often, Media Players, Disk Compression, Defrag, the list goes on and on.
But, if GM had 95% of the car market, and included a device that only paid in fiat currency, and it was 'artificially' tied into the ignition computer, so removing it made the cars useless. Then had the device subtly interfere with any alternate device. Finally, there was evidence, (emails from CEOs, VPS) that GM did this with the sole purpose of preventing BitCoin as a currency. Then you'll understand the scope of M$'s efforts in the browser wars, and what it took to finally get them at antitrust.
Re: How Apple Cheats
#170Earlier quoted context omitted.
The API is available. It compiles just fine. It just throws an exception when you try to initialize. There is no reason for this other than UI opinions. It clearly runs fine since Apple is using it. Since this is a simple control, there are no use cases that Apple is somehow snuffing through their use. It is not difficult at all in iOS 7 to create a modal popup on an iPhone. I don't think it would be too difficult to…
"It clearly runs fine since Apple is using it." This doesn't mean it runs fine, it means that in the particular cases that Apple uses the API for it runs fine. Apple may not have tested the API sufficiently for broader usage, or made special cases in the API to support their specific internal usage. Public usage of the API on iPhones may result in concerns about security, stability, or it may simply not behave on iPh…
This class only has one function. It pops up. That's all. There is a UIView that shows content. It literally only has one job.
The environment that runs the iPad and the iPhone is the same. You can run the same exact code on either device. The UI code between devices are equivalent. They have the same class hierarchies. UIPopoverViewController is an NSObject. It has one function that the writer of this article proved can be run just fine on an iPhone by reversing the code.
It uses CGRects to lay itself out. This is prevalent in one of the delegate callbacks.
It uses the UIPopoverControllerDelegate in order to send the calling class callbacks relative to certain events. That is standard code on iOS both for iPads and iPhones. When creating a universal app, I have never had to change how I use delegates between the iPad and the iPhone.
This is because they both run objective C with the same SDK. When compiling the iPad version of your XCode project, you may have to change your build target, which is indicative of differences in the environment (perhaps only the CPU architecture). You do not, however, change an SDK. The classes you import are identical.
I believe Apple's reasoning is entirely valid. Popovers look terrible on small devices. That is what the Apple guidelines state. I like that they are very opinionated with their design guidelines. There are still a very many ways of doing things and staying inside those guidelines.
Edit: I believe that the presence of the UIPopoverController while building an iOS app is proof enough that the SDKs are identical.