Microsoft retiring Silverlight for WP7 app development? [Update]

There's been a lot of debate about the future of Microsoft's Silverlight programming language. Silverlight was first developed as a kind of alternative to Adobe's Flash for presenting web video and content but has also been used to make apps for Windows Phone.

While Microsoft released Silverlight 5 back in December, the company has been quiet about any plans to develop and release future versions. Now a new blog post strongly suggests that Silverlight's days are indeed numbered. The latest update on the official Windows Phone developer blog has Microsoft's responding to Windows Phone app creators with their concerns about what the future might be for making apps via Silverlight. Lieberman states:

Please don’t panic; XAML and C#/VB.NET development in Windows 8 can be viewed as a direct evolution from today’s Silverlight. All of your managed programming skills are transferrable to building applications for Windows 8, and in many cases, much of your code will be transferrable as well.

This statement seems to indicate that Silverlight development support is on its way out, to be replaced with XAML and C#/VB.NET development. We have emailed Microsoft for comment.

In the same blog post, Lieberman re-confirms that all apps made for the current version of Windows Phone will be able to be run on the next major update to the OS. He states:

Driving application compatibility is a function of Microsoft’s commitment to its developers. Regardless of what we release in terms of new developer features and functionality, we have made a large investment in protecting your existing investments.

Update: Microsoft has sent this response to our inquiry: "We have not made any announcements about future versions of Silverlight and have nothing new to share at this time."

Report a problem with article
Previous Story

New York removes sex offenders from online gaming services

Next Story

New Aliens: Colonial Marines in-game images released

31 Comments

Commenting is disabled on this article.

Gush, one would notice that WinRT is completely different horse compared to Silverlight. Silverlight is .NET+XAML anywhere, while WinRT is bounded to the Windows platform. Only a few with Silverlight skills will embrace the WinRT development, because since the Silverlight's death there is no such thing anymore as cross-platform cross-browser portability for .NET.

And because of this for most of the former Silverlight developers the obvious choice now is HTML5/JS. But why would they develop this web stuff specifically for Windows 8 with JS bloated with native calls? Why would anyone do that? Instead one would choose an architecture where HTML5/JS front end is running in any modern browser and simply connects to the cloud service. And as for a standalone application an embedded browser can be used (e.g. WebBrowser, Chromiumembedded) with backend written either in native or managed code (C++, Java, Objective-C, Mono C#).

And it will go like usual web development, no need for any specific JS API from OS. So the question is why so much effort put into HTML5/JS adaptation for Windows 8? Complete nonsense to me.

There was a straight forward path for the .Net framework becoming a fully integrated part of Windows while keeping the Silverlight platform alive for the cross-platform applications. And even more, Microsoft could provide better support for Mono, Moonlight and mobile .Net frameworks. That would have definitely brought a lot of developers to the Microsoft development ecosystem and thus flood Microsoft App Market with tons of apps.

Riva said,
A Microsoft employee confirmed during a chat that Silverlight 5 is the last ever release.

Correct... However do you understand what this actually means and what this changes?

The answer isn't hard, but this is a great example of information/knowledge not being equal to understanding.

Silverlight as a separate technology is done, but it is rolled back into expanding .NET and WinRT as well as creating the base frameworks that Microsoft will use for HTML5 standards based web content and even Apps.


Here is the short answer...
This essentially changes nothing, and is a good thing as it is 'progressing' Silverlight to have a bigger role. The name/term 'Silverlight' will no longer exist as a separate product/technology.

This statement seems to indicate that Silverlight development support is on its way out, to be replaced with XAML and C#/VB.NET development.

Silverlight development IS C#/VB and XAML.

If I was a Windows Phone developer i'd be ****ed at Microsoft's mercurial attitude towards API's and standardisation. They seem to flip platforms on a whim.

simplezz said,
If I was a Windows Phone developer i'd be ****ed at Microsoft's mercurial attitude towards API's and standardisation. They seem to flip platforms on a whim.
It's more of an update than outright change. Notice...Microsoft states WP7 apps will run on Windows 8. That means its compatible code that is being carried over. Much like many of Windows XP apps can run well on Windows 7 with no change to the application.

You need to understand what the article is saying, because like many here; you simply have no clue what you're talking about.

I think this is the closest Microsoft has ever come to confirming the rumors that Windows Phone 8 will be built on Windows 8 and not Windows CE...

JonathanMarston said,
I think this is the closest Microsoft has ever come to confirming the rumors that Windows Phone 8 will be built on Windows 8 and not Windows CE...

Yup, this seems to hint that WP8 will go with WinRT as it's development platform and with that developers could thus be able to write an app, though with 2 different UIs, and target WP8 and Win8 in one go. This could also open the door for some tighter PC to phone interaction between apps if you have the same ones installed on your phone and pc. MS should also be able to combine the phone and PC app stores going forward, though that'd be a harder task I'm sure.

JonathanMarston said,
I think this is the closest Microsoft has ever come to confirming the rumors that Windows Phone 8 will be built on Windows 8 and not Windows CE...

yeah, but does that mean developers will need to recompile their WP7 apps to be compatible with WP8?

х.iso said,

yeah, but does that mean developers will need to recompile their WP7 apps to be compatible with WP8?

Maybe they'll write some sort of compatibility layer above WinRT to emulate Silverlight.

х.iso said,

yeah, but does that mean developers will need to recompile their WP7 apps to be compatible with WP8?

No, MS today said, officially, that all WP7 apps and games WILL RUN on WP8. I don't see why you'd have to change anything, it's SL/XNA and by nature those run just fine on Windows. So while the core can change from CE to NT the frameworks should still run just as well.

It's all in the same article posted above but for whatever reason neowin left that part out it seems.

"With regard to existing applications: today's Windows Phone applications and games will run on the next major version of Windows Phone. Driving application compatibility is a function of Microsoft's commitment to its developers. Regardless of what we release in terms of new developer features and functionality, we have made a large investment in protecting your existing investments."

х.iso said,

yeah, but does that mean developers will need to recompile their WP7 apps to be compatible with WP8?

No, that is the whole idea of the .NET model of WP7.

WP7 is really brilliant in seamless portability, as the hardware can change, the kernel can change, the .NET layer can change, and the OS Silverlight Platform can change, and yet the current set of Apps will still just work...

(This is the type of portability and cross platform vision that has been a holy grail for decades, and exists today for the first time with WP7 and Windows 8.)

xpclient said,
When WP7 launched, Silverlight was THE platform for app development. WinRT has resulted in MANY casualties.

Not really, the web and HTML5 are essentially the Microsoft vision of the web and the foundation of the XML/DHTML technologies they started a long time ago.

Waiting for the web to catch up, and not expecting the W3C would ever get to something as cool as HTML5/CSS3 techologies, they went ahead with WPF/XAML/Silverlight, which uses the same 'conceptual' model.

What has happened is that HTML5 is close to converging in features to Silverlight/WPF.

Microsoft has also been able to demonstrate amazing performance of HTML5 though IE9's new browser paradigm shift to a 'content compiler and runtime' instead of a 'content viewing application', as IE8 and other browsers work.

Next you add in .NET's CLI standards, and the newer 'user interface markup' extensible features like the CLI for the programming side for being language agnostic, and you can throw C# and Silverlight or Javascript and HTML5 through .NET with essentially the same level of performance.

Windows 8 is already filled with this technology and shows the WinRT/.NET/IE technologies converging to offer a really broad platform model that is fast and lets developers use whatever they like or need all the way to being essentially a W3C HTML5 standard RIA, but running as a Metro App.

Nothing has been destroyed or wasted, it just has come together as people like myself have been talking about since the first glimpse of IE9 and the changes in .NET along with the Silverlight push on WP7.

jasonon said,
good choice. keep focusing on native code and html5

what native code? HTML5/JS is the worst and most idiotic thing to use to write apps for an operating system.

Microsoft as always dumb as a brick and trying to push something because it's hyped up in hopes to get positive points by doing so.

JS is the most retarded scripting language created decades ago and has been patched to a frankenstein it is today and we should go and use it to write apps for an OS.

Jesus christ

Good luck to them I say. They have FAIL written all over Windows 8 and Windows Phone.. it's Vista and Zune all over again and hopefully they will learn something from this failure.

Boz said,

what native code? HTML5/JS is the worst and most idiotic thing to use to write apps for an operating system.

Well, the point is that the WinRT as a whole is intended to write only very limited and primitive applications. HTML5/JS is a good fit there. Win 8 in MS's vision is no more a system for serious application development, it is an overgrown smartphone.

Edited by xendrome, Apr 6 2012, 8:06pm :

Boz said,
it's Vista ... all over again and hopefully they will learn something from this failure.

Oh joy, another bandwagon rider.

Boz said,

what native code? HTML5/JS is the worst and most idiotic thing to use to write apps for an operating system.

Microsoft as always dumb as a brick and trying to push something because it's hyped up in hopes to get positive points by doing so.

JS is the most retarded scripting language created decades ago and has been patched to a frankenstein it is today and we should go and use it to write apps for an OS.

Jesus christ

Good luck to them I say. They have FAIL written all over Windows 8 and Windows Phone.. it's Vista and Zune all over again and hopefully they will learn something from this failure.

Really? So this means you must REALLY hate iOS and Android, since their entire Application model is designed around a JVM and Runtime?

The language in terms of performance is irrelevant when running at the Application layer through a dynamic runtime especially.

Just to put this in perspective, there is the old argument of native C++ code vs C# on .NET, which has shown that C# is as fast and sometimes faster than C++ native code due to the flexibility of the dynamic nature which can load faster, and execute faster as the .NET runtime is smarter than static code, which can adjust itself and how the code is executed. (Part of DirectX 9 is written in C# back when it was not nearly as optimized or fast as it is today, and even still DirectX 9 is faster than OpenGL that is very much pure native code C, C++.)


So with a dynamic runtime that can hit native code performance, especially on the NT or WinCE kernel and OS models, the actual 'programming language' and the separate 'interface language' become fairly irrelevant, as .NET was designed around the CLI for the CLR, meaning any language can be used on .NET (some dynamic typed languages being the only exception.)

So this means that it doesn't matter if the back end code is written in C# or VB or Pascal or Python or Perl or Ruby or F# or Cobol or Smalltalk or PHP .... and this is a really LONG list - the resulting .NET executable will have virtually the same performance. (The CLI is why there is so many languages supported, easily, and the CLI of .NET is now a 'standard' that is open for anyone to work and provide a language or create a new language that will work on .NET)

Since JAVASCRIPT/JSCRIPT also have CLI versions, it also runs on .NET, and will performance as well as the languages mentioned above.

So even though I agree Javascript kind of sucks, although it is getting better, the performance it offers on .NET and WinRT is fast, and can be as fast and even faster than native code at times.

The Microsoft compiler and .NET technologies is why this is possible, as there is the agnostic CLI allowing any language, and the CLR of .NET and the various execution models/modes of .NET and with 3.0 of .NET it also adds the 'user markup language' aspect at the visual level, which was originally only WPF using XAML, but has changed to become 'agnostic' as well and now supporting web standards markup languages like HTML5/CSS.

So at the interface level, whether it is XAML Silverlight, XAML WPF, or HTML5 the effective performance is going to be essentially the same.

Now add in how they got there with new technologies in IE9 that change the browser from a 'web content display application', to a 'web content compiler and runtime environment', you can see IE9 already shoving out HTML5 examples that are near native code speeds even doing rather graphically rich and complex things.

This technology is then wrapped back into .NET and is a part of WinRT for Metro Apps as well, creating a level of RIA performance not previously thought possible.
*(IE9 on a WP7 can run RIA HTML5 based demos faster than Chrome on your desktop.)

As an example of how close to native code speeds IE9 can handle Web content, I can use one simple example. Google Chrome had to use direct GPU code via WebGL that uses OpenGL to get 'similar' performance of the IEFish demo that IE9 was doing in straight up Javascript and HTML5.

(Google called it an HTML5 demo, but it was really just an OpenGL demo being drawn in Chrome, which is not a part of HTML5, nor a standard, and WebGL is also a high security risk with direct GPU access from web sites.)


The other part of this you are missing, is that WP7 is the subject here, and Android and iOS are already JVM/runtime based, just WP7 already does as well with the .NET CLR and Silverlight Application platform.

And still WP7 is amazingly fast using the .NET technologies, which are faster, more mature and more featured than Android's Dalvik JVM or iOS's dynamic runtime.


So this isn't a big change whatsoever, even if Microsoft goes complete HTML5 and Javascript only on WP7/WP8, it will be just a different markup and programming language, the performance will remain the same.


The other part overlooked is WinRT which is for Metro and is from Microsoft's IE9/IE10 team, the .NET/WPF/XAML/Silverlight technologies, and other Windows programming technologies converging.

So Metro Apps using WinRT on Windows 8 itself are already running Javascript/HTML5 Apps at amazing speeds.


Microsoft really isn't stupid, they have truly the brightest software and hardware engineers in the world, and if they seem to think that WinRT or HTML5 on trident or HTML5/Javascript on .NET will be fast enough, they probably know what they are talking about and have tested it quite extensively.

If Microsoft had any doubts or didn't understand the shift in the world of programming and the features that HTML5 now offers, they wouldn't be giving up their technologies like Silverlight, especially on WP7, as they have no compelling reason to do so.

Most of silverlight tech is in WPF. Most silverlight developers already know this, so its no biggie.

ekw said,
Most of silverlight tech is in WPF. Most silverlight developers already know this, so its no biggie.

Well yea it would be, since silverlight is a derivative of WPF, that used to be called WPF/E where the "E" stood for "Everywhere"

Also WPF is IMO a rather dead technology as well, since MS has been rather silent in regards to talking about plans for its future.

ekw said,
Most of silverlight tech is in WPF. Most silverlight developers already know this, so its no biggie.

This. One million times. As someone who taught themselves silverlight over the course of 2 years, the transition from SL to WinRT was rather painless.

greenwizard88 said,

This. One million times. As someone who taught themselves silverlight over the course of 2 years, the transition from SL to WinRT was rather painless.

You just hit the nail on the head right here. If we listen to the WP8 rumors that it'll share code with Windows 8 then the next development platform for WP8 will be WinRT as well, or a slimmed down version for the phone. Probably slimmed down since there should be a number of PC/Desktop specific APIs etc that you can't apply to the phone.

Regardless shifting Windows Phone development off of SL/XNA and over to WinRT kills two birds with one stone the way I see it. First it still keeps full compatibility with current WP7 apps and games which is something MS has said officially already, thus like you said moving devs from SL to WinRT shouldn't be very hard. And second and probably a bit more important, going with WinRT on the phone should also open up devs to using "native" code seeing how WinRT lets you use C++ etc, something devs have asked for on the phone since the start.

GP007 said,

Regardless shifting Windows Phone development off of SL/XNA and over to WinRT kills two birds with one stone the way I see it. First it still keeps full compatibility with current WP7 apps and games which is something MS has said officially already, thus like you said moving devs from SL to WinRT shouldn't be very hard.

I don't know where you've heard that current WP7 apps will be supported through WinRT, but that's not going to be the case. WinRT has a different set of libraries; it is a different framework. The .Net framework (or a subset) will need to be included for support for those applications.

SharpGreen said,

Well yea it would be, since silverlight is a derivative of WPF, that used to be called WPF/E where the "E" stood for "Everywhere"

Also WPF is IMO a rather dead technology as well, since MS has been rather silent in regards to talking about plans for its future.

This is where people disconnect intellectually...

HTML5 technologies are what WPF/XAML/Silverlight are about. The declaritive interface technology separate from the code, with very powerful capabilities.

In the late 1990s, Microsoft's 'proposals' to the W3C were very much what we see HTML5 being today, and sadly the politics from Sun and others killed it then. (Which is why everyone back then made fun of XML Word documents and custom fonts on a web page, how silly was Microsoft. *cough*)

The 'model' of what HTML5 and the direction of RIA technology is taking is creating the vision of what WPF and other Microsoft technologies from the late 90s were trying to create.

IE9 helped Microsoft 'see the light' on this as well, by redefining the browser as a compiling technology to run Web content instead of a document display application like other browsers are still designed. This created the layered model in the new IE9/IE10 that also moves DHTML concepts to a JIT compiled set of code.

The IE9 shift at Microsoft also demonstrated that HTML5 technologies when more content is 'compiled and ran' can have near native speeds, sometimes faster than WPF/Silverlight when running the same concepts in IE9 via CSS3/HTML5.

So this is a good thing, and IE9 on WP7 is blazing fast, still beating iPad/iPhone/Android on graphical web content that would have needed the .NET/WPF/Silverlight infrastructure to get the same performance just a few years ago.


care factor = 0.

I did install silverlight once, but deleted it not long after. Despite Windows update constantly harrassing me to install it, i haven't done so for years, and never will!

dvb2000 said,
care factor = 0.

I did install silverlight once, but deleted it not long after. Despite Windows update constantly harrassing me to install it, i haven't done so for years, and never will!

Obviously, you don't have a clue what the article is about.

dvb2000 said,
care factor = 0.

I did install silverlight once, but deleted it not long after. Despite Windows update constantly harrassing me to install it, i haven't done so for years, and never will!

Clueless.