For a minute, put yourself in the mindset of a developer of phone software. Arguably, having developed applications which were sold on Verizon Wireless and other cell carriers, this is a bit easier for this author. As a developer then, and attempting to receive some sort of compensation for your work, it would seem that there are too many platforms to develop for, all of them bad for different reasons.

Qualcomm’s Binary Runtime Environment for Wireless (aka BREW) is used by several major wireless carriers. From a technical perspective, it is a C-based API, which means that the learning curve is slight for C programmers. The best thing it has going for it, though, is that there is a centralized game store and market place. In theory, developers post their applications and games up to Qualcomm’s website. Carriers look through those apps and choose which ones they want to sell to their customers. Customers have one place to go to buy apps (Verizon calls it “Get It Now“). For a developer, BREW sounds like a great model. You don’t need to worry about selling to end users, or billing, or packaging up your product and selling it in a store. Customers can go on their phone and see a list of every piece of software available to purchase. If they do buy yours, they get the price of your app added to their phone bills. Nice and simple. What could be wrong with this?

Well, as it turns out, carriers aren’t interested in providing, what is to them, low margin software to their customers. They want to be able to sell games and applications (and ringtones) mostly as a way to get customers to switch to their network, and buy their cellphones. Consequently, there is little or no incentive for a carrier to decide to actually carry the game you (the developer) posted to the Qualcomm web site. This is why if you have Verizon Wireless, almost all the games available from “Get It Now” are from either from a huge game studio like EA or Sony, or based on a popular TV Show or Movie. The carriers simply don’t want to be bothered by a plethora of developers for what they consider to be chump change. As a developer, if the carrier doesn’t choose to carry you, you are out of luck. No way to get around them, no way to appeal, do not pass go, do not collect $200.

The other major platform for phone development is Java 2 Mobile Edition (AKA, J2me). This is the complete oposite end of the spectrum. Anyone can create a J2me app. When it first came out, J2me looked very promising. Like Java, which it is a subset of, software written in J2me could be run on any phone with Java support. Customers would be free to acquire software from any developer, anywhere on the planet — the carrier wouldn’t have complete control of the application pipe like in the BREW model. This would mean that developers have a much larger market of customers to sell to. Sounds like a good solution, right?

Unfortunately, while J2me was promised to be a great equalizer, this has turned out to be far from the reality. While BREW apps do require some amount of customization for each different handset it is released on, J2ME can vary even more greatly between them. Even different phone models released by the same manufacturer may not support the same J2me program! Because of the sheer number of phones and carriers which support J2me software, it is nearly impossible for a developer to write and test software on all of them. This means that any J2me application will only run on some subset of J2me phones.

Additionally, while the phone carriers cannot blockade access to their devices, developers must figure out how to get their product in front of customers. They must conduct marketing, figure out a billing model, and make sales individually to each customer. Applications are not digitally signed (as they are in BREW), so it becomes difficult for developers to prevent piracy of their product. Combined with the fact that most phones have a horrific user interface in general, and especially for installing J2me software, there are a series of significant barriers for selling J2me software which make it unpredictable to determine beforehand whether a product will succeed. This is a scenario that deters business-minded developers.

Of course, there is also the set of “Smart Phone” platforms, Palm-OS(now defunct), Windows Mobile, and Simbian. These each have their own sets of pros and cons. Certainly they have been successful targets for some developers, but for the purposes of this article we will say that the average user of those phones are typically very different from the average user of a regular phone, and specifically of an iPhone.

This brings us to the iPhone SDK. Apple seems to have derived the strengths of the business models of both BREW and J2ME. All software will be digitally signed, and distributed centrally by Apple. The digital signatures work two ways: They protect the developer from customer piracy, and they protect the customer from mischievous developers. There will be a centralized list of applications, so users can easily browse through apps they might want to download or purchase, and billing will be handled by Apple, which allows developers to concentrate on what they should be: developing. Unlike BREW, Apple has taken a stance that encourages independent developers to target the iPhone. They will place lesser-known, less expensive, or even free applications up on their store right alongside the bigger market players. Like J2ME, developers don’t need to strike a special deal with each carrier in order to get their software into people’s hands.

So, with this perspective, what are people complaining about? That they can’t write software which unlocks the iPhone. That they can’t publish software which curtails Apple’s own SDK or Safari web browser. Make no mistake about this: those complaints are pure ridiculousness. While it is to their advantage to do so, Apple didn’t have to release an SDK at all. Looking at the leading established models of software development, BREW and J2me, we can see that the Apple model takes their strengths and leaves their weaknesses — for the benefit of all 3rd party developers, and especially the independent and open source developers! This should be self-evident by looking at who the people are who are making the complaints — unfortunately, as with all things Apple, the enormous hype machine of the Interwebs has distorted the picture. Complaints are driven by …. Sun (founder of J2me, which Apple has no use for, and which will consequently suffer), Firefox (which, while a great desktop browser, wants to get into the mobile space dominated by mobile Safari) and Opera (struggling to be relevant in any market, desktop or mobile). Obviously, these complainers have motivations that are not entirely altruistic. (Note to avoid flamewar: this author is a huge desktop Firefox fan).

The second topic of complaint is that Apple won’t allow applications to run in the background, and they won’t allow voice-over-ip applications (like Skype) to run over the cell carrier (although running over Wi-Fi is fine). These really shouldn’t be the sore points they seem. From a developer’s perspective, there are certainly neat things one could do if allowed to run applications in the background (like an IM client, for example), which aren’t really practical otherwise. However, looking from a holistic perspective, some testers found that the battery would run dry in as little as four hours while running only basic background tasks. The radio and the CPU, when used actively, use a lot of power. This isn’t Apple’s fault — it’s a law of phsyics. And while I’m sure there are many people who would like to use Skype instead of their AT&T phone minutes, I’m sure the average kindergarden student can figure out why Apple won’t allow voice-over-ip apps to run over the unlimitted data connection instead of using your talk minutes.

So, what can we conclude about Apple’s SDK decisions? Certainly, they studied the existing market and the development models. The solution they came up with, from a business sense, not only takes the best of what is out there, but also meshes extremely well with Apple’s existing iTunes one-stop-shop model for how they already handle music, TV shows, and movies. While some developers may have gripes about some of the policies of the SDK (background tasks, Sun, Opera), the limitations are in actuality completely reasonable.

While the ultimate success of custom apps on the iPhone will only be determined with time, it is certainly off to a good start. As a past independant software developer, I see all of Apple’s decisions on the SDK as smart moves (even the ones that aren’t the most convenient to me), and ultimately very good to the customer, while also being reasonable, fair, and enabling opportunity for the developer. The only ones who don’t like it are the big-name established businesses which this new model will disrupt.

In and of itself, this is a good thing for everyone: the cell phone industry (they sell more phones), the carriers (people use their data plans), web sites (more hits), and of course you (its pretty cool, after all). And, the hype seems to be true: people really are using their “Real Web” browsers.

However, like Apple tried with the iPhone, some manufacturers seem to think that providing a full AJAX web environment is an alternative to allowing people to install local applications. After all, the apps already exist, and they are standardized. What’s not to like?

Unfortunately, there are a couple of holes in that logic. They are significant, although even the iPhone tried to get around them and found that it couldn’t.

First, the performance of a web-based program is significantly slower than a native one. For the iPhone, for example (the only phone so far with a full web browser), a web-based AJAX game is known to be around 100x slower than a comparable native version of the same program. That’s really slow. So slow, in fact, that almost any sort of game is pretty much out of the question.

Second, web-apps are only available where there is web access. In the States, at least, cell-based web access is pretty horrific, despite whatever recent claims the cell carriers have made. And because broadband speeds are accelerating, it makes the cell rates seem that much worse. Definitely not good enough to be taken seriously for an application. Second, you can’t run the app where you get no (or bad) cell service. Like in a subway, for example. Because the phones don’t cache the web page for very long, it means that you can’t even web apps that don’t need to contact the server are unusable if you want to pull up a game like Space Wormy.

For these reasons, phones will still need local apps for at least the foreseeable future. Hopefully, this won’t lead to the introduction of new cell phone platforms and API’s. The last thing the heavily fragmented cell phone industry needs is yet another platform. However, manufacturers can’t seem to help themselves. But that’s a whole other topic.

he only thing they can come up with (and the fact that you may not be able to change the battery without taking it to the store).

Want to get your mind blown? The virtual keyboard isn’t as good as a real keyboard. Want to know something else? It doesn’t matter! This is the real element that many reporters and financial analysts (and ) can’t seem to get right: Apple’s target audience for the iPhone is not the same set of people who have smart phones.

Here are some of the people Apple is targeting:
People who carry around separate iPods and [regular] cell phones.
People who want to listen to music on their phone, but don’t want to deal with terrible software
People who want to watch TV or Movies while they travel

Will these customers be impaired if their ipod is not a great word processor? Of course not. The argument of whether or not to include a physical keyboard is nothing new. The flip side of the argument is, “you know, with a regular keyboard, your BlackBerry can’t show video that well,” but you don’t hear people saying that. That’s because smart phones are established, and the iPhone isn’t. I think we’ll see that change in the next few weeks, though.

In fact, senior management feels so strongly about the rename that they are currently suing Nascar because the #31 car still says “Cingular” and not “AT&T.” It goes to show how dedicated they are that they were not deterred at all by the fact that they have not been been able to change the banners on many of their own stores yet. Also, it wasn’t until yesterday, more than a month later, that Cingular cell phones started saying “at&t” on them.

Yep … the “new” AT&T sure knows how to get their image across to consumers. It’s a good thing they are going to be exclusive carriers for the iPhone. I don’t think they’d have many customers left in another few years otherwise.

While having plenty of music is great, the problem starts to become that I can only listen to CD’s on my cdplayer, LP’s on my record player, and MP3’s on my IPod. If this sounds familiar, then Roxio’s “Record Now Music Lab” is targeted just for you.

Record Now Music Lab is a one-stop application which allows you to manage all your music from one place. It provides all the tools you might need to centralize your music collection on your computer. From there, you can copy it to the mp3 player of your choice. You can also use the digital copies as a backup for your CD’s in case they become scratched or lost. In my case, though, I like the convenience of not having to juggle hundreds of CD’s, and after using Music Lab to digitize my music, I can put my CD’s into storage.

Music Lab runs on any PC computer which can run Windows 2000 or XP. One thing to note is that it doesn’t provide any features or functionality which you can’t accomplish using free tools or utilities. What it does do well, however, is to provide all this functionality in one location, which makes it very easy to perform tasks.

Music Lab is capable of taking your CD’s and turning them into MP3’s directly. It can detect the CD and Track information of the CD you insert, and will automatically include that in the mp3 metadata. This is a nice feature, and it makes importing CD’s (probably one of the most commonly-used functions) a breeze. In addition to MP3, Music Lab supports converting MP3’s to AAC (Apple’s ITunes format) and OGG, which is a new open format which provides superior quality to MP3, although few players support it so far.

Music Lab can import your LP’s, cassette tapes, or potentially any other format via your sound card’s audio input jack. You will probably have to purchase a special “male-male” audio cable in order to connect the output on your player to the input on your computer, although these cables should be available inexpensively at most home audio or computer stores. One thing to be careful of is that your computer supports stereo input. Most computers do, but some of the budget-oriented PC’s only support mono sound in. The only drawback in this case is that your mp3’s will not have separate left and right channels. The Music Lab software has some basic filtering capabilities, which are able to take out some of the static hiss on older cassette tapes and LP’s.

Some additional features which help to achieve all your audio-goals from Music Lab are that you can transfer songs to many cell phones to use as ring-tones, and also that you can then burn your music back to audio CD’s. This latter can be useful for creating your own custom CD mixes for parties or long car rides.

The bottom line for Roxio’s RecordNow 9 Music Lab is that it is a solid, centralized application for managing and converting all your purchased music.

More advanced computer users might be better served to find free applications which only provide the specific functionality they intend to use, and thereby save the purchase price

Users who are looking for a simple, no-hassle solution, or who are not comfortable with tracking down and locating all the different software it would take to achieve the equivalent functionality will be happy they purchased it.