

Middleware and Section 3.3.1 - mrshoe
http://daringfireball.net/2010/04/middleware_and_section_311

======
cageface
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.

~~~
thought_alarm
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
But the influx of crappy iFart apps is O.K.?

~~~
thought_alarm
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.

------
tjr
_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?

~~~
wmf
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.

~~~
natrius
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.

~~~
roc
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?

~~~
natrius
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.

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

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

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

~~~
aero142
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.

~~~
dmnd
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.

~~~
webXL
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?

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

~~~
biafra
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?

~~~
contextfree
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.

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

------
ryoshu
"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...](http://blogs.adobe.com/cantrell/archives/2010/04/one_application_five_screens.html)

~~~
bonaldi
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.

