Recently I had the opportunity to test the windows bridge for iOS (codename Islandwood) for a customer to try converting a real world iOS application to the universal windows platform. According to MS this should be quite simple and they have an example, where a calculator app is converted successfully. 🙂
Seems easy, doesn’t it?
Well, we all know these „sample applications“ where things always work great…or sometimes not so great 😉
In my opinion the first problem is that non-tech customers may think: Cool, I use my existing iOS source code with the „MS converter tool“ and get a working universal windows platform app in minutes. Of course this is not how things work and this is mentioned by the program manager of the iOS bridge too:
Our goal with the iOS bridge has never been simply to run iOS apps on Windows. Rather, our goal is to help you write great Windows apps that use as much of your existing code and knowledge as possible.
Anyway, I followed this quickstart tutorial to install the Objective-C language service and used the VSImporter tool, which is included in the iOS bridge, to create a VS2015 solution from the existing iOS source code.
First compilation of the newly created VS2015 resulted in 6 erros.
The reason was that the iOS app uses some rather old 3rd party libraries which of course have not been converted (and most likely never will be) by MS. Since the errors were caused by some function calls which are not required to start the app, I simply commented them out in the source code and did another rebuild. My first goal was to simply start the app…getting it to do the actual work will be a task for later.
After rebuild I got 21 Errors and 222 Warnings.
These included many „unresolved external symbol“ errors for iOS view controls.
Ok, thats not going to work. 😉
Soooo, lets try something completely different.
A friendly iOS developer 😉 with whom I was working on this „bridge evaluation“ project created a simple, completely new iOS app, based on the „tabbed app“ iOS app template. Converting this new project by using VSImporter was working without any problems.
Thats what I was hoping for since the app consisted of a windows with 2 tabs and some text on them only. 😉
After compiling successfully and starting the ported UWP app, it crashed immediately.
'TabbedApp.exe' (Win32): Loaded 'C:\Windows\SysWOW64\Windows.ApplicationModel.dll'. Symbols loaded. Exception thrown: read access violation. img was nullptr. Unhandled exception thrown: read access violation. img was nullptr. Exception thrown at 0x05A8462B (COREGRAPHICS.DLL) in TabbedApp.exe: 0xC0000005: Access violation reading location 0x00000004. Unhandled exception thrown: read access violation. img was nullptr.
Please try searching for „UNIMPLEMENTED();“ in the sourcecode yourself and you will be surprised how many methods currently are NOT implemented, in the CIImage.mm this resulted in 43 matches.
Another example: UIButton.mm from UIKit contains 16 matches for „UNIMPLEMENTED();“ and I guess a button is a quite common used control.
Please keep in mind that the iOS bridge currently is Version 0.1 Preview and has a rather long list of issues.
I am sure, many of these issues will be fixed but in my personal opinion: who cares?
Does it make any sense for MS to try re-implementing all the iOS libraries and framework controls?
What a boring work to do! The list of included frameworks is rather large but as said: most methods are not implemented, so some code which uses them will compile…but not run of course.
What about other third party controls used by iOS developers?
Meanwhile iOS itself gets new features and new SDKs of course – will MS try to re-implement them as well?
On the other hand: At the moment iOS developers use Swift to create new apps, not Objective C but the bridge currently only supports Objective C.
In my personal opinion the resources spent to create the iOS bridge could be better used, for example to create a great Xamarin Forms designer which I would highly appreciate…or make WM10 stable 😉