Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How Apple Cheats

marksands.github.io

Post reply on HN
Print view View original

131–140 of 235 posts

Re: How Apple Cheats

#131

Post by keeperofdakeys »

mirsadm wrote: post #66
gioele wrote: post #63

Let's contrast with Android's take on a private API: private Content Providers. > The problem is, there are more Content Providers in the system than are documented in that package, and while you can use them, you probably shouldn’t. They’re there because some of the Google-provided apps use them internally to access their own data resources. Because Android is an open-source project, it’s easy enough to find them ju…

Not only that I believe Google contacted most of the popular SMS devs when they made huge changes to the SMS content providers in Kit Kat (which are private). They didn't really need to but did to let them know of the changes.

However they acted differently for the wakelock api. In Android, there is a private api that allowed access to a list of wakelocks, which was used by many apps to provide the user with more information about what is keeping the system awake. However, their was a security implication (this was a real concern), so 4.4 made the api both private and inaccessible. (Private apis by default you can't use, but you can get around it by getting a reference using language-features). Unlike the sms situation though, they didn't provide a replacement api without the security issue. So now you need to root the phone in order to access the list of wakelocks.

While this may not affect most of the users of these apps, this is quite unfortunate, because these applications were especially handy on non-stock phones, which usually aren't easily rootable.

Re: How Apple Cheats

#132

Post by DCKing »

yalogin wrote: post #16

I 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.

That should only go as far as the app store and the settings app. The rest of the applications on the system have no reason to be special for they don't need special system administration tasks to function.

Android even functions where nothing is a 'special' app. (Although no phone is actually released that way, but it can be achieved with custom ROMs).

Re: How Apple Cheats

#133

Post by taumhn »

That's a pretty boring way of preventing someone from using the API. You could easily swizzle the _popoversDisabled method and get away with it.

I remember trying to use a private API on Mac OS X and having my app receive a SIGKILL prompty after calling the function. It took me a while to find the fix: my app had to be signed. Mind you, it could be codesigned by a self-signed certificate and the system would be fine with it... these were fun times :)

Re: How Apple Cheats

#134

Post by rando289 »

GrinningFool wrote: post #120
jacquesm wrote: post #36

Earlier quoted context omitted.

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…

Those rules apply in a monopoly - when a business is not a monopoly it has considerably more freedom.

Apple has a monopoly on operating systems which work on apple hardware.

Re: How Apple Cheats

#135

Post by keeperofdakeys »

dilap wrote: post #27

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 it would have.

Re: How Apple Cheats

#137

Post by paulhauggis »

al2o3cr wrote: post #122
loup-vaillant wrote: post #112

Earlier quoted context omitted.

It's a local monopoly. An iOS user won't just switch to Android. Not overnight, at least.

"local monopoly": meaningless. That's like saying that Gmail has a "local monopoly" on web-based email because switching would be a hassle.

many people still considered windows a monopoly, when you could easily buy redhat at most local stores. MS Office file formats were also considered a monopoly by Richard Stallman, because businesses used them and it was difficult to now change (there are tons of competing formats).

the tech industry likes to change definitions to fit their viewpoints.

Re: How Apple Cheats

#138

Post by valarauca1 »

rando289 wrote: post #134
GrinningFool wrote: post #120

Earlier quoted context omitted.

Those rules apply in a monopoly - when a business is not a monopoly it has considerably more freedom.

Apple has a monopoly on operating systems which work on apple hardware.

I don't think your understanding how a Monopoly applied in the situation with Microsoft.

Microsoft's Anti-trust suite was because of its web browser's dominance, IE was during the anti-trust suite upwards of 95% of all browsers on the Internet, this was because of bundling and defaults.

While other OS's may not execute on Apple's own hardware, other hardware exists (other smart phones) that directly compete with Apple. And by compete I mean neither Apple nor Andriod nor WindowsPhone 'owns' >90% of the mobile market.

This is how Sun didn't get involved in trust litigation over the fact that Solaris was the only OS that ran on Sun SPARC hardware, because its hardware was work station hardware. Which had to compete with Silicon Graphics, IBM, Apple, Next, etc.

Re: How Apple Cheats

#139

Post by keeperofdakeys »

achivetta wrote: post #111
martinnormark wrote: post #65

This reminds me of how Microsoft added specific code to Windows 95 to ensure SimCity would run. This is from Joel Spolsky's Strategy Letter II: Chicken and Egg Problems http://www.joelonsoftware.com/articles/fog0000000054.html So Windows 3.x on Intel 80386s was the first version that could run multiple DOS programs respectably. (Technically, Windows 386 could too, but 80386s were rare and expensive until about the ti…

Amazingly, this sort of use-after-free causes compatibility problems for allocator writers even today. Imagine if you change the implementation of malloc() such that smaller allocations get their own mmap() region rather than being stuffed in with other allocations. Now any use-after-free bugs to allocations affected by the change will segfault instead of reading garbage, since the allocator would munmap the region u…

That's why programs like valgrind are great, they check all your memory allocations, and ensure these kinds of bugs don't occur (though it can only test codepaths that run, and has an overhead for all the checks).

This is also why I'm so excited about Rust. Suddenly your compiler and language definition ensure these kinds of bugs can't occur.

Re: How Apple Cheats

#140

Post by endersshadow »

scott00 wrote: post #117
endersshadow wrote: post #106

Earlier quoted context omitted.

It's not just the person you're responding to--the FTC looks only at relatively pure monopolies for anti-trust violations. There are lots of things that are legal as a player in a competitive market versus illegal as a monopoly. The US has a long history with pure monopolies, which are why the laws are the way they are. You can argue until you're blue in the face that the FTC should look at other things, as well, but…

The SEC has nothing to do with enforcement of antitrust law. The Federal Trade Commission and the Department of Justice share that responsibility.

You're right, I'm sorry--it was early and I got my initialisms wrong. Thank you for the correction--I'll correct my post.
Post reply on HN