6 ms·

Middleware and Section 3.3.1

56 points by mrshoe 16y ago

tjr 16y 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?
- wmf 16y 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.
  - natrius 16y 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.
    - roc 16y ago
      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 16y ago
        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.
- jsz0 16y 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.
greendestiny 16y 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.
- wmf 16y ago
  I think Gruber's point is that regular Mac apps could be ported to Carbon relatively easily, but PowerPlant apps couldn't.
  - aero142 16y 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.
    - dmnd 16y ago
      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.
      - greendestiny 16y ago
        That's very unlikely to be true these days, almost all frameworks are designed to be extensible.
      - webXL 16y ago
        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?
      - 16y ago
deleted 16y ago
[deleted]
tel 16y 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.
cageface 16y 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.
- gabrielroth 16y 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?
  - cageface 16y 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.
    - 16y ago
biafra 16y 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 16y 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.
  - biafra 16y 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?
    - contextfree 16y ago
      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.
  - barrkel 16y 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 16y 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_application_five_screens.html http://blogs.adobe.com/cantrell/archives/2010/04/one_applica...
- bonaldi 16y 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 16y 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 16y 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.

56 points by mrshoe 16y ago

tjr 16y 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?

wmf 16y 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.
- natrius 16y 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.
  - roc 16y ago
    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 16y ago
      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.
jsz0 16y 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.

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

wmf 16y ago
I think Gruber's point is that regular Mac apps could be ported to Carbon relatively easily, but PowerPlant apps couldn't.
- aero142 16y 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.
  - dmnd 16y ago
    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.
    - greendestiny 16y ago
      That's very unlikely to be true these days, almost all frameworks are designed to be extensible.
    - webXL 16y ago
      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?
    - 16y ago

deleted 16y ago

[deleted]

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

cageface 16y 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.

gabrielroth 16y 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?
- cageface 16y 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.
  - 16y ago

biafra 16y 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 16y 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.
- biafra 16y 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?
  - contextfree 16y ago
    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.
- barrkel 16y 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 16y 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_application_five_screens.html http://blogs.adobe.com/cantrell/archives/2010/04/one_applica...

bonaldi 16y 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 16y 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 16y 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.