Why Apple did what they did | Hacker News Reader

Why Apple did what they did

blog.alexandretestu.com

23 pointsKevinBongart27 comments

Why Apple did what they did: to hurt Adobe, to hurt Android.

Why they're not concerned about the collateral damage: because they really don't care whether small developers have access to the platform or not, they're more interested in having more AAA titles.

I'm pretty sure everyone who thinks it was arrogant, hostile, and stupid of them to do such a thing understands why Apple did it. Everyone also understood why Microsoft spent a great deal of time forcing OEMs to offer only their software.

I get the point about Adobe, but Android?

Using translators it would be possible to create a sort of meta-platform that could compile to both iPhoneOS and Android. A clever developer could make an SDK that abstracted the differences in the platforms and made it easier for developers to support both platforms by using the same codebase for the same apps on either. By making it more difficult to support both at the same time, Apple may be hoping to keep more developers on only their platform and retain the edge that they have over Android.

That's what quite a few programming platforms already do (I know it's the case with Appcelerator and suspect MonoTouch doesn't do it any differently); but these are actively outlawed by the new paragraph 3.3.1: (emphasis added)

Applications must be originally written in Objective-C, C, C++, or JavaScript.

Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited.

Flash could have made it easy to target iPhone and Android with very similar code bases.
Now, developing for one, doesn't making porting to the other so simple.
It forces small developers to ask: bigger market or open market?

I really hope the open market (Android) wins this. I'm not looking forward to Steve Job's (similar to Bill Gates') vision of the marketplace.

Makes it harder for people to port apps to Android if they are written in Object C. Apple figures that the iPhone is priority #1 for everyone developing a mobile version, so they can use their TOS to raise the cost of supporting priority #2.

The author hints that apps built on third-party compilers are of lower quality, without explaining how/why.
This blog is a commentary on the high number of apps in the app store and Apple's desire to try to maintain quality, with a few opening sentences about the current TOS changes as link-bait.

I (the author) never state that apps built on third-party compilers are of lower quality.
It is about Apple's struggle to maintain quality, yes, since I have little interest in the specifics of the TOS change.

I think he's hinting that Apple is probably thinking that apps built on third-party compilers are lower quality.

Exactly. Sorry my writing isn't very good. English is a second language for me.

Proportionally speaking, how many good iPhone apps would have been built by clever hackers using Scheme/Lisp/Haskell/Clojure and how many shitty iPhone apps would have been built using Flash?

How many good iPhone apps have already been built with Unity, Titanium, or MonoTouch or with an embedded Lua interpreter?

This little flash game has very high production values for artwork, music, and sound. In fact, I think its quality is on a par with anything Apple ever did. The interface would be a natural for a touch interface like the iPad.
Little Wheel: http://www.kongregate.com/games/fastgames/little-wheel
There are many Flash games of comparable quality. It is a shame that such excellence will never be allowed on the iPad under the current policy.
How to kill off Flash using Market Forces
If I were Apple, I would develop a toolset to convert flash apps to an iPad compatible target along with an outreach program to encourage the migration of such apps to the iPad and the Apple App Store. If HTML5 is not robust enough, then Apple should develop a target based on Javascript or other advanced VM, taking care to ensure that a subset of the target is nearly isomorphic to Flash/Actionscript. This could be done defensibly by drawing on prior art in programming languages, and a near 1 to 1 correspondence would make most of the conversion work possible through automated translation. As a standard, HTML5 is in a better position to be the target, however.
License such an SDK stipulating that the app and its derivative works can only be published on web sites in a manner which is compatible with Mobile Safari.
The effect of such a program would be to harness a profit motive towards killing off Flash! Using such a carrot is going to work better than the stick of legal action. The latter has the side effect of making many developers like Apple and the App Store less. The former would be an opportunity to reach more users and make more money.
You can catch more flies using honey than vinegar. You can kill more of them that way as well.

And Little Wheel, good as it is, is nothing compared to the likes of Machinarium (which is $20 for PC, and worth every penny). Guess what Machinarium is written in? Flash.

I was also going to mention Machinarium. Like Little Wheel, the game interface would make for an ideal multitouch game. Solving puzzles involves tapping and dragging things in your environment.

Here's some how/why, at least as regards frameworks designed for cross-platform development.
Cross-platform frameworks push developers towards lowest-common-denominator UI design -- you can only use the UI elements and interactions that are supported on all the platforms you target. So if there's a mediocre way to do something cross-platform and a more "Apple-Like" way to do it that isn't cross-platform (or which hasn't been baked into the framework yet, assuming it ever will be) a lot of apps are going to do it the mediocre way. (This doesn't really apply to games, as they usually have their own from-scratch UIs. But for every other kind of application it's absolutely going to be an issue.)
So say CS5 comes out and suddenly there are thousands of new developers who have never written for iPhone/etc. before, who only know about the features and interactions supported by Adobe's framework, and who, because they're Flash developers (sorry for the snark but I doubt it's far removed from how Apple sees it), wouldn't know what to do with a set of human interface guidelines to save their lives. I think it's safe to say that a large percentage of these developers will be delivering apps with interfaces that would be rejected if submitted as native apps -- but which developers using the native tools (and therefore steeped in the platform's ecosystem) would never have designed in the first place.
If Apple believes something's about to happen that will result in a significantly higher percentage of rejected applications, it's far easier for them to issue a blanket ban on it today and take all the heat for that decision in one blast than it is to let the can of worms be opened and deal with a new flood of problems on a case by case basis. I don't know if this is really their thinking but we'll find out, if the developer agreement is refined in a way that allows some of the dev processes discussed in other threads here as collateral damage.
There are other issues. Say CS5 had come out a year ago, and there were thousands of Apps in the App Store that used the Adobe framework. OS4 was released to developers last week, and all the native devs have started working with it. If OS4 breaks something for them, they're going to know about it and in all likelihood have a fix out by the time OS4 streets. But if OS4 breaks something in the CS5-built apps, the developers of those apps can't do anything about it until Adobe fixes the problem. You can argue that that's the developer's fault and the developer's problem, but when the people who bought those apps switch over to OS4, those users aren't going to think "god, how stupid of the developers to rely on a third-party framework by Adobe, a company whose reputation for timely bug fixes leaves much to be desired" -- they're going to think "Hey! OS4 broke my apps!". That's Apple's problem.
That's some of it, at any rate.
(Just to be clear: I'm not arguing that Apple only did this with pure, consumer-friendly motives -- I'm sure the Adobe/Google-kneecapping implications of this decision were very prominent in their minds if not the main driver. But there are also pragmatic benefits to Apple that have nothing to do with its effect on the competition.)

Apple risks driving away anyone who was considering iPhone development as their primary source of income; it's pretty risky to put all your eggs in one basket when the owner of that basket has a habit of spilling a large portion of its contents.
What I think I'd do if I was Apple is to provide a two-tier app store. Tier 2 apps would be only be checked to see that they're not malicious or destructively buggy. Tier-1 apps would be strictly reviewed for quality and performance, and would presented to the user as such. There would be a submission fee to get an app verified as Tier-1.

It would be a better post if you explained how each piece of your advice would help the situation for apple.
For example - the $100 per year fee means that a lot of the most useless apps will disappear from the store if their authors don't want to keep paying for them to exist.

Author's points would have been valid if Apple didnt charge developers for App approval process.
But there is a developer fee, which obviously go towards approval/rejection of submitted apps. Apple's existing app approval process is more than enough to not let in crappy apps.The fee will cover extra cost arising from influx of new developers.

One thing I do not understand. The graphic design crowd is the biggest force behind Mac popularity. And "graphic design software" and "Adobe creative suite" are synonims. So Adobe has the power to inflict huge damage to the OS X platform if it wants. Isn't Apple even slightly scared of this?

When you submit an iPhone app for approval, do Apple techs look at the code? Because this restriction would make their job much easier.
I wonder if someone submits obfuscated C code, will they reject it?

I would actually like to know if there is a real difference in performance between the apps compiled from flash and those written in objective-C ?

If it was about quality, why allowing C++ ? Why disabling GC ?

Apple's approval process makes the apps worse because they circumvent the iteration cycle. Companies cannot change their product to their customers' wishes without approval from Apple.
Besides, there are other solutions to the quantity/quality problem. For example, user feedback seems to work very well, and it scales!!!

Unlike the raging Adobe employee and his blog post we all debated two days ago, this guy has his head straight on, managing to see farther than his own nose and managing to keep a perspective covering more than just his own interests.

How does he know this? It seems like a MAJOR stretch to me. If they only want to increase quality of apps why aren't they more strict in the review process? Why have they allowed 60+ fart apps? To say all Flash/Unity/Appcelerator apps are of lower quality is silly. There will be low quality and high quality Flash apps submitted but that's the whole point of the review process.
From Apple's perspective
* (+) Hurts Flash and reduces Adobe CS CS5 sales
* (+) Requires devs to purchase Apple hardware
* (+) Requires devs to develop specifically for iPhone - no ports and no develop once, deploy anywhere
* (+/-) Reduces apps submitted (includes good and bad apps)
* (-) Hurts projects like Unity3D, Appcelerator, etc
* (-) Overall negative press from software developers (my opinion)
You can pick any one of these from above and write an entire blog article. I think the main reason for this decision is that it will hurt Adobe much more than it hurts Apple. Who cares if they lose a small number of developers?

Reply on news.ycombinator.com