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

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

Why this matters

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

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

How it works

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

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

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

A note about XojoScript limitations

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

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

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

Support for more Graphics

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

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

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

Class LinearGradientBrush

  Sub Constructor()

  Sub AddStop(stop As Double, c As Color)

  Property StartPoint As Point
  Property EndPoint As Point

End Class

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

Turning off this feature

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

Finally

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

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

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

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!

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

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

Stability and Modernization

Under the hood, we’ve updated the Web framework to use Bootstrap v5.3.8 and set the TypeScript target to ES2020. Windows users will notice better WinUI support for DesktopTabPanel and DesktopGroupBox, along with fixes for Dark Mode consistency.

You can find the exhaustive list of every change in the Xojo 2026r1 Release Notes.

Xojo 2026r1 is a free update for everyone.
Download Xojo 2026r1 now.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

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:

1. Go to Xcode > Preferences.
2. Select Apple Accounts.
3. Use your developer credentials to login into your developer account, or select it from the list if you are already logged.
4. Select the Team from the list.
5. Click the “Manage Certificates…” button.
6. 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:

1. Access the Apple Developer website.
2. In Certificates, Identifiers & Profiles, click Certificates in the sidebar.
3. On the top left, click the add button (+).
4. 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.
5. Follow the instructions to create a certificate signing request.
6. Click Choose File.
7. In the dialog that appears, select the certificate request file (a file with a .certSigningRequest file extension), then click Choose.
8. Click Continue.
9. Click Download.
10. The certificate file (a file with a .cer file extension) appears in your Downloads folder.
11. 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:

1. 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.
2. 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).
3. 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.

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

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

Code Signing on macOS: What Developers Need to Know

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

Then I remembered Extends.

It’s one of those features that sits quietly in the language. But once it clicks, it changes how you think about utility code entirely. Using Extends, within twenty minutes, my nested mess became readable.

Extends Methods in Practice

You know the feeling. You’re writing ParseLogEntry(rawLine) for the hundredth time, and something feels off. The function works. It’s in your Utilities module (maybe part of a Library?). But every time you call it, there’s this tiny friction. Why doesn’t String just know how to parse itself into a log entry? That’s what Extends fixes.

It lets you teach existing classes new tricks. You write a method in a module, tag the first parameter with Extends, and suddenly String, DateTime, Dictionary (whatever you need) behaves like it always had that method. No subclassing. No wrapper classes. Just the framework, extended to fit your brain.

Reading The Code

Code is read far more than it’s written. We both know this. But we still write code that reads backwards.

// The old way
Var result As DateTime = ExtractTimestamp(CleanLogEntry(rawLine))

// With Extends
Var result As DateTime = rawLine.CleanLogEntry.ExtractTimestamp

When you’re debugging at 2 AM, tracing logic through nested function calls is the last thing you want. Extension methods turn that horizontal scan into a vertical one.

When Extends is Exactly Right

I don’t use Extends for everything; it’s not a replacement for proper inheritance or composition. But there are specific moments when it’s exactly right.

Built-in types that need one more method. For my log parser, I needed to extract timestamps, clean junk characters, and pull out ISO dates. So, I extended the String class with my custom utilities and made it feel native.

Framework classes you can’t touch. You can’t subclass everything, but Extends can work around things like things third-party plugins, legacy code.

APIs you wish existed. I’ve lost count of how many times I’ve wanted a property or method on a framework class that just isn’t there. Extends lets me do just that.

For practical examples like email validation, URL validation, and dictionary helpers, check out this article that walks you through real implementations. If you want code you can copy into your project today, it’s a good place to start.

A Few Things To Keep In Mind

Nil doesn’t forgive. Call an extension on a Nil object and you’ll get a NilObjectException before your method even runs. The extension sits on the right side of the dot. That object needs to exist.

No override. You can’t replace built-in methods. If you try creating an extension with the same name as an existing method, the compiler will use the original. That’s a good thing; it means you can’t accidentally break framework behavior.

No properties. Extensions add behavior, not state. If you need to store data, you still need a subclass or a wrapper.

Stay organized. Put extensions in well-named modules like LogParsingExtensions or StringHelpers. Six months from now, you’ll want to know where that .ExtractTimestamp method came from.

Dependencies can hide. Extension methods live in modules and behave like native methods, so it’s not always obvious which module a class depends on. Good naming helps.

Trying Extends

If you’ve never written an extension method, take five minutes. Add a module to your project and create a method like this:

Public Function ExtractFirstISODate(Extends source As String) As DateTime
  Var rx As New RegEx
  rx.SearchPattern = "(\d{4}-\d{2}-\d{2})[Tt]?(\d{2}:\d{2}:\d{2})"
  
  Var match As RegExMatch = rx.Search(source)
  If match <> Nil And match.SubExpressionCount > 1 Then
    Var datePart As String = match.SubExpressionString(1)
    Var timePart As String = match.SubExpressionString(2)
    Var isoString As String = datePart + " " + timePart
    
    Try
      Return DateTime.FromString(isoString)
    Catch err As RuntimeException
      Return Nil
    End Try
  End If
  Return Nil
End Function

Now you can call it directly on any string:

Var logLine As String = "[2025-08-14T14:32:15] ERROR: Connection timeout"

Var timestamp As DateTime = logLine.ExtractFirstISODate

If timestamp <> Nil Then
  MessageBox("Found timestamp: " + timestamp.ToString)
Else
  MessageBox("No valid timestamp found")
End If

That’s it. No utility class to instantiate. No module name to remember. Just stringVar.ExtractFirstISODate.

For more complete examples, check out the Extension Methods topic in the Xojo Documentation.

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

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

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

1. Button press: Click the button and the thread starts.
2. Background loop: The thread iterates from 0 to kCountTo, sleeping 10 ms each step. After each step, it queues an update.
3. 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!

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

Optimizing Code Series:

• Optimizing Xojo Code, Part 1: Getting Started
• Optimizing Xojo Code, Part 2: Using a Timer to Keep the UI Responsive
• Optimizing Xojo Code, Part 3: Programmatic Timers and AddHandler
• Optimizing Xojo Code, Part 4: Timer.CallLater
• Optimizing Xojo Code, Part 5: Threads and UserInterfaceUpdate

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

1. 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).
2. Recursion: Each call updates the UI and, if not finished, schedules the next one 100ms in the future with incremented elapsed time.
3. Automatic Management: No Timer properties or handlers to manage; Xojo handles scheduling and cleanup.
4. 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!

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

Optimizing Code Series:

• Optimizing Xojo Code, Part 1: Getting Started
• Optimizing Xojo Code, Part 2: Using a Timer to Keep the UI Responsive
• Optimizing Xojo Code, Part 3: Programmatic Timers and AddHandler
• Optimizing Xojo Code, Part 4: Timer.CallLater
• Optimizing Xojo Code, Part 5: Threads and UserInterfaceUpdate

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:

1. Define one or more VisualStates in XAML.
2. Attach transitions to those states (for example, moving or fading an element).
3. 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.

<UserControl>
  <Grid>
    <VisualStateManager.VisualStateGroups>
      <VisualStateGroup Name="FlameStates">

        <VisualState Name="Bottom">
          <Storyboard>
            <DoubleAnimation
              Storyboard.TargetName="FlameTransform"
              Storyboard.TargetProperty="Y"
              To="40"
              Duration="0:0:1" />
          </Storyboard>
        </VisualState>

        <VisualState Name="Top">
          <Storyboard>
            <DoubleAnimation
              Storyboard.TargetName="FlameTransform"
              Storyboard.TargetProperty="Y"
              To="-100"
              Duration="0:0:1" />
          </Storyboard>
        </VisualState>

      </VisualStateGroup>
    </VisualStateManager.VisualStateGroups>

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

      <TextBlock.RenderTransform>
        <TranslateTransform Name="FlameTransform" />
      </TextBlock.RenderTransform>

    </TextBlock>
  </Grid>
</UserControl>

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:

<UserControl>
  <Grid Width="160" Height="240">

    <!-- Fire emoji 1 -->
    <TextBlock Name="Fire1"
           Text="🔥"
           FontSize="32"
           VerticalAlignment="Bottom"
           HorizontalAlignment="Center">
      <TextBlock.RenderTransform>
        <TranslateTransform Name="Move1"/>
      </TextBlock.RenderTransform>
    </TextBlock>

    <!-- Fire emoji 2 -->
    <TextBlock Name="Fire2"
           Text="🔥"
           FontSize="26"
           VerticalAlignment="Bottom"
           HorizontalAlignment="Center"
           Margin="20,0,0,0"
           Opacity="0.8">
      <TextBlock.RenderTransform>
        <TranslateTransform Name="Move2"/>
      </TextBlock.RenderTransform>
    </TextBlock>

    <!-- Fire emoji 3 -->
    <TextBlock Name="Fire3"
           Text="🔥"
           FontSize="22"
           VerticalAlignment="Bottom"
           HorizontalAlignment="Center"
           Margin="-20,0,0,0"
           Opacity="0.7">
      <TextBlock.RenderTransform>
        <TranslateTransform Name="Move3"/>
      </TextBlock.RenderTransform>
    </TextBlock>

    <VisualStateManager.VisualStateGroups>
      <VisualStateGroup Name="FireStates">

        <VisualState Name="Off"/>

        <VisualState Name="On">
          <Storyboard RepeatBehavior="Forever">

            <!-- Fire 1 -->
            <DoubleAnimation Storyboard.TargetName="Move1"
                     Storyboard.TargetProperty="Y"
                     From="0"
                     To="-180"
                     Duration="0:0:1.2"/>

            <DoubleAnimation Storyboard.TargetName="Move1"
                     Storyboard.TargetProperty="X"
                     From="0"
                     To="10"
                     Duration="0:0:0.6"
                     AutoReverse="True"/>

            <!-- Fire 2 -->
            <DoubleAnimation Storyboard.TargetName="Move2"
                     Storyboard.TargetProperty="Y"
                     From="0"
                     To="-160"
                     Duration="0:0:1.0"
                     BeginTime="0:0:0.3"/>

            <DoubleAnimation Storyboard.TargetName="Move2"
                     Storyboard.TargetProperty="X"
                     From="0"
                     To="-12"
                     Duration="0:0:0.5"
                     AutoReverse="True"/>

            <!-- Fire 3 -->
            <DoubleAnimation Storyboard.TargetName="Move3"
                     Storyboard.TargetProperty="Y"
                     From="0"
                     To="-140"
                     Duration="0:0:1.4"
                     BeginTime="0:0:0.15"/>

            <DoubleAnimation Storyboard.TargetName="Move3"
                     Storyboard.TargetProperty="X"
                     From="0"
                     To="8"
                     Duration="0:0:0.7"
                     AutoReverse="True"/>

          </Storyboard>
        </VisualState>

      </VisualStateGroup>
    </VisualStateManager.VisualStateGroups>

  </Grid>
</UserControl>

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.

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

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

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

1. New Timer: We create a new instance of the Timer class in memory.
2. 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.
3. 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!

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

Optimizing Code Series:

• Optimizing Xojo Code, Part 1: Getting Started
• Optimizing Xojo Code, Part 2: Using a Timer to Keep the UI Responsive
• Optimizing Xojo Code, Part 3: Programmatic Timers and AddHandler
• Optimizing Xojo Code, Part 4: Timer.CallLater
• Optimizing Xojo Code, Part 5: Threads and UserInterfaceUpdate

Test 1

Var rs As rowset = SQLiteDatabase1.SelectSQL("SELECT invoices.invoiceno, invoices.invoicedate, invoices.invoiceamount, customers.firstname, customers.lastname FROM Invoices JOIN Customers ON invoices.customerid = customers.id")
Results1.RemoveAllRows
Var grandTotal As Integer
Var totalIterations As Integer  = 10
For i As Integer = 1 To totalIterations
  Var start As Integer = System.Microseconds
  For Each row As databaserow In rs
    ListBox1.AddRow(rs.Column("InvoiceNo"), rs.Column("lastname"), rs.Column("firstname"), rs.Column("InvoiceDate"), rs.Column("InvoiceAmount"))
  Next
  Var stop As Integer = System.Microseconds
  Var total As Integer = stop - start
  grandTotal = grandTotal + total
  Results1.AddRow("Test " + i.ToString + ": " + total.ToString)
Next
Var avg As Integer = grandTotal / totalIterations
results1.AddRow("Average: " + avg.ToString)

Test 2

Var rs As rowset = SQLiteDatabase1.SelectSQL("SELECT invoices.invoiceno, invoices.invoicedate, invoices.invoiceamount, customers.firstname, customers.lastname FROM Invoices JOIN Customers ON invoices.customerid = customers.id")
Results2.RemoveAllRows
Var grandTotal As Integer
Var totalIterations As Integer  = 10
For i As Integer = 1 To totalIterations
  Var start As Integer = System.Microseconds
  For Each row As databaserow In rs
    ListBox1.AddRow(rs.Column("InvoiceNo"), rs.Column("lastname"), rs.Column("firstname"), rs.Column("InvoiceDate"), rs.Column("InvoiceAmount"))
    ListBox1.RowTagAt(ListBox1.LastAddedRowIndex) = row
  Next
  Var stop As Integer = System.Microseconds
  Var total As Integer = stop - start
  grandTotal = grandTotal + total
  Results2.AddRow("Test " + i.ToString + ": " + total.ToString)
Next
Var avg As Integer = grandTotal / totalIterations
results2.AddRow("Average: " + avg.ToString)

I assumed the second test would take longer since it’s doing the extra step of assigning the row to the RowTag property. However, when I ran the test, something curious occurred. The second test, rather than taking more time to complete, took less. This made no sense to me. It’s doing more so it should take longer. It’s not logical that asking it to do more would result in the task taking less time. After examining my code, I could not find any issues with it.

I modified the code to run each test 10 times then compute the average of all 10 tests. Depending on the run, the average time for Test 2 was nearly always shorter. Occasionally the average for Test 1 would be shorter than Test 2 but rarely. In fact, on my M4-based MacBook Pro, Test 2’s average was, in most cases, anywhere from 5% to 25% faster than Test 1. Next I tested it on an M1-based MacBook Pro with similar results. Then I tested it on an x86-based PC running Windows 11. This time Test 2 was slightly slower than Test 1 as I had been expecting from the beginning. Last but not least, I tested on Windows 11 running via Parallels on my MacBook Pro, compiling for ARM-64. In this test, Test 2 was indeed faster. I tried running these tests by changing the order (Test 1 then Test 2 followed by Test 2 then Test 1) and by quitting between runs. None of that seemed to matter.

The difference appears to be ARM. It could be the compiler or the CPU. Our Director of Engineering, Travis Hill, suspects that perhaps something like the branch predictor in the CPU is hopping a tiny bit faster because of the extra assignment and thus can better predict the next operation with the For Each loop. That could be. The timing is in microseconds so the difference is so small that for my purposes, it doesn’t matter. However, that it’s faster to do more work in this case is fascinating and unexpected.

In any case, it’s interesting to see code behave in a way that is so counterintuitive. Asking the method to do more, at least on ARM-based machines, caused the method to take less time.

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

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

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.

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

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

We’re taking a similar approach with our WinUI transition. We began with the DesktopXAMLContainer and are continuing by updating our Win32 controls to their WinUI counterparts, aiming for steady progress without disrupting existing workflows.

What can you look forward to in 2025r3?

We’ve expanded our WinUI offerings in this release with a broader set of updated controls. While 2025r2 introduced only a handful of WinUI-backed controls, 2025r3 builds on that foundation by updating a much larger group, including: BevelButton, Label, UpDownArrow, DateTimePicker, ComboBox, PopupMenu, RadioGroup, SegmentedButton, DisclosureTriangle, MoviePlayer, SearchField, TextField, and TextArea.

What are the benefits of using WinUI?

Win32 controls have been the foundation for many Windows apps, but WinUI introduces capabilities that traditional Win32 controls don’t have. Here’s a comparison to highlight some of the differences:

A Win32 DesktopLabel with a colored emoji is rendered in black and white.

Compared to the WinUI version with a colored emoji.

A Win32 DesktopTextField containing right-to-left text isn’t automatically recognized as such, so it renders left-to-right.

Compared to the WinUI version which can automatically detect right-to-left text and formats accordingly.

A password field (via DesktopTextField) with primitive support on Win32.

An actual WinUI version of their PasswordBox control with a preview widget.

A Win32 DesktopComboBox which does not support separators.

A more modern looking WinUI version with built-in support for separators.

A Win32 DesktopDateTimePicker with a dropdown calendar, but does not support dark mode.

A more modern looking WinUI version that also supports dark mode.

Win32 dark mode support is limited.

WinUI dark mode support is easier on the eyes.

The Win32 DesktopMoviePlayer is very dated.

WinUI has a much more modern look and feel.

Opt-in to WinUI

If you’d like to preview how your apps look and feel with WinUI controls, open the Windows build settings and check the options under the Advanced widget tab. Selecting “Use WinUI” applies WinUI styling to your desktop controls while keeping them scaled to your existing Win32 control bounds. Opting into “Native Control Sizes” gives you a more accurate representation of a true WinUI app, using the larger default font size and correspondingly larger controls.

More Work Ahead

As we continue down this path, we’re uncovering pain points that developers face when using WinUI controls in a Win32 environment—challenges Microsoft is no doubt familiar with as well. It will take time before we can fully move away from Win32 controls/windows and embrace WinUI, but we’re steadily heading in that direction. Thanks for joining us on this experience, more to come!

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

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

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.

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

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

Setup (3 lines you’ll reuse)

Var re As New RegEx
Var opt As New RegExOptions
re.Options = opt

1) Replace all occurrences (word boundary)

Goal: a → the (whole word)

Var re As New RegEx
Var opt As New RegExOptions
opt.ReplaceAllMatches = True
re.Options = opt

re.SearchPattern = "\ba\b"
re.ReplacementPattern = "the"
MessageBox(re.Replace("a bus on a street in a town"))
' the bus on the street in the town

2) Strip HTML tags

Var re As New RegEx
Var opt As New RegExOptions
opt.ReplaceAllMatches = True
re.Options = opt

re.SearchPattern = "<[^<>]+>"
re.ReplacementPattern = ""
MessageBox(re.Replace("<p>Hello <b>world</b>.</p>"))
' Hello world.

3) Extract the first number (capture groups)

re.SearchPattern = "(\d+)"
Var m As RegExMatch = re.Search("Order #12345 shipped")
If m <> Nil Then MessageBox(m.SubExpressionString(1)) ' 12345

4) Reformat dates with $1, $2, $3

Goal: YYYY-MM-DD → DD/MM/YYYY

Var re As New RegEx
Var opt As New RegExOptions
opt.ReplaceAllMatches = True
re.Options = opt

re.SearchPattern = "(\d{4})-(\d{2})-(\d{2})"
re.ReplacementPattern = "$3/$2/$1"
MessageBox(re.Replace("Due: 2025-09-09 and 2025-12-31"))
' Due: 09/09/2025 and 31/12/2025

5) Find all words (simple iterator)

re.SearchPattern = "\w+"
Var match As RegExMatch = re.Search("one two three")
While match <> Nil
  System.DebugLog(match.SubExpressionString(0))
  match = re.Search ' continues from last position
Wend

6) Replace only the second occurrence

Var s As String = "a bus drove on a street in a town"
re.SearchPattern = "\ba\b"
re.ReplacementPattern = "the"

Var first As RegExMatch = re.Search(s) ' find first
If first <> Nil Then
  s = re.Replace ' replaces the next match only
End If

MessageBox(s)
' a bus drove on the street in a town

7) Lookarounds

Match “foo” not followed by “bar”

re.SearchPattern = "foo(?!bar)"

7.1 Negative lookahead: match only http (not https) URLs

Var re As New RegEx
re.SearchPattern = "http(?!s)://\S+" ' http:// not followed by s
Var txt As String = "http://a.com and https://b.com"
Var m As RegExMatch = re.Search(txt)
While m <> Nil
  System.DebugLog(m.SubExpressionString(0)) ' http://a.com
  m = re.Search
Wend

7.2 Positive lookbehind + optional decimals: amounts right after $

Var re As New RegEx
re.SearchPattern = "(?<=\$)\d+(?:\.\d{2})?" ' $123 or $123.45 → capture just the number
Var txt As String = "Total: $19.99, Tax: $2"
Var m As RegExMatch = re.Search(txt)
While m <> Nil
  System.DebugLog(m.SubExpressionString(0)) ' 19.99, 2
  m = re.Search
Wend

Tip:

• Fixed‑width only for look‑behind: avoid quantifiers like +, * inside (?<=…)/(?<!…).
• Use lookarounds when you need context to the left/right but don’t want it included in the match or replacement.

8) Smallest span between tags (non‑greedy)

re.SearchPattern = "<b>.+?</b>" ' or: opt.Greedy = False

9) Extract emails (simple demo)

re.SearchPattern = "[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,}"
Var em As RegExMatch = re.Search("Contact: me@example.com")
If em <> Nil Then MessageBox(em.SubExpressionString(0)) ' me@example.com

10) Start at character position N (UTF‑8 safe)

Var t As String = "ąβç sample"
Var charPos As Integer = 5 ' 1-based character index
re.SearchPattern = "\w+"
re.SearchStartPosition = t.Left(charPos - 1).Bytes ' convert char index → byte offset
Var mm As RegExMatch = re.Search(t)
If mm <> Nil Then System.DebugLog(mm.SubExpressionString(0))

Quick replacement references

• $& = entire match (This reference represents the exact piece of text that your regular expression found. It’s incredibly useful if you want to add something before or after the matched text without changing the match itself.)
• $1…$50 = captured groups (Regular expressions allow you to define specific “groups” within your match by enclosing parts of your pattern in parentheses (). Each set of parentheses creates a captured group.)
• $` = text before the match (This special reference represents all the text in your original string that appears before the part your regular expression matched. It’s handy if you want to keep the beginning of the string intact while making a change in the middle.)
• $’ = text after the match (This refers to all the text in your original string that comes after the current match. It’s useful for preserving the end of the string.)

Options you’ll use most

opt.ReplaceAllMatches = True  ' global replace
opt.CaseSensitive = True      ' default is False
opt.DotMatchAll = True        ' make . match newlines
opt.Greedy = False            ' prefer shortest matches
opt.TreatTargetAsOneLine = True ' ^ and $ match whole string

Common gotchas

• Greediness: “.+” can overmatch; use .+? or set Greedy = False.
• Case sensitivity: default searches are case‑insensitive; enable CaseSensitive when exact case matters.
• UTF‑8: SearchStartPosition is byte‑based; convert character index to bytes (see example ↑).
• Lookbehind must be fixed‑width.
• Iteration: After the first Search(targetString), call re.Search with no args to continue.

Wrap‑up

Got a tricky pattern, validation, parsing, or a lookaround edge case you want covered? Drop a comment in the forums with your use.

Happy matching!

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

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

This is where ngrok comes in: a fantastic tool that creates secure tunnels to your localhost, making your locally running Xojo web app accessible from anywhere in the world. It’s a game-changer for testing, demonstrations, and rapid development.

What is ngrok and Why Xojo Developers Need It?

At its core, ngrok is a command-line tool that creates a secure, public URL for a service running on your local machine. Think of it as a temporary bridge from the internet directly to your computer, bypassing firewalls and NAT configurations.

For Xojo Web developers, this offers a wealth of benefits:

• Real-device Testing: Test your Xojo web app’s responsiveness and functionality on actual mobile phones, tablets, or other computers, even if they’re not on your local Wi-Fi network.
• Instant Demonstrations: Share your work-in-progress with clients, colleagues, or friends without the need of deploying to a remote server. They just need the ngrok-provided URL!
• Webhook Development: Many third-party services (payment gateways, messaging platforms, etc.) use webhooks to notify your application of events. These webhooks require a public URL to send data to. ngrok provides this, making local webhook development a breeze.
• Debugging Public-Facing Issues: Sometimes, an issue only appears when your app is publicly accessible. ngrok allows you to debug such scenarios without a full deployment cycle.

It’s truly a must-have tool in your Xojo Web development toolkit!

Getting Started with ngrok

Before we connect our Xojo app, we need to get ngrok set up.

Step 1: Download ngrok

Head over to the official ngrok website: https://ngrok.com/download.

Download the version appropriate for your operating system (Windows, macOS, Linux).

Step 2: Unzip and Place

Once downloaded, you’ll get a single executable file (e.g., ngrok.exe on Windows, ngrok on macOS/Linux). Unzip it and place it in a convenient location. I recommend creating a dedicated folder for it, or placing it somewhere easily accessible from your terminal or command prompt.

Preparing Your Xojo Web App

Xojo Web applications are self-contained web servers. When you run a Xojo Web app in debug mode or build it for deployment, it listens for incoming connections on a specific port. By default, Xojo Web apps usually listen on port 8080.

Let’s quickly ensure your Xojo Web app is ready:

1. Open your Xojo Web Project: Open any existing Xojo Web project, or create a new one for testing.
2. Run in Debug Mode: Click the “Run” button in the Xojo IDE. Your web app will launch in your default browser, at http://localhost:8080.

Tunneling Your Xojo App with ngrok

Now for the magic! With your Xojo Web app running locally, we’ll open a tunnel to it using ngrok.

Step 1: Open Terminal/Command Prompt

Open your system’s terminal (macOS/Linux) or Command Prompt/PowerShell (Windows).

Step 2: Navigate to ngrok Directory (if needed)

If you didn’t place the ngrok executable in a system PATH location, navigate to the directory where you unzipped ngrok using the cd command. For example:

cd /path/to/your/ngrok/folder

Step 3: Run the ngrok Command

Now, execute the ngrok command to create the tunnel. Since Xojo Web apps typically run on port 8080, the command will be:

ngrok http 8080

• http: Specifies that we’re tunneling an HTTP service.
• 8080: This is the port your Xojo Web app is listening on. If you’ve configured your Xojo app to use a different port (e.g., in the Build Settings), make sure to use that port number instead.

After running the command, ngrok will output information about the tunnel it has created. You’ll see output similar to this:

ngrok                                                                            (Ctrl+C to quit)

Session Status                online
Account                       Account Name (Free)
Version                       3.x.x
Region                        United States (us)
Forwarding                    https://a52b-20-40-100-120.ngrok-free.app -> http://localhost:8080

Connections                   ttl     opn     rt1     rt5     p50     p90
                              0       0       0.00    0.00    0.00    0.00

The most important lines here are the Forwarding lines. These provide you with the public URLs that point to your Xojo web app.

Testing Your Public Xojo App

With the ngrok tunnel active, your Xojo web app is now live to the world!

1. Copy the HTTPS URL: Copy the https:// URL provided by ngrok.
2. Test It:
   • Paste this URL into any web browser, on any device, anywhere with an internet connection.
   • Send the URL to a friend or client to get their feedback.
   • Test it on your mobile phone’s browser using its cellular data connection (not your local Wi-Fi) to simulate a truly external connection.

You’ll see your Xojo web app load as if it were hosted on a remote server!

To stop the ngrok tunnel, press Ctrl+C in the console.

Conclusion

ngrok can be an indispensable tool for any Xojo Web developer. It transforms the challenging task of exposing a local web app into a simple, one-line command. Whether you’re testing on diverse devices, showcasing your progress to clients, or integrating with external webhook services, ngrok streamlines your workflow and lets you focus on what you do best: building amazing applications with Xojo.

Give ngrok a try on your next Xojo Web project, and prepare to be amazed by the convenience it offers!

What if we create a Build Step script to automatically run ngrok when needed? Share your experiences and tips in the Xojo forums!

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

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

While license pricing is going up, we’re also increasing long-term value for our loyal users by doubling the auto-renewal discount from 10% to 20%.

What’s Changing Today

Beginning today, new Xojo Desktop, Web and Mobile licenses are $499/year. New Xojo Pro is $999/year. Xojo Pro Plus will remain $1999/year.

The Xojo Lite license is being retired and is no longer available. Existing Lite licenses will continue to function as expected. Lite renewals will be available until August 4, 2025. In order to receive future updates, existing Lite license holders will need to upgrade when their current license expires.

What is Coming Up

While the new pricing is in effect for new licenses starting today, we want to give existing users time to renew under the current pricing. The updated pricing for renewals and upgrades will take effect on August 4, 2025. One and two year renewals are available on our website. New and expired licenses can be renewed anytime. If you are interested in renewing for a longer period, please contact our support team.

The standard auto-renewal discount is doubling from 10% to 20%. Additionally, users who maintain an unexpired license¹ will receive even greater discounts over time: 25% after five consecutive years and 30% after ten years.²

We do not make this decision lightly. Our goal is to ensure that we can continue to invest in Xojo. This update reflects not only inflation over recent years but also the expanded value we’ve added to Xojo.

We remain committed to providing excellent value and keeping Xojo more affordable than many alternatives in the market. Raising prices today helps us keep that promise long-term.

Note: These changes do not affect the Xojo IDE which remains free for downloading, development and testing. You can still install Xojo on as many machines as you like and run your projects using the free IDE. Building for Linux and Raspberry Pi also remain free and do not require a license.

1. Updated to include all renewal types: Maintain an unexpired license, using auto-renewal or manual renewal, to receive these discounts. Renewals placed before a license expires always include the full 12 months of support. ︎
2. Discounts are automatically applied based on your auto-renewal history beginning August 4, 2025 and are not retroactive. ︎

Migrating Towards XAML

We are slowly and selectively updating our Win32 UI to the more modern WinUI with the help of XAML. You’ll notice some incremental updates in 2025r2 to this effect when you’ve got the Use WinUI (Experimental) build setting selected.

For those who can’t wait for our Win32 UI updates or need more advanced XAML layouts today, the DesktopXAMLContainer provides a powerful and flexible solution with virtually unlimited possibilities.

For a quick refresher, please take a look at a blog post we did when we first introduced the DesktopXAMLContainer control.

A Deeper Dive into XAML

While previous blog posts have showcased the potential of using DesktopXAMLContainer, there’s still much more to explore when it comes to effectively using and understanding XAML within Xojo.

XAML is Asynchronous

Understanding that XAML operates asynchronously helps explain why setting or retrieving a property might not behave as expected—especially when a control hasn’t fully finished constructing. To reliably detect when a XAML control is ready, use the EventTriggered event and check if the eventName is “Loaded”. This is particularly important when working with complex layouts that include XAML controls containing embedded XAML content.

Due to the asynchronous nature of XAML control rendering, the DrawInto mechanism also needed an enhancement. For DesktopXAMLContainer, we’ve added an asynchronous variant DrawIntoAsync, which renders the control and returns a Picture via the supplied callback method.

Sub RenderXAMLPreview(container As DesktopXAMLContainer, targetCanvas As DesktopCanvas)
  // Pass the canvas as the user data so we know where to draw
  container.DrawIntoAsync(AddressOf XAMLDrawComplete, targetCanvas)
End Sub

Sub XAMLDrawComplete(image As Picture, data As Variant)
  If image <> Nil And data IsA DesktopCanvas Then
    DesktopCanvas(data).Backdrop = image
  End If
End Sub

Translating your XAML Experience

Rotating and scaling a XAML layout is as simple as applying the appropriate RenderTransform. In the following example, we rotate a XAML CheckBox within a Timer.Action event. Even though the entire XAML content is updated on each timer interval, the result remains smooth and fluid, demonstrating how well XAML handles dynamic visual changes.

Sub Timer1.Action()
  Static angle As Integer = 0

  angle = angle + 10

  If angle >= 360 Then angle = 0

  Var isChecked As Boolean = True

  If XAMLContainer1.Content <> "" Then isChecked = XAMLContainer1.Value("CheckBox.IsChecked")

  Var xaml As String = "<Grid>" + _
	"<CheckBox Name='CheckBox' Content='Rotate Me' IsChecked='" + isChecked.ToString + "'>" + _
	"<CheckBox.RenderTransform>" + _
	"<RotateTransform Angle='" + angle.ToString + "' CenterX='50' CenterY='10' />" + _
	"</CheckBox.RenderTransform>" + _
	"</CheckBox>" + _
	"</Grid>"

  XAMLContainer1.Content = xaml
End Sub

Child Controls Inherit the Parent’s Background Brush

When embedding a Transparent DesktopXAMLContainer on top of another, the child will inherit the parent’s background brush. This is useful for basic brushes, but note that it does not support acrylic brushes and won’t automatically adjust offsets for linear gradient brushes.

Layering XAML

WinUI and Win32 controls are rendered on separate layers. WinUI content is composited first, then Win32 controls are drawn on top. As a result, any Win32 control will always appear above WinUI content unless you directly parent a DesktopXAMLContainer control on a Win32 control.

Setting Focus for Embedded XAML Controls

Starting with 2025r2, you can now set focus to a specific control in your XAML layout. Here’s how this looks:

<StackPanel Orientation="Vertical">
  <Button Name="Button1" Content="Button 1"/>
  <Button Name="Button2" Content="Button 2"
           Margin="0,10,0,0"/>
  <Button Name="Button3" Content="Button 3"
           Margin="0,10,0,0"/>
</StackPanel>

XAMLContainer1.Invoke("Button2.SetFocus")

Extended XAML Features

As mentioned in a previous blog post, we’ve extended XAML with a new markup syntax unique to Xojo. The primary goal of this extension is to improve the reusability of XAML controls. For example, consider a layout that includes three different XAML buttons:

Updating the caption or changing the button’s color would require manual edits to the XAML content string. Wouldn’t it be more convenient if those properties were available directly in the Inspector? With a custom subclass, some tweaks to its Inspector behavior, and the Xojo-specific {XojoBinding} syntax, you can make that happen.

First, create a subclass of the DesktopXAMLContainer, we’ll call this our XAMLButton, and add the properties that you want to expose in the inspector.

We’ll modify the XAML content to use the new {XojoBinding} syntax, which dynamically replaces the placeholder with the corresponding property value from the Inspector based on its name.

Now you can just drag out your subclassed control and adjust its properties directly in the Inspector without needing to manually edit the XAML content.

Make sure to check out our XAML Subclasses example project to see the other possibilities.

Having Fun With XAML

With a better understanding of XAML and how it integrates with Xojo, you’re now ready to build a XAML-driven UI on Windows. In fact, our IDE already makes use of XAML in several areas, like the Splash Screen, the XAML Control Chooser dialog and the toolbar in the Documentation window. The possibilities with XAML are vast, so dive in and explore what it can do for you!

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

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

Consistent Barcode Scanning Experience

Not to be outdone, the Barcode scanning experience on Windows has been brought up to par with other platforms, now including support for video mirroring in the scanning window. Also, if you were seeing a “squished” video before, we’ve now added support for a wider range of video devices and aspect ratios.

DesktopHTMLViewer Improvements

Thanks to some feedback we received, the DesktopHTMLViewer now supports raising the FocusReceived, FocusLost, KeyDown, and KeyUp events.

While DesktopHTMLViewer.Print works well, there are times you might want to go straight to PDF. If you’d rather skip the default print prompts, you can now use the new DesktopHTMLViewer.PrintToPDF(file As FolderItem) method to print HTML content directly to a PDF file. Just pass in the destination file and everything else works just like the regular Print method, including the PrintComplete event firing on success.

We’re always working to make Xojo better, and your feedback plays a big part in that. So from all of us here at Xojo—thank you! We truly appreciate your input as we continue to improve the product for you and everyone who uses it.

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

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

Introducing the Xojo IDE for Linux ARM64

With the release of Xojo 2025r1, however, everything has changed. Now, for the first time, developers can run the Xojo IDE directly on their Raspberry Pi 64-bit device. This means you can write, build, and test your applications all from within the same environment. The seamless integration allows for faster iteration and a smoother workflow, giving you more control over your development process. Not only can you now run the Xojo IDE on a Pi, but also on any Linux ARM64 distro.

What is Supported?

Nearly all the features you love about working in the Xojo IDE on other platforms are now available with the Linux ARM64 IDE, with the exception of building macOS and Mobile (Android/iOS) apps. Instead of remotely debugging your Raspberry Pi app using the Xojo IDE on Windows, you can now remotely debug your Windows app using the Xojo IDE on Pi!

For best results, we recommend a Raspberry Pi 5 or 500 with 8GB of RAM.

Xojo Loves Pi!

With the Xojo IDE now available for Linux ARM64, we’re making our case as the go-to solution for Raspberry Pi developers. The simplicity, cross-platform support, and power makes Xojo an attractive choice for those looking to build apps on the Pi, without the complexity of traditional programming environments.

NOTE: You can build Linux apps with Xojo for free, no license required. Just select Linux in Build Settings, then choose ARM or x86 architecture in the Inspector.

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

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

The History

While we’ve offered an API to get the Destination of a DragItem, it has been returning Nil on macOS for quite some time. In fact, it likely hasn’t worked since our transition from Carbon to Cocoa way back in the day. Amid all the API changes that came with that transition, DragItem.Destination was unfortunately left behind.

A New Way to FolderItem Drag

To avoid breaking existing code, we chose not to overhaul our entire drag-and-drop system just to support this feature. Instead, we’ve made a few simple additions that are necessary to get FolderItem drags to return a valid DragItem.Destination

Here’s how a FolderItem drag would currently be setup (for example in the DesktopWindow.MouseDown event):

Var fileToCopy As FolderItem = SpecialFolder.Temporary.Child("Test")
Var item As New DragItem(Self, 0, 0, 100, 100)
item.FolderItem = fileToCopy
item.Drag

After dropping the item at its Destination, checking item.Destination would always return Nil:

If item.Destination = Nil Then
    MessageBox "Not a happy destination. 😔"
End If

By making one simple addition and using the RawData API, we can now initiate FolderItem drags in a way that correctly returns a valid FolderItem.Destination.

Var fileToCopy As FolderItem = SpecialFolder.Temporary.Child("Test")
Var item As New DragItem(Self, 0, 0, 100, 100)
item.FolderItem = fileToCopy
item.RawData("public.file-url") = ""
item.Drag

Now, when you check the Destination after the drag is complete, you’ll receive something much more meaningful:

If item.Destination <> Nil And item.Destination IsA FolderItem Then
    MessageBox(FolderItem(item.Destination).NativePath)
End If

An Added Benefit

While this change is a big improvement, why stop there? In the past, you could only drag FolderItems to the Destination, and the entire contents of that FolderItem would be copied over. With the addition of this new dragging method, you can now assign content to RawData("public.file-url"). Instead of copying the entire FolderItem to the Destination, we’ll copy the content from the RawData instead.

Here’s how you could set it up:

// The fileToCopy does not need to exist, we'll simply
// pull the file name from it and create the file at
// the destination with the new content that is assigned
// to the RawData.
Var fileToCopy As FolderItem = SpecialFolder.Temporary.Child("DummyFile.txt")
Var item As New DragItem(Self, 0, 0, 100, 100)
item.FolderItem = fileToCopy
item.RawData("public.file-url") = "Content that will be written to the destination file."
item.Drag

Conclusion

With these enhancements, dragging FolderItems on macOS has become more flexible and powerful than ever. Not only can you now easily retrieve a valid Destination, but you also have the power to control the content being copied, thanks to the integration with the RawData API.

So, go ahead—drag that FolderItem and show us your destination!

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

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

Making Your App Stand Out

Designing an app that stands out can be a challenge, but sometimes, a simple UI refresh can make all the difference. One small yet impactful step in that direction was improving the Shadowed Box frame type of a DesktopWindow. If you’ve ever tried using it on Windows, you likely noticed a frustrating limitation—the title bar never fully disappeared. What should have been a sleek, borderless look was instead marred by a stubborn, shrunken title bar, making it easy to abandon the feature altogether, and perhaps preferring to use the Plain Box type instead.

With Xojo 2025r1, this is no longer a problem. The title bar now disappears entirely on Windows, just like it does on macOS and Linux. This makes it even more effective for use cases like splash screens, which appear much more dynamic compared to the flat look of the Plain Box type.

Modernize with WinUI

Our Splash Screen is a small example of what’s possible with WinUI through our DesktopXAMLContainer. For 2025r1, we’ve enhanced DesktopXAMLContainer by adding support for additional methods, properties, and events for WebView2, as well as support for the MediaElement control. We’ve also improved tab navigation between WinUI controls within a DesktopXAMLContainer and non-WinUI controls in your layout. Additionally, WinUI layout controls like StackPanel and Grid can now resize to the bounds of your control, instead of just resizing to fit content. This makes background fills, such as acrylic brushes, easier to manage. As we keep advancing Xojo’s WinUI support, you can start taking advantage of these shadowy changes today. Check out our XAML example projects included in the Xojo download Examples folder to see what’s already possible!

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

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

In this article, we’ll explore actionable, real-world design principles tailored to the unique needs of solo developers. Whether you’re building your first app or looking to improve your design skills, this guide will give you the tools and confidence to create apps that stand out in today’s crowded market.

Why Design Matters for Solo Developers

Before diving into specific principles, let’s address a fundamental question: Why is design so crucial for solo developers? The answer is simple—Users judge your app within seconds, forming quick impressions that impact their decision to continue using it. A poorly designed app drives users away, no matter how powerful its functionality is. Good design, on the other hand, builds trust, enhances usability, and keeps users coming back.

For solo developers, good design is also a strategic advantage. With limited resources, you can’t compete with big teams on the number of features. But you can compete on delivering a streamlined, delightful user experience (UX).

Core Design Principles for Mobile App Developers

Let’s break down effective mobile app design into manageable, actionable principles. These are specifically geared toward solo developers who need to maximize their impact without burning out.

1. Start with User-Centered Design (UCD)

The foundation of great design is understanding your users. Who are they? What problems are they trying to solve? What do they expect from your app?

Action Steps:

• Create user personas: Develop simple profiles of your target users, outlining their goals, challenges, and preferences. For example, if you’re building a productivity app, your persona might be a busy freelancer who values speed and simplicity.
• Map user journeys: Sketch the step-by-step flow of how users interact with your app. Identify any potential friction points and eliminate them.

Example:

Imagine you’re building a budgeting app. Your user persona might be a young professional who wants to track expenses quickly. A user-centered approach prioritizes features like one-tap expense logging and clear, visual summaries of spending.

2. Keep It Simple and Intuitive

Users shouldn’t need a manual to figure out how to use your app. Simplicity doesn’t just mean fewer features; it means making the most important features easy to find and use.

Action Steps:

• Follow established patterns: Use common design conventions, such as a bottom navigation bar for key actions. Users are already familiar with these patterns, so don’t reinvent the wheel.
• Limit choices: Avoid overwhelming users with too many options or settings. Focus on the core functionality that solves their problem.
• Prioritize clarity: Use simple, descriptive labels for buttons and menus. Avoid jargon or ambiguous terms.

Example:

Take inspiration from apps like Instagram. Its clean design makes it instantly clear how to post a photo, view stories, or explore content. Even as a solo developer, you can achieve a similar level of clarity by focusing on simplicity.

3. Optimize for Mobile First

Mobile screens are small, so every pixel counts. Designing for mobile-first means giving priority to usability on smaller screens before addressing larger screens.

Action Steps:

• Use responsive design: Ensure your app looks and works great on a wide range of screen sizes, from small phones to large tablets.
• Design for touch: Make buttons and interactive elements easy to tap with a finger. Aim for a minimum touch target size of 48×48 pixels.
• Focus on readability: Use legible font sizes (at least 16px for body text) and maintain sufficient contrast between text and background colors.

Example:

Consider a to-do list app. A mobile-first approach designs a clean, vertical layout with large, tappable checkboxes, ensuring users can quickly mark tasks as complete on the go.

4. Embrace Visual Hierarchy

Visual hierarchy refers to the arrangement of elements to guide users’ attention. When done well, users understand what’s most important at a glance.

Action Steps:

• Use size and color strategically: Make primary actions (e.g., “Submit” buttons) larger and more visually distinct than secondary actions.
• Group related elements: Use spacing to visually group related items, such as form fields or menu options.
• Leverage typography: Use different font sizes and weights to create contrast between headings, subheadings, and body text.

Example:

In a fitness app, display the user’s daily step count in a bold, colorful header, while less critical information (e.g., weekly trends) appears in smaller, subdued text below.

5. Focus on Performance and Speed

No one likes a slow app. Performance is a key part of the user experience, and it’s especially important for mobile apps, where users expect instant responsiveness.

Action Steps:

• Optimize assets: Compress images and use vector graphics where possible to reduce load times.
• Minimize animations: While animations can enhance UX, overusing them slows down your app. Use them sparingly and purposefully.
• Test on real devices: Don’t rely solely on simulators. Test your app on actual devices to ensure smooth performance.

Example:

If you’re building a weather app, users expect the current weather to load quickly. Preload data where possible and optimize your API calls for speed.

6. Iterate and Test Continuously

Design is an iterative process. Even the best initial design can be enhanced through user feedback and continuous refinement.

Action Steps:

• Start with a minimum viable product (MVP): Focus on the core functionality and get it into users hands quickly.
• Gather feedback: Use surveys, app store reviews, or in-app feedback tools to understand what users like and dislike.
• Refine based on data: Analyze user behavior (e.g., which features are most used) and improve accordingly.

Example:

When developing a language learning app, you might discover that users struggle with navigation. Based on feedback, simplify the menu structure or add tooltips to guide new users.

Tools to Simplify Design for Solo Developers

As a solo developer, you don’t need to reinvent the wheel. Leverage tools that streamline the design process:

• Figma: A powerful design tool for creating wireframes and prototypes.
• Xojo: Xojo’s drag-and-drop interface, combined with its easy-to-learn language, makes creating mobile apps across different form factors straightforward.
• Canva: Great for creating simple, clean graphics for your app.

Conclusion: You’ve Got This!

Designing a mobile app as a solo developer is no small feat, but by following these principles, you can create apps that are both functional and enjoyable to use. Remember to start with your users in mind, focus on simplicity and clarity, and continuously refine your work based on feedback.

Your Next Step: Take a look at your current project (or start a new one!) and apply at least one of the principles discussed in this article. Need a mobile app development platform? Check out Xojo for an intuitive, developer-friendly way to bring your app ideas to life.

We have something special to share with you! To celebrate our incredible community of developers, we’ve created a brand-new set of nine Xojo-themed desktop wallpapers just for you.

Whether you’re deep into coding your next big project or simply browsing the web, these wallpapers are designed to inspire and bring a fresh look to your workspace.

What’s Included?

A variety of designs to suit all tastes:

• Sleek Minimalist Styles: For those who appreciate clean and modern aesthetics.
• Xojo Logos and Graphics: Show off your Xojo pride with branded visuals.
• Vibrant Abstracts: Liven up your screen with dynamic and colorful patterns.

Here are just a few of the wallpapers included:

Download Your Wallpaper Pack Now!

Ready to give your desktop a makeover? Download the complete wallpaper pack with nine wallpapers to try:

Download Xojo Wallpaper Pack

Spread the Xojo Love

We’d love to see how the wallpapers look on your screens! Share a snapshot of your new setup on social media. Don’t forget to tag us. Your setup might even get featured on our official channels!

Stay Connected

We’re always working on new ways to enhance your Xojo experience. Make sure to follow us on social media for the latest updates, tips, and community highlights.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

Thank you for being a part of the Xojo community. We hope these wallpapers add a touch of inspiration to your day!

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!

The If…Else Statement

You’ve probably seen If...Else statements in other programming languages too. They’re like the basic building blocks for making decisions in your code. The main strength of If...Else is that it’s very flexible. It lets you check if something is true or false and then do different things based on the answer.

You can also combine conditions using And and Or.

• And: Checks if both conditions are true. For example, If age > 18 And hasLicense = True Then (You need to be over 18 and have a license).
• Or: Checks if at least one of the conditions is true. For example, If score > 90 Or extraCredit = True Then (You can get an A if your score is over 90 or if you did extra credit).

You can even add more options using ElseIf to create more complex sets of rules. Think of it like a choose-your-own-adventure book where the story changes based on your choices.

Example:

Var age As Integer = 25
Var message As String

If age < 18 Then
  message = "Minor"
ElseIf age >= 18 And age < 65 Then
  message = "Adult"
Else
  message = "Senior"
End If

System.DebugLog(message)

The Select Case Statement

The Select Case statement is like a neat and organized way to deal with a list of options for one thing. Imagine you have a variable, like a number grade. Select Case lets you check that grade against different cases (like “A”, “B”, “C”) and then do something specific for each grade.

Var grade As String = "B"
Var feedback As String

Select Case grade
Case "A"
  feedback = "Excellent"
Case "B"
  feedback = "Good"
Case "C"
  feedback = "Fair"
Case "D", "F"
  feedback = "Needs Improvement"
Else
  feedback = "Invalid Grade" // This is the default case
End Select

System.DebugLog(feedback)

The Else Case In a Select Case statement, acts like a default. If none of the other cases match the value you’re checking, the code inside Else will run.

Using Ranges in Select Case

You can also check for ranges of values using To. For example:

Var score As Integer = 85
Var grade As String

Select Case score
Case 90 To 100
  grade = "A"
Case 80 To 89
  grade = "B"
Case 70 To 79
  grade = "C"
Case Else
  grade = "D" 
End Select

System.DebugLog(grade)

When to Use Which

• Use If...Else when:
  • You only need to check if something is true or false.
  • You need to check many different things at the same time using “and” or “or”.
  • You need the most flexibility to handle all sorts of situations.
• Use Select Case when:
  • You’re checking one thing against a list of possible values.
  • You want your code to be super clear and easy to understand.
  • You want a neat way to organize different options.

Best Practices

• Use meaningful names: Choose names for your variables that clearly describe what they store (e.g., studentAge instead of just age).
• Keep it short: Try to keep the code blocks within your If...Else or Select Case statements relatively short and focused. If a block gets too long, consider breaking it down into smaller parts.
• Comment your code: Add comments to explain what your code is doing, especially in complex If...Else statements. This will help others (and your future self) understand your code.

Conclusion

Both Select Case and If...Else are useful tools for making decisions in your code. Choosing the right one depends on what you need your code to do. If...Else is great for handling complicated situations, while Select Case is perfect for keeping things clear when you have a list of options. Knowing when to use each one will help you write better code that is easier to understand and work with. By thinking about what you need to check and how clear you want your code to be, you can use both of these statements to create awesome apps!

Update

Since the time this article was published, our great Xojo community has taken the discussion even further! On the Xojo Forum, developers have shared advanced examples, creative use cases, and expert tips for using If…Else and Select Case statements.

Be sure to check out the thread here: https://forum.xojo.com/t/re-if-then-vs-select-case/83633

We’re continually inspired by the passion and knowledge of our community—thank you for making Xojo such a collaborative and supportive space!

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

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

Protecting Our Objects

Xojo objects are uniquely constructed and reference counted, a detail most users don’t need to think about. However, when working with preemptive threads, objects inherently require special protection. In Xojo 2024r3.1, we implemented safeguards to enable the use of objects in preemptive threads, but the approach wasn’t as efficient as it could be. Operations like passing objects as parameters or assigning them as properties incurred overhead, and those costs added up.

As uniquely as our objects are to construct, they also required a unique approach to protect them. In Xojo 2024r4 we updated how we protect our objects so that this operation happens much faster, improving the overall experience when running preemptive threads.

For an example of these efficiencies, check out this forum post where users benchmark the One Billion Row Challenge.

Uniquely Destructed Objects

As mentioned, our objects are uniquely constructed, and this uniqueness extends to their destruction as well. When a preemptive thread is running, it’s important not to wait for other objects to be destructed within the Destructor method.

Sub Object1.Destructor()
  While Object2 <> Nil
    // Waiting for Object2 to be destructed can lead to a deadlock,
    // especially if Object2 is being destructed from a separate thread.
  Wend
End Sub

Also, avoid situations where you are creating new objects while in the Destructor and referencing Self.

Sub Object1.Destructor()
  // Referencing Self in a new object will lead to a
  // recursive Destructor sequence causing a dead lock.
  Var newObj As New Class1
  newObj.NotAGoodIdea = Self
End Sub

Handling Race Conditions

In Xojo 2024r3.1, we created an example demonstrating how to synchronize shared resources using critical sections and semaphores. This example also highlights the effect of a race condition: your app will crash immediately, terminating the debugging session with no indication as to where the crash may have occurred.

These access violations were never caught by our debugger until now. Because these crashes may interfere with what can be displayed in the debugger, we’ve intentionally limited what is shown, as the access violation could leave the app in an unstable state. Although these access violations are not exclusive to crashes caused by race conditions, this new feature aims to help you identify potential race conditions in your apps when working with preemptive threads. Let’s take a look at that example and see what happens now when you run it through the debugger:

When you click the button designed to intentionally crash the app, you’ll now be returned to the debugger, where you’ll see a new crash icon. This symbol indicates that a crash has occurred, and the app cannot proceed further (which is why all debugging step commands are disabled, and the debugger values are not loaded so objects will be Nil). Your only options at this point are to stop the app or attempt to reload the debugger values.

Clicking the command button on the left refreshes or reloads the debugger values. If the app is stable enough, the debugger values will refresh; otherwise, the app may terminate automatically at this point.

In summary, these improvements aim to make working with preemptive threads more enjoyable by offering both enhanced speed and an easier process for identifying potential race conditions, which was previously much more challenging. Like the One Billion Row Challenge, we’re eager to hear about all the ways you’re making use of preemptive threads in your own apps!

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

• Facebook
• X
• LinkedIn
• GitHub
• YouTube