Currently, I have an add-in/extension model (in .NET) that uses XML (for metadata) and dynamic loading, and when the application starts, only that metadata is loaded. Loading of the actual extension (which lives in one or more .NET assemblies) is deferred until the functionality it provides is used for the first time by the host application. Would something like that work with UWP as well?
Using an app service for extensibility seems kind of cumbersome to me, because it looks like it works like a REST service, out-of-process, and the amount of data you can send back and forth within one message seems to be very limited (64KB?). I can imagine this would turn out to be really slow for larger amounts of data (like raw image data, for example) and because nothing is shared, require a lot of unnecessary copying of memory between the host app and the extension. That's just a lot of overhead, so it would be really cool if it could work in-process as well to avoid all of that mess.
While this is great news, I think that extensions should be different from apps when it comes to managing them from the Settings UI. If there are only a few extensions it's not a problem, but if things really get componentized thanks to extensions, the list will explode and become cluttered, and it will be hard to recognize what's an app and what's an extension. There should be a separate list for extensions, maybe even ordered by categories (like "media extensions", "social extensions", etc.)
Another question is: Will there be a mechanism for deferred loading of extensions? It would be great if, for example (to go with the demo), the binaries of the extension that enables grayscale won't be loaded into memory until its functionality is required (by clicking the button). That would keep the memory footprint low at startup time. Right now it looks like as soon as you enable an extension, its getting loaded into memory even if it is not going to be used.
Even on Windows 10, I still use the good old Lenovo Power Manager from Windows 7 on my ThinkPad to set charge start/stop thresholds, so my battery stops charging at 90% and won't start until it drops below 30%, which works great given the fact I use the device plugged in whenever I can and I don't want it to trigger another charging cycle just because I unplugged it for a minute or hour and it's still well at, let's say, 60%, for example. I think in general, there are two things to keep your battery healthy: keep it away from heat, and keep the number of unnecessary charging cycles low.
Windows 10 tip: To install the Lenovo Power Manager under Windows 10, you have to run the installer (setup.exe) in compatibility mode and change the product name from "Lenovo Power Manager" to something else in the setup.ini because starting with the November update, Windows 10 seems to block it based on the name. The program itself works just fine, I don't really get why this tool isn't supported (or updated at least) anymore.
I really hope when they are finished with the mobile obsession and made that platform solid, they'll find some time to spend on the desktop side of things again.
WPF being phased out - isn't that the route they're going, if you read the signs of the time? I just went through the session list of this Build, and there's not a single one about WPF development except for a panel discussion (see here). WPF is like dead in the water for at least two years. No words on its future, improvements, if they plan to let it take advantage of the native XAML stack etc. I hope there'll be some folks asking the right questions...