The future of mobile development?
Published by Rafe Blandford at 18:32 UTC, February 25th 2008
Michael Mace has written an interesting post on his blog Mobile Opportunity about the fall of (native) Mobile Applications. The basic thesis of the post is that native mobile development is declining because of platform fragmentation, issues around certification, and marketing problems. Michael goes on to suggest that mobile development itself is not dead, but that it will increasingly move to the web as a platform. Read on for more.
The post has also been picked up by a number of other well known mobile blogs including Dean Bubley at Disruptive Analysis, Patrick at Just Another Mobile Monday, Stefan at IntoMobile and others all of whom are adding to the conversation.
For future trends in mobile development there has been a lot of discussion around the web as platform with proponents saying its solves distribution and fragmentation problems. However, aside from obvious capability issues, web as a platform has its own variations on the usual problems:
- Browser fragmentation exists too and causes some of the same issues as platform fragmentation (e.g. Apple iPhone web application are hit and miss on the S60 Browser yet they share the same rendering engine). Good developers can of course get round this by allowing for this in the way they develop, but precisely the same thing can be said about other development methodologies. With multiple platform a given on mobile for the foreseeable future we're going to have browser fragmentation too.
- People tend to think of the web and widgets as a universal platform, but it is not really true. Pure web applications are fragmented by browsers (and by add-ons such as Google Gears), widgets are not always compatible (e.g. S60's WRT versus Widsets vs Yahoo Widgets). It is fair to say these all use the same technologies and are therefore easier to port between, but native development is going that way too with the likes of Open C and Qt.
- Distribution and marketing can be just as tricky - getting people to a website may be easier than getting them to install an application. However once installed a native application is probably easier to access than a web based one (fewer access barriers). Incidentally this is one of the stronger arguments for Widgets (packaging web as a platform in a native application shell). The distribution and marketing issue is a universal one, each type of mobile development has its won strengths and weakness', but the basic issue is customer awareness and customer discovery.
I still think web as platform will be hugely important in the future and for certain type of applications it is the way to go. However I also think there is a current tendency to over value web as a platform (in the near term at least). Arguably the same thing happened with native mobile application development, with Java and with others.
My view is that mobile development has evolved as mobile device have evolved. Open software platforms are starting to reach the stage of (relative) maturity. The importance of the OS and UI layer as a source of innovation is decreasing reflecting this maturity. More activity is now focused around the software and service layer than ever before. I see Nokia's Ovi strategy as being emblematic of this. As such I think there are more opportunities in mobile development than there ever have been before as the scope of what is possible widens. An enabler of this trend is a proliferation in run time technologies of which the web is just one.
Each run time has its on benefits and weakness and each has a place because it is the best solution for a particular problem. I see mobile development as having a continuum of development types. For S60 we might consider Symbian C++, Open C, Python, Java ME, Flash Lite, WRT, Web. Developer should pick the best tool for the job.
| Symbian C++ |
Deeper system integration, application performance.
Multimedia applications, Complex Productivity Applications, DRM and Security
|
Native |
OpenC
|
Advantages of native, but increased portability,Applications using open source components or with common application logic across multiple platforms.
Database systems (Berkley DB), Telephony Services (SIP Stack), Games (N-Gage)?
|
| Python |
Rapid prototyping, low learning curve, used in academic institutions. May allow web based applications to integrate with system (e.g. Mobile Web Server).
Concept applications?
|
Runtime |
Java ME
|
Cross- platform on mobile, but fragmented implementations. Performance issues. SWT introduces native look and feel, but at portability cost.
Games, ported applications, clients to web services?
|
Flash Lite
|
Designing user interfaces and graphically rich applications. Allows designers into mobile development space.
Branded applications, basic games?
|
WRT (Widgets)
|
Combines web with some system integration (WRT). Expands potential developer pool.
Informational and transaction based applications?
|
Web |
Web
|
Web as platform
Best for connected applications that are transactional in nature?
|
S60 is also moving towards a transparent consumer model - the idea that all applications are accessed and behave in a similar way. The idea is that the technology an application uses (be it native C++, WRT or Flash Lite) is invisible to the user. All applications have an icon in the application launcher, all can be multi-tasked, all have a similar look and feel (or the potential too).
A similar story can be found, or will be found on other platforms.
Thus I think current trends in mobile development are less about the death of native applications and more about the need for developers to show increasing flexibility in the tools they choose to use.
The other benefit of a maturing market is that the numbers of customers are starting to become very significant. S60 announced 150 million cumulative device shipments. Actual users on the S60 3rd Edition is of course less, but annual sale volumes are trending strongly upwards. 2008 will see 70-75 million S60 device sold - a significant user base in itself.
But there is still a discovery problem. I've yet to see the universal answer to it and I wonder if there even is one.
Categories: Developer
Platforms: General, S60 3rd Edition, UIQ 3
News Discussion
Unregistered
I think Flash Lite and KuneriLite should also be considered. It's a smart solution for those problems now and in long term.
cheers,
N.
Unregistered
Just have a look at the iPhone. Apple said "web-apps are fine, they can do everything you need, you have better security, bla bla bla". What happened? Most people hacked their iPhone so that they could use native applications. And Apple? They try to release an SDK as fast as possible to keep customers satiesfied and prevent them from hacking iPhones. The reason is simple: You even want to use a smartphone in areas without coverage, and I think we all know that those areas will keep existing for many years. And things like gaming (especially in future, whit high res displays and multiplayer games) will suck too much traffic and need a low response time (high and constant frame rate).
And who said native apps are dead? An Ex-Palm employee (want Palm OS 6 or Foleo anyone?), what an irony...
tomsky
I think what all of the web-platform proponents are missing is that these are only really good for webby sorts of things. Google reader is good for reading news on the internet, so it doesn't matter that you have to be hooked up to an internet connection to use it. Likewise posting photos on the internet, or watching youtube: both internet activities that we accept we need a connection to use.
But when you want to find a contacts address or check your calendar, you don't want to be firing up an internet connection every time. Smartphones have exceeded their initial brief: to provide additional services while on a phone. People now want to use them outside of phone coverage and usage patterns. But the web only goes so far in giving us useful applications - sometimes we want to be off the grid.
rbrunner
For me it's astonishing and also funny to watch how many of those "smartphone platform" discussions fail to mention the most important: the *market* for smartphone applications.
That market has numerous problems, and fragmentation is only one of them. The size of the market is *tiny* so far, because of several reasons already discussed many times here. And because the market is so small, no real pressure can build up.
Let's make a thought experiment: Let's assume that for whatever reason people start to buy many more smartphones and software for them like crazy, so that everybody with half a brain notices that there is big money in this market.
And then, wham, growths stalls, and consumers get very angry, beccause they hit the wall of fragmentation.
Do you really think the market would not be able to sort the fragmentation problem out? If there is *real* pressure from customers and the lure of *big* money to make?
Certainly not, if you ask me. And also, facing real pressure, there would certainly be other viable options than the (from a technical/architectural point of view) completely crazy "web applications on smartphone" solution.
Like Unregistered 2 posts up I watched very closely what happened with the iPhone: There I can see that already a little pressure from demanding customers can go a loooong way. Already moderate market demand forced Apple to change course!
ajck
Rafe,
Good analysis but I have to disagree somewhat with your first two bullet points.
> Good developers can of course get round this by allowing for this in the way they develop, but precisely the same thing can be said about other development methodologies.
Speaking as a developer of both native run time apps (including J2ME here) and mobile web based apps, I'd say sure, browsers offer a fragmented platform, both for simple markup and also for more sophisticated interactive elements (AJAX and Widgets). But the key difference is in general terms browser differences can be comparatively "easily" routed around on the server using automated device capability databases and associated tools. The most notable being the famous WURFL combined with WALL (or WALL4PHP in my case) - this auto adapts mobile web pages to the device accessing. It will be a small leap to make this work for widget/AJAX differences (it's a bit early for this development to have occurred yet).
Native/J2ME apps are a whole different ballgame. One can't auto-adapt an app to thousands of different devices without much effort, if it's native or J2ME. Reportedly some 50% of time and budget of J2ME developers goes on porting for example. Porting Symbian to Windows Mobile to Android to.... would also be a big undertaking. With mobile web and adaptation technologies as above, you can successfully hit thousands of different device models with little effort.
2nd point:
> widgets are not always compatible (e.g. S60's WRT versus Widsets vs Yahoo Widgets).
I don't think this is a good comparison. Widsets and Yahoo Widgets are not really proper, device integrated widget platforms - they are fake platforms that rely on a J2ME or similar download. True widget platforms are WRT, Opera Mobile 9.5's, iPhone, etc. Though there are differences amongst them, they are generally aligned around Opera's initial standards push via W3C's widget standards efforts (early days yet on that). And, as mentioned above, widgets will be much easier to auto adapt than separate native binary applications.
However, widgets will not be a universal platform for a long time I think. They offer great potential through their ease of development, to millions of web developers, but developers targetting those millions of consumers with older or lower end handsets will still basically only have simple mobile web pages or J2ME with all it's fragmentation problems, for the forseeable future.
Cheers
Alex
phonething.com
Unregistered
Hi
Nice article. I'm not sure what you mean exactly by discovery, and if it means what I think you mean, then...you're quite correct off course.
I have been working on the discovery side for a number of years, and the problem with universal is that it has to be designed at universal levels. Perhaps, large corporations are already researching these discovery tools, but it is being kept under close wraps as trade secrets.
The trends we are continually witnessing are wave trends, following the money trends. These are market and product trends - usually of a very-short lifespan nature. I'm interested in thoughts around the future trends, those which won't change easily, as they might represent paradigm shifts.
Discovery poses as a paradigm potential. For example, as an introductory: what if handsets fell away completely? What would happen to all the apps and how would they be presented in a mobile environment without the integrated device we know now? How would we be communicating, using which tools, and which technologies? What would society do if their mobile empowerment (read social empowerment) was lost somehow? And last, which is the cheapest, simplest, easiest to use, most acceptable form of communication one could hope for in the next 5 years?
Just a few ramblings, but hopefully it got the ball rolling on this subject.
Full thread: 6 Comments / Post New Comment