although it lacks many of the most basic features necessary to do that sort of development effectively.
Which features are missing, exactly? Cappuccino, for example, implements almost exactly the same APIs and conventions that native Mac/iPhone developers use, only in Javascript.
If Apple did it for our own good, they would allow anyone to release anything written in any way.
The point is that we know for a fact that they already are doing preprocessing of the application binaries to speed up review times. It is safe to assume that they will continue to improve the system to continue to improve/sustain review times.
If third party binaries have been, or will be, breaking the process because they do not output exactly what Apple is expecting from their own compilers, it is easier to mandate that only Apple's tools be used rather than try and handle every tiny variation that might be submitted by any random development tool.
The problem with translation is that it will mangle information normally available in the resulting binary. Just running otool on a binary will reveal a lot about how the program was written. Information that would be lost by computer generated symbols in a translation process. As I mentioned, we already know they are doing this now. We just do not know to what extent.
I am not suggesting Apple is making the change for developers benefit. I am suggesting that they could be doing it to improve their own operations in the app submission process, and not just to push Adobe's buttons.
instead of evaluating the resulting app and see if it does make the experience suck.
There are already Flash apps in the App Store, published before the updated agreement. Perhaps Apple determined that they did, in fact, suck?
The one thing that nobody ever talks about is, we know that Apple has been doing a lot of automated processing on the binaries to ensure they are in compliance with other areas of the SDK upon submission. What if they determined that output from other compilers were breaking their system and the restriction was made to ensure that developers do not waste a lot of time writing software that is going to automatically be rejected by the automated systems in the future?
Developers have been pushing for faster approval times since the App Store opened. Automated compliance testing is the way to make that happen. Is it better to use any tool you want, but wait months for approval? Or use Apple's own tools and have it approved almost instantaneously?
According to that article, Android, on all devices, is barely beating out iPhone OS on one device. iPhone OS is sold on three distinct devices (iPhone, iPod touch, and iPad), of which the latter two were not included in the numbers. Android has a long way to go.
You bring up an interesting point. Why hasn't Adobe baked Flash into WebKit? Even if Apple chooses to ignore the fork for Safari, there are hundreds of other browsers that use the same codebase, including Chrome and the Android browser that would benefit from the contribution.
Almost all OS X systems are sold in aluminum enclosures. Are you suggesting that when comparing OS X to Windows, we should only count the number of Windows systems sold in aluminum cases?
Platform numbers are interesting because they give some idea about how large the market is for third-party development. Last time I checked, the iPhone SDK does not even allow access to the phone equipment found in the iPhone. Therefore, developers certainly do not care if the host system is a phone any more than Windows developers care that the host system is made of aluminum.
I have a router that runs a version of Linux just as the Android devices do. Should it be counted too.
No. Not because it is not a phone, but because it does not run Android. Both the N900 and the Pre run Linux as well, but they were not considered Android devices in this survey.
If you are actually running Android and capable of running software designed for the Android on your router, then yes, it should be counted.
Android is an operating system that runs on multiple devices. iPhone OS is an operating system that runs on multiple devices. So why are they comparing Android on all devices to one device running iPhone OS?
Include iPod touch and iPad sales and Android is not outselling iPhone OS.
Distributing the movie for pay would require a license.
As I understand the license, distributing the movie for free, but having the video hosting provider (such as Youtube) inject ads into your movie, requires that both you and the provider have a license.
The guys at digg fully admit that they could spend their days tuning MySQL to achieve the performance they need. What is important to realize is that it costs real money and time to perform that tuning. Time and money that could be better spent improving the user experience of the website.
Cassandra, on the other hand, performs optimally no matter what the developers throw at it, without the need to tune every last detail to squeeze every last bit of performance out of it. As the site grows, if the cluster is not able to handle the load, new (cheap) systems can be added in minutes.
Digg's move to Cassandra was a business decision to keep their operational costs low. The links you posted mention that a good DBA would solve all of digg's problems, which is probably true from a technology standpoint, but what they fail to mention is that a good DBA costs as much, if not more, than it costs them to run their entire Cassandra cluster.
So yes, with the right tuning MySQL would be capable of powering digg. They admit it themselves. It just did not make sense from a business point of view because keeping MySQL running well is much more expensive than keeping Cassandra running well.
Some enterprising developers have already implemented the basic features of Flash in HTML5. If Adobe really cared about Flash, they would bring the project up to support the full Flash spec and ensure all future versions of Flash generate HTML5 code natively. Instead, they have decided to go home crying.
I do not deny that Apple has not be playing nice on this front, but Adobe really has not put much effort into bringing Flash to the device. As I have noted here and in previous posts, the new SDK rules do not prevent Adobe from putting Flash on the device.
It is a matter of semantics, but I believe that most developers do not consider libraries and frameworks to be Applications. The Application, as far as most developers are concerned, is the core code that starts with main() and delegates the tasks out to supporting libraries. I do not consider AppKit.framework to be my Application, for example, despite the fact that most iPhone applications rely on it.
Because a Library is not an Application, you are, according to the terms, free to write your Library in any language you want (including Flash) so long as the code does not directly link against any documented APIs. Your Application must still be written in C, C++, or Objective-C but it is able to load the library and perform the appropriate delegation.
Now comes in the question of "compatibility layer." If brokering tasks between your Application and the Library constitutes a compatibility layer, technically any calls made between separate libraries is a compatibility layer. If libsqlite3 returns a native C datatype and you need to convert it to a NSString datatype for your Application, is that not a compatibility layer? Arguably, virtually every single iPhone app in existence violates that clause.
I would have to completely re-write the game to get it to run on any of the other platforms.
I am not sure that is really true. Section 3.3.1, as far as I can tell, places no restrictions on supporting code (think 3rd party libraries). What you are required to do is write any code that links against Apple's provided APIs to be originally written in C, C++, or Objective-C (hereafter known as C-family languages).
What this means to you is that you can write your program in Flash, write a compiler* to convert the Flash output to code that can be executed natively**, and write an application in the C-family language of your choosing to provide a bridge between your own APIs used by the compiled flash code and Apple's frameworks.
No matter how you slice it, if you want your compiled Flash code (or any kind of platform neutral code) to run on any device you would have to provide an intermediary between the Flash API and the platform APIs. Even before the change in license, Apple's APIs required that your language be compatible with linking against C and Objective-C frameworks. Naturally, most developers will choose to implement the necessary bridge in a C-family language. As far as developers are concerned, nothing has really changed, save a few edge cases.
* Because interpreting code is forbidden ** Required step because Adobe will no longer be releasing theirs
The spec is attempting to specify which types of videos are required to be available so that developers know exactly what type of video file they can present to all browsers.
Theoretically the browser can play videos of types beyond what the spec requires, but there is no guarantee to the authors of the content that the next browser will be able to play the same video.
HTML5 will also specify which image formats are required. While you can pretty much count on JPEG, PNG, and GIF support in most browsers today, there has previously never been a requirement for a browser to support any of those types. A more explicit definition about file formats ensures that browsers are predicable, no matter who the vendor is.
But you can do those things with HTML5. Choosing a video format to standardize upon will allow HTML5 pages to reliably play video as well as all of those animations and interactivity that Flash is also capable of.
Perhaps he means that Microsoft may discontinue support for ASP.NET in the future. Meaning, unless you want to completely rewrite your application in the future language de-jour, you will be forever stuck running the version of IIS that is able to host your application along with all of its security and maintainability issues. There's Mono, but like we see with Firefox/Chrome/etc., it probably won't execute your application properly.
If you choose a language/framework that has greater support for a wide range of computer systems, when Microsoft stops supporting the IIS version that is able to host your application, you can jump over to virtually any other system without much effort enabling you to continue to take advantage of security updates, improved management tools, etc. as they become available in the future.
The moral: Always have an exit strategy for you application. For all you know, Microsoft will cease to exist tomorrow and a huge security flaw will be found in IIS the next. Then what?
Write a Flash interpreter capable of hosting Farmville, snag a provisioning profile from a another developer (if you want to save $100) and install it. Virtually the same process required to play the game in an open environment at present time. The SDK rules only apply if you want to use the App Store.
I still feel that he does have a point, even if it was, perhaps, not presented in the best manner.
If this was about a "cure" for a computer virus we would get long winded explanations about how the virus was able to attack the system, which systems are vulnerable, and exactly how the fix is able to remove the virus.
Instead we are told that researchers were able to successfully remove the virus from 32% of the computers in the lab. Encouraging, perhaps. But it does not help anyone better understand the hows and whys.
someone who has no idea how drug development and clinical trials work
Is that not his point? He wants to know more about how the drugs were developed and why they work they way they do. Instead he is given a brief line about the success rate in clinical trials and not much else.
Both Android, WebOS, and several other vendors (such as Nokia) use the Linux operating system for their phones. iPhone OS is OS X (forked from early 10.5 builds). With the necessary modifications, all of the aforementioned operating systems will present you with your familiar UNIX shell – the exact same shell, from the same codebase, available to the desktop-based counterparts.
What do you mean 5% market share? At the time they had 100% of the USB-only personal computer market. If you wanted to play in this market, it was a strict requirement to make your devices USB compatible. There was absolutely no PC market share to fall back on at the time.
Apple certainly didn't invent USB, but they were the first to make it "cool" to use USB for all of your peripherals.
Apple wasn't the first to realize that floppies were no longer meeting the portable storage needs of users, but they were the first to make it "cool" to stop using the technology during a time when floppies were still in widespread use.
Apple has now made it "cool" to hate Flash even though I, and many others, have hated Flash for many years now. Whether or not it will ultimately kill Flash remains to be seen. As you said, they failed to make Firewire cool. They do not always succeed in making things cool. But they do have a pretty good track record.
How long will it take for the fix to pay for itself?
Approximately 40 years.
Now imagine how much it will cost to maintain an entire office of Windows XP machines running IE6 for the next 40 years so that the employees can access the aforementioned button while the rest of the world has long moved on to newer and better technology.
This is not like the one DOS machine that you sometimes find sitting in the corner of a business. In these businesses, every single workstation relies on IE6 being present. Unless they are willing to fix the button at some point, they will never be able to upgrade their workstations again.
Because everyone is forced into using IE6 because of the aforementioned button, we need to also factor in the costs of ensuring IE6 compatibility with all in-development and future products. Depending on the complexity of the project, IE6 support could add as much as 30% to the cost of the project. That amount could be significant if we assume the company has a lot of web software needs.
Then there is employee satisfaction. A happy employee is a productive employee. Sure, employees still might be okay with using Windows XP and IE6 today. But what about in five to ten years? It would be like asking your employees to start using DOS workstations today.
Even with the contrived numbers you have given, fixing the button will quickly pay for itself when compared to the alternative. It is going to happen anyway, and it is going to cost a lot more later.
But an insecure system that malfunctions and loses $5 with a 50% chance time you press a button is still worth using if it earns $11 when it doesn't malfunction.
When the alternative is $11 in earnings every time a button is pressed, how is the malfunctioning system worth using? Fixing the button will increase profits by 120%. Even if the fix is expensive, it will quickly pay for itself.
What do you mean? They gave a perfectly suitable upgrade path: Use IE6 for internal apps where necessary, use Firefox/Chrome/Safari/Opera/etc. for the rest of the internet. I don't know how you can get much more compatible than that.
Slashdot Mirror
Which features are missing, exactly? Cappuccino, for example, implements almost exactly the same APIs and conventions that native Mac/iPhone developers use, only in Javascript.
If Apple did it for our own good, they would allow anyone to release anything written in any way.
The point is that we know for a fact that they already are doing preprocessing of the application binaries to speed up review times. It is safe to assume that they will continue to improve the system to continue to improve/sustain review times.
If third party binaries have been, or will be, breaking the process because they do not output exactly what Apple is expecting from their own compilers, it is easier to mandate that only Apple's tools be used rather than try and handle every tiny variation that might be submitted by any random development tool.
The problem with translation is that it will mangle information normally available in the resulting binary. Just running otool on a binary will reveal a lot about how the program was written. Information that would be lost by computer generated symbols in a translation process. As I mentioned, we already know they are doing this now. We just do not know to what extent.
I am not suggesting Apple is making the change for developers benefit. I am suggesting that they could be doing it to improve their own operations in the app submission process, and not just to push Adobe's buttons.
There are already Flash apps in the App Store, published before the updated agreement. Perhaps Apple determined that they did, in fact, suck?
The one thing that nobody ever talks about is, we know that Apple has been doing a lot of automated processing on the binaries to ensure they are in compliance with other areas of the SDK upon submission. What if they determined that output from other compilers were breaking their system and the restriction was made to ensure that developers do not waste a lot of time writing software that is going to automatically be rejected by the automated systems in the future?
Developers have been pushing for faster approval times since the App Store opened. Automated compliance testing is the way to make that happen. Is it better to use any tool you want, but wait months for approval? Or use Apple's own tools and have it approved almost instantaneously?
According to that article, Android, on all devices, is barely beating out iPhone OS on one device. iPhone OS is sold on three distinct devices (iPhone, iPod touch, and iPad), of which the latter two were not included in the numbers. Android has a long way to go.
You bring up an interesting point. Why hasn't Adobe baked Flash into WebKit? Even if Apple chooses to ignore the fork for Safari, there are hundreds of other browsers that use the same codebase, including Chrome and the Android browser that would benefit from the contribution.
Almost all OS X systems are sold in aluminum enclosures. Are you suggesting that when comparing OS X to Windows, we should only count the number of Windows systems sold in aluminum cases?
Platform numbers are interesting because they give some idea about how large the market is for third-party development. Last time I checked, the iPhone SDK does not even allow access to the phone equipment found in the iPhone. Therefore, developers certainly do not care if the host system is a phone any more than Windows developers care that the host system is made of aluminum.
No. Not because it is not a phone, but because it does not run Android. Both the N900 and the Pre run Linux as well, but they were not considered Android devices in this survey.
If you are actually running Android and capable of running software designed for the Android on your router, then yes, it should be counted.
Android is an operating system that runs on multiple devices. iPhone OS is an operating system that runs on multiple devices. So why are they comparing Android on all devices to one device running iPhone OS?
Include iPod touch and iPad sales and Android is not outselling iPhone OS.
As I understand the license, distributing the movie for free, but having the video hosting provider (such as Youtube) inject ads into your movie, requires that both you and the provider have a license.
The guys at digg fully admit that they could spend their days tuning MySQL to achieve the performance they need. What is important to realize is that it costs real money and time to perform that tuning. Time and money that could be better spent improving the user experience of the website.
Cassandra, on the other hand, performs optimally no matter what the developers throw at it, without the need to tune every last detail to squeeze every last bit of performance out of it. As the site grows, if the cluster is not able to handle the load, new (cheap) systems can be added in minutes.
Digg's move to Cassandra was a business decision to keep their operational costs low. The links you posted mention that a good DBA would solve all of digg's problems, which is probably true from a technology standpoint, but what they fail to mention is that a good DBA costs as much, if not more, than it costs them to run their entire Cassandra cluster.
So yes, with the right tuning MySQL would be capable of powering digg. They admit it themselves. It just did not make sense from a business point of view because keeping MySQL running well is much more expensive than keeping Cassandra running well.
Some enterprising developers have already implemented the basic features of Flash in HTML5. If Adobe really cared about Flash, they would bring the project up to support the full Flash spec and ensure all future versions of Flash generate HTML5 code natively. Instead, they have decided to go home crying.
I do not deny that Apple has not be playing nice on this front, but Adobe really has not put much effort into bringing Flash to the device. As I have noted here and in previous posts, the new SDK rules do not prevent Adobe from putting Flash on the device.
It is a matter of semantics, but I believe that most developers do not consider libraries and frameworks to be Applications. The Application, as far as most developers are concerned, is the core code that starts with main() and delegates the tasks out to supporting libraries. I do not consider AppKit.framework to be my Application, for example, despite the fact that most iPhone applications rely on it.
Because a Library is not an Application, you are, according to the terms, free to write your Library in any language you want (including Flash) so long as the code does not directly link against any documented APIs. Your Application must still be written in C, C++, or Objective-C but it is able to load the library and perform the appropriate delegation.
Now comes in the question of "compatibility layer." If brokering tasks between your Application and the Library constitutes a compatibility layer, technically any calls made between separate libraries is a compatibility layer. If libsqlite3 returns a native C datatype and you need to convert it to a NSString datatype for your Application, is that not a compatibility layer? Arguably, virtually every single iPhone app in existence violates that clause.
I am not sure that is really true. Section 3.3.1, as far as I can tell, places no restrictions on supporting code (think 3rd party libraries). What you are required to do is write any code that links against Apple's provided APIs to be originally written in C, C++, or Objective-C (hereafter known as C-family languages).
What this means to you is that you can write your program in Flash, write a compiler* to convert the Flash output to code that can be executed natively**, and write an application in the C-family language of your choosing to provide a bridge between your own APIs used by the compiled flash code and Apple's frameworks.
No matter how you slice it, if you want your compiled Flash code (or any kind of platform neutral code) to run on any device you would have to provide an intermediary between the Flash API and the platform APIs. Even before the change in license, Apple's APIs required that your language be compatible with linking against C and Objective-C frameworks. Naturally, most developers will choose to implement the necessary bridge in a C-family language. As far as developers are concerned, nothing has really changed, save a few edge cases.
* Because interpreting code is forbidden
** Required step because Adobe will no longer be releasing theirs
The spec is attempting to specify which types of videos are required to be available so that developers know exactly what type of video file they can present to all browsers.
Theoretically the browser can play videos of types beyond what the spec requires, but there is no guarantee to the authors of the content that the next browser will be able to play the same video.
HTML5 will also specify which image formats are required. While you can pretty much count on JPEG, PNG, and GIF support in most browsers today, there has previously never been a requirement for a browser to support any of those types. A more explicit definition about file formats ensures that browsers are predicable, no matter who the vendor is.
But you can do those things with HTML5. Choosing a video format to standardize upon will allow HTML5 pages to reliably play video as well as all of those animations and interactivity that Flash is also capable of.
Perhaps he means that Microsoft may discontinue support for ASP.NET in the future. Meaning, unless you want to completely rewrite your application in the future language de-jour, you will be forever stuck running the version of IIS that is able to host your application along with all of its security and maintainability issues. There's Mono, but like we see with Firefox/Chrome/etc., it probably won't execute your application properly.
If you choose a language/framework that has greater support for a wide range of computer systems, when Microsoft stops supporting the IIS version that is able to host your application, you can jump over to virtually any other system without much effort enabling you to continue to take advantage of security updates, improved management tools, etc. as they become available in the future.
The moral: Always have an exit strategy for you application. For all you know, Microsoft will cease to exist tomorrow and a huge security flaw will be found in IIS the next. Then what?
Write a Flash interpreter capable of hosting Farmville, snag a provisioning profile from a another developer (if you want to save $100) and install it. Virtually the same process required to play the game in an open environment at present time. The SDK rules only apply if you want to use the App Store.
I still feel that he does have a point, even if it was, perhaps, not presented in the best manner.
If this was about a "cure" for a computer virus we would get long winded explanations about how the virus was able to attack the system, which systems are vulnerable, and exactly how the fix is able to remove the virus.
Instead we are told that researchers were able to successfully remove the virus from 32% of the computers in the lab. Encouraging, perhaps. But it does not help anyone better understand the hows and whys.
Is that not his point? He wants to know more about how the drugs were developed and why they work they way they do. Instead he is given a brief line about the success rate in clinical trials and not much else.
Both Android, WebOS, and several other vendors (such as Nokia) use the Linux operating system for their phones. iPhone OS is OS X (forked from early 10.5 builds). With the necessary modifications, all of the aforementioned operating systems will present you with your familiar UNIX shell – the exact same shell, from the same codebase, available to the desktop-based counterparts.
What do you mean 5% market share? At the time they had 100% of the USB-only personal computer market. If you wanted to play in this market, it was a strict requirement to make your devices USB compatible. There was absolutely no PC market share to fall back on at the time.
My cell phone runs the same operating system and software that my computer does. Does that mean that my computer is just a phone too?
Apple certainly didn't invent USB, but they were the first to make it "cool" to use USB for all of your peripherals.
Apple wasn't the first to realize that floppies were no longer meeting the portable storage needs of users, but they were the first to make it "cool" to stop using the technology during a time when floppies were still in widespread use.
Apple has now made it "cool" to hate Flash even though I, and many others, have hated Flash for many years now. Whether or not it will ultimately kill Flash remains to be seen. As you said, they failed to make Firewire cool. They do not always succeed in making things cool. But they do have a pretty good track record.
Approximately 40 years.
Now imagine how much it will cost to maintain an entire office of Windows XP machines running IE6 for the next 40 years so that the employees can access the aforementioned button while the rest of the world has long moved on to newer and better technology.
This is not like the one DOS machine that you sometimes find sitting in the corner of a business. In these businesses, every single workstation relies on IE6 being present. Unless they are willing to fix the button at some point, they will never be able to upgrade their workstations again.
Because everyone is forced into using IE6 because of the aforementioned button, we need to also factor in the costs of ensuring IE6 compatibility with all in-development and future products. Depending on the complexity of the project, IE6 support could add as much as 30% to the cost of the project. That amount could be significant if we assume the company has a lot of web software needs.
Then there is employee satisfaction. A happy employee is a productive employee. Sure, employees still might be okay with using Windows XP and IE6 today. But what about in five to ten years? It would be like asking your employees to start using DOS workstations today.
Even with the contrived numbers you have given, fixing the button will quickly pay for itself when compared to the alternative. It is going to happen anyway, and it is going to cost a lot more later.
When the alternative is $11 in earnings every time a button is pressed, how is the malfunctioning system worth using? Fixing the button will increase profits by 120%. Even if the fix is expensive, it will quickly pay for itself.
What do you mean? They gave a perfectly suitable upgrade path: Use IE6 for internal apps where necessary, use Firefox/Chrome/Safari/Opera/etc. for the rest of the internet. I don't know how you can get much more compatible than that.