Performance: Beyond 13,000 Requests Per Second

If you have been following the web framework’s performance numbers over the releases, you know they have been steadily improving. In 2024r2, benchmarks were sitting at around 8-9k requests per second. In 2026r2, we are beyond 13k. That is a significant jump, and it comes from a fundamental change in how the framework handles connections under the hood.

Xojo Web is essentially a Console project built on top of ServerSocket and TCPSocket. Previously, each incoming connection would spawn a new Thread, process the request, and then that thread would be destroyed. In 2026r2, threads are created when the TCPSocket is created, before the connection even arrives. When a request comes in, the thread is already there, sleeping, waiting. No need to spin one up from scratch. And when a TCPSocket can be reused, so can its thread, meaning fewer kernel calls and less overhead overall.

That said, even with a 50% increase in this benchmark, most developers won’t notice a big difference. When the application has to deal with frequent database queries, for example, shaving a few milliseconds off request handling is a drop in the bucket. But where it does matter, it matters a lot. If your application is a plain REST API serving data for a mobile app with thousands of concurrent users, or when it is deployed to a constrained environment like a Raspberry Pi, this kind of improvement can make a real difference.

SEO Improvements Done Right

In 2026r1 we introduced the ability to call WebPage.Show from within the HandleURL event, which opened the door for serving pages to search engine crawlers. It worked, but it came with a significant cost: even for users who were not using this feature at all, benchmark numbers dropped from 7-8k requests per second down to 1-2k. That was not acceptable (pushing us to review the overall web framework performance on this release), and it also introduced edge cases for codebases that expected HandleURL to run without any session context active, because creating a session context on top of an existing one is not allowed.

In 2026r2, this is fixed properly. The performance penalty is gone for everyone. If you want to use WebPage.Show from HandleURL for SEO purposes, you now opt in explicitly by creating a WebSessionContext instance yourself, passing the requestparameter, before calling Show. It is a small step, but it makes the intent clear and keeps things safe for everyone else.

WebSessionContext has a new Constructor, accepting a request As WebRequest parameter.

We are not stopping here. SEO is important, and we are already working on a proper URL router to make these workflows easier and more capable. Stay tuned!

DatabaseConnection Gets a PerSession Mode

If you use a Database Connection in your web project, you are probably familiar with how they work: you add one to your project in the Navigator, give it a name, say MyDatabaseConnection, and then you reference it by that name anywhere in your code to run queries.

By default, that connection behaves like a singleton. Every session in your web app shares the same MyDatabaseConnectioninstance. For most read-only usage that is fine, but the moment you start using transactions, you can run into trouble. One session’s transaction can interfere with another’s, or worse, data from one session can leak into another’s results.

The new PerSession property in 2026r2 solves this at design time. When you enable it in the Inspector, MyDatabaseConnectionstops being a shared instance. Instead, each session gets its own connection, created lazily the first time that session needs it, and automatically destroyed when the session ends. Your code does not change, you still write MyDatabaseConnection.SelectSQL(...) as you always have, but now you can be confident each session is operating in complete isolation.

WebGraphics Gets DrawPath and FillPath

WebGraphics now supports DrawPath and FillPath, bringing it in line with what Desktop and Mobile targets have had for a while. If you have been writing custom drawing code for other targets using Graphics.DrawPath or Graphics.FillPath, that code can now be reused in your web projects without modification.

This is exactly the kind of cross-target parity that makes Xojo powerful. Check the WebGraphics documentation for the full details on how paths work.

WebImageViewer: Goodbye, Flicker

A small but welcome fix. When updating the Picture property on a WebImageViewer, previous versions would show a brief but noticeable blink, the image would disappear for a few milliseconds before the new one appeared. In 2026r2, the new image is shown directly. No blink, no flicker. It just works.

Wrapping Up

As usual, 2026r2 also includes a solid round of bug fixes across the web framework. Check the full release notes for the complete list. This is a release that delivers on multiple fronts: raw performance, correctness, cross-target parity, and laying better groundwork for SEO. The thread handling changes alone make this a compelling update for anyone running Xojo web apps under load. And with a proper URL router on the horizon, the SEO story is only going to get better.

Happy coding!

Ricardo has always been curious about how things work. Growing up surrounded by computers he became interested in web technologies in the dial-up connections era. Xojo has been his secret weapon and language of preference since 2018. When he’s not online, chances are he will be scuba diving … or crocheting amigurumis. Find Ricardo on Twitter @piradoiv.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

The good news is starting with Xojo 2026r2, your debugged macOS apps will exhibit the same behavior your users expect when the app is distributed. For example, if you use sandboxing and hardened runtime, these will be applied. Thus, all the regular operations dealing with files will occur in the sandboxed environment and will meet the settings made under the Build Settings > macOS > Sign > Sandbox panel. This same applies when hardened runtime is selected.

In addition, especially for more advanced macOS apps that need to use entitlements and provisioning profiles, these will also be applied when the app is Run / Debug from the Xojo IDE. In this case, make sure to select the Build For > Development Certificate required for signing the app.

Debugging with Entitlements in Action

In order to show how convenient it is to debug macOS apps with entitlements and provisioning profiles applied to them, let’s make use of one of the small improvements also introduced in Xojo 2026r2: synced KeyChain Passwords. For this to work you will need to have iCloud > Passwords enabled under System Settings > Apple Account > iCloud.

The first step is to create the development provisioning profile from Apple’s developer portal (specifically for keychain-access-groups), download it and add it to the project using a Copy Build step, making sure that Contents Folder is selected as the destination for the copied file.

Then, we need to create the associated entitlements file using your favourite text editor for that. Make sure it looks like this for the purpose of this example (you will need to change all the references to the app bundle ID and the Developer ID so these match yours):

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>keychain-access-groups</key>
	<array>
		<string>BW7PU32485.*</string>
	</array>
	<key>com.apple.application-identifier</key>
	<string>BW7PU32485.com.aprendexojo.Cheese</string>
</dict>
</plist>

Once created and saved using the “.entitlements” extension, add it to Build Settings > macOS > Sign > User Entitlements.

Creating a Synced Password

After adding a button to the default project Window, implement the Pressed event handler and add this fragment of code into the associated Code Editor:

Var newItem As KeychainItem

If System.KeychainCount > 0 Then

  newItem = New KeychainItem
  newItem.Label = "This is a Label"
  newItem.Description = "This is a description"
  newItem.ServiceName = "MyApplication"
  newItem.AccountName = "XojoTest"
  newItem.Comment = "This is a comment"
  
  ' Assign a password to the item
  ' Passing True as the third parameter means we want this one
  ' to be created / saved under the iCloud keychain,
  ' so it will be automatically synced with other Macs using
  ' the same iCloud user account.
  
  System.Keychain.AddPassword(newItem, "SecretPassword", true)
Else
  System.Beep
  MessageBox("You don't have a key chain.")
End If

Exception e As KeychainException
  MessageBox("Keychain error: " + e.Message)

Run the app from the IDE (you can enable both sandboxing and hardened runtime too if you wish), click the button and it will behave the same way it will when deployed. If you open Keychain Access app, select the iCloud entry in the Keychain window sidebar, and select then the Passwords option you will see the new added password from the debugged app.

Obviously, if you have more than a Mac using the same user iCloud account, you wil be able to see how that password will be synced and added to its Keychain too after a few seconds.

All in all, this means two things:

1. macOS debugged apps exhibit the same behavior expected when these are deployed, which means that you will be able to debug them in more real conditions.
2. The new ability to create synced passwords is quite convenient for those macOS apps making use of these, so your users won’t be required to create them again on each of their Macs or create different ones on each Mac they own.

In Summary

As we saw, setting sandboxing, hardened runtime, using entitlements and even provisioning profiles in you macOS apps during the debugging process now avoids conditional compilation branches, and provides a closer experience to the final (distributed) app, and even makes it easier to detect bugs in the code.

Javier Menendez is an engineer at Xojo and has been using Xojo since 1998. He lives in Castellón, Spain and hosts regular Xojo hangouts en español. Ask Javier questions on Twitter at @XojoES or on the Xojo Forum.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

Copying

Copying individual members (methods, properties, etc.) from a project item continues to work as before. However, we have added the ability for you to copy some entire project items out of Xojo as text.

Note: When copying a project item (or a member), the Navigator, not one of the editors, must have focus. You can tell it has focus by its color, which is non-gray (green on macOS, for example).

For example, you can select a class (or module or interface) and then paste its contents as text into your favorite text editor, blog editor or AI chat. As an example, here is the DataPoint class (from the Desktop Eddie’s Electronics example project) copied as text and pasted into this post:

Class DataPoint
  Public Sub Constructor(value as Integer, shape as Integer = 0)
    Self.Value = value
    Self.Shape = shape
  End Sub

  Public Function PointNearby(x as integer, y as integer, tolerance as integer = 10) As Boolean
    If Abs(x-Self.x) < tolerance And Abs(y-Self.y) < tolerance Then
      Return True
    End If
  End Function

  Public Property Label As String

  Public Property Shape As Integer

  Public Property Value As Integer

  Public Property X As Integer

  Public Property Y As Integer

End Class

This is surprisingly handy and is a great way to share your code outside Xojo. You can also select multiple project items at once, plus it works with layouts such as Windows, WebPages, Screens and Containers.

Pasting

Pasting code into Xojo has even more improvements. Previously you could paste single members (Methods, Enums, etc., but not properties) into a project item. Now you can paste multiple members at once, including properties. For example, select and copy the list of properties below and paste them onto a project item.

Note: When pasting the project item, the Navigator, not one of the editors, must have focus. You can tell it has focus by its color, which is non-gray (green on macOS, for example).

Public Property Company As String
  Private Property Country As String
Property Address As String
Public Property City As String

Public Property State As String // State code

You can even have different types of members in the selected text, like this:

Public Property Taxable As Boolean
Get
  Const kMax = 42
  Return False
End Get
Set
  Company = "TaxMan”
  Const kMin = 0
End Set
End Property
Public Property Company As String


Public Function Average(A As Double, B As Double) As Double
  Return (A + B) / 2
End Function

And taking things a step further, you can even paste in an entire class:

Class Calculator
  Public Sub Calc()
    Var i As Integer
  End Sub

End Class

Go ahead and copy the DataPoint class from the top and trying pasting it into a project.

And yes, you can also have multiple classes in the selected text:

Class Test
  Public Sub Hello()
    MessageBox("Hello")
  End Sub

End Class

Class Foo
  Public Sub Bar()
    Var i As Integer
  End Sub

End Class

If you paste in a block of text that is not recognized as Xojo code, it is inserted into a new Note, which is a quick way to get some docs added to your classes.

This pasting of project items works for classes, interfaces and non-nested modules. Now when an LLM creates a class for you, you can easily select the entire thing and paste it to add it to your Xojo project!

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.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

This is an important change for those who want modern web rendering on Windows without the large deployment footprint required by the Chromium Embedded Framework (CEF).

Why WebView2 Matters

Until now, Windows HTML rendering in DesktopHTMLViewer has primarily relied on CEF. While CEF provides excellent compatibility and a consistent Chromium-based rendering engine, it also comes with a substantial deployment cost. Including the required CEF runtime files can add well over 200 MB to an application’s distribution size.

Using CEF also means applications are tied to specific Chromium and CEF versions bundled with the app itself. Keeping current requires continuously rebuilding and redistributing newer CEF releases as Chromium evolves and security updates are released.

WebView2 changes that equation considerably.

Because WebView2 uses the Microsoft Edge rendering engine already present on many modern Windows systems, applications can avoid bundling a large embedded Chromium runtime entirely. Security and changes to WebView2 are handled through the operating system via Windows Update, rather than requiring applications to ship and maintain their own browser engine updates.

WebView2 Runtime Requirements

One important consideration is that WebView2 may require the Microsoft Edge WebView2 Runtime to be installed on the target system.

Windows 11

Most Windows 11 systems already include WebView2 as part of the operating system, so no additional installation is usually necessary.

Windows 10

Many Windows 10 systems already have the runtime installed because Microsoft distributes it through Edge and Microsoft 365 updates. However, older or managed systems may still require a separate runtime installation.

Applications that depend on WebView2 should verify runtime availability during installation and, if it is not present, either prompt the user or provide a link to download and install the required runtime.

You can also check DesktopHTMLViewer.IsAvailable at runtime to determine whether WebView2 is available.

Microsoft provides the runtime here:
https://developer.microsoft.com/en-us/microsoft-edge/webview2/

WinUI Targets Use WebView2 by Default

For WinUI desktop targets, WebView2 is now the default (and only) HTML rendering engine for the DesktopHTMLViewer. In addition, any new projects created in Xojo 2026r2 or later will default to using the WebView2 engine whenever a DesktopHTMLViewer is added to the layout.

Enabling WebView2 in older projects or non-WinUI Windows targets

For traditional Windows desktop targets that are not using WinUI, you can still opt into WebView2 support by enabling the HTMLViewer uses WebView2 option in the Advanced Windows build setting in the IDE:

When enabled, DesktopHTMLViewer will use WebView2 instead of CEF for HTML rendering.

This gives you the flexibility to choose between:

• smaller deployment size with WebView2, or
• fully self-contained deployment with CEF

depending on the needs of your application and target audience. However, moving forward we will be transitioning away from CEF entirely, and it is likely that we will no longer support or update our CEF based HTMLViewer in future releases.

Differences from CEF

Although both CEF and WebView2 are Chromium-based technologies, there are some behavioral differences you should be aware of:

• You may notice some subtle differences in how WebView2 returns results for JSON.Stringify when executed using ExecuteJavaScriptSync. i.e. the result coming back may be quoted.
• executeInXojoSync is supported, but it uses JavaScript Promises to simulate synchronous behavior, so existing code may need to be updated to use async/await. Example: const result = await executeInXojoSync("addNumbers", 2, 3);
• A WebView2-specific cache folder is created alongside the executable. If that directory is not writable, the cache folder is instead created in the user’s local AppData directory.

Final Thoughts

The addition of WebView2 support for DesktopHTMLViewer is a major improvement for Windows desktop deployment in Xojo, and reducing runtime size by hundreds of megabytes while still delivering modern Chromium-based rendering is a significant win.

Those who require rendering consistency or offline/self-contained deployments may still prefer CEF, but WebView2 offers an excellent modern alternative that better matches the direction of the Windows platform itself.

For now, you can choose between either engine depending on your needs, but moving forward we believe WebView2 is the preferred path on Windows. Happy browsing!

William Yu grew up in Canada learning to program BASIC on a Vic-20. He is Xojo’s resident Windows and Linux engineer, among his many other skills. Some may say he has joined the dark side here in the USA, but he will always be a Canadian at heart.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

Behind the Scenes…

Let’s start with a non-visible change, but a major and important one. In fact, this responds to one of Apple’s requirements for iOS apps:

“In the next major release following iOS 26, UIScene lifecycle will be required when building with the latest SDK; otherwise, your app won’t launch.”

Xojo has made the necessary underlying changes in the iOS Framework, and starting with Xojo 2026r2, all iOS apps are compiled/built so they can be run and published meeting this requirement.

What does this mean for you in practice? For any existing Xojo iOS projects, all you need to do is rebuild them with the current version of Xojo. This guarantees that the apps implement the required UIScene lifecycle and can be run without issues both on the iOS simulators and real iOS devices using iOS 26+.

MobilePopupMenu Arrives to iOS

Until now, making simple selections in iOS projects required a complex UI design involving navigation to different screens, the use of tables, containers, etc. Starting with Xojo 2026r2, we have simplified everything with the new MobilePopupMenu control.

In fact, the feature also uses a newly added class for the displayed menu entries: MobileMenuItem (more on this a bit later). It is also possible to add new entries to the menu as text, if you prefer. No matter how entries are added to the PopupMenuControl’s menu, the underlying items are MobileMenuItem instances, and these are the ones received in the SelectionChanged event handler.

You can populate the MobilePopupMenu entries at design time via the associated Inspector Panel, and select the default SelectedRowIndex value. Of course, you can do the same at runtime and change the control’s menu entries as you would with the equivalent control on Desktop.

MobileMenuItem

This new class added to the iOS Framework lets you create menu entries for the MobilePopupMenu, as well as for the newly added Menu properties on MobileButton and MobileToolbarButton.

Like its Desktop counterpart, it is possible to create hierarchical menu entries and assign icons to each item. What is specific to MobileMenuItem on iOS are the Destructive (Boolean) and DisplayMode (Enum) properties. When a MobileMenuItem instance is set to Destructive, it will be displayed as such under the iOS Design Guidelines, giving users a clear visual clue about the potentially destructive action.

The DisplayMode property can be set as Regular (the usual dropdown displaying of a menu) or as Palette. With Palette, child entries are presented in a smaller palette with horizontal navigation, which is especially recommended for tight UI designs where options are shown as icons.

If a MobileMenuItem is set to a MobilePopupMenu, it will not display the icons for the menu entries and will discard any child hierarchies (submenus), as is also the case for DesktopPopupMenu and WebPopupMenu. On the other hand, MobileButton and MobileToolbarButton are able to support submenus and will display the associated icons for every menu entry.

MobileButton

As previously noted, this control has new properties related to displaying a menu. It is possible to set the menu (MobileMenuItem instance) at runtime, and the behavior is controlled by the DisplayMenuAsAction (Boolean) property.

When DisplayMenuAsAction is set to False (the default), the Button fires its Pressed event as usual, and the menu is displayed only after a long press on the button. The menu selection made by the user will be received through the new MenuItemSelected(menu As MobileMenuItem) event handler that can be implemented on the button instance itself. All in all, this provides a good way for the button to react to two different user interactions.

If the DisplayMenuAsAction property is set to True, the associated menu is presented when the button is pressed. In this case, the Pressed event handler will not fire, only its MenuItemSelected (menu as MobileMenuItem) handler will fire after the user makes a selection in the menu.

MobileToolbarButton

MobileToolbarButton also has the new Menu and DisplayMenuAsAction properties, and these behave in the same way as described above. The main difference is that, in this case, the MenuItemSelected event handler needs to be implemented in the containing Screen instance for the NavigationBar to which the MobileToolbarButton has been added, just as the pre-existing ToolbarButtonPressed event handler was.

Badges

In addition to the support of menus, MobileToolbarButton also got the ability to display badges. This is useful in order to simplify many mobile apps UI designs.

The information shown in the badge is set through the MobileToolbarButton.BadgeText property. If this property is set to an empty string, the badge will not be displayed. In addition, there are other properties you can use to customize the badge’s appearance:

• BadgeColor As ColorGroup. Set the background color for the badge.
• BadgeTextColor As ColorGroup. Set the color for the text displayed in the badge.
• BadgeTextFont As Font. Set the font, style and font size to be used by the text in the badge.

In Summary

The new iOS Scenes based lifecycle will keep your apps in compliance with the requirement from Apple for future iOS releases beyond iOS 26, and we hope you will find the new menu items useful additions to simplify your iOS UI designs.

We are interested to know more about how you use these features, and invite you to share your iOS stuff on the Xojo Forum iOS channel!

Special thanks to Xojo MVP Jérèmie Leroy, he is always pushing and helping improve Xojo’s iOS support.

Javier Menendez is an engineer at Xojo and has been using Xojo since 1998. He lives in Castellón, Spain and hosts regular Xojo hangouts en español. Ask Javier questions on Twitter at @XojoES or on the Xojo Forum.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

These changes focus on two main areas:

• Expanded button symbol support in DesktopToolbarButton
• New layout and presentation control via toolbar style options

Smarter Icon Handling with Symbols

A key addition is the new Symbol property on DesktopToolbarButton. It lets you provide a single string containing multiple symbol names separated by semicolons. Each platform will then check that list and use the first symbol it recognizes.

The Symbol feature is only supported on Windows when using the WinUI target.

AllowMulticolorSymbol was added for macOS. When enabled, the OS may render toolbar symbols using multicolor variants where available, instead of enforcing monochrome styling.

Example

home.Symbol = "house.fill;home;go-home"
home.AllowMulticolorSymbol = True
back.Symbol = "chevron.left;back;go-previous"
forward.Symbol = "chevron.right;forward;go-forward"
search.Symbol = "magnifyingglass;find;system-search"

How it works

Instead of relying only on a static icon, the toolbar now attempts to resolve a symbol first. If a symbol is found, it is used in preference to any icon.

The lookup order is:

1. First matching symbol in the list
2. If none resolve, fallback to the standard icon (if one is set)

This allows you to provide multiple symbolic names as a fallback chain, improving cross-theme and cross-platform reliability.

Where to find the list of supported symbols

WinUI: https://learn.microsoft.com/en-us/uwp/api/windows.ui.xaml.controls.symbol

Linux: https://specifications.freedesktop.org/icon-naming

macOS: https://developer.apple.com/design/human-interface-guidelines/sf-symbols

Better Control Over Toolbar Layout

The toolbar itself now supports a new Style property. This controls how buttons are visually arranged.

DesktopToolbarStyles options:

• Default
  • Generally icon/symbol on top, caption below
  • On Linux and WinUI: icon/symbol on left, caption on right
• IconCaptionVertical
  • Forces vertical layout (icon/symbol above text)
• IconCaptionHorizontal
  • Forces horizontal layout (icon/symbol beside text)
  • Only supported on Linux and Windows
• IconOnly
  • Displays only the icon/symbol
• CaptionOnly
  • Displays only text labels

In Conclusion

With support for symbols, additional layout styles, and WinUI support on Windows, we’re making it easier to create toolbars that look more modern, feel more native on each operating system, and adapt better to different user environments. Whether you prefer icon-only toolbars, text labels, or platform-specific symbols, the new options give you more ways to fine-tune the experience for your users without adding extra complexity to your projects.

William Yu grew up in Canada learning to program BASIC on a Vic-20. He is Xojo’s resident Windows and Linux engineer, among his many other skills. Some may say he has joined the dark side here in the USA, but he will always be a Canadian at heart.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

Settings

Let’s start with the Settings window, which now has its own AI panel for adjusting how Jade works.

By default, “Enable AI Features” is checked. However, if you are not onboard the AI train, then you can uncheck that setting to turn off Xojo AI integration. This removes the Jade button from the toolbar and also disables the Help menu option.

With AI Features enabled, you can choose the Service to use. By default, “Anthropic Claude” is selected so that your previous Jade configuration works the same as before, but you now also have all these services to choose from:

• Anthropic Claude
• OpenAI GPT
• OpenRouter (Anthropic)
• OpenRouter (OpenAI)
• Local

More information about each of these is in the next section.

The “Allow access to project context” option lets Jade ask for information about your project, such as the names of project items, their source code and any compile errors.

The “Restore conversation from last time” option indicates if your last Jade conversation will be restored to the chat window when the IDE restarts.

Below this are the text areas where you can enter API keys for the services you are using.

Services

Anthropic Claude

When Anthropic Claud is selected, Xojo uses the most recent version of the Claude Sonnet model, which is currently 4.6. To use this service, you will need to create an Anthropic account, generate an API key and add some credits.

Access to project context is supported with Anthropic Claude.

OpenAI GPT

When choose OpenAI, Xojo uses a recent version of the gpt-mini model, currently gpt-5.4-mini. This particular model is fast, relatively inexpensive and well suited for coding purposes. To use OpenAI, you will need to create an OpenAI account , generate an API key and add some credits. There is also an option to earn some free credits that you can optionally turn on.

Access to project context is supported with OpenAI.

OpenRouter

OpenRouter is a unified API service that gives access to hundreds of LLMs from different providers (OpenAI, Anthropic, Google, Meta, etc.) through a single endpoint and key.” Like the others you will first need to create an account, generate an API key and purchase credits. OpenRouter applies these credits as appropriate when using the models you have configured.

There are two options for OpenRouter, so that you can tell it whether to use the Anthropic or OpenAI API. When you choose Anthropic, OpenRouter will automatically route you to Claude models. When you choose OpenAI, OpenRouter will direct you to the default model specified in your OpenRouter account settings.

Not all models will work with Jade and some models have limitations. Currently, only OpenRouter with OpenAI and an OpenAI GPT model supports project context. If you want to try other models, you will likely need to disable the “Allow access to project context” setting in Xojo.

Local LLM

A local LLM is a model that you are running locally on your computer or server you control. To run a local LLM, we recommend using LM Studio which makes it easy to download and run models on a local server.

When this is selected, you also need to provide the base URL for your server. With LM Studio, it is typically:

http://127.0.0.1:1234

In our testing with Xojo we’ve found that a Qwen model, such as qwen3-coder-30b works OK. Other models may not provide useful responses or even work at all. Even though this model works, it is far less capable than Anthropic Claude or OpenAI GPT.

If you want to use Ollama, you’ll have to specify the model name as part of the base URL like this:

http://127.0.0.1:11434#qwen2.5-coder:14b

A local LLM does not have access to project context and choosing this service option currently ignores that setting.

Which Should You Use?

Based on our internal testing, Anthropic Claude has the most accurate responses. It is also the slowest and most expensive.

OpenAI with GPT is the fastest and is relatively inexpensive for what you get.

OpenRouter is really only recommended for advanced users, but it does provide an easy way to switch to specific models.

A local LLM is free to use and completely private, but it is also much slower and far less accurate. Depending on the model you choose, a local LLM also requires significant computing resources (RAM and GPU).

I hope you find these Jade improvements useful to you!

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.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

1. The UI froze completely until the search finished.
2. If the folder tree was deep enough, you might have hit a StackOverflowException.
3. We haven’t actually built a proper UI for it yet!

Today, we’re fixing all three. We’ll introduce a custom app UI, create a Thread subclass to perform the search in the background, and swap our recursive folder crawl for a flatter, iterative approach to spare our stack memory. We’ll also add a file size limit to avoid choking on massive unreadable files.

Step 1: Designing the UI

First, let’s build the interface so you have a real application to run. On your main Window1 (or whichever Window you are using), we need to add a few controls:

• Path Selection: Add a DesktopTextField (named fieldPath, set to ReadOnly) to display the chosen folder path, and a DesktopButton (named buttonSelectPath, caption ...) next to it to open a SelectFolderDialog.
• Search Input: Add a DesktopSearchField (named fieldSearchTerm) where the user types the text they want to find.
• Action Button: Add a DesktopButton (named buttonSearchThreaded, caption Search Threaded) to start and cancel the search.
• Results List: Add a DesktopListBox (named listResults) and set its Column Count to 3. (Optional: Set the InitialValue of the Column headers to File | Line No. | Context).
• Status labels: Add a DesktopLabel (named labelStatusValue) at the bottom of the window to display the live search progress.

Step 2: Creating the Thread Subclass

Threading lets us run our file search simultaneously with the main application, keeping our UI totally responsive.

Instead of writing standard methods, we need to create a dedicated Class.

1. Add a New Class, in the SearchUtils module and name it FileSearch.
2. In the Inspector, change its Super to Thread.
3. Add the following Properties to your new class:
   • MaximumFileSizeMB As Integer = 1
   • SearchTerm As String
   • TargetFolder As FolderItem
   • startTime As Double (Set Scope to Private)

Defining Custom Events

We need our Thread to broadcast events to the Window that’s holding it. Add these three Event Definitions to your FileSearch class:

• Complete(timeElapsed as Double)
• MatchFound(result as SearchUtils.SearchHit)
• StatusUpdate(currentPath as String)

Step 3: The iterative approach

Recursion is elegant, but crawling a hierarchy thousands of folders deep throws a StackOverflowException. Instead, we flatten the traversal using an array as a queue. We start by adding our root folder’s children to an array. As we iterate through that array, any folders we find get their children appended to the end of the same array.

Here is exactly how it looks in the Thread’s Run event. Add the Run event to your FileSearch class and use this exact code and notice the use of AddUserInterfaceUpdate to safely queue UI updates:

Sub Run() Handles Run
  Var maxFileSize As Double = If( Self.MaximumFileSizeMB < 1, 999999999 * 1024 * 1024, Self.MaximumFileSizeMB * 1024 * 1024 )
  
  Var result As Dictionary
  
  Var lastUpdate As Integer = System.Microseconds
  
  If Not (targetFolder Is Nil) And targetFolder.Exists And Not searchTerm.IsEmpty Then
    
    Var child As FolderItem
    Var toSearch() As FolderItem
    For Each child In targetFolder.Children
      toSearch.Add( child )
    Next
    
    Var ti As TextInputStream
    Var line As String
    Var lineNumber As Integer = -1
    
    For index As Integer = 0 To toSearch.LastIndex
      child = toSearch(index)
      
      If System.Microseconds - lastUpdate > 1000000 Then
        result = New Dictionary
        result.Value( "type" ) = "status"
        result.Value( "current" ) = child.NativePath
        AddUserInterfaceUpdate( result )
        lastUpdate = System.Microseconds
      End If
      
      If child.IsFolder Then
        Try
          
          #Pragma BreakOnExceptions False
          
          For Each innerChild As FolderItem In child.Children
            toSearch.Add( innerChild )
          Next
          
          #Pragma BreakOnExceptions Default
          
        Catch e As IOException
          '// Skip inaccessible folders
        End Try
      Else
        If child.Length < maxFileSize Then
          Try
            ti = TextInputStream.Open( child )
            ti.Encoding = Encodings.UTF8
            
            lineNumber = 0
            
            While Not ti.EndOfFile
              lineNumber = lineNumber + 1
              line = ti.ReadLine
              If line.Contains( searchTerm, ComparisonOptions.CaseInsensitive ) Then
                result = New Dictionary
                result.Value( "type" ) = "match"
                result.Value( "path" ) = child.NativePath
                result.Value( "lineNo" ) = lineNumber
                result.Value( "lineText" ) = line
                AddUserInterfaceUpdate( result )
              End If
            Wend
          Catch ioe As IOException
            '// Skip unreadable files
          End Try
        End If
      End If
    Next
  End If
  
  result = New Dictionary( New Pair( "type", "complete" ) )
  AddUserInterfaceUpdate( result )
End Sub

Step 4: Sending Updates to the UI safely

In a thread, you cannot update UI controls directly. That’s why we used AddUserInterfaceUpdate above passing a Dictionary of data. This triggers the Thread’s UserInterfaceUpdate event on the main UI thread.

Add the UserInterfaceUpdate event to your FileSearch class:

Sub UserInterfaceUpdate(data() As Dictionary) Handles UserInterfaceUpdate
  For Each d As Dictionary In data
    Select Case d.Value( "type" )
    Case "match" 
      Var hit As New SearchHit( d.Value( "path" ), d.Value( "lineNo" ), d.Value( "lineText" ) )
      RaiseEvent MatchFound( hit )
    Case "complete"
      RaiseEvent Complete( (System.Microseconds - startTime) / 1000 )
    Case "status"
      RaiseEvent StatusUpdate( d.Value( "current" ) )
    End Select
  Next
End Sub

And finally, add a public method called Search to the class, making sure it executes Preemptively across CPU cores:

Public Sub Search(path As FolderItem, term As String)
  Self.Type = Thread.Types.Preemptive
  
  startTime = System.Microseconds
  
  Self.TargetFolder = path
  Self.SearchTerm = term
  Self.Start
End Sub

Step 5: Wiring the UI

Now, let’s bring it all together. Select Window1 and simply drag the FileSearch class from your Navigator onto your Window. It will appear in a shelf at the bottom as FileSearch1 (rename it to seeker).

Implement the Event Handlers to your new seeker control:

seeker.Complete:

Sub Complete(timeElapsed As Double) Handles Complete
  buttonSelectPath.Enabled = True
  buttonSearchThreaded.Caption = "Search Threaded"
  fieldSearchTerm.Enabled = True

  Var count As Integer = listResults.LastRowIndex + 1
  Var timeElapsedSeconds As Double = timeElapsed / 1000
  labelStatusValue.Text = "Complete in " + timeElapsedSeconds.ToString( "#0.00" ) + " seconds! " + count.ToString( "#" ) + " results found."
End Sub

seeker.MatchFound:

Sub MatchFound(result As SearchUtils.SearchHit) Handles MatchFound
  listResults.AddRow( result.FilePath, result.LineNumber.ToString( "#" ), result.LineText )
  listResults.RowTagAt( listResults.LastAddedRowIndex ) = result
End Sub

seeker.StatusUpdate:

Sub StatusUpdate(currentPath As String) Handles StatusUpdate
  labelStatusValue.Text = "Searching '" + currentPath + "'"
End Sub

And finally, the code in buttonSearchThreaded to kick off the search (and handle nice cancellation):

Sub Pressed() Handles Pressed
  Select Case Me.Caption
  Case "Search Threaded"
    If fieldSearchTerm.Text.Length >= 3 Then
      If seeker.ThreadState = Thread.ThreadStates.NotRunning Then

        listResults.RemoveAllRows

        fieldSearchTerm.Enabled = False
        buttonSelectPath.Enabled = False
        labelStatusValue.Text = "Searching..."

        Me.Caption = "Cancel"

        seeker.Search( Self.path, fieldSearchTerm.Text )

      End If
    End If
  Case "Cancel"
    seeker.Stop
    labelStatusValue.Text = "Cancelled"
  End Select
End Sub

Summary

By switching from recursion to a linear queue, we bulletproofed the code against StackOverflowExceptions. By moving the heavy lifting to a preemptive Thread, we completely unlocked the UI, making the app feel incredibly fast and responsive even while chewing through thousands of files. And using AddUserInterfaceUpdate, we safely pipe results directly back to the user without locking up the UI!

You can download the project here: SearchUtils.FindInFiles.zip

Special Thanks

A huge shoutout and special thanks to Xojo MVP and forum user Anthony G. Cyphers. Anthony generously provided the solution to evolve the SearchUtils module into this threaded version, along with the demo app UI.

P.S. Got your own spin on this utility? Have ideas for new features or alternative approaches? Jump into the Xojo Code Sharing Forum  and share your improvements with the community!

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!

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

Stephen Dodd has been a Xojo developer since 2001. Over two decades, he’s seen Xojo evolve, and his work embodies the cross‑platform strength Xojo offers users. During his recent Xojo license renewal, he commented “See the beautiful cross platform app made with it.” We absolutely love receiving comments like this; they remind us why we do what we do and how our community uses Xojo to create remarkable projects. Immediately I shared Stephen’s app, OfficeTime, with the team and it didn’t take long before someone said “this deserves a Spotlight On!”. Fortunately, Stephen was kind enough to say yes and answer our questions.

Mac, Windows or Linux?

Mac + Windows of course. Evaluating Linux demand.

What do you wish more people would ask you about when it comes to your work? Is there an aspect of your work that people often overlook but you wish they were more curious about?

I’m passionate about the user experience. The simpler the app, the more time is needed. OfficeTime came about when the staff at the agency I was head of hated tracking their time. Everyday I’d walk by graffiti someone plastered that said “Start writing. What’s stopping you?” Coding is writing. OfficeTime is successful because I’m not ‘into’ time tracking. I’m into something that does its job and stays out of your way.

I’m fond of hiding complication until it’s needed. For example, the user can change the rate of an existing category in OfficeTime. That introduces choices for what previously tracked time is affected. We hide all that interface until the user actually starts typing a new rate. Unfortunately for the developer, the simpler you make it, the longer it takes. 

What is something that has surprised you about coding in the last 5 years?

How fricking long implementing full featured, offline first cloud sync takes to get right. Cloud sync is deceptively hard. The majority of our bugs seem to revolve around timing issues of when data / UI is available or not.

Xojo isn’t the only tool in your kit. What is a piece of software more people should know about?

• OfficeTime to track my time!
• TextExpander to hot key in code snippets and customer support replies.
• Claude because it just has a more natural, intuitive output than ChatGPT or Gemini. 

Which three Xojo language features or framework capabilities do you find yourself relying/using on the most?

We hammer that listbox pretty heavily.  It’s core to all the views and reports.

What did you first build with Xojo? And when was that?

In the 90’s, using Xojo (then called REALbasic), I built a neural network (before AI was cool) to learn to play tic tac toe.

I originally took up Xojo because the O’REILLY book had a cheetah on it which meant it had to be fast. All the Microsoft books had bugs on them. 

What do you build with it now?

OfficeTime is a cross platform app to better track your time so you can bill more or be more accountable for fixed price projects.  The Mac/PC side is Xojo with a few custom written controls. It syncs with an iPhone/iPad app that was written in Xcode long before Xojo offered mobile development.

Do you earn a living with Xojo?

Yes.

What’s your biggest Xojo success?

OfficeTime

If you were introducing Xojo to a friend, which three words would you use to describe it?

Easy cross platform

Thank you to Stephen Dodd for answering questions and sharing his Xojo experience with the community. If you have an app, a project or a person you want to see featured in Spotlight On, tell us about it!

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

An extension method is a method that is called using syntax that indicates it belongs to another object. For example, say you really don’t like writing code like this that increments an integer value:

downloadCounter = downloadCounter + 1

With an extension method for Integer, you could instead write something like this:

downloadCounter.Add

Essentially, extension methods are global methods that use the Extends keyword to allow you to write the method using dot notation. This describes the first rule, which is that extension methods must be global methods on modules. The extension method for this Add method looks like this:

Sub Add(ByRef Extends i As Integer, amount As Integer = 1)
  i = i + amount
End Sub

Since this takes an optional parameter, you could also write:

downloadCounter.Add(5)

to mean:

downloadCounter = downloadCounter + 5

There is a lot more you can do with extension methods, but they are particularly useful for adding methods like this to the built-in data types (such as Integer) that are not available for subclassing.

Another good example is adding a DoubleQuote method that can be used to quote strings:

Function DoubleQuote(Extends s As String) As String
  Return """" + s + """"
End Function

Of course, you can also extend regular classes as well. This example extends DesktopListBox to add a search function that will search and select a row that contains a specific column value:

Sub Find(Extends lb As DesktopListBox, findText As String, column As Integer = 0)
  For i As Integer = 0 To lb.LastRowIndex
    If lb.CellTextAt(i, column) = findText Then
      lb.SelectedRowIndex = i
      Exit For
    End If
  Next
End Sub

You use it by supplying the text to find and, optionally, the column to search in. This just searches the first column:

ListBox1.Find("MyValue")

Extensions are a great way to make your code more readable and to easily add useful “utility” methods. To learn more about extension methods, refer to the Docs.

There’s an extension method example that is included with Xojo which you can find in the Examples section of the Project Chooser: Examples/Language/Extension Methods

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.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

I’ll update this FAQ from time to time, so you may want to bookmark it and revisit! In addition, the Xojo Forum is a great place to keep the conversation about this and other iOS Xojo-related topics!

Can I develop iOS apps on Windows?

No. Running, testing, or debugging an iOS project in Xojo requires the iOS Simulator which is provided only with Apple’s Xcode and is only available on macOS. We advise using ARM processor based Macs that are updated to the latest version of macOS. You can review the system requirements for building iOS apps with the latest Xojo release.

Do I need to install anything besides Xojo?

In addition to Xojo, you’ll need to install Xcode and run it at least once in order to accept to the provided agreements and to get logged-in into your developer account from the Xcode preferences (mostly in order to install the Developer Certificates).

Make sure there is, at least, an iOS SDK installed – it should already be there because it is done automatically during Xcode’s first installation (and subsequent Xcode updates).

In addition, if needed, you can download additional iOS SDKs from Xcode > Preferences > Components.

Also, make sure that the Xcode CLI tools are installed, because Xojo needs these in order to create the package during the build process. You can set these under Xcode > Preferences > Locations.

Why are the Run and Build buttons disabled for my iOS projects in Xojo?

There could be a few reasons for this.

• Check that the CLI tools are selected in Xcode. See previous point.
• Launch Xcode to make sure you have agreed to the license agreement and that there are no Xcode issues that jump out.
• Are you signed into the Xojo IDE with the account that holds your Xojo Mobile license? Open the license key window in the Xojo app and verify your license is there. If not, sign in to the IDE to automatically add your license. Check Troubleshooting tips for licenses.

I don’t see a Simulator under Xojo Project > Run On menu… what can I do about that?

Quit Xojo and re-open it. You should now see the same Simulators installed on Xcode under that Xojo submenu.

Do I need to keep Xcode open while using Xojo?

No. That is not necessary at all!

Everything was working fine… but now I can’t run or build iOS apps. Why?

It’s likely there is a new agreement you need to accept from Apple. Go to the Apple Developer Portal log-in using your developer credentials and check if there are new or updated agreements.

Another thing to check for are expired provisioning profiles or missing or expired Developer Certificates. If so, you need to create new ones.

And of course make sure your Xojo license is listed in the license key window. Are you signed into the Xojo IDE with the account that holds your Xojo Mobile license? Open the license key window in the Xojo app and verify your license is there. If not, sign in to the IDE to automatically add your license. Check Troubleshooting tips for licenses.

Can I use Xojo iOS if I have a free Apple Developer Account?

In short: yes. Free Apple Developer Accounts are those you can create using an Apple Account. That is, the same you use in order to access other Apple services. But, even if it is possible to use a free developer account, these have some limitations compared with the paid Apple Developer account. The following table summarizes these:

In addition, you need to also consider the following limitations:

• The number of App IDs that can be registered is limited to 10 and each expires after 7 days.
• The number of test devices that can be registered to the account is limited to 3, and each expires after 7 days.
• Provisioning profiles will expire 7 days from issuance, which may require you to rebuild and re-install your app to your device after expiration.

There are some free tools you can use to skip these limitations, but they are not officially supported, for example Sideloadly (in fact this one can be used even on Windows).

I have a free Apple Developer account and I followed all the previous steps and I still can’t run my app from Xojo.

In order for an iOS app to run it requires a provisioning profile. These can be created from the Apple Developer website or you can let Xcode handle them. If you don’t have a lot of experience with iOS development (or Apple platforms development in general), then the easiest way forward is to use the following steps which allow Xcode to create the provisioning profile for your specific app. These steps are for the most basic provisioning profile; one that doesn’t include the use of any of specific Apple services or technologies that require being included in such provisioning profile:

1. Open Xcode and create a new iOS project.
2. Give the project the same Bundle Identifier as the one you are going to use in your Xojo project.
3. In the main area of the Xcode window, select the item for the project root (A).
4. Then, select the target item from the Targets section (B).
5. Next, select the Signing & Capabilities tab. Make sure your Team is selected and the Bundle Identifier is the same one you are using for your Xojo app (C).
6. As result of the selections made, you will see the area corresponding to the (Xcode managed) provisioning profile that is going to be created.
7. Make sure a Simulator is selected and then run the App from Xcode. That action will open the selected Simulator and will run the blank app into it.
8. Because a provisioning profile has already been created, go back to Xojo and you will be able to run your Xojo app. If that is not the case, quit Xojo and reopen it so the IDE can find the just generated provisioning profile from Xcode.

Are there other ways to install my iOS apps to my registered devices without going through the App Store?

Yes. You can install built iOS apps on the devices previously registered in your developer account through what is called sideloading using Xcode.

Once the app has been built using Xojo (it creates a package – IPA file), go to Xcode > Devices and Simulator, select the device and drop the package onto the area showing the apps installed on that device. That action will initiate the copy (installation) of your iOS app on that specific device.

Take into consideration that this kind of installation allows the app to run for one year; that is, the timespan the provisioning profile lasts for that particular app. Once the provisioning profile expires, you will need to repeat the process: build the app with a new provisioning profile, and copy it again into the device.

Is it possible to distribute Xojo-created iOS Apps through the App Store?

Of course! In fact the Xojo IDE greatly simplifies the process of building and uploading directly your iOS apps to the App Store Connect portal, both for starting the required Apple review process previous for the app being available through the App Store, or if you simply want to distribute your betas to your beta-testers using Testflight.

In order to distribute iOS apps through the App Store you will need a paid Apple Developer membership.

Helpful Resources

As always, Xojo provides resources for free, no license needed to access our user forum, documentation, videos and other resources.

• Xojo iOS Quickstart
• Xojo iOS Tutorial
• How to Publish macOS and iOS Apps to the App Store Directly from Xojo
• Differences between iOS and Android
• Getting the user’s location from their mobile device
• How to apply a blur effect on iOS
• Sending and receiving mobile notifications
• Loading 3rd Party Frameworks in Xojo iOS
• iOS related posts on the Xojo Blog

Javier Menendez is an engineer at Xojo and has been using Xojo since 1998. He lives in Castellón, Spain and hosts regular Xojo hangouts en español. Ask Javier questions on Twitter at @XojoES or on the Xojo Forum.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

Part 1: Building JSON

Building JSON from scratch means firing up a new JSONItem and throwing data at it. Don’t build JSON by stitching strings together. It breaks easily, you’ll mess up the escaping, and JSONItem makes it completely unnecessary.

The Basic Payload

When you just need to fire a flat object at a web service:

Var apiPayload As New JSONItem
apiPayload.Value("endpoint") = "/users/create"
apiPayload.Value("timestamp") = 1715423000
apiPayload.Value("forceSync") = True

// Get the string back
Var jsonString As String = apiPayload.ToString
// {"endpoint":"/users/create","timestamp":1715423000,"forceSync":true}

Making Arrays

If you’re making a list of tags or IDs, use the .Add method. The moment you call .Add, Xojo treats that JSONItem as a JSON array under the hood.

Var tags As New JSONItem
tags.Add("xojo")
tags.Add("desktop")
tags.Add("api")

Var jsonString As String = tags.ToString
// ["xojo","desktop","api"]

Nesting Things

Most APIs want nested payloads. You map this out by making separate JSONItem objects and attaching them to each other.

Var payload As New JSONItem
payload.Value("status") = "active"

Var user As New JSONItem
user.Value("id") = 982
user.Value("username") = "johndoe"

Var roles As New JSONItem
roles.Add("admin")
roles.Add("editor")

user.Value("roles") = roles // Attach the array to the user object
payload.Value("data") = user // Attach the user object to the main payload

Var jsonString As String = payload.ToString
// {"status":"active","data":{"id":982,"username":"johndoe","roles":["admin","editor"]}}

Part 2: Parsing JSON

To go the other direction, pass a raw JSON string straight into the constructor.

Reading a Flat Response

When a server hands you back a flat config or auth token, just pull the values right out.

Var rawJSON As String = "{""token"":""abc123xyz"",""expiresIn"":3600,""active"":true}"
Var response As New JSONItem(rawJSON)

Var token As String = response.Value("token")
Var expiresIn As Integer = response.Value("expiresIn")
Var isActive As Boolean = response.Value("active")

Handling Optional Keys with Lookup

If you use .Value("key") and the key isn’t in the JSON, Xojo throws a KeyNotFoundException. Instead of writing boilerplate If response.HasKey("key") Then checks everywhere, use .Lookup(). It lets you define a fallback value in line.

Var rawJSON As String = "{""username"":""johndoe""}"
Var response As New JSONItem(rawJSON)

// Returns "johndoe" because the key is present
Var user As String = response.Lookup("username", "anonymous") 

// Returns False because "forceSync" is missing from the JSON
Var isSyncForced As Boolean = response.Lookup("forceSync", False) 

Looping Over an Array

If an API hands you a list of database records:

Var rawJSON As String = "[{""id"":1, ""name"":""Alice""}, {""id"":2, ""name"":""Bob""}]"
Var userList As New JSONItem(rawJSON)

For i As Integer = 0 To userList.Count - 1
  Var currentUser As JSONItem = userList.ValueAt(i)

  Var id As Integer = currentUser.Value("id")
  Var name As String = currentUser.Value("name")

  System.DebugLog(id.ToString + ": " + name)
Next

Digging out Nested Nodes

This is where .Child() comes in handy. While .Value() returns a generic Variant (which you can’t chain directly), .Child("key") explicitly returns the nested object as a JSONItem. This allows for perfectly clean chaining.

Var rawJSON As String = "{""weather"":{""current"":{""temp"":22, ""condition"":""Sunny""}}}"
Var forecast As New JSONItem(rawJSON)

// Use .Child() to tunnel down into objects, then .Value() to pull the final primitive data 
Var temperature As Double = forecast.Child("weather").Child("current").Value("temp")
Var condition As String = forecast.Child("weather").Child("current").Value("condition")

Part 3: Identifying the Structure

APIs are notoriously inconsistent. Check the .IsArray property to figure out what structure you’re dealing with before parsing it, so your loops don’t crash when passing something unexpected.

Var rawJSON As String = "[""apple"", ""banana"", ""orange""]"
Var parsedData As New JSONItem(rawJSON)

If parsedData.IsArray Then
  System.DebugLog("Looks like an array with " + parsedData.Count.ToString + " items.")

  For i As Integer = 0 To parsedData.Count - 1
    System.DebugLog(parsedData.ValueAt(i).StringValue)
  Next
Else
  System.DebugLog("It's a standard dictionary.")
  If parsedData.HasKey("data") Then
    System.DebugLog(parsedData.Value("data").StringValue)
  End If
End If

That’s it. For more info on JSONItem, don’t forget to check the online documentation at: https://documentation.xojo.com/api/text/json/jsonitem.html

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!

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

The Goal

We want to:

1. Search through subfolders automatically.
2. Add a maxDepth parameter so we don’t accidentally crawl the entire hard drive.
3. Keep the simple version working using method overloading.

Step 1: Move File Reading to its own Method

The original FindInFiles function did everything: validated the folder, looped through children, read file content, and matched text. Adding recursion to that would make the code look ugly, so let’s refactor our code.

We’ll start by moving the file-reading logic into its own private method: SearchFile. This keeps the “search” logic separate from the “looping” logic.

Private Sub SearchFile(file As FolderItem, searchTerm As String, hits() As SearchHit)
  Try
    Var input As TextInputStream = TextInputStream.Open(file)
    input.Encoding = Encodings.UTF8
    Var lineNumber As Integer = 0
    While Not input.EndOfFile
      Var line As String = input.ReadLine
      lineNumber = lineNumber + 1
      If line.Contains(searchTerm, ComparisonOptions.CaseInsensitive) Then
        hits.Add(New SearchHit(file.NativePath, lineNumber, line))
      End If
    Wend
    input.Close
  Catch error As IOException
    // Skip unreadable files
  End Try
End Sub

Step 2: Recursive Folder Traversal

Now we create SearchFolder. This method loops through a folder. If it finds a file, it calls SearchFile. If it finds a folder, it calls itself.

To keep this safe, we Use maxDepth:

• maxDepth = 0: Search only this folder.
• maxDepth > 0: Search this folder and N levels of subfolders.
• maxDepth = -1: Search everything (unlimited).

Private Sub SearchFolder(folder As FolderItem, searchTerm As String, hits() As SearchHit, maxDepth As Integer)
   Try
    For Each item As FolderItem In folder.Children
      If item Is Nil Or Not item.Exists Or Not item.IsReadable Then Continue
      If item.IsFolder Then
        If maxDepth <> 0 Then
          Var nextDepth As Integer = If(maxDepth > 0, maxDepth - 1, maxDepth)
          SearchFolder(item, searchTerm, hits, nextDepth)
        End If
      Else
        SearchFile(item, searchTerm, hits)
      End If
    Next
  Catch error As IOException
    // Skip inaccessible folders
  End Try
End Sub

The logic in nextDepth lets us count down if there’s a limit, or stay at -1 if there isn’t.

Step 3: Support Both Versions with Method Overloading

Overloading is a feature that lets you have multiple methods with the same name, as long as they have different parameters. In our case, it allows us to provide a simple version for one folder, and a recursive version with a depth limit. Xojo will automatically pick the right one based on the arguments you pass. You can read more about it in the Xojo Documentation.

The default version (depth 0):

Public Function FindInFiles(targetFolder As FolderItem, searchTerm As String) As SearchHit()
  Return FindInFiles(targetFolder, searchTerm, 0)
End Function

The recursive version:

Public Function FindInFiles(targetFolder As FolderItem, searchTerm As String, maxDepth As Integer) As SearchHit()
  Var hits() As SearchHit
  If targetFolder Is Nil Or Not targetFolder.Exists Or Not targetFolder.IsFolder Or searchTerm.IsEmpty Then
    Return hits
  End If
  Try
    SearchFolder(targetFolder, searchTerm, hits, maxDepth)
  Catch error As IOException
    // Skip inaccessible folders
  End Try
  Return hits
End Function

By separating the validation, traversal, and processing, the code is much easier to modify. If you want to add Regex support, you only change SearchFile. If you want to filter by file extension, you only change SearchFolder.

Summary

Now, you can search a single folder just like before, or crawl a directory tree with one extra parameter:

// Search up to 3 levels deep
Var results() As SearchUtils.SearchHit = SearchUtils.FindInFiles(myFolder, "TODO", 3)

The Complete Recursive Code

The SearchUtils Module

Module SearchUtils

  Class SearchHit
    Public Property FilePath As String
    Public Property LineNumber As Integer
    Public Property LineText As String

    Public Sub Constructor(filePath As String, lineNumber As Integer, lineText As String)
      Self.FilePath = filePath
      Self.LineNumber = lineNumber
      Self.LineText = lineText
    End Sub
  End Class

  Public Function FindInFiles(targetFolder As FolderItem, searchTerm As String) As SearchHit()
    // Simple usage: depth = 0
    Return FindInFiles(targetFolder, searchTerm, 0)
  End Function

  Public Function FindInFiles(targetFolder As FolderItem, searchTerm As String, maxDepth As Integer) As SearchHit()
    // Recursive usage: maxDepth ( -1 is unlimited )

    Var hits() As SearchHit

    If targetFolder Is Nil Or Not targetFolder.Exists Or Not targetFolder.IsFolder Or searchTerm.IsEmpty Then
      Return hits
    End If

    Try
      SearchFolder(targetFolder, searchTerm, hits, maxDepth)
    Catch error As IOException
      // Skip inaccessible folders
    End Try

    Return hits
  End Function

  Private Sub SearchFolder(folder As FolderItem, searchTerm As String, hits() As SearchHit, maxDepth As Integer)
    Try
      For Each item As FolderItem In folder.Children
        If item Is Nil Or Not item.Exists Or Not item.IsReadable Then Continue

        If item.IsFolder Then
          If maxDepth <> 0 Then
            Var nextDepth As Integer = If(maxDepth > 0, maxDepth - 1, maxDepth)
            SearchFolder(item, searchTerm, hits, nextDepth)
          End If
        Else
          SearchFile(item, searchTerm, hits)
        End If
      Next
    Catch error As IOException
      // Skip inaccessible folders
    End Try
  End Sub

  Private Sub SearchFile(file As FolderItem, searchTerm As String, hits() As SearchHit)
    Try
      Var input As TextInputStream = TextInputStream.Open(file)
      input.Encoding = Encodings.UTF8
      Var lineNumber As Integer = 0

      While Not input.EndOfFile
        Var line As String = input.ReadLine
        lineNumber = lineNumber + 1

        If line.Contains(searchTerm, ComparisonOptions.CaseInsensitive) Then
          hits.Add(New SearchHit(file.NativePath, lineNumber, line))
        End If
      Wend

      input.Close
    Catch error As IOException
      // Skip unreadable files
    End Try
  End Sub
End Module

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!

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

Am I affected? What do I do?

If you only read one section, read this one.

• On Xojo Cloud (Web 1 or Web 2)? You’re covered. Nothing to do.
• Using Lifeboat? Update Lifeboat and redeploy.
• Self-hosted behind Apache or Nginx? Drop in the filtering rule below. If you’re on Web 2, also upgrade to 2026r1.2 if possible.
• Self-hosted with the Xojo app exposed directly? On Web 2, upgrade to 2026r1.2 if possible, otherwise put a reverse proxy in front. On Web 1, put a reverse proxy in front (which is what we’d recommend either way).

The full details follow.

Timeline

• Thursday, the 23rd. A public issue and a private message landed on the same day, both pointing at the same bug.
• Thursday through Monday. We tracked down the root cause, wrote the fix, and tested it.
• Tuesday, the 28th. 2026r1.2 shipped with the patch.
• Wednesday, the 29th. Xojo Cloud patched at the platform level.

Under a week from the report to a patched release, with the platform-level mitigation following the next day.

What Happened

A request with a malformed percent-encoded sequence in a query parameter could crash a running Xojo Web app. The smallest reproducer is something like ?x=%. That’s a % not followed by two hex digits, which is invalid percent-encoding and isn’t decodable.

The bug lives in DecodeURLComponent. When the method ran into invalid input, it raised an exception instead of handling the input gracefully. Because the framework calls this method while parsing incoming requests, anyone could crash a web app by sending a single malformed URL. No authentication, no special headers, no payload. Just a bad query string.

A few things worth being upfront about:

• The bug has probably been there since DecodeURLComponent was introduced. Every Xojo release that ships the method might be affected.
• Both Web 1 and Web 2 are known to be affected. The Web framework has been calling this method on incoming requests across both generations.
• It’s not just a Web problem. DecodeURLComponent is a general-purpose method, and the same crash can happen in Desktop and other project types if you call it on attacker-controlled input. Web is the obvious target because requests arrive from the network, but the underlying issue isn’t Web-specific.

The Fix

In 2026r1.2, DecodeURLComponent no longer crashes on invalid input. Instead, it returns an empty String when the input contains a malformed percent-encoded sequence.

We thought about a few approaches and went with this one on purpose, for being consistent with the other sanity checks we do on this method. An empty return value lets existing code keep running rather than letting an exception bubble up through request handling, which is what you want from a method that’s frequently called on untrusted input. If your code already wraps DecodeURLComponent with its own validation, the new behavior gives you a clean signal to act on (an empty result) instead of an exception to catch.

Xojo 2026r1.2 is the only release with the fix. Web 1 won’t be getting a backported patch. What that means in practice is covered below.

What Xojo has already done for you

Xojo Cloud has been patched at the platform level. As of Wednesday 29th, Xojo Cloud rejects requests with malformed percent-encoding before they ever reach your app, returning a 400 Bad Request from the front-end web server. This protection doesn’t care which Xojo version your app was built with, and it covers Web 1 and Web 2 the same way.

If your app runs on Xojo Cloud, you don’t need to redeploy, upgrade, or change anything. We rolled this out specifically so that users who can’t upgrade right away are covered, including Web 1 users who can’t upgrade to a fixed version at all.

What you should do

The right move depends on which Web version you’re on and where your app runs.

If you’re on Web 2

Upgrade to 2026r1.2 and redeploy if you can. That’s the cleanest fix and it addresses the issue at the source.

We know “just upgrade” isn’t always realistic. You might be on an older version because your license has expired, because a third-party plugin you rely on hasn’t caught up yet, because a newer Xojo release introduced a regression you can’t ship around, or for any number of other reasons. If that’s you, the hosting-based mitigations below will protect your app in the meantime, and they work regardless of which Xojo version you built with.

If you’re on Web 1

There’s no Xojo release that patches DecodeURLComponent for Web 1, so the fix has to live outside your app. The good news is that if you follow Xojo’s standard hosting recommendations, you’re fully covered against this specific issue:

• Stay on Xojo Cloud. You’re already protected.
• Use Lifeboat. Tim Parnell shipped a Lifeboat update that catches malformed percent-encoding before it reaches your app. Update Lifeboat and redeploy.
• Run behind Apache or Nginx with the rules in the next section.

Separately, and on a longer horizon: Web 1 isn’t receiving framework patches anymore in general, so if you’re still on it, this is a reasonable moment to start thinking about a migration to Web 2. That’s a much bigger conversation than this post, but worth flagging.

Hosting-level mitigations

These rules reject malformed percent-encoded URLs at the web server, before the request reaches your Xojo app at all. They work for Web 1 and Web 2, and they don’t depend on the Xojo version you built with.

Apache:

# Reject malformed percent-encoding in the URI.
RewriteCond %{THE_REQUEST} %(?![0-9A-Fa-f]{2})
RewriteRule .* - [R=400,L]

Nginx:

# Reject malformed percent-encoding in the URI.
if ($request_uri ~ "%(?![0-9A-Fa-f]{2})") {
  return 400;
}

Reload your web server after updating the config (apachectl graceful or nginx -s reload) and check that a request like https://yourapp.example.com/?x=% comes back as 400 Bad Request.

These two snippets aren’t the only way to handle this. The goal is just to block malformed URLs before they reach your app, however you do it. If you’re running mod_security, for example, a rule that rejects URIs containing invalid percent-encoding will get you the same result. Same idea for any WAF, edge filter, CDN, or load balancer in front of your stack: catch the bad request, return a 400, move on.

If your Xojo app is exposed directly to the internet

If your Web app is talking to the internet without a reverse proxy in front of it, your options are narrower. On Web 2, upgrade to 2026r1.2 if you can. On Web 1, or on Web 2 if upgrading isn’t an option, you’ll need to put Apache, Nginx, or Lifeboat in front of your app, or move to Xojo Cloud, our managed hosting solution.

This is also a good moment to revisit the setup more broadly. Xojo recommends always serving Web apps behind a web server, both for performance and as a defense-in-depth measure against bugs like this one. A reverse proxy would have neutralized this specific issue before it reached the framework, and it’ll do the same for the next class of issue too.

If you use DecodeURLComponent in a non-Web project

The crash isn’t unique to Web. If you’re calling DecodeURLComponent on input you don’t control (anything coming from a user, a file, a network response, a clipboard), the same bug can hit a Desktop, Console, or other project type.

Upgrade to 2026r1.2 if you can; that’s the proper fix.

If you can’t upgrade, you’ll need to sanitize the input yourself before calling DecodeURLComponent. The check is simple in principle: every % in the string must be followed by exactly two hexadecimal characters (0-9, A-F, a-f). If any % doesn’t meet that condition, treat the input as invalid and don’t pass it to DecodeURLComponent. A small helper that validates the string up front and either returns early or substitutes an empty value will keep your app from crashing on the same kind of malformed input that triggers the Web bug.

Acknowledgments

Thanks to the user who reported this through both public and private channels. That’s exactly the kind of disclosure that lets us turn a fix around in under a week. Thanks also to Tim Parnell for the fast Lifeboat update, which gave self-hosted users a drop-in mitigation almost immediately.

If you find a security issue in Xojo, please report it privately. You can email support@xojo.com or file a confidential issue on the issue tracker. Both reach us, and either one lets us get a fix out before the details become public, protecting the rest of the users.

References

• Release notes for 2026r1.2

Ricardo has always been curious about how things work. Growing up surrounded by computers he became interested in web technologies in the dial-up connections era. Xojo has been his secret weapon and language of preference since 2018. When he’s not online, chances are he will be scuba diving … or crocheting amigurumis. Find Ricardo on Twitter @piradoiv.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

Specifically, the following properties can be used there:

• Graphics.FontName
• Graphics.FontSize
• Graphics.FontAscent

These properties are known from other Xojo targets (e.g. Desktop), but are not part of the official mobile API and are not shown in Autocomplete. They cannot be used outside of this event.

In contrast, the mobile API property Graphics.Font cannot be used within the DrawControlInLayoutEditor event. The usage is strictly limited to the DrawControlInLayoutEditor event. Using these properties in runtime code will result in errors.

These properties allow for more accurate text rendering in the layout editor, for example in custom controls where font metrics need to be considered.

Although these properties are not part of the mobile API, they can be used selectively within the layout editor context.

This code will work fine in your mobile control’s DrawControlInLayoutEditor event:

Var s As String = "Happy coding!"
Var x As Double = g.Width / 2 - g.TextWidth(s) / 2
Var y As Double = g.Height / 2 - g.TextHeight / 2 + g.FontAscent

g.DrawingColor = Color.Red
g.DrawOval(0, 0, g.Width, g.Height)

g.DrawingColor = TextColor
g.Bold = True
g.FontName = "Times New Roman"
g.FontSize = 16
g.DrawText(s, x, y)

Happy coding!

Martin T. is a Xojo MVP and has been very involved in testing Android support.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

Though he started his development journey on Windows machines, after a seven-year spell at SAIC Ltd. (Science Applications International Corp), Paul decided he wanted to move to Apple computers and started looking for a VB/Access replacement. That’s how he discovered Xojo and built a suite of applications that managed multiple aspects of his hire-boat business, overseeing 17 boats on the British Canal System. Even in retirement, he remains actively coding in 2026.

Mac, Windows or Linux?

Mac.

How did you find Xojo? And when did you start using Xojo?

I started in 2000 with RealBASIC. I needed a database/programming combination to run my boat yard and hire boat business on the British Canal system. I went for RealBASIC and FrontBase database, it was fast reliable and very stable. It enabled me to create a suite of about 10 programs for renting the boats, doing the maintenance, tracking sales and running the cafe. The applications managed the bookings for 17 boats which operated on a varied pattern of 3, 4, 7 and 14 night holidays. The progams stored the bookings, printed the legal documents required at the start of each trip and logged the fuel usage and engineering routines.

Do you earn a living with Xojo?

No, but my business would not have run without it.

Xojo isn’t the only tool in your kit. What is a piece of software more people should know about?

A good knowledge of a database which interfaces well with Xojo is useful. I interfaced my early applications with FrontBase but the plugin does not exist now. I moved to PostgresSQL, it was a bit different at first, but the new AddROW instruction in Xojo has really streamlined my apps.

Which three Xojo language features or framework capabilities do you find yourself relying/using on the most?

My three main items are Listbox, Graphics – items loading pictures and drawing on top of the picture, and the database plugins. Shame we lost FrontBase but PostgreSQL seems to suite me almost as well.

What do you build with it now?

I currently help a very good friend who owns a canal boat marina in the heart of the UK, sadly he uses Windows machines and some rather clunky Access database applications, I would love to get my hands on them!

How would you explain your most recent project to a new developer?

I wanted to maintain a visual display of the boats in a marina and track the ownership and movements of the boats. Initially, I created a Listbox to display the database table which allowed me to count and record vessel details. But I wanted to visualise the position and load it as a picture. Using the DesktopBevelButton, I recorded the position on the plan. They are the red and green squares along the edge of the piers and clicking on an individual location fetches the boat data. I am now looking to locate all the technical resources electric and water points and pontoon detail for our service and engineering crew.

Do you use it for any hobbies?

At nearly 80 I just enjoy the mental exercise, but I still build games for my granddaughter and things to help at the office where I do some administration. I retired and sold the business, but I do some part-time work at a canal marina where we live. Using Xojo and PostgreSQL I am developing a visual boat management system. We moor nearly 200 boats of varying lengths on pontoons of varying lengths! A real juggling job!

What’s your biggest Xojo success?

Sticking with it for such a long time, all through changing RECORDSET to ROWSET, and how simple INSTR grew. I mastered the new graphics methods after much effort – but I did it!

If you were introducing Xojo to a friend, which three words would you use to describe it?

Flexible, fast with great technical backup when you need it.

Thank you to Paul Garfield for answering questions and sharing his Xojo experience with the community. If you have an app, a project or a person you want to see featured in Spotlight On, tell us about it!

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

In total, more than 60 new declares have been added for MobileSlider, allowing you to control virtually every UI parameter of the control—whether it’s the shape of the thumb, its color, the track colors (both for the active/left and inactive/right portions), and much more. You can also set the step size, similar to what you’re used to on the desktop.

Just take a look at the updated Android Design Extensions demo app and try it out.

Feel free to take a look at the developer repository, create feature requests, and provide feedback on extending this extension library. I’m happy to receive any voluntary financial support for the work I’ve done so far, which you are welcome to share here. You can download the project with many examples at https://github.com/XojoGermany/AndroidDesignExtensions.

Happy coding!

Martin T. is a Xojo MVP and has been very involved in testing Android support.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

Now, that we already know all the pieces involved in this particular puzzle (certificates, sandboxing, notarization, hardened runtime, etc.), the question to answer is…

What kind of macOS code signing do you want to do today?

Apple developer certificates installed on your Mac determine the kind of code signing and, thus, the distribution options available for your macOS app. They can also support certain macOS security requirements that distribution methods or features may impose, such as entitlements or provisioning profiles.

This diagram can help determine these based on the certificate used when signing the app, so you can get a better idea:

As a practical summary:

• Ad-Hoc signing / None: This option makes sense primarily when you’re developing and running or debugging the app on your Mac or on the same computer, since it typically doesn’t require special entitlements or provisioning profiles.
• Apple Developer / Development. Using this certificate enables sandboxing, hardened runtime, entitlements and provisioning profiles even when debugging from the IDE or testing the build on your own computer. It offers a better experience, but you won’t be able to notarize it or bypass the Gatekeeper barrier if distributed to other users.
• Developer ID Application / Direct Distribution. With this certificate, you can notarize your app so Gatekeeper won’t block distribution outside the Mac App Store. When debugging from the IDE, entitlements and provisioning profiles (if needed) are applied as well, along with optional sandboxing.
• Apple Distribution / App Store. Use this certificate when the app has been tested and it is ready to be sent to App Store Connect… or even when you’re planning to send it to the App Store Connect so a group of beta-testers can test it using Apple’s TestFlight.

How the Xojo IDE helps with all of this?

We have been adding features to the Xojo IDE to make code signing and distributing your macOS apps an easier and leaner process; most of these are available under Build Settings > macOS > Sign:

Developer ID – Build For

This is the most recent addition to better deal with the first, and most important, piece of the puzzle: handling certificates! Instead of having to go back and forth between the Keychain Access and the Xojo IDE to copy/paste the expected data from the certificates for the kind of build or distribution you plan for the app, you can now find under the Developer ID field all the available Developer Teams (usually just yours) and, when a Developer Team is selected, the “Build For” popup menu will be populated with the available options for builds/distributions based on the installed developer certificates for that team.

When all the Apple developer certificates are properly installed for a given Developer Team, the available options will be: Development, Direct Distribution and App Store (plus None, meaning Ad-Hoc signing).

If you find that some of these options are missing from the “Build For” popup menu, that means the corresponding certificate is not installed or there is some kind of issue with that certificate (maybe it has expired or has its private key missing). In those cases, we included the “Inspect…” option under the “Developer ID” popup menu. Selecting Inspect lets you gain a better picture about everything related to your Apple developer certificates and even get advice about how to fix the most common issues.

Sandboxing

Enable this feature if you plan to debug, build, or distribute your app as a sandboxed app. In that case, the associated editor will make it even easier to enable the sandboxing features that may apply to your particular app. The IDE will take care of all the rest. Note that, while sandboxing was previously only applied to built/distributed macOS apps in previous Xojo releases, starting with Xojo 2026r1 it is also applied when the app is being debugged from the IDE.

Hardened Runtime

Enable this option mainly for apps meant to be built and/or distributed using Direct Distribution or the App Store options. While this is optional when distributing it via the Mac App Store, it is still highly recommended to enable it for that scenario.

When the app is debugged from the IDE, the hardened runtime won’t be applied even if it is enabled… mainly so you can debug it!

As with sandboxing, the hardened runtime option also includes its own editor to make your app-specific selections easier. The IDE will take care of the under the hood processing when the app is built.

Notarization

If you haven’t started notarizing your macOS apps yet, now is the time! This will be possible only with the Direct Distribution option (equivalent to the Developer ID Application Certificate) and implies enabling hardened runtime. When you enable notarization, the associated hardened runtime will be enabled for you, even if you don’t select additional option from its editor.

Notarization requires the use of what Apple calls an App-Specific Password, which you can set up by following the steps found in the window that appears when the associated Setup button is clicked.

Once everything has been setup, the notarization process will happen the next time the app is built. Note, the notarization process will not take place when the app is debugged from the IDE (as with hardened runtime); you don’t need to specifically disable that option.

Entitlements

The combination of certain certificates, build, and distribution options you choose for your app may require you to set a series of entitlements; for example, when enabling sandboxing and/or hardened runtime. Additionally, with Xojo 2026r1 it is possible to attach your built or debugged apps to Xcode Instruments for further inspections beyond the current capabilities of Xojo’s debugger.

In all of the above scenarios, Xojo will take care of the required entitlements without you needing to notice it; but if your app also makes use of some features that require adding extra entitlements (and probably a matching provisioning profile), as happens with most of the Apple specific services such as iCloud, Keychain, In-App Purchases, etc., you will need to craft the corresponding .plist file for them and add it using the User Entitlements option. These entitlements will be combined with the ones automatically generated by Xojo and included in the app during the code signing process.

Provisioning Profiles

On macOS, provisioning profiles are supported by a Copy Files build step, which requires selecting Contents as the destination folder. Not ideal, but that way you can select what kind of provisioning profile you want to apply to builds or when debugging your project (this is a new feature starting with Xojo 2026r1).

Property List Editor

The ability to add your own property list entries to the compiled/distributed macOS app is enhanced by a complete Property List Editor available under Build Settings > macOS since Xojo 2025. It makes it easier to create these entries and even save them for reuse in other projects.

The entries you add with the Property List Editor will be combined with those automatically generated by the IDE, or with entries that may have been added to the project using previous methods (such as adding an external .plist file to the Project Navigator sidebar).

Publishing to the Mac App Store

While there are some steps that need to be done both at Apple’s Developers Portal and App Store Connect Website, you will be able to set your app category directly from the IDE under Build Settings > macOS.

In addition, the Publish feature (responsible for sending your app to App Store Connect) will be in charge of verifying that the project meets everything that Apple requires prior to send it for reviewing or making available through TestFlight.

In order for the Publish button to be enabled, you need to select the App Store option for the selected “Developer ID” Team from the “Build For” popup menu under Build Settings > macOS > Sign.

Dealing with Certificates Issues

It doesn’t matter if your app requires entitlements, provisioning profiles, or if you are going to notarize it or enable sandboxing plus hardened runtime. All of this is based on the signing of your developer certificates, so let’s go back and see how to deal with the most common issues related with these.

Backup Your Certificates

Once you have installed your certificates, the first thing you should do is export them from Keychain Access to a secure place (ideally, not in your computer but an external USB key or drive). Why? Here’s why:

1. Apple only allows you to create certificates a maximum of five times per year (mostly because they expire after one year, as we did see in a previous entry). Every time you install certificates, whether on the same computer or a different Mac you own, they count as new certificates, with different serial numbers and SHA1/SHA256 data. In practice, this reduces the number of installations available per year.
2. In addition, some features, like provisioning profiles, rely on the specific certificates selected during their creation. You will get a signing error if you build the app on a Mac with different certificates.
3. If you need to restore your Mac or migrate to a new Mac, your certificates won’t be restored using the usual tools from Apple. Having a backup of your developer certificates will make easier to restore them in Keychain Access after restoring your computer or when you change to a new Mac.

Instead of using Xcode to install new certificates on every Mac you intend to use for code signing, install them on just one Mac, export them from that Mac, and import them into the Keychain Access app on your other Macs. This ensures all of your Macs will use the same certificates.

Review Pending Apple Developer Agreements

This is one of the most common issues related to code signing: it just stops working and you don’t know why and even the returned error messages doesn’t reveal why. If you’re sure you have the required developer certificates installed, they are valid (not expired), and don’t have any other issues then it is time to sign-in into the Apple Developer and App Store Connect portals to check if there are some pending agreements you need to accept.

Missing and Expired Certificates

This is another very common issue. Starting with Xojo 2026r1, we made easier to detect this situation. If a given certificate for your team is not installed, then you won’t be able to select the signing option from the “Build For” popup menu under Build Settings > macOS > Sign. You can further dig into it selecting the “Inspect…” option from the “Developer ID” popup menu, and even receive some advice on how to fix it!

Certificates are all good… but the signing throws errors

When using the Direct Distribution or App Store options, the code signing process uses Apple Time Servers to add the date and time as part of the signing. That means that the computer requires an active Internet connection, and that such time servers must be reachable from Apple’s side (it’s very rare for them to be down).

Other operations such as notarization and publish also require an active Internet connection, and the corresponding Apple services must be up and running. Some times these can be down.

When these issues occur, it is a good idea to check the Apple Services status webpage.

In summary

It’s been a long four-article ride with the aim of giving you a clearer understanding of what happens under the hood when you code sign your macOS apps, what kind of certificate you need for a given distribution, and which macOS security features are supported by Development, Developer ID Application or Apple Distribution certificates; and, most importantly, how Xojo helps you with all of it!

I’d love to hear about your experience with macOS code signing, the rough corners you still need to tackle, and other improvements you would welcome. The Xojo forums are a great place to keep the conversation going!

Happy macOS code signing with Xojo!

Javier Menendez is an engineer at Xojo and has been using Xojo since 1998. He lives in Castellón, Spain and hosts regular Xojo hangouts en español. Ask Javier questions on Twitter at @XojoES or on the Xojo Forum.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

Code Signing on macOS: What Developers Need to Know

• Part 1, Get Started
• Part 2, Code Signing With Developer Certificates
• Part 3, Entitlements and Provisioning Profiles
• Part 4, How Xojo helps with Certificates, Signing and Distribution

First, I’m going to create a headless desktop application. A console application would work, but shows a command box.

In the Xojo IDE, create a new desktop project and delete Window1 and MainMenuBar. Then add the Opening Event Handler to App and add this code:

Self.AllowAutoQuit = True

This will allow the application to quit when done.

Add the DocumentOpened Event Handler to App and add this code:

If item _ ' Using item
 .NativePath _ ' property NativePath
 .NthField(":", 1) <> "AlertDemo" Then ' Compare the value left of the ":"
 Return ' If invalid return (quit)
End If
Var alert As String ' Define the variable
alert = item _ ' Using Item
 .NativePath _ ' property NativePath
 .NthField(":", 2) ' Extract the contents to the right of the ":"

alert = DecodeURLComponent(alert) ' Convert the content to plain text
MessageBox(alert) ' Show the alert
' The app will now quit

To test you can select Shared in Build Settings.

And enter a value into Command Line Arguments:

Running the app in debug mode will show:

Now build the project and create an installer using Inno Setup.

[Setup]
AppId={{B4D9ABDA-9F58-4FE0-A5F3-3E39C28EAB59}
AppName=Alert Demo
AppVersion=1.0
DefaultDirName={commonpf64}\Axis Direct Ltd\Alert Demo
DefaultGroupName=Axis Direct
OutputDir=C:\Xojo Projects\Alert Demo\Installer
OutputBaseFilename=AlertDemoInstaller
Compression=lzma
SolidCompression=yes
ChangesEnvironment=yes
[Languages]
Name: "english"; MessagesFile: "compiler:Default.isl"
[Tasks]
[Dirs]
Name: "{app}\Alert Demo Libs"
[Files]
Source: "C:\Xojo Projects\Alert Demo\Project\Builds - Alert
Demo\Windows 64 bit\Alert Demo*"; DestDir: "{app}"; Flags:
ignoreversion
Source: "C:\Xojo Projects\Alert Demo\Project\Builds - Alert
Demo\Windows 64 bit\Alert Demo\Alert Demo Libs*"; DestDir:
"{app}\Alert Demo Libs"; Flags: ignoreversion
[Icons]
[Run]
[Registry]
Root: HKCR; Subkey: "AlertDemo"; Flags: uninsdeletekey
Root: HKCR; Subkey: "AlertDemo"; ValueType: "String";
ValueData: "URL:AlertDemo Protocol"; Flags: uninsdeletekey
Root: HKCR; Subkey: "AlertDemo"; ValueName: "URL Protocol";
ValueType: "String"; ValueData: ""; Flags: uninsdeletekey
Root: HKCR; Subkey: "AlertDemo\shell"; Flags: uninsdeletekey
Root: HKCR; Subkey: "AlertDemo\shell\open"; Flags:
uninsdeletekey
Root: HKCR; Subkey: "AlertDemo\shell\open\command"; Flags:
uninsdeletekey
Root: HKCR; Subkey: "AlertDemo\shell\open\command";
ValueType: String; ValueData: "{app}\Alert Demo.exe %1";
Flags: uninsdeletekey

The registry section creates the registry entries per William’s blog post.

Now that the application Is installed, we’ll look at the Web Application. For the sake of testing, I’m just adding a Button to a WebPage and adding the following code into the pressed event.

Var s As String = "Hello World"
Var Alert As String
Alert = EncodeURLComponent(s) ' Make the string URL safe
GoToURL("AlertDemo:" + Alert, True) ' Launch the app in a new tab

And that is it!

For printing a docket, I would pass a unique identifier for the transaction using this method then access the data using URLConnection & HandleURL.

Wayne Golding has been a Xojo developer since 2005 and is a Xojo MVP. He operates the IT Company Axis Direct Ltd which primarily develops applications using Xojo that integrate with Xero www.xero.com. Wayne’s hobby is robotics where he uses Xojo to build applications for his Raspberry Pi, often implementing IoT for remote control.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

What Is Conditional Compilation?

Conditional compilation allows you to include or completely exclude sections of code from the final application based on a condition. Unlike an If statement at runtime, this decision is made at compile time. Code excluded through conditional compilation simply does not exist in the compiled application.

#If False – Completely Excluding Code

#If False
  MessageBox("This line will never be compiled")
  Var result As Integer = DoSomething()
#EndIf

When the condition is False, the entire block is ignored by the compiler. It is not compiled, not included in the application, and not even checked for syntax errors. The code is effectively invisible to the compiler.

Why Not Just Comment It Out?

At first glance, #If False seems to do the same thing as a comment. But there are key differences:

1. Nested Comments Are No Problem

If a code block already contains comments, commenting out the entire block quickly becomes messy:

' Var x As Integer = 42 ' Default value
' Var y As Integer = x * 2 ' double it
' ' This is already a comment

With #If False, everything stays clean:

#If False
  Var x As Integer = 42 ' Default value
  Var y As Integer = x * 2 ' double it
  ' This is already a comment
#EndIf

2. Incomplete or Broken Code

Sometimes you want to keep an unfinished code draft without it preventing the build. Since the compiler completely skips the contents of an #If False block, the code inside may even contain syntax errors:

#If False
  ' Experimental approach – not finished yet
  Var data As  = LoadFromServer(
  ProcessResult(data
#EndIf

This code would be useless as a comment because you’d have to comment out each line individually. With #If False, it’s safely stored away.

3. Quickly Disabling Large Code Blocks

For larger sections, #If False / #EndIf is far more practical than prefixing every line with '. Plus, the block can be reactivated instantly by simply changing False to True.

#If True – Always Including Code

#If True
  MessageBox("This line will always be compiled")
#EndIf

An #If True block is always compiled — it behaves identically to regular code. This might sound useless at first, but it does have practical applications.

When Is #If True Useful?

1. Quick Toggling During Development

Imagine you’re working on a feature and want to quickly enable or disable certain code sections:

#If True ' <- Set to False to disable the new feature
  ' New feature
  Var service As New CloudSyncService
  service.SyncNow()
#EndIf

By simply changing True to False, you can disable the feature without deleting or commenting out any code.

2. Placeholder for Future Conditions

Sometimes you already know that a code section will later be tied to a condition — such as a platform or build type. With #If True, you can prepare the structure in advance:

#If True ' TODO: Change to TargetMacOS once Windows alternative is ready
  Var folderPath As String = SpecialFolder.Applications.NativePath
#EndIf

3. Visual Code Grouping

In longer methods, #If True can serve as a visual structural block to highlight related code:

#If True ' --- Initialization ---
  Var db As New SQLiteDatabase
  db.DatabaseFile = dbFile
  db.Connect
#EndIf

#If True ' --- Load data ---
  Var rs As RowSet = db.SelectSQL("SELECT * FROM users")
#EndIf

Defining Custom Compiler Constants

Xojo also allows you to define your own constants for conditional compilation.

#If kEnableLogging
  WriteToLog("Application started")
#EndIf

This lets you control features or debug functionality centrally through a constant without having to modify the code itself.

Best Practices

1. #If False instead of mass comments: For larger code blocks that need to be temporarily disabled, #If False is the cleaner solution.
2. Add a comment: Always document why a block is disabled:

#If False ' Disabled until bug #1234 is fixed
  ProcessCriticalData()
 #EndIf

3. Don’t use permanently: #If False blocks should not remain in the code indefinitely. If the code is no longer needed, remove it. If it is needed, activate it.
4. Prefer platform directives: When dealing with platform-specific code, use the specific constants (TargetMacOS, TargetWindows, etc.) instead of #If True or #If False.
5. Avoid deep nesting: While nested #If blocks are possible, use them sparingly as they quickly reduce readability.

Conclusion

#If False and #If True are simple yet powerful tools for everyday Xojo development. They offer a cleaner alternative to commenting out large code blocks, enable quick feature toggling during development, and lay the groundwork for a structured, cross-platform codebase. Used thoughtfully, they save time and help you stay organized — even in larger projects.

If you want to automatically convert a selection into a #If/#EndIf block, you can do so via the context menu: “Wrap In > #If / #EndIf”

Happy coding.

Martin T. is a Xojo MVP and has been very involved in testing Android support.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

In this post, we’ll build a simple Find in Files utility in Xojo that:

• searches the files in a folder
• reads each file line by line
• performs a plain-text, case-insensitive match
• returns the file path, line number, and matching line

The goal is simple: build something useful while leaving the door open for the fancier stuff.

What this Find in Files function will do

Let’s keep the scope clear:

• search one folder
• search plain text only
• skip subfolders for now
• return the matching file path, line number, and line contents

Step 1: A class in a module and some properties

Before touching the file system, let’s define what a match looks like.

You could return raw strings, but that gets messy fast. A small class keeps the code readable and gives us an obvious place to extend later. In this version, I like keeping that class inside the same module as the search function. It keeps the entire utility self-contained instead of spraying helper types all over the project.

So, we start by adding a module SearchUtils and inside the module we will add a class SearchHit.

Module SearchUtils

  Class SearchHit

    Public Property FilePath As String
    Public Property LineNumber As Integer
    Public Property LineText As String

    Public Sub Constructor(filePath As String, lineNumber As Integer, lineText As String)
      Self.FilePath = filePath
      Self.LineNumber = lineNumber
      Self.LineText = lineText
    End Sub

  End Class

End Module

Each result stores three things:

1. the file path
2. the line number
3. the matching line

Step 2: Walk through the folder

FolderItem.Children lets us loop through a folder with a For Each loop, which keeps the code clear.

We’ll also reject bad input early:

• the folder is Nil
• the folder does not exist
• the item passed is not actually a folder
• the search term is empty

This process is simple, fast and effective.

Step 3: Read files line by line

For text files, TextInputStream.Open is the right tool. From there, we can call ReadLine until EndOfFile becomes True.

I prefer this over ReadAll for a utility like this. ReadAll is fine when the file is small and you know what you’re doing, but line-by-line reading is a better default here. It keeps memory use in check and gives us line numbers for free.

For the sample code, I’m explicitly using UTF-8:

input.Encoding = Encodings.UTF8

That keeps the sample predictable. It does not mean this code can gracefully decode every text file you throw at it. Files with unknown encodings or binary-ish content are a separate problem, and they deserve their own solution.

Step 4: Match the text

For a plain-text search, String.Contains does exactly what we need:

line.Contains(searchTerm, ComparisonOptions.CaseInsensitive)

It handles the case-insensitivity without the overhead, or the headache, of regex.

Step 5: The full module and class and function

Module SearchUtils

  Public Class SearchHit
    Public Property FilePath As String
    Public Property LineNumber As Integer
    Public Property LineText As String

    Public Sub Constructor(filePath As String, lineNumber As Integer, lineText As String)
      Self.FilePath = filePath
      Self.LineNumber = lineNumber
      Self.LineText = lineText
    End Sub
  End Class

  Public Function FindInFiles(targetFolder As FolderItem, searchTerm As String) As SearchHit()
    Var hits() As SearchHit

    If targetFolder Is Nil Then
      Return hits
    End If

    If Not targetFolder.Exists Or Not targetFolder.IsFolder Then
      Return hits
    End If

    If searchTerm.IsEmpty Then
      Return hits
    End If

    For Each item As FolderItem In targetFolder.Children
      If item Is Nil Then Continue
      If item.IsFolder Then Continue
      If Not item.Exists Then Continue
      If Not item.IsReadable Then Continue

      Try
        Var input As TextInputStream = TextInputStream.Open(item)
        input.Encoding = Encodings.UTF8

        Var lineNumber As Integer = 0

        While Not input.EndOfFile
          Var line As String = input.ReadLine
          lineNumber = lineNumber + 1

          If line.Contains(searchTerm, ComparisonOptions.CaseInsensitive) Then
            hits.Add(New SearchHit(item.NativePath, lineNumber, line))
          End If
        Wend

        input.Close

      Catch error As IOException
        ' Skip files that cannot be read as text.
        Continue
      End Try
    Next

    Return hits
  End Function

End Module

How it works

Let’s break down the important parts.

Input validation

This block prevents pointless work and avoids avoidable runtime problems:

If targetFolder Is Nil Then
  Return hits
End If

If Not targetFolder.Exists Or Not targetFolder.IsFolder Then
  Return hits
End If

If searchTerm.IsEmpty Then
  Return hits
End If

Rule of thumb: reject bad input early.

Folder iteration

This is the core loop:

For Each item As FolderItem In targetFolder.Children

We’re only scanning the folder’s immediate contents. If an item is another folder, we skip it.

If item.IsFolder Then Continue

Safe text reading

Each file is opened with TextInputStream.Open inside a Try...Catch block:

Try
  Var input As TextInputStream = TextInputStream.Open(item)
  input.Encoding = Encodings.UTF8
  ...
Catch error As IOException
  Continue
End Try

That way, one unreadable file does not take down the whole search. It gets skipped and the rest of the folder still gets processed.

Line-by-line matching

This is where the actual work happens:

While Not input.EndOfFile
  Var line As String = input.ReadLine
  lineNumber = lineNumber + 1

  If line.Contains(searchTerm, ComparisonOptions.CaseInsensitive) Then
    hits.Add(New SearchHit(item.NativePath, lineNumber, line))
  End If
Wend

Because we’re reading one line at a time, attaching the correct line number is trivial.

Why keep SearchHit inside the module?

Because it belongs to this utility. The search function and its result type are part of the same little unit of behavior, so keeping them together makes the project easier to scan and easier to transform it to a Library.

It also means code outside the module uses the namespaced type:

Var results() As SearchUtils.SearchHit = SearchUtils.FindInFiles(folder, "xojo")

Using the function

Here’s a simple example that lets the user choose a folder and then writes the results to the debug log:

Var folder As FolderItem = FolderItem.ShowSelectFolderDialog
If folder Is Nil Then Return

Var results() As SearchUtils.SearchHit = SearchUtils.FindInFiles(folder, "error")

For Each hit As SearchUtils.SearchHit In results
  System.DebugLog(hit.FilePath + " | line " + hit.LineNumber.ToString + " | " + hit.LineText)
Next

If you want to display the results in a DesktopListBox, that works nicely too:

Var folder As FolderItem = FolderItem.ShowSelectFolderDialog
If folder Is Nil Then Return

Var results() As SearchUtils.SearchHit = FindInFiles(folder, "error")

ListBox1.RemoveAllRows
ListBox1.ColumnCount = 3

For Each hit As SearchUtils.SearchHit In results
  ListBox1.AddRow(hit.FilePath)
  ListBox1.CellTextAt(ListBox1.LastAddedRowIndex, 1) = hit.LineNumber.ToString
  ListBox1.CellTextAt(ListBox1.LastAddedRowIndex, 2) = hit.LineText
Next

A few sample results might look like this:

C:\Logs\app.log | line 18 | Error connecting to database
C:\Logs\app.log | line 42 | Error writing audit record
C:\Configs\service.txt | line 7 | Last error message: timeout

Practical limitations of this version

This utility is useful, but limited.

It assumes UTF-8

That is fine for plenty of modern text files, but not all of them. If you’re dealing with mixed encodings, you’ll need a smarter approach that detects the file encoding.

It doesn’t recurse into subfolders

That is deliberate. Recursive search is useful, but it adds another layer of behavior and another place to make the code harder to read.

Final thoughts

A basic Find in Files function is one of those utilities that looks small but pays off quickly. This is a base-layer utility. Once you have this working, adding recursion or regex is a much smaller lift.

Let’s discuss in the forums.

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!

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

That’s why Xojo is still here: relentless adaptation.

Back when Xojo was REALbasic, version 1.0 only supported MacOS 8/9 and the 68000 and PowerPC processors. Since then we have seen countless changes in the computer technology landscape. Classic MacOS, Windows NT, Windows 95, Internet Explorer 6, Early versions of GTK on Linux, diskettes, and spinning hard drives are now ancient technology.

Xojo itself has changed dramatically over time as well. Though the basic idea of it, that you should be able to quickly and easily both learn Xojo and build apps, has not changed. Some code from an example project back then would be recognizable to a Xojo user today. Assigning variables, conditional statements, loops, even many classes like Graphics, FolderItem, TextInputStream, would all look familiar. That said, almost everything else has changed:

• The IDE was originally written in C++. It is now written in Xojo.
• There entire Xojo framework was originally written in C++. Today it’s a big blend of languages including quite a bit of Xojo.
• It originally had a single pass compiler. The entire compilation process has been rewritten. It is a modern, two-pass system that uses LLVM as its backend.
• REALbasic v1 could only produce desktop apps for MacOS 8 and 9 running on 68000 and PowerPC processors. Today, Xojo supports x86 and ARM processors, desktop apps for Linux, MacOS and Windows, mobile apps for Android and iOS and web apps.
• The documentation was originally almost entirely in printed form. It cost $30, weighed 49 ounces (just over 3 lbs.) and we shipped it to you right from our office. Now, the documentation is all online.
• The way users reported bugs and made feature requests has changed several times over the years.
• The community formed in mailing lists, and occasional Xojo events, now exists on our online forum.

And that adaption continues. We improve the frameworks with each release. We have added the ability to build Libraries. We are working on making web apps more responsive. We are continuing our march towards updating the Windows framework to WinUI. We are making changes to the Xojo IDE so that you can use AI tools such as Anthropic’s Claude Code, Google’s Gemini Code Assist, and Open.AI’s Codex, which, coincidentally, was almost the name we chose for what is now Xojo.

Companies survive by adapting, and Xojo, Inc. is no exception. Over the years we’ve changed everything from offices, personnel, and policies. While the team has changed over the years, many members have been with the company a very long time. In the tech industry, the average turnover is 2 to 3 years. Over the last 30 years, our average turnover is 7 years. Counting current team members, however, it’s a whopping 16.6 years! And among the current engineering team, there are 136 person-years of development on Xojo. We started working out of my apartment, then my house and then into an office here in Austin, Texas. Over time, about half of us found we were working from home a lot, so we decided to go entirely remote in 2008. We have changed many of our internal policies to make Xojo a great place to work. Every member of the Xojo team works so well together that it makes coming to work every day genuinely rewarding.

In general, only about 5% of businesses last 30 years. In tech it’s closer to 1%. It’s an honor to be a member of the tech industry’s 1% club!

What drives all of us at Xojo is helping you turn what started as an idea, into reality. We couldn’t have done it without all the dedicated Xojo users. That some of you have been with us for the entire journey, so far, is especially gratifying.

On behalf of the entire team, thank you for making Xojo possible.

Geoff Perlman is the Founder and CEO of Xojo. When he’s not leading the Xojo team he can be found playing drums in Austin, Texas and spending time with his family.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

In this release, Jade’s output has been improved to limit scrolling when responses are shown, making it easier to read through the specific information and code samples. In addition, Jade now does a better job of parsing the results it gets, which prevents situations where responses could sometimes get cut off.

Lastly, Jade has had some fixes to improve reliability and has been updated to use Anthropic Claude Sonnet 4.6 for more detailed and accurate responses.

These improvements may be small, but they allow Jade to continue to be a helpful Xojo coding assistant.

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.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

With this feature you can provide custom drawing for a control at design time, making it easier to visualize your UI without running the project.

If this sounds familiar, it’s because it brings Desktop and iOS/Android projects closer to what’s already possible in Web projects with WebSDKUIControl, where custom layout rendering has been available for some time.

Why this matters

Previously your custom Canvas controls would appear as generic placeholders, making it difficult to understand how they would look at runtime. Now you can:

• Render a preview of your control directly in the layout editor
• Display dynamic or state-based visuals
• Make custom controls much easier to work with at design time

How it works

For Desktop projects, you can subclass DesktopUIControl and implement the DrawControlInLayoutEditor event. Your drawing code is executed by the IDE as it renders the control in the layout. For iOS and Android projects, this event is available on MobileUIControl.

You can also use this event directly with DesktopCanvas and MobileCanvas controls, so you can start drawing in DrawControlInLayoutEditor without needing to subclass anything.

This event gives you the flexibility to draw whatever you need—shapes, text, or even simplified representations of runtime content. For example, a custom media player control could display a play button and timeline, or a chart control could render a sample graph.

A note about XojoScript limitations

One important detail to keep in mind is that DrawControlInLayoutEditor runs using XojoScript. This allows the IDE to safely execute your drawing code at design time, but it also means not everything you’d typically expect to use in Xojo is available, especially when it comes to the graphics APIs.

In practice, most common drawing operations—such as shapes, lines, and text—work as expected. However, in some cases these graphics calls use a slightly different API, as is the case with LinearGradientBrush.

Also, because this runs as XojoScript, you cannot call other methods from within your DrawControlInLayoutEditorcode. To access your control’s properties, you’ll need to use the built-in  ColorProperty, BooleanProperty, IntegerProperty, DoubleProperty, and StringProperty methods.

Support for more Graphics

In 2026r1, we’ve expanded the graphics capabilities available to DrawControlInLayoutEditor, building on what was previously supported for WebSDKUIControl. New additions include support for:

• LinearGradientBrush, PictureBrush, and ShadowBrush
• LineDash, LineDashOffset, LineCap, LineJoin, and MiterLimit
• Outline
• Scale, Rotate, and Translate
• SaveState, RestoreState
• Color constants (Red, Green, Blue, Yellow etc.)

Since XojoScript does not support the Pair type, the LinearGradientBrush API was adapted slightly:

Class LinearGradientBrush

  Sub Constructor()

  Sub AddStop(stop As Double, c As Color)

  Property StartPoint As Point
  Property EndPoint As Point

End Class

The main difference is how the brush is constructed and how stops are added, without needing Pair. With this new API, you can turn a basic graph into something much more visually appealing.

Turning off this feature

While many may prefer custom rendering for custom controls, it can become a bottleneck when a large number of controls are rendering content. If you prefer a less resource-intensive experience, you can disable this behavior in Settings → Layout by enabling the Static Rendering option.

Finally

With DrawControlInLayoutEditor now available for Desktop and Mobile projects, you can take advantage of the same benefits Web projects have enjoyed for years. Be sure to check out the new DrawControlInLayoutEditor example project, adapted from the WebSDK → CustomButton example. We hope you enjoy designing and previewing your custom controls with this new event—and yes, it also works in Libraries!

William Yu grew up in Canada learning to program BASIC on a Vic-20. He is Xojo’s resident Windows and Linux engineer, among his many other skills. Some may say he has joined the dark side here in the USA, but he will always be a Canadian at heart.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

MobileChart

Matching the features available for iOS, MobileChart lets you create a wide variety of charts to show in your Android app.

MobileColorPicker

This new control, as its name suggests, lets you use the system color picker to select a color.

MobilePDFViewer

Last year Android added PDFDocument support for creating your own PDFs, and now we’ve added MobilePDFViewer to give you an easy way to show PDF document files from your Android apps.

Zip/Unzip

The FolderItem class now supports the Zip and Unzip methods to make it simple to compress and uncompressed Zip files.

Android Keeps Getting Better

There are also improvements to MobileTabPanel, MobileTextArea, MobileSlider, MobileScrollableArea, Barcode and more. With each release, Android gets closer to feature parity with iOS!

And of course, we continue to squash framework and compiler bugs.

Be sure to check out the full release notes for all the details!

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.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube