Excellent overview on the cruel dynamics of the iPhone App Store:
Think of it as if there was a single Top 40 music radio station everybody listened to: moving up or down in the list has a huge impact on sales, and dropping from the list means your sales will be easily reduced by one or two orders of magnitude.
It took them months but Apple has finally done the right thing.
Stories of indie developers making a quarter million in 2 months are driving a surge of crappy shovelware in the iPhone App Store. Russell Beattie weighs in and compares it to the gold rush that mass sales of J2ME handsets produced.
Wil Shipley proposes a new model for the App Store, where all applications are accepted but only a select few are publicly listed in the store frontend. The rest are still searchable by name and linkable from external sites:
Everyone can get into the warehouse. Only the select few can get into the storefront.
Entrepreneur role model Mike Lee has been fired from Tapulous. I've admired the guy since I read about him on Will Shipley's blog. He is the perfect product guy. On his latest post he describes how he is going to move on by incorporating United Lemur as his own company.
Slick video of Intua BeatMaker, a music creation app for the iPhone (via Russ).
AppleInsider reports on a new Apple patent for remote browsing and iPhone streaming:
But instead of accessing the files from the device's built-in storage, the iPhone or iPod would use a wired, Wi-Fi, or cellular connection to remotely access and retrieve the media items from a user's home Mac or PC.
Other than the built-in Youtube app the iPhone has no media streaming support, and the draconian TOS on the SDK makes it impossible for third parties to offer a general purpose streaming application on the App Store. Could this mean that the SDK limitations are in place so Apple can introduce its own streaming support and claim they are the first and/or the only ones offering it? Keep the tinfoil hat at hand.
How current smartphone platforms deal with background apps
Developers and the Apple faithful are still arguing about Apple decision to block third party apps from running in the background on the iPhone. I'm going to try to offer a bit of perspective on the issue by explaining how current smartphone platforms deal with background apps.
Going by the classic definition of smartphone, both Google Android and the Blackberry JDE are arguably not smartphone platforms and feature phones with J2ME are sure as hell not one. But I am going to include them for the sake of comparison.
Palm OS
Lacks background process. Anything running "in the background" is in fact an OS interrupt handler or some other hackery. Palm OS is simply obsolete in terms of operating system design, and has been for years.
Symbian
Symbian allows full GUI background processes. When the device runs low on memory the operating system will start shutting down background processes. Additionally many of its APIs have explicit error conditions related to low memory errors and resource sharing. The operating system notifies the application when it needs to close it for memory reasons by sending the EEikCmdExit message.
Windows Mobile
Windows Mobile is similar to Symbian w.r.t. background apps. It allows full GUI applications to run in the background and uses its standard message delivery system to notify the application before closing if it runs out of memory (messages WM_HIBERNATE and WM_CLOSE).
Feature phones with J2ME
Sony Ericsson first, and recently Nokia have added background running for J2ME applications. Midlets are by nature usually very frugal on memory consumption so it works fairly well. In addition J2ME also supports termination notifications issued by the OS, so applications can save their running state on low memory conditions. That said the majority of J2ME feature phones are not from Sony Ericsson or from the high end Nokia range, so in general background running midlets are not supported.
Blackberry JDE
I am not experienced on Blackberry development, but as a platform it has supported background applications since day 1 and they are explicitly supported in the API.
Android
Android probably features the best and most balanced background application support. It has memory warning callbacks, like Symbian, and the explicit guarantee that the operating system will try its best to keep the application around, like Windows Mobile. But its defining feature is the the concept of Services: UI-less processes that run in the background and can be spawned on request by applications or by URI schemes:
A Service is a body of code that runs in the background. It can run in its own process, or in the context of another application's process, depending on its needs. Other components "bind" to a Service and invoke methods on it via remote procedure calls. An example of a Service is a media player; even when the user quits the media-selection UI, she probably still intends for her music to keep playing. A Service keeps the music going even when the UI has completed.
iPhone OS
The iPhone OS is a full Unix-like operating system, with a full blown kernel with memory protection and demand paging, running on a powerful CPU that has full support for all these features. In terms of OS design and features it leaves everything else in the dust. Which only makes the way Apple has chosen to cripple third party applications more painful to accept. The iPhone OS has full support for background applications if you are Apple. If you are not then it will kill your application the moment the user jumps out of it.
How Apple could add backround apps on the iPhone
The official reason is that background apps would kill the iPhone battery in no time, so they are not supported. But there is another way. Instead of keeping the full blown GUI of the application have the OS support the Google Android concept of Services. UI-less processes with access to certain features like the sound and network system, working under CPU and I/O quotas so they play nice to each other. They would be still under a "can be killed anytime" policy, but since they don't need to keep a GUI around they would be much easier on the RAM and CPU of the device.
Looks like Apple is pulling out iPhone applications with no explanation:
Apple pulled the app yesterday without giving my any notification that they were doing it, or what their justification was for removing it.
I’ve tried to contact them about the issue, but it’s been a complete dead end. If anyone has a useful contact number for apple, please let me know.
Full video of a roundtable organized by TechCrunch on the impact of the iPhone on the mobile Web, and how it relates to other (non-)platforms like Android.
AdMob CEO Omar Hamoui (in T-shirt) argued that it indeed represents a fundamental shift because it is the first time most people are actually using the mobile Web, regardless of how long it’s been around.
Despite AT&T not allowing tethered iPhone connections Apple has finally enabled sales of NetShare in the App Store. NetShare is a SOCKS proxy from the creators of Installer.app for jailbroken iPhones.
So far I've found 2 accepted ways of getting bookmarklets, well, bookmarked on the iPhone.
Browser bookmarks sync
iTunes offers bookmark sync with your native browser of choice. So it's just a matter of adding the bookmarklet to your PC or Mac browser and then syncing it with the iPhone.
The iTransmogrify way
It consists of having a page on the site offering the bookmarket with an URL formated like this:
http://example.com/DELETEME?javascript:code
When such a page is loaded on the iPhone it asks for the user to bookmark it, then to edit the bookmark by hand in the phone browser to delete everthing before the javascript: part. This is the page iTransmogrify uses.
More developer comentary on the current distribution model for the iPhone:
Unfortunately, we don't have An App Store, we have The App Store. The difference is exclusivity. With An App Store, software can be put on the iPhone through some other method. The App Store, however, is the sole way to get software on the iPhone.
Interesting discussion over at Russ' blog about reconciling the lack of openness on the iPhone with the reality of the current mobile industry.
Despite being out of beta the iPhone SDK still has a shrink-wrap NDA that prevents the Pragmatic Programmers from publishing their book or screencasts (from John Gruber).
Russ lists the many missing apps on the iPhone App Store. Many of which one can take for granted on other mobile platforms like Symbian or Windows Mobile.
Loving to hate the iPhone
The iPhone is a sweet platform to develop for, but its distribution model for third party code is like a textbook definition of the walled garden. Every line of code you are writing depends on the blessing of Apple to make it to the hands of your customers. The EULA on the SDK goes well into what could be called editorial control. The lame excuse of caring for the cellular network is false. For example the majority of Windows Mobile smartphones being sold by the same operators that now sell the iPhone are application unlocked and offer full hardware access to third parties. This includes the radio hardware and it is what makes features like the GPS-less localization in Google Maps for Windows Mobile possible.
The App Store is fine. The problem is that it is the only way to sell or distribute your application. If you are a small company and want to do iPhone development you are in the hands of Apple. They decide if you applications can be sold or not. They can control the positioning of your product inside their store (the only store). They decide if you can make it to end of the month. If you don't like it you cannot sell your product from your site or in another store. You are screwed, your code and effort is worthless, and you need to start from scratch on another platform.
The niceness of the tools makes it worse. The programming environment, its API, even Objective-C. It's all good, usable, thoughtful. It's developer-friendly. You want to keep programming on it. You loathe the time to go back to the perverted flavor of C++ Symbian forces you to use, or the endless rigid verbosity of Java. And that siren call is what dooms you in the end. Java code can be ported with some effort between its main mobile platforms (J2ME, Blackberry and soon Android.) And non-UI C++ code can be made portable between Symbian and Windows Mobile. On the iPhone platform you are effectively locked by Objective-C.
It's going to be very interesting to see how the situation evolves in the next 12 months. Apparently the App Store debuted with certain amount of usefulness challenged software, contradicting what many thought was going to be an opportunity for keeping a consistent user experience and quality level; which, along with the cell network collapse doomsday scenario, was the other favorite excuse for the wall garden apologists.
The App Store for the iPhone/iPod touch 2.0 is up. With 500 applications available on the launch day. For reference a popular Symbian site lists 503 applications for current Nokia smartphones.
500 Nokia S60 3th edition applications
- Developed over the last 3 years.
- They do not need to pass any quality certification, only a code-signing process.
500 iPhone 2.0 applications
- Developed over the last 6 months.
- Their code-signing process involves an actual quality assurance test.
After looking into both platforms, from a developer point of view, it doesn't surprise me at all. Even with the maniacal control Apple puts onto their platform it is still more developer friendly than anything Symbian/Nokia has released over the years. You are just more productive on Cocoa. It is actually a joy to program with.
The world's toughest programmer on the apps his company is shipping in time for the iPhone 3G lauch:
The back cover contains Handshake, the revolutionary way to exchange contact information. You simply place the phones together and make a handshaking gesture. The phones use the accelerometer data to find each other in the cloud and exchange cards.
Simply brilliant.