Well-informed individuals have known about the upcoming death of the S60 platform some time – unfortunately, some (influential) individuals had Yucca leaves in their ears during the announcement and continue to peddle dangerous and wrong information.
David Wood has provided us with extra information, which can be had here.
The TamsS60 team sat down with its long-time friend and benefactor, David Wood. He talked openly about the next binary break – the full scoop is below:
Please tell us more about yourself & your current role at Symbian
I have spent more than 20 years envisioning, architecting, implementing, and avidly using smart mobile devices (devices that can also be called “personal electronic brains”): ten years with PDA manufacturer Psion PLC, and then ten more with smartphone operating system specialist Symbian Ltd. Since 2009 I have been part of the Leadership Team of the Symbian Foundation, with the job title “Catalyst and Futurist”.
As ‘Catalyst’, my role is to enable the Symbian software movement to discover and explore innovative solutions for the many challenges and opportunities faced by the mobile industry.
As ‘Futurist’, my role is to distil compelling visions of the future of technology, business, and society – visions that provide the energy and inspiration for deeply productive open collaboration among the many creators and users of mobile products.
Which role will Qt take in future releases of Symbian?
From Symbian^4, Qt will become the preferred programming environment for many parts of S60 app development. Qt is widely regarded as a productive, elegant set of class libraries, with a great deal of active community support.
Does this mean that the current way of developing S60 apps will be phased out?
Yes, the plan is that the current “S60 Avkon” APIs for the UIs of applications will be phased out. Other public APIs (such as for middleware and engine portions of applications) will continue to be supported.
For a developer who currently does S60v5 apps: what is the latest release of Symbian which will be able to run them?
These applications should run fine on devices built with Symbian^3. Engine level components of applications (which don’t use any S60 Avkon APIs) should run fine on later devices.
Will Carbide be discontinued?
There are no plans to discontinue Carbide. Carbide will continue to evolve and be enhanced.
Will the Symbian UI be changed significantly in the future? Will this endanger binary compatibility?
There will be significant changes – both incremental and (in the case of the transition to Symbian^4) revolutionary. There will be a large break in binary compatibility with Symbian^4 (emphasis by editor). Such a step is not taken lightly, but it seems to be the emerging view of the Symbian community that the large benefits of this break will outweigh the undeniable drawbacks.
The big picture here is that a change in UI idiom and development environment will result in very significantly improved productivity, and in turn in a huge range of impressive and attractive applications.
Could you explain us what Horizon does?
Symbian Horizon is an application-publishing platform designed to reduce barriers to success and increase the profitability of delivering applications on the Symbian platform. Horizon will provide a service that allows developers to write an application once, and publish in dozens of stores worldwide. See http://developer.symbian.org/main/horizon/ for details.
Anything you would like to add?
I encourage readers to become involved in the Symbian conversation – reading and commenting on the blog posts at http://blog.symbian.org, discussing developer issues at http://developer.symbian.org, and proposing and debating ideas on the future of mobile at http://ideas.symbian.org.
Related posts:
I am still VERY skeptical of this approach – the computing landscape is littered with bigger companies who tried this and failed (Palm, Netscape, BeOS are the ones that immediately spring to mind).
I live in hope Symbian sees sense and treats QT like MS did with MFC – as a layer on top of the Win32 API. The integration and deployment issues that discarding the existing UI and application integration infrastructure will cost cost third parties a bomb in time and money and I am not convinced Symbian have communicated enough to companies that they will HAVE to rewrite their applications for ^4 onward. With many people in Symbian battling to break even it will be a VERY hard sell to scrap working and existing code to start fresh with a new and unproven platform in one go.
From what I have seen so far QT can be layered on top of Avkon without binary breaks so why not adopt this model going forward. I am happy that Avkon is not going to be extended going forward but forcing a rewrite…
Of course when Nokia actually ship REAL products using QT rather than talking about it it may make it a more credible platform but certainly for the big faceless corporation I work for this is going to be one of those issues that will be “can we justify jeopardizing our multi-platform release schedule for a platform that is essentially new and going to require a significant commitment to rewrite, integrate, test, debug, endless partnering requests with Nokia for non platform API’s etc” – I dread to think the answer…
Hi – A few quick clarifications…
The body of the article is correct but I would not have chosen a headline talking about the death of S60 / Avkon. That’s misleading (though attention-grabbing):
a.) S60 will continue: there are huge amounts of non-UI APIs, which will be available to developers from S^4 onwards
b.) Avkon has a lot of life left in it in the meantime! It’s impossible to know for sure, but there could be 100s of million new devices shipped on S^1, S^2, and S^3, in the months and years ahead. That’s a huge opportunity for application developers to bear in mind.
Second to answer some comments from PaulT:
It’s true, Qt itself can coexist fine with existing Avkon and S60. It’s not Qt, but Orbit (the new set of UI elements) that causes the incompatibility. However, even with Qt and Orbit installed, the vast majority of Symbian platform APIs will continue to be accessible, as before.
>endless partnering requests with Nokia for non platform API’s
Happily, that’s something that the move to open source should render unnecessary!
The difficult question is: why not support Avkon alongside Orbit? That’s a decision for the Symbian community as a whole to take. It’s conceivable that some manufacturers might ship devices like this, but it looks more likely (from reading the discussions on the Symbian Developer Forums) that complete removal of Avkon will allow a more efficient software system that will also pose less confusion to end-users.
Another big question is: when should Symbian be talking to developers about this forthcoming change. Some people say “it’s too early to introduce this news” and others “it’s already too late”
So I think we’ve probably got the timing about right.
// David Wood, Symbian
Hi,
thank you all so much. Will post David Wood’s clarification in a jiffy!
All the best
Tam Hanna
Great news!
I hope that the break of binary compatibility means the end of the dreadful C++ dialect known as Symbian C++.
–
Paulo Pinto
I whole heartedly agree with “Paulo Pinto”. It is a huge pain to develop with “native” C++ on Symbian.
I must be among the minority people on the planet who love C++, but I wouldn’t do “Symbian” C++ for love or money.
In fact, I have skipped over C++, and jumped over to Python. While not as easy as it can be, it still is a much environment than the Symbian C++ dialect.
Most developers seem to think QT is a joy to use, and so I think it would be great to get it on Symbian.
I just hope that “Symbian” C++ (Enters, Leaves, 2 Phase Constructors, etc) is also dropped and we get a modern C++ platform.
Paul. Their might be a high risk of failure here, but to do nothing and keep the status quo is a certain suicide.
A real programing language makes sense, and the fact that Apple can pull it off with Objective C, is proof enough that Nokia can do it with C++. Those that want scripting languages such as python, javascript can breathe easy as Qt bindings for all of these exists.
The one thing I fear is the OS itself, what is Symbian OS ? How many developers out there know it. I think Nokia should take advantage of this pause and embrace Linux.
I applaud you Nokia for having the guts to face your troubles and to take the big risk to resolve them.
Hello Maemo!!
why not play to build a s60v3 emulator / virtual machine. Jeff Atwood has an excellent blog post about how Windows 7 has a version of Windows XP that can beused while in windows 7.
http://www.codinghorror.com/blog/archives/001258.html
also like how the plam pre could/can have a palm os emulator (not sure if its available yet)
http://www.downloadsquad.com/2009/04/02/palm-pre-and-webos-gets-emulator-for-older-palmos-apps/
that way you get the best of both worlds. While most are probably going to be happy with out old apps, people that need to run specific apps can use the new hardware/software as a viable option = D
Maemo, U there?
David,
We have a very large production Symbian enterprise application with hundreds of thousands of lines of ‘well designed’ OO code.
Last time Symbian decided to introduce a binary break it literally took us more than 12months of intense effort to get back to a stable version on the new devices. It almost cost us our largest operator channel. Most new APIs were defunct, incomplete, undocumented, and _all_ early devices on the new platform suffered from major stability issues for a very long time. We had to spend huge efforts working around these issues to ever slipping deadlines. Well working and stable APIs appeared to have been willy-nilly removed and replaced.
Promises were made at the time that this would never happen with Symbian again.
We understand and appreciate that you are trying to improve the extreme development complexities with Symbian, but the last thing we need are changes that render hardened production software useless. So please, please do not throw the baby out with the backwater. Many companies like ourselves have put thousands of hours into testing, verifying and trialing their Symbian software to production quality, and if you had any idea what pains you are creating for your partners by introducing such breaks, and the massively negative effect it has on Symbian’s reputation as a future proof platform, you wouldn’t even be dreaming about a forklift change of UI APIs.
Don’t get me wrong, we are very pleased to see the platform evolve with improved APIs such as Qt, but it should be a given at this stage that Qt is developed alongside Avkon for a gradual and binary compatible phase out, rather than an immediate replacement.
Look to the computing industry for some of the SW / FW platforms that have been able to sustain through multiple generations, such as e.g. Oracle (SQL), SUN (Java), Microsoft, Linux, Apple, Cisco (IOS), and Intel (x86). They always evolve, but NEVER do anything like this. It would be great to finally see a European company being able to do the same, so please now mature from supplying an unstable, inconsistent and fickle OS API set that can’t handle anything but cool, neat and quick little apps.
Dear “I”.
While your company may suffer I don’t think it is fare for to expect Nokia to tie its future to what it is easy or best for you, not when they are loosing market share. Some of the companies you mentioned did do major shifts. Are you still using MFC on windows? When will that reach its EOL? Things change in Linux on a daily basis, Apple went from Carbon to Cocoa (or was it the other way around).
Maybe your company needs to reinvent itself as well, if not others will gladly step in to fill the void (if any) left by your company. And to be honest the bus leaving town with S60 developers you represent is nothing compared to the legions of Qt developers out there waiting to join the party.
Concerning your hundred of thousands of lines of code for your well designed OO code – that’s really a small amount of source code. If you can’t rewrite applications of that size, maybe your OO design isn’t so great. Besides, with a better toolkit like Qt (which is far more then a GUI) you might be able to realise an order of magnitude in code size reduction. (Qt’s webkit engine lets you write a minimal but fully functional web browser in 10 lines of code)
Bottom line change, or get the hell out of the way.
Zing!
Let me try to summarise some of the questions raised in the comments above, and to supply answers:
Q: Why can’t the new UI system (Orbit) remain compatible with the old one (Avkon)?
A: If the new system is constrained to remain compatible with the old one, it will significantly increase the complexity of the new UI system, add to the run-time overhead (in terms of memory used and speed of execution), and will slow down its introduction.
Q: Is there really no way for a compatibility layer to be added, or for devices to contain both UI systems in parallel? Aren’t there advantages to a gradual transition between the UI systems?
A: In truth, this remains an open question. It is something for the entire Symbian developer community to review and debate. This discussion is just beginning to start in earnest.
Q: Why can’t Symbian give a definite answer about the future contents?
A: Symbian operates a model of open management and open planning for future platform releases. The community collectively reviews options. Decisions are made, in the end, either by software package owners (for smaller changes) or by Symbian Councils (for larger changes – such as this case). Symbian^4 remains in active planning phase.
Q: Is Symbian considering providing guidance to developers on converting applications from Avkon to Orbit?
A: Yes – though the details remain to be worked out.
Q: If someone wishes to become involved in discussions about this topic, what’s the next step?
A: Visit the Symbian Developer website, and take part in the forums there. Note that people who are prepared to make contributions of design and/or code will in general have more influence over discussions than people who merely request changes in plans.
// David Wood, Symbian
As a professional developer, I am going to side with “I” here. Introducing a new set of API’s and removing the old ones is a bad idea for a number of reasons. The ones I would like to add are 1) trust and 2) opportunity costs.
1) is simple, can you still trust a mayor player that is changing it’s mind all the time? Nokia (as the 800 pound gorilla) sure has it’s reasons, but you are either a provider of a stable computing platform, or you are not a provider of a computing platform at all.
2) if you need to port to a new set of API’s for the new platform of the same vendor, you should also investigate porting to a new set of API’s for a different platform of a different vendor. There could very well be more money there.
Can you explain the roadmap for Symbian in plain English please?
I never got pass chapter 2 of my coming 4 years old book regarding Symbian C++. And Binary break from version 8 to 9 is disappointing enough.
People who cry about Avkon departure and the gradual Symbian C++ framework replacement with the Qt one, cry not because they really liked Symbian C++ or because they cannot port their applications to Qt etc (all this are BS), but mostly because they were the few available players in a niche software platform / market, the present Symbian is.
With the advent of Qt to Symbian, this situation changes as new players (programmers) like my self, have the opportunity to get involved in the Symbian platform without even touching the dreadful Symbian C++ and the messy Avkon UI components (what makes the devious Symbian framework in few works!)
Competition will arise and old companies and niche Symbian programmers (with high revenues due to Symbian complexity) will have to either reform their products or die peacefully, that’s what’s crying about Symbian/Avkon is all about!