GitHub – Xojo Programming Blog

Year of Code 2025: October Project – Multi-Platform Communication

Gabriel Ludosanu — Mon, 13 Oct 2025 19:01:53 +0000

For October’s Xojo Year of Code 2025, I built MPACSocket, a tiny, reusable UDPSocket subclass that enables zero-config, local-network presence and chat across platforms. It wraps binding, broadcast, presence beacons, peer tracking, and JSON parsing into a single class with a clean event-based API. Drop it into Desktop projects and you’ve got instant LAN discovery and messaging.

What this project includes

A self-contained UDPSocket subclass (MPACSocket) that handles bind, presence broadcasting, peer pruning, and chat envelopes with versioned JSON (good for further updates to the protocol).
Simple API: Start(port), Stop(), Rename(name), SendChat(text). Everything else comes through events like Bound, ChatReceived, PeerOnline/PeerOffline, PeerUpdated, StatusChanged, and SocketError.
A sample DesktopWindow (wndMPAC) that wires MPACSocket to a transcript area and peers list.

How to use

Add MPACSocket to your project, drop it onto a DesktopWindow or instantiate in code.
Set DisplayName, call Start(62636), and listen to events to update your UI or console output.
Use SendChat to broadcast a message; presence beacons and peer tracking happen automatically.

Download

You can download the entire Xojo project from GitHub

This project shows how a small, well-scoped class can turn low-level UDP into a friendly, cross-platform building block. Feel free to adapt the events or JSON schema for your own protocols.

Gabriel is a digital marketing enthusiast who loves coding with Xojo to create cool software tools for any platform. He is always eager to learn and share new ideas!

Year of Code Project

How to Play:

Each month we’ll announce a new theme and share an example project of our own. Share your projects to the Xojo Forum thread for that month via GitHub (all the links you need are posted above ↑ ). Learn how to use Xojo and GitHub.

The Prizes:

Monthly winners get $100 at the Xojo store. Every month you submit a project is another chance to win the grand prize. The grand prize is $250 cash plus a Xojo Pro license and a year of GraffitiSuite and will be announce in December. Learn more about the prizes.

Year of Code 2025: September Project, Games

Paul Lefebvre — Mon, 08 Sep 2025 17:57:38 +0000

I’m a bit of a retro computing and gaming guy and I enjoy making versions of retro games using Xojo. Although Xojo is not really designed for making games, its Canvas class works well for many kinds of simple games. That means our theme for the Year of Code for September is Games!

One of the first games I made using Xojo was a clone of Atari Tank (based on the version included with the Combat Atari 2600 cartridge).

The core of Tank served as the basis for the XojoWars game contest, where it was re-imagined as a space battle.

Tank is a rather simple game and really needs to be two-players, which is why I added the ability for two people to play it over the network using UDPSocket. This version, which I called NetTank, is available on GitLab.

On the mobile side, I’ve made a 2048 sliding-tiles game and Turtle, which I suppose is kind of an infinite version of Frogger.

However, I’ve had the most fun making clones of Asteroids and Space Invaders. I wrote some about Invaders in xDev Magazine last year, but at some point I’ll get it enhanced enough to share in a blog post.

With that lengthy pre-amble I can now share my game for this month’s project, which is a clone of Asteroids that I uncreatively call Space Rocks. Although an older version of this game has been included with the Xojo examples for several years, this is an updated version with some new features:

Smaller ship to better match proportions of the rocks.
Improved ‘heartbeat’ sound.
High Score is saved and restored.
Level increases as you clear all the rocks, which adds even more rocks that also move faster.
Command or Shift key now work for firing missiles.

Yes, 14340 is my high score. So far. I dare you to beat it!

The full project is on GitHub: https://github.com/paullefebvre/SpaceRocks

Keep in mind that you don’t have to make an arcade-style game. Strategy and turn-based games are a lot of fun and also great candidates for Xojo. For reference, take a look at the web-based Cosmic Trader game that Ricardo made last year. A platform-style or maze game might also be interesting. I can’t wait to see (and play) what you make!

Paul learned to program in BASIC at age 13 and has programmed in more languages than he remembers, with Xojo being an obvious favorite. When not working on Xojo, you can find him talking about retrocomputing at Goto 10 and on Mastodon @lefebvre@hachyderm.io.

Year of Code Project

How to Play:

The Prizes:

Year of Code 2025: August Project, Console Apps

Gabriel Ludosanu — Thu, 07 Aug 2025 13:30:00 +0000

Welcome back to the Year of Code 2025 series! For August, I built a minimalist and fun Console Task App that allows users to add, remove, and list tasks interactively in the terminal. No graphical interface, just pure console magic that demonstrates the power of Xojo for CLI apps.

What this project includes:

Interactive command-line interface to manage tasks
Commands to add new tasks, mark tasks complete, list all tasks, and remove tasks
Simple file saving/loading to keep your tasks persistent between sessions
Clean and modular code architecture for easy customization or extension

This project highlights how Xojo can be used beyond GUI applications, making it ideal for automation scripts, tooling, or quick utilities you want to run directly in the console (Mac, any Linux flavor, Windows) without the overhead of a full UI.

You can check out the full source code and try it out yourself at GitHub: Xojo-Console-Tasks.

Give it a spin, modify it to suit your needs, and share your enhancements or questions with the Xojo community. This is a great way to get comfortable with console application design in Xojo and to stretch your coding skills in a new context.

Stay tuned for next month’s project as we continue our journey deep into the many facets of coding with Xojo!

Year of Code Project

How to Play:

The Prizes:

Gabriel is a digital marketing enthusiast who loves coding with Xojo to create cool software tools for any platform. He is always eager to learn and share new ideas!

Year of Code 2025: June Project, Cross-Platform Code Class

Gabriel Ludosanu — Tue, 10 Jun 2025 18:00:00 +0000

June’s Year of Code theme is about writing code that works in any type of Xojo project. To demonstrate Xojo’s powerful multi-platform capabilities, this month I’m sharing a practical example: a single data loader and search class you can use—without modification—on Linux, Mac, Windows, Web, Console, iOS, Android or Raspberry Pi!

Introducing `dataClass`: Universal Data Fetching for Xojo

Do you ever wish you could just grab some remote JSON data, search through it, and use it in your app, no matter what kind of project you’re building? That’s exactly what this little, pure-Xojo dataClass allows!

Here’s what it does:

Loads a list of posts from a web API (using standard URLConnection and Xojo’s built-in JSONItem).
Lets you search by any term within the post’s title or body – case-insensitive.
Works unchanged in all Xojo project types – all of them!

Why is This Cool?

By using only built-in classes and avoiding platform-specific quirks, you can build business logic and utility classes that drop straight into your app, whatever the deployment target.

The Complete Source Code

You can copy the full dataClass source from this GitHub repository.

What Will You Build?

Have a favorite cross-platform Xojo technique, class or code module? Show us your own! Share in this month’s Year of Code forum thread.

Stay tuned for more Year of Code 2025 examples, and happy coding!

Gabriel is a digital marketing enthusiast who loves coding with Xojo to create cool software tools for any platform. He is always eager to learn and share new ideas!

Year of Code Project

How to Play:

The Prizes:

Year of Code 2025: May Project, Mobile Apps

Paul Lefebvre — Wed, 07 May 2025 16:00:00 +0000

One of the most common things I love to use my phone for is sharing pictures of my pets with others. We have two cats and a dog: Shawmut, Christofur and Lucy. To be honest, I’m not much a cat person as I find that cats are almost all Richards, constantly causing and getting into trouble. I’m 100% a dog person.

But even though I have my own pets, I do love looking at pet pictures. It’s a simple pleasure, but there’s not much that I find more calming.

Years ago I made a Xojo app (CatsUp) that displayed random cat pictures and it was a lot of fun. And one thing that Xojo excels at is making it fun to create software! That’s what the Year of Code is all about, after all.

Speaking of that, here is the Year of Code topic for May: Mobile Apps.

You can already find CatsUp for iOS and Android included in the Xojo examples, but why stop at just cats? Being a dog guy, I want to see some dogs. All the dogs.

Since I’m not here to start a cats vs. dogs war, I thought, why not both? It turns out I’m not the only one that thinks this as there are actually public web services that serve up pictures of cats and dogs. Web services and mobile apps go together like peanuts butter and chocolate.

The web service for cats that I’ve previously used is called TheCatAPI and is available here: https://thecatapi.com

There is an equivalent dog one called, unsurprisingly, TheDogAPI: https://www.thedogapi.com

For my mobile app this month, I’ve created an all-new app that can show pictures of cats, dogs or both! I call it Pawz.

Pawz app icon

Actually, it’s two apps since I made versions for iOS and Android. Here’s a look:

Pawz on iOS

Pawz on Android

Although they are separate projects, both use basically the same code. In fact there is only about 50 lines of code in each project! The UI itself is just a big ImageViewer that is used to show the picture and several toolbar buttons.

There are three buttons to request a cat picture, dog picture or a surprise picture that could be either. There is also an extra button that lets you share the picture, if you really like it.

You can find the source for the iOS and Android versions of Pawz on GitHub here:

https://github.com/paullefebvre/pawz

Year of Code is all about having some fun making an app. As you can see with Pawz, it doesn’t have to be anything extravagant. Even fun apps can be made quickly with very little code!

I can’t wait to see what great mobile apps you all create this month. Share your creations in the Forum topic.

One More Thing

Although phones and tablets are what we usually think of when talking about Mobile Apps, you know what else is rather mobile? A vehicle! And it just so happens that many vehicle manufacturers, such as Cadillac, Chevy, Ford, Honda, Polestar, Renault and Volvo are now using Android to run their infotainment systems. Technically it’s Android Automotive OS (AAOS), but it is very similar to regular Android.

Because Xojo builds standard Android Runtime (ART) apps, Xojo Android apps also work on Android Automotive OS as a “parked app”. You can test with this by using Android Studio to install an Android Automotive VM for the Emulator. Once you’ve added that you can run your Xojo Android projects on it just like any other device. Pawz works fine in an AAOS Emulator.

Why do I bring this up? No reason, although I believe Xojo 2025 Release 2 pre-release testing might be starting soon…

Year of Code Project

How to Play:

The Prizes:

Year of Code 2025: April Project, User Interface

Gabriel Ludosanu — Tue, 08 Apr 2025 15:30:00 +0000

April’s Year of Code theme is all about a great User Interface, I decided to focus on refining the user experience of an existing application. My project involves a user interface revamp of the familiar built-in ToDo desktop app example provided with Xojo.

The goal wasn’t to add new features but to explore how applying thoughtful UI design principles can significantly enhance the look and feel of an application, making it more visually appealing and cohesive.

Here are some of the key aspects of the UI revamp:

Design System Foundation: I started by establishing a basic design system. This involved defining core visual elements to ensure consistency across the entire application interface.
Typography Definition: Specific styles were defined for how titles and standard text should appear. This helps create a clear visual hierarchy and improves readability.
Consistent Color Palette: A specific set of colors (Light & Dark mode) was chosen and implemented throughout the project, contributing to a unified and more polished look.
Refined ListBox Appearance: The standard DesktopListBox control received some visual tweaks to better align with the overall updated aesthetic.

The aim was to demonstrate how focusing on UI details can elevate even a simple example application.

Here’s a glimpse of the revamped ToDo app:

You can find the complete source code for this UI-enhanced ToDo app project on GitHub.

Stay tuned for more exciting projects as we continue our Year of Code 2025 journey!

Gabriel is a digital marketing enthusiast who loves coding with Xojo to create cool software tools for any platform. He is always eager to learn and share new ideas!

Year of Code Project

How to Play:

The Prizes:

Year of Code 2025: March Project, Web Apps

Gabriel Ludosanu — Wed, 05 Mar 2025 15:04:00 +0000

March’s topic is Web Apps and I’m excited to introduce my project: Quiziverse, a complete quiz and trivia web application.

Quiziverse is designed to engage users with time-limited questions across various categories, making it a fun and interactive way to test knowledge. The application leverages a SQLite database as the backend for all data storage.

Here are some of the key features of Quiziverse:

Admin Area: The app includes a secure admin area, allowing administrators to manage categories and questions easily. Admins can add, edit, or delete questions and categories to keep the trivia fresh and exciting.
Scoreboard: A dynamic scoreboard keeps track of player scores in real-time, fostering a competitive spirit among users. Players can see how they stack up against others, adding an element of fun to the experience.
Time-Limited Questions: Each question comes with a timer, challenging players to think quickly and answer before time runs out. This feature adds to the intensity of the game and keeps players on their toes.
Import JSON Files: To make it easy for admins to add new content, Quiziverse includes a function to import JSON files containing new categories and questions. This feature simplifies content management and allows for quick updates.
Mobile Optimized Design: Understanding the importance of accessibility, Quiziverse is designed to be mobile-friendly. Players can join the trivia challenge from their smartphones or tablets for a seamless experience.

Here’s a sneak peek of the Quiziverse interface:

You can find the complete source code for Quiziverse on GitHub, along with detailed documentation to help you get started.

Stay tuned for more exciting projects as we continue our Year of Code 2025 journey!

Gabriel is a digital marketing enthusiast who loves coding with Xojo to create cool software tools for any platform. He is always eager to learn and share new ideas!

Year of Code Project

How to Play:

The Prizes:

Build a Xojo Plugin with GitHub Actions

Jürg Otter — Tue, 25 Feb 2025 22:30:00 +0000

As part of Xojo’s 2025 Year of Code initiative, February’s theme is databases—a perfect fit for my recent work on the Open Source CubeSQLPlugin. This article shares insights into automating its build process with GitHub Actions Workflows.

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.

Year of Code 2025: February Project, Database Apps

Paul Lefebvre — Tue, 11 Feb 2025 16:48:26 +0000

February’s Year of Code 2025 topic is Databases and my project is a SQLite object-relation mapping library that I call Storm.

I first created Storm in 2008 when I was working on consulting projects as a way to more rapidly create database apps for clients. It has been updated over the years and the latest version is available on GitHub:

Storm

An ORM lets you write code like this to set database column values and save them:

Var dodgers As New Team
dodgers.Name = "LA Dodgers"
dodgers.Coach = "Dave Roberts"
dodgers.Save

Team is a table in the database with a corresponding class in Xojo that inherits from Storm.DBObject.

The included demo projects shows how you can implement a simple UI for a database with Team and Player tables.

The docs for Storm are contained within its Github repository wiki.

In addition to accessing the full repository on GitHub, you can also download Storm as a ZIP.

I’ve created a forum topic for you to start sharing your Year of Code projects and I’ll also be sure to include this one as well. Remember, participants can win a $100 to use in the Xojo Store!

Year of Code Project

How to Play:

The Prizes:

Year of Code 2025: January Project, Desktop Apps

Paul Lefebvre — Wed, 15 Jan 2025 19:26:16 +0000

January’s Year of Code 2025 topic is Desktop apps and my project is XojoText.

XojoText is a simple text editor that lets you edit multiple files in one window with a list of files in the left sidebar. You can create new blank documents, documents from a selection in another document or from the clipboard.

It is based on the XojoText example that is included with Xojo, but enhanced in these ways:

Word, character, line counts shown at bottom of editing area.
Recent Items menu.
Window menu.
Saves window position.
Prompts to sae changes.
Contextual menu on files in the sidebar.
Click “x” to close files in the sidebar.

Suggestions for improvements and things to add:

Find/Replace capability.
Printing.
PDF generation.

I’ve created a forum topic for you to start sharing your Year of Code projects and I’ll also be sure to include this one as well.

You can download the XojoText project from GitHub here: https://github.com/paullefebvre/XojoText

Year of Code Project

How to Play:

The Prizes:

Year of Code 2025: Kickoff

Paul Lefebvre — Thu, 09 Jan 2025 16:30:00 +0000

Xojo is kicking off 2025 with something for everyone in the Xojo community, an event that will help new users grow their Xojo coding skills and existing users polish theirs. Back in 2018, we did a “Summer of Code” contest that challenged people to create one project a week through the summer. This was a lot of fun and many interesting apps were made that summer. For 2025, we have expanded that idea out to the entire year! However, instead of one app a week, we will make one app a month from January to November 2025. In December we will give away a grand prize!

The Idea

Early each month we will share a blog post that introduces an app “theme” and recaps the prior month. A week or so later, we will create a Forum topic and post an example project created by one of the Xojo team. To participate in the Year of Code, make a Xojo project that that demonstrates the theme in some way, share it on GitHub to make it easily accessible to everyone and then add a post about it (with your GitHub link) to the Forum topic.

If you have not used GitHub before, here is a blog post on how to share a Xojo project on GitHub.

Ideally, these will be small, focused apps that can be made in a few days. The idea is to have fun creating something that others might learn from. But I guarantee you’ll learn something as well. After all, the best way to get better at coding is to always be coding.

How To Participate

Each month Xojo will announce a new theme and share an example project. Share your own projects in the Xojo Forum thread for that month via GitHub, preferably. Projects with code shared at other sites can be eligible as long as the code is accessible to everyone. Learn how to use Xojo and GitHub.

The Prizes

And yes, there will be prizes for those that participate. Each month all participants (everyone who shares a project that month) will be entered for a chance to win a monthly prize of $100 at the Xojo Store plus a 25% off coupon for GraffitiSuite.¹ The $100 can be applied to any Xojo license purchase or Extras Store item. At the end of 2025, all participants from the year will be entered to win the grand prize of a Xojo Pro license, $250 cash and a free year of GraffitiSuite. The more months in which you participate throughout the year, the more chances you’ll have to win the grand prize.

January’s Theme

Now that it is January (Happy New Year, everyone), the 2025 Year of Code kicks off with this theme: Desktop apps. People have used Xojo to make wonderful desktop apps since its inception in 1998 so this is an ideal first theme that is broad enough to allow anyone to participate. Look for a post next week announcing this months’ project details. Once it is posted, I will start a forum topic for others to share GitHub links to their projects and apps. In early February we will do a blog post that highlights what people made this month and introduce February’s theme.

I hope you will join us for the 2025 Year of Code and I look forward to seeing what you make with Xojo!

#2025YearOfCode

Monthly winners are excluded from future monthly prizes but each monthly participant earns an additional entry into the grand prize drawing. ︎

Year of Code Project

How to Play:

The Prizes:

Using Xojo and GitHub

Paul Lefebvre — Tue, 02 Apr 2024 17:26:24 +0000

Now that Xojo Lite includes support for saving projects in version control format, it seems like a good time to revisit how you can use Xojo with GitHub, the popular online Git hosting service.

What are Git and GitHub?

Git is an open-source version control system, also known as a source control system. Created by Linus Torvalds in 2005, it is now the most popular version control system, supplanting Subversion a while ago.

GitHub is an online Git hosting service, now owned by Microsoft. GitHub provides additional features beyond just Git hosting, but for this post we will focus on its Git hosting. GitHub is free to use for both public and private repositories.

A repository is essentially a place to store a project. Public repositories are great ways to share open-source projects. Others can view and download the source code. Private repositories are only visible to you and are great for your own internal projects.

Git is a distributed version control system, which just means that the source code can be versioned locally and on the server, only synchronizing when necessary. For simplicity it is common to keep both in sync, however. Older version control systems such as Subversion were server-based and versions were only ever kept on the server. A distributed version control system is slightly more complex, but it does have the advantage of making it easier to work offline.

A version control system tracks changes made to text files, something that is incredibly useful when it comes to source code. Tracking changes is a very common task that is needed while programming. You may have seen people save their projects as MyProject1, MyProject2, MyProjectNewVersion, etc. That is a rudimentary way of trying to ensure you don’t lose changes as you update your code. With version control and the Xojo version control project file format you get a much more flexible technique.

When you save your project using the Xojo version control project file format (called Xojo Project) in the file selector, each project item is saved as its own file on the drive. And each of these files is plain text — you could view them using a text editor if you wanted.

You might be thinking: “I’m just a single developer, I don’t need this extra complexity.” But version control systems are not just for multi-person teams. Sure, version control is a great way to make sure that different team members don’t make different changes to the same code. But version tracking is useful to everyone. Even as a single developer, being able to review previous changes, and revert changes if they don’t work out can be a lifesaver. It removes any “fear of breaking things” from your workflow. Plus, having your source code on a remote server (GitHub) can also function as one of your source code backups.

A Quick Example

To give you an example of how this works, consider a single text file that exists in Git: ReadMe.txt

Initially it contains just this text:

Hello!

You pull down the file to your computer (I’ll define Git terms like these below) to work on it. Opening the file in a text editor, you change its text to this and save:

Hello, Xojo!

Now the file on your computer contains that text. This is called the working copy. The file in the repository still has the text “Hello!”. Now you can do a couple useful things.

You can ask to see the differences between the file in the repository and the one in the working copy. When doing so, most tools will highlight the line that changed, showing the repository contents on the left and the working copy contents on the right. This is a wonderful way to review changes made to code.

The other thing you can do is commit the change to the repository. This adds this file to the repository and makes it the latest version. In Git you’ll then be able to see that this file has two versions and you’ll be able to see what the file looked like for each version.

These two things mean that you will never again lose any work. Anytime you make a change to your code that you want to save as a version in the repository, you commit it. You don’t want to commit after every change as that is too granular and will be hard to manage, but it means you can safely make a bunch of big changes to something and still be able to go back and review what the code looked like previously.

The other useful thing you can do is revert changes. If, after saving the file with “Hello, Xojo!” you realize that was a mistake, you can go back to the previous version by choosing to revert the file. This discards the local working copy and pulls down the most recent revision from the repository.

I realize that this might all seem rather different and confusing, but once you do this on a couple small projects you’ll get the hang of it and you will never want to go back to using MyProject1, MyProject2 again!

Terminology

Repository: This is essentially a place to store a group of files, which for our purposes will be a Xojo project saved in the version control file format (Xojo Project).

Clone: Copies the repository to your computer so you can work on it

Fetch: Updates the local repository with any changes that are stored on the server

Pull: Similar to fetch, except that it also copies the changes into the working copy

Commit: Add the changed file to the repository as a new version

Push: Pushes the committed file to the server (GitHub). Often this is done as a single step: Commit and Push.

Working Copy: Your local copy of the repository and the file

General GitHub Usage

With Xojo, the general workflow you will use is:

Create repository on GitHub for the project.
Pull it down to a folder on your computer.
Create a Xojo project.
Save it in Xojo Project (text) format into the above folder.
Commit and Push it to GitHub.
Make additional changes to the Xojo project.
Commit and Push to GitHub as necessary.

Create a GitHub Account

If you don’t already have a GitHub account, you’ll need to create one. Head on over to the sign up page to start the process:

Create a Repository

Now that you have a GitHub account, you’ll want to go to your GitHub home page and click the “New Repository” button.

As mentioned above, a repository is essentially where your project is stored. You’ll typically want a separate repository for each project. This is what the new repository form looks like:

For open-source projects you’ll want to make sure “Public” is selected as it’s not really open-source if it is not public. For a public repository, be sure to come up with a catchy “repository name” and always include a description. Choose “Private” for internal projects.

I always check “Add a README file”, which adds an empty README file to the repository. You can update it later, but it is where you’ll briefly describe the project and how to use it (using Markdown). The README is shown by default when you go to the repository in a web browser.

You should also select “Xojo” for the gitignore template (click the dropdown and type “xojo”). This identifies the project as using the Xojo programming language, which helps with searches and also marks the “uistate” file (which contains user-specific UI settings, such as window sizes and positions) so that it is not included in the project.

Last is the license. For most public open-source projects, I recommend the MIT License, which essentially allows anyone to use your code however they want. For private projects, you can leave it at “None”.

Click the Create Repository button to create the repository.

Clone the Repository to your Computer

With the repository created, you can view it on the GitHub website for you account:

From here you’ll be able to see the files in the repository, along with other information.

You are now ready to “clone” the repository to your computer. This copies the repository files to a folder on your computer so you can modify its files. Of course, the only files in the repository will be LICENSE and the empty README.md, but it is still necessary to do the clone so that you can create the folder where you will then add your Xojo code.

In order to clone, you’ll want to use a Git client application. There are many to choose from, but two free ones are the official GitHub Desktop and Atlassian SourceTree. GitHub Desktop is simpler so that is the one I’ll show here.

Download GitHub Desktop: https://desktop.github.com

Start GitHub Desktop and click “Sign into GitHub.com”.

On the Configure Git page, enter the name and email you want to use to identify your commits.

Click Finish on the next page to show the main screen where you have the option of creating new repositories or cloning a repository. Since we already created a repository online in the previous section, you want to select “Clone a Repository” (you can also choose this from the File menu). In the list, choose the repository you created above, choose your local folder location (Choose…) and click Clone.

You now have a folder on your disk where you can add your Xojo project. This is what the repository looks like in GitHub Desktop:

Note: If you are using another Git client, you will choose its “clone a repository from URL” feature and then provide the URL shown in the “Clone or Download” button on the repository page.

Add Your Xojo Project Code

Start Xojo and open the project you want for the repository you cloned (or you can just create a new project). Click “Save As”, make sure the Format is “Xojo Project” and choose the folder you created when you cloned the repository.

Go back to GitHub Desktop and you’ll now see all the Xojo files appearing in the list as “changed files”. (For this test I used a Xojo SQLiteExample.)

You now need to “Commit” these changes. By default they are all selected/checked in GitHub Desktop so you can enter a brief summary and description (for the first commit, often “Initial commit.” is used, but I used “Initial Xojo commit.”) and then click the “Commit to main” button.

Each time you commit you want to be sure to type a clear summary and description of the changes. This will be helpful later when you are reviewing prior commits.

This marked the files as committed in your local repository, which is needed before you can push the changes up to the online repository. Generally speaking you want to commit things after you have made changes that you want to track. You don’t need to immediately push the changes up to the server (online repository) each time, however, people often do as it is simpler. Some Git clients even offer a single button or command to commit and push in one step.

For this initial commit you definitely want to push the commit to the server, so click the button in the toolbar that says “Push origin”. This pushes the commit to the origin, which is the GitHub repository in this case.

If you now go back to the GitHub repository online and refresh the page you’ll now see the files have been committed:

Sharing Your Public Project

If you created a public repository then it is now available on GitHub for anyone to use. People can find it by searching or you can share the URL (perhaps in the Xojo Forum).

Since I published a public project, anyone can use it. This means that they can clone it and push changes to your project as “pull requests”. A pull request is a change that a user has made that they would also like you to apply to your project. Since this is your project, others cannot directly change it without you adding them as contributors. However, you can review these pull requests and choose to pull and merge the change into your project if you want. Or you can reject the pull request — it’s all up to you since it’s your project.

Changing and Updating Your Project

You’ll likely be continuing to change your project to fix bugs and add features. Each change you make shows up in GitHub Desktop where you can commit it and then push it to the server.

As an example, go back to Xojo and make a change to the project. I added some comments to the AddTeamRow method. After saving, the changes are now visible in GitHub Desktop:

You can see the one file that was changed, SQLiteWindow, and the changes (or diff) is shown in the viewer. Here you can see the changes by the blue highlighted lines in the gutter. The first change indicates that line 386 was removed and replaced, with the change noting that “Please” was added.

The next two changes indicate that new lines were added to the code.

It’s always good to review code like this before you commit it to make sure the changes are what you expect.

You can now Commit this change (always add Summary and Description text so you know the reason for the change!) and then Push it to the server (Push origin).

Discarding Changes

Say you’ve made changes to your Xojo project, but realize you’ve really messed things up and want to go back to the way the code was. For example, say I’ve accidentally deleted a bunch of code in the ShowData method and saved the project. In GitHub Desktop, it would look like this:

You can see the big red area indicating the code that was removed.

To discard this change, I can right-click on SQLiteWindow in GitHub Desktop and select Discard Changes. This pops up a confirmation dialog and clicking Discard Changes will restore the file to its previous version, which is the version of the file that was last committed to the repository.

After doing this, you will need to close the project in Xojo and then re-open it so that it can refresh its internal project structures to reflect the discarded changes. After doing that, you can go back to the ShowData method to see that the code is restored.

This capability is a big reason why version control is also incredibly useful for solo developers.

Using or Cloning Other Repositories

Don’t forget that you can also use other people’s public repositories. To do so you’ll want to click the “Clone or Download” button on the repository page.

For simple usage, where you just want to grab the current version of the repository because you don’t intend to change anything, you can then click the Download ZIP button. Once downloaded, unzip the file and then open the project in Xojo where you can use it or copy/paste it into your own projects (review the license agreement before you use projects, of course).

You’ll want to clone a project when you want to manage it using GitHub Desktop (or your GitHub client of choice). This allows you to fetch/pull updates from the online repository and also allows you to make your own changes and push them up to the server where the repository owner will get them as pull requests, as described above.

Change Your Default Project Format

You might find it worthwhile to change your default project format to be the version control format. This way it will always be selected by default when you save. You can change this in Xojo’s General Settings:

Pro Tip: When saving a project for the first time in version control format, it is always a good idea to save into a newly created folder. This ensures that all your files will be neatly contained in one place and won’t accidentally override something else that may have been in the folder.

Git Going

If you’ve created Xojo projects in public repositories on GitHub, be sure to share them in the forum!

This post just scratches the surface of what GitHub does and also only touches lightly on Git and the concept of source control in general. If you’d like to use Git for source control, but would prefer an alternative to GitHub you might also want to check out Atlassian BitBucket which also offers free Git hosting for both private and public repositories.

Free Xojo Linux and Raspberry Pi for Everyone

Xojo — Tue, 26 Mar 2024 15:26:18 +0000

Beginning with Xojo 2024r1 you can use Xojo’s free IDE to build Linux desktop and console apps from Linux, macOS, or Windows, no license required.

Xojo Linux is Free

We have made building for Linux free and included in the Xojo IDE! This means that on Linux you get a version control ready IDE, along with the ability to build desktop and console Linux apps (including Raspberry Pi), all for free. Launch Xojo 2024r1 (or any later release of Xojo) and open any desktop or console project, go to Build Settings, select Linux and in the Inspector choose the appropriate Architecture that matches the Linux OS you want your app to work on, either ARM or x86. Click Build to compile your project to a standalone app that you can then run on Linux – no license required.

Wrapping Up

All these changes were made based on feedback from the Xojo community and to better match the changing ways that people develop and share software projects. With this change Xojo continues its dedication to supporting Linux.

Download Xojo to get started.

Edited 07/2025 to reflect changes to licensing.

Xojo for Students

Xojo — Thu, 25 Jan 2024 13:00:00 +0000

Xojo is a programming language and development environment for creating cross-platform applications for macOS, Windows and Linux from whatever computer you use – Mac, Windows or Linux. You can also create web, iOS, Android and Raspberry Pi apps with Xojo. To empower students, Xojo has partnered with GitHub to offer Xojo Pro to all students in the GitHub Student Developer Pack. In addition to Xojo, the Pack includes tons of free tools to help students expand their technical knowledge and learn new skills.

Students looking to begin their journey into programming choose Xojo for its ease of use and dedication to cross-platform development. Plus, Xojo is true rapid app development and is ideal for building prototypes and mockups really fast. All of these features benefit from Xojo’s OOP-focus. Xojo also has an active and helpful community and years worth of free, on-line resources.

Ease of Use from App Design to Build

Xojo is known for its user-friendly and visual development environment. It employs a drag-and-drop interface, which can be helpful for students who are new to programming and those who want to rapidly prototype software without delving into complex coding. Xojo is efficient, featuring a streamlined development process and extensive feature set, you can create applications fast without sacrificing quality or functionality. Xojo is based on object-oriented programming principles. Learning OOP through Xojo can provide students with a solid foundation in programming concepts that are widely applicable in the software development industry.

Multiplatform Development for Windows, macOS, Linux, mobile, & web

Xojo is incredibly versatile. Whether you’re interested in desktop, mobile, or web application development, you can built it with Xojo. With its cross-platform capabilities, you can even build applications that run on multiple platforms from a single code-base. This can be particularly valuable for students working on a MacBook but needing app for a Windows machine or vice-versa. Write your app once and compile it for macOS, Windows and Linux.

Rapid Application Development for Prototypes and Mockups

Xojo is designed for rapid application development (RAD), making it an ideal choice for students who need to create functional applications quickly. Students can use Xojo to build practical, real-world applications. This hands-on experience can be valuable for learning and demonstrating software development skills, especially for those working on the design and usability aspects of software development.

Community and Resources

Xojo has an active community and offers resources, including documentation, tutorials, and forums. Students can benefit from this support when learning and troubleshooting. With an active and friendly community of developers, top-notch support team and extensive documentation and tutorials, you’ll always have the help and resources you need to succeed. Learn at your own pace, and have access to the support you need to overcome challenges along the way.

No matter why you choose Xojo, whether for its simplicity, cross-platform capabilities, rapid development or community and resources, Xojo is a valuable tool for learning programming and software development concepts. Xojo is a great place to start when building or looking to expand your development toolkit.

Download Xojo

Xojo GitHub Actions

Jürg Otter — Wed, 19 Oct 2022 12:30:00 +0000

Would you like to automate the build processes of Xojo built applications with GitHub Actions? With no user interaction the whole process can be performed: Build all Targets, CodeSign Windows executables, create and sign the installers, package the macOS app in a .dmg and notarize the app, and for Linux create a .tgz package.

What are GitHub Actions?

If you want to read all about it – head over to their documentation. To get started, you should at least know about the following terms:

Workflow

A workflow is a configurable automated process that will run one or more jobs. Workflows are defined by a YAML file checked in to your repository.

Job

A job is a set of steps in a workflow that execute on the same runner. Each step is either a shell script that will be executed, or an action that will be run.

Runner

A runner is a machine that runs your workflows when they’re triggered. GitHub provides ready to use runners as preconfigured virtual machines. And of course you can host your own runners.

A GitHub Actions workflow can be configured to be triggered when an event occurs in the repository. So how to leverage that? Let’s talk about the Git Branching strategy that I’m going to use in this example first.

Git Branching Strategy

Using GitHub obviously means the one is using Git as Source Control. There are quite a few common strategies and workflows to use Git. For this example I’ll be using the following:

Default Branch: main
I want to make sure that all code in the main branch can be compiled at all times. Every push (or Pull Request against the main branch) should automatically build a Beta Version of the app.
At some time I want to use the latest commit to build a final version of the application.
Feature branches: feature/xyz
To start working on a new feature or bug fix, I’ll create a feature branch. As I often commit I don’t want to build every single commit. There might be commits with “work in progress” which won’t even compile.
Once ready: I create a Pull Request against the main branch.
Pull Request (against main branch)
This means a feature or bug fix is ready. So a GitHub Action should kick in and build the app. If that fails it simply means the feature isn’t ready for the main branch. The built Beta Version can be downloaded to do some more manual tests before merging into the main branch.
Once the Pull Request is merged (always using a squash commit), this will result in a single commit to the main branch (of the whole new feature). Same procedure: a Beta of the app is automatically built and ready for to download and test.
Release a Final Build
After adding couple of new features and bug fixes I want to release a final version.
Whenever I feel ready, a GitHub Actions Workflow can be started manually. That will build a Final Version, create a Release in the GitHub Repository and upload all Builds to the Release as Assets.

A bit of information before starting to write the GitHub Actions Workflows:

About Workflows

Workflows are defined by a YAML file checked in to the repository in the .github/workflows directory.

YAML files

A word of precaution when writing and editing YAML files:

Indentation is done by spaces (not by tabs!)
Indentation has to be exact, or expect to get syntax errors

Xojo GitHub Actions Workflows

According to the Git Branching Strategy I want to build Beta Releases (on Pull Requests and on Push to the main branch), and I want to manually create a Release with a Final Build.

This means that there will be two Workflows:

Beta Build
Create Release

They have something in common. Both need to build the Xojo project and execute the postbuild steps. To avoid duplication I’m going to write a reusable workflow:

Xojo (Build and PostBuild)

A workflow (Beta Build | Create Release) that uses another workflow (Xojo Build and PostBuild) is referred to as a “caller” workflow. The reusable workflow is a “called” workflow.

This ScreenShot shows the Beta Build workflow which calls the reusable Xojo workflow:

The Create Release workflow looks similar during it’s run. It can be started manually on GitHub.

Once finished, a new Release is available in the GitHub repository:

The Set Up

There is quite a bit to do:

Set up a Build Mac
A Mac of our own is needed. The reason for that is that Xojo isn’t set up on GitHub’s virtual macOS machines (one would need to download and install it every single time). And even if it were, we would need to setup and register Xojo with a License. And Xojo Licenses take a seat on every machine – so no good idea for a fresh virtual machine on every build.
Create a Xojo IDE Communicator
Build Automation with Xojo requires to communicate with the Xojo IDE. I’m going to use the project that Xojo ships in the examples, but modify it a bit.
Configure the GitHub Repository Settings
There are settings to enforce the chosen Git Branching Strategy. And there are some settings for GitHub Actions that need to be set up.
Set up a self-hosted GitHub runner
Install the GitHub runner on the Build Mac and link it to the repository.
Xojo Project and Post Build Scripts
I’m going to add a PreBuild Xojo Script. And of course all Post Build Scripts regarding CodeSigning, Installer creation, packaging, Notarization.
GitHub Actions: Secrets
CodeSigning means certificates and passwords. They get their safe place in the repository Secrets.
GitHub Actions: Workflows
Once everything is in place… one can finally start writing the actual workflows.

As you can imagine, guiding you through all these steps is going to be quite a lengthy article.

Source Code & Documentation

Should you consider using GitHub Actions with your own Xojo projects, then have a look at this repository: GitHub: jo-tools/xojo-github-actions

It contains the full documentation, the source of the modified Xojo IDE Communicator, an Example Xojo Project – and of course all the GitHub Actions Workflows.

I hope this gives you a lot of helpful hints, ideas and approaches so that you get a head start to get your Xojo Projects built using GitHub Actions Workflows.

That’s all Folks!

I hope this brief introduction of how Build Automation for Xojo built Application can be used with GitHub Actions Workflows has been helpful to some, food for thought to others.

August is Bug Bash Month at Xojo

Dana Brown — Wed, 13 Jul 2022 13:46:21 +0000

We are excited to announce that during the entire month of August the majority of our engineering team will be focusing on a Bug Bash!

The Xojo MVPs give us regular feedback on issues affecting the community at large – sometimes that is about a new feature, early testing of a release or more general matters. Recently the MVPs emphasized to us that bugs that don’t affect a lot of users, but can be really annoying to a small group of users, don’t get much attention. We talked about how to best address some of these issues and since we haven’t done a Bug Bash in a while, we decided it was time to do one.

Nominating a Bug for the Bug Bash

Starting now, each user can nominate up to 10 bugs to be fixed during the Bug Bash. You don’t have to nominate them all at once, we will accept nominations through August 31st. To nominate a bug, post this exact language as a comment on the case(s) you wish to nominate in Issues: [BugBash2022Nominee]. Starting in August, our system will add a Bug Bash label to make it easy to find them.

If you find that a case is already nominated with the Bug Bash label, do not add it again. Per usual, if the case affects you, add a “thumbs up” so we have some idea of how many users are affected by a particular bug. Please note that Feature Requests will not be considered for the Bug Bash.

Not every case that is nominated will be fixed. There are a multitude of reasons for this, but each case nominated will be evaluated and we’ll let you know the outcome.

We hope you’ll participate in the Bug Bash. No case is too old, too small or too esoteric! Submit your nominations today!

Xojo Educational Licenses for Teachers

Alyssa Foley — Wed, 01 Sep 2021 18:12:20 +0000

Xojo is the the best kept secret of developers around the world and now we’re making it easier for teachers with the free Xojo Educational license. Xojo is an integrated development environment (IDE) and an object-oriented programming language and it makes an excellent introduction to programming. We’re offering this license to empower educators of all kinds, whether they teach in a traditional classrooms, adult education programs or clubs. Teach universal programming concepts that apply to Xojo and nearly all programming languages. Create a Xojo account using your .edu (or other) educational email address and reach out to request your free Xojo Educational license today!

Xojo is free to download and free for development and learning, for everyone. Teachers and students can download Xojo to as many computers as they want. Teachers can activate their license on 3 computers in order to build apps, while students can use the free Xojo IDE to develop, run and debug their projects. Whether you teach on Windows, Mac or Linux, the Xojo IDE is cross-platform so you can code on your platform of choice, and so can your students. If you are teaching Desktop development, your students can stretch their skills and use Xojo to learn to make Web, Mobile or Raspberry Pi apps. Xojo is all about making developing for different platforms and devices easier with one cross-platform, object-oriented language, in fact, that’s how Xojo got its name.

A Xojo Educational license makes apps for all supported platforms (Desktop, Web, Mobile, Console & RPi). Students can create native user interfaces quickly and intuitively with drag and drop from Xojo’s library of built-in controls. Xojo includes modern support for inheritance, interfaces, polymorphism, graphics, internet protocols and more. Xojo comes bundled with SQLite and works with databases like PostgreSQL, MySQL and Microsoft SQL Server. Free technical support via email is included with the Educational license and access to the Xojo Forum is free for everyone. Apps compiled with Xojo are native, stand-alone and yours forever.

The More You Know

Xojo documentation, example projects, tutorials, YouTube channel and Intro to Xojo Programming Textbook and Teacher’s Guide are all free.
Video: Success With Xojo In Improving Student Retention In Intro to Programming Classes, Dr Ed Lindoo, Regis University
Xojo Pi for building Raspberry Pi apps (Linux 32-bit ARM apps) is free.
Students can get Xojo and tons of other free programming tools in the GitHub Student Developer Pack.
Xojo is celebrating 25 years as a development tool and programming language in 2021!
Still not sure Xojo is right for your classroom? Email Xojo directly with any questions at hello@xojo.com.

GitHub – Xojo Programming Blog

Year of Code 2025: October Project – Multi-Platform Communication

What this project includes

How to use

Download

Year of Code 2025: September Project, Games

Year of Code 2025: August Project, Console Apps

What this project includes:

Year of Code 2025: June Project, Cross-Platform Code Class

Introducing dataClass: Universal Data Fetching for Xojo

Why is This Cool?

The Complete Source Code

What Will You Build?

Year of Code 2025: May Project, Mobile Apps

One More Thing

Year of Code 2025: April Project, User Interface

Year of Code 2025: March Project, Web Apps

Build a Xojo Plugin with GitHub Actions

Write a Xojo Plugin

Build a Xojo Plugin

Example: CubeSQLPlugin

Build for all Platforms and Architectures

macOS

Linux

Windows

How to Build your Xojo Plugin

How to Transition from Manual to Automated

A Fun Fact

That’s All Folks!

Year of Code 2025: February Project, Database Apps

Year of Code 2025: January Project, Desktop Apps

Year of Code 2025: Kickoff

The Idea

How To Participate

The Prizes

January’s Theme

Using Xojo and GitHub

What are Git and GitHub?

A Quick Example

Terminology

General GitHub Usage

Create a GitHub Account

Create a Repository

Clone the Repository to your Computer

Add Your Xojo Project Code

Sharing Your Public Project

Changing and Updating Your Project

Discarding Changes

Using or Cloning Other Repositories

Change Your Default Project Format

Git Going

Free Xojo Linux and Raspberry Pi for Everyone

Xojo Linux is Free

Wrapping Up

Xojo for Students

Ease of Use from App Design to Build

Multiplatform Development for Windows, macOS, Linux, mobile, & web

Rapid Application Development for Prototypes and Mockups

Community and Resources

Xojo GitHub Actions

What are GitHub Actions?

Workflow

Job

Runner

Git Branching Strategy

About Workflows

YAML files

Xojo GitHub Actions Workflows

The Set Up

Source Code & Documentation

That’s all Folks!

August is Bug Bash Month at Xojo

Nominating a Bug for the Bug Bash

Xojo Educational Licenses for Teachers

The More You Know

Introducing `dataClass`: Universal Data Fetching for Xojo