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

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

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

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

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

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

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

Why this matters

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

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

How it works

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

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

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

A note about XojoScript limitations

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

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

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

Support for more Graphics

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

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

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

Class LinearGradientBrush

  Sub Constructor()

  Sub AddStop(stop As Double, c As Color)

  Property StartPoint As Point
  Property EndPoint As Point

End Class

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

Turning off this feature

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

Finally

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

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

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

MobileChart

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

MobileColorPicker

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

MobilePDFViewer

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

Zip/Unzip

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

Android Keeps Getting Better

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

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

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

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

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

New Controls

Three new controls have been added to the Web framework in this release, aiming to close the difference gap between Web and the other project types.

WebSwitch is a toggle control that mobile developers will already be familiar with. It’s been available on iOS and Android for a while. It’s now available for web projects too, so if you’ve been approximating a toggle switch using a styled checkbox, you can finally retire that workaround.

WebColorPicker brings color selection to web apps in the same way DesktopColorPicker does for desktop. Drop it in from the Library, wire up the event and you have a color picker the Xojo way.

This is how WebColorPicker looks like in your browser:

The third new control adds barcode reading support. Your web app can now read barcodes directly from the user’s camera, from desktop or mobile browsers. This opens up a lot of practical use cases: Inventory systems, ticketing, product lookups, that previously would have pushed you toward a native mobile app.

Again, drop the Barcode control into your project and implement the events:

That’s it! Your web apps can scan a great variety of barcodes now. Including QR, Data Matrix, Aztec, PDF 417 and much more!

Icons on WebButtons

WebButton now has an Icon property. You can assign any WebPicture to it, or use one of the Bootstrap icons that are already bundled with the framework. It’s a small addition, but it makes a noticeable difference when building action-heavy interfaces where a label alone doesn’t communicate enough at a glance.

Add a button into your project:

Configure its Icon property in the Opening event:

Me.Icon = WebPicture.BootstrapIcon("key-fill")

If you don’t specify a color in BootstrapIcon, it will inherit the button caption color in this case. This is the easiest way to support Dark Mode with the new WebButton.Icon property, without doing any special tricks.

Here is how it looks like at runtime:

Dark Mode:

WebLabel: Semantic HTML and Proper Element Types

Two related changes landed for WebLabel in this release. The first is a correctness fix: the control was previously rendered using the HTML <label> element, which is semantically meant to label form inputs, not to display general text. That has been corrected.

The more interesting addition is that you can now choose which HTML element WebLabel renders as. If you want a label to be an <h1> or an <h2>, you can set that directly in the Inspector. This is useful not just for visual styling, but for accessibility tools and search engines that rely on page structure to understand content hierarchy.

Improving both, accessibility and making search engines happier, are some of our goals for 2026. You will continue seeing improvements in this sense.

WebTextArea Gets AddText

WebTextArea now has an AddText method, consistent with how the control works on Desktop and Mobile. If you’re writing code that targets multiple platforms, this kind of parity saves you from having to check which target you’re on, before appending text.

Scale Indicator on WebMapViewer

WebMapViewer now has a HasScaleIndicator property. When enabled, a small visual scale appears on the map showing real-world distance. It makes a difference in apps where users need spatial context. Field work, logistics or anything where “how far is that?” is a question users might actually ask.

Performance and Modernization Under the Hood

A few changes in this release won’t be immediately visible, but they improve things for everyone.

Bootstrap has been updated to v5.3.8 which fixes some issues introduced in v5.3.7 impacting Xojo. The TypeScript compiler has been updated to v5.9.3, and the compilation target has been bumped from ES6 to ES2020. Unused code in the Web Framework has been cleaned up to reduce the compiled bundle size.

Xojo has also removed its own internal usage of Modernizr. The library is still present for now so existing apps that rely on it won’t break, but it’s no longer used by the framework itself and will be removed in a future release.

If you’ve been meaning to audit your web app for performance, this is a good moment to look at SendEventsInBatches and LazyLoadDependencies on WebSession as well. Both now default to True on new projects, so if your existing app has them disabled, it’s worth trying them out. These properties have been around for a while already but were turned off by default.

API Consistency Cleanups

A few methods have been deprecated in favour of names that are consistent with the rest of the framework:

• WebApplication.AutoQuit → AllowAutoQuit
• WebListBox.ReloadData → ReloadFromDataSource
• WebRadioGroup.RemoveAllRows → RemoveAll, and RemoveRowAt → RemoveAt

Your existing code will still compile, but it’s worth updating these when you get a chance.

Wrapping Up

Between new controls, better HTML semantics, and a leaner runtime, 2026r1 is a worthwhile update for anyone building web apps with Xojo. Check out the full release notes for the complete list of changes.

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

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

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

The Developer ID field was introduced in Xojo 2022r1, allowing you to fill in the developer certificate information needed for signing built macOS apps; however, it could be confusing to know exactly what information was expected.

• Developer ID Application
• Developer ID Application: Francisco Javier Rodriguez Menendez
• Developer ID Application: Francisco Javier Rodriguez Menendez (BW7PU32485)
• 7D767DB917A45A8976BEB5B92F04E8C18D09501A

And… which certificate should be used for Development builds, Direct Distribution, or Mac App Store publishing? That may not be obvious for someone new to all this.

Additionally, what happens if the entered data comes from an expired certificate or if the certificate isn’t in the Keychain?

The new approach: How it works

The Team-based signing chooser for the Mac Developer ID field follows these steps:

• Collects all the developer certificates found under the user Keychain.
• Groups the valid certificates by Team (what Apple designates as the TeamID).
• Based on the previous information, the new popup menu “Build For” will offer only the code-signing options available for the current selected Team:
  • Development. This is the equivalent to using the Apple Development certificate.
  • Direct Distribution. This is the equivalent to using the Developer ID Application certificate.
  • App Store. This is the equivalent to using the Apple Distribution certificate. In addition, the Publish feature will be enabled if, for the selected Team, there is also a valid 3rd‑party Mac Developer Installer certificate available.

If None is selected in the Developer ID popup menu, the macOS app will be built/debugged using Ad-Hoc signing.

Both menus update on the fly, so if new certificates are added (or removed) from the keychain, or if any have expired since last opened, both the Developer ID and Build For popup menus will reflect those changes.

macOS Certificates Inspector Window

Under the Teams popup menu, there is also an Inspect… option. When selected, it opens a new window where you can view and gather additional information for:

• Installed / Missing Apple Intermediate Certificates.
• Installed / Missing / Expired Developer Certificates, grouped by Team.

At a glance, you’ll see useful details for each certificate, such as:

• The expiration date
• The keychain where it is stored.
• Serial number, useful for identifying same-kind developer / intermediate certificates under different Macs.
• Issuer specific information.

Clicking any certificate provides more detailed information about the role it plays in the macOS signing process.

This Inspector is also useful in order to identify some of the most common issues related with the handling of certificates such as:

• Missing certificates for a given Team, determining thus the options that are available under the “Build For” popup menu.
• Expired certificates. These also determine the options that are available under the “Build For” popup menu for a given Team. In addition, if you want to do some cleanup, it is possible to delete these expired certificates directly from the Inspector without needing to open the Keychain Access app.
• About to expire certificates, so you are aware of it and the impact it could have on apps close to be distributed or on already created Provisioning Profiles, for example.
• Certificates with their private key missing. These can’t be used for signing purposes, so you will be able to re-install them in the keychain (if you have a backup) or install a new certificate.
• Developer Certificates where some of the required intermediate certificate is missing. You will be able to install the missing Intermediate (active Internet connection required).

Improvements to macOS Builds and Debugged apps

Although Sandboxing, Entitlements, and Provisioning Profiles have been part of macOS app development, this release brings several enhancements in these areas:

• Now it is possible debug Sandboxed apps directly from the IDE.
• Entitlements and Provisioning Profile are applied when the app is debugged from the IDE.
• Improvements in how the required Entitlements are added and signed when the macOS app is built; and also a better handling of the user-added entitlements and provisioning profile files (if required).
• Debugged and Built apps can be attached to the Instruments app. Among other things, Instruments can be used to detect issues such as memory leaks in the executed app. The IDE now automatically adds the required entitlement for this when: the app is debugged/built using the “None” (Ad-Hoc signing) from the Team popup menu, or, 2) when the app is built for Development (Build For) for a given Team.

When Build For is set to Direct Distribution or App Store, the required entitlement for Instruments to attach to the app, will be added only when the app is debugged from the IDE. If you want to use Instruments with a built app signed using these certificates, then you need to add that entitlement explicitly.

This decision is because when get-tasks-allow is set to True (the entitlement required in order Instrument being able to function), there are some well documented vulnerabilities that could be used to escalate privileges or inject code into your app. That’s not desirable for your distributed apps for sure (whether using Direct Distribution or if your app is installed through the Mac App Store).

Looking forward

We know there are still some areas to improve regarding code signing on macOS (and iOS) and we are working on some of them already. In the meantime, you’ll likely find the new Team-based Developer ID option more approachable, especially if this is your first experience dealing with certificates, signing, and distributing your freshly built macOS app.

A big THANK YOU to Richard Grafl for all his help and feedback during the beta-testing cycle of this feature.

Happy macOS code-signing!

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

Learn more about Code Signing in our recent series:

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

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