@Norman P --

I think I was a little premature in my testing --

When I went to add all of the soft declares as External Methods in a separate Module, my actual runtime calls couldn't locate them generated a FunctionNotFound exception. This time I was careful to make sure I was only building a 64-bit dylib, and a 64-bit Xojo executable. The dylib IS being copied into the built app's Content/Frameworks folder.

Perhaps there's an Xcode build pref that still needs to be set? ALTHOUGH -- worked perfect when done through soft declare and path was provided...

Do External Method names need to be prefixed with the name of the Module, if that External Method is declared as "Global"?

@Norman P -- OH, you are going to be AMAZED by this...

As a TEST -- I uncommented the FIRST of four soft declares I had made during my initial testing (I had commented them out when I was testing adding all four External Methods to a separate Module)

When I did that, then there was NO PROBLEM calling the other three External Methods -- either when RUNNING or BUILDING/Double-Clicking the built app.

It's like my first soft declare (with an EXPLICIT absolute path) caused the dylib to be found and loaded, so there was no longer any kind of dynamic binding issue during execution.

If I commented out that soft declare, none of the External Methods could be found now -- although there was absolutely no link warning about an undefined symbol.

Does that theory make sense?

@Andrew Lambert -- Yes, definitely set the "soft" check box. I think this has to do with WHERE Xojo is expecting to find the dylib -- OR the crazy dylib settings like @rpath that need to be set when linking the dylib.

@Norman P --

I'm just trying to get macOS working first. And now I THINK I have:

The name of the lib's name in the External Method definition UI needed to be set to:

@executable_path/../Frameworks/libTestLibForXojo.dylib

...which is what you said:

if the dylib is in this location "@executable_path/../Frameworks/<your dylib name here>" as a result of the copy files step then things should just work

But I though you meant if the dylib was IN THAT LOCATION -- which it already was. But I hadn't set the Lib name in the UI to that EXACT syntax.

So it look good now!

Thank you! (and everyone else)!

..now on to IOS / Windows tests....

@Norman P -- OK -- so you are agreeing with what we posted above:

1) Name of the lib's name in the External Method definition UI needs to be set to: @executable_path/../Frameworks/<myDylibName.dylib>

2) Must add a Build Step > Copy Files to copy the above dylib to the Framework Folder (in the App package). This will work for BOTH "run with Debugger" or launching the built executable App.

3) In Xcode, the Linking Setting "Dynamic Library Install Name" should be just the name of the built dynamic library <myDylibName.dylib>, which is also the Xcode default of $(EXECUTABLE_PATH).

4) A CONSTANT may be created to handle different dylib paths for multiple platforms. For example, #App.kDylibLocation can be defined for platform "OS X Cocoa" for "English" as "@executable_path/../Frameworks/<myDylibName.dylib>", but for "IOS" "English", it would need to be a different path (do you know what that path might need to be?)

How's that?

@Norman P -- on the subject of dynamic libraries and IOS --

I'm running into the "FunctionNotFoundException" during the iPhone simulator execution when trying to soft declare against a C-API function in the dylib I generated for IOS 9.2 (arm7, arm64).

I DO the build_step to copy the dylib to the Frameworks folder.

Do I need to build the dylib as a "Framework" for this to work on IOS?

@Norman P -- OHHHHH -- so for the IOS simulator, i.e. Xojo's "RUN and DEBUG" option, I should use the same old dylib as MacOS? Not code built for arm7/arm64? Is that true of BUILD, too?

AND TO BE CLEAR: are you saying I should build a .dylib in Xcode against the IOS SDK but with the x86 / x86_64 architecture? Or simply USE the same Xcode-generated x86 / x86_64 dylib I build for MacOS? NOTE: in either case, these are pure C++ code libraries -- completely cross-platform -- no cocoa (or carbon) whatsoever.

At what point do I build an arm64 dylib for deploying on real IOS hardware, and can Xojo do a build integrating that dylib in a way acceptable to the Mac App store (unlike posts on this forum from 16 months ago, which stated the Mac App store would NOT accept a dylib)?

Your documentation states that the simulator only (presently) runs a 32-bit app. Has that changed? Obviously, 32-bit is now history on IOS.

when you build for simulator, Xcode will automatically build x86/x64 for you.

@Norman P --

I think the problem(s) I'm running into with IOS MAY be due to using Xcode 7.2.1. Xcode 8.x is the minimum required for proper IOS & Xojo?

I'm also seeing an issue with normal macOS where a Xojo External Method with a parameter of Int32 is not finding the corresponding C-API dylib function with that parameter defined as int32_t. That should absolutely work, right?

@Norman P --

Got Xojo's invocation of the IOS SIMULATOR to access and correctly call dylib, but ONLY if I use soft declare and provide a full path to the dylib.

But trying to use the External Method approach didn't work for IOS as it had for macOS -- it results in a compile-time error, "this item does not exist", for each of the External Methods I call.

HOW I SET UP THE EXTERNAL METHODS:

• Build Copy step copies dylib to Frameworks
• Lib field in External Method definition uses @executable_path/Frameworks/libIOSTestLibForXojo_simulator.dylib
• Soft checkbox selected; Objective-C checkbox NOT selected. Scope = "Global"

Even explicitly setting each External Method's Lib field to the same exact path as I provided for soft declare results in the compile-time error "this item does not exist" for each call.

In both cases (soft declare and External Method) the dylib was compiled for i386 architecture. That worked perfectly with soft declare and IOS Simulator.

Is there any documentation, FAQ, tutorial, etc. that discusses the library path for calling one's own dylib / framework for an IOS project?

As for submission to the app store I am not 100% sure if they will or will not accept apps with dylibs in the Frameworks dir of the app package

@Norman Palardy --

I'm happy to package my library for IOS by any method (dylib, Framework, or Xcode-linked .a file) that allows it to become part of the Xojo-generated app but it MUST get into the app store. There MUST be an absolute sure-fire route to do so, Right? Otherwise the thousands of IOS MonkeyBread functions offered by @Christian Schmitz wouldn't function on IOS?

I have a large, deep, and battle-tested library of non-UI cross-platform C++ code with a C-API that is essential to work with the Xojo front end on ALL platforms.