Learning – Xojo Programming Blog

Conditional Compilation in Xojo: #If False and #If True

Martin T. — Fri, 03 Apr 2026 13:42:00 +0000

If you’ve been working with Xojo for a while, you’re likely familiar with conditional compilation directives like #If TargetMacOS or #If DebugBuild. But there are two particularly useful variants that are often overlooked in day-to-day development: #If False and #If True. In this article, we’ll look at what these directives do, when to use them, and why they can be a better choice than regular comments in certain situations.

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

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

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

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.
Prefer platform directives: When dealing with platform-specific code, use the specific constants (TargetMacOS, TargetWindows, etc.) instead of #If True or #If False.
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.

Build a Simple Find in Files Function

Gabriel Ludosanu — Thu, 02 Apr 2026 16:15:00 +0000

Sooner or later most apps need some version of the ability to find text in those files, whether you’re scanning log files, config files, exported data, or source code.

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:

the file path
the line number
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!

Jade Improvements

Paul Lefebvre — Tue, 31 Mar 2026 15:23:00 +0000

For Xojo 2026 Release 1, we’ve made some improvements to Jade, Xojo’s integrated AI assistant. Jade is easily accessible from the toolbar, making it handy for getting coding advice and asking general Xojo questions, especially about the documentation.

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.

Custom Control Rendering with DrawControlInLayoutEditor

William Yu — Tue, 31 Mar 2026 15:22:00 +0000

One of the notable additions in Xojo 2026 Release 1 is that the DrawControlInLayoutEditor event is now available for Desktop and iOS/Android projects, giving you more possibilities over how your controls appear in the layout editor.

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.

Watchpoints in Xojo: A Smarter Way to Track Your Data

William Yu — Tue, 31 Mar 2026 13:22:00 +0000

Debugging isn’t just about stepping through code anymore, it’s about understanding how your data behaves over time. With the new watchpoints feature in Xojo, you can now monitor variables and object properties more intelligently, without constantly stepping line by line or adding logging just to see when values change.

What Are Watchpoints?

Watchpoints let you pause execution when the value of a variable or property changes. Instead of asking “how did I get here?”, watchpoints help you answer “when did this change?”

This is especially useful when:

A value is being modified unexpectedly
Multiple parts of your code interact with the same object
You’re tracking down subtle state-related bugs

How Watchpoints Work

Setting up a watchpoint requires pausing execution where you would like to start monitoring the variable or property of an object.

In this example, we want to monitor the count variable, so you can right-click it in the variables debugger list and select Watch from the context menu. Once a watchpoint is set on a variable or property, the debugger keeps track of its value during execution. When the value changes, execution pauses and shows the line that triggered the change. Notice that the watchpoint break line is highlighted differently from the current execution line, and a Watchpoints list is now displayed.

This gives you immediate visibility into:

What code caused the modification
What the previous and new values are
What the surrounding state looks like

Why This Matters

Traditionally, tracking down a value change required manually stepping through code or adding temporary logging. Both approaches are time-consuming and error-prone.

Watchpoints eliminate that friction by:

Reducing the need for repetitive stepping
Highlighting only meaningful changes
Letting you focus on the root cause faster

Conditional Watchpoints

Watchpoints in Xojo aren’t limited to triggering on every change—you can make them conditional. For example, you can break only when a value is equal to, greater than, or less than a specific threshold, or even when it falls within a defined range. For string, both case-sensitive and case-insensitive comparisons are supported. This makes it much easier to focus on the changes that actually matter, especially when a variable updates frequently but only becomes problematic under certain conditions.

To add a condition to a watchpoint, right-click the watched variable or property and choose Edit Watchpoint Expression from the context menu.

The expression editor adapts based on the type of variable or property you’re watching, providing hints about what values and conditions you can enter.

Handling Object Lifetimes

One important detail when working with watchpoints is object lifetime.

If a watchpoint is attached to a property of an object that goes out of scope or is destroyed, the debugger can no longer track it. In these cases, Xojo provides feedback through the Messages pane so you know the watchpoint is no longer valid, along with the last known value.

What works and what doesn’t

You can set watchpoints on most variables and properties, even variants; however, Arrays, Structures, and computed properties are not supported. Code within #pragma DisableBackgroundTasks or #pragma Debug False blocks will not trigger watchpoint breaks. Watchpoints are also not currently available for Android projects.

Final Thoughts

Watchpoints bring a new level of precision to debugging in Xojo. Instead of chasing bugs through code, you can now let the debugger do the work of tracking down exactly where things go wrong.

Give them a try in your next debugging session—you might find yourself solving problems faster than ever!

Code Signing on macOS: What Developers Need to Know, Part 3

Javier Menendez — Tue, 24 Mar 2026 16:00:00 +0000

If you followed the previous two articles in this series, you should be set up properly now, right? Your Mac developer certificates are stored in Keychain Access, so you only need to fill in the Developer ID field under Build Settings > macOS > Sign with the appropriate certificate value, click Build (or Publish), and distribute your new amazing app worldwide. Well, not quite. There are still other pieces to consider when signing and distributing your macOS app.

For the past 20 years, Apple has increasingly tightened security measures when it comes to running apps distributed by third parties. Let’s take a look at this summarized timeline of code-signing and security measures added by Apple over years:

The most notable developments happened in 2011, 2012 and 2018, when terms like Sandbox and, especially, Containers, Gatekeeper, Hardened Runtime and Notarization were introduced and began to impact other pieces of the puzzle to consider when signing macOS apps. In fact, we could say that technologies such as code-signing, Sandboxing, Entitlements or Provisioning Profiles were among the first iOS technologies to make their way to macOS.

So here is an broad overview what these technologies mean:

Sandboxing– When used, Sandboxing confines applications to a restricted, designated area of the system (its own “container”), preventing them from accessing user data, hardware or other apps without explicit permission. The system requires apps to ask for permission to use hardware resources or access user files. Sandboxing is mandatory for apps distributed through the Mac App Store.
Gatekeeper- This technology is the primary security layer that checks whether a downloaded app comes from a verified/known developer, especially when the application has been Notarized by Apple.
Hardened Runtime– Acts as a proactive, system-enforced shield that protects applications while they run, preventing malicious code from exploiting legitimate software. Enabling Hardened Runtime is required for Notarization.
Notarization– Notarization is an automated security screening process run by Apple that scans software distributed outside the Mac App Store for malicious components and known security issues. Today, notarization is required for software distributed outside the Mac App Store that has been signed with the Developer ID application certificate. As a result of the process, notarization generates and staples a ticket, signed by an Apple certificate, to the app so Gatekeeper can trust it when executed.

So, basically, while Sandboxing is still optional for apps distributed outside the Mac App Store (i.e., signed with your Developer ID certificate), Notarization and Hardened Runtime are the recommended defaults. Enabling Sandboxing for your app is something you should consider based on the needs (features) and the privacy balance you want to offer your users.

If you plan to distribute the app through the Mac App Store as well, it will need to be Sandboxed and signed with your Apple Distribution certificate, while enabling Hardened Runtime is optional.

Entitlements and Provisioning Profiles

Entitlements and Provisioning Profiles are also required for many of these security measures, depending on the features and services your app uses, and they come into play during building and signing.

If you decide to go the Sandboxing route, then using Entitlements is mandatory. The good news is that Sandboxing entitlements are free to use (they don’t require creating or adding a Provisioning Profile to the project). However, if your app needs special access to the Keychain or uses iCloud, Apple Pay, or other services, you’ll need to create a Provisioning Profile in the Apple Developer portal.

Wait—what are Entitlements and Provisioning Profiles, and how do they relate to macOS app code signing?

Entitlements

Entitlements are XML-based .plist files (not unlike the app’s Info.plist) containing a set of key-value pairs. They are embedded directly into the app’s binary as part of the code signing process, typically using your Developer ID Application or Apple Distribution certificates.

Provisioning Profiles

While Entitlements are just a file, Provisioning Profiles are a different beast:

Provisioning Profiles must be created in the Apple Developer Portal. When you create one, you specify the App ID (the combination of your Team ID and the app bundle identifier which are case sensitive so pay attention). Even if you don’t plan to distribute your macOS app via the Mac App Store, you still need a Provisioning Profile, which requires creating an App ID first in the Developer Portal.

There are two kinds of Provisioning Profiles: Development and Distribution. As part of the provisioning profile creation, you must choose which type you will use.

Development Provisioning Profiles are used while you’re developing your app; the app is signed with an Apple Development certificate and is intended to run on a set of Mac computers you’ve registered. During creation, you can add as many Apple Development certificates as you have under your Team ID.
Distribution Provisioning Profiles are used when distributing your app. For direct distribution, sign with the same Developer ID certificate you’ll use for signing the app; for Mac App Store distribution, sign with the Apple Distribution certificate.
Development and Distribution Provisioning Profiles do expire. This is something to keep in mind, especially when deploying new or updated versions of your app, because you may need to create new profiles.
Development and Distribution Profiles are editable. If you make a mistake, note that both types can be edited in the Apple Developer portal, but only for certain fields: the App ID, the profile name, the selected certificate, and (for Development profiles) the included testing devices.

When Certificates and/or Provisioning Profiles expire…

We’ve already noted in previous articles that Apple Developer certificates expire one year after they’re created. We’ve also learned that if your app relies on a Distribution Provisioning Profile, that profile can expire as well. So, what does this mean for your already deployed apps?

No worries. Let’s focus first on directly distributed macOS apps (those signed with the Developer ID certificate) and pull one screenshot from the previous article:

Observe the highlighted Timestamp line. When the app is signed, the date is added automatically (retrieved from Apple’s servers). So, when a user runs an app whose embedded Developer ID Certificate has expired since its release, Gatekeeper will rely on that timestamp, compare it to the embedded certificate’s expiration date, and if everything matches—meaning it was signed before the certificate expired—the app will continue to work, provided the embedded certificate has not been revoked by the developer. In addition, if the app was Notarized, that helps a lot, because the stapled ticket includes its own timestamp and was signed with a longer-lasting Apple Certificate.

If the app is distributed through the Mac App Store, there’s good news. After you submit the app for distribution via App Store Connect and it passes Apple’s review, the app’s signing with your Apple Distribution certificate is replaced by Apple’s own signing. This means that users who install the app from the Mac App Store can continue to run it even if your original Apple Distribution certificate expired long ago.

Distribution Provisioning Profiles behave differently from others: once they expire, the app containing such a Distribution Profile will fail to execute.

The good news is that a Distribution Profile lasts for a very long time (around 18 years) so you’ll likely have ample time to create new distribution provisioning profiles and deploy updates that use renewed profiles well before users are affected.

Of course, as soon as any of your Apple Developer certificates expire, you already know how to request and install new ones in your Mac keychain.

Nearly Concluded

In the next, and last article, we will see how Xojo helps with everything related to signing and distributing your macOS apps. I’ll also show you how to deal with some of the most common issues related with certificates.

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.

Code Signing on macOS: What Developers Need to Know

Code Signing on macOS: What Developers Need to Know, Part 2

Javier Menendez — Wed, 18 Mar 2026 14:00:00 +0000

On the Apple side of code signing with developer certificates, we already know that the required root certificate, acting as the base anchor of the trust chain, is installed already on our Macs under the System Roots keychain.

But before we can reach our leaf developer certificates, we also need to have the Apple Development Intermediate certificates installed in our keychain. These are typically found in the Login keychain, though they can also be found in the System Roots or System keychains.

Installing Apple Developer Intermediate Certificates

Since Xcode 11.4.1 and later, these can be automatically downloaded and installed in the keychain, but if not, they can also can be downloaded from the Apple PKI webpage. The ones we are interested in are:

Developer ID – G2
Worldwide Developer Relations – G2
Worldwide Developer Relations – G3
Worldwide Developer Relations – G4
Worldwide Developer Relations – G5
Worldwide Developer Relations – G6

Note: The Developer ID – G2 certificate corresponds to the Developer ID Certification Authority. The WWDR certificates (G2–G6) correspond to the Apple Worldwide Developer Relations Certification Authority.

As you can see from the list, there are several versions (or generations) for the WWDR Intermediate certificate; so, which one should you download? The short answer: it depends.

On February, 7, 2023 the previous WWDR intermediate certificate expired; so Apple decided to rollout a new renewed version that will expire on February 20, 2030. As part of that update Apple issued additional Intermediate certificates to better segment the purpose of different certificates:

G2: ECDSA signing for Apple Pay.
G3: Software signing and Services.
G4: Features supported by Apple Push Notification Service.
G5: App Store Signing and Services.
G6: ECDSA signing of Software and Services.

In practice, G3, G4, and G5 are sufficient for most scenarios.

Developer Certificates: The final goal!

To focus on the subject, what kind of leaf developer certificates are created from these two types of Intermediate certificates? This scheme will help:

As you can see from the above diagram, there are four main leaf certificates we will use to sign our macOS apps, based on their prefix:

Developer ID Application. Use this one to code sign a macOS app distributed outside the Mac App Store.
Developer ID Installer. Use this one to code sign the Installer, DMG or .pgk file of a macOS app distributed outside the Mac App Store.
Apple Distribution. This certificate is required to code sign a macOS app sent to the AppStore Connect for its distribution through the Mac App Store.
3rd Party Mac Developer Installer. This Certificate is required to code sign the package of the app sent to the AppStore Connect. For example, when using the Publish feature from the Xojo IDE.

Creating and Installing the Developer Certificates

As stated in the first article of this series, you need a paid Apple Developer Program membership. Once that’s in place, the easiest way to install these required certificates in your macOS Keychain is through Xcode.

So, if it is the first time you need to install them on a Mac computer:

Go to Xcode > Preferences.
Select Apple Accounts.
Use your developer credentials to login into your developer account, or select it from the list if you are already logged.
Select the Team from the list.
Click the “Manage Certificates…” button.
Click the “+” popup menu in the lower-left corner of the resulting window, and select the developer certificate you want to install (all of these if it is the first time you install them).

Note: Under the hood, Xcode follows the same process described for installing the developer certificates manually.

If you prefer to go through the manual process instead:

Access the Apple Developer website.
In Certificates, Identifiers & Profiles, click Certificates in the sidebar.
On the top left, click the add button (+).
Under Software, select Developer ID, then click Continue.
- Developer ID Application: This certificate is used to code sign your app for distribution outside of the Mac App Store Connect.
- Developer ID Installer: This certificate is used to sign your app’s installer Package for distribution outside of the Mac App Store Connect.
- Apple Development: Used to run and debug apps on macOS during development.
- Apple Distribution: Used to sign apps for submission to App Store Connect.
- Mac App Distribution: Used to sign macOS apps intended to be distributed through the Mac App Store.
- Mac Installer Distribution: Used to send the macOS app to the App Store Connect for TestFlight or distribution through the Mac App Store.
Follow the instructions to create a certificate signing request.
Click Choose File.
In the dialog that appears, select the certificate request file (a file with a .certSigningRequest file extension), then click Choose.
Click Continue.
Click Download.
The certificate file (a file with a .cer file extension) appears in your Downloads folder.
To install the certificate in your keychain, double-click the downloaded certificate file. The certificate appears in the My Certificates category in Keychain Access.

It’s All About Identities

While Intermediate and Root certificates only have the Public Key on them, so they can verify other (leaf) certificates, the leaf certificates installed on your macOS Login keychain behave a bit different. Let’s see how.

Both if you use Xcode or create the CSR request manually to generate the developer certificates, using the Keychain Access app for that, in both of these scenarios a Private Key will be created and stored locally on your keychain as part of the process. Only the public key section of that private key is sent to the Apple servers so it can be included in the generated developer certificate. Once any of the possible developer certificates is downloaded and installed in the keychain, such certificate will have its private key associated with it:

The pair of the developer certificate and the associated private key is what is called an Identity.

Code signing With Developer Certificates

In fact, while we often say or hear “code signing with certificates,” the real signing of the app is done with the private key associated with that certificate. The certificate itself (and thus the public key portion of that key pair) is included in the signing process. This allows macOS to verify the signature each time the user runs the app

Do you remember the diagram showing how the “Ad-Hoc” code signing process works? Let’s compare it when the same process is done using a “Developer ID Application” Certificate… and, most important, the associated private key:

As you can see, in this case the data is cyphered using the private key from the developer certificate and, then, the certificate itself is stored as part of the app itself. So, if for example we build this time an empty Desktop app for macOS using the Developer ID Application, and open the resulting CodeResources file in a text editor we will see something different compared with the Ad-Hoc signed version:

In this case the field requirement associated with each file and hash value is significantly more strict. In fact, it makes reference to the Chain of Trust Gatekeeper is required to follow and validate. In plain English, the highlighted lines come to say something like:

Hey! make sure there is a Developer ID Application certificate (Apple Extension attribute —OID— 1.2.840.113635.100.6.1.13 for the X.509 certificate), for the developer with a TeamID BW7PU32485.
Next, verify such certificate is issued by the “Apple Developer ID Certificate Authority” (other of the Apple-specific X.509 extension, attribute or OID. In this case: 1.2.840.113635.100.6.2.6).
And finally, go down through the Chain of Trust and verify the previous one with the Anchor certificate (Apple Root CA, do you remember?)

So far so good. But how we can know if the app meets these requirements; and what about the certificates themselves? Well, it’s easy to check both using the codesign tool.

Open a Terminal window and type the following command:

codesign --verify -vvv "MyApp.app"

The output will be something similar to this:

As you can see in the highlighted lines, yes, it satisfies the Designated Requirements we saw in our CodeResources file! Also, the previous line states that it is valid on disk. That means:

All of the expected files are present.
There are no extra files.
None of the files have been modified.
A basic trust evaluation of the leaf certificate was successful.
And it satisfies its own Designated Requirements (DR).

It is even possible to see the Chain of Trust for the code signature issuing:

codesign --display -vv "MyApp.app"

And if you are curious enough, it is even possible to extract the embedded certificates stored in the CMS structure within the code signature:

codesign --display --extract-certificates "MyApp.app"

As result it will, usually, create three files. Take a closer look at the “Issuer” and “Subject” lines; specially on the Subject line for the OU value (Organizative Unit or, using Apple wording, the TeamID) for the codesign0 file. Do you remember the “leaf[subject.OU=BW7PU32485]” data from the CodeResources file? :

codesign0. This is the file for the Leaf certificate; in our example “Developer ID Application”.

codesign1. This one is for the Intermediate Certificate; in our example “Apple Developer ID Certificate Authority”.

codesign2. This one is for the Anchor Certificate; in our example “Apple Root CA”

As shown by the Issuer line in the codesign0 file for our “Developer ID Application,” it points to the previous certificate in the trust chain—the Developer ID Certification Authority. The codesign1 file for the extracted Developer ID Certification Authority points to the Apple Certification Authority in its Issuer field. Finally, the codesign1 certificate points to itself because, as the Root Certificate, it serves as the anchor for the trust chain.

Wrapping up

In this second article, we delved deeper into how Apple Developer certificates work, how a macOS app is signed (Ad-Hoc or with a specific developer certificate), and how the OS’s security features validate the signing when a user tries to run the app.

In the next article, we will cover more details about signing apps for the two main distribution types: Direct distribution and Mac App Store. We will also discuss what happens when certificates expire and how to troubleshoot the most common issues related to development certificates.

Code Signing on macOS: What Developers Need to Know

Code Signing on macOS: What Developers Need to Know, Part 1

Javier Menendez — Wed, 04 Mar 2026 16:00:00 +0000

Your macOS app is finished and ready to go. But unless you plan to run it only on your own machine, there’s one essential step before sharing it with others: code signing with certificates.

This blog series provides a clear, practical overview of how certificates work, with a focus on signing and distributing macOS applications. Some concepts apply to digital certificates in general, while others are specific to the macOS code signing process. By the end of the series, you’ll understand what certificates are, why they matter, and the role they play when building and distributing a macOS app.

The Developer ID field in the Build Settings > macOS > Sign Inspector Panel is our starting point:

By default, this field is empty. When you click Build, the app bundle (and its contents) is signed using a more relaxed security configuration. This does not require an explicit developer certificate and does not verify that the app comes from a known, trusted developer.

This type of signing is called Ad-Hoc signing. It is perfectly fine when debugging from the IDE or when building apps you intend to run locally.

In earlier versions of macOS, it was even possible to distribute and run Ad-Hoc–signed apps on other Macs, as long as the user explicitly chose to trust them. While this is still technically possible on recent versions of macOS, Apple has continued to tighten security, making it increasingly difficult for users to launch Ad-Hoc–signed applications.

In most cases, Gatekeeper will intervene and prevent the app from launching. Since the system cannot verify the identity of a trusted developer, it treats the app as unverified. With Ad-Hoc signing, macOS can only confirm that the app has not been modified since it was signed, it cannot validate who created it.

Under the hood: How “Ad-Hoc” signing works

Every time an app is signed (including all the contents inside its bundle) macOS uses Apple’s codesign tool. When Ad-Hoc signing is applied, the simplified process works roughly like this:

A hash value (a unique digital fingerprint) is calculated for every file in the app bundle, whether it is executable or not, as well as for the bundle itself.
These hash values are stored inside the app bundle, in the _CodeSignature folder.
If the app contains multiple architectures (for example, x86 and ARM), the process is repeated for each supported architecture.

When a user double-clicks the app to launch it, macOS performs a similar verification process:

It recalculates the hash value for every file in the bundle.
It compares the newly calculated values with those stored in the _CodeSignature folder and if any hash differs from the stored value, macOS determines that the bundle has been modified since it was signed and it will refuse to launch the app.

Want to see this in action? Create a new Desktop project in the Xojo IDE, save it to your Documents folder, and build it for macOS.

Next, locate the built app in Finder. Control-click it and choose “Show Package Contents.” Then open the Contents > _CodeSignature folder and inspect the CodeResources file using your favorite text editor. You’ll see a list of hash values and digests corresponding to every file in the app bundle.

Apple Developer Certificates: Establishing Trust on macOS

What must you do so your apps are recognized as first-class citizens on macOS and can be distributed without Gatekeeper intervening? The answer is likely familiar: enroll in the Apple Developer Program (currently US $99 per year).

Among its many benefits, membership in the Apple Developer Program allows you to create your own Developer ID certificates. When you use these certificates to sign your apps, macOS can validate the signature and identify you as the verified developer distributing the software.

But how is this trust established and verified? To answer that, we need to start at the very root, literally!

Every computer, smartphone, tablet, and many other devices come with preinstalled Root Certificates. These certificates are issued by trusted organizations known as Root Certificate Authorities (CAs), including Apple. They serve as the foundation of a chain of trust, allowing other certificates issued by those authorities to be verified.

Technically speaking, a Root Certificate Authority (CA) is the top-level trusted entity in a public key infrastructure (PKI). It issues self-signed root certificates that act as the trust anchor for verifying other digital certificates. In other words, it is the foundation upon which the entire certificate trust model is built.

It is easy to take a look to these installed on your Mac:

Open Keychain Access.
Select Certificates at the top of the window.
In the sidebar, choose System Roots.
You will then see the complete list of root certificates trusted by macOS.

You’ll notice that there are three different Apple Root CA certificates. Why?

Each X.509 certificate contains detailed metadata defining its cryptographic properties and permitted usage. This includes the key type (such as RSA or ECDSA), the public key length, and the signature algorithm used.

Apple Root CA: Is a RSA type, with a public key length of 2048 bits that uses the SHA-1 algorithm.
Apple Root CA-G2: Is a RSA type, with a public key length of 4096 bits that uses the SHA-384 algorithm.
Apple Root CA-G3: Is a ECDSA type, with a public key length of 384 bits that uses the SHA-384 algorithm.

Intermediate Certificates and the Chain of Trust

Root certificates are highly valuable and sensitive, so they are rarely used directly to sign end-user certificates (also called “Leaf” certificates). In the case of macOS app development, the developer’s certificate is the Leaf. This is where Intermediate Certificates come into play.

In simple terms, Intermediate Certificates are signed by Root Certificates and, in turn, are used to sign Leaf certificates. This protects the Root certificate from direct exposure. Together, the Root, Intermediate, and Leaf certificates form what is called the “Chain of Trust.”

The Chain of Trust verification starts with the Leaf certificate and works upward through the Intermediate to the Root. This same process occurs whenever you visit a secure website, make an online payment, or transmit sensitive data securely.

For example, the Leaf certificate is validated against its Intermediate certificate. If the Intermediate certificate is missing or expired, the Leaf certificate is considered invalid. Similarly, the Intermediate certificate itself must be validated against the Root certificate. If the Root certificate is missing or expired, the Intermediate is invalid, and all Leaf certificates signed by it are also invalid.

The same process happens when you sign your macOS apps: macOS validates the entire certificate chain before allowing the app to run.

Finally, certificates closer to the Root generally have longer validity periods. Leaf certificates must be renewed more frequently, while Root certificates are valid for many years.

Wrapping up

In this first article, we covered the fundamentals of digital certificates and their role in macOS app security. In the next article, we will focus specifically on Apple Developer certificates and how they enable trusted app distribution.

Code Signing on macOS: What Developers Need to Know

Optimizing Xojo Code, Part 5: Threads and UserInterfaceUpdate

Gabriel Ludosanu — Mon, 02 Mar 2026 23:43:13 +0000

In Part 1, we learned why tight loops with DoEvents freeze your UI. Part 2 showed us Timer controls. Part 3 moved timers into code. Part 4 simplified scheduling with CallLater.

But timers have a limit: they still run on the UI thread. If your background work is genuinely heavy (database queries, file I/O, complex calculations), a timer won’t save you. You need actual background processing and that’s where threads come in.

The Core Idea: Threads

A thread is a separate execution path that runs outside the UI thread. While your thread does the heavy lifting, the UI stays responsive to clicks, typing, scrolling. When your thread finishes a chunk of work, it notifies the UI thread via UserInterfaceUpdate, and only that callback runs on the main thread.

The rule is simple: threads cannot touch UI controls directly. If you try, you get a crash. UserInterfaceUpdate is your bridge.

For a deeper dive into how Xojo’s threading model works under the hood, including cooperative vs. preemptive threading, see Cooperative to Preemptive: Weaving New Threads Into Your Apps.

Let’s Code

Prerequisites: Add a StatusLabel (DesktopLabel), a DesktopButton, and a Thread control. Also define:

kCountTo As Integer = 100

The Thread Control

Drag a Thread from the library into your window and name it BackgroundWorker.

The Button (Start the Thread)

Place this in the Pressed event of a button:

Sub Pressed()
  If BackgroundWorker.ThreadState = Thread.ThreadStates.NotRunning Then
    BackgroundWorker.Start
  End If
End Sub

This checks if the thread is already running. If not, start it. This prevents multiple threads from piling up if someone clicks fast.

The Thread.Run Method (Background Work)

Implement the Run method on your Thread:

Sub Run()
  For i As Integer = 0 To kCountTo
    
    ' Do background work here. No UI access allowed.
    ' It can be: database query, file read, API call, pretty much anything that might block "freeze" the UI of the app
    
    ' Prepare a Dictionary payload for the UI
    Var info As New Dictionary
    info.Value("progress") = i
    info.Value("message") = "working"
    Me.AddUserInterfaceUpdate(info)
    
    ' Sleep (optional)
    Thread.SleepCurrent(10)   // Sleep 10 ms
  Next
End Sub

The key line is Me.AddUserInterfaceUpdate(info). This queues data for the UI thread to process. Each call adds one item to a queue, and the UI thread drains it in UserInterfaceUpdate.

The Thread.UserInterfaceUpdate Method (UI Sync)

Implement this event to handle updates from the thread:

Sub UserInterfaceUpdate(data() As Dictionary)
  ' Runs on the main UI thread. Safe to update controls here.
  
  ' Guard against empty or malformed data
  If data = Nil Or data.Count < 0 Then Return
  
  Var d As Dictionary = data(0)
  
  ' Extract the progress value safely
  Var progress As Integer = 0
  If d.HasKey("progress") Then
    progress = d.Value("progress").IntegerValue
  End If
  
  ' Update the UI
  StatusLabel.Text = progress.ToString
  
  ' Mark completion when we hit the target
  If progress >= kCountTo Then
    StatusLabel.Text = "done"
  End If
End Sub

Important notes:

data() is an array of Dictionaries.
Always check HasKey before accessing a value to avoid runtime errors.
Use .IntegerValue (or .StringValue, etc.) to safely extract values.
This runs on the UI thread, so it is safe to update StatusLabel and any other visual controls.

How It Works

Button press: Click the button and the thread starts.
Background loop: The thread iterates from 0 to kCountTo, sleeping 10 ms each step. After each step, it queues an update.
Responsiveness: While the thread works, you can still interact with the rest of your application. No freezing.

A Note on Thread Safety

Threads are powerful but risky if misused. Here is the boundary:

Safe in Run(): Anything that doesn’t touch UI controls. File I/O, database queries, calculations, network calls.
Unsafe in Run(): Reading or writing UI control properties directly. StatusLabel.Text = ... is a no no!
Safe in UserInterfaceUpdate(): All UI control access. This runs on the main thread.

If you forget this rule and try to update a label from inside Run(), your app will crash with a ThreadAccessingUIException. Instead pass data through AddUserInterfaceUpdate.

When to Use Threads vs. Timers

Use timers for:

Short, frequent tasks (10-50 ms ticks).
Simple progress updates.
Cases where you are just deferring work a bit.

Use threads for:

Long-running operations (seconds, minutes, hours).
Genuinely blocking work (I/O, network, heavy calculations).
Multiple independent background tasks.

In this series, we moved from blocking the UI to using timers on the UI thread, then to actual background threads. Each approach solves a different problem.

Wrapping Up

Threads are the heavy artillery of responsive design. They run independent of the UI and communicate safely via UserInterfaceUpdate. Once you grasp the boundary between thread code and UI code, you can build applications that never freeze, no matter how much work is happening behind the scenes.

See the Thread documentation for more details on priority, stack size, and advanced patterns.

Until then, happy threading!

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!

Optimizing Code Series:

Scatter Chart: Connecting the Points

Javier Menendez — Mon, 09 Feb 2026 16:26:56 +0000

A user recently asked whether it’s possible to connect the (x, y) points in a Scatter chart using DesktopChart, and if so, how to do it. The short answer is yes, it is possible. Read on and I’ll show you just how easy it is.

For this example, we’ll use the x and y coordinate values of the sine and cosine functions as the data for our scatter DataSets. Go ahead and create a new Desktop project in the Xojo IDE.

Next, select the default Window1 and drag a DesktopChart control from the Library panel into the Layout Editor for Window1. Adjust the right margin to the recommended right layout guide, then lock the Top, Left, and Right layout locks for the Chart1 instance using the Inspector. At this point, your design should look similar to this:

While you’re there, select Chart1 and, in the Inspector, set the option Behavior > Mode to Scatter.

Next, with Window1 selected, add two properties using the following values:

Property 1:

Name: CosStyle
Type: ChartLinearStyle
Scope: Private

Property 2

Name: SineStyle
Type: ChartLinearStyle
Scope: Private

These properties will be used to store references to the Style objects associated with the cosine and sine function DataSets.

Finally, with Window1 still selected, add the Opening event and enter the following lines of code into the associated code editor:

CosStyle = New ChartLinearStyle
CosStyle.Line = ChartLinearStyle.LineTypes.Dashed

SineStyle = New ChartLinearStyle
SineStyle.Line = ChartLinearStyle.LineTypes.Solid

DrawScatterChart

In brief, this code creates new ChartLinearStyle instances for the properties added earlier. It assigns a solid line style to connect the cosine function data points and a dashed line style to connect the sine function data points. After that, it calls the DrawScatterChart method, which is responsible for rendering the sine and cosine functions on the Chart1 instance.

Now, let’s create that method on Window1 using the following values in the Inspector:

Name: DrawScatterChart
Scope: Private

Type the following snippet of code in the associated Code Editor for the method:

// These are the Array variables in charge of storing the Scatter data points
// for the Sine and Cosine functions
Var sinePoints() As ChartScatterDatapoint
Var cosinePoints() As ChartScatterDatapoint

// …and these variables will handle the DataSet instances
// for the previous arrays of data points on both functions
Var sineDataSet As ChartScatterDataset
var cosDataSet As ChartScatterDataset

Const pi = 3.14159265359
Var y As Double
Var maxXValue As Double = 2.0 * pi

// Using a simple loop to feed the x and y
// values for the Sine and Cosine
For x As Double = 0.0 To maxXValue Step 0.5
  
  y = Sin(x)
  sinePoints.Add(New ChartScatterDatapoint(x, y, 1))
  
  y = Cos(x)
  cosinePoints.Add(new ChartScatterDatapoint(x, y, 1))
  
Next

// Next, we create the new instances for the Scatter DataSets
sineDataSet = New ChartScatterDataset(Color.Blue, sinePoints)
cosDataSet = New ChartScatterDataset(color.Red, cosinePoints)

// …and we set the Style to be used on each of them
sineDataSet.Style = SineStyle
cosDataSet.Style = CosStyle

// … and of course the labels to be shown on the Legend section
// of the chart itself
sineDataSet.Label = "Sine Function"
cosDataSet.Label = "Cos Function"

// As the last step, we add both DataSets to the chart
// so these can be rendered
Chart1.AddDatasets(sineDataSet, cosDataSet)

Run the app, and it should look similar to this:

A change of Style… on the fly!

As with many aspects of DesktopChart, any changes made at runtime are reflected immediately, without the need to redraw the chart, re-feed the data sets, or perform any other complex operations. Let’s take advantage of this by changing the sine and cosine styles at runtime, allowing users of our example app to toggle whether the points are connected.

Add two DesktopCheckBox controls below the bottom margin of the Chart1 instance on Window1. Set the Caption of the first checkbox to “Connect Sine Points” and the second to “Connect Cos Points.” For both checkboxes, use the Inspector to set Initial State > Visual State to Checked.

The final layout should look similar to this:

Lastly, add the ValueChanged event to both CheckBox instances. Then, for the checkbox with the caption “Connect Sine Points,” add the following lines of code to its event handler:

If Me.Value Then
  SineStyle.Line = ChartLinearStyle.LineTypes.Dashed
Else
  SineStyle.Line = ChartLinearStyle.LineTypes.None
End If

Add the following lines of code to the ValueChanged event handler for the checkbox with the caption “Connect Cos Points”:

If Me.Value Then
  CosStyle.Line = ChartLinearStyle.LineTypes.Solid
Else
  CosStyle.Line = ChartLinearStyle.LineTypes.None
End If

Run the app again and, this time, click each checkbox to see how the points are no longer connected when a checkbox is unchecked, and are connected when it is selected.

Summary

As you can see, styles can be used not only to connect points in a Scatter chart, but also to customize the point endpoints beyond the default appearance. For example, you can set the endpoint to “None” or choose from many other available options. Even better, any changes made to a style at runtime are applied immediately.

Optimizing Xojo Code, Part 4: Timer.CallLater

Gabriel Ludosanu — Mon, 02 Feb 2026 21:25:28 +0000

In Part 1 of this series, we looked at a common but discouraged approach using a tight loop with DoEvents to keep the UI from freezing. In Part 2, we explored a better alternative by replacing that loop with a Timer control dragged onto a Window. In Part 3, we advanced to creating Timers programmatically with AddHandler for use in classes and modules.

Now, for even simpler one-off or chained delayed tasks, Xojo offers Timer.CallLater: no Timer instance required.

The Strategy: Timer.CallLater

Timer.CallLater(milliseconds, AddressOf MethodName, arg As Variant) schedules your method to run after the specified delay on the main UI thread. Pass data via the Variant parameter. To chain calls (like our countdown), re-call it from within the method. Use Timer.CancelCallLater(AddressOf MethodName) to abort pending calls.

For full details, see the Timer documentation.

Looking at the Code

Prerequisites: Add a StatusLabel (DesktopLabel control) and a constant kCountTo As Integer = 20000.

Let’s look at how we implement this.

The Setup (Button Pressed)

Place the following code in the Pressed event handler of a button control:

Sub Pressed()
  Timer.CancelCallLater(AddressOf UpdateProgress)
  
  StatusLabel.Text = "0"
  
  Timer.CallLater(100, AddressOf UpdateProgress, 100)
End Sub

The Handler (Recursive Chain)

Create the following method that handles the recursive chain of delayed updates:

Sub UpdateProgress(elapsedMs As Variant)
  Var elapsed As Integer = elapsedMs.IntegerValue
  
  If elapsed >= kCountTo Then

    StatusLabel.Text = "done"

  Else

    StatusLabel.Text = elapsed.ToString
    Timer.CallLater(100, AddressOf UpdateProgress, elapsed + 100)

  End If
End Sub

Crucial Note: The handler method must accept a Variant parameter to receive the argument passed to CallLater. Always use type-safe extraction like .IntegerValue.

How It Works

Initial Schedule: The button cancels any pending calls and schedules the first UpdateProgress after 100ms, passing 100 as the elapsed time (just in case we like pressing a button multiple times quickly).
Recursion: Each call updates the UI and, if not finished, schedules the next one 100ms in the future with incremented elapsed time.
Automatic Management: No Timer properties or handlers to manage; Xojo handles scheduling and cleanup.
Cancellation: Ensures only one chain runs at a time.

Wrapping Up

Timer.CallLater shines for delayed UI updates or chained tasks without the overhead of Timer objects. It’s concise, safe, and powerful for responsive apps.

In Part 5, we’ll tackle true background processing with Threads and UserInterfaceUpdate.

Until then, 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!

Optimizing Code Series:

Xojo + XAML + Goto = 🔥

William Yu — Thu, 22 Jan 2026 20:50:59 +0000

For decades, Goto has been treated as a programming faux pas—something to avoid at all costs. Like most rules though, there are exceptions. The Goto I’m talking about here is one of them… and it can quite literally light your app on fire—programmatically speaking.

One of the hidden gems in Xojo 2025r3 is support for XAML transitions, which makes it possible to add lightweight animations to your UI without writing any custom animation code in Xojo. Instead, you define visual states in XAML and let the XAML engine handle the animation for you.

At a high level, the workflow looks like this:

Define one or more VisualStates in XAML.
Attach transitions to those states (for example, moving or fading an element).
From Xojo code, switch between states using Invoke("GotoState", ...).

Pro Tip
DesktopXAMLContainer subscribes to Operator_Lookup, so you don’t have to call Invoke directly. Instead of writing XAMLContainer1.Invoke("GotoState", "WhichState"), you can simply call XAMLContainer1.GotoState("WhichState").

Visual States in XAML

A VisualState represents a named configuration of UI properties. When you transition from one state to another, XAML can automatically animate the change.

Below is a simple example that animates a fire emoji moving upward, similar to a candle flame flickering or burning upward.

Example XAML

This example uses a TextBlock to display the fire emoji and animates its vertical position with a TranslateTransform. Note that visual states must be defined on a control, so we attach them to a UserControl, allowing it to participate in GotoState transitions.


  
    
      

        
          
                          Storyboard.TargetName="FlameTransform"
              Storyboard.TargetProperty="Y"
              To="40"
              Duration="0:0:1" />
          
        

        
          
                          Storyboard.TargetName="FlameTransform"
              Storyboard.TargetProperty="Y"
              To="-100"
              Duration="0:0:1" />
          
        

      
    

          Text=""
      FontSize="32"
      HorizontalAlignment="Center"
      VerticalAlignment="Bottom">

In this XAML:

The VisualStateGroup named FlameStates contains two states:
- Bottom – moves the emoji downward.
- Top – moves the emoji upward.
The DoubleAnimation targets the Y property of a TranslateTransform.
The transition duration is handled entirely by XAML.

Triggering the Transition from Xojo

Once the visual states are defined, switching between them from Xojo is straightforward. Assuming this XAML is hosted in a XAMLContainer named XAMLContainer1, you can trigger the animation like this:

XAMLContainer1.GotoState("Top")

And to move it back down:

XAMLContainer1.GotoState("Bottom")

Why This Is Powerful

What makes this feature especially useful is that:

The animation logic stays in XAML, where it naturally belongs.
Xojo code remains clean and declarative—just tell the UI which state to go to.
More complex effects (opacity, scaling, rotation, easing functions) can be added without changing any Xojo code.

Here’s a more interesting variation, where the flames drift upward rather than moving in a straight line:

To light up the flames we’ll simply invoke the “On” state:

XAMLContainer1.GotoState("On")

For subtle UI polish—like animated indicators, highlights, or playful effects such as this candle flame—XAML transitions provide a surprisingly powerful new tool in Xojo.

Detecting UI Compatibility Mode in macOS Apps with Xojo

Javier Menendez — Wed, 14 Jan 2026 22:49:34 +0000

As you may already know, starting with Xojo 2025r3, macOS apps can be developed and compiled with UI Compatibility Mode either enabled or disabled. Now imagine you are creating a Library intended for use in other projects and, as part of its UI-related functionality, the Library needs to determine whether the host application is running with UI Compatibility Mode enabled. How can you do that? Read on to find out.

To determine whether a macOS app is running with UI Compatibility Mode enabled, we’ll use a small set of Declares inside a method contained in a Module, purely for the purposes of this example. Begin by creating a new Desktop project and adding a new Module to it (for example, a simple “Module1”). Next, add a new method to the Module with the following signature:

IsCompatibilityModeEnabled As Boolean

Then add the following code to the method:

#If TargetMacOS Then
  
  If System.Version.MajorVersion >= 26 Then
    
    Declare Function NSClassFromString Lib "Foundation" (clsName As CFStringRef) As Ptr
    Declare Function NSMainBundle Lib "AppKit" Selector "mainBundle" (obj As Ptr) As Ptr
    Declare Function NSInfoDictionary Lib "AppKit" Selector "infoDictionary" (obj As Ptr) As Ptr
    Declare Function NSDictValueForKey Lib "AppKit" Selector "valueForKey:" (obj As Ptr, key As CFStringRef) As Ptr
    Declare Function NSGetBoolValue Lib "AppKit" Selector "boolValue" (obj As Ptr) As Boolean
    
    Var Bundle As Ptr = NSClassFromString("NSBundle")
    
    If Bundle <> Nil Then
      Var MainBundle As Ptr = NSMainBundle(Bundle)
      
      If MainBundle <> Nil then
        Var infoDictionaryPlist As Ptr = NSInfoDictionary(MainBundle)
        
        If infoDictionaryPlist <> Nil Then
          Var valueObj As Ptr = NSDictValueForKey(infoDictionaryPlist, "UIDesignRequiresCompatibility")
          
          If valueObj <> Nil Then 
            Return NSGetBoolValue(valueObj)
          End If
          
        End If
        
      End If
      
    End If
  End If
  
  Return False
  
#EndIf

In short, the previous code retrieves the app’s Info.plist from the macOS bundle and loads it into an NSDictionary object (similar to Xojo’s Dictionary). It then attempts to access the value associated with the key UIDesignRequiresCompatibility. If the returned object is Nil, it means the Info.plist does not contain that key and the app is therefore running in native macOS Tahoe mode. If the key is present, the method returns the Boolean value associated with it; a value of True indicates that the app is running with UI Compatibility Mode enabled under macOS Tahoe. That’s all there is to it!

Testing the Method

Now add a DesktopButton to the project’s default window and implement its Pressed event. Next, insert the following line of code into the associated Code Editor:

MessageBox("Compatibility Mode Enabled: " +  IsCompatibilityModeEnabled.ToString)

For testing purposes, select Build Settings > macOS in the Project Browser and enable UI Compatibility Mode, which can be found under the Build section of the Inspector. Run the app and, if your Mac is running macOS 26 or later, you will see the following message:

Quit the app and return to Build Settings > macOS to disable UI Compatibility Mode. Run the app again and this time you will see the following message:

In Summary

As you can see, Declares are a powerful feature in Xojo’s extensive toolbox, allowing developers to directly access and use APIs provided by the operating system. In this case, they enable you to retrieve the app’s Info.plist from the main bundle, load it into a dictionary, and read the value associated with a specific key.

Optimizing Xojo Code, Part 3: Programmatic Timers and AddHandler

Gabriel Ludosanu — Wed, 14 Jan 2026 16:27:11 +0000

In Part 1 of this Optimizing Xojo Code series, we looked at a working but discouraged approach using a tight loop with DoEvents to keep the UI from freezing. In Part 2, we explored a better alternative by replacing that loop with a Timer control dragged onto a DesktopWindow. This is a simple and effective solution that takes advantage of Xojo’s object-oriented nature.

But what if you need a timer inside a Class or a Module where you can’t drop a visual control?

The Strategy: AddHandler

When you use a Timer control from the library, you double-click it to add an Action event. When we create a Timer in code, we don’t have a “code editor” for it in the same way. Instead, we use the AddHandler command to tell Xojo: “When this timer fires its Action event, run this specific method instead.”

Looking at the Code

Let’s look at how we implement this. In our example project, we have a button that initializes our timer and a separate method to handle the “ticks.”

The Setup

First, we define a property on our window (or class) to hold our timer: mWaitTimer As Timer

Then, in the Pressed event of our button, we instantiate it:

Sub Pressed() Handles Pressed
  ' 1. Cleanup
  If mWaitTimer <> Nil Then
    mWaitTimer.RunMode = Timer.RunModes.Off
    mWaitTimer = Nil
  End If
  
  ' 2. Initialization
  mElapsedMs = 0
  StatusLabel.Text = "0"
  
  ' 3. Create the dynamic timer
  mWaitTimer = New Timer
  mWaitTimer.Period = 100 ' 100 ms tick
  mWaitTimer.RunMode = Timer.RunModes.Multiple
  
  ' 4. The Magic: Link the Action event to our WaitTick method
  AddHandler mWaitTimer.Action, AddressOf WaitTick
End Sub

The Handler (Doing the Work)

Now, let’s create the method named WaitTick. Crucial Note: When using AddHandler for a Timer, the first parameter of your receiving method must be of the type Timer so it knows which object triggered it.

Sub WaitTick(t As Timer)
  mElapsedMs = mElapsedMs + t.Period
  
  If mElapsedMs >= kCountTo Then
    ' Achievement unlocked! Stop the timer and clean up
    t.RunMode = Timer.RunModes.Off
    StatusLabel.Text = "done"
    
    ' It's good practice to remove the handler when done
    RemoveHandler t.Action, AddressOf WaitTick
  Else
    StatusLabel.Text = mElapsedMs.ToString
  End If
End Sub

How It Works

New Timer: We create a new instance of the Timer class in memory.
AddHandler: This command connects the Action event of our new timer to the WaitTick method. The AddressOf operator tells Xojo the memory location of the code we want to run.
Passing the Object: Because WaitTick receives t As Timer as a parameter, you can actually use the same handler for multiple different timers and knows exactly which one is calling for attention.

Wrapping Up

By moving your Timers into code, you take a significant step toward writing more modular Xojo applications. You’ve moved the logic from “Global UI state” into “Managed Code execution.”

In the upcoming Part 4, we’ll look at a shortcut that makes one-off background tasks a breeze: Timer.CallLater.

Until then, happy coding and don’t forget to add your own solution in the Xojo Forum!

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!

Optimizing Code Series:

Community Contributions to the Xojo Blog: Spotlight On & Guest Posts in 2025

Alyssa Foley — Thu, 18 Dec 2025 20:25:07 +0000

Besides being a great resource for everything from Xojo code tips and snippets to videos that show you cool things, plus news and announcements, the Xojo Blog also strives to build community among the wide range of people who use Xojo around the world. We welcome guest bloggers from the Xojo community and highlight the many different ways people use Xojo through our Spotlight On series.

In 2025, guest authors shared their expertise and real-world experience on the Xojo Blog. These posts bring fresh perspectives, practical solutions and deep technical insight that help other developers learn faster, solve problems more effectively and feel more connected to the Xojo community.

Guest posts in 2025 included:

Martin T., Xojo MVP: Hide the Tabs in an Android MobileTabPanel Using Declares
Martin T., Xojo MVP: Xojo for Android: A Two-Year Retrospective
Martin T., Xojo MVP: It’s here – Android Design Extensions 4.0
Anthony Cyphers, GraffitiSuite and Xojo MVP: Handling Feature Requests
Kem Tekinay, Xojo MVP: MemoryBlocks For Speed: A Case Study
Kem Tekinay, Xojo MVP: The Beauty of Binary Searches
Jürg Otter: Build a Xojo Plugin with GitHub Actions
Ezekiel Burke, Iron Elephant Solutions: Introduction to PocketBase: A Backend Alternative for Xojo Developers

We are always looking for users in the Xojo community who want to share a problem they’ve solved, a creative solution or an interesting project. If you’re interested in contributing a guest post or have an idea you’d like to explore, send it to me at alyssa@xojo.com.

In 2024, we introduced the Spotlight On series to highlight the work Xojo users do and their experiences using Xojo. Since many Xojo users don’t fit the mold of a traditional developer role, Spotlight On offers a fun and approachable way to learn how someone got started with Xojo and how they use it today. Spotlights can focus on an individual developer, a business or a specific Xojo-based project.

Spotlight On features in 2025:

If you’d like to be featured in a future Spotlight On or know someone in the Xojo community whose story would be great to share, we’d love to hear from you. Reach out with suggestions to me at alyssa@xojo.com.

The Xojo Blog is at its best when it reflects the voices, experiences and creativity of the community itself. Whether through guest posts, Spotlight On posts or shared ideas, we look forward to continuing to learn from and celebrate the people who make Xojo what it is.

Alyssa has been with Xojo for over 18 years. She loves solving problems and building community. You can reach her at alyssa@xojo.com or through any of Xojo’s social media channels. If you can’t reach her she’s probably out hiking the beautiful trails through her city of Portland, Oregon, or maybe enjoying a drink with friends by the river.

Tip: Customize Toolbars on macOS apps

Javier Menendez — Wed, 17 Dec 2025 17:04:00 +0000

Starting with Xojo 2025r3, macOS apps are built using macOS SDK 26. One benefit of this is that your apps automatically gain access to newer native macOS features with little or no extra work. In some cases, these features are available immediately; in others, they can be enabled with a simple Declare. One such example is allowing users to customize an app’s toolbar.

To demonstrate this, we’ll use the Desktop Toolbar example project that ships with Xojo. You can find it in the Examples section of the New Project window. Open this project using the Xojo 2025r3 IDE.

Once the project is open, locate the MainWindow in the Project Browser. Under MainWindow, select the WindowToolbar item and then choose its Opening event. At the top of the Code Editor for this event, add the following lines of code:

Var hdl As Ptr = Me.Handle
If hdl.Integer <> 0 Then
  Declare Sub AllowCustomization Lib "AppKit" Selector "setAllowsUserCustomization:" (hdl As Ptr, value As Boolean)
  AllowCustomization(hdl, True)
End If

It’s that simple!

Run the app and open the contextual menu by right-clicking (or Control-clicking) on the window’s toolbar. You’ll see a new Customize Toolbar menu item. Select it to open the standard macOS toolbar customization panel, where you can rearrange or remove items as you like. When you click OK, your changes are immediately applied to the current toolbar.

One important caveat: these customizations are not preserved between app launches. This happens because each toolbar must have a unique identifier that macOS uses to save and restore its configuration. Since the example toolbar does not provide one, the OS has nothing to store or retrieve. But… who knows what the future holds?

macOS and iOS: UI Compatibility Mode

Javier Menendez — Tue, 09 Dec 2025 16:31:52 +0000

macOS 26 and iOS 26 bring many changes, most notably a major UI overhaul. This means that some elements in your existing layouts, both small and significant, may look different. To help developers with this transition, Apple has introduced UI Compatibility Mode in both operating systems for this release.

So, what is UI Compatibility Mode? It’s Apple’s way of ensuring that your app’s UI appears in macOS 26 and iOS 26 just as it did on previous OS versions. No Liquid Glass effects, no unexpected changes in control sizes or behavior, everything stays as you designed it. This means your pixel-perfect layouts from older OS versions, like Sequoia or iOS 18, will continue to look exactly as intended.

More technically, when UI Compatibility Mode is enabled, your app behaves as if it were compiled with an earlier SDK.

The caveat: Apple only guarantees this behavior while macOS 26 and iOS 26 are current. With the next major OS releases, this mode may no longer be available, so it’s a temporary solution.

The upside: At the time of writing, Apple is still refining these OS versions with point releases. If you need your app to run on macOS 26 or iOS 26 with full compatibility, you can enable UI Compatibility Mode in the Inspector Panel under Build Settings > macOS and Build Settings > iOS.

When enabled, both your debugged apps and the built versions (including those submitted to Apple via Publish) will look and behave on macOS 26 and iOS 26 as if they were compiled with the previous SDK. In fact, the behavior is even more consistent than if they had been compiled using the prior Xojo release.

Below, you can see how the same app appears when running on macOS 26 and iOS 26 with UI Compatibility Mode turned off (showing Liquid Glass and all the new UI effects), compared to how it looks when the switch is turned on:

The Last Word

All in all, macOS 26 and iOS 26 introduce a major UI overhaul, which can change the appearance of existing layouts. To help developers, Apple has added UI Compatibility Mode, which lets your apps appear on these new OS versions just as they did on previous releases—no Liquid Glass effects or layout changes. Technically, enabling this mode makes your app behave as if it were compiled with an earlier SDK. While Apple only guarantees this behavior for macOS 26 and iOS 26, it ensures consistency for both debugged and built apps, including those submitted via Publish.

UI Compatibility Mode gives you a choice: enable it to preserve your exact layouts across all OS versions, or leave it off to adopt the new macOS 26 and iOS 26 look and feel, which may require adjusting your UI for some quirks.

Introducing Jade, the Xojo AI Assistant

Paul Lefebvre — Tue, 09 Dec 2025 16:31:26 +0000

With Xojo 2025 Release 3, we are introducing Jade, an AI assistant for Xojo. This initial version is primarily for asking general Xojo-related questions and can be used as an alternative to the documentation.

Getting Started

Jade uses Anthropic Claude as its engine, so before using Jade, you first need to sign up for an Anthropic API key to access Claude. You can do this from the Anthropic Claude Console.

From there you can create your account. After you’ve done that, you will want to get an API key to use with Xojo. Click on the “API keys” tab to see existing keys and create new ones. Click the “Create Key” button to generate a new key. In the dialog, give it a name to indicate its purpose.

When you click Add, the actual key will be shown. Copy it to the clipboard.

Note that you cannot see the key again after closing that dialog, but you can always create a new key at any time.

Now go to Xojo Settings and in the General tab, paste it into the “Anthropic API Key” field.

Go back to the Claude Console and click on the Billing tab to buy credits. Interacting with Jade requires credits. The amount of credits used depends on the complexity of your interactions. Until you get used to Jade and credit usage, you’ll probably want to start with a small amount, like $5, and disable auto-reload.

Using Jade

To use Jade, select Help->Ask Jade or click the Ask Jade button in the toolbar. You’ll get some short introductory text. Note: Using Jade requires an internet connection.

You interact with Jade similarly to a chat app by typing prompts in the conversation area (bottom section) and pressing Send. Jade will think for a moment and then display its response.

If Jade’s response includes Xojo source code you can click one of the buttons above the code block to copy the code to the clipboard or to directly insert it into the active code editor.

When interacting with Jade, keep in mind that although it remembers the context from the current conversation, it has no knowledge of prior conversations. Click the “Start Over” button to clear things and start a new conversation. Starting a new conversation is useful when switching to a different topic as it prevents Jade from relying on information you previously discussed that is no longer relevant.

The Export button saves the current Jade conversation to a JSON file which is a great way to save information you want to retain and refer to later.

Other Tips

Jade currently uses Claude Sonnet 4, but this may change as newer models become available.
The only thing Jade knows about your project is what type it is (Desktop, Web, iOS, etc.). If you want Jade to offer suggestions based on your code, you will need to copy/paste the relevant code into the Jade conversation area.
Your Jade conversation is restored when the IDE restarts. If you get errors, ensure that you have valid internet access, that the API key is valid and you have a positive credit amount.

Wrap

We hope you find Jade helpful with your Xojo development. Remember, Jade in Xojo 2025r3 is the first version of an AI assistant for Xojo and will improve over time. In subsequent releases we expect to add more capabilities and project integration. Read more about Jade in Xojo’s Documentation.

Creating Libraries that Support Multiple Project Types

Geoff Perlman — Tue, 09 Dec 2025 16:31:12 +0000

Libraries, introduced in Xojo 2025r3, make it easy to reuse your classes and interface items such as windows, webpages, and mobile screens across projects. As compiled code, Libraries ensure your projects always use a specific version of your functionality while allowing you to share features with other Xojo users without exposing your intellectual property. Think of them like plugins written in Xojo instead of C++, with the flexibility to use them in a single project folder or in the Plugins folder for access across all projects. The Xojo documentation provides guidance on creating your own Libraries.

When you create a Library in Xojo, it’s tailored to the project type you’re working in, whether that is Desktop, Web, Mobile or Console, so everything stays organized and easy to manage. The Library format was designed to support all project types simultaneously; unfortunately, the Xojo IDE was not. The good news is that there are still ways to take advantage of the flexible underlying format. Since Libraries are simply .zip files, you can change the extension to .zip and decompress them to explore their contents. Inside, you’ll find a folder named for the project type you originally created it from, making it easy to understand the structure. Here are two ways to create Libraries that support multiple project types.

Merging Libraries Manually

To manually create a multi-project-type Library, start by building a separate Library for each project type your functionality supports, then change each one’s extension to .zip and decompress it. Choose one decompressed Library to serve as the final version, and copy the project-type folders (Desktop, Web, iOS, Android or Console) from the others into it. When everything is combined, recompress the folder back into a .zip file and change the extension to .xojo_library. You now have a single Library that works across all the project types you included.

Using LibMerge

LibMerge is a utility we created to make it easier to merge Libraries.

Download LibMerge for Linux, macOS or Windows. It will be included in the Extras folder in the next major release.
Launch LibMerge and then click the Add button to select the Libraries you wish to merge or drag them into the Libraries list in the LibMerge window.
On the Info tab, make sure the Version, Copyright and Description values are as you want them for the merged Library. These initial values are loaded from the first Library you add to the list.
Click the Save As button to choose a name and location for your merged Library. That’s it!

If you choose two libraries that both already support the same project type, LibMerge will tell you and not load the second Library. Included with LibMerge is the LibMerge Library which you can use to build the merging of Libraries into your own build tools. Check out the included LibMerge API Guide for details. Here is an example:

Try
   Var merge As New LibMerger
   merge.AddLibrary(SpecialFolder.Desktop.Child("MyDesktopLibrary.xojo_library"))
   merge.AddLibrary(SpecialFolder.Desktop.Child("MyWebLibrary.xojo_library"))
   merge.SaveMergedLibrary(SpecialFolder.Desktop.Child("MergedLibrary.xojo_library"))
Catch error as UnsupportedFormatException
   System.Beep
   MessageBox(error.Message)
End Try

Whether you prefer to roll up your sleeves and merge Libraries manually or let LibMerge handle the heavy lifting, Xojo gives you the flexibility to build reusable components that work across all your project types. With a little exploration and the right tools you can streamline your workflow, reduce duplication and keep your projects cleaner and more maintainable. LibMerge makes this process fast and reliable whether you’re merging two Libraries or twenty. Read more about Libraries in the Xojo Documentation.

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.

New WebUserAuthentication Control: Look, Mom, No Passwords!

Ricardo Cruz — Tue, 09 Dec 2025 16:30:29 +0000

The web framework has a new control available in the Library, WebUserAuthentication. Now that Passkeys have arrived, let’s explore this feature!

Passkeys Demo

In this demo, we will be creating a new account using just our email. Using a platform authenticator, like Apple Passkeys or Windows Hello will make this pretty easy. They are integrated in the operating system and synced across devices. I will be using macOS with the integrated Passwords app, but this is supported in Windows through Windows Hello, or you could store, sync and use Passkeys using a Google Chrome Profile.

As you can see, there is no intermediate step. No need to use a separate app to store your passwords securely. A Passkey will be generated and stored in the authenticator in one simple step. This Passkey will be automatically synced across devices and available on my iPhone.

Opening the Password application, I already can confirm my new Passkey has been stored for “localhost”. Notice the user name is also there, meaning you won’t need to fill it during the login process.

The username isn’t important or even required, it’s just to display a friendly name for this user. A Passkey will include the user ID, which can be any arbitrary String you want. In my example, I’ve used the new Random.UUID method, but this is completely up to you. And this is transparent for the end user.

Now, let’s try to login:

That’s it!

Another thing to notice is, while I have several Passkeys for different websites, only the relevant Passkey can be used. This makes Phishing attacks useless. End users won’t be able to use a Passkey anywhere else, just on the website where it has been created. And also, users won’t be able to send their password by mistake to an attacker because … they can’t!

For web application developers, another interesting thing to note is that you won’t be able to store a Passkey insecurely. Even if your database gets compromised, a hacker won’t be able to use the stored public keys to authenticate those users with another service. To make it easier to understand, you will be storing a lock, not the key used to open it.

Other User Journeys

My demo is just the classic email / password sign up / sign in workflow, but without using a password. Passkeys is based on WebAuthn (part of FIDO2) and there are several ways you can use this technology in your web application. For example, you could use a shared computer and still be able to securely log in using your mobile. The platform will display a QR code you can read with your phone camera, and grant the access from your personal device.

In my example application, the user can sign up using different emails. If the Passwords app encounters more than one for my domain it will allow the user to specify the Passkey to use:

Xojo will take care of preparing the WebAuthn steps, verifying signatures and doing the common busy work for you. You will have to decide which workflow makes sense for your application and perform any further verifications, like sending a verification email on register, to ensure this user owns that account.

Multi-Factor Authentication

If you already require your users to authenticate with a username (or email) and a password, you could use WebUserAuthentication as a second factor. That means the user will need to provide something this person knows (a username and password combination) in addition to something the user has (the authenticator device)

Other common multi-factor authentication schemes are email magic links and time-based one-time passwords, “TOTP”.

More factors equal better security, of course. But as usual when it comes to security, you’ll have to find the sweet spot between secure and comfortable.

Usernameless + Passwordless Authentication … Wait, What?!?

“How can I authenticate without providing my username or email?”. This is where real new possibilities arise. When you use a username with a password that only Chuck Norris and you know, this becomes a “proof of identity” (at least in theory, in practice a hacker could compromise an account using a weak password)

When using an authenticator without a username or password, it becomes a “proof of possession” of the authenticator device.

Again, think about it as a locker’s lock and a key. Everyone can see the lock, but only people with the correct key can open it. The public key would be the door’s lock, while the authenticator device would be the key. You can share the key with another person you trust to grant this person access to the contents behind that door. The difference with a real-life lock is that we will be using a really secure one, with a security key.

As long as you can proof you have a valid “key” to authenticate, you are granted to continue.

Consider the following scenario. The company could have a web application that uses a traditional username + password authentication but, for really special activities, the user needs to authenticate with a physical USB key authenticator device that is shared by everyone in the office.

Other use cases are obviously when privacy is involved. A private journal, or a private blogging service, voting. The inconvenience in this case is the user won’t be able to recover the account if they lose access to the authenticator. In this case, you might want to offer a different recovery solution, like printing a very long recovery code. If they also lose the recovery code, they will permanently lose the account.

How To Use The New Control

As you do with any other non-visual control, like a WebTimer, you can just drop the new WebUserAuthentication control into your WebPage.

Then configure its properties. The most important one is the Domain field. It must match the domain name where your application will be deployed. If you want to test it locally without using HTTPS, it must be “localhost” (“127.0.0.1” won’t work)

There are four events available:

You can use RegistrationSucceeded and AuthenticationSucceeded to interact with your Database, store the details and redirect the user to their dashboard.

In RegistrationSucceeded, a WebAuthenticationCredential will be given to you. This is a data transfer object with the following properties you need to store in your database:

ID
PublicKey
AuthenticationAttempts
DisplayName

Error will be fired when something goes wrong. A message will also show with the details about what happened, but it isn’t meant to be shared with the end user. During the sign up and sign in processes, you should display generic messages for security, to avoid letting bad actors know what’s going on. If you need to inform the user something related to these messages, you can send them an automated email instead.

CredentialRequested will be fired during the authentication ceremony. A userId and a credentialId will be given to you, and you should return a new WebAuthenticationCredential instance with the details coming from the RegistrationSucceededEvent.

Also, when AuthenticationSucceeded happens, the event will come with an authenticationAttempts parameter. This will be an incremental value used to update your credentials. This is part of the WebAuthn protocol sign in ceremony used to detect cloned authenticators, which is supported by Xojo. Please notice this value might come always as “0” when using Safari, for example, but Google Chrome will increase its value each time.

You can initiate a Registration or Authentication ceremony by calling Register or Authenticate, respectively.

Register(userId As String, username As String = “”, displayName As String = “”)
The parameter userId is required, the new credential will be built specifically for it. It can be anything that makes sense in your application, like an auto-incremental number or a random UUID . The other parameters are meant for giving the credential a friendly name. The username could be a nickname, or an email. In workflows where you allow the user to store more than one passkey, the displayName could be something like “Backup key”.
Authenticate(Optional allowCredentials() As String)
This will initiate the authentication ceremony. You can optionally pass an array of credential IDs, allowed for the user trying to get access to the protected resource.

Adoption and Compatibility

Not every user may know they even exist, what they are, how they work or if they will be more secure than using their pet’s name and birthdate. This can cause some friction. Other users that adopted the usage from day one might have at least two physical USB keys. They expect your application to allow them to enter more than one, just in case they lose their main USB key.

Passkeys are here to stay and their adoption will continue growing on web services. That said, depending on the combination of operating system and browser, there are some gotchas. Google Chrome or Firefox should work on every operating system. Apple users will probably obtain the best user experience if they’re tied to this ecosystem. Linux users using alternative browsers could experience some challenges.

If compatibility is a must for your application, you should still offer an alternative to Passkeys. For example, legacy passwords, or “magic login links” sent by email.

Wrapping Up

We are sure Passkeys will be the norm in the coming years. Read more in the Xojo Docs. Xojo is ready to embrace them and you can start adopting them in your Xojo Web application today!

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.

Welcome to the Grid

Javier Menendez — Tue, 09 Dec 2025 16:29:53 +0000

Xojo 2025r3 introduces the first iteration of the DesktopGrid control. This long-awaited control allows you to display as many rows and columns as needed, making it ideal for complex data layouts. Let’s take a closer look at some of its features.

Like other controls in the Xojo framework, DesktopGrid is a data-source-based control. Instead of manually adding cells, rows, or columns as you would with a ListBox, the DesktopGrid itself requests the data it needs when it needs it. This approach brings several benefits:

ContainerControl-based cells: The cells in a DesktopGrid are full ContainerControls, just like the ones you’re already familiar with. You can use the same layout for all cells or customize different layouts for individual cells, rows, or columns. Each cell represents a live control and behaves accordingly.

Lower memory footprint: DesktopGrid keeps only the cells that are currently visible on screen “alive,” which significantly reduces memory usage, especially when working with very large data sets. For example, when you resize the containing window, the DesktopGrid will request additional content from its DataSource only if necessary. When cells move outside the visible area of the DesktopGrid, their corresponding ContainerControl instances are “closed,” triggering an event you can handle, and freeing the memory they were using.
Faster execution: Large data sets are not preloaded into the control. This means that opening a window with a DesktopGrid or running an app with many cells happens almost instantly, providing a smooth and responsive experience even with extensive data.

Layout Flexibility: Since the number of rows and columns is determined by the DataSource, a DesktopGrid instance can have a flexible layout rather than a rigid, static one. For example, you can adjust the number of columns based on the available width of the DesktopGrid. You can also set different widths for individual columns, while the row height remains fixed.

Data representation changes “on the fly”: Because the DataSource provides the content for each cell, you can dynamically change the data representation (the ContainerControl layout) at runtime or even pull data from a completely different source.
A better separation of responsibilities: While you can implement the GridDataSource interface directly on the DesktopGrid or in its containing Window, using a dedicated DataSource class is the cleaner approach. This ensures a clearer separation between the view (the DesktopGrid), the model (the data feeding the cells), and the controller (which manages interactions between the two). A single DataSource can also feed multiple DesktopGrid instances, making your code more reusable.
Headers everywhere: By default, DesktopGrid displays column and row headers. You can modify this in the Inspector Panel or via code. Depending on your scenario, you might choose to show both headers, just one, or hide them entirely. By default, the headers display simple numbering for each column and row. However, you can fully customize their content using the PaintHeaderContentForColumn and PaintHeaderContentForRow methods of your GridDataSource implementation, giving you complete control over how headers appear.

Is the DesktopGrid a replacement for DesktopListBox?

While you can use DesktopGrid for many purposes, it is not a direct replacement for DesktopListBox in all scenarios. If your data is primarily textual (like simple labels) or relies on features specific to DesktopListBox, such as hierarchical data representation, then DesktopListBox is still the better choice.

DesktopGrid shines in scenarios where you need complex layouts in each cell using live controls rather than temporary pictures or workarounds. Each cell can have its own layout, including interactive controls such as ListBoxes, buttons, or other reactive elements that respond to user interactions. This makes DesktopGrid ideal for rich, interactive, and highly customizable grid layouts.

Performance Caveats to Consider

Although the first iteration of DesktopGrid was designed with performance in mind, there are some factors that may affect its redraw speed. The most significant is that each cell uses live controls, so performance will be similar to placing the same number of controls directly on a Window. While alternative approaches—such as reusable cells or backing picture representations—could improve speed, they come with their own trade-offs.

As a general rule, performance depends on cell size and the number of visible cells at any given time. A large DesktopGrid with many rows and columns, even if each cell contains just a simple label, may experience slower refresh rates. Additionally, actual performance can vary depending on the operating system and its version, as these affect the underlying drawing and refresh processes.

Wiring the Grid

Although this is just the first iteration of the DesktopGrid control, we are already working on the next set of features while further refining the existing ones. You can read more about this control in the Xojo Documentation. We want to extend a big THANK YOU to everyone who provided feedback and dedicated their time testing the Grid during the beta cycle, you know who you are! Your input is invaluable, and the feature requests you submitted (combined with others already on our roadmap) will help shape a DesktopGrid that better fits your needs.

Optimizing Xojo Code, Part 2: Using a Timer to Keep the UI Responsive

Gabriel Ludosanu — Tue, 25 Nov 2025 16:00:00 +0000

Welcome back! If you missed the first part in this series, check out Optimizing Xojo Code, Part 1: Getting Started, where we dissected the blocking While loop that counted up to kCountTo, updated a label, and kept the UI responsive only by calling App.DoEvents. That code works, but it spends most of its life running on the UI thread. In this tutorial we’ll rebuild that workflow step by step and end up with the first optimized solution: a timer-driven solution that keeps the interface responsive.

Step 1: Let’s sketch the goal

We will need a button that, when pressed, starts a simulated wait that updates a label every 100 ms until a fixed duration (kCountTo, which remains 20000 ms in our example) is reached. So, the timer will fire periodically and handle the counting there. The button simply resets state and starts the timer.

Step 2: Prepare the UI components

Create a DesktopLabel named StatusLabel to display progress.
Add a DesktopButton (caption it “Method 1”) whose Pressed event will kick off the timer.
Finally, place a Timer control onto the window, name it mTimer, set its Period to 100, and set RunMode to Multiple (but leave it off until the button starts it).
Add an Integer property to the window such as mMsWaited to accumulate elapsed milliseconds, and keep kCountTo defined as 20000.

Step 3: Wire up the button

The button handler becomes very simple. Reset the tracked milliseconds, show "0" in the label, ensure the timer runs at 100 ms ticks, and let it fire repeatedly:

Sub Pressed()
  // Reset the tracked elapsed ms and start the timer at 100 ms ticks.
  mMsWaited = 0
  StatusLabel.Text = "0"
  mTimer.Period = 100
  mTimer.RunMode = Timer.RunModes.Multiple
End Sub

This code primes the state but does not block. The timer will perform the actual counting.

Step 4: Let the timer take over

Implement mTimer.Action to run on the UI thread. Each tick adds the timer’s period to mMsWaited, updates the label, and turns itself off once kCountTo has been reached:

Sub Action()
  mMsWaited = mMsWaited + Me.Period

  If mMsWaited >= kCountTo Then
    Me.RunMode = Timer.RunModes.Off
    StatusLabel.Text = "done"
  Else
    StatusLabel.Text = mMsWaited.ToString
  End If
End Sub

This keeps your UI responsive because the timer fires briefly and returns control back to the event loop instead of spinning inside a While loop.

Step 5: Test the flow

Run the app, click the button previously created and watch the label count up and stop at the target value. The timer approach lets other interface interactions remain responsive while still providing clear progress feedback.

What makes this timer driven solution a solid first step?

It shows how you can preserve the original behavior while giving the UI breathing room. It avoids App.DoEvents, reduces tight loops, and still delivers frequent updates. In the next article we’ll build on this idea and explore alternative approaches that continue to improve responsiveness and structure.

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!

Optimizing Code Series:

Optimizing Xojo Code, Part 1: Getting Started

Gabriel Ludosanu — Thu, 20 Nov 2025 15:50:38 +0000

We all write code that works. It compiles, it runs, and it accomplishes its task. But sometimes, “working” isn’t quite the same as “optimal.” Optimization is about making your applications faster, more responsive, and more efficient, leading to a better experience for the end-users.

Let’s look at a small, functional snippet of Xojo code. It does its job but it has room to grow, to become more polished.

The Code in Question

Important Disclaimer

Xojo 2025r2.1: Publishing macOS Apps Under Tahoe

Javier Menendez — Tue, 14 Oct 2025 21:20:03 +0000

macOS 26 is in the wild, and many Xojo users have likely updated their Macs to the latest version. While Xojo 2025r2.1 is compatible and can build apps that run under the latest macOS, the Publish feature depends on certain tools provided by Xcode. Unfortunately, one of these tools has undergone a significant change in the latest Xcode release, causing the Publish feature to no longer function correctly.

There are two possible solutions:

If your Mac still runs under macOS 15.7 Sequoia (or an earlier macOS version supported by Xojo’s Publish feature) with Xcode 26 installed, you can restore Publish feature compatibility by installing Xcode 16.4.x and making that version the active one in your toolchain (especially if you have multiple Xcode versions installed).
If your Mac is running macOS 26.x Tahoe with Xcode 26 installed, Xojo’s Publish feature for macOS apps won’t work as expected, specifically when it attempts to retrieve the AppID from the App Store Connect. The good news is that by the time this error occurs, your app has already been successfully compiled and the .pkg file created. You can use Apple’s Transporter app to complete the final step of uploading the .pkg file to App Store Connect.

This issue has been fixed and the solution will be included in Xojo 2025r3. The update also improves how the App ID is retrieved by relying on the available provider listing. This rare issue could affect users whose Apple ID is associated with multiple publishing services, for example, if the same Apple ID is used for both app development and podcast publishing.

Once Xojo 2025r3 is released, the Publish feature will work as before on macOS Sequoia (and previous supported macOS versions), and it will also function properly with the new Xcode 26 toolchain – whether installed on Sequoia or on the latest macOS 26. Read more about Xojo Support for macOS 26 and iOS 26 on the Xojo Blog.

How To Create a Custom Button Control in Xojo – Part 5: Adding Text Alignment

Gabriel Ludosanu — Wed, 08 Oct 2025 15:54:00 +0000

In our previous installment, we successfully wired up keyboard focus to our custom DesktopCanvas subclass, making it fully accessible and user-friendly.

Now, we’re going to tackle another key feature: customizable text alignment. By the end of this tutorial, you’ll be able to set the button’s text to align left, center, or right, and we’ll introduce a small amount of padding to keep the text from touching the edges when it’s not centered. This approach uses a strongly typed Enumeration to ensure we only accept valid alignment values, maintaining the high quality of our custom control.

1. Define the Text Alignment Options

To make our alignment property easy to use and type-safe, we will define a new enumeration inside the CanvasButton class.

Inside your CanvasButton class, go to Insert > Enumeration and add the following:

  Left = 0
  Center = 1
  Right = 2

2. Add New Properties for Alignment and Padding

Next, we need two new properties in the CanvasButton class to store the selected alignment and the padding value.

The TextAlignment property will use our new TextAlign enumeration, and, crucially, it defaults to TextAlign.Center.
The TextPadding property provides an adjustable inner margin, which is especially important for left and right alignment.

Public Property TextAlignment As TextAlign = TextAlign.Center
Public Property TextPadding As Integer = 8

3. Update the Paint Method

The core of this change happens in the Paint event handler. We need to modify the logic that calculates the horizontal position of the text (tx) to respect the value of our new TextAlignment property.

Locate the Paint event and replace the existing code with the following:

Sub Paint(g As Graphics, areas() As Rect) Handles Paint
  #Pragma unused areas
  
  // Use the custom CornerRadius property.
  Var currentCornerRadius As Integer = CornerRadius
  
  // Declare variables for the colors used in drawing.
  Var currentBgColor As Color
  Var currentBorderColor As Color
  Var currentTextColor As Color
  
  // Determine colors based on the button's current state (enabled, pressed, hovered).
  If Enabled Then
    If IsPressed Then
      // Use highlight color if pressed.
      currentBgColor = HighlightColor
      currentBorderColor = BorderColor
      currentTextColor = TextColor
    ElseIf IsHovered Then // Check for hover only if not pressed
      // Use hover color if hovered.
      currentBgColor = HoverColor
      currentBorderColor = BorderColor
      currentTextColor = TextColor
    Else
      // Use the custom background color for the default state.
      currentBgColor = BackgroundColor
      currentBorderColor = BorderColor
      currentTextColor = TextColor
    End If
  Else
    // Use appropriate system or standard gray colors for the disabled state.
    currentBgColor = Color.LightGray
    currentBorderColor = Color.Gray
    currentTextColor = Color.DisabledTextColor // Use system disabled text color
  End If
  
  // Set the drawing color and draw the background shape with rounded corners.
  g.DrawingColor = currentBgColor
  g.FillRoundRectangle(0, 0, g.Width, g.Height, currentCornerRadius, currentCornerRadius)
  
  // Set the drawing color and pen size for the border.
  g.DrawingColor = currentBorderColor
  g.PenSize = 2
  // Draw the border shape just inside the background rectangle.
  g.DrawRoundRectangle(0, 0, g.Width, g.Height, currentCornerRadius, currentCornerRadius)
  
  // Draw the focus ring
  If IsFocused And AllowFocusRing Then
    g.DrawingColor = Color.HighlightColor
    g.PenSize = 1
    g.DrawRoundRectangle(2, 2, g.Width-4, g.Height-4, CornerRadius-2, CornerRadius-2)
  End If
  
  // Enable anti-aliasing for smoother text rendering.
  g.AntiAliasMode = Graphics.AntiAliasModes.HighQuality
  g.AntiAliased = True
  // Calculate the width and height of the button text.
  Var tw As Double = g.TextWidth(ButtonText)
  Var th As Double = g.TextHeight
  // Calculate the X position to center the text horizontally.
  // Updated: compute X based on TextAlignment (Left, Center, Right) while preserving centered behavior as default.
  Var tx As Double
  Select Case TextAlignment
  Case TextAlign.Left
    tx = TextPadding
  Case TextAlign.Right
    tx = g.Width - tw - TextPadding
  Case TextAlign.Center
    tx = (g.Width - tw) / 2
  End Select
  // Calculate the Y position to center the text vertically, with a small adjustment.
  Var ty As Double = (g.Height + th) / 2 - 3
  // Set the drawing color for the text.
  g.DrawingColor = currentTextColor
  // Draw the button text at the calculated centered position.
  g.DrawText(ButtonText, tx, ty)
End Sub

The magic happens at line 60

4. Inspector Integration

If you want the alignment to be easily adjustable in the Xojo Inspector, you should expose the TextAlignment and TextPadding properties. For TextAlignment, because it uses an Enumeration, Xojo will automatically display a helpful dropdown menu with Left, Center, and Right options once you expose it through the Inspector Behavior editor.

Right-click the CanvasButton class in the Project Navigator.
Select ‘Inspector Behavior…’
Scroll through the property list and check the checkboxes for both TextAlignment and TextPadding.

Try It Out

You can now set the text alignment directly in the code or via the Inspector.

For example, to set alignment in code:

// Set the button to right-aligned text
MyCanvasButton.TextAlignment = CanvasButton.TextAlign.Right

Since the default value for TextAlignment is Center, no existing code needs to be modified, and all your current custom buttons will continue to render perfectly centered unless you explicitly change the alignment property.

Hope this update was useful.

You can grab the latest source on GitHub: GitHub – CanvasButton

Learning – Xojo Programming Blog

Conditional Compilation in Xojo: #If False and #If True

What Is Conditional Compilation?

#If False – Completely Excluding Code

Why Not Just Comment It Out?

#If True – Always Including Code

When Is #If True Useful?

Defining Custom Compiler Constants

Best Practices

Conclusion

Build a Simple Find in Files Function

What this Find in Files function will do

Step 1: A class in a module and some properties

Step 2: Walk through the folder

Step 3: Read files line by line

Step 4: Match the text

Step 5: The full module and class and function

How it works

Input validation

Folder iteration

Safe text reading

Line-by-line matching

Why keep SearchHit inside the module?

Using the function

Practical limitations of this version

It assumes UTF-8

It doesn’t recurse into subfolders

Final thoughts

Jade Improvements

Custom Control Rendering with DrawControlInLayoutEditor

Why this matters

How it works

A note about XojoScript limitations

Support for more Graphics

Turning off this feature

Finally

Watchpoints in Xojo: A Smarter Way to Track Your Data

What Are Watchpoints?

How Watchpoints Work

Why This Matters

Conditional Watchpoints

Handling Object Lifetimes

What works and what doesn’t

Final Thoughts

Code Signing on macOS: What Developers Need to Know, Part 3

Entitlements and Provisioning Profiles

Entitlements

Provisioning Profiles

When Certificates and/or Provisioning Profiles expire…

Nearly Concluded

Code Signing on macOS: What Developers Need to Know, Part 2

Installing Apple Developer Intermediate Certificates

Developer Certificates: The final goal!

Creating and Installing the Developer Certificates

It’s All About Identities

Code signing With Developer Certificates

Wrapping up

Code Signing on macOS: What Developers Need to Know, Part 1

Under the hood: How “Ad-Hoc” signing works

Apple Developer Certificates: Establishing Trust on macOS

Intermediate Certificates and the Chain of Trust

Wrapping up

Optimizing Xojo Code, Part 5: Threads and UserInterfaceUpdate

The Core Idea: Threads

Let’s Code

The Thread Control

The Button (Start the Thread)

The Thread.Run Method (Background Work)

The Thread.UserInterfaceUpdate Method (UI Sync)

How It Works

A Note on Thread Safety

When to Use Threads vs. Timers

Wrapping Up

Scatter Chart: Connecting the Points

A change of Style… on the fly!

Summary

Optimizing Xojo Code, Part 4: Timer.CallLater

The Strategy: Timer.CallLater

Looking at the Code

The Setup (Button Pressed)

When Is `#If True` Useful?

Why keep `SearchHit` inside the module?