Tag Archives: iphone

iOS vs Android Revisited

So, it looks like I called that one wrong. Or did I?At first glance, it appears that android is a serious contender against the iPhone and IOS. It’s even arguable about which on is more popular at this point — do you measure by total units sold, or sales in the most recent quarter? What about the fact that Android is available on all carriers, but the iPhone is only on one?

Answering each of those questions gives you a different answer. However, one thing is certain — in a few short years we’ve gone from a marketplace seemingly dominated by Windows Mobile and Symbian to one where iOS and Android set the pace of innovation, customer expectations, and market growth. Both new platforms are here to stay, and rather than hurting each other, the response in the marketplace seems to be that each is accelerating the growth of the other by raising expectations for what a smart phone should be head and shoulders above the now-legacy platforms.

4 Reasons the Android vs iPhone Deathmatch Will Never Be

A colleague recently asked me who I thought would win the mobile phone wars: Apple or Google. He suggested that Android is a better horse to bet on because Google has virtually unlimited resources to spend until Android dominates the mobile phone market. From reading around the Internet, this seems to be a common misconception.

The expectation of an emerging dominant platform for smart phones comes from general experience with the PC industry, where there has been virtually a single platform for decades. However, the cell phone business is very different from the PC business: while market forces pushed the latter towards platform consolidation, there are several factors keeping mobile platforms distinct. Factor in Google’s self-stated motivation for entering this market in the first place and it becomes clear that the current fragmentation of smart phone platforms isn’t going to go away any time soon.


1: Cell Carriers Discourage Platform Consolidation

Partially by design and partially by nature, it’s plain impossible for a single platform to become dominant today. Cellular companies make exclusive deals with handset manufacturers, keeping phones out of the hands of consumers who would otherwise purchase them in a heartbeat. The exclusive AT&T and Apple deal comes to mind, but cell companies have been in this practice long before there was an iPhone. Hip devices draw new customers, and the manufacturer receives generous financial kickbacks to keep things exclusive. Additionally, some carriers use different radio technologies, which means that device manufacturer must develop different hardware to support all the different radio technologies around the world, adding expense and slowing hardware rollouts. This isn’t a factor which will go away soon.

2: The Market Has Legs

In 2009 a smart phone sales exploded. According to Gartner, there were sales of 172 million smart phones in 2009, a 24% increase from 2008, and that growth is expected to continue. This means that every company in the market can sell more units than the previous year without competing directly for customers. As long as this continues to be the case there is plenty of room in the market for multiple platforms. For some context, the ceiling for this growth is high. If all cell phones sold were smart phones (not an unreasonable long-term perspective) there would be 1.2 billion every year, so there’s quite a bit of room to grow.

3: Consumers Aren’t Sticky

In stark contrast to the PC market, smart phones are relatively simple to operate. Since the learning curve is lower, consumers are less likely to be afraid of switching to a different platform. Other factors gain relative importance. For example, consumers don’t put a high value on the shape and color of their desktop PC or laptop (beyond the basic form factor), but industrial design plays a more important role with smart phones. In part this is because OS tie-in is less important.

Consumers are also likely to switch between cell carriers every year or two, and when they do they are more likely to purchase the most cost-effective smart phone available with the new carrier. Statistically, this depends mostly on the promotions running at the time, if the same platform is even available. Apple’s exclusive AT&T contract, and Microsoft’s major revision to Windows Mobile are cases where users may not even be able to stick with the same platform if they wanted to.

4. Google Isn’t in the Mobile Phone Business

Surprise. Here’s a quick recap from Eric Schmidt from when Android was first announced:

The fundamental problem with most phones today is they don’t have full-power browsers. We’ve been taking our mobile services and use specialized engineering to get them on other devices. No longer … Imagine not just one Gphone, but a thousand Gphones as a result of the partnerships … I’m a very happy iPhone user. It’s important to say that there will be many, many mobile experiences, and Android will be used on many other kinds of devices…

Remember that when Android first came out, there was really no viable mobile web browser aside from Safari on the iPhone. Google makes their money on web search. Lots of people had phones, but couldn’t realistically use them to search, and Google therefore couldn’t make money from them. Google solved the problem by giving away a smart phone OS to any device manufacturer who wanted it.

So, while Google does have a bottomless wallet, there’s no reason for them to spend significantly more on cell phone development. Android simply has to be “good enough” to motivate smart phone competitors to improve the browsers on their phone. Google makes the money whether a user searches via an Android phone, an iPhone, a Symbian phone, or potentially even a Windows Mobile phone (should mobile IE ever become a reasonable browser). That’s why the pace of Android development has slowed as its uptake has accelerated. Google doesn’t need to dominate the market, because they don’t care which phone or browser you use, as long as you use one. To put it another way, Android is a stick they can use to herd the cell phone market in the direction Google wants.

Conclusions

The public likes competition, and the Internet will never stop pitting different platforms against each other. At first glance, Android and iPhone OS look like they compete against each other. However, the motivations behind their development are very different: Apple wants to sell hardware, while Google wants to spur users to browse the web from their phones. These goals aren’t mutually exclusive, which is why Eric Schmidt sat on the Apple board of directors until well after Android was released. Because of their respective philosophies, Google and Apple will never compete in the mobile phone space — Apple will never license their OS to other device manufacturers, and Google will never shift their revenue base to hardware sales (The Nexus One is another stick to hit device manufacturers with, not an attempt to make a profit for Google).

So, to answer my friend’s question, “who will win the mobile phone wars: Apple or Google?” I don’t think either will win, because there isn’t really a war – at least not between those two. Palm, Microsoft, Nokia, and Research in Motion are different stories altogether. Until the market hits the ceiling though, none of them are going to achieve market dominance anytime soon. It has become a game of staying power, and the only platform in any real danger is Palm.

The submerged iPhone: 6 months later

Six months ago I took my iPhone into a hot tub with me. It wasn’t on purpose – I had it in my bathing suit pocket (because, where else would you carry it?).

I immediately realized my mistake, and rushed to dry it off. If you search the Internet, you’ll find that the beat thing to do next is stick your iPhone (or other soggy electronics) into a bag of white rice. Rice absorbs water better than almost anything else. It will quick the moisture right out of your phone.

After 24 hours, I took the iphone a out of the rice and guess what? It worked perfectly! Well, almost perfectly. The screen was a little psychadellic, but that cleared up after a few more days as the cu al bits of water dried up, and then it was good as new.

Or so I thought. While I had survived the immediate risk of frying my phone, the moisture ha done some long term damage to the circuit board inside: it had allowed rust to start to set in.

Fast forward to today. 6 months later, my phone started acting funny. It claimed I had an incompatible device plugged in. All of a sudden, the battery only lasted a few hours. The circuit board had rusted and begin to short out.

Unfortunately, the water indicator was still bright orange, so apple wouldn’t fix it for me (rightly so). There’s nothing for it now; my iPhone is in the twilight of it’s life, ends early with electronic alzhimer’s.

Telnet Client Released for iPhone & iPod Touch

A Telnet client for your iPhone or iPod Touch! This client can be used for interactive communication with another host using the TELNET protocol.

It implements a simple terminal emulator, and can be used to connect to any standard telnet server including Linux, BSD, Solaris, OS X, Cisco, or even Windows as long as telnet services are enabled.

You can choose which host and even which port to connect to, which makes this useful for debugging web and mail servers.

Works over WI-FI or your Carrier Network.

iPhone SDK: Correcting BREW and J2me

Apple seems to be getting a lot of negative press on its recent SDK announcement. Much of the criticism seems to focus around two issues: That not all functionality of the phone is accessible via the SDK, and that Apple controls the distribution method to the phone. I’ll address the second point first. Some perspective on the history of apps on cell phones will do a lot to put this in perspective, and see why these decisions were made as tradeoffs, and actually strengthen the position of the iPhone as a leader in custom applications.

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.