Tag Archives: iOS bridge

Windows 10 Anniversary Update SDK Now Available! Windows Store Open for Submissions

Today I’m pleased to announce that following the Windows 10 Anniversary Update we have released the Windows 10 Anniversary Update SDK, build 14393 along with Visual Studio 2015 Update 3. The new SDK contains more than 2700 enhancements to the Universal Windows Platform allowing you to take advantage of our fastest growing OS ever and gives you access to the latest innovations in Windows 10 which are now available in the Anniversary Update. These updated APIs make it easier than ever for you to create more natural ways of interaction, like vision, writing, and speech into your apps and experiences. The Windows 10 Anniversary Update SDK delivers improvements to:

  • Windows Ink: A pen is a natural choice for apps that depend on analog input, such as sketching, animation and even signature capture. Now, with just two lines of code you can bring Windows Ink into your apps through the news InkCanvas and InkToolbar controls.
  • Cortana APIs: There is no easier way to interact with your computer than to talk to it, and Cortana brings you powerful features that you can use in your own apps. With the Windows 10 Anniversary SDK you can go further than simply adding voice controls to your apps, now with Cortana Actions you can drive increased user engagement by registering actions with Cortana that she will use to connect users to your apps at just the right time.
  • Windows Hello: Biometric authentication brings the magic of vision to apps and now with the Windows 10 Anniversary SDK, web developers can use Windows Hello in Edge to authenticate users with just a glance.
  • To find out more about these APIs and other enhancements in the Windows 10 Anniversary Update SDK visit Dev Center.

And we’re just getting started. With today’s launch we continue our goal to make Windows more open for all developers by providing you the tools you need to make Windows home no matter what platform you build for. Since //build my team and I have travelled the globe and met with thousands of developers and we have heard firsthand what is important to you. Among them, the promise of the Desktop Bridge to help you quickly and easily modernize your existing Win32/.NET apps, excitement to see real, native Bash running on Windows and Xamarin as a cross-platform development solution. We’re continuing to act on your feedback and offer more for cross-device developers, including these technologies:

  • Desktop Bridge (Project Centennial): The millions of developers using Win32 and .NET to build desktop apps can now get access to the benefits of the Universal Windows Platform and the Windows Store. Using the modern deployment technology of UWP, desktop apps can cleanly install, uninstall and update, as well as get full access to UWP APIs including Live Tiles, roaming storage, push notifications and more.
  • Bash Shell on Windows: We are pleased to deliver a top requested feature from users of popular command-line tools. You can now download the Bash shell from our partners at Canonical directly from the Windows Store. Now you can run native Bash and GNU/Linux command-line tools directly on the new Windows Subsystem for Linux.
  • Improved Tools and Bridges for iOS and Android Developers: Visual Studio now includes Xamarin tools built-in, ready to create apps for Windows and iOS and Android. In addition, our open source Windows Bridge for iOS enables iOS developers to bring Objective-C code into Visual Studio and compile it into a UWP app.

Windows Store Open for Submissions; Including Process for Submitting Desktop Bridge Apps

Starting today we are opening Dev Center and the Windows Store for submissions of apps built for PCs, phones and HoloLens, targeting the Windows 10 Anniversary Update SDK.

In addition, we will begin the process of accepting apps using the Desktop Bridge. While we build the pipeline into the Windows Store to publish these apps, our team will work directly with developers to get their converted apps and games into the Windows Store. Contact our team here if you are interested in submitting an app using the Desktop Bridge to the Windows Store.

Later this month, we’ll have a post on new Dev Center features and will share more detail on getting Xbox apps targeting the Windows 10 Anniversary Update SDK into the Windows Store.

Ready, Set, Build!

With the improvements in the Windows 10 Anniversary Update SDK there just isn’t a reason to wait. The Windows ecosystem is thriving – offering you an active and engaged audience of more than 350 million monthly active users. The Store is open for business and new innovations with Inking, Cortana and Edge will enable new experiences that simply aren’t possible on other platforms.

If you are not already building for Windows, download the Anniversary Update SDK today and get busy!

Thank you to our Windows developer community for your passion and creativity – we can’t wait to see what you come up with next! My team and I love to hear your feedback, and we use it to guide platform investments. Please keep the feedback coming using our Windows Developer Feedback UserVoice site.

Windows Bridge for iOS: UIKit, meet XAML. XAML, meet UIKit.

One year ago this August, we released the Windows Bridge for iOS (“Project Islandwood”) as an open-source project on GitHub. For those of you just joining us, the goal of the iOS bridge is to make it easy for iOS developers to make great Windows apps while reusing much of their existing Objective-C code and iOS development skills.

The community response to the project has been overwhelming; hundreds of issues have been opened (and many of them closed), nearly 100 pull requests have been submitted (and many of them accepted), and there are currently over 600 forks of the project – and all that is to say nothing of the great partnerships we’ve made with companies using the iOS bridge to bring their apps to Windows 10.

The reasons for open-sourcing the bridge were twofold: first, we wanted to get as much feedback as possible so we could make sure our priorities were aligned with developers’. And second, we wanted to lay the groundwork to build a strong community around the project so it could be extended by anyone and everyone would benefit.

Since August, the project has made significant advances on virtually every front, from an updated CoreFoundation implementation to a vastly improved Auto Layout engine, and support for new UIKit classes. We’ve also made great strides forward with our tooling experience, adding native visualization and object inspection for Objective-C to Visual Studio earlier this year.

The iOS bridge has always been an extremely ambitious project, and all of this progress was made possible thanks to the contributions and feedback of our developer community.

What’s next?

As we’ve listened to and learned from iOS developers over the last year, one piece of feedback in particular has stuck out. Time and time again, our customers and developers have told us they need more complete API coverage from our UIKit implementation.

Bridging iOS user interfaces to Windows is a tricky proposition. On the one hand, we want to maximize code reuse for users and minimize the amount of legwork they have to do once they bring their Objective-C code base to Windows. On the other, UIKit is a vast framework with hundreds of classes, and re-implementing the entire thing is simply not feasible – not to mention the fact that Windows already offers much of the same functionality in the form of XAML. While XAML has been part of the iOS bridge from the outset – it’s always been possible to create and use XAML objects using Objective-C code – there has not been an easy, clearly devised path to migrate your UIKit-based UIs to XAML.

We’d like to change that. Starting today, we’ll be sharing a series of technical design documents on GitHub outlining our solution to this problem and soliciting your feedback.

As a result of these changes, the iOS bridge will be able to offer:

  • Faster bring up of iOS controls, so more of UIKit is available to you
  • An improved touch-input model for more performant event handling
  • Much improved support for accessibility and localization
  • Better test automation, resulting in more stable and high-quality controls
  • Much improved integration with and leveraging of Windows’ UI framework, XAML

Out with the old

Our extant approach to user interfaces has simply been to implement UIKit – all of UIKit, or as much as we possibly could. So for instance, you could continue to use elements like UIButtons in your app on Windows, but your code would be using our custom implementation of UIButton rather than Apple’s first-party one.

In its idealized form, this approach has the seeming advantage of offering one-for-one compatibility with iOS. In reality, however, this often meant that we wound up with partially implemented classes and incomplete support for basic use cases and scenarios.

For instance, our UITableView implementation could handle simple operations like insertion, deletion, and reloading, but if you tried to move cells from one row to another, you’d run into a hard technical wall; the requisite methods and properties just weren’t there yet, and unless you wanted to implement them yourself, you were simply out of luck.

This proved extremely frustrating for our users, as it was difficult to tell at a glance what worked and what didn’t. We’ve worked to mitigate the problem over the last year by thoroughly annotating the iOS bridge code base – marking every method and every property as fully interoperable, partially implemented or not supported – but the fundamental problem of a fragmented and incomplete feature set persisted. It simply wasn’t clear what would and wouldn’t work.

As mentioned earlier, however, much of the functionality we were attempting to recreate already existed elsewhere on Windows – in the form of XAML – which brings us to our new approach.

In with the new

If you follow the iOS bridge project on GitHub, you may have noticed that over the past few weeks we’ve begun to shift some of our key UIKit controls away from their custom implementations and instead build them on top of existing XAML controls.

For instance, in early June we removed our implementation of UITextField – which was designed to mimic iOS’s UITextField as closely as possible, but was, in fact, incomplete – and replaced it with a version of XAML’s TextBox class that was wrapped in UITextField’s APIs. By plumbing UITextField’s methods and properties through to their respective counterparts in XAML’s TextBox, we were able to preserve virtually all of the UITextField functionality using an existing XAML control.

To be clear: this means that you can continue to use the UITextField class in your code, but what happens under the hood is radically different; rather than calling an incomplete implementation that does not account for all possible use cases, you’ll actually be using a tried-and-true XAML control.

Going forward, we’ll be using the same approach for other UIKit controls like buttons and sliders. Container classes will be similarly mapped; for instance, UIScrollView will be rebuilt on top of XAML’s ScrollViewer and we are currently exploring options for UICollectionView and UITableView. In each case, our team will work to preserve as much UIKit functionality as possible while taking advantage of features that already exist on Windows.

This approach offers a number of advantages. For one, it greatly reduces the amount of work it takes to bring up on Windows the UIKit classes iOS developers depend on. For another, it dramatically increases what the bridge is able to offer in terms of accessibility and localization, not to mention performance, stability, and polish. Lastly, the new approach allows us to take advantage of test automation designed for XAML, which will help to raise the quality bar of our UI frameworks and prevent regressions.

The caveat to this approach is that it means that recreating 100 percent of UIKit’s features and functionality can no longer be the ideal; instead, the goal will be to map as much UIKit behavior as possible to corresponding XAML functionality, potentially supplementing XAML’s current capabilities where appropriate. Our team will work hard to preserve key iOS behaviors and paradigms, but not every UIKit method and property will have a counterpart to be mapped to on Windows. Despite this, we feel that the net benefits are well worth the tradeoffs.

New features, new tools

Along with the implementation changes, we’ll be introducing a new tool we’re calling Xib2Xaml. This tool will convert the XIB and Storyboard files you’ve built using Xcode’s Interface Builder into Windows-native XAML files, allowing you to edit them directly in Visual Studio.

In the past, making changes to your XIBs and Storyboards meant going back to Xcode and running through the whole bridge workflow again – there was no native support for editing XIBs in Visual Studio. With the new Xib2Xaml tool, you’ll be able to take advantage of Visual Studio’s Blend interface editor, allowing you to migrate your existing UIKit and Storyboard-based layouts and work with Windows UI controls directly to build great UWP experiences.

We feel these changes will make the Windows Bridge for iOS more robust and easier to use than ever before. And as always, we welcome your feedback – we’ve already begun the work of transitioning our code base to the new UI approach, and you can see the relevant design documents in the following places:

  • UI Design Document

We’ve published a complete technical design document detailing all of the changes we’ve made to our UI approach thus far.

  • UI Touch Input Document

The new approach to implementing UI controls has necessitated some changes to the way the bridge handles touch-input processing. With these changes, we have successfully integrated XAML-backed UIKit controls with the iOS hit-testing mechanism and native responder chain, resulting in a much more consistent, functional and performant input model. The one drawback to this change is that iOS’s dynamic hit-testing functionality – i.e., the ability of any UIView subclass to override the hitTest:withEvent: method to redirect touch input – is no longer supported at this time.

Check out the code changes and design document outlining the new approach on GitHub and if you have any questions, thoughts or concerns, don’t hesitate to let us know.

Download Visual Studio to get started.

Using the iOS Bridge to Bring Storyboards and Auto Layout to Windows 10

Calculator_App_Hero_FINAL (1)

In part one of the Windows Bridge for iOS series, we created a simple to-do list app in Xcode and used the Windows Bridge for iOS to bring it over to Windows 10. In part two of the series, we went on a tour of Visual Studio for iOS developers. In today’s tutorial, we will use the Windows Bridge for iOS to convert an existing iOS calculator app created using Storyboards and Auto Layout to create a Universal Windows Platform app that will adjust to various form factors on Windows 10.

As a refresher, the Windows Bridge for iOS is an open-source project that provides an Objective-C® development environment for Visual Studio and support for iOS APIs. It allows you to create a Universal Windows Platform (UWP) app that will run on any Windows 10 device using iOS APIs and Objective-C code.

Getting Started

For today’s tutorial, you will need:

Understanding the Project Structure

With the calculator sample application downloaded and unzipped on your Mac development environment, let’s open the Xcode project and briefly explore the application. This application consists of:

  • AppDelegate – receives notifications about the state of the UIApplication object and performs tasks on events like startup and shutdown.
  • ViewController – provides the view management infrastructure for the app’s user interface, such as loading, disposing, and managing interactions with the various views used in the app.
  • Storyboards (LaunchScreen and Main) – visually lays out your users’ path through your app using scenes, segues between screens and the controls used to trigger the segues.
  • Project properties (plist) – a structured xml file containing a list of properties that define various configuration settings
  • m – instantiates the application object, sets up the main event loop, and begins processing events. Most times, there is no need to modify this file.

The UI implementation is done visually in Main.storyboard and all the heavy lifting is done in ViewController.m, which contains the methods that perform the calculations.


Let’s run the app in the simulator and perform a few calculations. As you can see, this is a fairly simple app—there are several buttons and a label that allows you to perform mathematical calculations.


Using vsimporter

We are ready to run the app through the vsimporter tool. To do so, you’ll need to copy your Xcode project files to your Windows Machine (or VM). With the files copied, open the Xcode project folder on your Windows machine.

You’ll want to navigate to the directory that has the Calculator.xcodeproj folder in it. In Windows Explorer, click File-> Open Command Prompt.

Open the Windows Bridge for iOS folder (winobjc) and navigate to the “bin” folder. Find the file named vsimporter.exe and drag it onto your command prompt window, then press “Enter.”



Go back to your Xcode project folder and you will see that a new Visual Studio solution (Calculator-WinStore10.sln) has been created automatically as the output of the bridge. The Calculator app is now a Universal Windows App.


Digging Deeper with vsimporter

The vsimporter tool creates a Visual Studio solution from the original Xcode project while preserving relevant project settings and importing assets, headers, and source files.

This is all pretty straightforward mapping up to this point. The vsimporter begins from a custom “Islandwood template” and then copies and tweaks a few files. The real “magic” is in the project importer itself and in the runtime.

Understanding Storyboards

As a reminder, a Storyboard in Xcode is a container of scenes, which correspond to the views and objects used in the app’s UI. A Storyboard can be used to represent everything from individual view layouts to segues between view controllers. A NIB file is the compiled binary version of a XIB. In addition to setting up our Visual Studio project’s code structure, the vsimporter tool invokes a related tool called “Xib2Nib” and uses the enclosed XIB files to generate NIB files.



The Xib2Nib tool can import and support simple Storyboards and NIBs. It processes these XIB files by iterating through the XML and building out a new plist/NIB file for each Storyboard encountered in the Xcode project. The end result is that the Storyboard we carefully laid out in Xcode – with all of its Auto Layout magic and layout constraints – remains intact when we run vsimporter and bring our code to Windows 10. If the Xib2Nib tool doesn’t work for your project, file a bug  or contribute to the project.

Launch the new solution file with Visual Studio 2015. You’ll notice that the imported Xcode project looks pretty familiar. In addition to bringing over the main Xcode project files, the importer added references to the needed UWP APIs and assets needed for publishing to the store.


Also added were external dependencies to the iOS APIs supported by the Windows Bridge for iOS.


Tip: Be sure to install Objective-C syntax highlighting if you haven’t already done so. It is available as a Visual Studio extension (objc-syntax-highlighting.vsix) and is located in the same directory as the vsimporter.exe file.

Running and Resizing the Application

Run the application on your local machine and you’ll notice the same calculator UI we saw running in the Xcode Simulator. Try resizing the app window and notice how the UI is now responsive and fits multiple app dimensions. You now have a native iOS app running on Windows.



Wrapping Up

Although our project didn’t encounter any unsupported iOS API calls, other apps might. So, what is an app developer to do? You’ll want to open an issue and let the team know. The team is committed to working with the iOS developer community to improve the bridge and enable iOS app developers to port their apps to the Universal Windows Platform.

Additional information can be found here: