This is just from my limited experience trying to develop mobile software around 2002 (J2ME and investigating Symbian) and developing for Android and iOS nowadays.
I developed 3 apps on J2ME at that time and investigated Symbian. The impression I got of Symbian of that time was that it was painful to develop against. J2ME was less painful but very, very limited. Think no animation support, just bitmaps, and I have to write my own game run loop, collision detection, etc.... This was most probably due to the limited hardware of the time but nonetheless, it was primitive.
In comparison, iOS and to a lesser extent Android are basically fully featured OSs with mostly full exposed functionality. iOS gives you core graphics, opengl es, core text, core animation, grand central dispatch, networking, etc... Android gives you views, animation, background tasks, activities, intents, etc...
The distribution model was also broken. If you wanted something distributed, you had to basically go with a carrier. There were attempts at an app store but there were not successful.
Contrast this with the App Store, Google Play, and iOS enterprise development program where you don't have to go begging to a carrier to get your app distributed.
To summarize, Symbian was coming from a previous era and had no chance. If you compare RIM's situation to Nokia's, I bet you will see a similar chart.
Could you explain what you mean by "to a lesser extent Android"? Android lets apps add widgets to the home screen, replace the home screen, replace the browser, run arbitrary background tasks, and so forth. You can even sideload apps and create your own app store. None of this is possible on iOS.
iOS presents a programming model of MVC where the view can be anything. This is basically the same programming model as on OS X and similar to the programming model for windows if you use MFC. I found iOS libraries to be more traditional OS like and more mature. In contrast, Android forces you into activities, layouts, and intents. Layouts basically don't let you layout out things on a pixel basis unless you use the deprecated absolute layout. So Android is forcing you to try to write apps that work on a wide variety of devices and that interoperable with each other and they do this by forcing a different programming model on the programmer. How one transitions from one screen to another in iOS is how you would expect it to bd done in OS X or Windows. Android forces it via intents instead. Basically on iOS, I feel more in control except when the documentation is intentionally obscure but on Android I feel like I am programming in service of multi-device support, interoperability, and have to seriously limit the APIs I can use because over half of the devices out there are 2 major versions behind: no hardware acceleration and an animation system that has been replaced.
> Layouts basically don't let you layout out things on a pixel basis
It's a natural approach when you have devices with different screen resolutions and sizes. Pixel-based layout works well when all devices have the same screen size, but break horribly when they don't. BTW, I'm curious on how the iPhone 5 runs iOS 4 apps.
I am just curious but what changed after the iPhone? It seems like there were a couple of app stores (e.g. GetJar) before the iPhone, but I don't know if they differed before the iPhone or if they were basically a less popular earlier version. Did carriers have to approve apps that went into the store or did they have to approve the store as a whole?
The app stores were not built into the phones. You had to navigate to those third party app stores via the web and download them to your phone. But that web navigation was done via your computer rather than your phone itself. The phones were serving a baby form of HTML that had to be routed via through the carrier if memory serves.
Fascinating read. I always enjoyed my Symbian phones, since the interface was pretty damn good for the keypad form factor, and I have a big soft spot for sliders; the behind-the-scenes mess that grew out of the late-90s platform tech goes a long way to explain more about why quality apps were so few and far between.
True background multitasking on a phone in 2006 was really fun, though.
I pre-ordered a Nokia 5630 XpressMusic (S60) in April 2009 and recieved it late May.
It was awesome! Great camera-recording, WiFi, 3.5mm audio plug, good looking, slim. Maybe not a competitor to the iPhone 3g but I felt it was on par with Android devices at the time, and available at only ~260€ without contract.
This feeling lasted for 5 minutes, then it crashed. And it crashed again. And again. 20-30 times that night as I tried different features, before I just gave up. I started to regret my purchase.
It got better over the following year with updates but it never fully stopped to crash. Often it would crash while playing music, which really sucks for a phone sold to me as THE music smartphone. By June 2010 I had switched to a HTC Desire (which I'm still happy with, now with a custom ROM).
It is interesting to read in this post-mortem that 'Testability' was really hard on Symbian, and that problems or bad choices on how e.g. email polling should work, that must have been caught by engineering, somehow slipped through the cracks into the hands of customers.
If testability had been easy and quality the highest prio at Nokia, then the 5630 could have been the phone I still use, and I would have recommended it to friends back then instead of saying 'Stay clear!'. I might even have considered buying another Nokia phone. Things could have been different.
bear in mind that seeing why something failed (or is failing) is pretty easy after the fact, ridiculously hard to do before the fact. that said, i think many people saw the handwriting on the wall before "the fall", even at nokia. so, why did they continue to slip and become irrelevant in the smartphone ecosystem?
inertia. plain and simple. not market inertia - although that plays a part - but internal inertia. and nokia had around a decade of inertia, some of it is technical debt that gets harder to pay off, some of it comes from big customers and partners you acquired. but underestimate the weight of that at your peril.
every business has stakeholders, internal and external. when you recognize a significant shift must be made, these stakeholders still have to be satisfied. you have teams of people - customers, partners, business units - invested in the way things are. to make changes to your core technology and violate the expectations of those stakeholders is insanely difficult to pull off. RIM is going through this, as well. one cannot simply "just adopt android (or windows mobile)" and be done with it. you have to see contracts and expectations (e.g. core applications and solutions) through with those stakeholders.
clayton christensen did a great job of elaborating on this in "the innovator's dilemma", everyone should study it. this is a ruthless market with fickle customers - developers, end users (witness the crash of motorolla in about one year!), everyone you need to win over - and an insanely fast cycle, much faster than your platform and hardware development cycle. today's darlings will be tomorrow's road kill, they always are in this business.
Great read. I once did a project for S60. Initially I thought to use C++ but its implementation for this platform required to learn a lot of platform-specific quirks. I ended up implementing the project in Python. I'm really happy that I did not waste my time on learning the platform. This rises the obvious question: how to choose a platform that really deserves the effort to study it?
That is indeed a very good question. Other than waiting, it's one I have no answer to. The best technology doesn't always win as we all know. I remember being extremely excited about Moblin, a little puzzled when it switched to Meego, and downright disappointed as it slowly fizzled away, one paper cut at a time by a company with no leadership.
I was in total shock when they killed it. I think most people would be too if they just saw someone (in this case Nokia) commit suicide right in front of them.
I was going to make a version of Ted Nelson's Zigzag for the Symbian platform (circa 2002). It never worked out. I worried recently that I didn't catch the wave (eg, Symbian), but now I know that the iPhone changed distribution, and actually the time is ripe for Zigzag to take off on mobile phones.
Interesting: when I visit this doc (on Google Docs), there's a line at the top of the page that says:
"Wow, this file is really popular! Some tools might be unavailable until the crowd clears. [Try again] [Dismiss]"
This strikes me as a strange choice by the Google Docs team; rather than fixing the problem, they just tell you it exists. I mean, this is Google; don't they have lots of bandwidth and server capacity? Why can't they handle traffic spikes? Can anyone here shed some light on this?
The reasonable case for multi-person editing of a document is several people at the max editing the document concurrently.
Having thousands of people doing that is not a real-life scenario.
It's better to protect yourself from extremes like that by disabling editing functionality in that case than try to engineer a system that actually allows thousands of people editing a document concurrently (because it would be very expensive in engineering time and especially testing time).
There's literally no business case to be made for supporting thousands of concurrent edits - no one actually needs that functionality.
I don't think it's a matter of bandwidth. The document is being served up just fine; the only feature that seems to have been disabled is real-time commenting.
Google Docs, like most of their applications, is built on a highly available, globally-distributed database. (There's evidence that it was using Megastore as of a couple years ago, and I wouldn't be surprised if it's now been migrated to Spanner.) That lets them scale to effectively infinite numbers of users, but it doesn't solve the problem of handling thousands of concurrent readers and writers all contending for the same individual rows in a multi-TB table, from multiple datacenters around the world.
This is pretty normal behaviour in large scale software. We add 'circuit breakers' (usually time, memory and rate based) that prevent denial of service attacks and stop exposed algorithms breaking sensible time limits per request. The last thing you want is one customer causing quality of service problems for another.
Probably they have reserved bandwidth for paid Google Apps accounts, and although Google is a computing giant, it's bandwidth is not unlimited. And about fixing it, I don't think this is a bug, it's a feature.
Just my opinion.
Excellent article. The first part reminds me of the fragmentation and stupid decisions made for the Android ecosystem. More importantly, however, it really explains a lot about what happened _since_ the death of Symbian with Moblin and Meego as well as Nokia in general.
Quite a sad story, IMO, but unfortunately one they seem doomed to repeat with Elop "running" things. On the verge of what could have been the first GNU/Linux smartphone (N9) to take real market share, he killed both Moblin and Meego. It's amazing they still released the N9 and yet still switched to Windows.
Elop absolutely deserves a place next to ex-Sun's ex-CEO Schwartz as two of the worst CEO's tech or not in history.
tl;dr: Nokia is dying itself, slowly being killed by Elop. In two years or less, we'll probably get Nokia's postmortem, and it'll be a sad story for all.
I developed 3 apps on J2ME at that time and investigated Symbian. The impression I got of Symbian of that time was that it was painful to develop against. J2ME was less painful but very, very limited. Think no animation support, just bitmaps, and I have to write my own game run loop, collision detection, etc.... This was most probably due to the limited hardware of the time but nonetheless, it was primitive.
In comparison, iOS and to a lesser extent Android are basically fully featured OSs with mostly full exposed functionality. iOS gives you core graphics, opengl es, core text, core animation, grand central dispatch, networking, etc... Android gives you views, animation, background tasks, activities, intents, etc...
The distribution model was also broken. If you wanted something distributed, you had to basically go with a carrier. There were attempts at an app store but there were not successful.
Contrast this with the App Store, Google Play, and iOS enterprise development program where you don't have to go begging to a carrier to get your app distributed.
To summarize, Symbian was coming from a previous era and had no chance. If you compare RIM's situation to Nokia's, I bet you will see a similar chart.