FAQ
Here are answers to some of the most common questions we receive. This FAQ is a work in progress and will continue to be updated and expanded.
- I'm getting errors after downloading the bridge through the "Download ZIP" button on Github. What should I do?
- I’m getting errors on my header files about *.tlh files that can’t be opened, “+” and “-” method modifiers being marked as “expected declaration” and “unrecognized token” for “@interface” and “@property”. What should I do?
- What kind of telemetry does the iOS bridge collect?
- How do I get my project log file to help determining the cause of an issue?
- How does the bridge handle automatic magnification?
- Does the bridge support ARM?
- What's the deal with all of these stubs?
- How do I enable syntax highlighting for Objective-C in Visual Studio?
- How can I use a VM on a Mac to develop a single codebase simultaneously in Visual Studio and Xcode?
- What about accessibility?
I'm getting errors after downloading the bridge through the "Download ZIP" button on Github. What should I do?
There are two ways to install the bridge:
- Download one of the precompiled release .zip packages from the releases page.
- Download the complete source via
git clone https://github.com/Microsoft/WinObjC.git.
Installing the bridge using one of the precompiled releases is simple; just follow the instructions on our Getting Started page.
If you would like to build the bridge from source – meaning you downloaded the complete repo using git – you must install Git LFS. We use Git LFS to manage the storage of large binaries that are part of the source code repo. For instructions on how to install Git LFS, please see our Building From Source wiki page.
NOTE: If you download the repo using the "Download ZIP" button on the main repo page, you will get errors building the project. Please use either one of the precompiled release builds or build from source using git.
I’m getting errors on my header files about *.tlh files that can’t be opened, “+” and “-” method modifiers being marked as “expected declaration” and “unrecognized token” for “@interface” and “@property”. What should I do?
As you can see on the image below, Visual Studio IntelliSense wrongly flags these errors since it doesn’t yet have support for Objective-C projects. However, those errors do not prevent the compilation of your project, so you should ignore them at present.
Beginning with the 160304 release, we are capturing some data from Visual Studio users who have opted in to sharing telemetry with Microsoft in order to gain insight into the issues our developers are facing. We are doing this in two ways: first, through the Objective-C syntax-highlighting VSIX Visual Studio extension, and second by instrumenting Xib2Nib and vsimporter using ApplicationInsights.
Capturing build issues directly from Visual Studio allows our team to identify, understand, prioritize and fix the top issues facing our developer community.
Yes. Data will only be collected if you chose to share telemetry with Microsoft when you installed Visual Studio.
Using regular expressions, we carefully filter out all personally-identifiable information, including:
- User IDs
- Local and network paths and filenames
- Protocol handlers with paths
- Any messages that do not match WinObjC types AND contain one of the following strings: "method", "class", "property", "interface", or "namespace"
In other words, the only data we collect are specifically related to bridge features or unimplemented APIs and have been stripped of personal identifiers.
Xib2Nib uses ApplicationInsights to log start/stop events as well as any unrecognized tags and unsupported classes encountered.
vsimporter uses ApplicationInsights to log start and stop events while your Xcode project is converted to a Visual Studio solution. The instrumentation also logs information about your build target and build phases to determine their levels of support in the bridge.
When posting an issue, adding the contents of your project log file is extremely helpful pin down the cause of the problem. To do that, follow the steps below:
-
Open your project in Visual Studio and go to Tools (1) -> Options (2).
-
In the left panel of the Options window, select Build and Run (2) under Project and Solutions (1).
-
Under MSBuild project build log file verbosity (1), select Diagnostic (2).
-
Click OK to close the Options window.
-
Rebuild your project solution.
-
Go to the following path in the File Explorer: /.vsimporter/-WinStore10/<Release/Debug> (1), where is the path to your project solution, is the name of your project and <Release/Debug> is the configuration you built in the previous step.
-
Locate your project log file <ProjectName>.log (1), and copy and paste its contents as a comment to your issue.
As part of our development of Project Islandwood, we have reversed some recent changes to automatic magnification. By default, Project Islandwood enables auto magnification which will automatically size your screen content to the size of the window.
To preserve the best layout experience for iOS developers porting their applications to Windows, the Windows Bridge for iOS uses the native scale of your device to render the layout of your application. The scale reported back to your application is automatically scoped (or clamped) to a value of 1 or 2. In this way you get the best possible layout being displayed without any additional efforts. You can enable or disable this feature if desired.
This capability is determined by the following WOCDisplayMode properties set in the +setStartupDisplayMode category of UIApplication (UIApplicationInitialStartupMode):
useHostScaleFactor: Enables/disables the use of? the native scale.
clampScaletoClosestExpected: Clamps the magnification to the closest value for native scale - 1 or 2.
As of the 160218 release, the bridge offers preliminary support for ARM devices, so you can test and run your apps on Windows Phone. The ARM compiler is currently in the Community Technical Preview (CTP) stage and we are actively seeking feedback. If you encounter problems building and running your app using the CTP ARM compiler, please file an issue.
We introduced a large number of framework stubs in the 160218 release which contain headers that match the iOS 9.1 SDK. These framework stubs have stub implementations that typically return stub values (usually 0).
We want app developers to be able to compile, link and run their iOS apps on Windows 10 as quickly and easily as possible. Stubbing the iOS framework surface area allows developers to see where degraded functionality lies and focus their attention on the areas that need work. This is the approach we have taken internally to support apps using the Islandwood platform.
The methods and properties that are stubs have the STUB_METHOD and STUB_PROERTY macros respectively after them. For example:
GAMEPLAYKIT_EXPORT_CLASS
@interface GKNSPredicateRule : GKRule
- (instancetype)initWithPredicate:(NSPredicate*)predicate STUB_METHOD;
@property (readonly, retain, nonatomic) NSPredicate* predicate STUB_PROPERTY;
- (BOOL)evaluatePredicateWithSystem:(GKRuleSystem*)sys STUB_METHOD;
@endIf your app uses any of these methods or properties, you will get a build time warning that will give you an idea of the missing APIs you may be using. The warning will be of the sort:
Warning: method x is deprecated: it is not implemented
Define NO_WARN_STUBS in your project file.
Define NO_STUBS in your project file.
The Foundation and UIKit frameworks have some incorrect STUB_* macros in them. We are working on cleaning them up.
To enable Objective-C syntax highlighting in Visual Studio, navigate to bin/ and double click objc-syntax-highlighting.
Note: If you chose to share telemetry with Microsoft when you installed Visual Studio, enabling syntax highlighting will also turn on telemetry sharing with the Windows Bridge for iOS team. Capturing build issues directly from Visual Studio allows our team to identify, understand, prioritize and fix the top issues facing our developer community. For more information, see "What kind of telemetry does the iOS bridge collect" above.
If you're using the iOS bridge on a Virtual Machine on a Mac, you can easily set up a cross-platform development environment by storing your codebase in a shared folder that is accessible from both the Windows 10 and OS X side. With this approach, you can run Xcode and Visual Studio side by side. To get started, download an evaluation virtual machine for your preferred virtualization environment from our website.
Warning: With this configuration, you may have to rebuild your whole solution or clean and build in Visual Studio before seeing changes made in your code (rather than Visual Studio automatically keeping track of modified files and recompiling the necessary ones). We are investigating this issue; if you encounter it, please file a bug and let us know.
Note: By default, Visual Studio will not register an app with the system if its files are on a network drive, and since folders shared with the Mac host machine in a virtual Windows 10 environment are treated as network drives, we have to change a few settings to get Visual Studio to build and run.
The easiest way to do this is to override the project's output directory. Right click on the project and change the output directory to $(Temp)\$(MSBuildProjectName)\bin\$(Configuration), where Temp is an environment variable pointing to your Temp directory.
At present, the Windows Bridge for iOS is still in development and does not yet support all the accessibility features your app might use in iOS. Accessibility is extremely important and we are working hard to ensure that future releases include this vital support. We appreciate your patience.