181–190 of 235 posts
Earlier quoted context omitted.
Yeah, in a monopoly situation I see where you're coming from, but Apple has very healthy competition from Android. It's not currently in Apple's interest to hobble 3rd party apps; quite the opposite.
On a side note: I wonder why they hard coded the 4 names rather than grant access to all apps with bundle identifiers starting with "com.apple."
Earlier quoted context omitted.
Yeah, in a monopoly situation I see where you're coming from, but Apple has very healthy competition from Android. It's not currently in Apple's interest to hobble 3rd party apps; quite the opposite.
On a side note: I wonder why they hard coded the 4 names rather than grant access to all apps with bundle identifiers starting with "com.apple."
It's totally reasonable for Apple to use APIs internally that it's not ready to make public -- making an API public is a serious decision with lots of downsides! You've got to support the API forever, and future design directions are constrained. To expect Apple to make all code it uses internally available publicly is silly. (If you want some great examples of the extreme amount of work it can be to support legacy A…
When Microsoft did the same thing in Windows it was grounds for anti-trust lawsuits to be brought against them: http://www.pcpro.co.uk/news/101947/microsoft-used-undocument... The idea here is that if you are supplying both the operating system and the applications that your applications should not benefit from being made by the same company as the OS, in other words, that it should be a level playing ground without…
It's called Windows "DirectUser" UI and it's in violation of the antitrust settlement.
sources:
* http://blogs.msdn.com/b/oldnewthing/archive/2006/02/10/52952...
* http://social.msdn.microsoft.com/Forums/windowsdesktop/en-US...
Internet Explorer's use of DUSER.DLL is only temporary.
The final version of Internet Explorer will not use it.
-- Raymond Chen [author of "The Old New Thing"]
Earlier quoted context omitted.
You are fundamentally misunderstanding a monopoly position.
You can always define something as not a monopoly by asserting the truth that people spend their money on a variety of items so the monopolist is competing with manufacturers and purveyors of beer, diesel and kites for the sales. The existence of monopoly isn't actually the interesting test, the test is usually is there an abuse of market power to the detriment of competitors. Emphasis on "abuse" The flip side is tha…
I remember being taught about YKK, a monopoly producer of zips, they kept their monopoly by producing good quality cheap zips. The profit made was enough that they could stay in business but not enough that it was worth other companies expending capital to get into the market.
Monopoly is one state of the market on a spectrum in a capitalist economy, it is neither good or bad it just is.
Earlier quoted context omitted.
"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…
It's totally reasonable for Apple to use APIs internally that it's not ready to make public -- making an API public is a serious decision with lots of downsides! You've got to support the API forever, and future design directions are constrained. To expect Apple to make all code it uses internally available publicly is silly. (If you want some great examples of the extreme amount of work it can be to support legacy A…
If taken too far, this can lead to two-tiers of applications, which can be incredibly bad for the eco-system. On early Windows Phone 7, Nokia used an entirely different api to other apps, that gave much more freedom. So Nokia apps both allowed custom styles, and were much faster. This meant no apps on the store could really compete with the system apps. I'm unsure if this changed with Windows Phone 8, though I'm sure…
Are there any private APIs which really do amount to "unfair advantage for Apple"? or does the whole issue amount to sniveling about not being able to play with all their toys and having to bring your own?
So who will be the first to override "bundleIdentifier" to inspect the stack and return @"com.apple.iBooks" if UIPopoverController is calling it?
Earlier quoted context omitted.
Yeah, in a monopoly situation I see where you're coming from, but Apple has very healthy competition from Android. It's not currently in Apple's interest to hobble 3rd party apps; quite the opposite.
It's a local monopoly. An iOS user won't just switch to Android. Not overnight, at least.
When deciding if a monopoly exists, the relevant threshold is whether the customer had other reasonable options at the time of entering the contract, and in the smartphone world they unequivocally did have other options.
It's totally reasonable for Apple to use APIs internally that it's not ready to make public -- making an API public is a serious decision with lots of downsides! You've got to support the API forever, and future design directions are constrained. To expect Apple to make all code it uses internally available publicly is silly. (If you want some great examples of the extreme amount of work it can be to support legacy A…
However, this is iBooks, which you get from the App Store just like all third-party apps. It's explicitly competing with products from third-party developers. In this area, there should be a level playing field.
When us third-party developers distribute on the App Store, we have to agree to a contract that, among other things, states that our apps will not use private APIs. Why do Apple's apps, when distributed through the App Store, not follow the same rules? Why should they get special treatment for apps that aren't built in to the OS and which are distributed using the same channels the rest of us use?
This popover example is fairly trivial, since nothing stops you from building your own version of it and shipping it in your app, but it illustrates the point. A more significant example is the screen brightness control. iBooks has a slider that you can use to adjust the brightness of the screen. This brightness adjustment uses private API, and because of that, other eBook readers cannot replicate that feature. There is no technical reason third-party apps couldn't do this (they have the same access to the device that iBooks does) but Apple doesn't allow it.
The Kindle app, for example, has a brightness slider too. Except it doesn't adjust the screen brightness. It just adjusts the gray level of the white background, while leaving the backlight at original strength. This means that you lose contrast and use more battery power, meaning that the Kindle app is inherently worse because Apple isn't playing fair.
This is less important these days, now that Control Center lets you easily access the device brightness from anywhere. It was a big hit against Kindle's usability for years, though.
Might be time for the Apple PR machine to crank up some more stories about developers making millions writing apps. As every casino in Vegas knows, watching some guy hit it big is a great way to take your mind off how many resources you're losing. I wonder, though, if there's going to be an end-game to this walled-garden nonsense. On one hand, people (tech-minded people) seem to be slowly getting it. On the other han…