How did you get that? What I meant was that if developers were developing using the XCode tools then a lot of the work needed to do things would already be handled by the APIs which Apple has refined for the minimal specs of the devices. Why reinvent the wheel when Apple's already given you one with less weight?
Great. So when Adobe implements it, they can just call those APIs too. If they don't do that, their stuff will be noticably slower... But that is exactly the point I was making: Nothing prevents an XCode guy from doing exactly the same thing, nothing makes bad programmers into good programmers. If they want to enforce quality standards, they are free to do so. But restricting dev tools does not accomplish that goal. It is simply anti-competitive.
Quote:
It's running on devices with at least 128MB RAM and 600MHz processors. It doesn't take a rocket scientist to realise that programming methods used on desktop and laptops aren't going to work on a mobile device.
Does the operating system suddenly fail to enforce the firewall between OS and app just because it is a mobile device? Is the OS now incapable of releasing all the resources held when an app quits or is terminated? The answer is NO. Therefore, your original statement makes no sense. If you think it does make sense, perhaps you should explain with a tangible example why what you said makes sense. The only real difference is that CPU isn't free on mobile. Everything else is just a matter of scale.
Snow Leopard showed a reversal of that idea when they removed GBs of space from the OS. Admittedly a lot of that was due to removing PPC code and printer drivers but it's a bog step in the right direction. Less is more. Less superfluous code equals more refined code more refined code means less resources required less resources required means more resources for doing work.
No, PPC code was hardly removed from Snow Leopard. Go check it out yourself with the 'file' command. You'll find all the libraries are still there. If it wasn't, Rosetta wouldn't work. The biggest gain in Snow Leopard was that Apple undid a packaging mistake they made with Leopard. I don't remember the exact detail, but they accidentally included a lot more 'resources' in the builds of each App than were necessary. Apparently they couldn't undo it once it had shipped, or didn't think it was a good idea.
Quote:
Originally Posted by Dick Applebaum
Even if your last statement is true... isn't that what business is about?
To some extent. My main issue is with the attempt to cover Apple's nearly unprecedented actions with the fig-leaf of technical necessity. The rest of it, is that at some point(and that point may be now) there is a case for restraint of trade against Apple.
And your reply to the original poster is correct. I really wish Daniel Eran Dilger knew what he was writing about and did not write front page articles based on incorrect information.
A valid argument.. if garbage collection was the issue. Which it isn't. But maybe you can email Apple PR (don't forget to CC: AI) and give them the tip.
If GC CPU/power drain was the problem, the solution is you run it less often. Or create and discard less objects. It is not a big issue for the typical crApp. Java does require garbage collection, but it is provided by the Java VM (aka runtime). The cost, as you noted, is in occasional CPU use or increased memory footprint. The increased memory footprint allows less frequent execution of the garbage collector, compared to an equal load with less spare memory.
This is all true... but Apple is trying to maximize the performance, footprint, battery use, etc. of apps. Everything they can do to eliminate cycles is a potential improvement.
The logical extension to your position that you can reduce GC overhead by doing it less often, or discarding less objects... is to eliminate GC altogether.
That's what Apple decided was in the best interest, for now, of iPhone OS.
Me, as a playtime developer, it would be a lot easier to the the system do GC. But Apple doesn't support it in iPhone OS... their game, their rules! If I don't like it, I go to a different game!
This does not prevent porting of apps / multi-platform development
Unless you want to limit yourself purely to iPhone dev you are better off primarily using C/C++ and only dipping into Objective-C for iPhone specific features. This makes multi platform dev work much easier. All Apple's change does is limit the choice of tools developers can use and speaking as a developer I want to have a range of tools and be able to pick the best tool for each specific job.
The reason Java is still slow and shitty on the desktop is because of the bloated java platform, not because of the language or runtime.
Nope, it's definitely the runtime (read JVM). The proof comes when you use something like Intent which is a JVP (Java Virtual Processor) which runs Java apps 50 times faster than the fastest JVM. Having an entire machine in RAM is ridiculous when you can have a processor in memory and let the physical machine do all the work.
I do believe he has coined a new word, acronym actually... and it seems to fit the OSFA cross-platform apps in discussion.
Here's a question:
How does a developer write a cross-platform app like Koi Pond?
.
I didn't coin it, it has been around a long time. When I used it, it references the nature of most Apps: small little things doing very little actual computing or processing. Merely waiting for some input, and providing some net accesses, and output. Not the kind of thing where the issue of garbage collection becomes a big factor in operation.
No, PPC code was hardly removed from Snow Leopard. Go check it out yourself with the 'file' command. You'll find all the libraries are still there. If it wasn't, Rosetta wouldn't work. The biggest gain in Snow Leopard was that Apple undid a packaging mistake they made with Leopard. I don't remember the exact detail, but they accidentally included a lot more 'resources' in the builds of each App than were necessary. Apparently they couldn't undo it once it had shipped, or didn't think it was a good idea.
That makes no sense at all. Rosetta doesn't need a pile of PPC code lying around in the OS to run old PPC only apps. All it needs to do is translate the code from PPC to Intel. Virtual PC never needed Intel code in Mac OS X or Mac OS 9 in order to translate Windows into PPC back on the PPC machines and neither does Rosetta.
This article makes zero sense: there is no reason that Adobe couldn't update it's flash->iPhone compiler to support the new multi-tasking APIs.
Apple wants applications that have been tailored directly for their platforms... they don't want generic applications that "work" on platforms. So they'll create whatever rules they need to ensure that this happens.
+1
I smell a giant load of BS. There is no technical reason why other app development tools can't be engineered to work properly. I think this is about keeping their app count higher than competing platforms. If I can cross-compile to android and windows mobile 7 (or whatever they are calling it these days) then Apple no longer has bragging rights.
If it really is a technical issue then: Non-native objective-c apps don't get to benefit from multi-tasking and run the same way current apps do. Done.
This is all true... but Apple is trying to maximize the performance, footprint, battery use, etc. of apps. Everything they can do to eliminate cycles is a potential improvement.
...snip...
Me, as a playtime developer, it would be a lot easier to the the system do GC. But Apple doesn't support it in iPhone OS... their game, their rules! If I don't like it, I go to a different game!
Except that GC is a runtime(user process) feature, not an OS feature. Therefore, it doesn't matter whether Apple includes it or not. It has not been claimed as the reason for disallowing non-Apple dev tools. And if it was, they can achieve their goal by the more limited means of quality testing: Enforcing a quality test on ALL apps, not just saying only XCode apps can be published.
Quote:
Originally Posted by lowededwookie
That makes no sense at all. Rosetta doesn't need a pile of PPC code lying around in the OS to run old PPC only apps. All it needs to do is translate the code from PPC to Intel. Virtual PC never needed Intel code in Mac OS X or Mac OS 9 in order to translate Windows into PPC back on the PPC machines and neither does Rosetta.
Yes, Rosetta needs a big pile of PPC code lying around. As I said, go look yourself. It is all still there in Snow Leopard. Virtual PC needs plenty of Intel code: An entire operating system. Rosetta just needs the PPC libraries, and relies on the native Intel operating system.
But isn't Apple trying to improve the situation we have today?
If a compiled Flash app always terminates completely, then it will confuse the user and [appear to] perform poorly (takes too long to start, doesn't resume where I left off, etc). Likely, these apps would reflect poorly on the platform.
Actually it should be pretty easy to write the flash-to-iPhone compiler so the resultant app correctly saves its state. Using the other background services such as voip, or location is probably not going to happen, but suspend/resume should be fine.
As long as they weren't trying to bypass the Apple API (which is already covered in the licensing agreement) there shouldn't really be any difference between an app written in flash and one written in C, C++ or Objective-C.
This does not prevent porting of apps / multi-platform development
Unless you want to limit yourself purely to iPhone dev you are better off primarily using C/C++ and only dipping into Objective-C for iPhone specific features. This makes multi platform dev work much easier. All Apple's change does is limit the choice of tools developers can use and speaking as a developer I want to have a range of tools and be able to pick the best tool for each specific job.
But isn't Objective-C available to ALL the major platforms? If you want to take the least amount of time to get apps running on all platforms you choose the language that is available to all platforms and work around the ugly bits within the language. Surely a good programmer would be able to find ways around limitations in a language to achieve what they want to do. I mean JQuery, Sproutcore, Cappuccino, and Protocol use Javascript to perform things that many people never expected Javascript and HTML to be able to do so I'm sure writing in one language like Objective-C on Windows, Mac OS X, Linux, iPhone OS, Symbian (if it's available) will be less work than writing an app in Flash then porting it to Objective-C or whatever.
To some extent. My main issue is with the attempt to cover Apple's nearly unprecedented actions with the fig-leaf of technical necessity. The rest of it, is that at some point(and that point may be now) there is a case for restraint of trade against Apple.
First, what if Apple can prove their position that building apps (with the new restrictions) allows them to do a better job of supporting multitasking.
This could be something as simple as: we aren't allowing support (initially) so we can have greater control over the UEX. This is similar to not trying to do everything at once (iTunes, iBooks, and iPads in every country at the same time).
Apple has a finite amount of technical talent... they need to be prudent how they use this precious resource... put the bang where you get the most buck!
Second, I used to work for IBM (1963-1980) when they were in the middle of their monopoly and restraint of trade lawsuits. (Your forum name was a pretty big name at IBM-- is that you, Gene?).
AIR, the restraint of trade was related to a tie-in (customers had to use punched cards supplied by IBM in the accounting machines rented from IBM). The suit languished in the courts for many years an was eventually resolved by a consent decree (IBM admitted no wrongdoing). The effect took place long after it ceased to have any meaning.
AIR, the monopoly issue was decided by directed verdict in IBM's favor. The judge decided that even though IBM had 97% of the market, it was a result of the quality of its products and services-- none of which were monopolistic... essentially, fair competition is not anticompetitive,
Just for comparison, at around the same time, the merger of Von's and Shopping Bag supermarkets was prevented because with something like 4% of the marketplace, it would tend toward a monopoly
I smell a giant load of BS. There is no technical reason why other app development tools can't be engineered to work properly. I think this is about keeping their app count higher than competing platforms. If I can cross-compile to android and windows mobile 7 (or whatever they are calling it these days) then Apple no longer has bragging rights.
So in your mind, the fact the Apple's iPhone developers are all required to use the same tools is a problem, because it is much better to have everyone creating apps in ActionScript and C# against MonoTouch, because those things are apparently possible.
Has it occurred to you that Apple might want its developers to get on the ball with iPhone 4.0, and not be suck with Adobe's or FOSS tools that have months of lag time before they catch up to the features Apple releases in Xcode?
Has it occurred to you that Apple might want to introduce optimizations that assume its technologies are being used across the board?
Are you also outraged that iPhone doesn't have the mess of app environments Mac OS X does (Carbon/Java/BSD/Cocoa/Flash/whatever else), as this provides such glorious choice for all those involved?
Has it ever occurred to you that Apple doesn't have any moral obligation to push its apps to the platforms of the competitive phone makers who are copying its hardware?
I find it hilarious that the same people who are bawling for Flash are also weeping that Apple is exerting proprietary control over the App Store platform it created. Of fucking course it doesn't want to enrich its competitors. Apple did all the work here.
App developers are benefiting from a platform Apple created. They do not deserve the right support a competing platform so they can resell lowest common denominator apps everywhere. That doesn't benefit end users. And there's no evidence that developers want to spread their apps outside of the markets that are actually making money. And currently, the only mobile software making any money is Apple's, despite all the propaganda for Android.
First, what if Apple can prove their position that building apps (with the new restrictions) allows them to do a better job of supporting multitasking.
Let's hear why. Those with knowledge are being pretty clear here in saying that it is actually impossible that these restrictions are connected to multitasking. One person in a thread yesterday floated the idea, and now AI has an article claiming it to fact. It's just spin, and AI is just a sign on the door in the Apple PR department.
Quote:
This could be something as simple as: we aren't allowing support (initially) so we can have greater control over the UEX. This is similar to not trying to do everything at once (iTunes, iBooks, and iPads in every country at the same time).
Again, this is inventing excuses for Apple on the basis of nothing. If they want to announce that is what they are doing, they can do so.
Quote:
Apple has a finite amount of technical talent... they need to be prudent how they use this precious resource... put the bang where you get the most buck!
BS. Apple is enormous.
Quote:
Second, I used to work for IBM (1963-1980) when they were in the middle of their monopoly and restraint of trade lawsuits. (Your forum name was a pretty big name at IBM-- is that you, Gene?).
Of course, I am not him, as he is no longer with us, but his Law torments the multitudes into eternity. I adopt the name because of His law, and the ever-present belief that some miracle is going to come along and make multi-core/multi-threading easy/100% scalable.
CS4 is the last Adobe app suite that I am buying. I see no point in further spending money on upgrades that do only cosmetic changes and minimally change my workflow for the better.
Yes, Rosetta needs a big pile of PPC code lying around. As I said, go look yourself. It is all still there in Snow Leopard. Virtual PC needs plenty of Intel code: An entire operating system. Rosetta just needs the PPC libraries, and relies on the native Intel operating system.
OK, checking System Profiler I'll give you there is a lot of Universal Binary things in FrameWorks but I can only really see 1 application that comes with the OS and is Universal and that's Airport Utility. It's hard to say though how much of the Universal Binary frameworks are actually the result of installing the Developer Tools or if they are there as standard.
Virtual PC however did not need Intel code in Mac OS X or 9 to run. To think that is ludicrous at best. It worked best on G4 and G5 processors because both of those processors had some Intel code in them but it also worked on G3s which didn't. However, Virtual PC did not need to have any Intel code in the OS at all to work. The virtual machine had Intel code in the sense that Windows is only Intel but it did not need anything in the Mac OS to be able to translate that Intel code to PPC and that's what I'm getting at with Rosetta not needing PPC code in Snow Leopard to translate it into Intel code. It never has and if it did need some ability to do so it would not be in the OS it would be in the application package.
But isn't Objective-C available to ALL the major platforms? If you want to take the least amount of time to get apps running on all platforms you choose the language that is available to all platforms and work around the ugly bits within the language.
Objective-C is mainly used for Apple development only. Few people use it on other platforms. Objective-C uses gcc so could work on other platforms but the problem is the standard libraries eg Cocoa on Mac or GNUStep on Linux. They may be missing on other platforms.
C and C++ are the industry standards for multi-platform work. They are well known by large numbers of developers and have good compliers and tools available on every platform.
Personally I like C# although admittedly I haven't tried cellphone dev with it yet. C# is a nice modern language with lots of really nice tools available. However, this change by Apple doesn't just stop Flash, it also prevents C# so this option is now unavailable.
Again, there is no good technical reason for the change. It most definitely has nothing to do with multitasking as stated in the article. It also doesn't stop multi-platform development as I can still use C/C++. All it does is limit my ability as a developer to pick the best tool for a specific job.
Let's hear why. Those with knowledge are being pretty clear here in saying that it is actually impossible that these restrictions are connected to multitasking. One person in a thread yesterday floated the idea, and now AI has an article claiming it to fact. It's just spin, and AI is just a sign on the door in the Apple PR department.
Why should any company reveal their reasons for doing whatever in a competitive environment?
Look, I have this great idea for an app that will sell billions... I've story-booked it here so you can see the potential:
Again, this is inventing excuses for Apple on the basis of nothing. If they want to announce that is what they are doing, they can do so.
Sure they could! Why don't you start the ball rolling by posting some of your best source code, design, documentation, plans...
Quote:
BS. Apple is enormous.
AIR, Apple had to pull Mac OS X talent from Leopard (delaying its release) to get the iPhone OS out on time.
I am too lazy to research it, but Apple has a fraction of the number of employees as Microsoft.
Apple really screwed up when they took on too much (release mobileme and a whole lotto' new software ah the same time.
I think they learned their lesson.
Historically, Apple tries to create great new things with as few people as possible... the old interaction matrix... fewer people == less meetings (and pre-meeting meetings) and more time actually doing things.
It would not surprise me if there were less than 10 people implementing multitasking... and that they will succeed because they focus on what needs to be done and talk to eachother-- Adobe, et al, are not even on the horizon, at this point.
Speaking to all the devs in the thread, have any of you contacted Apple to discuss your concerns (especially the Unity engine question)? I know all of you are passionate about your work and how consumers will be affected, so I'm sure that Apple will be able to provide some clarity here. It is in their best interests to help you.
Have the mods here ever thought about putting a separate section in AI for devs to showcase their work? As a keen AI member I would be interested to see what the resident devs here have cooked up. :-)
Comments
How did you get that? What I meant was that if developers were developing using the XCode tools then a lot of the work needed to do things would already be handled by the APIs which Apple has refined for the minimal specs of the devices. Why reinvent the wheel when Apple's already given you one with less weight?
Great. So when Adobe implements it, they can just call those APIs too. If they don't do that, their stuff will be noticably slower... But that is exactly the point I was making: Nothing prevents an XCode guy from doing exactly the same thing, nothing makes bad programmers into good programmers. If they want to enforce quality standards, they are free to do so. But restricting dev tools does not accomplish that goal. It is simply anti-competitive.
It's running on devices with at least 128MB RAM and 600MHz processors. It doesn't take a rocket scientist to realise that programming methods used on desktop and laptops aren't going to work on a mobile device.
Does the operating system suddenly fail to enforce the firewall between OS and app just because it is a mobile device? Is the OS now incapable of releasing all the resources held when an app quits or is terminated? The answer is NO. Therefore, your original statement makes no sense. If you think it does make sense, perhaps you should explain with a tangible example why what you said makes sense. The only real difference is that CPU isn't free on mobile. Everything else is just a matter of scale.
Snow Leopard showed a reversal of that idea when they removed GBs of space from the OS. Admittedly a lot of that was due to removing PPC code and printer drivers but it's a bog step in the right direction. Less is more. Less superfluous code equals more refined code more refined code means less resources required less resources required means more resources for doing work.
No, PPC code was hardly removed from Snow Leopard. Go check it out yourself with the 'file' command. You'll find all the libraries are still there. If it wasn't, Rosetta wouldn't work. The biggest gain in Snow Leopard was that Apple undid a packaging mistake they made with Leopard. I don't remember the exact detail, but they accidentally included a lot more 'resources' in the builds of each App than were necessary. Apparently they couldn't undo it once it had shipped, or didn't think it was a good idea.
Even if your last statement is true... isn't that what business is about?
To some extent. My main issue is with the attempt to cover Apple's nearly unprecedented actions with the fig-leaf of technical necessity. The rest of it, is that at some point(and that point may be now) there is a case for restraint of trade against Apple.
Actually, the original ktappe post was http://forums.appleinsider.com/showp...9&postcount=85
And my reply was two posts later:
And your reply to the original poster is correct. I really wish Daniel Eran Dilger knew what he was writing about and did not write front page articles based on incorrect information.
A valid argument.. if garbage collection was the issue. Which it isn't. But maybe you can email Apple PR (don't forget to CC: AI) and give them the tip.
If GC CPU/power drain was the problem, the solution is you run it less often. Or create and discard less objects. It is not a big issue for the typical crApp. Java does require garbage collection, but it is provided by the Java VM (aka runtime). The cost, as you noted, is in occasional CPU use or increased memory footprint. The increased memory footprint allows less frequent execution of the garbage collector, compared to an equal load with less spare memory.
This is all true... but Apple is trying to maximize the performance, footprint, battery use, etc. of apps. Everything they can do to eliminate cycles is a potential improvement.
The logical extension to your position that you can reduce GC overhead by doing it less often, or discarding less objects... is to eliminate GC altogether.
That's what Apple decided was in the best interest, for now, of iPhone OS.
Me, as a playtime developer, it would be a lot easier to the the system do GC. But Apple doesn't support it in iPhone OS... their game, their rules! If I don't like it, I go to a different game!
.
Unless you want to limit yourself purely to iPhone dev you are better off primarily using C/C++ and only dipping into Objective-C for iPhone specific features. This makes multi platform dev work much easier. All Apple's change does is limit the choice of tools developers can use and speaking as a developer I want to have a range of tools and be able to pick the best tool for each specific job.
The reason Java is still slow and shitty on the desktop is because of the bloated java platform, not because of the language or runtime.
Nope, it's definitely the runtime (read JVM). The proof comes when you use something like Intent which is a JVP (Java Virtual Processor) which runs Java apps 50 times faster than the fastest JVM. Having an entire machine in RAM is ridiculous when you can have a processor in memory and let the physical machine do all the work.
I do believe he has coined a new word, acronym actually... and it seems to fit the OSFA cross-platform apps in discussion.
Here's a question:
How does a developer write a cross-platform app like Koi Pond?
.
I didn't coin it, it has been around a long time. When I used it, it references the nature of most Apps: small little things doing very little actual computing or processing. Merely waiting for some input, and providing some net accesses, and output. Not the kind of thing where the issue of garbage collection becomes a big factor in operation.
No, PPC code was hardly removed from Snow Leopard. Go check it out yourself with the 'file' command. You'll find all the libraries are still there. If it wasn't, Rosetta wouldn't work. The biggest gain in Snow Leopard was that Apple undid a packaging mistake they made with Leopard. I don't remember the exact detail, but they accidentally included a lot more 'resources' in the builds of each App than were necessary. Apparently they couldn't undo it once it had shipped, or didn't think it was a good idea.
That makes no sense at all. Rosetta doesn't need a pile of PPC code lying around in the OS to run old PPC only apps. All it needs to do is translate the code from PPC to Intel. Virtual PC never needed Intel code in Mac OS X or Mac OS 9 in order to translate Windows into PPC back on the PPC machines and neither does Rosetta.
This article makes zero sense: there is no reason that Adobe couldn't update it's flash->iPhone compiler to support the new multi-tasking APIs.
Apple wants applications that have been tailored directly for their platforms... they don't want generic applications that "work" on platforms. So they'll create whatever rules they need to ensure that this happens.
+1
I smell a giant load of BS. There is no technical reason why other app development tools can't be engineered to work properly. I think this is about keeping their app count higher than competing platforms. If I can cross-compile to android and windows mobile 7 (or whatever they are calling it these days) then Apple no longer has bragging rights.
If it really is a technical issue then: Non-native objective-c apps don't get to benefit from multi-tasking and run the same way current apps do. Done.
This is all true... but Apple is trying to maximize the performance, footprint, battery use, etc. of apps. Everything they can do to eliminate cycles is a potential improvement.
...snip...
Me, as a playtime developer, it would be a lot easier to the the system do GC. But Apple doesn't support it in iPhone OS... their game, their rules! If I don't like it, I go to a different game!
Except that GC is a runtime(user process) feature, not an OS feature. Therefore, it doesn't matter whether Apple includes it or not. It has not been claimed as the reason for disallowing non-Apple dev tools. And if it was, they can achieve their goal by the more limited means of quality testing: Enforcing a quality test on ALL apps, not just saying only XCode apps can be published.
That makes no sense at all. Rosetta doesn't need a pile of PPC code lying around in the OS to run old PPC only apps. All it needs to do is translate the code from PPC to Intel. Virtual PC never needed Intel code in Mac OS X or Mac OS 9 in order to translate Windows into PPC back on the PPC machines and neither does Rosetta.
Yes, Rosetta needs a big pile of PPC code lying around. As I said, go look yourself. It is all still there in Snow Leopard. Virtual PC needs plenty of Intel code: An entire operating system. Rosetta just needs the PPC libraries, and relies on the native Intel operating system.
But isn't Apple trying to improve the situation we have today?
If a compiled Flash app always terminates completely, then it will confuse the user and [appear to] perform poorly (takes too long to start, doesn't resume where I left off, etc). Likely, these apps would reflect poorly on the platform.
Actually it should be pretty easy to write the flash-to-iPhone compiler so the resultant app correctly saves its state. Using the other background services such as voip, or location is probably not going to happen, but suspend/resume should be fine.
As long as they weren't trying to bypass the Apple API (which is already covered in the licensing agreement) there shouldn't really be any difference between an app written in flash and one written in C, C++ or Objective-C.
There is no technical reason for this change.
This does not prevent porting of apps / multi-platform development
Unless you want to limit yourself purely to iPhone dev you are better off primarily using C/C++ and only dipping into Objective-C for iPhone specific features. This makes multi platform dev work much easier. All Apple's change does is limit the choice of tools developers can use and speaking as a developer I want to have a range of tools and be able to pick the best tool for each specific job.
But isn't Objective-C available to ALL the major platforms? If you want to take the least amount of time to get apps running on all platforms you choose the language that is available to all platforms and work around the ugly bits within the language. Surely a good programmer would be able to find ways around limitations in a language to achieve what they want to do. I mean JQuery, Sproutcore, Cappuccino, and Protocol use Javascript to perform things that many people never expected Javascript and HTML to be able to do so I'm sure writing in one language like Objective-C on Windows, Mac OS X, Linux, iPhone OS, Symbian (if it's available) will be less work than writing an app in Flash then porting it to Objective-C or whatever.
To some extent. My main issue is with the attempt to cover Apple's nearly unprecedented actions with the fig-leaf of technical necessity. The rest of it, is that at some point(and that point may be now) there is a case for restraint of trade against Apple.
First, what if Apple can prove their position that building apps (with the new restrictions) allows them to do a better job of supporting multitasking.
This could be something as simple as: we aren't allowing support (initially) so we can have greater control over the UEX. This is similar to not trying to do everything at once (iTunes, iBooks, and iPads in every country at the same time).
Apple has a finite amount of technical talent... they need to be prudent how they use this precious resource... put the bang where you get the most buck!
Second, I used to work for IBM (1963-1980) when they were in the middle of their monopoly and restraint of trade lawsuits. (Your forum name was a pretty big name at IBM-- is that you, Gene?).
AIR, the restraint of trade was related to a tie-in (customers had to use punched cards supplied by IBM in the accounting machines rented from IBM). The suit languished in the courts for many years an was eventually resolved by a consent decree (IBM admitted no wrongdoing). The effect took place long after it ceased to have any meaning.
AIR, the monopoly issue was decided by directed verdict in IBM's favor. The judge decided that even though IBM had 97% of the market, it was a result of the quality of its products and services-- none of which were monopolistic... essentially, fair competition is not anticompetitive,
Just for comparison, at around the same time, the merger of Von's and Shopping Bag supermarkets was prevented because with something like 4% of the marketplace, it would tend toward a monopoly
.
+1
I smell a giant load of BS. There is no technical reason why other app development tools can't be engineered to work properly. I think this is about keeping their app count higher than competing platforms. If I can cross-compile to android and windows mobile 7 (or whatever they are calling it these days) then Apple no longer has bragging rights.
So in your mind, the fact the Apple's iPhone developers are all required to use the same tools is a problem, because it is much better to have everyone creating apps in ActionScript and C# against MonoTouch, because those things are apparently possible.
Has it occurred to you that Apple might want its developers to get on the ball with iPhone 4.0, and not be suck with Adobe's or FOSS tools that have months of lag time before they catch up to the features Apple releases in Xcode?
Has it occurred to you that Apple might want to introduce optimizations that assume its technologies are being used across the board?
Are you also outraged that iPhone doesn't have the mess of app environments Mac OS X does (Carbon/Java/BSD/Cocoa/Flash/whatever else), as this provides such glorious choice for all those involved?
Has it ever occurred to you that Apple doesn't have any moral obligation to push its apps to the platforms of the competitive phone makers who are copying its hardware?
I find it hilarious that the same people who are bawling for Flash are also weeping that Apple is exerting proprietary control over the App Store platform it created. Of fucking course it doesn't want to enrich its competitors. Apple did all the work here.
App developers are benefiting from a platform Apple created. They do not deserve the right support a competing platform so they can resell lowest common denominator apps everywhere. That doesn't benefit end users. And there's no evidence that developers want to spread their apps outside of the markets that are actually making money. And currently, the only mobile software making any money is Apple's, despite all the propaganda for Android.
First, what if Apple can prove their position that building apps (with the new restrictions) allows them to do a better job of supporting multitasking.
Let's hear why. Those with knowledge are being pretty clear here in saying that it is actually impossible that these restrictions are connected to multitasking. One person in a thread yesterday floated the idea, and now AI has an article claiming it to fact. It's just spin, and AI is just a sign on the door in the Apple PR department.
This could be something as simple as: we aren't allowing support (initially) so we can have greater control over the UEX. This is similar to not trying to do everything at once (iTunes, iBooks, and iPads in every country at the same time).
Again, this is inventing excuses for Apple on the basis of nothing. If they want to announce that is what they are doing, they can do so.
Apple has a finite amount of technical talent... they need to be prudent how they use this precious resource... put the bang where you get the most buck!
BS. Apple is enormous.
Second, I used to work for IBM (1963-1980) when they were in the middle of their monopoly and restraint of trade lawsuits. (Your forum name was a pretty big name at IBM-- is that you, Gene?).
Of course, I am not him, as he is no longer with us, but his Law torments the multitudes into eternity. I adopt the name because of His law, and the ever-present belief that some miracle is going to come along and make multi-core/multi-threading easy/100% scalable.
Yes, Rosetta needs a big pile of PPC code lying around. As I said, go look yourself. It is all still there in Snow Leopard. Virtual PC needs plenty of Intel code: An entire operating system. Rosetta just needs the PPC libraries, and relies on the native Intel operating system.
OK, checking System Profiler I'll give you there is a lot of Universal Binary things in FrameWorks but I can only really see 1 application that comes with the OS and is Universal and that's Airport Utility. It's hard to say though how much of the Universal Binary frameworks are actually the result of installing the Developer Tools or if they are there as standard.
Virtual PC however did not need Intel code in Mac OS X or 9 to run. To think that is ludicrous at best. It worked best on G4 and G5 processors because both of those processors had some Intel code in them but it also worked on G3s which didn't. However, Virtual PC did not need to have any Intel code in the OS at all to work. The virtual machine had Intel code in the sense that Windows is only Intel but it did not need anything in the Mac OS to be able to translate that Intel code to PPC and that's what I'm getting at with Rosetta not needing PPC code in Snow Leopard to translate it into Intel code. It never has and if it did need some ability to do so it would not be in the OS it would be in the application package.
But isn't Objective-C available to ALL the major platforms? If you want to take the least amount of time to get apps running on all platforms you choose the language that is available to all platforms and work around the ugly bits within the language.
Objective-C is mainly used for Apple development only. Few people use it on other platforms. Objective-C uses gcc so could work on other platforms but the problem is the standard libraries eg Cocoa on Mac or GNUStep on Linux. They may be missing on other platforms.
C and C++ are the industry standards for multi-platform work. They are well known by large numbers of developers and have good compliers and tools available on every platform.
Personally I like C# although admittedly I haven't tried cellphone dev with it yet. C# is a nice modern language with lots of really nice tools available. However, this change by Apple doesn't just stop Flash, it also prevents C# so this option is now unavailable.
Again, there is no good technical reason for the change. It most definitely has nothing to do with multitasking as stated in the article. It also doesn't stop multi-platform development as I can still use C/C++. All it does is limit my ability as a developer to pick the best tool for a specific job.
Let's hear why. Those with knowledge are being pretty clear here in saying that it is actually impossible that these restrictions are connected to multitasking. One person in a thread yesterday floated the idea, and now AI has an article claiming it to fact. It's just spin, and AI is just a sign on the door in the Apple PR department.
Why should any company reveal their reasons for doing whatever in a competitive environment?
Look, I have this great idea for an app that will sell billions... I've story-booked it here so you can see the potential:
http://i_am_a_dumbass.net
Again, this is inventing excuses for Apple on the basis of nothing. If they want to announce that is what they are doing, they can do so.
Sure they could! Why don't you start the ball rolling by posting some of your best source code, design, documentation, plans...
BS. Apple is enormous.
AIR, Apple had to pull Mac OS X talent from Leopard (delaying its release) to get the iPhone OS out on time.
I am too lazy to research it, but Apple has a fraction of the number of employees as Microsoft.
Apple really screwed up when they took on too much (release mobileme and a whole lotto' new software ah the same time.
I think they learned their lesson.
Historically, Apple tries to create great new things with as few people as possible... the old interaction matrix... fewer people == less meetings (and pre-meeting meetings) and more time actually doing things.
It would not surprise me if there were less than 10 people implementing multitasking... and that they will succeed because they focus on what needs to be done and talk to eachother-- Adobe, et al, are not even on the horizon, at this point.
.
Speaking to all the devs in the thread, have any of you contacted Apple to discuss your concerns (especially the Unity engine question)? I know all of you are passionate about your work and how consumers will be affected, so I'm sure that Apple will be able to provide some clarity here. It is in their best interests to help you.
Have the mods here ever thought about putting a separate section in AI for devs to showcase their work? As a keen AI member I would be interested to see what the resident devs here have cooked up. :-)
What a great post! I second everything you say.