Xojo plugins are add-ons that extend the functionality of the Xojo development environment, allowing developers to add additional features, integrate third-party libraries, and much more.

Write a Xojo Plugin

This article assumes familiarity with the Xojo Plugin SDK and focuses on automating plugin builds. If you’re new to plugin development, check out the resources in Xojo’s “Extras” folder, YouTube tutorials, and the Xojo Forum.

It builds on my previous blog post Xojo Github Actions and involves Docker, which has also been a part of a previous blog posts (Docker, Database Servers and Xojo, Running Xojo Web Applications in Docker). So read up there on what a GitHub Actions workflow is, what the .yaml files in the Folder .github/workflows are used for.

Build a Xojo Plugin

Since Xojo is a cross platform development environment, a Xojo plugin needs to be built for all the supported platforms (Windows, macOS, Linux) and all their architectures (Intel/ARM, 32/64Bit).

All the plugin parts (the Windows .dll‘s, .macOS .dylib‘s and Linux .so‘s) are being packaged into a .xojo_plugin file.

One of the challenges is to have an environment to build all that. At the first glance it seems that one would need a Mac, a Windows machine – as well as some Linux environment (any of which could also just be a virtual machine). And one would first think that there will be a lot of manual steps involved – building the plugin source on various machines, copying all the built plugin parts together to finally assemble the resulting .xojo_plugin.

However – all that is not required. You can build a Xojo plugin without your own machine being involved, fully automated. GitHub Actions provides all we need.

Example: CubeSQLPlugin

Let us have a look at this existing Open Source Plugin.

CubeSQLPlugin is an extension for the Xojo programming environment that allows developers to use CubeSQL, a fully featured and high performance relational database management system built on top of the SQLite database engine.

The plugin is being used in the Open Sourced Administrations Tools for CubeSQL, which are both written in Xojo: CubeSQL Web Admin and CubeSQL (Desktop) Admin.

Internally the plugin uses LibreSSL for TLS Connections of Database Clients to CubeSQL Server. This means that first the LibreSSL libs need to be built for all build targets. Only then can the plugin source be built again for all build targets. And finally, all the plugin parts need to be assembled into the Xojo plugin structure for the final .xojo_plugin.

We have automated the whole build process of the plugin using GitHub Actions by having created three workflows. You’ll find their source in the folder .github/workflows. All workflow executions you’ll find on GitHub in the tab named Actions (as long as they have not been deleted or removed).

LibreSSL
This workflow will download the LibreSSL Source, and build it for all needed build targets. It needs to be run only once, e.g. if a new LibreSSL version is available that should be included for the next plugin build. That’s why it’s a workflow that can be run manually. It asks which LibreSSL version should be built and whether the built libraries should be committed and pushed to the repository.

CubeSQLPlugin
This workflow will build the CubeSQL Xojo Plugin for all build targets using the currently committed LibreSSL libs in the repository. It will commit and push all the built .dll‘s, .dylib‘s and .so‘s to the repository.

Create Release
That one is pretty obvious, right? It builds the structure of the final .xojo_plugin and creates a new Release in the repository with the final Xojo plugin – ready to be downloaded.

Build for all Platforms and Architectures

The two workflows “LibreSSL” and “CubeSQLPlugin” are similar in their approach to building for all the supported platforms (Windows, macOS, Linux) and all their architectures (Intel/ARM, 32/64Bit).

GitHub offers hosted virtual machines to run workflows. All virtual machines contain an environment of tools, packages, and settings available for GitHub Actions workflows to use.

So our workflows can simply use these environments. The workflows consist of several steps, each of which can be executed on a different runner. Remember that I’ve written: “You can build a Xojo plugin without your own machine involved”?

In the following ScreenShot we’re seeing that the Linux-ARM64 plugin part is being created on a Ubuntu 24.04.1 ARM machine.

macOS

• Runs on a GitHub macOS virtual machine.
• Uses the preinstalled Xcode command line tools to build “Intel x86_64” and “ARM64” and combine the two to a universal binary.
• CodeSigns with credentials added as repository secrets.

Linux

• ARM32, ARM64
  • Runs on a GitHub Linux virtual ARM machine.
  • To always have exactly the same build toolset (e.g. so that it doesn’t matter if GitHub updates to a newer Ubuntu version) it leverages a Docker container (e.g. arm64v8/gcc) – and actually builds the source inside the Docker container.
• i386, x86_64
  • Runs on a GitHub Linux virtual Intel machine.
  • Also uses a gcc Docker Image to build the source.

Windows

• Runs on a GitHub Windows virtual machine.
• Uses the preinstalled Visual Studio environment to build all “win32”, “x64” and “ARM64”.

How to Build your Xojo Plugin

I’m very well aware that this article can’t help you build your plugin. Each one is individual and needs its own steps and processes.

However, should you consider automating your plugin build process. You might want to look in more detail in the open-source plugin source and the workflows which are building CubeSQLPlugin for all required targets and architectures.

How to Transition from Manual to Automated

While creating a plugin, one doesn’t think of its build process in the early stages, maybe not even for the first few released versions. 

Plugin building is usually a manual process, requiring manual execution of a lot of steps and commands on various machines. It is tedious and prone to errors. It takes time, which adds up the more you build. There’s a point when one should think about streamlining and automate the process, allowing for building new versions without too much effort.
In addition, it’s certainly a good idea to have a consistent build environment other than your own development machine as you could install and change things on there which could impact the builds. That’s why building inside a Docker container is an interesting approach – it will remain exactly the same each and every time, even if the host machine is changed (e.g. by being updated to a new operating system version).

All that used to be like that before having written the GitHub workflow.

How can you transition from a manual to an automated process for your own project? I won’t be able to provide all answers. But, I’d like to give a few ideas of possible steps, with no intention of them being complete or the best choice for your project.

• Use a version control system.
  • Git and GitHub are (for many use cases) free.
  • Using a Cloud solution serves as a backup should something happen to your machines.
  • You can additionally benefit from other services such as the GitHub Actions workflows mentioned in this article.
• Everything that is only in your head should go into some written form. Once you don’t need to do something for some time, you might forget or miss something.
  • Start with documenting all steps, commands, and actions.
• Try to get rid of manual steps. Are you copy-and-pasting several commands to a terminal each and every time?
  • Put them in a shell script, so that you only need to run one command.
  • You can use these scripts later when going to a fully-automated system.
• When initial development is finished and you’re ready to release:
  • Don’t do releases from your development machine. It might be defunct, broken, stolen, or you’re installing some new cool stuff and suddenly notice issues with other projects. Having a dedicated build machine is one idea.
  • Another is going the “GitHub Actions” way which also has its benefits.
    • Runners are virtual machines that are provisioned and “fresh” every time. It’s always the very same environment to start with for each build, no matter what you’re doing during a build.
    • You don’t need to maintain many different build machines yourself. This can even solve some security issues, as it’s probably not your main interest of keeping everything up to date. I prefer to focus on programming and not on system maintenance.
    • However, the runners might be outdated in a few years – and new runners (with newer operating systems) will be available.
      • That’s usually not a very big issue on macOS and Windows since their build tools are usually backwards compatible for quite a long time.
      • Especially for Linux we have decided not to rely on the provided host but use a Docker Image and run the builds inside a Docker container. So you can, for example, use a Docker container with an image that perfectly fits your lowest compatibility needs, while the host itself might only have (too) new libraries installed.
  • Start putting all your steps and scripts into a workflow – be it just on your dedicated build environment, or using GitHub Actions.
    • Certainly separate them per required host (macOS / Windows / Linux).
    • Split a long script into smaller parts, e.g: Download LibreSSL, Build x86_64, Build arm64, Build Universal.
      • In case of an error, it’s easier to see that “macOS: Build arm64 has failed”, compared to “Build for macOS has failed” (because it’s all in a lengthy script).
• Running the workflows manually is great and likely more than good enough.
  Once the project activity grows (e.g. you’re receiving a lot of pull request or have many developers working on it):
  • Ensure that the build and test workflows are running on each pull request, require them to complete successfully before being able to merge. That by the way has been explained in the previous blog post Xojo GitHub Actions. After all, no one wants to find out after many commits that the build is no longer working, and then have to search the history for what might have caused the problem.
• You’ll notice that once it’s all automated you no longer miss it. It causes no additional effort for you, instead bringing a lot of benefits (such as noticing early when code changes cause oddities in tests and builds).

A Fun Fact

In the early days a build of the CubeSQLPlugin often took a couple of hours – and with personal attention needed so that one couldn’t work on much else during that time.

The first iteration of the workflows reduced the entire build (LibreSSL + Plugin) to about 25 minutes. With no attention and manual interaction needed – which means more time for other work. What took the longest was the LibreSSL ARM builds – they have been run on Intel hardware with QEMU for ARM emulation.

Back to the beginning of this article and Xojo’s 2025 Year of Code initiative – in February I have improved the workflows to use the newly available GitHub Actions runners that run on ARM hardware. Which means that no more emulation is required – and the build time has now come down to about 4 minutes for LibreSSL Libs (required only once per new LibreSSL version) and 2.5 minutes for the Xojo database plugin for all its supported platforms and architectures!

That’s All Folks!

I hope this brief introduction of how to use GitHub Actions workflows and Docker to build a Xojo plugin has been helpful to some, food for thought to others.

Jürg Otter is a long term user of Xojo and working for CM Informatik AG. Their Application CMI LehrerOffice is a Xojo Design Award Winner 2018. In his leisure time Jürg provides some bits and pieces for Xojo Developers.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

The 2020 Xojo Design Award Winners are:

Best Consumer App – HDRtist NX

Ohanaware: A detail-oriented High Dynamic Range Imaging app for MacOS X.

Best iOS App – PropertyMe Manager

PropertyMe: The PropertyMe Manager app gives property managers access to their portfolio wherever they are.

Best Lifestyle App – Crossword Wizard

Rush Software: Create and play crossword games.

Best Developer Tool – RegExRX

MacTechnologies Consulting: A cross-platform Regular Expression development tool.

Best Vertical Market App – qwireCast

qWire: Desktop app to help Hollywood casting director make cast lists.

Best Vertical Market App – bMD Medical Software*

bMD biomedical Developments SRL: Medical practice management software.

Best Plugin – MBS Plugins

MonkeyBread Software: This huge toolbox for Xojo developers includes thousands of classes, controls and examples to extend Xojo.

*Yes, there are two Best Vertical Market Apps, they were both so good we had no choice but to award them both!

Please run a current Xojo version with MBS Xojo Mac64bit Plugin installed. Due to our dependencies list, please add Main, MacCloud, MacBase, MacCocoa, MacControls, MacCG and MacCF plugins too. Start with a new project. To the window we add a SCNControlMBS control from the library and rename it MyControl. Drag it across the entire window size and lock all edges. It is very useful because we want fullscreen mode later. 

Then we need two properties MyScene and MyView. MyScene has the type SCNSceneMBS and MyView has the type SCNViewMBS. Afterwards, add the open event of the SceneKit control. 

We start with the setting of MyView and MyScene like this:

MyView = Me.View 
MyScene = New SCNSceneMBS
MyView.scene = MyScene

Then we enable the default light and the camera control, because we want to see a 3D effect and want to move the camera using the mouse. We set black as the background color.

myView.autoenablesDefaultLighting = True  
MyView.allowsCameraControl = True   
myView.backgroundColor = NSColorMBS.blackColor 

Next we add our first node to the scene. The center of the scene is the Sun. In basic structure the Sun is a lit up sphere. So we add a sphere geometry with a given size. In this project we can’t work with the original conditions, because Mercury would be so small that it is impossible to see. Plus, we would have same problem for the distance between the Sun and the planets. Because that, our Sun has a radius of 13. Then we add a node and give it geometric information about the Sun. The position of the node is the origin with the coordinates 0,0,0. Finally, we add the node to our scene. 

Dim SunGeometry As New SCNSphereMBS(13)  
Dim Sun As New SCNNodeMBS(SunGeometry)  
Sun.Position = New SCNVector3MBS(0, 0, 0)   
MyScene.rootNode.addChildNode(Sun)

Then we start our program. 

We see a white sphere on the screen. The Sun looks a bit edged because of the segment count. Our Sun sphere is very big and needs more segments then the default segment count. Set the segment count property ahead of adding the node to the scene command. 

	SunGeometry.segmentCount=100 

Then we set each planet in a similar way. Because the planets look different, we want to change their colors as appropriate or even put a picture as a graphic over each sphere. For the color of an object we have the firstMaterial.diffuse.contents Property. This is how you would set a gray color for Mercury. 

 MercuryGeometry.firstMaterial.diffuse.contents = NSColorMBS.grayColor

If we want to map a picture on a geometry, for example for Earth, we add this picture to our project and set it to the geometry. It’s a bit like covering it with a blanket with a high percentage of elongation. We can imagine that by covering a sphere, we stretch the blanket on the equator more than on the polar caps. Because that, if you look on a map, the longitudes and latitudes are not parallel, but rather bent. In reality the longitude and latitude are parallel. You can see that on a globe. Fortunately for us a world map is already a perfect UV map for a sphere. Thanks to the website www.ginkgomaps.com which supplies world maps to everyone. I used one of these maps in my example. You can customize the map with a graphic program. Then add it to the project and set it in the property. 

Dim EarthGeometry As New SCNSphereMBS(1.47)  
EarthGeometry.segmentCount=100  
Dim Earth As New SCNNodeMBS(EarthGeometry)  
EarthGeometry.firstMaterial.diffuse.contents = EarthPic  
Earth.Position = New SCNVector3MBS(25, 0, 0)   
MyScene.rootNode.addChildNode(Earth)

All other textures I draw myself in a graphic program.

For the position of the Planets, we must pay attention to the fact that the origin of the single planets are in the center of the sphere and we set in the constructor of the geometry as the radius and not the diameter. The distance between two planets are: radius of planet 1+radius of planet two+ space between them. 

Following this same pattern we add the other planets. Saturn has a planetary ring. The ring is a tube with an inner radius that is bigger than the planet and a small hight. I use the same structure on the ring as on the planet. The tube is a bit rotated. We rotate the ring a bit by x and y. The specification of a rotation looks like this: 

saturnRing.orientation = New SCNVector4MBS(-0.4, -0.5, 0, 1)

Let’s Move the Solar System

Now we want to move the Scene. We assume that the planets’ orbits are all parallel to the xz plane and that they are exactly circular. To roate around a certain point, we create a geometry for each rotation. It lies in the point and is a parent node of the geometry. If a parent node moves, a child node moves too. The inverse does not apply. In that way, if we rotate the helping node in the origin, the child node moves around the origin too. We cannot use the Sun as the parent node for all planets because the planets are supposed to move at different speeds. 

The creation of the geometry looks similar for each planet:

Dim UranusRotationGeometry As New SCNSphereMBS(1)  
Dim UranusRotation As New SCNNodeMBS(UranusRotationGeometry) 
UranusRotation.Position = New SCNVector3MBS(0, 0, 0)  
MyScene.rootNode.addChildNode(UranusRotation) 

UranusRotation.addChildNode(Uranus) 

These geometries are covered by the Sun. 

Then we add the movements. We defined a rotation of the helping node and set the information about the rotation. We want to rotate around the y axis in each cycle about 360°. The information is given in the unit rad. Because of this we must convert 360° to 6.283 rad. The last parameter is about the speed of the operation. In this section we can set the proportion of the speed of the planets. The speed of Earth is the basic value. Everything is based on this value. The assumption is: an Earth year lasts 365 days. For each planet we use the number of Earth days a planet takes to rotate once around the Sun. We divide this value by the days of an Earth year. For Neptune we get a value that is approximate to 164.79 rad. That we can multiply with a variable. The variable can be set by the customer to regulate the speed of the solar system. We want to repeat this movement again and again. In this way we set it. In the last step we set this rotation to the scene.  

Dim moveNeptune As SCNActionMBS = SCNActionMBS.rotateBy(0, 6.283, 0, 164.79 * speed)
Dim Neptunerepeat As SCNActionMBS = SCNActionMBS.repeatActionForever(moveNeptune)
NeptuneRotation.runAction(Neptunerepeat)

Finally, we want to talk about lighting. The Sun is the light source. It is a light that comes from a point and shines in all directions. That type of light source is called an omni light. We define a light as a property from a node. Since our Sun is a node in the scene, we add the light property directly. All nodes that spray light don’t get any light and they are normally black. With the emission property we can make the sphere look like it is glowing. We choose yellow as color. 

Dim SunGeometry As New SCNSphereMBS(13) 
Dim Sun As New SCNNodeMBS(SunGeometry) 
sun.Light = New SCNLightMBS 
sun.Light.Type = SCNLightMBS.SCNLightTypeOmni 
sun.Light.Intensity = 2000
sun.light.Color = NSColorMBS.whiteColor sun.Light.Intensity = 2000 SunGeometry.firstMaterial.emission.contents = NSColorMBS.yellowColor SunGeometry.segmentCount = 100 
Sun.Position = New SCNVector3MBS(0, 0, 0)  
MyScene.rootNode.addChildNode(Sun)

The scene seems very dark if the Sun is our only light source, so add weak ambient light that lights up all elements in the same way. The unit of the light intensity is lumen. Now you can run the project and admire your own programmed solar system. Have a lot of fun with that. Link to project.

If you have questions about SceneKit don’t hesitate to contact me. And please join my session about SceneKit at the XOJO.CONNECT conference in Nashville.

Download the project.

Stefanie Juchmes studies computer science at the University of Bonn. She came in touch with Xojo due to the work of her brother-in-law and got a junior developer position in early 2019 at Monkeybread Software. You may have also read her articles in Xojo Developer Magazine. 

Since the early days there has been the feature request to use the graphics class in Xojo to draw to a PDF document. We recently came back to this old feature request and decided to try a new way to implement it and our new code seems to work just fine. With some help from Xojo engineers, we even got the alignment right.

At the Xojo Developer Conference 2019 in Miami in the presentation about news in MBS Xojo Plugin, Christian Schmitz presented this new feature. We can draw the normal drawing commands for lines, rectangles, polygons and pictures, but also text and even vector graphics. With the support of vector graphics, you can even use the report engine in Xojo and let it output your reports as PDF documents.

In your project, you can have a central draw(g as graphics) method, which handles drawing your content. For a print preview, you can let it draw to a picture and show the picture scaled down in a canvas. The same code can be called for drawing to a graphics object from printer received via OpenPrinterDialog function. And for saving as PDF, you can use the graphics object from DynaPDF. Just query PageGraphics object while you have a PDF page open.

Here is a code example:

Dim pdf As New DynapdfMBS
Dim f As FolderItem = SpecialFolder.Desktop.Child(“DynaPDF Graphics.pdf”)

// For this example you can use a Starter, Lite, Pro or Enterprise License
‘pdf.SetLicenseKey “Starter” 

// Create new PDF. Use f = nil for in-memory PDF
Call pdf.CreateNewPDF(f)

// append a new page, so we have an open page
Call pdf.Append 

// get graphics object to draw on the page
Dim g As Graphics = pdf.PageGraphics

// draw as usual
g.DrawString “Hello World”, 105, 100
g.DrawRect 100, 80, 100, 100

// close page and file
Call pdf.EndPage 
Call pdf.CloseFile

// for in-memory PDF, use GetBuffer here to grab it.
‘Dim PDFData As String = pdf.GetBuffer

As you see, we use normal drawing commands for adding text to the page. A few lines are needed to setup the PDF environment and after drawing to properly close the file. If you like to customize the new PDF pages, you can implement NextPage event on DynaPDFMBS class and for example import an existing PDF document as letter paper for your background. You should also implement Error event to handle any problem while creating the PDF document. 

Depending on your DynaPDF license, other features like rendering PDF Pages, importing of other PDF pages or digital signatures may be possible. But even with starter license, you can create new PDF documents and draw into them. If you have questions, please do not hesitate to contact Monkeybread Software.

Christian Schmitz has been active in the Xojo community for over 20 years. As the developer behind the Monkeybread Software Plugins he provides thousands of classes and example projects to help you build better applications with Xojo. In Europe, Christian has organized over 10 conferences, including the upcoming conference in Cologne this fall. You may have also read his articles in Xojo Developer Magazine. DynaPDF and other MBS plugins are available in the Xojo Add-Ons Store and at Monkeybread Software.

I did some research and found that Amazon provides a service that does exactly what the client was asking for. The service, called Amazon Translate, is available as one of many services that are available through Amazon Web Services.

In this post, I’ll walk you through the process of getting signed up for Amazon Translate, and then share some code that you can use to add language translation to your own Xojo projects. We’ll use the MBS Xojo CURL Plugin, which makes calling the Amazon Translate API easy. But first, let’s learn a little about Amazon Translate.

Amazon Translate

Amazon Translate is an API that can be used to translate text on demand. You send it text in a “source language,” tell the API what that source language is, as well as the “target language” that you want the text translated to. The API responds with the translated text.

Amazon Translate uses machine learning and neural networks that have been designed specifically for language translation. When performing a translation, the service reads the text one sentence at a time, and reads each word individually, to determine the meaning of a sentence. In other words, the service doesn’t just translate words. Instead, it’s acting as an interpreter. This results in translations that are extremely accurate.

In order to use Amazon Translate, you’ll need an AWS account. If you already have an AWS account, log into the account.

Next, you’ll need to create an “Identity and Access Management” (IAM) user. To do so, under Services, select “IAM” (which can be found in the “Security, Identity, & Compliance” category). This will present you with the IAM Dashboard.

Under Groups, create a new group and give it a recognizable name. For example, you might call the group “translate.” As you are creating the group, give it the “TranslateFullAccess” permission.

Next, create an IAM user. Under Users, click the “Add user” button. Give the user a name such as “XojoTranslater.” For the “AWS access type” be sure to select “Programmatic access.” Add the user to the “translate” group that you created above. There’s no need to assign any tags to the user, so you can skip that step.

And finally, create an Access key for the user. Be sure to make note of both the “Access key ID” and “Secret access key” values that are automatically assigned. You’ll need these in order to make API calls.

The MBS Xojo CURL Plugin

If you don’t already have the MBS Xojo CURL Plugin, download it and install it. To install the plugin, simply drag it into the Xojo “Plugins” folder.

The project will work with an unlicensed version of the MBS Xojo CURL Plugin. In this case, you’ll occasionally see a popup message reminding you to purchase a license. However, I highly encourage you to purchase a license. You can license the plugin individually, or as part of the MBS Complete plugin bundle.

The Xojo Example Project

To demonstrate the Amazon Translate service, I’ve put together an example Xojo desktop project (project file). Before running the application, be sure to set the three App-level properties: AWSAccessKeyId, AWSSecretAccessKey, and the AWSRegion. For the AWSAccessKeyId and AWSSecretAccessKey properties, use the values that you set when you created the Access key for the user. For the AWSRegion, refer to this and use the value that makes the most sense for you.

Once you’ve configured the app, run it, and it will look something like this.

The Xojo Code

Let’s take a look at some of the code.

The AWSTranslator class is a subclass of the CURLSMBS class. The class does two important things: It provides access to a list of the languages that are supported, and provides a method for calling the Amazon Translate API.

The “Languages” property is a dictionary that you can use to get the names of the languages that Amazon Translate supports and the corresponding language codes. The example app uses this dictionary to populate the “Translate From” (SourcePopupMenu) and “Translate To” (TargetPopupMenu) popup menus.

The Translate method creates the payload that gets sent to the Amazon Translate API, and sets special HTTP headers that are needed in order to call the API. But most importantly, it uses the CURLSMBS class’s “SetupAWS” method to configure the CURL instance so that all of the steps that are required to “sign” the API request are done automatically. This is an amazingly convenient function of the MBS Xojo CURL Plugin. You can get a sense of what’s involved in signing the request here.

To translate text using the AWSTranslator class, you create an instance, configure it with your IAM credentials and AWS region, pass it the source language text, the source language code, and the target language code. In the example app, this all handled in the Window1.Translate method. The values are pulled from the App-level properties, as well as the various window controls. Finally, you call the AWSTranslator instance’s Translate method. If the translation is successful, the translated text will be available via the TranslatedText property. If any errors occur, the ErrorType and ErrorMessage properties will be set.

The “Estimated Translation Cost” is calculated whenever the Source Text changes. The value is calculated by taking the length (number of characters) of the Source Text and multiplying it by 0.000015 (the average cost for translating a single character).

Wrapping Up

I’ve been amazed at the speed and accuracy of the Amazon Translate service. And after developing the AWSTranslator class, I was able to quickly and easily add language translation to my client’s middleware app.

I hope you’re equally impressed by the Amazon Translate service, and that you find the AWSTranslator class to be helpful in your own Xojo projects.

Tim Dietrich is a custom software developer based in Richmond, Virginia. To learn more, visit: https://timdietrich.me

“Developers adopting low-code platforms want dramatically higher productivity without sacrificing features that allow them to get under the hood if the application they’re building calls for it.”

That’s an understandable concern. Developers want the productivity they can get from low-code tools but they don’t want to give up the ability to call directly into the operating system when they need to. There are low-code platforms that don’t provide such access. Fortunately, Xojo isn’t amongst them. Our vision for Xojo has always been to make the tool easy to learn and highly productive to develop applications with, without sacrificing power when you need it.

In those rare cases when you need to use an OS capability for which the Xojo framework does not provide built-in support, there are three different ways to do so:

1. The Shell – Xojo’s Shell class makes it easy to issue OS commands and get back results.
2. Plugins – These are libraries (usually written in C or C++) that can include OS SDK calls.
3. Declares – These allow the developer to call individual OS calls from their code.

If you’re a developer using a traditional 3GL language and want to get the productivity benefit of low-code tools, take a look at Xojo as it gives you that without sacrificing low-level OS access.

For software, distribution usually means generating and validating unique serial numbers for each of your products and users. Serial numbers (or license keys) help you manage your users, unlock a free trial or demo version for full use and, of course, minimize illegal use of your apps.

Let’s admit it, there is no silver bullet. Even the greatest companies (you know who you are) throw lots of money at implementing and improving serious protection schemes that are often quickly bypassed.  It comes down to: How much time, money and resources are you willing to spend implementing a protection or licensing scheme?

The bad guys will always find a way to break your software protection if they are interested in doing that. Does that mean giving up on protecting your software? Not at all! When I was faced with the problem myself, in order to protect my own products, I went to the drawing board to build a way to generate unique serial numbers —or licensing information— for all the Xojo supported platforms.

The result of this process was the GuancheMOS plug-in. GuancheMOS is a fully multiplatform plug-in for desktop, web and console apps (not for iOS due to the fact that iOS only can link against static libraries), on 32-bit and 64-bit architectures.

The simplicity of GuancheMOS means that you can use it as is, or as the starting point to build your own private and unique serial number automations. Integrate it as part of the purchase process in your website, wrap it as the core piece of other unique information collection. It’s already used by dozens of developers around the world in ways I hadn’t ever thought of while designing it! The best part, is that implementing GuancheMOS in your product takes about 5 minutes.

You can download and try GuancheMOS for free today.

Javier Rodri­guez has been the Xojo Spanish Evangelist since 2008, he’s also a Developer, Consultant and Trainer who has be using Xojo since 1998. He manages AprendeXojo.com and is the developer behind the GuancheMOS plug-in for Xojo Developers, Markdown Parser for Xojo, HTMLColorizer for Xojo and the Snippery app, among others

64-bit support, for example, has been a major focus and continues to be. At one time, 64-bit was a nice-to-have. Then it became important and now it’s critical. There are Linux distributions that no longer provide 32-bit support. iOS now requires apps to be compiled to 64-bit in order to be in the App Store. You might have noticed that the 2017r2 cycle was longer than usual. This was due to the fact that we were doing some major refactoring of how strings are handled under 64-bit. Some of the string functions you depend on were not always behaving themselves and were much slower than they were in 32-bit applications. That refactoring took twice as long as we’d originally planned. That’s just the way things go sometimes. Even companies such as Microsoft and Apple have announced features that were later delayed. We’ve all been there.

We are also working to provide a 64-bit version of the Xojo IDE. This is important for those you of with large projects because the current 32-bit IDE can only address so much memory. Once your project gets big enough, the IDE can run out of memory even though your computer has plenty to spare. We need this ourselves because the Xojo IDE is written in Xojo and as you can probably imagine, is a very big project. 64-bit applications can address all of the memory your computer (or any future computer you own) will ever have. A 64-bit version of the IDE will permanently resolve this issue.

Sometimes the platform vendors make changes that require us to rearrange things a bit in the short term. For example, our first 64-bit platform was going to be Linux until Apple announced the 64-bit requirement for iOS apps to be in the iOS App Store far earlier than expected. Recently, Apple made it clear that under iOS 11 the Xcode 9 version of the iOS Simulator would not support 32-bit apps or debugging. We had originally planned to support 64-bit iOS Simulator debugging in 2018. Instead we are working hard and fast on that right now.

As a result of all this, some of our plans have been pushed out a bit. We had originally aimed to have Android, interops and plugins made with Xojo available for beta testing by the end of this calendar year. Now that’s not going to happen. We are still working quite hard on all these things (and more) but the 64-bit work has just waylaid us a bit. It is our intention, barring any additional unforeseen circumstances, to ship these features in the first half of 2018.

Fortunately, not all things have been delayed. We are working on a big update to the Windows framework that will dramatically reduce the flicker you sometimes see. This will not just improve the user experience of your apps but the Windows version of the Xojo IDE as well. Those of you that deploy to Windows or use Xojo itself on Windows will be quite pleased. I’m confident we will have these improvements available by year end.

If you want to help us with testing 64-bit Xojo or the updated Windows framework this year, please join our Pre-Release Testing Program.

For those of you that have been participating in pre-release testing, thank you so much. You are providing a valuable service to us and the Xojo community at large.