Include C++ source?

Is it possible to include C++ source in a XOJO app for IOS? My software for Windows and OSX is mostly C++ with only the userinterface and file-IO written in RealBasic. Is it possible to port this to IOS without completely rewriting it all? De C++ parts were called dynamically in .ddl (windows) and .dylib (osx) libraries. It came to my attention that dylibs are not an option in IOS. Is there any other way to include C++ in an IOS project?

You cannot call methods in C++ libraries from REALbasic or Xojo, you can only call C functions.

That is an AppStore limitation, not a technical limitation (will need some twerking though at least vor versions prior to iOS 8).

I’m a bit confused. I am calling C++ functions from within RealBasic 2009 both in the Windows and the OSX version. The C++ functions were compiled in VisualStudio (windows) and Xcode (osx). That all works fine there. So what I want to do is to port the RealBasic code that I have to XOJO for IOS and find some way to also be able to use the existing C++ code.

How do you call these functions ?

In iOS, plugins and dynamic libraries are not permitted.

[quote=255770:@Jos Maas]I’m a bit confused. I am calling C++ functions from within RealBasic 2009 both in the Windows and the OSX version. The C++ functions were compiled in VisualStudio (windows) and Xcode (osx). That all works fine there.
This works fine as you can call out to eternal dll’s etc

This DOESN’T work on iOS at all
It’s an iOS limitation

[quote=255774:@Norman Palardy]This DOESN’T work on iOS at all
It’s an iOS limitation[/quote]
dylibs work on iOS – iOS itself consists of dylibs being loaded at runtime. But you won’t get your app into the AppStore.

depends on the version
there’s a bunch of restrictions & in part this is why apple has a new scheme for how to do this on iOS

and not getting it in the app store means it cant be distributed using normal App Store channels
there are the enterprise etc but they’re not usual channels

Had to go find one of the lengthy article about ios & dynamic libraries
It’s all kinds of fun
Or just skip to the conclusion

Dynamic libraries signed by Apple can be (and are!) loaded by an iOS application
A simple iOS application loads over 150 dynamic libraries on launch
Xcode doesn’t support creating dynamic libraries, frameworks or plugins on iOS but it is very easy to work around this
If code signing were not a thing we could load dynamic libraries, frameworks and load plugins at runtime on iOS just like we do on the Mac
In practice, the kernel will kill any application that attempts to load a dynamic library that is not signed or which signature cannot be validated
A shipping dynamic library would need to be signed by Apple with the same certificate as the one used for App Store applications
Last but not least, the App Store policies don’t allow dynamic libraries and even if it were technically possible it wouldn’t pass App Store validation

Way to take what Norman said out of context (bonus points: he didn’t even say it the way you implied) to make the topic more confusing and make yourself sound ultra-correct.

In Xcode you can include both Objective-C code and C++ code that is then included in the same executable file. In that case there is no separate .dylib file. But in XOJO I can’t include C++ source, because that was never possible in RealBasic or XOJO and now I also can’t include them in dylibs because that is not possible in IOS.

It seems that there is no other option for me then to go the Apple way and port the RealBasic part to Objective-C in Xcode. That would be much less work then porting the C++ to XOJO. Also because in Realbasic it was not possible to create real threads with accurate timing in miliseconds.

There are other newer mechanisms that, once we drop support for iOS 7, come into play
They open more possibilities
I just dont know off the top of my head what the schedule is for removing support but iOS 7 is already marked as deprecated

Build and use dylib on iOS

Been there done that read it

Still cant get it out the door for the reasons cited in the article I linked to (which also details how to make an iOS dylib)

If that only works on jailbroken ios device then that would be a big reduction of the market for my product. In an early windows version of this product, customers had to replace a single file to turn the demo into a full version. You don’t want to know how many people were absolutely unable to do this. And will Apple allow a product in there store that does nothing without the dylib?

In software development it is common practice to write software modules in different languages, then compile each module in a matching compiler. The resulting static libraries are then merged in an executable using a binder. My problem would be solved if Xojo for IOS included a binder that would merge the Xojo part with static lybraries produced in XCode. Or if Xojo would have an option to produce a static library instead of an executable that can be picked up in the Xcode binder and merged into an executable together with other Xcode produced static libraries .

Hah, I don’t think booty shaking going to help no matter what :wink: