This past week, Microsoft finally began to lift the proverbial covers off of the next version of their Windows Phone operating system in Windows Phone 8.While the presentation around Windows Phone 8, made at Microsoft’s Windows Phone Summit event in San Francisco, was anticipated by a number of audiences, the majority of the messages made over the period of around 2 hours were focused on one audience in particular – developers.
I’ve had the fortune of “wearing many hats” when it comes to mobile technology. I have traditionally been the classic “power user” when it comes to daily usage, willing to push the boundaries of any mobile platform put in front of me. I also have worked extensively over the course of the last ten-plus years with IT end enterprise organizations to leverage and cope with the constant change mobile technologies present in the workplace. Finally, a good part of over 20 years of application design and development has been focused on either directly building mobile solutions or crafting solutions that integrate mobility. It is the developer in me that watched with the greatest intent as Microsoft began to unveil its story for the future of Windows Phone.
I’ve had some time to think about all that was presented at the Windows Phone Summit event. As a result, I have a lot of thoughts around a lot of things. A lot of these thoughts are also creating a lot of new questions that will only be answered with more information from Microsoft. What follows are just a few of my “musings”…
Microsoft’s move to a more common core for Windows Phone 8 in relation to Windows 8 RT and Pro will really have application designers and developers alike thinking about opportunities. Greater alignment leads to faster development across platforms. As a result, there are more things to consider, some even before a line of code will be hammered out. Some examples –
- Does my application as a single entity have relevance across all platforms?
While this question may seem simple enough at the surface, it gets more complicated when you think about the fact that not all use cases are applicable across devices and form factors. Take the case of an ERP (“Enterprise Resource Planning”) application. The desktop use cases may be massive, but do they all apply to someone out in the field using a phone? Ideally, applications where all use cases work for all platforms would make for a single application solution, but experience says this is not usually the case. There also needs to be some caution to avoid the temptation to just develop one solution, as this leads to the old dilemma of “shoving a desktop application into a mobile device”. While hardware has come a long way, there is still the issue of usability.
- How common is “common”?
While we know about shared common core code and capabilities across the Windows 8 platforms, there is a lot of “the devil is in the details” to consider when actually building across platforms. It will be important for Microsoft to get to the details here for some developers. This is something that will likely not be answered until the Windows Phone 8 SDK becomes available “later this summer” (Microsoft’s own words). It will, however, likely impact some applications from a design perspective, with no details resulting in no direction.
- How can one be “platform-aware”?
The other side of the “all-in-one” application across platforms solution is a design that attempts to target functionality based upon a given platform. This approach, however, hinges on some important (but yet to be disclosed) information. One question that comes to mind revolves around cross-platform binary compatibility. Will we be “compiling once and running everywhere”, or will we be targeting compiles across platforms? Another question -will there be something more than screen resolution at runtime to determine what our application is actually running on? Will we be given more granular information from within a running application in order to dynamically respond? These types of questions will, yet again, have an impact on application design approaches. The longer the wait for answers, the later applications will come to market.
To migrate or maintain?
Microsoft has already committed to supporting existing Windows Phone 7.5 applications being compatible without modification for running on Windows Phone 8. While this allows for some simple compatibility (and sales) for any one application, there may be more at hand for a developer to think about before making a decision to simply “stand pat”. For example, –
- Is native code the better way to go?
Windows Phone 8 brings back the ability to develop native code applications using C++. Now, Microsoft was very clear during the Windows Phone Summit at “providing guidance” regarding managed vs. native development. According to Microsoft, native code is for games, while managed code is for… well, everything else. Microsoft did not say, however, if there will be native code limitations that will prevent using native code beyond game applications. Furthermore, Microsoft did not elaborate on possible design solutions that could leverage a combination of the two (for example, native assemblies but a managed UI layer).
For game developers, it seems very clear cut that migrating from XNA and managed code to C++ and native code is the way to go. For everyone else, there are still some questions to be answered. Native code definitely provides performance benefits in some areas (graphics being one obvious example). But what about other areas? Will file/data access be better served with C++ coding. And if a developer can choose this route at first, will Microsoft tighten it’s stance in the future, limiting only to graphics with Direct3D? Native code development will definitely be enticing for many, but without a clearer statement of direction from Microsoft (beyond the initial general guidance provided last week) there will likely be a trepidation to go down this path.
- Can I maintain multiple versions of an application?
So, I have an application running under Windows Phone 7.5. Fine – I’ll keep that version in tact, then build a new version using Visual Studio 2012 and the Windows Phone 8 SDK (the new version will take advantage of whatever it can, but the old version might still have enhancements). Sounds great, right? Well, a couple of questions remain here as well. Will the Marketplace support multiple versions of my application. While you would think the answer is yes, don’t forget that Microsoft first denied that capability between Windows Phone 7 and 7.5. They did eventually change that, but now they have changed yet again by restricting access to the Windows Phone Marketplace to only devices running Windows Phone 7.5.
There is also the question of development tools support. Will Windows Phone 7.x development make it to Visual Studio 2012, or will we (yet again) have to maintain multiple versions of tools? And what about those (myself included) who already have to maintain Visual Studio 2008 in order to support the .NET Compact Framework and Windows Mobile 6.x applications? Will the “3 VS versions” scenario even be realistic? There is a lot of open ground here, and the ramifications are quite large. This is one areas Microsoft must address sooner rather than later.
- How exactly do we deploy an enterprise Windows Phone 8 application?
Microsoft talked at a very high level about LOB application deployment at the Windows Phone Summit. They also provided a “demonstration”. Well, not really. What they showed was a sample application that served as a sort of “Enterprise Hub”. Unfortunately, I have since seen many references to this application, all inferring exactly the opposite of what Microsoft clearly stated it was not. Let’s be clear here – Microsoft clearly (and multiple times) stated that -1 – This was an example of what an enterprise could develop as a way of providing information and delivering LOB applications to their employees. There was no statement that this was a built-in application for Windows Phone 8 or that this was the only way an LOB application could be deployed.
2 – This application would be available to developers as a reference for crafting their own tailored solutions. This infers something similar to the “Starter Kits” that Microsoft has made available in the past for use by the development community.Of course, this leads to the question “How exactly do we deploy an LOB application”? Well, it has been mentioned that, much like iOS and Apple, that there will be an enterprise version of the Windows Phone App Hub (the developer portal). LOB applications will still need to be signed in order to be installed. The question, however, is whether or not applications can be truly “side-loaded” after signing. True side-loading would allow, for example, the application to be placed somewhere where it can simply be downloaded/copied and installed – no questions asked. If, however, Microsoft still requires that the application still reside in the Windows Phone Marketplace infrastructure but is only exposed through a “deep link” (i.e. – not exposed through an user interface), then there will likely still be some aversion to development from some enterprises as a bit of intellectual property control is lost. It is important to note that both Apple and Google do allow for side-loading of applications today; if Microsoft still does not do this with Windows Phone 8, there is the potential for some bad karma from the enterprise.
- Define “Device Management”, Please…
Microsoft briefly touched upon device management capabilities for Windows Phone 8 at Windows Phone Summit. When I say “briefly”, I mean a couple of sentences, with the most notable mentioning that Windows Phone 8 devices would be managed in similar fashion as desktop computers. This incredibly vague statement has huge potential impacts to enterprise developers, as many organizations will not deploy LOB applications without the guarantee that device management is possible.
If one were to take Microsoft’s statements as literal, it would infer that, at the least, Microsoft will support device management for Windows Phone 8 through either Exchange Server mailbox policies (something it already does today with Windows Phone 7.x and with Windows Mobile 6.x), Microsoft System Center Configuration Manager 2012 or InTune (for cloud-based management). However, all of these solutions currently rely on Microsoft Exchange Server, and are really limited in terms of “device management” (device PIN/Password policies for Windows Phone 7.x). Is Microsoft taking this further with their solutions for Windows Phone 8? We simply do not know.
For those enterprises who currently utilize third-party cross-platform device management solutions, it is very obvious that the ability to manage Windows Phone 7.x devices is severely limited. The reason – there is really nothing exposed to developers of device management software in the way of APIs to support effective device management. For these enterprises (and, more importantly, their solution providers), the big question is “What is Microsoft doing to enhance and extend device management functionality through developer APIs?” Once again, nothing is really available at this point. It is reasonable to assume, however, that if this story does not change, there will still be enterprises wanting to develop LOB applications that simply will not.
Microsoft’s Windows Phone Summit event was a relief in many ways to developers. There was some story to be told. However, like all good stories, the table of contents whets the appetite but makes you hungry for more. With only a few short months until what is expected to be the launch of Windows Phone 8, there are still a lot of developer stories to tell and questions to be answered. Personally, the developer in me is extremely excited by the potential of Windows Phone 8. Until some of these questions are answered, though, I am containing my excitement.