Middleware and Section 3.3.1

http://daringfireball.net/2010/04/middleware_and_section_311

by mrshoe • 16 years ago

56 31 16 years ago

tjr• 16 years ago

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?

wmf2• 16 years ago

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.

natrius2• 16 years ago

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.

jsz0• 16 years ago

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.

greendestiny2• 16 years ago

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.

wmf2• 16 years ago

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

aero142• 16 years ago

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.

tel• 16 years ago

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.

cageface2• 16 years ago

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.

gabrielroth2• 16 years ago

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?

cageface2• 16 years ago

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.

thought_alarm2• 16 years ago

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.

theBobMcCormick• 16 years ago

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

biafra2• 16 years ago

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

jstevens85• 16 years ago

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.

biafra2• 16 years ago

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?

barrkel2• 16 years ago

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.

ryoshu• 16 years ago

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

marbletiles• 16 years ago

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.

dedward• 16 years ago

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.

Tichy• 16 years ago

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.

Middleware and Section 3.3.1

Related Stories