Today, everyone is linking to a provocative article from The Register with the headline Apple handcuffs ‘open’ web apps on iPhone home screen. There are three separate issues, all of which cause Web applications that are launched from the home screen to work more poorly than they do if you run them in Safari. The biggest issue is that Applications run from the home screen are not making use of the new JavaScript interpreter in iOS 4.3.
A friend who’s a software developer boils down that issue as follows:
Sounds like a bug to me.
For the discussion behind those points, see this thread at Hacker News.
It seems like almost everyone with a blog is captivated by the debate over Apple’s new policies related to in-app purchases. I read at least one good post on the subject every day. The money issues are important but not really interesting. Apple is leveraging its absolute control over which applications can be installed under iOS to pry away a big chunk of the revenue from application vendors.
The one rationale for the new policy I best understand is that application vendors will modify their pricing model so as to pay Apple the smallest amount possible. So if Apple charges 30% on direct purchases through iTunes and 15% for in-app purchases, many developers will distribute their application for free and then unlock the good features through an in-app purchase. If the percentage is different for subscriptions and for standalone in-app purchases, developers will try to switch to subscription-based pricing. In that sense, Apple has a strong incentive to charge the same price across the board.
What really interests me, though, is Apple’s false confidence in the idea that one payment system will actually work for everyone. Chris Adamson explains why this won’t work:
A client of a client of mine is likely to get caught up in this I-AP drama, and in a meeting this week, we laid out exactly how I-AP works, and what they have to do in order to implement it, including entering every product into the iTunes Connect web interface, a nightmarish prospect when you have thousands of SKUs. When we finished, there was a long silence on the phone, followed by a colleague saying “you can probably imagine the look on everyone’s faces here.”
I’m sure that the iOS team at Apple feels that they have designed an elegant and powerful payment system, maybe the best that anyone has ever created. But it’s apparent that not only is such a system insufficient for any application that might be conceived in the future for iOS, it’s also insufficient for many applications that already exist today.
It strikes me that the core error was when Apple allowed itself to be convinced that a one size fits all payment system would work for the full iOS ecosystem. I do wonder whether it was an executive decision that was passed on to engineers to implement, or the product team came up with a solution that the executives decided could work for everyone.
The folks who created Readability have published an open letter to Apple after their app was rejected because it violates the new license terms that require that all purchases made from within applications use Apple’s In App Purchase functionality. Here’s their response:
Before we cool down and come to our senses, we might as well share how we’re feeling right now: we believe that your new policy smacks of greed. Subscription apps like ours represent a tiny sliver of app sales that represent a tiny sliver of your revenue. You’ve achieved much of your success in hardware sales by cultivating an incredibly impressive app ecosystem. Every iPad or iPhone TV ad puts the apps developed by companies like ours front and center. It was a healthy and mutually beneficial dynamic: apps like ours get exposure and you get to show the world how these apps make your hardware shine. That’s why we’re a bit baffled here.
To be clear, we believe you have every right to push forward such a policy. In our view, it’s your hardware and your channel and you can put forth any policy you like. But to impose this course on any web service or web application that delivers any value outside of iOS will only discourage smaller ventures like ours to invest in iOS apps for our services. As far as Readability is concerned, our response is fairly straight-forward: go the other way… towards the web.
I have read plenty of arguments both ways about this new policy, but I’m pretty convinced at this point that aside from whether or not it’s evil and greedy, it’s almost certainly bad business for Apple.
Apple does many things incredibly well, which is why I love their products. The problem is that their confidence leads them to want to force their developers to do things the “Apple way” rather than letting come up with their own ways to do them. The fact that they can also dictate terms that require developers to pay a very large portion of their fees to Apple doesn’t discourage them either.
I suppose it’s possible that the new In App Purchasing framework Apple is mandating is so awesome that it’s worth the 30% you have to pay. In that case, while Apple is losing developers now, they’ll all come running back to take advantage of the new opportunity. It strikes me as more likely, though, that this mandate will be a disaster for Apple, because it snares too many producers who already have existing business models and can’t afford to suddenly start giving 30% of their subscription revenue to Apple.
Update: John Gruber rebuts:
Maybe I’m missing something, but these guys claiming to be surprised and disappointed by Apple’s insistence on a 30 percent cut when their own business model is to take a 30 percent cut strikes me as rich. And how can they claim that Readability isn’t “serving up content”? That’s exactly what Readability does. What they’re pissed about is that Apple has the stronger hand. Readability needs Apple to publish an app in the App Store. Apple doesn’t need Readability.
This gets at the tension. Readability doesn’t need Apple if they can sell their web-based service without them. Apple doesn’t need Readability if they’re one of a relatively small number of defectors from the iOS platform. I honestly have no idea which way this one’s going to go.
Update: Marco Arment explains why the new requirements are burdensome to developers aside from the 30% cut Apple will take. Adapting applications to fit into Apple’s payment framework will be impossible for some applications and require substantial reworking for many applications. That seems like too large a price to pay on top of the large revenue share that Apple will take.
Arment does a good job of listing some corner cases that put developers in a very tough position with regard to Apple’s requirements. I don’t expect Apple to have come up with all of these cases and accounted for them. What they illustrate is that Apple isn’t clever enough to come up with a system that will work for everyone and thus shouldn’t try to force everyone into one system.
Andy Crouch, A World Without Jobs:
As remarkable as Steve Jobs is in countless ways—as a designer, an innovator, a (ruthless and demanding) leader—his most singular quality has been his ability to articulate a perfectly secular form of hope. Nothing exemplifies that ability more than Apple’s early logo, which slapped a rainbow on the very archetype of human fallenness and failure—the bitten fruit—and made it a sign of promise and progress.
A thought provoking piece on Steve Jobs and finding hope in a secular world.
John Gruber posted a piece on Friday that is a must read for people who are interested in mobile computing, noting an absence of killer apps for Android. In it he talks about some reasons why, despite the strengths of the platform, we’re not seeing developers create unique, compelling applications for it. I don’t use an Android device, so it could be that Gruber’s argument rests on a shaky foundation, but it seems right to me from what I’ve read.
What I want to talk about, though, is a sort of “third freedom” when it comes to computing. The first freedom, referred to as Freedom 0 by Mark Pilgrim, is the freedom to “run the program, for any purpose.” Back in the day, people called it “libre” software to distinguish it from software that’s free in the “free beer” sense. That’s the second freedom. Software that’s free to download and install — freeware.
Obviously Apple’s iOS does not represent Freedom 0 in any way. You use it on Apple’s devices, under Apple’s terms, or not at all. Yes, you can jailbreak your phone but that is considered completely out of bounds. For the most part, Apple seems to see Freedom 0 as a negative. As far as the second freedom goes, some iOS software is freeware, some isn’t.
What Apple offers in exchange for giving up Freedom 0 (and they ask not only end users but also developers to give it up) is a new freedom for computer users — the freedom to install stuff on your computer without screwing things up. Freedom 0 is about giving you the right to screw up your computer in whatever way you see fit. Apple’s freedom is about giving you the opportunity to install any of thousands of applications with the knowledge that your phone will work just as well after you install them as it did before, and that you can get rid of those applications whenever you want.
Hackers and power users see this as a bad tradeoff, but I would imagine that for many users, this tradeoff is completely worth it. Ask any of the people who pay Geek Squad hundreds of dollars to disinfect their PCs whether they’d give up some of the freedom to do what they like to their PC in exchange for never having to deal with those sorts of problems again.
The iPhone was a huge hit before you could install apps for it at all, so it’s not as though this third freedom was the key to its success, but it’s clear that it is the key to the success for third party developers for iOS. It’s why people are willing to go through all of the pain of dealing with the App Store approval process to get their software onto the iOS platform.
The vast majority of users don’t want to be systems administrators any more than most drivers want to be mechanics. Apple has already built one successful platform that offers users the opportunity to avoid that responsibility, and it looks like they’re trying to bring that model to personal computing as well. I wouldn’t bet against them at this point.
First Apple deprecated their Java implementation. Now they’ve released it as open source:
Oracle and Apple today announced the OpenJDK project for Mac OS X. Apple will contribute most of the key components, tools and technology required for a Java SE 7 implementation on Mac OS X, including a 32-bit and 64-bit HotSpot-based Java virtual machine, class libraries, a networking stack and the foundation for a new graphical client. OpenJDK will make Apple’s Java technology available to open source developers so they can access and contribute to the effort.
The question that remains for me is whether Apple will continue to contribute code to OpenJDK. (Hopefully they will.)
This, combined with the fact that Apple is no longer going to ship Flash on OS X, seems to signal that Apple isn’t interested in being responsible for shipping updates for other people’s runtimes any more. You can certainly run Java or Flash on your Mac if you like, but the vendor is responsible for making sure that your runtime is patched and secure.
Marco Arment makes the point that the Mac App Store is for developers who aren’t already developing Mac apps. This was the point I was trying to get at the other day when I said:
I can see a future where a sizable percentage of Mac users only use applications that they installed through the Mac App Store.
There are a lot of people who buy Macs, go to the Apple Store and take some classes, and never bother to install anything on their Mac that wasn’t there when they bought it. Maybe they buy a productivity application so they can do word processing, and that’s it.
The App Store is a way to deliver applications to those people, and like Marco, I think it’s going to be very successful in that regard. Anyway, go read his post, The Mac App Store isn’t for today’s Mac developers.
Chris Adamson talks about the strange fact that the number one use of Java desktop applications is to run tools used to create Java server applications:
We know the big use for AWT and Swing, and it’s a terrible irony: measured by app launches or time spent in an app, the top AWT/Swing apps are surely NetBeans and IntelliJ, IDEs used for creating… other Java applications! The same can be said of the SWT toolkit, which powers the Eclipse IDE and not much else. This is what makes this white elephant so difficult to dispose of: all the value of modern-day Java is writing for the server, but nearly all the Java developers are using the desktop stuff to do so, making them the target market (and really the only market) for Desktop Java. If there were other viable Java applications on the desktop, used by everyday end-users, Apple couldn’t afford to risk going without Java. There aren’t, and it can.
This is sort of a weird result of how Java evolved. The original idea behind Java is that it would be a replacement for platform-native GUI toolkits, but of course that didn’t work out particularly well. However, it did make it easy for Java developers to write their tools in Java, and those tools wound up being write once, run anywhere.
That, in turn, contributed to the resurgence of the Mac. If you were a Java developer who used Eclipse, it was very very easy to move from Windows to the Mac. When it became obvious that using the Unix-based OS X was a better deal for Java developers than using Windows, you could just get a Mac, download Eclipse or whatever Java IDE you enjoy, check out your source, and get started.
Adamson’s prediction is that you soon won’t be able to run your favorite Java IDE on a Mac, but I don’t think he’s correct. At least I hope not. The strong negative reaction we’re seeing from the Java community is, for the most part, an expression of this worry. They don’t want to have to choose between their favorite tools and their favorite operating system, especially when they don’t have to right now.
Yesterday, I talked about what we might be able to infer from Apple’s decision to deprecate Java and prohibit Java applications from the Mac App Store in terms of the future of the Mac as an open platform. Today, I want to round up some links about the future of the Mac as a Java development platform and as a platform for developers.
Nobody is exactly sure what to make of the deprecation of Apple’s port of the Java Development Kit for the Mac, but a lot of people are rather stressed about it, as you can see from several threads at Hacker News. I am a Java developer and I do all of my work on a Mac. Losing the ability to continue to work in this manner would be a hit to my productivity.
First, Apple announced that the version of the JDK that they maintain is deprecated. A Java developer who is a Mac user emailed Steve Jobs what Apple’s future plans are for Java on OS X. Jobs responded that Oracle maintains the Java released for other platforms, that Apple’s Java release is always behind the latest Oracle (formerly Sun) release, and that keeping Java up to date for OS X is their job. Java creator James Gosling takes issue with Jobs on a number of points, noting that many companies do maintain Java for their platforms, and that Apple in the past chose to maintain the port for a variety of reasons. Former Sun open source evangelist Simon Phipps explains why it would be difficult for Oracle to take over maintenance of the OS X JDK.
Matt Drance says this is the end of Java as a development platform for Macs. The one community that really cares about this is Java developers who use Macs. Here’s his prognosis:
A lot of Java professionals use Macs for development, even if they deploy somewhere else. What will they do? If they’re using Eclipse, I think they’ll be OK. It shouldn’t take long to shim SWT on top of an OpenJDK port, and IBM has shown a lot of initiative over the years. Other “pure Java” IDEs, like JetBrains’ (superior, in my opinion) IDEA, depend on a working AWT, and therefore have some more thinking to do.
And finally, Tim Bray, on Twitter:
Unclench, everyone. There are millions of Java devs, all their tools are in Java, they like Macs, one way or another it’ll be there.
I don’t know what the future of Java on the Mac is, but I think it’s foolish for Apple to turn its back on hosting development environments that they don’t fully control. One of the factors that brought Apple back into relevance as a computer maker was the fact that Apple provided a friendly version of Unix that Web developers could use to get their work done. A few years ago switching from Windows to Mac became a no brainer if you were developing apps that would eventually be deployed on Unix servers. That led to a lot of Macs being sold, not only to those developers but also to the people those developers influence.
Furthermore, I believe that the presence of Macs on the desks of millions of software developers who were doing Java work, or PHP work, or Ruby on Rails work contributed in a big way to the growth of iPhone development. There are huge advantages associated with being the platform of choice for developers. Apple should be very careful before it fritters away those advantages.
The big question everyone is asking is whether the Mac App Store is a step toward the closing of the Mac platform, making it a walled garden like iOS where you can only install applications by way of the App Store. This was the big worry when the iPad was originally released — is the closed model the future of personal computing? Migrating the App Store model to the Mac platform isn’t very comforting to those of us who like to be able to install and run any software we like on our computers.
Today the App Store Review Guidelines have been leaked, answering one of my big questions, which is whether Apple is going to exercise control over which Mac applications can be distributed via the store. The answer is yes, they will.
The next question is whether Apple is moving toward the App Store being the only way to distribute Mac applications and the only way to install them. I think the answer that is that Apple is not headed in that direction. Here’s one reason why:
Apps that use deprecated or optionally installed technologies (e.g., Java, Rosetta) will be rejected
Apple is stating flat out that Java applications will not be allowed in the app store. This is important because developers in general, and Java developers in particular, make up a substantial part of the market for Apple computers. Many people migrated to the Mac specifically because it was a nice place to set up a full Web development environment that mirrors what you might use in production — you can install Eclipse (or your favorite Java IDE), Tomcat, MySQL, and Apache and get work done. It doesn’t seem like you’ll be able to install any of those applications in the App Store.
So the question is, will Apple turn its back on developers who use OS X completely? That seems highly unlikely to me.
My sense is that we’re going to see people using App Store apps and traditionally installed apps side by side for a long time. The review requirements make it clear that users will be unable to install the kinds of applications they need for many kinds of work by way of the App Store, so the Mac will need to remain an open platform in order to accommodate those users.
Oddly enough, this gives me some hope for future opening of the iOS platform. The Mac platform is going to be an experiment in running App Store-style managed applications alongside applications that require open access to the operating system to install. If the combination works out very well, it seems like Apple may decide to further open iOS.
I can see a future where a sizable percentage of Mac users only use applications that they installed through the Mac App Store. But I don’t see a future where the Mac App Store becomes the only way to distribute OS X applications. Apple is foreclosing that possibility itself with its review policy.
© rc3.org. Powered by WordPress using the DePo Skinny Theme.