I ran into a strange error recently when I tried to open one of my converted iOS Windows Bridge for iOS.
The project would not load and there was not much of an error message, until I checked the output windows.
Error: The imported project "C:\_CODES\WinObjC\msvc\starboard.props" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.
At this point I realized that I was opening this on another machine and that on this machine the WinObjC SDK was not installed in the same path as the other one.
Edit project file find the reference to WINOBJC_SDK_ROOT and change it to the proper location
As mentioned in my other article make sure that you install the SDK in a path that does not contain any spaces in its name.
As the BUILD Tour came to Toronto last Friday, I was given the opportunity to record a couple of videos for the Bonus section of the event.
So, along with my colleague Jeremy we talked about a couple of topics related to HoloLens development.
That was a blast and I hope I get to do it again soon.
The Windows Bridge for iOS (previously known as Project Islandwood, or WinObjC) is an OpenSouce project started and maintained by Microsoft primarily and by the community that allows developers to enable their existing iOS apps written in Objective-C to run on Windows 10 as Universal Windows Platform apps. What’s more, you can enhance those apps with UWP specific features like Live Tiles, Cortana and others.
There are 3 main components that make the bridge:
A custom clang compiler was written for this project to support compile Objective-C language to Windows bytecode.
To ensure that your apps can compile without any code changes, all of the APIs had to be written to conform to the Apple API definition but using the underlaying Windows libraries. I.E Imagine the CCLocationManager class, implemented using the Geolocator API.
Additionally, all the Windows API definitions have been described as headers from the Windows core winmd files to be made accessible to the Objective-C language.
There are a number of differences in the way an Xcode project is structured vs a Visual Studio project. The vsimporter, tool will generate the solution files and convert any assets to match the requirements for a Windows App, while other tools will compile the Storyboards and Xibs.
Last but not least, the Visual Studio syntax highlight plugin enables nice syntax highlighting for Objective-C in Visual Studio
The way I see it there are 3 steps in porting an iOS app with the Windows Bridge for iOS
In the conversion step we are transforming our Xcode project into a Visual Studio solution file that we can open up with Visual Studio. This is relatively easy, and seldom creates any issues. Open a command prompt in the folder hosting your Xcode project and run the vsimporter.exe file from the WinObjC bin folder.
What you’ll get is a new folder that contains the generated UWP project and a Visual Studio Solution file that you can open up.
With the first step out of the way, we can now open the solution in Visual Studio and make sure we can actually compile. This step is a bit trickier than before and you’ll often need to make minor adjustments to ensure the solution compiles.
If there are API’s that were not bridged you will get compilation errors and need to find workarounds for those portion of the code (a lot of the APIs have been stubbed out, so they won’t give compilation errors, but there are still some missing). Also due to platform differences some structs or enums might be different and you’ll need to fix those (i.e. mach_timebase_info_data_t missing in Win32 use mach_timebase_info_t instead)
By far the most complex task, and probably where most of the time will be spent in a conversion project is to ensure that at runtime, the project works and behaves as expected.
All those missing APIs that have been stubbed out will start to cause problems now, and some differences in how APIs are implemented can crash your app.
It’s too broad of a subject to try and describe in great detail, but the one thing that is worth mentioning at this point is that every time you encounter a runtime problem, your first instinct should be to find the root cause and see if this is a problem with your code or maybe a more general issue with the SDK itself, and if it’s generic enough, open an issue of the project’s page or better yet, open the issue, and try and fix it and open a pull request so that everyone else can benefit from it.
If that wasn’t enough, after you have finished converting your app and everything works great on Windows, you can go a step further and start enhancing the app with Windows specific features like Cortana, Live-Tiles, Notifications, etc. You can do that with using Objective-C code since all the Windows APIs have been exposed and accessible from your ObjC code.
Contributions to the project are always welcome. As I mentioned above, whenever possible, try and update the SDK rather to change your code if something does not look right. If you’re having an issue and the code works properly on iOS, that might be a good thing to update in the SDK for future conversions to just work.
Make sure you read the contribution guidelines.
The main project page can be found on GitHub where there are links to great additional resources.
Check out the BUILD 2016 session - Getting started with the Windows Bridge for iOS
Lastly the Dev Center Bridge for iOS page.
As I was trying to deploy one of my apps to the Xbox One, I ran into a strange error that ate a lot of my time to fix.
I don’t think you’ll be getting in this touble if you start from scratch but considering a lot of the new apps on Xbox will be existing apps, this might apply
DEP0700 : Registration of the app failed.
Make sure package.appxanifest TargetDeviceFamily includes Windows.Xbox or Windows.Universal.
<TargetDeviceFamily Name="Windows.Xbox" MinVersion="10.0.0.0" MaxVersionTested="10.0.10586.0" />
<TargetDeviceFamily Name="Windows.Universal" MinVersion="10.0.0.0" MaxVersionTested="10.0.10586.0" />
Fix Visual Assets
As I’ve mentioned in my Build 2016 overview post, this year Microsoft announced they are finally opening the Xbox One for developers to deploy and debug their apps.
So I did a quick test and tried to deploy one of my apps on the Xbox as a quick experiment.
To get started you can read all about it on the official site but here is a quick summary of the most important things I found
I’m really excited at the new possibilities that the Xbox opens and I am looking forward to publishing my first Xbox compatible app soon.
I’ve been working with the HoloLens for about 6 weeks now (yes, I’ve been one of the lucky Wave 1-Day 1 HoloLensers) and even though I haven’t written anything yet, there’s a lot of stuff I learned about it and I will try to start and put in on “paper” in the following weeks.
One of the key things in delivering a truly amazing HoloLens experience is performance. Top priority from start to end of the project is to have the application running at 60fps ()
I am not going to write here about the techniques on how to achieve that - you can find all about it on the excellent HoloLens documentation site here and here, but I will present some pointers on how to measure that framerate as easily as possible.
As my current MCSD - Store Apps (Win 8.1) certification will expire at the end of August I started looking at the next step MCSD - Universal Windows Platform certification.
I quickly passed the first one MS 70-354 but then I got stuck at the second and more difficult one - MS 70-355.
Not only the syllabus for the exam is way more extensive, but the lack of an official study guide makes it hard to study for it.
So I’ve attempted to dissect the skills measured section, broke it down 3 level deep down to the base topic for each chapter, and provide links to documentation for each section (where’ there’s a missing link, I did not find any relevant official documentation on that particular topic. I will update the post as I find them)
Even though it’s been a month since BUILD ended, the announcements made and their importance still resonates today.
First takeaway comes from the first moments of the keynote. It’s defining Microsoft’s strategy with a somewhat cliché motto, but what makes it interesting is the explanation that Satya Nadella gave when talking about it.
In Microsoft’s view, mobile does not represent what we all think it does, it’s not referring to a device or even a category of devices. What it represents is the mobility of the users. It represents the freedom of being anywhere, using device at any time and have all your knowledge, context and information with you. And to make all of this possible you need the cloud which has everything you need and it’s accessible from anywhere you need it. In this light I believe that Microsoft is really close to achieving this vision.