Quick question, a search of the forums doesn’t seem to answer it for me (unless I missed the thread!)
Is the restriction on plugins a Xojo limitation or a thing that iOS doesn’t allow?
Just curious really…
Originally it was an iOS limitation, but there’s still no intention of making a C-based plugins SDK. Plugins for iOS will be written in Xojo and can include static libraries or other resources they might need.
Is not the principal interest of plugins to wrap C functions ? Especially Objective-C or Swift in this instance ?
Seems to me Xojo plugins are extremely interesting, but the recourse to Objective-C would seem a must. As Jason King and Ulrich Bogun encountered, there are limits to declares in Xojo.
This is where the static libraries come into play. If something can’t be accomplished in Xojo code, the plugin just needs to declare into the static library and that can be written in C or Objective-C.
Seems to me, if it COULD be written in XOJO code, there would be less of a need/desire for it to be in plug-in format. A plug-in should extend the functionality, and as we ALL know… XOJO for iOS needs alot of extending
The reason for “plugin” is just to make it so authors can distribute a compiled binary like any other plugin author
Not everyone wants to give away their source code
[quote=245542:@Norman Palardy]The reason for “plugin” is just to make it so authors can distribute a compiled binary like any other plugin author
Not everyone wants to give away their source code[/quote]
That I can understand. And I am looking forward for it, as a third party developer working primarily in pure Xojo code.
But on iOS, that is not the prime need I think.
If Christian was able part but a small fraction of his plugins to iOS, it would considerably boost the possibilities of a rather indigent Xojo iOS.
Thanks Joe - I’d completely forgotten about the plan for Xojo based plugins…
But with Xojo based plugins we can extend ourselves, all in the one language, without having to go to a 3rd party or getting dirty in the plugins SDK - unless I’ve missed something.
Except in iOS there are things that the very way Xojo is built prevents manipulating. I am a whole lot less savy than Jason King and Ulrich Bogun in the matter, but I know Xojo chose to manage views in a much less complete manner than XCode. As a result, there are things that are simply impossible to do in Xojo iOS.
There are also other places where declares do not suffice, because Xojo lacks the building blocks necessary to address the framework. Our two official specialists I mentioned above could tell you a good deal more about why they hit a wall in their commendable effort to access certain features.
It is a fact that the iOS framework is intended to be called in Objective-C or in Swift. In spite of nifty workarounds, sometimes there are simply no way around Xojo limitations. It would be nice to have access.
Yet again, seems to me the Fisher Price approach taken by Xojo for iOS could kill its growth possibilities. Sure, it is utterly safe, as everything is meant to protect users from shooting themselves in the foot. Just like Fisher Price Roller Skates. But at one point the child needs to try real roller skates. If it is forbidden by mother Xojo (who knows best), he will surely try the forbidden toy elsewhere. And we all know how close the B4X site is.
I like Xojo. Up until now, being able to produce very fast or very powerful plugins in C was part of the attractiveness of the language. Now we are told that won’t be possible anymore. Pity.
Of course they will still be possible. We anticipate many plugins will still have C based libraries in the new system- and that includes libraries built for iOS in Xcode. It’s just instead of a separate C SDK layer for plugins, you’ll just use Xojo to call to those libraries.
That is different. If we can call C libraries directly from Xojo, that is welcome novelty ! Thank you Travis.
Yes. The new plugin system will be Xojo code based. That alone will open up the doors for more people to build plugins. But it certainly does not preclude including (and calling) libraries built in other languages like the current plugin system, as Joe mentioned above. We wouldn’t limit the system in that way.
I don’t know enough about iOS yet to comment on the problems Ulrich/Jason have had with hooking into the iOS Framework. The fact Declares and the Canvas are there makes it a lot more flexible than it could have been. It does seem that more controls are overdue but I think I read somewhere that the release after next will show love to iOS(?)
#Cough# Wind*ws #Cough, Cough!#
Xojo based plugins, that’s got to be a good thing. though. I remember thinking that when I heard about those but that was some time ago now hence my forgetting 
Already, the introduction of the ContainerControl is a way to create encrypted custom controls.
Looking forward for plugins 