The Mac was well loved even then in education and delightfully pushed the old Apple IIs out of schools. Fast forward to 2010, a parent myself, with a teen even going to my own alma mater.  After a conference, I stepped over to the beautiful new computer room and noticed it was full of Apple eMacs. These were G4 based (non-Intel) iMacs that were specifically for the education market – serviceable machines that especially had price going for them.  Now and then I use an old G4 based Mac Mini for web surfing (and testing out PPC based software) and it remains a very viable computer.

Now here is the problem, actually two problems – Apple xCode 3.2.X and higher (released in March 2010)  require an Intel based Mac running Mac OS X 10.6.  Just based on hardware specs, the K-12 market is in trouble, however consider the operating system requirements in addition to this. Many shipped with OS 9.2 and an early version of Mac OS X – 10.1.4. The eMac can run Mac OS X 10.5, which makes it possible to use xCode 3.1.x. However several iterations of xCode also require Mac OS X 10.5. This means there have been at least one or more paid for OS system updates  which may not be present on K-12 Macs. Apple wants its developers running the most recent versions of Mac OS X, and if you check backwards compatibility, usually only two versions back of the OS than the then current OS. For example, you are going to have a lot of trouble supporting an OS version earlier than 10.4 if you use the present kit.

So the options are bleak if you want to stick with Apple only tools. If you are using one of these old Macs (like so many K-12 schools are), they can, at best, run only older versions of xCode. And that in turn means your programming course cannot include development for the iPhone too.

What makes me suspicious anyway about the Apple site were the alleged HTML 5 examples posted that not only required you view them with Safari, but that at least some required Safari + Mac OS X Snow Leopard. That is a terrible demonstration of standards based web browsing – to require a specific web browser and operating system.  I can only guess it is Apple’s way of getting more people using Safari.

Steve, it isn’t that you have these policies that is the problem, especially if they were in place when you made it possible to develop for iPhone. The problem is that these changes and decisions come from some hidden agenda, and that any developer at any time could be excised for doing nothing more than following your own guidelines.

Around the Internet: Slashdot | Reddit | The Guardian | Macworld Australia | TechCrunch

Sixth, the most important reason.

Besides the fact that Flash is closed and proprietary, has major technical drawbacks, and doesn’t support touch based devices, there is an even more important reason we do not allow Flash on iPhones, iPods and iPads. We have discussed the downsides of using Flash to play video and interactive content from websites, but Adobe also wants developers to adopt Flash to create apps that run on our mobile devices.

…

Flash is a cross platform development tool. It is not Adobe’s goal to help developers write the best iPhone, iPod and iPad apps. It is their goal to help developers write cross platform apps. And Adobe has been painfully slow to adopt enhancements to Apple’s platforms. For example, although Mac OS X has been shipping for almost 10 years now, Adobe just adopted it fully (Cocoa) two weeks ago when they shipped CS5. Adobe was the last major third party developer to fully adopt Mac OS X.

Whilst we understand the reasons behind Apple’s decision, we cannot ignore the opportunity that presents itself. That opportunity is Google’s Android platform and Apple may have given its rival a new set of fans with a point to prove.

It is clear that Steve Jobs would like to keep all eyes trained on his HTML 5 vs Flash smokescreen argument. HTML 5 is just being implemented and it simply cannot deliver all the functionality of Flash, though it can be used to deliver media in ways that Flash does – like audio and video. But Flash is much more than that. Just like the argument is not HTML 5 vs Flash but Apple vs Cross Platform tools that include Flash, but also include tools like Runrev, REALbasic and Unity.

The absence of such a high-level IDE is an opportunity for competing platforms. And, given the lack of windowing, the iPhone OS seems like a far better platform for something HyperCard-esque than the Mac ever was.

With Gruber’s previous support and blessing from Steve Jobs himself on his Apple positive stance on changes to the iPhone SDK, it is interesting that he makes even this statement. Since his DaringFireball blog doesn’t allow for comments, it is not clear to what extent his support for cross platform tools means. The dialog is intense over on Slashdot, with the topic remaining a top page affair even today. I think even the loyalties of some long time Mac OS focused vendors and developers are getting tested as developers realize that the issue isn’t Apple vs Flash or the red herring of Flash vs HTML 5, but Apple vs Cross Platform Development and Apple vs Developers.

Operating system vendors don’t like it when an operating system sticks around for long, but a large segment of their customers do. Large corporations and small business share a common practice – get the most out of the system you have, because the cost of upgrading infrastructure is incredibly expensive.  Walk into a bank like US Bank, and you’ll find most desktops running Windows 2000 Pro. Many home users  and small businesses are happily running Windows XP desktops because Windows XP lets they do what they need to do. And as much as Apple doesn’t want to admit, K-12 schools aren’t throwing away their old PPC based Mac OS computers.

A decade ago, it was true that the vast majority of software purchases took place for computers within their first six months of ownership. That was a time when solutions weren’t being delivered by server side or social service applications.  Shrinkwrapped software was sold primarily through resellers or distributors, though vendors were beginning to wake up to direct download sales. The channel hasn’t gone away, but the life cycle of a software release is shorter.

A lot of early adopter iPhone buyers are sadly learning that they won’t be able to take advantage of the next big release of the iPhone OS.  However, it is characteristic of early adopters of every stripe to want to trade up. That is a relatively painless obsolescence because it is the expectation of the type of customer who is willing to pay a much, much higher price for a product, rather than waiting a year or two for market forces to reduce the cost.

Planned obsolescence is very much a concern for independent software  vendors; not only for their own products, but what is forced onto them by their hardware or operating system partners.  For ISVs, the key is to sell as many units as possible, and one way to retain or gain new customers is to allow customers to use their titles on top of old operating systems. That’s why as a developer you need to consider carefully what tools you use, and also what operating systems you target. One thing that Microsoft Windows and Linux have in common is that developers can choose to have longer product revs if they want.

Perhaps consequentially, app stores are the preferred distribution model for only 15% of North American developers, with over half preferring direct sales to end-users or enterprises.

The reality of retail outside of the App Store is that retail demanding a 30% margin is not fantastical. In fact, a range between 20-30% on software titles as a retail margin are the norm. Retail provides vendors with the floor space love necessary to connect with the end user. As a venue with a complete monopoly over iPhone and iPad applications, App Store does not make any special promises comparable to real world equivalents that differentiate it from the basic service model provided by resellers.

If 85% of the developers believe the service is overpriced, and over half of app store developers responding prefer direct sales to end users and enterprises, it is possible they perceive the App Store as simply a credit card charging service, or at best, something akin to Kagi or other shareware sales venues.  I would otherwise think it a poor comparison because Apple does provide reseller value to the developer. The major difference between the App Store and a normal reseller relationship is that the App Store holds a monopolistic control over 100% of revenues generated from app sales (it is possible to generate other revenue from apps, but not on the app itself)  as well as extreme authorial control through SDK restrictions. This casts the 30% in a different light – if a reseller gets a percentage of all revenue generated, it is entitled to the same percentage that’s the norm in retail? Certainly Apple thinks so.

Another conclusion about the unhappy developers is that they know enough about how to set up a basic sales website and would like to shrink their overhead costs down to modest website upkeep and credit card fees. That makes sense. With so many App developers previously or currently being Mac OS X application developers as well, they may already have the infrastructure in place to do just that – they know they can be paying 5% or so on those sales instead of a mandatory 30%, at least for some of their sales.

Almost every vendor I do business with made good use of that time – we certainly did at Paradigma. Now xCode is a very good development environment. But now the OS vendor has a big influence over cross-platform version control, or control over your minimum operating system requirements for your applications. Or they can simply change the terms of their EULA in ways that make your business impossible.