Hacker News Reader

Comment by interpol_p | Hacker News Reader

While I view this move as hypocritical of Google, it does feel like it's in their customers' best interest.

Think about it from a less technical perspective: I can install an app from the official Google Play store that voids my warranty.

They can't have that on their public facing store. Google wants users to install apps, they don't want them to be afraid of voiding their warranty.

It's interesting to see how things played out over the last few years.

Google has been moving towards a more controlled environment, from something that was initially billed as open.

Apple started completely locked down with a strong customer focus, and has cautiously been making their policies more developer friendly.

I personally prefer Apple's approach, as it was always about the end user — but as a developer I was sometimes envious of Google's lenient policy. Google's assertion of control now makes me more interested in developing for their platform.

View on HN

Always about the end user?

Like when Apple said that all Apps needed to be originally written in their crappy language, and that you could not cross-compile to it?

That had literally nothing to do with the end user, and everything to do with trying to enforce a monopoly.

I'm pretty sure the restriction to objective-c was due to performance concerns.

why? if the app performes badly they can just reject it, regardless of the programming language

I believe it was also due to wanting developers to make use of the latest OS frameworks. Third party development frameworks often lagged behind in features (i.e, doesn't support new auto rotation features, doesn't support new camera features, and so on).

The policy was changed and ultimately never enforced, but I always viewed it as a way to ensure that developers kept up-to-date.

It think the timing (days before the Adobe Flash CS5 launch, the first release that included iPhone application support, IIRC) and the eventual reversal makes it clear that this was about making life difficult for Adobe and Flash and not much else.

Good point.

And after having a client deliver us an Adobe Air app to "fix", I am so glad it didn't become a popular way to develop iOS apps.

Apple said that, but never enforced it. So that piece of policy was more a fallback (i.e., "something we can point at if an app happens to do something we didn't anticipate"). And it was eventually removed (hence my comment about Apple lessening some of their control over time).

Most of Apple's decisions are about the end user, often to the detriment of the developer. Mandatory app review, Apple deals entirely with customers, unified in-app purchase interface.

By the way, when that policy was put in place Apple had no "monopoly" to "enforce". So it simply makes no sense for you to say that.

It had everything to do with maintaining control over their platform. Cross-compilation was not encouraged because it almost always means that the frameworks which cross compile maintain feature parity with older versions of the platform SDK. It means that end users don't see apps taking advantage of new features and frameworks.

Look at where Apple is now and tell me that was a bad decision — developers scramble to update their apps to incorporate the newest OS features, this leads to huge competition in design and polish amongst the best apps on the App Store. Ultimately the decision benefited customers and developers.

The policy was overturned largely because games became unexpectedly popular. And games don't need to use the latest OS features to deliver a quality experience. The rising popularity of Unity 3D also drove the decision. (You will recall that when the policy was publicised, there were hundreds of Unity developed games on the App Store. None were pulled and the policy was instead changed.)

Looking where Apple is now, that decision helped them, but I don't think you are making a case that it helped consumers. There are countless ways that Apple stifled competition when 3rd party applications compete directly with the applications Apple ships OOTB.

The unified in-app purchase has benefits, but it also comes with strings attached. The 30% rake means that either users pay for the markup or developers must eat that overhead. By locking application developers out of rolling their own in-house solutions, consumers suffer. That decision may benefit consumers by presenting a unified interface, but it has everything to do with making Apple more money. If Apple really had it's users in mind, they could have simply created an API that provides the unified interface but allows developers to hook in their own back end processing. Better yet, allow in-app purchases that don't have the 30% markup. This will never happen because at the end of the day Apple is looking out for themselves, not the users of their devices.

Your argument does not take into account the fact that a unified interface boosts consumer confidence and trust, which increases spending. It directly influences the quality of the end product — compromising on that is failing your users. Who cares if developers have to give up a cut? It's a level playing field: every developer gives up 30%, so prices standardise with that in mind.

If developers rolled their own and there was a proliferation of mis-matched payment methods throughout the App Store (based on whatever each developer thought got them the most money), then I doubt consumers would be spending as much as they do today. Even Google Play requires developers selling digital goods to use Google's in-app purchase API (of which they get a 30% cut).

The decision helped Apple as much as it helped customers — happy customers pay more money and pay again. So it is in Apple's interest to be as pro-consumer as possible in order to make the most money.

The 30% fee is the same as what Google takes. At the time it was introduced, it was substantially less than other publishers (I heard numbers in the 50-70% range).

Even then, Apple does a lot of work for their 30%. For example, they handle your international tax contributions (Google Play does not), they handle customer returns (Google Play does not).

As a developer that has sold directly and through in-app purchase, I have never felt that the 30% was much of an ask. If you sell on Steam you'll pay around the same cut, almost all other App Stores have standardised on 30% since the App Store.

No one here is arguing that Apple shouldn't offer a standard in-app purchase option. As you describe, there are substantial benefits. The issue is with the way they mandate it, even in situations where it is actively harmful.

Amazon (to take the most notorious of many examples) doesn't need Apple's help to build consumer confidence and trust. In fact, including Apple in Amazon's transactions makes them more complicated and less trustworthy (consider what could happen if there's a hiccup in associating your Kindle account and your Apple ID). And the 30% cut isn't anywhere near a level playing field for them, since they compete with the one company that doesn't pay it (and have similar costs for acquiring the digital content they sell).

You also misunderstand Google Play's policy on digital in-app purchases. Google doesn't require all in-app purchases to go through their IAP system, just the ones that unlock application functionality (so you can't evade the 30% cut of app purchases by rolling your own IAP). This is qualitatively different from Apple's policies as a simple glance at the iOS vs Android Kindle, Nook, Kobo, Amazon MP3 (and on and on) apps will demonstrate.

Finally, I'll add that Apple handling returns isn't necessarily a benefit. It means iOS developers can't offer more generous return policies than the standard one, something many have used to good effect on Android.

You are correct, of course. I agree and think Apple should change their policy regarding non-app specific digital content. However, I believe Apple should simply lower their payment split down to 5-10% and behave more like a standard payment processor attached to your Apple ID.

Amazon should then be allowed to increase their prices on iOS to compensate for the difference. I would happily pay a little extra per-purchase to keep all my purchases under one account, using one interface, and would be happy to take advantage of Touch ID authenticated purchases across stores.

I still do not like the idea of purchasing on iOS outside my Apple ID. It is quite outside my comfort zone to purchase within an app using a different UI, trusting my details with a different provider, and so on.

Regarding handling returns: one of the main complaints I have heard from Android developers is the influx of emails they have from customers asking for refunds, and having to process those refunds. While I agree that it could be used as a promotional opportunity, many developers view it as an unnecessary burden.

> Most of Apple's decisions are about the end user, often to the detriment of the developer. Mandatory app review, Apple deals entirely with customers, unified in-app purchase interface.

Please explain to me how Apple effectively blocking users of Amazon apps from having the in-app stores (ebooks, mp3s, etc.) they have on Android is in the user's interest. When you're done with that, do the same for Apple's effectively blocking in-app links to Amazon's web stores. From where I'm sitting, that's all about protecting Apple's interests their competing stores, interests of their users be damned.

Conjecture: End users can be confident everything that they purchase in an app is tied to their iTunes account. Purchasing an Amazon e-book using the Kindle app means the end user — who is not the most tech-savvy — needs to have an Amazon account and they need to be aware that anything purchased in the Kindle app (and only the Kindle app) doesn't get associated with their iTunes account, which is a different behavior than every other app on the App Store.

Of course, the 30% cut that Apple wanted to take most likely had something to do with it, but there is a good reason to forbid developers from implementing their own in-app purchases.

If Apple didn't have this restriction, it wouldn't just the Kindle app, of course. It would also be Nook, Kobo, Google Books, Amazon Cloud Player, Google Music, HMV, ...

Superficially, this sounds even worse, but this is exactly the situation on Android. I've never heard of an Android user being confused by it, so I suspect this behavior far more intuitive than you think. On the other side of the ledger, I've heard of more than a few users (including tech-savvy ones who were previously familiar with the relevant history) being confused about not being able to buy books in the iOS Kindle app.

Separately, you didn't address Apple's prohibition of links to the relevant web store / website through which the store can be reached. At that point the purchase isn't even in-app (and the relevant purchase flow is exactly the same except that the user has to remember how to get to the website on their own), so...

>That had literally nothing to do with the end user, and everything to do with trying to enforce a monopoly.

That word, monopoly. I don't think it means what you think it means.

What they were trying to enforce was a common programming language for all apps that they could improve in tandem with the OS, so they wouldn't be held hostage in the future to be backwards compatible to some popular runtime (like Flash once threatened to be for the Web).

P.S And "crappy language", really? As far as pragmatic languages lean on resources for native coding go, Objective-C is up there with the best of them. Not to mention the breadth and the maturity of the Cocoa libs.

Objective C is so good that no one ever chooses to use it outside of Apple world.

Right, because the popularity of a programming language is always directly correlated to the quality of its design, and because when people choose languages to build a project in they only ever take technical considerations into account.

This is the same as criticizing C# because nobody uses it outside of Microsoft world - or Java on mobile because nobody uses it outside of Android.

err.. I think there are lot of mono software written in c# that runs on Ubuntu .. and Java not used outside of Android? ROFL

>I think there are lot of mono software written in c# that runs on Ubuntu

Not as much as you think. Mono is a niche product too.

>and Java not used outside of Android? ROFL

He said "Java on mobile". Perhaps try to understand what you read before rolling on the floor?

Java mobile (or "end user" apps in general) are Android, some crapplets, and that is mainly.

If it weren't for development tools for Java devs (Eclipse, NetBeans, etc) and some internal enterprise monstrocities people are forced to use, there wouldn't be any Java desktop adoption either.

You're really reaching if you are trying to argue that Java isn't popular.

User installable applications for pre-smartphones were pretty much exclusively in J2ME...

"Apple world" is pretty big.

Quit acting like GNUStep doesn't exist.

That's because there isn't a vast SDK like Cocoa outside of OS X. That needs vendor support.

But that doesn't say the whole story.

Objective-C started as a small language, with a commercial compiler by Brad Cox and no backing by any major vendor. Since then it has only gone from strength to strength.

Before Apple, it was used by NeXT. The first major first-person-shooter (Doom) was done by Carmack on a NeXT in C and Objective-C. The first web broswer was written in Objective-C, by Tim Berner's Lee. Both have praised the environment and language.

Then, there was the OpenStep initiative, between NeXT and SUN, again using an Objective-C API, which, have it been seen to fruition, it would have given us a great UNIX desktop/workstation environment, like a cross between NeXT and Solaris, a decade before OS X and modern Gnome/KDE.

Then there's also the GNUStep project, a third party implementation of that OpenStep/NeXT idea, that also maintains an Objective-C compiler.

There are even ...Javascript ports of Objective-C ( http://www.cappuccino-project.org/ ).

And now of course, Objective-C is adopted by Apple after acquiring NeXT. They sure didn't feel it's a bad language and they have to move on -- instead they bet the whole company's development plans (and third party devs) on the language, and it paid off.

It's one of the most mature and development environments. And I've never seen anyone that programs in it (as opposed to "tried it for a week") badmouth it -- quite the contrary.

I don't know about you, but I can't stand it it when my method calls are less wide than my screen. ObjC solves that.

I also like how there are mutually incompatible object types (the C types vs the ObjC types) that you have to MakeLongAndRidiculousCallsToConvertAcross.

Going through the basic stuff on the "learn this language" sites was painful.

ObjC is the most programmer-hostile language I've ever seen that wasn't designed with that in mind.

There is literally no reason to not allow cross-compiling. From one language into Objective-C. From one library into Cocoa. The ONLY reason to prohibit that, is to try to force people to stay inside your walled garden, with no way to climb out, allowing you to simultaneously develop apps for multiple (non-iOS) devices.

It was a dick move, and thank goodness they got called out for it.

And yes, it was to try to enforce a monopoly.

The app doesn't void your warranty. It encourages you to perform further actions that may void your warranty. Major difference. The article is clear that Google admits the app itself is not harmful.

I don't think that's a good enough distinction. If it's from the official store it should not even indirectly lead to harming your device or warranty.

If an app tells you to throw your phone in the air — and I was both the phone hardware manufacturer and app store curator — I wouldn't allow it on my store either. It's going to increase customer complaints.

Not sure if you're intentionally referencing this, but there are definitely apps in the Google Play store that explicitly encourage you to throw your phone in the air, such as Send Me To Heaven app[1]

[1] https://play.google.com/store/apps/details?id=com.carrotpop....

(I don't actually disagree with your point, just thought it was funny)

Eh, it's actually a pretty weak argument. It doesn't violate your warranty on a nexus device. If google believes in the nexus program, then this is not a particularly consistent position.

The Nexus lines are not the only Android devices out there. Google has a huge interest in the rest of the Android lines and wouldn't want to piss off OEMs by including an app that would void their warranties.

I definitely agree with what that one Reddit comment says - if you can't sideload it then you shouldn't flash your ROM.

While I agree that the Play Store is becoming more controlled, the fact that you can sideload apps means that ultimately, the platform itself is still very open -- maybe just not as much to the typical end user.

It doesn't void my warranty. Nor millions of others'.

How is it “hypocritical”? they tend to boot malware as well from the play store, which also violates the TOS.

This app has bricked the devices of less technical users and left them without a warranty, Google's obligations is to prevent that.

Fair enough, calling Google hypocritical was reactionary on my part.

In my memories of Google's introduction of the Android Market, they seemed to play-up the "no review period" as an advantage over the App Store. I think there has been some mixed messaging from Google over the years — they extol openness and developer freedoms, but clearly enforce terms of service where it counts.

Perhaps it's not hypocritical, but at times it feels like there are two Googles.

Reply on news.ycombinator.com