Guest post by Engadget’s recent piece, “Mobile OS shootout“, provides a relatively thorough comparison of current smartphone platforms and what they have going for them, mostly from a consumer gadget hound’s point of view. They provide a bunch of nice comparative tables, among them the table “Third Party Development”. From this table we learn that each platform has its own SDK, whereby some of the apps available are considered “native” – a distinction most non-developers won’t be able to grok, since it depends on an understanding of runtime environments, etc. It’s hard to say exactly who this table is targeting, actually; the developer or the end-user that the rest of the article seems to target. Let’s just investigate some of the assumptions it makes.
The table and the accompanying text paints a picture of six different platforms, each an island unto itself with a set of applications developed for that platform alone using the designated SDK. The end-user reading the article comes away with the sense that the iPhone is the phone of choice, if for no other reason than that it clearly has the most apps developed for it.
A developer reading the article, on the other hand, gets the sense that they might as well pick one platform and stick to it, since to get it on more than one platform they’ll have to learn x-many development frameworks and duplicate effort everywhere – an overwhelming prospect. “Which one platform has the biggest payoff in terms of the learning-curve to potential-customer ratio?” they wonder. Once again, there’s a good chance they’ll choose the iPhone, since as everyone knows, iPhone apps are cash cows.
This is, of course, exactly the kind of thinking that Apple encourages. It is also not the only way of thinking out there, not by a long shot.
You see, before Apple came along and blinded everybody with its shiny UI and mega-overpowered marketing campaign, developing for mobile devices was quite a bit more diverse than the “one Apple way” development philosophy may lead you to believe. That diversity hasn’t gone away, and in some ways it’s even increased. Windows Mobile, believe it or not, leads the way in supporting a diverse array of third-party development environments: in addition to apps developed with Microsoft’s SDK, it has always supported Java ME apps, and for a while now it’s supported Flash Lite apps, too. Same exact deal for Symbian phones. All in all the development landscape for the current crop of smartphones, in contrast to Engadget’s portrayal, actually looks like this:
Clearly, the operating systems that offer developers the most choice of development environment are Windows Mobile and Symbian. (Note that Engadget’s labeling of Symbian as having only “Medium” app availability seems rather ridiculous if Java ME and Flash Lite apps are factored in.) Perhaps more importantly, it’s clear that a large portion of smartphone operating systems can be targeted by using either Flash Lite or Java ME (and no complaining about Java ME fidelity/incompatibility issues; all of these smartphone OSes provide top-notch Java implementations). The above table shatters the illusion of the developer at a crossroads, having to pick just one of six OSes to develop for, and having to learn a whole new programming language (Objective C, anyone?) just to do so. As it turns out, apps that run on three or four of the top six smartphone OSes can be written in one shot, and that using tools with which a huge number of developers are already familiar (namely, Flash and Java, and the toolsets surrounding them).
Note that I’ve listed “WebKit” as a development environment even though (to my knowledge) only the iPhone and the Pre’s webOS support web-based apps outside the browser, and that with their own caveats. The main point is that, with minimal changes, four out of six smartphone OSes (including the iPhone) can be targeted with WebKit, and the future of WebKit, and web-based applications in general, looks bright.
Another point of interest is that Qt is likely to become a part of the Symbian stack sooner or later (what with Nokia owning it and whatnot). This is a point in Symbian’s favor, since it currently receives a lot of slack for its antiquated set of APIs, and since getting the same apps to run on Windows Mobile or even mobile Linux devices should be a piece of cake.
Finally, the future of Java ME will largely hinge on the release of JavaFX Mobile, whenever that may come. Right now it has been demoed on Windows Mobile and Android devices, but whether it will run on Android, or even Symbian for that matter, upon release is still up in the air. JavaFX promises to bring Java up to speed with Flash in terms of easy development of fluid, animated apps. The speedy, and ubiquitous, release of the JavaFX Mobile runtime will be key to this success.
To conclude, the takeaway lesson for budding smartphone developers is: Don’t believe the Apple (or the Engadget) hype. There are not, in fact, six separate platforms that you have to learn in order to cover the smartphone market, nor is there a real need to stick with just one platform and forget the others. Flash, Java, and to a lesser extent Silverlight, Qt and WebKit, all provide solutions that cross smartphone OS boundaries and can save development time and headaches.
The .Net Compact Framework could be considered part of the “Native” API for Windows Mobile devices, but a version of it is also available for Symbian devices, (see http://www.redfivelabs.com/) so may be an option for development on those platforms.
I’m no Microsoft fan, but I have to admit that .Net is an excellent platform.
Hey cool, I didn’t even know about that! Yet another way to develop apps for Symbian!
I wish there was Python for non-Symbian phones
iPhone Applications in Python: http://www.saurik.com/id/5
ps: http://en.wikipedia.org/wiki/Mobile_development
Edited 2009-03-23 11:28 UTC
it’s good that most phones do not support silverlight
So we should be using Flash, which is proprietary, interpreted, has performance and scaling issues and the mobile version is a subset, or Java which is interpreted and has performance issues even on desktop systems with infinitely more processing power, or Silverlight which is proprietary, interpreted and has a limited history, or Qt – ok if you say so, or WebKit with very limited interaction with the devices features without custom libraries therefore making cross platform development a logistical nightmare – all so that we are not using Apple’s proprietary system therefore making Thom happy by not developing for the iPhone even though…
I must be missing something here.
For years the Microsoft brigade have belted out the “use Windows because it has more apps” tune, but now that Apple have achieved this with the iPhone that choir wants to change the chorus to “don’t use what has most apps because it has an Apple logo on it!” Well sorry you can’t – it has too many words and won’t fit the tune
Look we know you hate Apple with a passion Thom but the reality is that they have provided a complete platform for developers to create apps and sell or give them away in one place, simply and inexpensively and with a fairly decent developer support system attached. Who else has done that?
A point that has changed substantially since iPhone 1.0, when Apple were dumped on by certain people for only providing web based apps…
Edited 2009-03-23 15:54 UTC
Um, Thom didn’t write the article…. I did.
“So we should be using Flash, which is proprietary, interpreted, has performance and scaling issues and the mobile version is a subset”
Oh give me a break! For simple 2D games or non-graphics-intensive applications Flash Lite is just fine. I’ve played countless Flash Lite games without issue on my Cowon D2, which only has a 192MHz processor….
“or Java which is interpreted and has performance issues even on desktop systems with infinitely more processing power”
Um, we’re talking about Java ME (that stands for Micro Edition) here, not desktop Java. Big difference. Most Java ME apps run on hardware that’s a sore sight worse than the smartphones we’re talking about here.
It’s true that 3D support on both these platforms still leaves a lot to be desired. But smartphones with dedicated graphics are just now coming into their own, and I’m sure the platforms will change with the times too.
Edited 2009-03-23 17:29 UTC
VRally was installed by default on my Nokia 6280 about 5 years ago. It’s JSR 184:
http://jcp.org/en/jsr/detail?id=184
Many (most?) mobile phones have dedicated graphics with 3D acceleration and support JSR 184
You can download it here for free:
http://www.gsmhacks.com/forums/symbian-os-9-1-games/48098-v-rally-2…
It works on many mobile phones that are 5 years old.
There are many 3D J2ME games.
Hey, those graphics really are pretty good!
Yeah, I knew 3d on Java ME was possible, I just didn’t realize there were that many phones capable of these kinds of graphics. I guess I wouldn’t know since at the moment I use Java ME for simple 2D games or boring stuff like GMail and Google Maps. Given that 5-year-old Nokia can do this, I imagine that a current one would look pretty damn sick!
I think it’s a no brainer. 99% of the phones support J2ME, J2ME is secure and reliable and perfect for the phone. It’s the easy choice.
Have you ever written a J2ME app? I’m guessing not. If you did you would find that it is extremely limited. Compared to a real native app it has the following limitations:
1. Java, hence slower, more power hungry and… well java is just bad.
2. Maximum app size (including all data) of around 1 MB on most phones.
3. Very simple GUI toolkit. Only supports simple (and ugly) forms. There are 3rd party alternatives but none are very good.
4. No filesystem access (unless you pay lots to get your app signed). No seek function.
5. Most other APIs also *require* your app to be signed.
6. Very small library missing lots of functionality.
7. No multitasking (at least on most phones).
8. You can’t choose which buttons to assign to menu items – only give each item a priority and the phone chooses (usually in a stupid way).
9. Did I mention Java is shit?
J2ME is possibly the *worst* option. I wish Google would make a nice C++ API for Android.
You guessed wrong. I’ve actually used J2ME and I find that it allows to do a lot of stuff. I believe it is the right way to do applications for several reasons. It is an open standard in the mobile world and makes your application run on a wide range of phones. This is the best way not to restrict yourself to one vendor. It is secure and portable and not just to mobile phones.
I don’t agree with all your points about J2ME.
1. It is not power hungry or slow. The JIT compiles your app before running it and it is optimized for the actual phone it is running on and in many cases, it is doing it better even when the program is badly written, expecially vs badly written native apps with memory leaks and bad structure. It let the programmer concentrate on optimizing what matters the most: the algorithms, instead of trying to do efficient memory management and ending up creating bugs.
2. There is no maximum limit for J2ME apps. It is a good idea to keep them small when you transfer them to mobile phones without 3G support, but there is no limit.
3. There are a lot of them:
http://j2me.ngphone.com/opensource/ui.htm
I find that some of them are pretty good, but it is a matter of taste.
4. There is filesystem access. Most phones ask the user about it for security reasons: you don’t want an application you don’t know to send your data over the internet or to delete your files. On my SonyEricsson, I can select ‘ask’, ‘allow’ or ‘refuse’, independantly for each apps. I have several J2ME applications installed that are allowed to access my filesystem.
5. Most of them don’t.
6. It depends on the phones. There are several JSR that allow you to access pretty much any feature that you can find on a phone. Is there something in particular that you are missing?
7. On most phones, each MIDlet is a task and you can do multithreading inside a midlet.
8. This is true and that is because all phones have different button layout, but the iPhone does not have buttons anyway. On touchscreens, it does not matter.
9. It’s in your head
I believe J2ME is pretty nice when you know it.
Is that despite a lot of the phones having supposedly common OS’s and/or APIs/languages, since each one has different capacities in terms of RAM, CPU, and attached devices and often GUI (above and beyond the difference of screen size!) and keyboards, that still rather complicates the task for the developer: while nominally you’d hit a bunch of phones with one code base, at least you’d like to think so, you then still have to work around the limitations of the various systems, either making custom versions for each one, or, selecting a subset of features, and developing for the lowest common denominator’s capacities in all the ways.
By contrast, at least as of this time, other than having a camera or not, or Bluetooth or not (old iPod Touch), there is no hardware or software difference between the two devices in terms of targeting: you write code once, and poof, unless it actually requires the camera itself (and can’t just grab pictures from the photo roll) or uses Bluetooth and you’d like to target it at the first generation iPod Touch as well (and until 3.0 is out to the general public, the second generation iPod Touch) you’ve got yourself a target currently with 30 million devices that will run your software, as-is.
Now, there are differing versions of firmware out in the wild, as not everyone upgrades constantly: a lot of the versions are more bug fixes, with minor enhancements to functionality. So, if you want to be sure to get the greatest potential customer base, you need to release it and test it for the lowest revision number: then again, this isn’t any different in practice from any other phones, unless, of course, you can’t get updated firmware/OS revisions readily
Meanwhile, while there’s still a lot more phones to aim for other manufacturers, the smartphone with the closest platform installed base is the RIM products, which currently have about 22 million devices: last I knew, 30 million is greater than 22 million
All the other manufacturers, while they may very well have sold more phones that are programmable total, have the issue of having so many different mutations that there’s that lowest common denominator/test multiple phones aspect: not only does this increase testing and developing time before release, this also multiplies support requirements for fixing the software, besides requiring any developer that’s serious about doing the job correctly to buy one model of each phone it is supposed to run on.
Now, as to the Objective C argument: Objective C is a relatively limited expansion from standard C, and not only can you use any old C code with it, there’s also Objective C++, meaning you can interface any old C++ code with it as well, seamlessly: if you really want to, you can limit your Objective C usage entirely to GUI-related stuff, which, if you’re of the intent on supporting multiple types of phones, is what you would want to do anyway: keep the GUI code and the underlying app guts separated in clean packages.
It’s true that you have to aim for the lowest common denominator, but how is that any different than the way apps are developed on any other computer system? That’s why they have things called “System requirements”.
Ultimately if you’re making a game or an app that requires basic internet access, you should have no problem targeting the vast majority of (non-iPhone) smartphones. Flash Lite especially is garanteed compatible. With Java ME you might want to specify whether discrete graphics are necessary, but other than that you should be home free.
Obviously if you’re doing something more complicated that really does take advantage of a special hardware feature (for instance, multi-touch or tilt capability) you may be better off with the official SDK.
Edited 2009-03-23 18:39 UTC
It’s actually far more significant on phones than on PC’s: most PC’s have more than enough RAM to run something, and the users can almost always add more RAM: this can’t be done on any phone I’m aware of (not talking about Flash RAM here!).
Also, when it comes to video displays, the display on a phone is not only fixed and can’t be upgraded, but there are wildly divergent resolutions compared to other phones: the screen size that a user sees on a computer doesn’t vary nearly as much for the number of pixels used, and even so, there’s a certain minimum actual physical size that’s still readable that you can count on.
And then there’s the other interface things: pointing. Not all phones even have a way to use a stylus/pointing device in any way, shape or form, which then makes it that much more interesting to target user interfaces that use such things. It may be more common amongst the more expensive smartphones or featurephones, but things still aren’t 100% consistent, and some devices now support multitouch.
And then, next, there’s keyboards: there’s a lot of phones that only have the standard phone keypad, and that’s about the only thing you can count on phones to have that’s more or less standard in the keys it has and the layout: all bets are off beyond that. You can’t count on the layout of navigation buttons or shortcuts for all the different phones being the same, so if you have GUI menus/etc. there will be overhead dealing with this difference.
These days, there’s quite a few phones that have differing connectivity capacities, including WiFi, or not: this is also something that matters in practice.
And finally (I’m sure I forgot something) there’s always the accelerometer differences: these can be useful for a lot of things, but not only is it true that not all phones even with the same OS type have them or not, but not all are 3 axis accelerometers: that kind of cuts that down, too, from being sane to target.
It’s true that if you design an app for a touchscreen, it won’t work very well on a phone that doesn’t have one. The other way around, though–designing for non-touchscreen phones–presents absolutely no problem running the app on touchscreen phones. So basically, you choose whether to make an app universal or touchscreen only.
As for keyboard support, it doesn’t really matter. A text input field is a text input field. Sure, you may not be able to optimize the proportions of the display exactly for a given phone, but ultimately you program a text input field, and the particular Java implementation takes care of the rest.
As for screen resolution, if you use best practices and make your app resolution-independent, again you should have no issues.
Of course it’s true that this takes a bit more of a flexible mentality than programming apps for the iPhone. The iPhone is a control freak’s dream: every pixel is displayed exactly as the creator envisioned.
If you don’t need that level of control, though, then there’s no reason to confine yourself to one platform.
It is fine to write an app that can run one a wide variety of platforms. But when competing on high-end platforms such as iphone, such an app will very likely to be a looser in that market. So unless you can control competition by other means like patent, why bother?
You really are stretching things here.
It will be wonderful for that person who just bought that new shiny $800 unlocked phone to find that the app (s)he just bought will work as well as it does on a free phone. Please!
As far as Rez Indep. goes. That’s not so simple. Will an app designed to work well on a 160 x 120 screen work just as well on one with a 480 x 320 screen? Will it work better? The entire GUI for those small screens has to be different from what’s needed in a large one. It doesn’t “just” scale. It must be written properly.
The same thing is true for phones with meager cpu’s and RAM. A program designed to work well on them won’t work properly on a faster machine, because of the compromises made. Again, it doesn’t just scale on these levels.
If programs are written for the top performing devices, they won’t scale down properly.
These things aren’t nearly as seamless as you are trying to convince people they are.
Whether you realize it or not, keyboards ARE an issue. A big issue. A developer has to decide how much input a customer will be willing to deal with. Customers without full keyboards can’t input as much. It’s too tiring. Hard keyboards vs virtual ones are also an issue. Virtual keyboards offer customization that can’t be done with actual buttons. Again, the developer has to deal with this.
Even you admitted that games will be “simple”
You don’t seem to be understanding a lot of issues here.
I am understanding issues. What you are missing is that just because you are using Java ME does NOT mean you have to write a program that scales down well. You can choose whatever lowest common denominator you want–for instance by only supporting/marketing your app for touchscreen Symbian, Windows Mobile and BlackBerry devices.
This article and this discussion is about developing *for smartphones* and not Java ME development in general.
Java ME versus not Java ME is a red herring: the programming language and environment matter very little to the stuff he is mentioning, which I also was clearly mentioning, but running an interpreted/VM environment just makes it that much more of an issue in practice, because reducing RAM has a nonlinear effect on performance on something that does garbage collection automatically, well, even when not…
And seriously, how many users would like to use their phones to full advantage, instead of settling for the lowest common denominator functionality? That’s just not enhancing the value of what they’ve bought, then.
I think I’m going to have to do a followup article on what’s possible using Java ME on such a top of the line phone. I think you’ll be surprised.
Er, you’ve completely missed the point: the very nature of how fragmented things are means that “top of the line phone” is not going to run on many different not-so-top-of-the-line phones in any useful manner: such applications will need to have their capabilities adapted to only as much as the lower-end phones that it’s ported to, which may make the application not nearly as useful (a great example is phone-based video games: they might end up being absolutely unplayable or impossible to run on a lower-end phone) and this isn’t even counting all the user interface issues, such as differences in total number of pixels, screen size, whether or not it uses such non-guaranteed things as 3 axis accelerometers, etc. so just because a top-of-the-line phone with Java ME can do quite a bit, means nothing for every other phone you may want to run the same software on, because the experience won’t be the same.
Take V-Rally for instance. It runs on my nokia 6280 that is 5 years old. I believe even if you target just the N95 there are more of them that iphones. I have no numbers but I see more of them around me, but I’m pretty sure that if you target all phones that can run vRally and that have a scrren of exactly 240×320 that’s more than 500 000 phones.
I get my j2me applications from http://www.getjar.com There you can find free jar files and I’m pretty sure they have more than 30000 apps. Also Vodafone is spamming me with adverts asking me to install games from them. They also have quite a lot of apps, but you must pay them. If I click yes, they get 5 euros or so from my phone carrier. I believe this is like this since 10 years or so. I just don’t get what the buzz around the app store is all about.
And BTW J2ME application are compiled by the JVM before running them. You don’t notice the speed difference with native applications it’s 1:1. It just happen to be more secure and it never crashes the phone. When I say never, it’s NEVER. I run J2ME applications since at least 10 years. Never, ever have I had my phone crash, even downloading free crap games and some of them are programmed with the feet, believe me. Having your phone crash like a computer is not acceptable in my books. I must be able to receive phone calls, no matter how badly programmed some games are. For me this is mandatory.
The iPhone OS doesn’t crash if an app does. If a phone needs an app to run entirely within a VM to keep that from happening, that’s not much of an OS. While the iPhone OS is NOT perfect, I’d be willing to bet any smartphone OS also has bugs, too, which doesn’t change the relative equation that relates to running applications and whether or not they affect the operation of the phone. And, of course, that’s some of the claims Apple will make: non-Apple foreground/background applications are deliberately constrained so as to not affect the ability for the iPhone to actually function as a phone.
500,000? So what, that’s nothing, the iPhone platform as of last week had 30 million
Yeah, it’s still a young platform without as many phones total as any of the larger carriers/handset makers, but the thing is, they’re all the same for everything that’s important, between the iPhone and iPod Touch models. So, if that’s not a number pulled out of your butt, why would you want to target such a small number of phones, considering not everyone will buy any single app, when for a similar amount of development effort, you can target so many more potential devices (60 times) that are more capable? Yeah, you can target all the really low-end devices, but how satisfactory is that, really, when you can’t do a proper GUI, etc. ? It takes quite a bit more effort to make something work and work well on a very constrained device, compared to something that’s got a bit more under the hood, especially when that other something has a complete GUI explicitly designed for the form factor, that doesn’t try to shoehorn something like a Microsoft Windows GUI you’d see on a desktop, down into a very limited resolution on the phone.
Apple very well could have tried to take the Aqua desktop GUI from OS X and do the same thing Windows Mobile does with the GUI that’s similar, but fortunately, Apple didn’t. It’s not perfect, that’s true, but perhaps you can term it as it sucking less
Of course, the big problem with making a perfect GUI for something as small as a phone for displaying lots of information and being able to manipulate/interact with it, is that no matter how small we can manufacture screen resolutions and keyboards, humans don’t shrink 
That was a typo. I meant to say 500 millions (500 000 000)
http://www.macworld.com/article/133078/2008/04/tco_iphone_freeze.ht…
Edited 2009-03-24 10:22 UTC
Er, you’ve completely missed the point: the very nature of how fragmented things are means that “top of the line phone” is not going to run on many different not-so-top-of-the-line phones in any useful manner [/q]
It’s funny that the only argument you have is that you won’t be able to run your apps on lower-end phones. Because with iPhone apps, you can’t run your apps on any other phones, period
.
Good luck on that!
You really do miss the point.
It’s the customer acceptance that matters, not developer acceptance. Developers go to the platform that customers are going to.
Java, in any form is never the BEST solution. It is the easy one.
Even here, though, it is the minimal solution. Try to sell that to your customers.
If it’s going to use all the features on each phone, it’s going to have to be customized anyway. So what’s the point? If it isn’t customized, then it won’t have access to all the features.
Going to a platform like the iPhone, which doesn’t support all the crap the others support is still going to be a much better idea for most developers, because they can actually write programs that will support all the features of the platform, and know that, except for new hardware differences, which don’t cause a problem for older users, their program will work on all the devices properly.
Write once, use everywhere. Developers like that concept much better than having to constantly write new versions for every different model that comes out.
I believe the problem is not what your phone support but what your application need.
Very few application are going to use ALL the feature of any phone. They just use the features that are suitable for their goal. For instance, if you are doing a business app to control stocks on your phone, you’re not going use the accelerometer in any way.
If you use J2ME, you are going to depend on the JSR you need and you will support the phones that support them. You don’t have to write a version for the phones which support the accelerometer and those who don’t. You just write a version of your app for the phones that support the feature you need. This is like doing applications for desktop PC. If your application requires OpenGL capable graphics, then you do make your application depend on that.
You’ve just proven what I said!
Developers will just LOVE to have to produce three, four, five, or even more versions of their software.
Yeah, that’s worked very well on the desktop as well.
They are smart, usually. What they will do is go for the largest market. And what will that be?
J2ME is actually well implemented with JSR extensions and there are standard profiles like MIDP 2.0 which is supported by more than a billion of phones.
Even when you depend on a lot of JSR, like the JSR 184 for 3D, the market is still much larger than the iPhone market. Nokia alone ships more than 100 million MIDP 2.0 phones each quarter. A market of 30 million units is not impressive in the phone market. It is a very small niche actually.
Apple is very good at advertising their phone, but don’t make a mistake. Its market share doesn’t compare to any profile of J2ME phones.
Can you cite sources for those profiles, what they entail, and the actual number of functioning units using them?
There’s a sufficiently wide variety of CPU speeds and RAM that, unless the profiles are very specific to RAM and CPU speeds and types, makes those practical profiles much smaller in reality, and that’s not even counting the factor of customers first being able to find the apps in a sane manner, and then buy/install them, since not all carriers do things in exactly the same manner.
Manufacturers make their devices conform to the profiles based on what the hardware is capable of. It’s that simple. So as a rule, what you see really is what you get when it comes to profile compatibility.
You are 100% correct on this count, that the App store is more convenient, and that Apple was way ahead of the game on that count. Luckily, the other vendors are finally getting the clue.
Edited 2009-03-23 20:43 UTC
Since so many have rushed in to defend the iPhone, let me just say two things:
1) Apple makes great products, and the iPhone is a great device.
2) The iPhone’s popularity has less to do with its App store than with its basic, excellent design. Proof of this is that even before the App store existed, the iPhone became a phenomenon overnight.
Apps add a lot of value, of course they do, but the success of the iPhone over other smartphones is not due to the App store’s superiority over other software distribution methods. It is superior, of course, but that’s not the main reason for the iPhone’s success.
Every Symbian and Windows Mobile user I’ve ever met has had at least two third-party apps installed on their phones, and often as not it was in the range of six-plus apps. There was a vibrant third-party app community on other platforms long before Apple came along and convinced everyone else that they “had it all wrong”. In fact, it’s largely due to this community that there was such a push for Apple to create an SDK in the first place.
Edited 2009-03-23 21:07 UTC
I think the SDK prices and platform (which is counted into the SDK price ) are overlooked, and Android beat most of them ( Eclipse based , free , most of mainstream dev OSes).
Anyway that can lead to quality/maturity problem and lots of duplicates ( I guess that tons of “free” windows mobile application serve the same purpose and do enjoy the same stability ). On the other hand paid apps require a quality out of the box, and Apple might be right to give dev a good reason to make paid apps instead of free ones.
However the entry price is far to high for new dev ( buy an imac at least (I already own a PC, yes it’s a linux, yes I still dual boot on windows for purpose that linux don’t do easily), then pay the dev subscription, learning a new “not that much portable” language), some might find it a good argument to switch to Apple though.
I didn’t read the article (that’s why I read OSNews, to get the executive summary
, but I wonder if they took into account the role of the carriers. For example, of the two largest US carriers, Verizon only offers two of the 6 platforms in that table: Windows Mobile and Blackberry (3 if you count the older Palm OS, but their newer Palms are Windows). A third platform, iPhone, is AT&T-only, and I don’t think the nicer Symbian phones are available on AT&T unless you get them unlocked. Android is T-Mobile-only right now, and the Palm Pre will be Sprint-only.
Maybe the situation is different (better, hopefully) in other parts of the world, but if you are a developer looking at the US market, I think you have limited choices for volume markets right now: iPhone and Blackberry, and maybe Windows Mobile (WinMo though was lagging those first two significantly from what I’ve read recently).
I hope Symbian and Android (and Palm Pre if it’s good) get wider carrier penetration here, and Verizon honors their commitment to opening their network. I like Verizon’s coverage and service, but their smartphone selection is scant. Blackberry appears too restrictive, and Windows on a phone just doesn’t work too well, at least not on my current model.
I made a comment in an android threat on how i was unimpressed. Now as a developer for embeded devices (which mobile OS’s are used for, or are variants of OS’s used for embeded stuff) my comment that i was unimpressed with Android and felt it to be a lot easier to program and work with (as a developer) Windows Mobile (CE) and Symbian was modded down so fast i couldn’t hit refresh fast enough to see it vanish. now can you guys see why I had such opinions?
http://osnews.com/thread?349935
Edited 2009-03-24 21:23 UTC
Finalists – http://www.igfmobile.com/02finalists.html
Iphone: 11
Flash Lite: 1
Nintendo DS: 1
J2ME: 1
Winners – http://www.macworld.com/article/139604/2009/03/igfmobile.html
Iphone: 5 (not counting the two special awards)
the evil developers just don’t care about open platforms!
Developers don’t just do games.
Moreover you should not take this award too seriously. First off, this is an english speacking site and the event took place in California (home of Apple). Second off, Apple has a lot of fans.
If you type ‘best mobile games’ on google, you will find many DS and J2ME titles. There are other mobile awards with a lot of J2ME games.