Enable the use of existing iOS libraries

[Alovchin91]

This is more like a suggestion than an issue.

I would like to see an ability to build Windows Runtime components that can be used from any supported language and that can use existing iOS libraries.

I'm a C# developer, and the company I work for uses Flurry Analytics in mobile apps. I'm building mobile apps for Windows and Windows Phone, and recently I learned that Flurry doesn't support Windows Runtime SDK anymore. This issue could be easily solved with Windows iOS Bridge by just using Flurry's iOS SDK and wrapping it up in a Windows Runtime component.

I believe there are many other examples of such an application for iOS Bridge.

Windows Runtime components are discussed in issue #20

[AhmadBaracat]

I think this is a great idea and would open the door to many libraries that does not support Windows. Do you think we, developers, can start working on it?

[Alovchin91]

The only issue I see is external library's processor architecture. This means iOS libraries would not run on x86-x64 machines, though Mac libraries should. The iOS Bridge compiler could analyze all the external imports in the code, and then the linker could create a section in the resulting PE file that lists all those imports. Then the stub code in the PE could call iOS Bridge Runtime to load each external iOS library and analyze its imports (now here I'm not sure how iOS library's import section looks like) and then patch them to point into the Runtime's functions. Much the same way Windows loader works.

[colincornaby]

A serious issue would be API support. A lot of libraries might try linking to API that's not there. For example, a library we ship tries to touch a lot of API that's not present. Even then, the behaviors could be different. It seems like it could be a lot more trouble than it's worth for a Windows native application.

Most libraries ship with x86 libraries in since the iOS Simulator is x86 (and x86-64), so that's not a serious problem.

[colincornaby]

If we're talking about binary libraries, existing binaries could do things like call into Mach or the iOS kernel functions (or even BSD functions) which probably won't be emulated or would be difficult to emulate for this API. For example, an API like Flurry might ask kernel level code for device configuration, and that's going to be very difficult to emulate through an API like this.

[Alovchin91]

Okay, I see. Let me split this issue into two then as it also contains another important suggestion: #20

[rhaning]

Thanks for the idea, we don't have any plans for supporting iOS binaries at this time.