Middleware and Section 3.3.1 | Hacker News Reader

Middleware and Section 3.3.1

daringfireball.net

56 pointsmrshoe31 comments

It really has been an education watching all the Apple shills stumbling over each other in their rush to defend this transparently absurd claim. Nobody has shown more reckless disregard for backward compatibility than Apple in the modern Jobs era. The idea that they'd let the discomfort of any number of Mono or Flash developers hold back their plans is ludicrous in light of their breakneck pace of incompatible change.

The loads of shovelware in the app store put the lie to the quality claim so let's just focus on what's right in front of our faces. This is all about raising the barrier to writing cross-platform apps and locking down Apple's control in the emerging mobile computing market. The dishonesty with which this naked power grab is sweetened has a positively Soviet flavor.

Write-once, run-anywhere is a lie.

If Apple wanted to really hurt their developers, they would allow the App Store to be ruined. Flash developers are not entitled to placement in the App Store, and there isn't a single App Store developer who would look forward to an influx crappy Flash apps.

You can talk about hypothetical scenarios all you want, but as long as the iPhone and the App Store remain immensely popular with developers and users it's very hard to argue that Apple is doing it wrong.

But the influx of crappy iFart apps is O.K.?

Not it's not. You obviously don't understand how the App Store works or the lengths some developers and marketers go to abuse and game the App Store.

That's why Apple has taken a number of steps to curb the abuse and help promote serious higher-priced apps over the volume of 99-cent apps. It's what developers want and it's what users want. Yet the peanut gallery always howls at these App Store "restrictions".

Like I said, as long as Apple continues to manage the App Store properly it will continue to be immensely popular with developers and users. And the people who don't understand it will continue to criticize it.

Nobody has shown more reckless disregard for backward compatibility than Apple in the modern Jobs era.

Well, their record on backward compatibility is mixed -- Carbon, Classic, and Rosetta spring to mind -- but let's stipulate that the above is true. Apple has been able to make major changes to its platform because they're not beholden to any incumbent developers. Microsoft and Adobe have a certain amount of sway, but not enough to keep Apple from improving the platform.

Now they're trying to extend that independence into the iPhone/iPad era. What's dishonest about any of this?

So I'm supposed to believe that Apple was prepared to force all its developers to do two complete rewrites (os 9 -> os x, carbon -> cocoa) and port to a new ISA and break compatibilities across every one of its 10.x releases but they're just too polite to tell a bunch of Flash developers to get stuffed if their Flash app breaks in the next iPhone release. Remember, these will, by definition, be apps of inferior quality since they're not Obj-C so it's even less plausible that Apple will worry about breaking them, if you take them at their word.

Ask any developer of audio units, for example, how worried Apple is about forcing them to rewrite code every time there's a new Logic release.

just too polite to tell a bunch of Flash developers to get stuffed

Nobody said anything about politeness. Where is Apple pretending that this policy is about anything other than maintaining control of the platform?

The fear isn't that they'd have to be rude. The fear is that, if Flash apps for iPhone/iPad became a huge successful popular segment of the market and Flash didn't keep up with iPhone OS, users would have to choose between not upgrading and breaking their apps. Apple doesn't want that. Therefore, no Flash.

It's a policy that's better for some people (e.g. Cocoa Touch developers) and worse for other people (e.g. Flash developers). Some users will prefer it this way; other users would be happier the other way. But the decision is made by Apple, and Apple's making the decision based on its perception of its own interests, and no one is claiming any different.

It's fine for you to object to the policy, but I really don't understand the accusations of hypocrisy.

but they're just too polite to tell a bunch of Flash developers to get stuffed if their Flash app breaks in the next iPhone release.

They don't give a damn about most developers: what they don't want is a whole bunch of pissed-off customers whose games (and other apps) broke when they upgraded to iPhone OS 5.0, because Adobe didn't get around to it.

Yes, MonoTouch is keeping up to date with Apple’s native APIs today, but what happens three, four, five years from now if MonoTouch stops keeping up and hundreds (or thousands) of popular iPhone OS apps are dependent upon it? That’s the scenario Apple wants to avoid.

I for one have a couple of applications currently on the iTunes store that I haven't updated in a year, and have no short-term plans to update. Provided they continue to run on upcoming iPhone operating systems, how would these "100% pure Objective-C iPhone SDK" programs be any different for the iPhone app ecology than writing a C# program using outdated SDK bindings?

The difference is that you could update those apps if you want to. Your laziness affects your app; Miguel's hypothetical future laziness affects thousands of apps.

Metrowerks PowerPlant wasn't open source. MonoTouch is. If Miguel gets lazy, you can still update your apps as long as you aren't lazy.

If you had the time/resources/expertise/inclination to support and extend the entire stack yourself, why would you have used the middle-ware to begin with?

My understanding is that there are plenty of MonoTouch users out there, and the work required to keep the project up to date doesn't seem huge. iPad support took them 24 hours to implement. I don't think likelihood of stagnation is significant.

Apple's App Store policies are constantly evolving so who knows? Maybe they'll purge abandoned apps at some point for exactly the same reason.

A key point to keep in mind in this whole debate it mentioned here. There's an assumption on Apple's part that these new platforms are so infant that they're certainly going to be doing major transformations over the next few years. That sort of lends a bit more credence to the demand for control.

How is Metrowerk's Powerplant the horror story? Any apps programmed using the classic Mac OS APIs were just as incompatible come OSX.

Are we seriously talking about Apps not being updated with the latest features five years down the track as a reason to ban middleware? Those Apps aren't going to be updated anyway, and if they are they'll probably need a complete rewrite anyway.

I think Gruber's point is that regular Mac apps could be ported to Carbon relatively easily, but PowerPlant apps couldn't.

I agree that is what he is saying, but as far as I can tell, that is crap. What is so magical about native apis? If a middleware application calls an api and it changes, it breaks, but the same is true for a native application.

An author of a native application can update the app himself. An author of an app which is dependent on middleware must wait until the middleware is updated.

And in either case, the author needs to be involved. From an end-user perspective, there's one or two parties that could prevent my app working on a new OS version. So don't you always run that risk when you buy software from a small vendor?

Getting all the applications that work with any given middleware piece is easier than getting all applications working, which each use their own idiosyncratic home-baked middle layers. These common bits of middleware reduce the number of moving parts.

That Apple needs to work hard to keep applications working - well, that's what it's like when you're a popular platform vendor. Ask MS how hard they had to work to get DOS and Win 3.1 apps running on Windows 95. That's the way the game is played when you're playing in the major league.

That's very unlikely to be true these days, almost all frameworks are designed to be extensible.

"MonoTouch is not in the same boat as Flash’s iPhone compiler, as it’s not a cross-platform framework."

Did Gruber read Section 3.3.1? It says: "Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine"[...]

Section 3.3.1 does not talk about frameworks, it's about programming languages.

Gruber didn't say that MonoTouch would be compatible with Section 3.3.1.

>MonoTouch is not in the same boat as Flash’s iPhone compiler, as it’s not a cross-platform framework. It’s a lighter shade of gray, if you will. But it’s still a layer of middleware between developers and Apple’s own APIs. Yes, MonoTouch is keeping up to date with Apple’s native APIs today, but what happens three, four, five years from now if MonoTouch stops keeping up and hundreds (or thousands) of popular iPhone OS apps are dependent upon it? That’s the scenario Apple wants to avoid.

He said it's not clear, that it's a different shade of grey.

But it's not. It's clear as day, it's black and white: MonoTouch is not compliant with 3.3.1 in so far as MonoTouch is used with a language that is not C, C++ or Objective C.

He is implying it could be compatible: "Flash’s cross-compiler, we know, is explicitly ruled out by the new Section 3.3.1. Where MonoTouch stands, however, is not yet clear."

Or isn't he?

How is Flash explicitly ruled out and C# is not?

They both are. I think he may have meant that under the conjecture that Apple intends to selectively enforce this, they might be less inclined to exclude Monotouch apps in practice.

Insightful - I would say that in the past, however, on OSX, Apple LET metrowerks get that popular, rather than keeping their own IDE and build system take over.... they're trying to counter that this time.

I don't get it. That would assume that developers are too stupid to select the right tool for the job by themselves. On the other hand, it is supposed to improve the quality of apps. So you help stupid developers, which leads to a higher proportion of stupid developers on the app store - how does that help quality?

Smart developers should be able to evaluate a framework for themselves, and even use native interfaces to extend existing frameworks if some required functionality is missing. Some of the middleware might even be open source.

It's not even worth arguing about. I don't need anybody to tell me what is the best tool for my job. If they want, educate me, advertise why their tool is the best, etc. But don't force me to do something because they assume they know better than I do what is good for myself (and my app).

I can't imagine why any argument could convince me that it is for my own good to enforce a certain tool. All that is being said, features not being available etc., might weigh in for my decision for a specific tool. But it can never be a reason for such an enforcement.

"For example, when Apple introduced in iPhone OS 3.2 the new split views that the iPad uses extensively when rotating your screen, that functionality would have taken too long to bring in a satisfactory way to say Silverlight on iPhone or Flash on iPhone."

Really? http://blogs.adobe.com/cantrell/archives/2010/04/one_applica...

Yes. All that link shows is the same app running on lots of different screen sizes, with no concessions to the local device beyond resizing the same layout. It's lowest-common-denominator in action, really.

The iPad split views are completely different: when the device is in landscape mode two separate views are side-by-side, when it is moved to portrait one view becomes main and the other hides under a button.

If you're using UIKit it does all this for you, for free. But if a Flash dev wanted it, they'd have to roll their own, or wait for CS6, when Adobe might implement it for them. Either way, take up of the new interface would be massively delayed while Apple waited for Adobe.

Apple's done with waiting for Adobe.

Reply on news.ycombinator.com