Cover Photo by Ashkan Forouzani on Unsplash
I have been working on Ink Calendar since October 2017. Since then the app has grown to be much more capable and complex. When developing I expect there will be issues with my code, but as I have discovered there are also major issues with Windows APIs. In this post I plan to layout the issues I have been trying to fix for years with no success.
Ink Analysis Crash
One of the obvious hallmarks of Ink Calendar is the inking. Inking is different than traditional computer inputs like keyboard and mouse. A powerful inking experience requires quick selection and the ability to convert from ink to text. Lucky for me Microsoft makes this very easy with an API.
However this same magical API called InkAnalysis is the single biggest source of instability within Ink Calendar. My personal guess is this API is not heavily used because it has not improved or changed since I have been using it. Also Microsoft’s documentation on how to isolate the application from the InkAnalyzer does not exist. I have been working with the team to resolve issues; so far with no success.
Calendar API Errors
The other headline feature in Ink Calendar is the Calendar part. When users ink on a day and want to add that day to their Calendar in a more formal way there is a very easy API which can be called to add the appointment to the user’s calendar. However this API is frequently and randomly broken. No good feedback on a successfully added appointment. This means as a developer I have to guess if the appointment was added or the dialog was just canceled by the user.
Within the same AppointmentManager
API is getting the user’s calendar appointments to show them on the calendar. This also is broken randomly and does not provide up-to-date appointment data. This completely prevents Ink Calendar from being able to provide a seamless calendar application. There is no clear way to connect with Microsoft regarding this issue and I have tried several different avenues.
Azure Pipelines
Building UWP apps and submitting them to the Microsoft Store should be the easiest Azure Pipeline that exists, but it is such a terrible experience there is no wonder UWP was never widely adopted. When users finally get pipelines working they randomly break with totally unhelpful error messages “internal compiler error.”
Does Microsoft Want UWP Developers to be Successful?
It doesn’t seem like it. When compared to other platforms like iOS and Android, UWP devs have no advocates within Microsoft. All of the recent developer and technology investments have been made last and worst for UWP experiences. Azure DevOps, AppCenter, C# language, .NET 5, are best when not developing a Windows GUI application. UWP is ignored and abandoned. Microsoft’s own 15 year old framework WPF has gotten more support than UWP.
I want to be an independent UWP developer, but as time goes on it becomes clear UWP is the bastard child of Microsoft.