Good point. Apple uses a compatibility layer (Cocoa) to get iTunes and Safari to run on Windows without having to rewrite them from scratch as native applications. And they do it in a different programming language than what Windows' native APIs are written in.
Oh the Irony. And what hypocrisy!
iTunes on Windows is total mess. The UI's non-standard, and the logic in the program works in a weird way for a Windows user... I'd love to see Microsoft to ban these low quality ports.
Yes, there are layers inherently involved in programming. Apple just wants to make sure you stick to the ones they have the most control over.
I think that these are indeed Apple's intentions. And I think they're the right intentions. But I think the way Apple expresses these intentions in their developer agreement has an unintended consequence.
Apple wants your app to like like this, this is good:
iPhone OS -> UIKit -> Your App
Apple doesn't want your app to look like this, very bad:
iPhone OS -> UIKit -> [Flash, QT, etc.] -> Your App
So far so good. But the unintended consequence of how Apple phrased its agreement is that the following is also forbidden:
iPhone OS -> UIKit -> Your App <- backend implementation details written in a different language
In the last case everything the user sees and interacts with is written exclusively in Objective-C. There's no middleman. But behind the scenes the Objective-C controllers delegate to code written in another programing language that's compiled and linked natively. The final executable is indistinguishable from one that was written exclusively in Objective-C. It probably would even get through Apple's approval process, though it appears to be expressly forbidden.
I explained in a previous post why you might want or need to employ such an app structure. I think such an implementation is in line with Apple's goals for the platform. It's just an uncommon corner case that gets caught in the cross fire.
Section 3.3.1 of Apple's agreement states that "only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs." Apple should clarify what directly linking means. All code is "directly linked" in the final executable. But maybe if your app links with Apple's frameworks, and also links with your own code written in another language, but there are mp dependencies between your code in the other language and Apple's high level frameworks, this would qualify as not directly linking. As long as directly linking with absolutely fundamental libraries like libc is permitted, I'd be okay with this.
iTunes on Windows is total mess. The UI's non-standard, and the logic in the program works in a weird way for a Windows user... I'd love to see Microsoft to ban these low quality ports.
I think the same way about iTunes on Mac OS X as well.
Seriously, try to manually arrange your library, copy your content machine to machine. Arrange things (add metadata), then move that. Plus it was written in Carbon -- they hate Carbon for everyone else, then use it themselves. etc., etc.
Ten years of delayed movement to Cocoa and now Adobe fans are crying wolf?
Deal with it.
You either want to make a ton of money on the mobile platforms and even solid returns on the laptop/desktop as it continues to expand or you just want to target the laptop/desktop markets.
I'm not a developer or software writer, but from what I've heard, Flash can be used to introduce viruses to PCs. If true, then theoretically it could introduce viruses to the iPhone OS, thus making the user experience an unpleasant exercise like PCs have become.
Do you have the Flash plugin on your Mac?
A few million others do.
Has that turned your Mac into a virus-laden zombie?
I'm not a big fan of Flash, but I care for FUD even less.
You all know that there are hundreds of apps at apple app store that essentially do the same thing, most of those are ported (so written by developers in a different language) and many of them perform just BAD. Why have such a thing?
Ask Apple. They approve a lot of merde that was made with their own dictated tools.
Whether an app is good or bad isn't a function of how low-level the language is that it was written with. It's not a question of programming, but one of design.
In fact, the higher productivity from RAD tools favor good design by freeing the developer from the tedium of bit-counting and letting them spend more of their time and attention on the user interface.
Quote:
Originally Posted by Soskok
P.S. some times to have a choice is bad, dont forget it.
Apple wants your app to like like this, this is good:
Code:
iPhone OS -> UIKit -> Your App
Apple doesn't want your app to look like this, very bad:
Code:
iPhone OS -> UIKit -> <Flash, QT, etc.> -> Your App
Problem. All good code looks more like this:
Code:
iPhone Kernel -> iPhone Abstaction A,B or C -> UIKit -> Your App
But your App breaks down into:
Code:
Your App Library -> Your App OOD-> Your App UI
And so on.
Sometimes you put abstractions on top of things like OpenGL or OpenCL. Sometimes you're building/including libraries to interpret XML. Sometimes you doing something like Excel, where you create your own language to interpret cells. (Apple's Numbers will violate their own terms, because they have their own language in there). And so on.
It is arbitrary.
They used to say FORTRAN programmers can write FORTRAN in any language. (back in the FORTRAN4 days). The point being that you can write bad code in any language. The language is NOT an indication of quality. This is something that any 1st year programmer knows, except Apple.
Pleeeeeease.... we have been through this a gazillion times in these threads, and you should not be contributing to FUD.
Gross margin (which is what you are referring to here) ≠ Profit margin. Apple's profit margin is ~20%, well in line with other successful companies, and much lower than companies such as Google (~30%) and MSFT (~35%).
Even with that, saying that Apple is not about making money (what original poster claimed) is ridiculous... as it would be for any other corporation. And last time I've checked, Apple was a corporation - not a humanitarian, non-profitable institution.
We all know what's really going on here. Jobs has a vendetta against Adobe. This has nothing to do with what is good for the end user. Let the market figure that one out. That's how capitalism works. If your app sucks, people won't buy it. If its great, and its built with Flash, good for you.
Makes me think its quite possible to write excellent apps for the iPad using Adobe technologies.
And, the fact is that Adobe is very entrenched in the publishing world. If the iPad is supposed to save publishing, then the designers should be able to use tools that fit well into their existing work-flows. These Photoshop guys aren't going to run out and learn HTML5.
This is a draconian measure that is going to stifle innovation...
If you want to write for just iPhone, there's a productivity advantage to using higher-level languages, and that advantage multiplies logarithmically when you want to deploy to multiple devices.
If you've ever pondered the millions of man-hours lost every year to bugs caused by the difference between "=" and "==" you know what I mean, and if you haven't there are plenty of papers describing the productivity advantages of modern high-level languages for applications programming.
While some like to point out that Apple is the leading smart phone manufacturer, they're overlooking that other OSes run on devices from multiple manufacturers.
Android and most other mobile OSes don't dictate what language you can use. They don't care, the more the merrier as long as it lets you deliver the goods.
The only reason Apple has more apps today is that most of the mobile RAD tools in the pipeline aren't shipping yet. Once they do, we can expect to see an explosion of app development.
With any of those tools you can write and maintain a single code base for 75% of the mobile market.
It could be 100%, but Jobs is devolving into Gates so developers will have to be satisfied with bypassing the iPhone until he comes around.
In the meantime, Jobs has given Android the biggest gift ever: thousands of developers using high-productivity RAD tools.
Jobs' excuse that everyone at Apple suddenly forgot how to write APIs to handle threads effectively for their multitasking simply doesn't hold water. What he's after is control, pure and simple, and he's got just enough hubris to believe that his 25% market share can reverse the tide of history which increasingly favors RAD tools.
I get your point. But why is it the platform? Because that's where they say it is. This is all arbitrary. Software Engineers know better.
It's the platform because that's the platform they created. This is really a tautology.
Quote:
Too late. They just did. They said "the ones we like are the only ones you can use.
No, they said use the ones we created for the platform, see above.
Quote:
To say "Flash Sucks" shows ignorant of software development. Flash is a tool. Do we argue "a screwdriver sucks? It does at pounding nails or cutting wood -- for driving screws, it isn't that bad.
Some screwdrivers just suck. And using a phillips head screwdriver on flat head screws rarely works well.
I think that these are indeed Apple's intentions. And I think they're the right intentions. But I think the way Apple expresses these intentions in their developer agreement has an unintended consequence.
Apple wants your app to like like this, this is good:
iPhone OS -> UIKit -> Your App
Apple doesn't want your app to look like this, very bad:
iPhone OS -> UIKit -> [Flash, QT, etc.] -> Your App
So far so good. But the unintended consequence of how Apple phrased its agreement is that the following is also forbidden:
iPhone OS -> UIKit -> Your App <- backend implementation details written in a different language
In the last case everything the user sees and interacts with is written exclusively in Objective-C. There's no middleman. But behind the scenes the Objective-C controllers delegate to code written in another programing language that's compiled and linked natively. The final executable is indistinguishable from one that was written exclusively in Objective-C. It probably would even get through Apple's approval process, though it appears to be expressly forbidden.
I explained in a previous post why you might want or need to employ such an app structure. I think such an implementation is in line with Apple's goals for the platform. It's just an uncommon corner case that gets caught in the cross fire.
Section 3.3.1 of Apple's agreement states that "only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs." Apple should clarify what directly linking means. All code is "directly linked" in the final executable. But maybe if your app links with Apple's frameworks, and also links with your own code written in another language, but there are mp dependencies between your code in the other language and Apple's high level frameworks, this would qualify as not directly linking. As long as directly linking with absolutely fundamental libraries like libc is permitted, I'd be okay with this.
I see your point, and I happen to agree with you on what should be allowed. If none of your code in the alternate language relies specifically on Apple's frameworks, then it doesn't seem that you are using any kind of compatibility layer with their platform. The UI code is written using their APIs, while it seems the computationally complex Scala part is fully encapsulated by your C/C++/Objective C code without any calls back to iPhone APIs within said Scala code (please correct me if I misunderstood). The issue of direct linking is the final sticking point, but hopefully they see it the same way if you decide to submit your application in its current state. I would be very interested to hear the verdict, by the way, because I can envision myself using a similar structure sometime in the future if they allow it. Good luck to you.
Makes me think its quite possible to write excellent apps for the iPad using Adobe technologies.
And, the fact is that Adobe is very entrenched in the publishing world...
I think you're hitting the nail on the head.
If you're Apple and you want to lock publishers into a proprietary DRM, and make them write a custom solution for just your platform, then what's the worst thing that could happen? That they could have better tools that works cross-platform and is easier for them to implement (integrates with their publishing workflows).
Since Flash/Air works better for publishers, it weakens Apple's power over them.
So this isn't about Apple's power over Adobe. This is about Apple's power over the Publishers.
If Publishers can use Adobe's tools to publish to ANY iPad like device, then Apple can't bully them into their costs/policies as much. Adobe's just stuck in the middle by daring to help Publishers too much.
It's amazing how much whining is done over Apple. I keep thinking "why not shut the hell up, change your diaper and buy a competitor's product?" It's especially annoying to see forum twits whine about Apple stopping 'innovation' when they've never done anything of consequence. That should be an automatic 5 across the eyes, probably should cost them a few teeth.
This entitlement mentality is weak intellectually and ultimately a cowardly dodge of personal responsibility. I think it's a way talentless people bolster their own lack of motivation and hide their deep insecurities. Apple isn't your problem folks, you need to get on the Cialis forums and complain about your issues there.
Well then, it sounds like the JooJoo would be the perfect platform for both you and the developer. The JooJoo was built from the ground up, has none of the evil restrictions that the evil Apple and even more evil Steven P. Jobs impose and require. There should be plenty of JooJoos available for sale. Problem solved.
No, I just don't automatically assume Apple is always in the right...because that would be as dumb as assuming they are always wrong.
this to me is a bollocks, non issue, if it were pretty much anyone else other than apple no one would be on their case, because no one would care. If it had been apple circa 1999 no one would be on apple's back either, because no one would be threatened.
Now apple as much as sneezes and we have a ton of pundits commenting on it.
Since Flash/Air works better for publishers, it weakens Apple's power over them.
So this isn't about Apple's power over Adobe. This is about Apple's power over the Publishers.
Interesting. Do you really think Apple needs to do that? I mean, they didn't insist that studios edit all movies with FinalCut in order for them to be sold in the iTunes store...
But who knows, maybe they would have if they could have gotten away with it!
Then they could start dictating movie plots and product placement... "We've found that movies that feature images of non Apple computing devices result in an inferior experience for the audience." "We've found that movies where the bad-guys use Macs generate confusion in the minds of our customers."
Comments
No, there is no hypocrisy or double standards or foul play, Will it be harder to port, yes, but that's not the motivation here.
No, it's fairly clear to most that the decision is to lock developers in.
Good point. Apple uses a compatibility layer (Cocoa) to get iTunes and Safari to run on Windows without having to rewrite them from scratch as native applications. And they do it in a different programming language than what Windows' native APIs are written in.
Oh the Irony. And what hypocrisy!
iTunes on Windows is total mess. The UI's non-standard, and the logic in the program works in a weird way for a Windows user... I'd love to see Microsoft to ban these low quality ports.
Yes, there are layers inherently involved in programming. Apple just wants to make sure you stick to the ones they have the most control over.
I think that these are indeed Apple's intentions. And I think they're the right intentions. But I think the way Apple expresses these intentions in their developer agreement has an unintended consequence.
Apple wants your app to like like this, this is good:
iPhone OS -> UIKit -> Your App
Apple doesn't want your app to look like this, very bad:
iPhone OS -> UIKit -> [Flash, QT, etc.] -> Your App
So far so good. But the unintended consequence of how Apple phrased its agreement is that the following is also forbidden:
iPhone OS -> UIKit -> Your App <- backend implementation details written in a different language
In the last case everything the user sees and interacts with is written exclusively in Objective-C. There's no middleman. But behind the scenes the Objective-C controllers delegate to code written in another programing language that's compiled and linked natively. The final executable is indistinguishable from one that was written exclusively in Objective-C. It probably would even get through Apple's approval process, though it appears to be expressly forbidden.
I explained in a previous post why you might want or need to employ such an app structure. I think such an implementation is in line with Apple's goals for the platform. It's just an uncommon corner case that gets caught in the cross fire.
Section 3.3.1 of Apple's agreement states that "only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs." Apple should clarify what directly linking means. All code is "directly linked" in the final executable. But maybe if your app links with Apple's frameworks, and also links with your own code written in another language, but there are mp dependencies between your code in the other language and Apple's high level frameworks, this would qualify as not directly linking. As long as directly linking with absolutely fundamental libraries like libc is permitted, I'd be okay with this.
iTunes on Windows is total mess. The UI's non-standard, and the logic in the program works in a weird way for a Windows user... I'd love to see Microsoft to ban these low quality ports.
I think the same way about iTunes on Mac OS X as well.
Seriously, try to manually arrange your library, copy your content machine to machine. Arrange things (add metadata), then move that. Plus it was written in Carbon -- they hate Carbon for everyone else, then use it themselves. etc., etc.
Deal with it.
You either want to make a ton of money on the mobile platforms and even solid returns on the laptop/desktop as it continues to expand or you just want to target the laptop/desktop markets.
I'm not a developer or software writer, but from what I've heard, Flash can be used to introduce viruses to PCs. If true, then theoretically it could introduce viruses to the iPhone OS, thus making the user experience an unpleasant exercise like PCs have become.
Do you have the Flash plugin on your Mac?
A few million others do.
Has that turned your Mac into a virus-laden zombie?
I'm not a big fan of Flash, but I care for FUD even less.
Well if it's not, it darn looks like it is. I didn't have chance to sit with SJ and discuss that in private, though. Have you?
He's been pretty clear in his email about the motivations (pointing to Grubers article) and they are really pretty obvious to an intelligent observer.
You all know that there are hundreds of apps at apple app store that essentially do the same thing, most of those are ported (so written by developers in a different language) and many of them perform just BAD. Why have such a thing?
Ask Apple. They approve a lot of merde that was made with their own dictated tools.
Whether an app is good or bad isn't a function of how low-level the language is that it was written with. It's not a question of programming, but one of design.
In fact, the higher productivity from RAD tools favor good design by freeing the developer from the tedium of bit-counting and letting them spend more of their time and attention on the user interface.
P.S. some times to have a choice is bad, dont forget it.
When, specifically?
Apple wants your app to like like this, this is good:
iPhone OS -> UIKit -> Your App
Apple doesn't want your app to look like this, very bad:
iPhone OS -> UIKit -> <Flash, QT, etc.> -> Your App
Problem. All good code looks more like this:
iPhone Kernel -> iPhone Abstaction A,B or C -> UIKit -> Your App
But your App breaks down into:
Your App Library -> Your App OOD-> Your App UI
And so on.
Sometimes you put abstractions on top of things like OpenGL or OpenCL. Sometimes you're building/including libraries to interpret XML. Sometimes you doing something like Excel, where you create your own language to interpret cells. (Apple's Numbers will violate their own terms, because they have their own language in there). And so on.
It is arbitrary.
They used to say FORTRAN programmers can write FORTRAN in any language. (back in the FORTRAN4 days). The point being that you can write bad code in any language. The language is NOT an indication of quality. This is something that any 1st year programmer knows, except Apple.
Pleeeeeease.... we have been through this a gazillion times in these threads, and you should not be contributing to FUD.
Gross margin (which is what you are referring to here) ≠ Profit margin. Apple's profit margin is ~20%, well in line with other successful companies, and much lower than companies such as Google (~30%) and MSFT (~35%).
Even with that, saying that Apple is not about making money (what original poster claimed) is ridiculous... as it would be for any other corporation. And last time I've checked, Apple was a corporation - not a humanitarian, non-profitable institution.
Ten years of delayed movement to Cocoa and now Adobe fans are crying wolf?
How does this vaguely relate?
Why aren't you complaining that Apple hasn't moved FinalCut, iTunes or QuickTime over?
This video: http://www.youtube.com/watch?v=wwFbwHaP5tE
Makes me think its quite possible to write excellent apps for the iPad using Adobe technologies.
And, the fact is that Adobe is very entrenched in the publishing world. If the iPad is supposed to save publishing, then the designers should be able to use tools that fit well into their existing work-flows. These Photoshop guys aren't going to run out and learn HTML5.
This is a draconian measure that is going to stifle innovation...
It boils down to one: productivity.
If you want to write for just iPhone, there's a productivity advantage to using higher-level languages, and that advantage multiplies logarithmically when you want to deploy to multiple devices.
If you've ever pondered the millions of man-hours lost every year to bugs caused by the difference between "=" and "==" you know what I mean, and if you haven't there are plenty of papers describing the productivity advantages of modern high-level languages for applications programming.
While some like to point out that Apple is the leading smart phone manufacturer, they're overlooking that other OSes run on devices from multiple manufacturers.
Take a look at these stats:
http://techcrunch.com/2010/04/05/com...on-the-iphone/
In terms of subscribers per OS, Apple is #3 with about one-fourth of the market.
Gartner says it'll be that way for Apple for a while, as Android eclipses them:
http://www.computerworld.com/s/artic...2_says_Gartner
Android and most other mobile OSes don't dictate what language you can use. They don't care, the more the merrier as long as it lets you deliver the goods.
The only reason Apple has more apps today is that most of the mobile RAD tools in the pipeline aren't shipping yet. Once they do, we can expect to see an explosion of app development.
With any of those tools you can write and maintain a single code base for 75% of the mobile market.
It could be 100%, but Jobs is devolving into Gates so developers will have to be satisfied with bypassing the iPhone until he comes around.
In the meantime, Jobs has given Android the biggest gift ever: thousands of developers using high-productivity RAD tools.
Jobs' excuse that everyone at Apple suddenly forgot how to write APIs to handle threads effectively for their multitasking simply doesn't hold water. What he's after is control, pure and simple, and he's got just enough hubris to believe that his 25% market share can reverse the tide of history which increasingly favors RAD tools.
Great post, mate.
I get your point. But why is it the platform? Because that's where they say it is. This is all arbitrary. Software Engineers know better.
It's the platform because that's the platform they created. This is really a tautology.
Too late. They just did. They said "the ones we like are the only ones you can use.
No, they said use the ones we created for the platform, see above.
To say "Flash Sucks" shows ignorant of software development. Flash is a tool. Do we argue "a screwdriver sucks? It does at pounding nails or cutting wood -- for driving screws, it isn't that bad.
Some screwdrivers just suck. And using a phillips head screwdriver on flat head screws rarely works well.
I think that these are indeed Apple's intentions. And I think they're the right intentions. But I think the way Apple expresses these intentions in their developer agreement has an unintended consequence.
Apple wants your app to like like this, this is good:
iPhone OS -> UIKit -> Your App
Apple doesn't want your app to look like this, very bad:
iPhone OS -> UIKit -> [Flash, QT, etc.] -> Your App
So far so good. But the unintended consequence of how Apple phrased its agreement is that the following is also forbidden:
iPhone OS -> UIKit -> Your App <- backend implementation details written in a different language
In the last case everything the user sees and interacts with is written exclusively in Objective-C. There's no middleman. But behind the scenes the Objective-C controllers delegate to code written in another programing language that's compiled and linked natively. The final executable is indistinguishable from one that was written exclusively in Objective-C. It probably would even get through Apple's approval process, though it appears to be expressly forbidden.
I explained in a previous post why you might want or need to employ such an app structure. I think such an implementation is in line with Apple's goals for the platform. It's just an uncommon corner case that gets caught in the cross fire.
Section 3.3.1 of Apple's agreement states that "only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs." Apple should clarify what directly linking means. All code is "directly linked" in the final executable. But maybe if your app links with Apple's frameworks, and also links with your own code written in another language, but there are mp dependencies between your code in the other language and Apple's high level frameworks, this would qualify as not directly linking. As long as directly linking with absolutely fundamental libraries like libc is permitted, I'd be okay with this.
I see your point, and I happen to agree with you on what should be allowed. If none of your code in the alternate language relies specifically on Apple's frameworks, then it doesn't seem that you are using any kind of compatibility layer with their platform. The UI code is written using their APIs, while it seems the computationally complex Scala part is fully encapsulated by your C/C++/Objective C code without any calls back to iPhone APIs within said Scala code (please correct me if I misunderstood). The issue of direct linking is the final sticking point, but hopefully they see it the same way if you decide to submit your application in its current state. I would be very interested to hear the verdict, by the way, because I can envision myself using a similar structure sometime in the future if they allow it. Good luck to you.
This video: http://www.youtube.com/watch?v=wwFbwHaP5tE
Makes me think its quite possible to write excellent apps for the iPad using Adobe technologies.
And, the fact is that Adobe is very entrenched in the publishing world...
I think you're hitting the nail on the head.
If you're Apple and you want to lock publishers into a proprietary DRM, and make them write a custom solution for just your platform, then what's the worst thing that could happen? That they could have better tools that works cross-platform and is easier for them to implement (integrates with their publishing workflows).
Since Flash/Air works better for publishers, it weakens Apple's power over them.
So this isn't about Apple's power over Adobe. This is about Apple's power over the Publishers.
If Publishers can use Adobe's tools to publish to ANY iPad like device, then Apple can't bully them into their costs/policies as much. Adobe's just stuck in the middle by daring to help Publishers too much.
It's amazing how much whining is done over Apple. I keep thinking "why not shut the hell up, change your diaper and buy a competitor's product?" It's especially annoying to see forum twits whine about Apple stopping 'innovation' when they've never done anything of consequence. That should be an automatic 5 across the eyes, probably should cost them a few teeth.
This entitlement mentality is weak intellectually and ultimately a cowardly dodge of personal responsibility. I think it's a way talentless people bolster their own lack of motivation and hide their deep insecurities. Apple isn't your problem folks, you need to get on the Cialis forums and complain about your issues there.
wow...
Well then, it sounds like the JooJoo would be the perfect platform for both you and the developer. The JooJoo was built from the ground up, has none of the evil restrictions that the evil Apple and even more evil Steven P. Jobs impose and require. There should be plenty of JooJoos available for sale. Problem solved.
No, I just don't automatically assume Apple is always in the right...because that would be as dumb as assuming they are always wrong.
Now apple as much as sneezes and we have a ton of pundits commenting on it.
Since Flash/Air works better for publishers, it weakens Apple's power over them.
So this isn't about Apple's power over Adobe. This is about Apple's power over the Publishers.
Interesting. Do you really think Apple needs to do that? I mean, they didn't insist that studios edit all movies with FinalCut in order for them to be sold in the iTunes store...
But who knows, maybe they would have if they could have gotten away with it!
Then they could start dictating movie plots and product placement... "We've found that movies that feature images of non Apple computing devices result in an inferior experience for the audience." "We've found that movies where the bad-guys use Macs generate confusion in the minds of our customers."