An iOS plugin that fails to run in the IOS Simulator

SDKs Plugins
1

So I figured that a MobileControl plugin using the UIKit requires a Cocoa replica to display in the IDE. This has nothing to do with Xcode’s Mac Catalist. Fine. I get that because after all Xojo is not Xcode and It runs and depends on Cocoa. But when a debug-run is issued, the plugin causes Xojo or its connection with the simulator to end. Unfortunately, I cannot determine why, because Xojo’s debugger quits without any info, and the simulator complains that it cannot find the debugger.

The EyeControl example does not help because it does not use Cocoa and UIKit, it simply uses Xojo Graphics.

Help.

2

I think that Xcode 12.4 is causing the inability to run the simulator in Xojo. EyeControl does not work in my hands.

RegisterExecutionPolicyException /Users/anvh/Library/Developer/Xcode/DerivedData/EyeControl-bcedtkvponkxnbdorhmevlwrbhbt/Build/Products/Debug-iphonesimulator/libEyeControl_iOS_Simulator.dylib (in target ‘EyeControl_iOS_Simulator’ from project ‘EyeControl’)
cd /Applications/Xojo\ 2020\ Release\ 2.1/Extras/PluginsSDK/Examples/Eye\ Control/Xcode
builtin-RegisterExecutionPolicyException /Users/anvh/Library/Developer/Xcode/DerivedData/EyeControl-bcedtkvponkxnbdorhmevlwrbhbt/Build/Products/Debug-iphonesimulator/libEyeControl_iOS_Simulator.dylib

3

The RegisterExecutionPolicyException can be avoided when the new build system of Xcode is disabled. But it does not solve the problem. Using Xcode 10.2 in macOS Mojave and whether or not the new building system is invoked (RegisterExecutionPolicyException is not generated), I cannot get EyeControl to work in the simulator. Am I the only one who tries the REALMobileControl? What am I doing wrong? What is necessary?

4

Stepping back and start from zero.

  1. Took the EyeControl example and compiled it on a MacBook Pro M1 using Xcode 12.4 strait out of the box and set the Schemes to release.
  2. Using the plugin structure containing inside the Build Resources the folders IOS Device (empty), IOS Simulator (libEyeControl_iOS_Simulator.dylib (universal or x86_64)) and Mac Universal (libEyeControl.dylib) and Xojo happily shows the EyeControlMobile in its iOS library. Note that omission of the EyeControl (defined by libEyeControl.dylib) in the plugin causes Xojo not to load the EyeControlMobile.
  3. Placing the EyeControlMobile on Screen1 and running it leads to compiler issues:
    ----------- Screen1.Name
    There is more than one method with this name but this does not match any of the available signatures.
    Screen1
    ---------- Screen1.EyeControlMobile1.Name Layout (property name)
    Can’t find a type with this name
    Name
    ---------- Screen1.EyeControlMobile1.Name Layout (property name)
    This item does not exist
    Name
    ---------- Screen1.EyeControlMobile1.Name Layout (property name)
    Can’t find a type with this name
    Name

So that is the underlying culprit I could not get our plugin to work in the debugger. Xojo is messed up when the EyeControlMobile is used.

5

I’m still on Xcode 12.2 but everything is working here (using 2020r2.1), did you already try clearing the caches? (i.e. Xojo Preferences->Build->Clear Caches). Here’s my build, nothing modified from the examples, except of course with enabling SUPPORTS_IOS_TARGET
EyeControl plugin

6

Thanks for responding. When Xojo is launched I get the following when using the downloaded plugin:
“libEyeControl.dylib” can’t be opened because Apple cannot check it for malicious software.
and
This software needs to be updated. Contact the developer for more information.

Of course I could use Xcode 10.2 on Mojave intel Mac, but:
Xcode 12.2 shouldn’t be too different from Xcode 12.4. Are you on an intel Mac? Is it because I am on a M1 Mac? And yes I cleared the caches.

7

It is weird. Using the plugin created with Xcode 12.4 in Mojave and loaded by Xojo 2020r2.1, I get two EyeControlMobile icons in the library and when dropped on Screen1 they generate a question mark and the complier balks with the same messages as indicated above.

So it is definitely Xcode 12.4 doing all this crap. Jeez., Hope I can download Xcode 12.2 then.

8

And I forgot to acknowledge that the downloaded plugin in Mojave/Xojo 2020r2.1 indeed behaves as you indicated.

9

Are you signing your plugins?

10

Yes, I do. And I got it to work but for another reason. The details will be forthcoming. Have to figure a couple of things.

11

Is there a way to discriminate between a Desktop application and a Mobile application? We can discriminate between a console application and a desktop application. So I tried:

EyeControlData* GetData(REALobject theObj)
{
REALobject (_App)(void) = nil;
if (!_App)
_App = (REALobject ()(void))REALLoadFrameworkMethod(“App() as MobileApplication”);
if (!_App)
_App = (REALobject (*)(void))REALLoadFrameworkMethod(“App() as Application”);

REALobject appObject = _App();

REALclassRef ref = REALGetClassRef("Application");

if (ref && REALObjectIsA(appObject, ref)) {
    MSG(com.vanhoekplugins "Desktop Application");
    return (EyeControlData*)REALGetControlData(theObj, &EyeDefinition);
}

ref = REALGetClassRef("MobileApplication");

if (ref && REALObjectIsA(appObject, ref)) {
    MSG(com.vanhoekplugins "Mobile Application");
    return (EyeControlData*)REALGetMobileControlData(theObj, &EyeMobileDefinition);
}
return 0;

}

In the IDE we get “Application”, not “MobileApplication”. Running in the Simulator we get “MobileApplication”. The REALmobileControl uses the iOS SDK (UIView). The REALcontrol uses the MacOS SDK (NSView). Indeed, TARGET_OS_IOS returns false in the IDE, consistent with “Application”.
Our plugin defines a zillion methods, props associated with NSView and we can easily define:
#if defined(APPLE)
#if TARGET_OS_IPHONE
@compatibility_alias LSView UIView;
typedef CGRect NSRect;

#else
@compatibility_alias LSView NSView;
#endif
#endif

So that the REALMobilControl can use the methods already defined by using the GetData method to associated with either the REALcontrol or the REALmobilControl.

Another question is, can the REALmobileControl host a UIView by returning it as a handle getter, alike an NSview’s handle getter?

1 Like
12

To be clear, this behavior contrasts when we choose a consoleApplication and test for it in the IDE-console environment: it tells you “ConsoleApplication” and when debug-runned it also tells you “ConsoleApplication”. Thus, we are forced to create another huge “mm” file to circumvent what I think is a bug, tied to hard coding for the REALmobileControl. And for what it is worth, the “TARGET_OS_IOS” should also return true when in the IDE.

13

<https://xojo.com/issue/64073>

14

That doesn’t make sense. The IDE can’t load the iOS version of the code, so TARGET_OS_IOS will never be 1.

You need a Mac (dummy) version of the control to register it.

15

Am aware, but it requires to draw an NSView in the Offscreen callback. So it requires an instantiation of the macOS version of the plugin, and because the SDK is the iphonesimulator for the “iOS Simulator” you have to become very creative. And I saw your feedback post.

16

First of all, I think you are missing the point I had expressed in feedback. If you create a Console project, the IDE will respond that the App is a ConsoleApplication. Similarly, once and I hope, I would expect that a iOS project will tell us that the App is a MobileApplication. You are correct that the current version of the IDE cannot do this.

You say to create a dummy REALmobileControl that links to the AppKit? And you put that dylib in to the “iOS Simulator” directory? I do know that the REALcontrol in the “Mac Universal” directory is a requirement, but am unsure now given your dummy Mac version.

17

You may not have understood me.

Your iOS libraries will always have TARGET_OS_IOS set as you build them for that. But your plugin also must include a macOS library (TARGET_OS_IOS is not set, but TARGET_MACOS should be). There you register the plugin control for iOS; so the IDE knows about it. And you include drawing code to show the control on the window editor.

We do that for our controls. So MBS Plugin registers for example a WKWebKit control for macOS with REALcontrol and one for iOS with REALmobileControl.

18

In essence I do this already. Got the REALcontrol dydlib in the “Mac Universal” and the REALmobileControl in the “iOS Simulator” directory. And I think I know how to approach it:

#if defined(__APPLE__)
#if TARGET_OS_IOS
    #define Data(defn, instance, typeName, data) typeName *data = (typeName *) REALGetMobileControlData(instance, &defn);
#else
    #define Data(defn, instance, typeName, data) typeName *data = (typeName *) REALGetControlData(instance, &defn);
#endif

#else
#define Data(defn, instance, typeName, data) typeName *data = (typeName *) REALGetControlData(instance, &defn);
#endif

without creating a huge second file for the REALmobileControl. I was taken aback by the EyeControl example. Of course the behavior functions require specificity with AppKit vs UIKit.

Thanks for your and others responses.

19

What I mean is you have one set of cpp files where you build a dylib.
And you build it for each platform: Mac Intel, Mac ARM, iOS Simulator and iOS Device.

And each one does the REALRegisterMobileControl and REALRegisterControl.
(you may skip REALRegisterControl on iOS as it’s a NOP)

And for me I have those in two cpp files separated as the code is a bit different for each one.

20

I get and got that already