Developers using Visual Studio 2015 can now develop iOS apps for use on Windows 10. The technology has been mentioned before under the Project Islandwood moniker, but is now officially released as the Windows Bridge for iOS. Published through GitHub, the open source project is available under the MIT license.
The Code
The Windows Bridge for iOS provides Windows developers with a fully-fledged Objective-C development environment for Windows using Visual Studio. To make this language support more useful, the Bridge also includes an iOS API layer.
Currently the Windows Bridge supports Windows 8.1 and Windows 10 on the x86 and x64 architectures. Microsoft’s Kevin Gallo indicates that mobile support (via ARM) is planned for a future release. Microsoft Program Manager Salmaan Ahmed has provided some details around the 4 major pieces of the Windows Bridge. These include an Objective-C compiler, an Objective-C runtime, iOS API headers/libs, and integration with the Visual Studio IDE.
Interestingly binaries for the compiler are included in the GitHub repository but the compiler itself will not be open sourced. Eventually a finished version of the compiler will ship in binary form in an update to VS2015 schedule for release later this year. This compiler is based on Clang— and according to the contents of the GitHub repo, based on LLVM 3.6. From what has been announced so far, Microsoft’s customizations allow Objective-C and C++/CX code to coexist in the same project.
Astute readers will not that the 4 components listed above do not include an emulator or iOS runtime. Ahmed says that Microsoft’s goals for the project are to provide full access to the Windows API, reuse existing iOS code, and to let apps benefit from both API sets (iOS & Windows) without any limiting boundaries. Running iOS app on Windows without conversion in an emulator (as is possible with Android apps) is not a project goal.
The Controversy
After this was released to the public several developers noticed that their work was included in the WinObjC project without attribution. These developers include Peter Steinberger and Christopher J.W. Lloyd. While these omissions have since been corrected, these developers were rightly upset that their code was initially used in this manner. When asked about this matter, Microsoft responded with the following:
“We missed a couple of attributions with our initial Islandwood preview release. The community caught the mistakes and we immediately fixed them. We appreciate the feedback and apologize for the oversight.”
Revealing the source to the project also brought up a potential security issue that could be considered risky or dangerous in its own right. Landon Fuller found that the project is currently replacing the functionality of the arc4random() function with the less optimal rand() function. The danger is that as currently implemented developers may overlook the details and think they are making use of the arc4random() function when in reality they are not. When asked about this, Microsoft’s provided the following statement:
“This initial preview is primarily meant to generate community feedback on the core architecture of the project to help ensure we have a solid foundation to build on. Feedback to date suggests that core project components such as compiler integration and Windows interoperability are architecturally sound. We released an early preview knowing that the community would help find gaps in our technology and our processes and we’ve already made fixes to things like code attribution based on community input. We’re very encouraged by the level of interest and constructive feedback that the Islandwood preview is generating and will keep working with the community to improve the project.”
For background, Matt Thompson has written a brief explanation for why arc4random() is considered a better choice (see the section “Why Should I Use arc4random(3) instead of rand(3) or random(3)?”).