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

Brink · Jul 14, 2016

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.

Windows Bridge for iOS on Windows Dev Center

Windows Bridge for iOS on GitHub

Get started with an Evaluation Virtual Machine

Open an issue on GitHub to let us know what you think of the new UI strategy

Download Visual Studio to get started.
Click to expand...

Source: Windows Bridge for iOS: UIKit, meet XAML. XAML, meet UIKit. | Building Apps for Windows

:)

VarunRavindranath · Jul 14, 2016

Microsoft Edge crashes while failing to load the file and thus creates a virus kind of behaviour

Hi

I had accidentally opened a xaml page in Microsoft edge. It fails to load the xaml page and every page needs to be closed as a result. Typically the xaml files can't be opened using edge but if u have zipped file and tries to open it from zip file the issue
occurs. It tries to parse the xaml and some how is not able to load the content . Closing that page don't resolve the issue as it is effected the open tabs too.

It interrupts the start itself and it becomes the active window.

Please fix this bug.

Regards

Varun

Shawn 'Cmdr' Keene [MVP] · Jul 14, 2016

Desktop Icons

They rebuilt the start menu as a XAML app so it scales for all form factors (all the way from a 3'' phone screen, 6 and 8'' tablets, larger tablets, full desktops, and even their giant 80" meeting room screens). But in doing so, they shed out all the
legacy code from Windows 95-Windows 7. It no longer uses any shell context menu classes, so all the regular right-click menus you'd get on any typical file system icon are gone.

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

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

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

Windows Bridge for iOS: UIKit, meet XAML. XAML, meet UIKit - Similar Threads - Bridge iOS UIKit

Erreur d'application OneDrive source Windows Xaml du bureau

Desktop windows xaml source onedrive application error

Desktop windows xaml source onedrive application error

Fluent XAML Theme Editor won't download

XAML Islands v1 - Updates and Roadmap for Windows 10

what is Microsoft advertising SDK for XAML update?

Introducing XAML Standard and .NET Standard 2.0

Mixing and Matching UIKit with XAML and the Windows Bridge for iOS

XAML Behaviors, open source and on UWP