The Silverlight 4 plug-in is actually very small, about 6MB (a lot smaller than Flash). as in preventing the plug-in from installing. Silverlight would work just fine on iOS Safari just as it does on OSX, but APPLE block it. soooooo, it's clearly Apple doing the blocking on iOS and NOT Microsoft's fault at all. this is not Microsoft's problem, this IS APPLE blocking a plug-in.īut to further help you folks understand, Silverlight 4 runs just fine on OSX under Safari. Flash is a browser plug-in - blocked, Silverlight 4 is a browser plug-in. The short version is that any change that renders Flash unacceptable also takes out Silverlight.

They're not enough to make Silverlight possible. Apple's rigidity and often capricious rule changes are the problem here, not Microsoft.Īnd yes, I'm aware of the rule changes in Sept 2010. That's simply not the case, as shown by the fact that they've been writing Silverlight for MacOS for since the first version and want to port it to iOS. Your implication is that it's simply a choice by Microsoft to 'not support' iOS and thus it's their fault. That's directly because of a decision Apple made. Since trying to make Silverlight work WITHOUT an interpreter or a local compiler is very difficult and would essentially cripple Silverlight to the point of being unusable, there really isn't a point in doing it. They already have a version for MacOS - they've made versions since Silverlight 1. If Apple removed the 'no interpreter' rule, then Microsoft could have Silverlight on iOS in a second. BUT, by the same token, Apple's arbitrary rules impact other company's decision making process and determines the cost-effectivity of taking on a project. In the most literal of senses, Apple doesn't have to do anything for anyone (except where required by law) and so yes, everyone else has to accomodate Apple. There really IS no way to 'adapt' Silverlight to iOS in any way that's meaningful.Īnd you're kind of playing a semantic game here. More to the point, to comply, it would end up being a far more rigid development system or it would be entirely unusuable. The only way Microsoft can make Silverlight work on iOS isn't as much an 'adaptation' as 'a complete redesign and implementation in a way that makes it into something entirely other than what it is now'. Silverlight is a system, not an app - inherent in it is the fact that it will require an interpreter, or a local compiler of some sort. Net and Silverlight from day one - and Mono supports both platforms as well and iOS is essentially a stripped down version of MacOS - so Silverlight for iOS already exists (or is close). They've had a MacOS version of both the full. So, no - it's not a question of Microsoft getting around to doing it.

The 'must be written in ObjC' restriction put the final nail in the coffin. Net IL to native translator which would have gotten past the 'no interpreted languages' restriction. The Mono group had already released a 'Mono for iOS' which embedded a lightweight version of the. Net and Mono (the open source version of.

Worse, they also added a requirement that any app MUST be written in ObjC and compile to native code. While it's generally agreed that this was a direct shot at Adobe Flash, it had the side effect of taking out Silverlight and Java. Apple made a policy change with iOS 4.0 that expressly forbade any kind of interpreted language or virtual machine on iOS devices (other than ones they themselves wrote, of course).

Silverlight for ipads