Everything and the Mobile Software Universe…

Did you ear of any Android Market application success? Developer being rich? …

No you don’t, and if you develop an application sold on the AppStore and on the Android Market you know already that the Android Market has not taken off … yet (?)

So what’s going-on on the little robot side of the app planet?.

First the status : size of the Android Market in $$….

The AppStore opened in July 2008, when Android aired in February 2009, a 6 months advance for Apple…only.

During last WWDC2010 keynote Steve Jobs announced that so far Apple has paid out over $1 billion to app developers (their 70% cut for all sales).?

For Android, no official statement but Larvalab dug through AndroidZoom for us here :

Overall (as of June 18th, 2010), there were roughly 2,250 paid games and 13,000 paid non-game apps in the Market. The reason for the large number of apps vs. games is mainly due to the proliferation of spam apps, something which is much rarer in the games category. 4 games are in the 50,000-250,000 range, while 9 apps are in the 50,000-250,000 range. No paid app or game has yet exceeded 250,000 sales. Approximately 60 apps were in the 10,000-50,000 sales range, compared to approximately 45 games. It continues from there, with the vast majority of apps and games falling in to the ignominious “less than 50? bucket.

Overall we estimate that $6,000,000 has been paid out to developers for games, and $15,000,000 has been paid out on apps. That is a total of $21,000,000, nearly 1/50th the amount paid out to devs on iPhone.?

21M$ for around 15000 paid apps, you get it, for now there is no money is this market, why?

….but it is so small despite Android impressive numbers

There are now over 60 compatible Android devices from 21 OEMs in 48 countries. The devices are spread across 59 carriers.?

TechCrunch: Android Numbers

“In May (2010), we announced that there are 100,000 handsets every day. Today, that number is 160,000,”?

Andy Rubin (via AndroidSpin)

Check also those latest mobile internet OS share numbers from the latest (May 2010) admob report: An Android explosion

So why are you not making any money on Android market compared to the same application on the AppStore?

Android Payment mechanism:

• Google Checkout : you have to enter at least once your credit card information on the deice…many people still don’t trust their phone, and it’s a burden to do without any error
• No coupon, nor code : no flexibility
• from LarvaLabs again:

The Android Market is less flexible (than iTunes) – each purchase is a separate credit card charge… The credit card charge can even be denied without informing the user properly. It can also be disputed by the purchaser, resulting in expensive chargeback costs to the developer that are often even larger than the original purchase price of the app!??

Free culture:

It may sound childish to a business oriented reader, but how to explain this chart:  (Android data found on AndroLib and iPhone from 148apps.bz)If you want to do a paid application on Android, big chance your competition will be a free one…and be sure that with more than 60% of free apps, user are accustomed … to not pay for apps!? Here is the proof: This Admob survey really backup this “free” vision on Android, very few users are returning Application buyers, compared to the AppStore.

The big one : refund policy

Google developer distribution agreement

3.4 Special Refund Requirements. The Payment Processor’s standard terms and conditions regarding refunds will apply except the following terms apply to your distribution of Products on the Market. 
Products that can be previewed by the buyer (such as ringtones and wallpapers): No refund is required or allowed. 
Products that cannot be previewed by the buyer (such as applications): You authorize Google to give the buyer a full refund of the Product price if the buyer requests the refund within 48 hours after purchase.?

So yes you read it : a user has 2 days to ask you for a refund! And this is where a big chunk of you money is evaporating: some developers are saying 30 to 50% refund rate ( here , or here and here in the comments), on one of our cross platform app, which is selling well on Appstore we have a 60% refund rate on the android Market!

With such a refund rate, we may expect higher price than AppStore to compensate  the loss: WRONG Apps price are lower on the Android Market ! (courtesy of Distimo)

For games and many apps the retention rate is very low after 2 days (see the chart below from Pinch Media) that may explains those refund rates, of course casual gaming is seriously impacted.

Piracy (it is really easy to jailbreak an Android phone, so easy that is is being funny) may also of concern, because once downloaded it is possible to keep the app…even after the refund, with a VERY easy solution.

But why is there any refund policy in the first place?

The answer is simple: as Google has no application review process, only for the sake of looking more open and customer friendly, so a lot of crappy and buggy apps (ie crashing ones) are on the market today, so google NEEDs to allow the users to get a refund in case of a terrible application.

So it is kind of funny and ironical to have read all those rants against Apple and their AppStore review process by various developers and so called analysts when in reality the review process is probably the gate keeper of the AppStore revenue stream.

So what?

With a simple math, if number of potential buyers devices were the same on the AppStore and on the Android Market, due to the 30% refund rate, that 30% less people are buying one app per month, and in average the Application prices are 10% less on Android, you can only expect roughly 30% of the revenue from the Android Market compared to the AppStore … with the crazy assumption that you have the same potential number of customers!…and today this is really not the case.?

If your application is not profitable on the AppStore (big chance it is the case see here) , don’t count on the Android Market as a way to make your revenue explode, very very big probability that it won’t bring back any significant amount of money…as of today.

Feel free to share your experience in the comments! Do you see the same low revenue? Do you have and Android Market success story?

Recently Samsung announced Bada, a new development environment: in a nutshell this is an SDK with a set of C/C++ API associated to an application framework, ported on top of Samsung legacy RTOS, or Linux.
Bada will be deployed in a majority of Samsung touch phones from smartphones to feature phones.
Antony has been quicker than me and posted a nice Bada article at Vision Mobile, depicting why this Samsung move may prove to be a wise one. I mostly agree with him, his arguments are around gross margins, market pressure and differentiation. I’ll try to dig a little more around this differentiation aspects in the Samsung case and why they really seem to innovate in this area, especially versus an Android strategy.

When Bada was announced, I was very negative, my first reactions and comments were harsh: again a me too initiative from Samsung, the OEM with fantastic execution but no clear vision of its services/software strategy, trying all the available OS on the planet and waiting to see if one is successful.
Then I’ve looked back at what they achieved recently and what they’ve announced with Bada.

• They are now the undisputed number 2 in number of devices sold (not far from 20% of the market in Q2 2009 for ex)
• The Touchwiz UI 3.0 is on the smartphones AND ALL the other touch phones of the company: difficult to tell who is or is not a smartphone now (I’ve made the experiment at the last CTIA).
• Release of the Touchwiz UI widget SDK to develop widgets for all the Touchwiz based phones.

What are they trying to do with this TouchWiz UI ?: use the best software platforms (RTOS for cost effectiveness and integration, high level OS for SDKs and features) while trying to uniformize the user experience and consolidate the Samsung brand.

Obviously the next step, to retain its customers, a politically way to say “lock them in”, is to have exclusive applications and services accross the Samsung devices line…even better if the customer has paid for it so he won’t throw away its application investments to buy a competitor phone for its next purchase. Same strategy as Apple, but here we are talking about Samsung a company with dozens if not hundreds of different device models, across all the price ranges, selling more than 200 millions phones a year (yes a year! how many iPhones sold today? , ok margins, blablabla…and yes I have an iPhone).
How to do that? Make a robust application environment, OS agnostic, with a dedicated SDK, to allow deployment of the same binary to a range of devices with different software platforms … well this is exactly the description of Bada.
We (speaking in the name of OpenPlug in this sentence only) have advocated this very same idea for the last 7 years to push OEMs in this direction (Samsung and Nokia were part of the lot ), and this is at the end taking of : Nokia with Qt (still has to deliver but the intention is clear) and Samsung with Bada.

But why creating a new one and not simply reuse Android code base?…I’m sure you have the answer already:

• Android is free? Android is by no extend free: you have to pay a lot of your R&D budget to make a phone with your brand, your services, etc…
• Android is open, why not getting it? NO Android is a closed box, Google and only Google can really change it, it’s really time for the industry to wake up: it’s not because you have the code of something that you can control it. If you don’t have the roadmap and the team who is maintaining and developing it you simply have meaningless mega bytes of symbols
• …but this is from Google, the good guys! Sorry, they are not, they are pushing their own services, not yours, and now with the NexusOne their own phone and user experience.

Google/Android has a complete opposite aim versus OEMs own agenda:

• Android is here to push Google services in the mobile world, as a corollary it allows you to swap your device as easily as possible because the new one will have all your data and applications loaded and compatible from the old one.
• … wait,wait this is exactly what an OEM doesn’t want: an OEM wants you to buy your next phone from them, not the competitor. So you have to differentiate.

Samsung, like Nokia, simply doesn’t want that an external third party software house decides if its devices has to be like that or like this… to be look alike brothers to its direct competitors (check the Windows Mobile phones for the last 5 years, and you will get the point : all the same).
So why not following their own path? Apple has made the choice and is successful, Nokia is trying, Samsung has to move, and for me it is doing so in a more pragmatic way than Nokia:

• Bada is not about reinventing a new OS with the underlying plumbing to the hardware as is Nokia Mameo, who cares of that today?
• The User Experience is already in production and refined device after device
• Bada SDK is not “fancy” but raw C/C++ … but what the point as long as I can sell and do my applications for hundred of millions of devices and customers (let the fun to the WebOS guys…I’ll get the cash)

Of course Bada is not quite their today, where are the devices? where is the market place? But it is refreshing to see Samsung taking its own path, its own direction…opening even more opportunities to application developers.

After a huge AdobeMax in Los Angeles (more on that later, in another post and twitter), we’ve headed to San Diego for one day to look around this year CTIA, and attend the WIP Jam session.

Two words about San Diego: this city is GREAT! Go go Gaslamp! and the new Hitlon is just amazing…enough tourism.

Here are some bad shots (from by old iPhone 3G) about what we’ve seen:

[From three hardware related Nokia PR, blogger Thomas Menguy shows how those announcements fits within the new Nokia strategy]

MWC is the PR moment, and here are three from Nokia  showing how the game is changing in Finland.

Nokia selects Broadcom as a next generation 3G chipset supplier.

“Today’s announcement with Broadcom is a further example of Nokia’s commitment to our diversified, multi-supplier chipset strategy,” said Kai Oistamo, Executive Vice President, Devices, Nokia. “This agreement, which targets low cost, high volume markets, demonstrates that we view Broadcom as a reliable supplier to bring the benefits of 3G to Nokia customers around the world.”

Nokia selects Broadcom as a next generation 3G chipset supplier

Nokia and ST-Ericsson announced they are co-operating to provide the Symbian Foundation with a reference platform based on ST-Ericsson’s U8500 single chip

ST-Ericsson, Nokia’s reference platform for Symbian Foundation

Nokia and Qualcomm Incorporated (Nasdaq: QCOM) today announced that the two companies are planning to work together to develop advanced UMTS mobile devices, initially for North America. The companies intend for the devices to be based on S60 software on Symbian OS, the world’s most used software for smartphones, and leverage Qualcomm’s advanced Mobile Station Modem(TM) (MSM(TM)) MSM7xxx-series and MSM8xxx-series chipsets

Nokia and Qualcomm plan to develop advanced mobile devices

What does this mean?

For years Nokia was relying on Texas Instrument to produce its custom 2G/2.5G/3G chipsets. Nokia was designing the core chipset and letting Texas Instrument finishing the integration and physically producing the chips: Nokia was mastering the whole hardware IP of its phones, and was not relying on generic chipsets for the vast majority of its production, with all the margins it implies .

Feeling the wind of change: from one supplier, Nokia is transitioning to three, it has licensed its 3G hardware IP to ST (and presumably to Broadcom, rumors mentioned Infineon also), and will use some “generic” chipsets.

Texas Instrument has really missed the ball here, by stopping 3G investment (well they have made some, but failed delivering), and being mostly ruled by business guys with no technical vision of where the market were going: How a company with 70% of the billion units chipset market may leave it completely in such a short amount of time? Nokia diversification is part of the equation, for sure.

Nokia really seems to shift its focus: relaxing their efforts on the chipset front, they won’t simply try to cut internal cost, they will invest, and my guess (as everyone else ) is of course on Ovi, services, etc.

PR after PR, announcements after announcement, PR after PR, product after product, Nokia is showing how serious it is about reinventing itself again. It won’t happen overnight, but it is coming, and it may be a game changer!

As I’ve advocated not so long ago in those 2 posts about capuchin and what it means to fragmentation and the Adobe packager and the trend it shows toward runtimes (cross posted to VisionMobile here for capuchin and here for Adobe packager).

But Sender 11 really have for me the best argument about it:

But the strange thing is I don’t hear developers complaining much about fragmentation any more. They may be too busy creating apps for the iPhone and Android. A straightforward, low barrier way to monetize your app apparently trumps standardization any day. A way to make money is more important than a way to save money.

Morten Hjerde, What’s your developer story?

Well what else to add? Adapting a software to platform is only a 2nd order issue if you can monetize it. Thanks to all the AppStores.

Anyway really take the time to read the whole article, very good analysis about fragmentation, maximized with those “open-but-proprietary-platform-with-my-very-own-apis-and-my-very-own-store”  where there is 0 compatibility between an Android application and an iPhone one…but who cares?

Anyway I think the fragmentation issue will pop back with the explosion of different AppStores and new platforms (perhaps an actor has something to do here ), and I’m not convinced the browser will be the right way to do it.

Thanks Morten for this insightful article, hope to meet you in Barcelona!

There were rumors (here and here for example) about Apple using an an Intel Atom for its next generation iPhone, well they seems to be wrong: According to this New York Time article who found this out …thanks to a linked-In profile! :

Wei-han Lien, the senior manager of Apple’s chip team, dished out the morsel on LinkedIn, saying he’s busy at work crafting an ARM processor for the next-generation iPhone.

PA Semi NYT article (relayed from Electronista and TUAW)

So Apple, thanks to the 300M$ PA Semi buyout is entering the application processor design, but why? :

For a quick recap the hardware architecture of a smartphone is now pretty standard :

• a "big" cpu sporting all the applications and the high level OS: the application processor
• a 3G/2G modem chipset connected to the application processor, on which the 3G/2G protocol stack is running.
• a mix signal chip for power management and analog to digital conversions
• depending on the modem, a RF chip (connected to the antenna )
• …many various chips (wifi, Bluetooth being the most prominent)

The answer may be as simple as COST: After the phenomenal amount of money spent on 3G chipset modem development the real hardware margin are no more on wireless chipsets, but on the application processor themselves: see the very successful Texas Instrument OMAP line, the Samsung Arm line and others, versus the low margin, high risk 3G/2G chipset business of Infineon for example, or EMP, TI, etc…Qualcomm is a different story with their enormous IPR revenues, around 5% (!) of a mobile phone cost.

By making its own application processor, Apple will retain those margins for itself, while buying modem from other sources…and looking at the iPhone+iPod+whatevernewmobiledevice volumes we are talking here of perhaps hundred of millions of devices a year!  SO the savings, compared to the 300M$ buyout will be quickly amortized.

Of course the other big bonus when doing its own processor is that you can cram in it all the hardware acceleration you need for ….your software, and when your processor will be associated with only ONE OS, the possibility for optimizations (power consumption and speed)  are way above what a generic purpose processor may offer.

Any comments?

Thomas

Ok I admit, I have an iPhone. I love it,  blablabla you know the song already. It has its flaws, but as an old time mobile software engineer I’m really stroked by one BIG fact: The applications I use the most on it are fully web based!: My IM messenger (JiveTalk), my english/french dictionnary (Ultralingua), my mail and rss reader (special version of gmail and google reader) … even my all time favorite mobile game Bejeweled is web based!

What a shock I wasn’t prepared for that: when Steeve Jobs told us that the only way to add application will be (at first) through the web browser I was the first to laugh, only raw C++ is meaningful for applications, a web browser is a mere toy compared to a real application framework.

How wrong I was. And here is why. (and no it won’t be only about the iPhone)

• Unlimited and affordable data plan, and efficient bandwidth and coverage: I’m in Europe (France) and here network coverage and edge (2.5G) are very efficient.
• Webkit and Mozilla : Webkit engine tends to begin the defacto mobile web browser (check what pleyo is doing) embedded in S60, MacOS, Android…the only other credible contender is the Nokia Mozilla version (my Nokia N800 is simply unbeatable for web browsing).
• Raise of ad-hoc web services framework: the famous and numerous web widget frameworks (webwag being one to be noticed), and Yahoo GO for example.
• And the biggest one which is vastly under looked: modern websites, sorry webservices, are fully Model/View/Controller (ruby on rails, but above all struts2, etc.) what does it means in human readable language? : it is VERY easy to adapt the content/services of  a web site to different browsers / way of presenting data. Look at the plethora of “iPhone” optimized sites (ebay, dailymotion, facebook, etc)  that have popped up everywhere in few months.

Those approaches have something in common

• Need of a reliable wireless data link
• Well architectured network backend to provide optimized business data and adapted rendering data (the last one is not mandatory, check RSS for example were the business data has no notion of representation in it).
• An “On Client” web service framework: a browser with standard and added proprietary APIs like the iPhone Safari, a limited and fully proprietary engine like YahooGO, or a full OS with the complete stack like Android and … the iPhone OS (OK, don’t forget the “old” high level OSes like S60 and WinMobile).

Everything seems to be in place, and from what we saw above a good web service client platform would have to:

1. Be fun to use and compelling, tailored for each user
2. Be VERY efficient for the phone common tasks (phone call, address book)
3. Offer a nice and easy way to deploy data representation and flow control from existing web services backends…with good performance and relatively wide access to the underlying platform and datas

For me the first two doesn’t have to be understated (just try a WinMobile phone for a few months to understand what I mean ), as the device remains a phone, a communication machine and voice is still the undefeated champion for communication. This is where the iPhone is groundbreaking at a first sight…and also where I’m not sure of what Google Android will deliver (call me skeptical if you want…).

The third point may bring a lot of optimism … as it implies that we doesn’t need a single platform anymore, but a bunch of deployment possibilities, tailored for each devices/client or even each services . Android and  the iPhone may be seen as such a platform with at least two of those deployment possibilities: the browser and application native development, here Android is much more friendly to Java/Web programmer that the iPhone. But we could perfectly imagine devices with more deployment options or other completely different but close enough to web development standards to allow fast adaptation of web backends….why not an iPhone with an Android sandbox?

At the end the famous “cloud” (the network) is really shaping the “on device” clients, allowing more and more diversity and at there won’t be a “one fit all” solution…

Thanks Steve Jobs for being the first to have put in place all the elements of the chain, dealing with carriers, content provider, services providers…and coming with a great consumer electronic design.

Google wants to go further? not sure for now, but the US 700 MHz auction have to be followed very carefully cause if this spectrum becomes “free” of the carriers, we don’t know how fast it could go!

Found at All About Symbian:

Red Five Labs has just announced that their Net60 product, which enables .NET applications from the Windows world to run unchanged under S60, is now available for beta testing.

.NET on S60 3rd Edition now a reality?

This is really interesting: even the battle for languages/execution environment is not settled.

For years Mobility coding was tightly coupled with assembly code, then C and in lesser extent C++. The processor of choice is the ARM family (ok some others exist, but no more in the phone industry)…this was before Java.
Basically Java (the language) is no more than a virtual processor with its own instruction set, and this virtual processor, also called a Virtual Machine, or JVM in the case of java, simply do what every processor do: it processes some assembly code describing the low level actions to be performed by the processor to execute a given program/application.

On the PC other execution engines have been developed: the first obvious one, the native one is the venerable x86 instruction set: thanks to it all the PC applications are “binary compatible”. Then Java also, and more recently … the Macromedia/Flash runtime (yes Flash is compiled in a Byte Code which defines its own instruction set). An other big contender is the .NET runtime…with you guessed what, its own instruction set.

At the end it is easy to categorized the executions engines:

• The “native” ones: the hardware executes directly the actions described in a program, compiled from source code to a machine dependent format. A native ARM application running on a ARM processor is an example, or partially for a Java program that is running on an ARM with Jazelle (some Java byte code are directly implemented in hardware)
• The “virtual” ones: Java, .NET, JavaScript/Flash (or ActionScript, not so far from JavaScript: the two languages will be merged with the next version: ActionScript 3 == JavaScript 2 == ECMAScript 4) where the source code is compiled in a machine independent binary format (often called byte code)…But how an ARM emulator running on an x86 PC may be called? you guessed, virtual.

So why bother with virtual execution engines?
Java has been built with the premise of the now famous (and defunct ) write once run everywhere, because at that time (and I really don’t know why) people were thinking that it was enough to reduce the “cross platform development issue” to the low level binary compatibility, simply allowing the code to be executed. And we know now it is not enough!

Once the binary issue was fixed, the really big next one were APIs (and to be complete the programming model) … and the nightmare begins. When we say Java we only name the Language, but not the available services, same for JavaScript, C# or ActionScript. So development platforms started to emerge CDLC J2ME .NET framework, Flash, Adobe Flex, Silverlight, Javascript+Ajax, Yahoo widgets … but after all what are GNOME, KDE, Windows, MacOS, S60, WinMob ?…yes development platforms.

The Open Source community has quickly demonstrated that binary compatibility was not that important for portability: once you have the C/C++ source code and the needed libraries plus a way to link everything, you can simply recompile for ARM/x86 or any other platform. Hum I’ve made a big assumption here: you have “a way to link everything”. And this is really a big assumption: on many platforms you don’t have any dynamic link, nor library repository or dynamic service discovery…so how to expose cleanly your beloved APIs?
This is why OSGI has been made, like COM, Corba, some .NET mechanisms, etc : all is around component based programming, encapsulating a code around what it offers (an API, some resources) and what it uses (API and resources).

Basically an execution engine has to:

• Allow Binary Compatibility: Abstracting the raw hardware, ie the processor, either using a virtual machine or a clean build environment
• Allow clean binary packaging
• Allow easy use and exposition of services/APIs

But it seems impossible for virtual engines to dissociate the language(s) and the engine: Java …well for Java, ActionScript for Flash, all the # languages for .NET. An execution engine is nothing without the associated build chain and development chain around the supported languages.
In fact this is key as all those modern languages have a strong common point: developers do not have to bother with memory handling, and as all the C/C++ coders will tell you it means around 80% less bugs, so a BIG productivity boost, but also and it is something a tier one OEM told us: it is way more easy to train and find “low cost” coders for those high level languages compared to C/C++ experts!… another development cost gain.

A virtual execution engine basically brings productivity gain and lower development cost thanks to modern languages ….. we are far far away from “write once run everywhere”

But as we have seen before it is really not enough and here comes the real development environments based on virtual execution engines :

• .NET framework platform : an .NET VM at hearth, with a big big set of APIs, this is what I would like to know what are the APIs exposed in this s60 .NET port
• Silverlight : also a .NET VM at hearth + some APIs and a nice UI framework
• J2ME: a JVM + JSR + …well different APIs for each platform
• J2SE: a JVM + a lot of APIs
• J2EE: a JVM + “server side” frameworks
• Flex : Adobe Action Script Tamarin VM + Flex APIs
• Google Android: Java VM + Google APIs,… but more interestingly also C++: as android use Interface IDL description C++/Java interworking will work (I have some posts to do about it)
• …and the list goes on

So at the end what really matters is the development environment as a whole, not simply a language (for me this is where android may be interesting). For example the Mono project (that aims to bring .NET execution with Linux) was of few interest before they ported the Windows Forms (Big set of APIs to make graphical stuff in .NET framework) and made them available in their .NET execution engine.

What I haven’t mentioned is that the development costs gain allowed by modern languages comes at a cost: Performance.
Even if Java/.NET/ActionScript JIT helped partially for CPU (Just in Time compilers: VM technology that translates virtual byte code to real machine code before execution), it is still not the case for the RAM used, and in the embedded world the Moore law doesn’t help you, it only helps to reduce silicon die size, to reduce chipset cost, so using a virtual engine actually will force you to … upsize your hardware, increasing the BOM of your phone.
And it isn’t a vague assumption: when your phone has to be produced in the 10 millions units range, using 2MB of RAM, 4MB of flash and an ARM7 based chipset helps a lot let you make money selling at low cost….we’ve spent some nights/days optimizing stuff to make it happen smoothly very recently

At OpenPlug we have built a nice execution engine, not virtual, running “native code” on ARM and x86, with an easy to use service discovery mechanism: a component platform for low cost phones. Then we have added a development environment with tools and middle to high services….we have learned big time and sometime with pain all the bricks needed for such an environment! …

A key value may be around one framework and multiple execution engine for easy adaptation with legacy software and productivity boost for certain projects/hardware, or some parts of the software.

Because once you know how to cleanly make some code running independently from the hardware, you have to offer a programming model! Implying how to share resources between your modularized pieces of code…and in that respect execution engines are of no help, you need an application framework (like OpenPlug ELIPS, or Hiker from access, Android is about that, but also S60 and Windows Mobile): it will abstract the notion of resources for your code : Screen, Keypad, Network, CPU, memory, … this is another story, for another post!

Please comment!
Thomas

Found here:
IDIOT TOYS: Tech reviews for the bored: Nokia used to be better at coming up with phone names
(where did they found this name???)

 
How fast it is moving! The number of form factors is also something to think about: phones hardware will never be commoditized! Which is a good news for…software innovation.

Tags: Nokia

Ok exit the Motofone F3 here is the Sagem my150x : Today I had briefly this baby in hand from an insider. The screen in monochrome, but with a particular technology that looks like old LED based VCR. Notification icons are “hardware based” like the F3, menus are pretty simple and quite well readable with a good contrast, no T9 for SMS. I was impressed by the sturdy sleek and fashion design, and the really great tactile feeling of the case (really similar to the great smooth Samsung plastics).

But what is really amazing is its BOM: 16$ ! Some “rumors” are telling that it will be sold 29 euros in Carrefour. And it seems that in UK Orange to sell Sagem my150x pay-as-you-go phone for 10!

This is the first phone sporting the Infineon ULC mono chip…and this is great!

For further reading check the following reviews:

TrustedReviews – Sagem my150X and MobileGazette Sagem my150x