DBKit is a set of data-aware controls for Xojo: drop a DBKit.TextField on a layout, point it at a database, table, and column, and it loads, displays, and saves the value by itself. The query code, the glue code, the error handling: gone.

Version 1 proved the idea. It covered the basics and saved real time. But it still left work on your plate: filling listboxes, keeping controls in sync, writing the code that moves data back and forth.

Version 2 finishes the job. The controls are now fully self-sufficient. In most cases there is no database code left to write at all. The CustomersWindow from the DBKit Desktop Example project has no code at all. The same is true of the CustomersPage of the DBKit Web Example.

DBKit.Table. This is an all-new control built from the ground up: it fetches only the rows it needs to display, so whether you have hundreds of rows or millions no longer matters. Rows load fast. Table replaces the old ListBox-based approach entirely, on Desktop and Web alike.

What is new

DBKit.Row. This is the heart of v2. A Row is the object every row event hands you, and it is how you work with data everywhere in DBKit. Read and write column values by name: row.Column("quantity"). Values from related tables use qualified names: row.Column("products.price"). Columns that do not exist in the database, like calculated columns, work exactly the same way: assign them and the table picks them up. One object, one API, everywhere.

Row events. v2 introduces a full set of row events covering the row’s whole lifecycle: RowDisplayed, RowLoaded, RowChanged, RowEditing, RowSaving, RowSaved, RowCreated, RowDeleted, RowUndone, and RowNotSelected. RowDisplayed fires for each row as it appears, which is where per-row customization lives, including calculated columns:

Sub RowDisplayed(row As DBKit.Row) Handles RowDisplayed
  row.Column("linetotal") = row.Column("quantity") * row.Column("products.price")
End Sub

Calculated columns. Some values do not live in the database. A line total is quantity times price. Define the column, compute it in RowDisplayed, and the table treats it like any other column, including in totals and inline editing.

Related rows, automatically. Tell DBKit about your table relationships and it loads related rows on its own. You just set the TableRelationships property in the Inspector, one relationship per line:

invoices.customerid=customers.id

DBKit.Table displays related columns with no extra work, and on DBKit layouts, controls bound to related-table columns load automatically too. That products.price in the example above comes from the related products table. No JOINs in your code.

Inline editing. Mark columns editable and users can edit cells right in the table. Edits flow through the same row events, so calculated columns like that line total stay correct automatically.

A much more powerful SearchField. Drop a DBKit.SearchField on a layout and users can search as they type, with no code at all. It automatically searches every displayed column whose data type matches what they enter: text matches from the beginning of the value, quotes force an exact match, > and < compare numbers, two periods define a range, dates work in local or ISO format, and typing a column name first searches just that column.

Database connections without the code. DBKit works directly with DatabaseConnection objects. Configure the connection in the IDE for SQLite, MySQL, PostgreSQL, or ODBC, hand it to DBKit, and there is no connection code to write.

DBKit layouts. DBKit.Window, DBKit.Page, and DBKit.Container are layouts with a simple idea: bind the layout to a table, and every DBKit control on it shows the current row. The layout handles loading the row, saving edits, adding and deleting rows, undo, navigating between rows, and loading related rows. You arrange controls; DBKit does the rest.

Nearly identical on Desktop and Web. Everything above works the same in desktop and web apps: the same controls, the same events, the same Row object. Learn it once, use it everywhere.

If you are coming from v1

The conversion guide is short, and most of it is code to delete. That is the point.

Try it

DBKit v2 is available now. The DBKit Desktop Example and DBKit Web Example projects show it all working together: customers, invoices, and invoice items, with barely any database code in sight. The customers page in the web example, which displays and edits complete customer records, contains no code at all. Not one line. And that is just the start: v2 has a lot more new features, so check out the DBKit overview and the Classes reference.

If you’re new to DBKit, try out the DBKit tutorials for desktop and web.

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

Download Xojo

There’s still work to be done, but WinUI has reached an important milestone. We’re encouraging developers to start testing their existing applications with WinUI and, most importantly, to let us know when you encounter something that doesn’t work as expected.

Menus and Contextual Menus

One of the biggest additions in this release (Xojo 2026r3) is support for WinUI based Menus and Contextual Menus.

Menus are an essential part of many desktop applications, and bringing them to WinUI makes it possible to build more complete, native-feeling Windows applications with Xojo.

Symbol Support

We’ve also added support for symbols to a variety of controls, including DesktopPopupMenu and Menus.

Symbols provide a convenient way to add familiar visual indicators and icons to your application’s interface while taking advantage of the system’s available symbol resources. This gives you another way to create modern Windows interfaces without having to manage and distribute every image yourself. Note that Symbol support is only available for WinUI, Linux and macOS.

Picture.SystemImage Comes to Desktop

Originally available for iOS projects, Picture.SystemImage is now available on desktop as well. This provides a simple way to access system-provided images and symbols from your Xojo applications.

The list of supported symbols can be found here:

• Windows: https://learn.microsoft.com/en-us/windows/apps/design/iconography/segoe-fluent-icons-font
• Linux: https://specifications.freedesktop.org/icon-naming
• macOS: https://developer.apple.com/design/human-interface-guidelines/sf-symbols

On Windows, symbols are loaded from the Segoe Fluent Icons font (on Windows 10 they are loaded from the Segoe MDL2 Assets), so this feature is supported on both WinUI and non-WinUI Windows targets.

Designed with WinUI in Mind

As we add new functionality and controls, we’re designing with modern desktop platforms like WinUI in mind from the start. This means not only adding WinUI support to existing controls, but also improving the overall desktop experience where we can.

For example, our new DesktopTable provides a much better WinUI look and feel than the older DesktopListBox control, giving you a more modern foundation for displaying tabular data.

We’re also making existing controls take better advantage of the features available on modern platforms. PopupMenu now makes use of the Icons assigned to its MenuItems, so when building for WinUI, Linux, or macOS, those Icons automatically appear in your PopupMenus.

Even familiar controls are getting an update. SegmentedButtons can now properly receive focus and be navigated between segments using the keyboard.

 MessageBox is now dark-mode aware when built with WinUI, allowing it to better match the appearance of your application and the user’s system settings.

From Experimental to Beta

Moving WinUI support from Experimental to Beta is an important step for Xojo.

Beta means that we believe WinUI is ready for more developers to begin using and testing in real-world applications. It does not mean that every feature is complete or that there aren’t still issues to address. There is more work ahead, and your feedback will be an important part of getting WinUI ready for production use.

Give WinUI a Try

WinUI represents an important step forward for Xojo on Windows, and we’re excited about where it is heading.

If you’ve been waiting to try WinUI, now is the time. Start testing your applications, explore the new functionality, and let us know what you discover. Your feedback will help us make Xojo’s WinUI support a great foundation for building modern Windows applications.

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

Download Xojo

While I’ve been using Claude Code and I refer to it through this blog post, any other coding agent that knows how to read the AGENTS.md file should work just fine as well. We’d love to hear your AI stories and we even have a dedicated forum category for AI related posts.

I’ve been testing Agentic Mode for a while, and one session stands out. I gave Claude Code an intentionally vague prompt, something like “make something wow, the more wow, the better”. This is what Opus 5.5 came with after 11 minutes:

Far from perfect, but still very cool!

It’s a mission control panel showing a 3D globe with the earthquakes of the last seven days from the USGS feed, the live position and trajectory of the International Space Station, and the day/night line. It also has a command palette. And it’s multiplayer: every web session joins as a crew member, and you can see each other appear and move around in real time. Click a crew member and you jump to their view.

Let me show you how we got there.

The Setup

There isn’t much to it, honestly. I created a new Xojo Web project, saved it in the plain text file format, and enabled Agentic Mode.

When you turn Agentic Mode on, the IDE creates an AGENTS.md file in the project folder if there isn’t one already. That file points to XOJO-CODING.md, which explains to the agent how to work with the IDE. It also links to example projects for each Xojo target, including Web.

There’s no MCP server involved, no plugin to install. The whole protocol is a couple of text files. When the agent wants to build and run the project, it touches a file called XojoRunProject.txt, and the IDE does the rest. If something doesn’t compile, the IDE writes the errors to XojoCompileErrors.txt so the agent can read them.

Claude Code read the instructions and followed them perfectly from the very first prompt.

A JavaScript app in a Xojo shell? No, thanks

The first version was impressive, but there was a catch. Claude Code built almost everything in JavaScript. It worked, but what I had was a JavaScript web app inside a Xojo Web shell, and that’s not really the point.

So I asked it to refine the project, using WebContainers and regular Xojo Web controls as much as possible. This is how the project looks in the IDE afterwards:

The page is now built from reusable pieces you’d recognize from any Xojo project: a StatsPanel, a CrewPanel with a CrewRow for each crew member, QuakeCard, LegendPanel, HintBar, a ToastStack for notifications, and so on.

JavaScript didn’t disappear completely, and that’s fine. It stayed where it really makes sense. GlobeControl is a WebSDKUIControl wrapping the Globe.GL library, which handles the 3D globe. Claude Code also wrote a few other Web SDK controls for things that really should happen in the browser, like opening the command palette when you press Cmd+K. You wouldn’t want a round trip to the server just to show a palette.

If you open the project, you’ll be able to follow it, and change it, like any other Xojo Web app.

This is my main tip if you try this yourself: tell the agent explicitly that you want a maintainable Xojo app. Otherwise, it will reach for whatever it knows best in order to please you.

Compile, Fix, Repeat

Every now and then, Claude Code wrote something that didn’t compile. A syntax error here, a wrong type there. The good news is that it saw the error in XojoCompileErrors.txt right away, fixed it and built the project again. I didn’t have to jump in a single time.

If you’ve ever copied and pasted code from a chat window into the IDE, then copied the compile error back into the chat, you know how much friction this removes.

Testing in a real browser

This is where it gets interesting for web projects. Code that compiles isn’t necessarily code that works, and in a web app, the only way to know for sure is to open it in a browser.

With the Claude in Chrome extension, Claude Code can do exactly that. You just need Google Chrome open, with the extension installed and logged in. From there, the agent runs the app, opens it in Chrome, clicks around and tests the project end to end.

When something looks a bit off at runtime, it takes a screenshot of the browser, tweaks the project, runs it again, and keeps looping until it looks right. Since a multiplayer feature needs more than one user, it opened several tabs to check that the crew members showed up for each other, and closed them once it didn’t need them anymore. And if the Chrome extension isn’t available for whatever reason (like using other coding agents), it can fall back to Puppeteer and drive a browser on its own.

In practice, this means I could describe a feature, go outside and have a coffee, and come back to find it implemented, tested and polished.

If you’re using other targets, feel free to ask your coding agent to embed an MCP server and use it to test the app. It will find its way to test it, no matter what. It will ask you to do a final human review on specific new features, but overall, the agent will be on autopilot most of the time.

A few rough edges

This is a promising setup, but it isn’t perfect yet.

If two or more coding agents try to compile different apps at the same time (and I mean the very same second), the IDE may tell you the compiler is busy, or that it couldn’t find the debug app. If you are not in front of your computer, you might find the session stuck, waiting for some human help.

The limitations I’ve found so far were easy to work around, by explaining to Claude Code what to do when it happens. More on that in a moment.

Teaching your agent new tricks

XOJO-CODING.md will keep improving, and we’ll keep updating the example projects to give coding agents more context. Still, sooner or later you’ll find something the agent doesn’t know how to do.

In my case, Claude Code didn’t know how to encode constants, or how to use folders. It was dropping every single class into the root of the project. It worked, but imagine finding your way around a big project like that.

If your project is under Git, this is really easy to fix. Tell the agent you’re about to create some nested folders, or a constant with special characters. It will take a look at the repository and ask you to make the change in the IDE and save the project. Once you’ve done it, tell Claude Code, and it will look at the differences to see how the IDE wrote those files. From there, you can let it refactor the project and move everything into folders.

Then comes the important part: ask the agent to write down what it learned in AGENTS.md. Every new session reads that file, so the next one will already know how the IDE creates project files, and how you like to work. This is also where it added the note about the busy compiler.

If you’re working on an existing project, it gets even easier. You won’t need to show the agent how to use folders if your project already uses them, because it will follow what’s there. The more you use it, the better it gets. And the bigger the project, the easier it is for the agent to add new features in the same way you’re already working.

Try it yourself!

You can download the Mission Control project here:

Download GlobeProjectTest.zip

Open it with 2026r3, run it in a couple of browser windows, and watch your crew show up.

Working on Several Features at Once with Git Worktrees

Once you get used to delegating features, you’ll start wondering why you have to wait for one to finish before starting the next. This is where Git worktrees come in.

A worktree lets you check out several branches of the same repository at once, each one in its own folder. Since every folder has its own copy of the project file, the Xojo IDE just sees them as different projects and opens each one separately. You can have one agent adding a new panel in one worktree, while another one fixes a bug in a second worktree, without stepping on each other’s toes.

When a feature is ready, review the changes and merge the branch, just like you would with work coming from any other developer on your team. Or even better, ask the agent to do the merge.

A few things to keep in mind. First, each web app needs its own port. If two worktrees try to run their debug apps on the same port, only the first one will start. Ask each agent to use a different debug port in its worktree, and they’ll be able to run side by side.

Second, commit your AGENTS.md file. That way, every worktree starts with everything your agents have learned so far, and a finding from one worktree can be merged back for the rest. Just don’t write a specific port number there, or every worktree will inherit the same one. Tell each agent which port to use when you start the session instead.

And third, remember the rough edge I mentioned earlier: if two agents happen to compile at the very same second, the IDE may report the compiler as busy. That’s exactly the kind of note worth adding to AGENTS.md, so your agents know to wait a moment and try again.

Wrapping up

I didn’t expect this to work as well as it did. The agent writes the code, the IDE compiles it, Chrome shows the result, and the loop keeps going until the app works. Your job moves from typing code to deciding what to build, and reviewing what comes back.

Learn more about using Agentic Mode in the Docs and in the AI QuickStart. I’d love to see what you build with Agentic Mode. Share some screenshots or recordings in a new forum thread, or send me a private message if you prefer.

Happy coding!

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

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

Download Xojo

Breaking Changes First

I’d rather start with the uncomfortable part, so nobody gets surprised after updating.

Unhandled exceptions will now quit your app

Until now, the web framework was silently swallowing unhandled exceptions, and your app kept running as if nothing had happened. Desktop projects don’t behave like that. After going back and forth on it internally, we’ve decided to treat this difference as what it really is: a bug.

Starting with 2026r3, a web app will quit when an exception isn’t handled, unless you Return True from one of the UnhandledException events.

There are two of them. When something goes wrong inside a session context and you aren’t catching it in code, Session.UnhandledException fires first. A database call failing after the user presses a WebButton is a typical example. If you Return True there, the app keeps running. If you don’t, the exception keeps bubbling up and App.UnhandledException fires.

App.UnhandledException is your app’s last chance, and this is where the behavior changes. If you don’t Return Truethere, the app will print the stack trace, hoping it ends up logged somewhere, and quit.

If you really want things to work like before, add a Return True to App.UnhandledException and you’re done. But I’d encourage you to use this as an excuse to start paying attention to those exceptions. They are trying to tell you something. At the 2024 MBS Conference, Xojo MVP Jeremy Leroy gave a talk about tracking exceptions with Sentry, and I can’t recommend it enough:

Positioning controls by code

The second change comes from a series of bug fixes around positioning controls programmatically. The web framework had some issues here that made dynamic interfaces more painful than they should have been, and many of you ended up writing workarounds.

Web projects now place controls much closer to how Desktop projects do. The catch is that a workaround in your code may now be compensating for a problem that no longer exists. If you position controls by code, check your layouts after updating and remove the workarounds you don’t need anymore.

We try really hard to avoid breaking changes. In these two cases, we believe it’s the right call in the long run.

URL Router

On to the new stuff. The URL router is another piece of the puzzle on our way to SEO friendly web apps. Until now, if you wanted nice URLs, you had to parse them yourself in App.HandleURL, probably fighting with regular expressions along the way.

2026r3 adds a new WebApplication.AddURLRoute method. Imagine you are building a blogging system with URLs like this one:

/2026/06/25/build-a-threaded-find-in-files-solution/

You’ll need a WebPage to display a single post. Let’s call it BlogPostWebPage. With that in place, this one-liner in App.Opening is all it takes:

AddURLRoute("/<year:integer>/<month:integer>/<day:integer>/<slug:string>/", TypeOf BlogPostWebPage)

Two things are happening here. The obvious one: when a request matches the route, Xojo Web creates a new BlogPostWebPage instance and shows it. Notice the type next to each parameter name, too. A URL like /hello/06/25/some-post/ won’t match, because “hello” isn’t an integer.

The second one is more subtle, and it’s where this gets handy. Since the route defines named parameters, you can read them from the BlogPostWebPage.Opening event using Session.URLNamedParameter:

Self.Title = Session.URLNamedParameter("slug")

From there, it’s just a matter of using the slug to query your database and fill the page with the right post.

This is the first version of the router, and we’re looking forward to your feedback. If you find something we missed, please open a Bug Report or a Feature Request.

WebCanvas.DrawControlInLayoutEditor

Xojo targets keep borrowing ideas from each other. In the previous release, DesktopCanvas got a new DrawControlInLayoutEditor event, heavily inspired by WebSDKUIControl.DrawControlInLayoutEditor. Now WebCanvas supports it as well, so your canvas-based controls can show a preview of themselves in the Layout Editor instead of an empty box.

WebFileUploader Improvements

Until now, if a user picked the wrong file, the only thing you could offer was clearing the whole uploader and asking them to select everything again. That’s not great when they’ve picked ten files and only one of them was wrong.

WebFileUploader in 2026r3 adds the FileNameAt and RemoveFileAt methods, plus the FileCount and LastFileIndex read-only computed properties. With them, you can let your users change their mind and remove individual files before uploading.

WebRectangle.Pressed Event

Last, but not least, WebRectangle finally has a Pressed event. WebRectangles are commonly used to group other controls, like a card with a title, a picture and a couple of labels, so making the whole group clickable made a lot of sense. Child controls can still have their own Pressed handlers. If none of them handles the press, it keeps bubbling up until it reaches the parent WebRectangle.

Bug Fixes & Wrapping Up

The rest of the web side of this release is mostly bug fixes, more than 40 of them. As boring as that might sound, if just one of them makes your day to day a bit easier, it was worth it.

As usual, make sure to read the full release notes, because there’s much more in there than fits in a blog post. And thank you for taking the time to read this, test the betas, report bugs, send feature requests and renew your license. It all helps more than you might think.

Happy coding!

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

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

Download Xojo

MobileDocumentPicker: Beyond the Sandbox

Starting with Xojo 2026r3, your iOS apps are able to open and even save files outside the usual folders related to the app sandbox. Using the new MobileDocumentPicker class, it is now possible to open any available PDF document saved on the device (or even in iCloud) and display it using the MobilePDFViewer.

This also applies when saving files. For example, any PDF documents created using the PDFDocument class, any image, text or any other kind of document file you create in your iOS app can be saved for public availability outside of the sandboxed folders. Once saved, these documents can be opened by other apps installed on the same device, or even automatically synced via iCloud.

It is not necessary to enable any capability in your iOS project, or add entitlements or additional entries to the app’s .plist file, just use MobileDocumentPicker.Open and MobileDocumentPicker.Save methods.

Printing Arrives to iOS

In addition to the MobileDocumentPicker, we also added the MobilePrinterPicker starting with Xojo 2026r3. This control allows your app to print any of the most common file formats (for example PDF, images, text, html, .Pages and .Numbers) to any printer available on the network that is compatible with the AirPrint technology.

You only need to call the MobilePrinterPicker.Print method, passing along the FolderItem whose content will be printed. The iOS modal dialog will offer options to select the target printer and all of the print settings for that printer, from the page size, to the range of pages to print, enabling duplex printing, color printing, etc. 

Viewing Documents

Now that we are able to access documents beyond the app sandbox and print them, it would be great to have the ability to display the most common document formats in your iOS apps – plus allow users to edit and save their changes! That is exactly what the new MobileDocumentViewer does.

The MobileDocumentViewer allows your iOS app to view the following file formats:

• iWork documents.
• Microsoft Office documents.
• Rich text format, or RTF, documents.
• PDF files.
• Images.
• Text files with a uniform type identifier that conforms to the public.text type.
• Comma-separated values, or CSV, files.
• Video files.

And edit (and save) the changes made by the user in the following ones:

• PDF Files (signing, drawing, rotating pages, adding or deleting pages, adding pages from scan, etc.)
• Images (drawing, cropping, etc.)
• Video files (trimming)

You only need to drag the MobileDocumentViewer from the Library into the Tray area of the Screen where it is intended to be used. Calling the Show method on the instance will open the modal view to let users view and navigate among the received array of FolderItem instances of the documents to be shown.

To react to the changes made by the user in the compatible document file formats, there is the DocumentSaved event handler, which (once implemented) receives the FolderItem of the document that has been modified.

MobileSearchField

Available on Desktop and Web targets, the MobileSearchField has been added to the Mobile target.

In previous releases, it was possible to do a search or filter data in iOS apps using the iOSMobileTable control. However, there are situations where you may need more than one search control on the same iOS screen; and in some cases, you don’t need the search to display matching data in an iOSMobileTable.

For those scenarios, you can now add and use as many MobileSearchField controls as your app requires.

When using this control, you can not only set the default Hint or Text property values, but also enable a scope bar and set the title names for each scope. Think of the scope bar as a way to let users (and your app) filter results not only by the typed text, but also by a specific category, for example.

The scope bar can be enabled or disabled at runtime via code, as well as each title name displayed by the scope bar.

The main event handlers that you will probably want to implement for this control are:

• SearchPressed(). Fires when the user taps on the “Done” button on the device soft keyboard
• ScopeChanged(index As Integer). Fires when the user changes the current scope in the scope bar (if enabled for the search field instance
• TextChanged(). Fires every time there is a change in the text field of the SearchField control

iOSMobileTable SearchField

We also improved how the already available search field for iOSMobileTable behaves, especially when the iOS app is run on iOS 26+.

• If the app uses a MobileTabBar or MobileToolbar, then the associated iOSMobileTable search field will move automatically to the navigation bar section.
• When the search field is in the navigation bar section, it will be collapsed by default (displaying only the loupe icon), so it doesn’t take up extra space on the app screen when the user isn’t searching. Tapping on the loupe icon will expand the search field for the table, letting the user type. As soon as the search field loses the focus, it will collapse again as the loupe icon.

MobileMenuItem and MobilePopupMenu Improvements

Both MobileMenuItem class and MobilePopupMenu were introduced in Xojo 2026r2. In 2026r3, they received a number of improvements.

MobileMenuItem

• Icon property. It is now possible to use Picture.SystemImage or a Picture directly to assign an icon to each item.
• Symbol property. You can now assign an SF Symbol name to this property and it will be used as the item’s image. You can also assign multiple symbol names separated by semicolons. The first one found will be the one used.
  An advantage of using Symbol instead of Icon is that it will generate the assigned image at the expected size.
• AllowMulticolorSymbol property. When this property is set to True, the assigned symbol will use the Multicolor rendering mode instead of Monochrome.
• Separator. It is now possible to add separators to a menu using the same syntax as on Desktop: New MobileMenuItem(“-“).
• IntegratedPalette display mode. Starting with Xojo 2026r3, we added the IntegratedPalette to MobileMenuItem.RenderingModes. When used as the display mode on a submenu, it will be integrated into the main menu it is attached to using an horizontal format. This allows creating the kind of menus commonly found in many iOS apps.

For example, the following code:

Var horizontalSubmenu As New MobileMenuItem("")
Var firstSubmenu As New MobileMenuItem("Pencil")
firstSubmenu.Tag = "Pencil"
firstSubmenu.Symbol = "pencil"

Var secondSubmenu As New MobileMenuItem("Eraser")
secondSubmenu.Symbol = "eraser"
secondSubmenu.Tag = "Eraser"

Var thirdSubmenu As New MobileMenuItem("Lasso")
thirdSubmenu.Symbol = "lasso"
thirdSubmenu.Tag = "Lasso"

horizontalSubmenu.AddMenu(firstSubmenu)
horizontalSubmenu.AddMenu(secondSubmenu)
horizontalSubmenu.AddMenu(thirdSubmenu)
horizontalSubmenu.DisplayMode = MobileMenuItem.DisplayModes.IntegratedPalette

Var mainMenu As New MobileMenuItem
mainMenu.AddMenu(horizontalSubmenu)

Var firstMain As New MobileMenuItem("Triangle")
firstMain.Symbol = "righttriangle"
firstMain.Tag = "Triangle"
Var secondmain As New MobileMenuItem("Viewer")
secondmain.Symbol = "plus.viewfinder"
secondmain.Tag = "Viewer"

mainMenu.AddMenu(firstMain)
mainMenu.AddMenu(secondmain)
mainMenu.AddMenu(New MobileMenuItem("-"))

Var thirdMain As New MobileMenuItem("Delete")
thirdMain.Symbol = "trash"
thirdMain.Tag = "Delete"
thirdMain.Destructive = True
mainMenu.AddMenu(thirdMain)

Me.Menu = mainMenu
Me.DisplayMenuAsAction = True

will create this menu when displayed:

MobilePopupMenu

On the MobilePopupMenu side, it received several fixes and improvements. Also, since MobileMenuItem can now handle separators, MobilePopupMenu now includes the AddSeparator method already available in the DesktopPopupMenu counterpart.

And because MobileMenuItem can now handle an Icon or Symbol, you can expect these to be supported when the items are displayed in the popup menu control.

Symbols Everywhere!

The Symbol and AllowMulticolorSymbol properties were not only added to MobileMenuItem, starting with Xojo 2026r3, you will be able to set them for the following controls and classes on iOS:

• MobileButton
• MobileToolbarButton
• MobileSegmentedButton
• iOSMobileTableRowAction

That means you can now create more visual, modern (and colorful) UI designs for your iOS apps.

MobileScreen

A couple of interesting improvements in this area:

• MobileScreen.Show(makeCurrent As Boolean) – When the passed parameter is set to True, the new screen will substitute the current one without changing or being added to the app navigation stack. If the value is set to False, it will behave like the regular Show method when no parent screen is provided.

• MobileScreen.ShowModal – We added a couple more parameters at the end of the method signature. The first one allows you to set the size of the modal to be shown (Medium, Large, Resizable) using the new ModalPresentationSizes enum. The last parameter, when set to True, will display a grabber widget at the top of the modal so the user better knows they can drag, especially if the modal is set to ModalPresentationSizes.Resizable.

The Arrival of Dynamic Type

Dynamic Type is an Apple iOS feature that allows the user to set a preferred text size for apps that support it. That way, users can adjust the text shown by labels, text fields, text areas or even the captions on buttons to better fit their visual needs.

You can find this setting under Settings > Accessibility > Display & Text Size > Larger Text. From here, users can choose their preferred text size, and can also enable the Larger Accessibility Sizes switch if they need even bigger text than the standard range offers.

Starting with Xojo 2026r3, we’ve added a new Boolean property called UseAccessibilityFontSize to the following classes:

• MobileButton
• MobileLabel
• MobileTextArea
• MobileTextField

When this property is set to True, the controls will automatically display text at the size the user configured in their iOS Accessibility settings. Note that enabling this property forces the control to use the system font, since Dynamic Type only works with system fonts.

Reacting to Dynamic Type Changes

If you want to use some variations of the system font (for example, Bold), or manually react to user changes for the Dynamic Type settings, then you will find the new AccesibilityFontSizeChanged event handler on the MobileScreen class useful.

In addition, we added the shared method AccessibilityFontSize to the Font class, so you can retrieve the current Dynamic Type font size set by the user and react accordingly. For example, if you keep the UseAccessibilityFontSize set to False for your controls, this value lets your code apply any needed UI changes.

MobileTextArea and MobileTextField

These controls also received a small but useful feature: when you need to dismiss the keyboard and there is no suitable UI area to tap, the text field or text area can clear its focus and close the keyboard itself.

Now, the new Boolean AllowDoneButton property can be set to True to add a “Done” button in the associated view of the keyboard itself. This way, once the user has finished typing in the control, they only need to tap the “Done” button in the keyboard for it to be closed and the control focus to be cleared.

Summary

We can’t wait to see how the new features will make their way into your iOS apps. As you’ve seen, there are also a good number of improvements you can use to update your existing apps and delight your users even more. Share your comments and creations on the Xojo Forum.

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

Download Xojo

For about a year now, Jade, Xojo’s built-in AI chat assistant, has been able to help you with coding questions, code reviews, bug fixes and focused code generation. Agentic Mode takes things to an entirely new level.

Coding agents are separate products that are able to do interactive code generation directly on project files. Popular coding agents include Claude Code and ChatGPT Codex, but there are many others. I’ve personally found that Claude Code works well from inside the Claude desktop app.

Although most of the AI companies let you use their chat products for free, you usually have to purchase a plan to get access to the coding agent. Of course, there are some free plans around and you could even install a local LLM and an open-source agent if you wanted. Since the coding agent works directly on the project files, any coding agent will work with Agentic Mode in Xojo.

What is Agentic Mode?

For Xojo, Agentic Mode is a setting in the File menu that provides some guidance to the coding agent and allows the agent to request to run Xojo projects and get back compilation errors. It also tells Xojo to regularly reload files in the project as they are changed.

To use Agentic Mode you first have to save the project to text format. After doing this, you can select File->Agentic Mode to turn it on. This displays the Messages panel so you can see information about project files that get reloaded.

You can now go to your coding agent and add the folder containing your text project as a work folder. After doing that you can type prompts to the coding agent and watch it do its thing. The agent will think, change files, request to run the project, review any compilation errors and generally just chug along until it has finished the task you gave it. While this is all happening, you’ll be able to watch project items change in Xojo and even see the debug app start and stop.

Each coding agent works similarly, but they have their differences as well. They are also all highly capable and will learn new features as they work through your project and your prompts.

Agentic Mode in Action

To show you how Agentic Mode works, we will do two quick examples.

This first example creates an empty project and asks the coding agent to create an app.

Start Xojo, from the Project Chooser select Desktop and give it the name StockTicker. Check the “for AI (Agentic Mode)” checkbox and click Create. You will be immediately prompted to choose a folder. Select a folder and Xojo will automatically create a new folder in that folder with the name StockTicker, save the project as text into the folder and turn on Agentic Mode.

You can now open your coding agent (I’m using Claude Code for this example) and start a new session. Add the StockTicker folder as a working directory and select your preferred model (I used Sonnet 5.5/Medium). Now enter the prompt to create the app. I used this:

Create a stock ticker app. By default have it show some common stocks in the S&P 500, but allow the user to enter their own stock tickers. Use a web service to get values for stocks in common indices. Display the stock prices in a list.

Here is my initial setup with Xojo and Claude Code both open:

Claude Code chugged for a couple minutes and when it was done it had created this app:

Here is a (sped-up) video of the overall process:

The next example modifies an existing project. In this case, we will use the ToDo project that is included as a Xojo example. Using the Project Chooser, open the Desktop ToDo example and save it as a text project to a folder called DesktopToDo. Turn on Agentic Mode (File->Agentic Mode).

Open your coding agent, add the DesktopToDo folder and give it your prompt. I used this:

Please review and improve this project. Perhaps make the UI a little snazzier and clean up code as necessary.

The ToDo app UI went from looking like this:

To this:

It took less than two minutes for Claude Code to make these changes, fixing some of its own compile errors along the way. There were also code changes, of course. It even offered to make additional changes, such as add the ability to save the ToDo items between app launches.

Here is a (sped up) video of Claude Code working on this with Xojo:

Keep in mind that because these AI systems are non-deterministic you will get wildly different results from the same prompt. For example, in different tests with this same example and prompt, I got a changed ToDo app UI that was more colorful and had automatic saving and loading.

Other Agentic Mode Notes

You can toggle Agentic Mode on or off via IDE scripting with this command:

DoCommand("ToggleAgenticMode")

Many coding agents have their own built-in browser and can use that to run and test Xojo web apps.

You can use Xojo while a coding agent is changing things, but keep in mind that changes you make might get overwritten by agent changes.

When Agentic Mode is turned on, Xojo adds an empty AGENTS.md file to the project folder that imports the XOJO-CODING.md guidelines file. You can add your own tips and suggestions to AGENTS.md (and even have the agent do it itself), but keep the link to XOJO-CODING.md intact. If you already have an AGENTs.md file in that folder that you added then Xojo won’t overwrite it, so be sure to tell it to reference XOJO-CODING.md with something like this:

<xojo-coding>
Before answering ANY message (including questions, suggestions, and planning) read the @XOJO-CODING.md file, right now.
Begin your first reply with one line: "XOJO-CODING.md loaded", then answer normally.
</xojo-coding>

The Agentic Mode setting is saved with your Xojo text project file. This allows you to have projects that automatically activate Agentic Mode when they are opened.

I hope you find Agentic Mode helpful for your workflow! Read more in the Xojo Docs or get started with the AI QuickStart.

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

Download Xojo

Project Reloading

In prior versions of Xojo you could reload a project, after it had been modified, by using File -> Revert to Saved. This feature essentially closes and re-opens the entire project and it works with all project formats: Binary, XML and Text.

With 2026r3, this feature remains with a couple small tweaks. First, you can now reload the project without having to first modify it. An example when this might be useful is if you have just updated your Git client with the latest changes from your team and want to quickly reload the entire project.

This feature has also been renamed from “Revert to Saved” to “Reload Project”.

Project Item Reloading

Reloading the entire project can be handy, but is also somewhat overkill for text projects that save each project item as a separate file. If just a single file on disk was changed, then you may not want to reload the entire project, which could cause you to lose IDE changes, lose your place in the Navigator or just take too long.

You can now use File -> Reload Item to reload the selected item in the Navigator. Note that “Item” in the menu is replaced with the name of the selected item. This feature reloads the selected item and keeps it selected.

This feature is destructive, so if you have made changes to the project item in the IDE, they will be lost as the item is completely replaced by the version on the disk.

It is a quick way to reload an item that has been changed by a version control update or an AI coding agent. Reloading is also a great way to fix a borked edit, rather than doing multiple Undos.

This feature only works with Text projects.

Reload Changed Files

Finally, you may have multiple files you want to reload but don’t know exactly which ones they are. This sort of thing can happen with a version control update or an AI coding agent. Rather than force you to reload the entire project, you can now use File -> Reload Changed Files to reload the files on disk that are different than what is in the IDE.

This feature is destructive, so if you have made changes to the project items in the IDE, they will be lost as the item is completely replaced by the version on the disk.

This feature only works with Text projects.

IDE Scripting

The above features now also have equivalent IDE Scripting commands. They are:

• ReloadProject()
• ReloadProjectItem(itemPath As String) As Boolean
• ReloadChangedFiles()

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

Download Xojo

This is the output you get when copying a layout to text:

Window HelloThere
Inherits DesktopWindow
  Layout Property Width = 600
  Layout Property Height = 400
  Layout Property MinimumWidth = 64
  Layout Property MinimumHeight = 64
  Layout Property MaximumWidth = 32000
  Layout Property MaximumHeight = 32000
  Layout Property Title = "Hello World"
  Layout Property HasCloseButton = True
  Layout Property HasMaximizeButton = True
  Layout Property HasMinimizeButton = True
  Layout Property HasTitleBar = True
  Layout Property Resizeable = True
  Layout Property DefaultLocation = 2
  Layout Property Visible = True
  Layout Property ImplicitInstance = True
  Layout Property BackgroundColor = &cFFFFFF
  Layout Property MenuBar = 1436252159

  Control Button1 Inherits DesktopButton
    Layout Property Scope = 2
    Layout Property Left = 20
    Layout Property Top = 55
    Layout Property Width = 171
    Layout Property Height = 20
    Layout Property LockLeft = True
    Layout Property LockTop = True
    Layout Property TabStop = True
    Layout Property AllowAutoDeactivate = True
    Layout Property Caption = "Hello"
    Layout Property Default = True
    Layout Property Enabled = True
    Layout Property Visible = True
    Layout Property FontName = "System"

    Private Sub Pressed() Handles Pressed
      MessageBox("Hello " + TextField1.Text)
    End Sub
  End Control

  Control TextField1 Inherits DesktopTextField
    Layout Property Scope = 2
    Layout Property Left = 20
    Layout Property Top = 11
    Layout Property Width = 171
    Layout Property Height = 38
    Layout Property LockLeft = True
    Layout Property LockTop = True
    Layout Property TabIndex = 1
    Layout Property TabStop = True
    Layout Property AllowAutoDeactivate = True
    Layout Property BackgroundColor = &hFFFFFF
    Layout Property HasBorder = True
    Layout Property Enabled = True
    Layout Property TextColor = &h000000
    Layout Property AllowFocusRing = True
    Layout Property Visible = True
    Layout Property FontName = "System"
    Layout Property Text = "Xojo"
  End Control

End Window

You can copy that text and paste it back into a desktop project to add the window to it.

Note: Layouts that contain control sets do not copy/paste properly.

But one other cool thing you can now do is paste the above window text into a different project type, such as a web project. The window gets converted to a WebPage and its controls are converted to web controls. Here is what the above window looks like when pasted into a web project:

You could also paste it into an Android or iOS project:

When you do this, your controls, code and properties are moved over, but the layout itself is not otherwise adjusted. Control sizes and positioning may need adjustments for the different size layouts. But this should provide a way to give you a quick jumpstart when migrating some UI between project types. If there is enough interest in this capability, perhaps we can add some conversion rules to help adjust control position and sizing between project types.

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

Download Xojo

Most existing DesktopListBox code will compile with little or no change when transitioning to DesktopTable. At the same time, DesktopTable adds features that previously required custom controls or additional code.

What’s New?

DesktopTable adds support for:

• Frozen columns and rows — Keep important columns, headers, or totals visible while scrolling

• Merged cells — Span cells across rows and columns for titles, groupings, and custom layouts
• Sticky section headers — Keep section headers pinned as their section scrolls
• Hidden and reorderable columns — Hide columns without removing their data, or let users rearrange them
• Per-row heights — Set individual row heights and optionally allow users to resize rows

• Insets — Add space before the first or after the last row
• Progress bars, checkboxes, and containers — Built-in cell types for richer data presentation

• Custom cell controls — Use CellBoundsAt to position your own controls over cells
• Automatic Right-to-Left support — The table automatically adapts and aligns columns and text for right-to-left languages

• Virtual data sources — Work with large datasets without storing every row in the control
• CSV and TSV support — Save and load table data directly
• Row swipe actions — Provide familiar leading and trailing actions on macOS, Windows, and Linux touchpads

• Live column resizing — Respond while a column is being resized, as well as when resizing finishes
• Custom drawing and macOS vibrancy — More control over the table’s appearance and behavior

Moving from DesktopListBox

The transition is intentionally straightforward. Change the super of your DesktopListBox control to DesktopTable, build your project, and address the few members that have been renamed.

Most familiar APIs—including AddRow, CellTextAt, ColumnCount, ColumnWidths, RemoveRowAt, and SelectedRowIndex—retain their existing names.

A Few Things to Check

Some behavior is intentionally different. In particular, row reordering with a DataSource or expandable rows requires you to handle DragReorderRows, and row dragging requires DragRow to populate the DragItem and return True.

Sorting also removes merged cells, so applications using merged cells should re-apply their merges after sorting. Frozen rows retain their position and cannot be reordered.

If you want to improve performance when adding and removing rows, you can set AllowRowAnimation to False.

An Enhanced IDE Experience

We couldn’t introduce DesktopTable without enhancing the IDE experience as well. Table editing in the IDE is now more intuitive, compared against DesktopListBox, making it easier to edit and work with your tables.

We’ve also updated the debugger to better handle DesktopTable contents, efficiently loading rows dynamically and allowing you to jump directly to and inspect specific rows without loading the entire table.

Final Thoughts

DesktopTable gives existing DesktopListBox applications a familiar starting point while opening the door to considerably richer table interfaces. Stay tuned for more blog posts exploring many of its exciting new features!

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

Download Xojo

During internal testing for Xojo 2026r3, we identified this issue and have already fixed it. The workaround below is for users who have the previously described setup but are are running Xojo 2026r2.1 or earlier releases and need to test their iOS projects under any of the iOS 27 Simulators. Note that this issue doesn’t happen if you debug your iOS projects on a physical device running iOS 27.0.

The workaround

Until Xojo 2026r3 is released, the workaround is simple: just add a new Build Script to your iOS project, placed right before the Sign step, under the Build Settings > iOS section of the Project Navigator:

Then add the following snippet of code to the associated Script Editor:

Var buildLocation As String = CurrentBuildLocation
Var appPackageName As String = CurrentBuildAppName

Var cleanBinaryName As String = ReplaceAll(appPackageName, ".app", "")

Var command As String
command = "cd " + buildLocation + _
" && cd " + Chr(34) + appPackageName + Chr(34) + _
" && install_name_tool -change /System/Library/PrivateFrameworks/WebKit.framework/WebKit /System/Library/Frameworks/WebKit.framework/WebKit " + Chr(34) + cleanBinaryName + Chr(34) + _
" && cd .. " + _
" && xattr -cr " + Chr(34) + appPackageName + Chr(34) + _
" && codesign --force --deep --sign - " + Chr(34) + appPackageName + Chr(34)

Var result As String = DoShellCommand(command)

To test it, select Project > Run On and choose any of the available iOS 27.0 Simulators already installed on your Mac as part of the Xcode plus iOS SDK 27 installation process.

If everything goes well, your iOS project will run without issues as it did with previous Xcode and iOS SDK configurations, or even during the beta cycle for Xcode 27.0 and iOS SDK 27.0.

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

Download Xojo

The issue the user was dealing with was the Developer ID popup menu showing a different name than expected for the Developer ID Team. Interestingly, this problem didn’t occur on his second Mac.

As a result, he was not able to select any of the “Build For” options, because the remaining developer certificates installed on that Mac were issued under the same Team ID but with a different Company Name.

In this particular case, a couple of X.509 certificates OIDs (think of these as certificate attributes) are worth highlighting:

• 2.5.4.11 – Organizational Unit Name (OU): This corresponds to the Team ID for Apple Developer Certificates. It is unique and never changes.
• 2.5.4.10 – Organization Name (O), also known as the Legal Entity or Company Name: This value can be changed from the Apple Developer portal, under Account > Membership Details, but only if your developer program membership is registered as an Organization (not an Individual).

The underlying problem

In this particular case, several factors converged:

• The certificate issued under the unexpected Team name had expired long time ago but was still present on that Mac. This part wasn’t too bad, Xojo can safely ignore expired certificates.
• The real issue was that this expired certificate had been installed on that Mac long before the other (correct) certificates using the current Organization Name. Because of this, when Xojo iterated through the installed certificates at the system level, it encountered the expired one first – and mistakenly used its Organization Name for all certificates sharing the same Team ID.

Now that we’re aware of this behavior, we have fixed it for Xojo 2026r3.

The Solution

Once we identified what was happening, the fix to this particular case was simple: delete the expired, offending certificate from the Keychain Access app on that Mac.

The Recipe

If you run into a similar issue, whether it is trouble selecting a specific Team ID, or missing “Build For” options, the best first step is to use the Inspect… option under the Developer ID popup menu.

The Certificate Inspector lists all installed certificates for every Team in a much simpler way than digging through Keychain Access. It also provides additional details and, when possible, direct actions to resolve some of the most common issues related to managing your Apple Developer Certificates.

Reviewing Certificates in More Depth

Alternatively, or if you are running a Xojo version prior to Xojo 2026r1, you can inspect your certificates manually by running the following command in Terminal:

security find-certificate -a -p | awk '/---BEGIN CERTIFICATE---/{flag=1; print; next} /---END CERTIFICATE---/{print; flag=0; print "---END---"} flag' | while IFS= read -r line; do if [ "$line" = "---END---" ]; then echo "$cert" | openssl x509 -noout -subject -enddate 2>/dev/null; cert=""; else cert="$cert$line"$'\n'; fi; done

The output will list, in the Terminal window, all the Apple Developer certificates found on your computer along with some key pieces of information worth inspecting:

• CN (Common Name): Indicates the certificate type, for example, Development, Developer ID Application, or any other Apple development certificate.
• OU (Organizational Unit/Team ID): Remember, this value never changes for your Apple Developer Program membership.
• O (Organization): The current Organization Name associated with the certificate. This can be changed, but only for Organization-type membership (not Individual).
• notAfter. The expiration date for that certificate.

Conclusion

This edge case is a good reminder that expired certificates sitting in your Keychain can quietly cause unexpected issues. Thanks to the fix in Xojo 2026r3 and the new Certificate Inspector, spotting and resolving these problems are now much easier.

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

Download Xojo

You may have seen this thread in the Forums, This is the farthest I’ve pushed canvases, showcasing Xojo user Christian Wheel’s use of the Canvas control from a custom animated GIF renderer built entirely in Xojo code, to slick audio production tools for radio and podcasting. Many people reached out and wanted to know more about this project and what else Christian has been doing with Xojo. As it turns out, he’s been doing quite a lot! In this post Christian talks about vibe coding, laser cutters and why Xojo’s “idea-to-executable” speed made it the perfect tool for getting things done, at Apple and beyond.

Mac, Windows or Linux?

Windows & MacOS, I use both daily. I generally prefer Windows desktops and Mac laptops, even though I do have a Mac Studio and a Windows laptop too. I literally have dozens of computers, haha.

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

Honestly, nobody really asks me about my work! Most people know me from my work as a radio host and DJ, so that’s where the majority of my interactions occur with other people. My software development endeavors have always been my “side-gig” even though I’ve had some successes in that area too. Just the fact that I get to talk about computers with anybody is a breath of fresh air for me.

What software or skill is on your “Learn Next” list and why?

Last year I picked up a laser cutter and 3D printer and haven’t yet been able to explore them as much as I would like to. I’ve done some 3D modeling for use in animations and visuals, but that’s very, very different from modeling tangible objects, where there needs to be a lot more consideration for engineering principles involved. I also feel like it’s cliche in 2026 to add “AI” to a list of things to learn, but it’s genuinely true. I’ve been running some local models and while I’ve dabbled a bit, I’d like to dive more into training my own models, LoRAs, etc.

Between those maker tools and my UV Printer, I want to lean more into making aesthetic mods for PC hardware and getting more into exotic and custom PC builds.

Even though I’ve been a “content creator” on the radio for decades (including a “call for help” radio show about tech, software and hardware), I plan on going all-in on YouTube in the tech space shortly, covering everything from PC part reviews, unboxings, benchmarks, build guides, troubleshooting, homelab projects, creator gear, software tools, Apple, and extreme-themed PC builds. I’ve made significant investments in building studio spaces and an 8K cinema-grade production pipeline, so I’m taking this seriously!

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

I definitely did not have the rise of Vibe Coding on my Bingo card. There are so many interesting aspects to it. At the end of the day, getting more people interested in software development is a great thing for the industry. There are lots of people in our field who enjoy gatekeeping it, and I understand that the industry was already fiercely competitive before the flood gates opened to everyone. But this is the new reality and everyone has to adapt. But on the the other hand, for people without a strong background in development, experience with security and proper testing, you end up with a lot of buggy, potentially dangerous applications created by those without the experience to put in the final 10% of every project (which, as we know, is what takes 90% of the time). This is all evolving so fast and there’s no doubt in my mind that we’re going to see some very high-profile embarrassments and systemic software failures caused by vibe coding. And in a way, we have to, that’s the only way things will improve.

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

There are so many great third-party tools in the Xojo ecosystem. While I love learning new things, sometimes you just need to get something done and it’s faster to buy something rather than build it yourself. Shout outs, in no particular order, to Christian Schmitz/MBS, Anthony Cyphers/GraffitiSuite, Tim Parnell/Lifeboat+TPLM, Jim McKay/PiDog, Björn Eiriksson/Einhugur, Marc Zeedar/xDev, and so many more that really boost the Xojo experience. For testing, Parallels on Mac, and VMware Workstation on Windows, are invaluable to me. The ability to take and revert to snapshots in seconds is like magic. You also can never underestimate a good text or hex editor. For text on macOS I use BBEdit and on Windows Notepad3. UltraEdit is fantastic for hex on both.

How/When did you find Xojo? What did you first build with Xojo?

I discovered REALbasic in the early 2000’s when Microsoft made the decision to go all-in on VB.Net and away from VB6/COM. While it shared a lot of the same keywords and syntax, VB.Net is a fundamentally different language. So I figured if I had to learn a new-but-similar language anyway, I might as well learn something cross-platform. For much of the decade I was a DIY Windows snob though, and refused to spend on Apple hardware, which kept me using OS X on Virtual Machines and such. Once the iPhone became popular I finally gave in and bought an iPhone to complement my Android, and a MacBook Pro to complement my gaming laptop. Most of the things I built with Xojo were just internal tools, things that improved my own workflow in radio and DJing. Many of my tools proved useful to coworkers, and with the increase in Apple’s hardware market share, Xojo was instrumental in allowing me to create distributables for everyone.

What do you build with Xojo now?

Most of the things I’m building at the moment are audio related. I have a ton of legacy VB code that deals with audio on Windows, and I’m slowly Xojo-ing it to be cross-platform. One of my main apps I’ve been developing for 4 years now, is called PlaylistPal. It’s a playlisting app for DJ’s that basically lets them import playlists from any source, streaming service, or even a text request list, and load it into their DJ software. There’s a lot of work done under-the-hood to resolve songs into universal ID’s and let DJs match those playlist entries with music they already own.

I’ve also been building audio production software for radio shows and podcasts. As shown in the forum post, the Xojo canvas is a powerful tool. It actually reminds me of the old days of DOS programming when you had to draw everything yourself, handle mouse and keyboard input at a very low-level, and actually optimize your code to run fast.

It has been fun to create new UI elements in the canvas. Another Canvas-related project I’ve been working on is an animated GIF control, completely in Xojo code. It parses the binary image data of an animated GIF file and uses a timer for each frame’s duration. It can be a bit slow to load all the frames to memory, but it does so in a thread so as to not slow your app down. It supports transparency via alpha channel or color replacement. It’s containerized so you just drop it into a Window, set some properties, call some methods, and receive events. I still have some bugs to work out but it’s been a lot of fun to develop.

I also just recently fell into a project creating digital signage software, for billboards, restaurant menu boards, trade show screens and such. I needed software to control my own LCD panels and found the existing options lacking or overly complicated, so I decided to create my own in Xojo. The wonderful thing that Xojo brings to a project like this is I can compile for everything! The user can create their slideshow on Windows or Mac and run the project connected to their screens on anything from a Raspberry Pi to a Mac Mini.

Do you earn a living with Xojo?

At the moment, no. I don’t have anything for sale. But eventually, once my software is at a point where I feel it’s marketable I’ll flip that switch. Until then, it’s test, test, test!

Do you use Xojo for any hobbies?

I find that Xojo, both Desktop and Web, makes GREAT frontends for AI applications. I have a great little AI stack for audio that I’ve developed on Windows. On Desktop I can build a UI to run the python scripts directly and capture their output, or I can build it into a Web App and create an API that I call from a macOS or Web app. The same python scripts can be Dockerized for Linux deployment when I want to put them on the internet and build a real web app to control them. I recently started playing with RunPod, which lets me load my Docker apps in their cloud and spins up instances on demand, so they can use cloud GPUs that aren’t practical to host locally.

What’s your biggest Xojo success?

Probably using it at Apple. I worked for Apple for a few years and quickly identified the need for a few internal tools to make things simpler for our department. I used Xojo to create them and it was fast and easy to work with, simple to make updates, and it was just accepted. Nobody questioned what language I was using, they just cared about functionality. But Xojo’s rapid idea-to-executable workflow really worked in my favor at Apple.

Looking back, how long did it take for your app vision to evolve from a blank project into a working solution?

What I like about Xojo is that you can go from nothing to something SO quickly. It’s adding all the niceties that can take a long time. Little touches and details can all be accomplished if you’re willing to put in the work. Of course, not every project requires you to put in the work. You don’t need smooth animations and lots of options for everything you build. I think for most of us, we have an idea, spend some time in the code editor building out our algorithm, and then haphazardly toss a few buttons and textfields onto a Window to test things out. Only once we’ve got something somewhat-working do we refine the user experience and engage with the artistic side of the app. That means for personal tools, you can go from zero to finished in a few minutes or hours. But for a major project… I mean gosh, I’ve been building PlaylistPal for FOUR YEARS and still make updates constantly, but I had friends testing it by the end of the first week. Your app is really as good as the time you put into it, but the benefit of Xojo is that you’re generally free to pause and release at any point along the way.

How do you decide when to use Xojo versus another tool or language?

I think personally, these days I default to Xojo unless the project has a need that Xojo can’t address. For example, I recently had a Windows project that required a single portable executable with no accompanying libraries. I could, of course, use Xojo and wrap up the project in something like BoxedApp, but that can end up being problematic in other ways. So I ended up using .Net for that one. But other than exceptions like that, Xojo is my go-to these days. I have decades of classes and modules that already have a bunch of code that I’m used to including in every project, so I try to stick to it as much as possible unless there’s a reason to use something else.

What does Xojo do particularly well compared to other tools?

The basics between platforms is largely the same and the differences are insulated from you, for the most part. Obviously the more things you want to do that deviate from standard behaviors, the more work you’ll need to put in, but once you wrap your head around the way Xojo does things, there’s only a little bit you need to learn about other platforms in order to implement your vision.

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

• Ease of cross-platform. Most things just work seamlessly across platforms and I don’t have to worry about it. Really intricate algorithms that I wrote for desktop can be literally copied and pasted into a web app. That’s just so… chef’s kiss.
• Canvases. They’re a blank slate that lets you create whatever you can imagine. If you want a button with a dragon on it that breathes fire when you click it, as long as you’ve got the time and the talent, you can create it.
• I’ve been diving deep into Xojo Web lately. I love that you can do anything from build a full web app with pages and controls or go really low-level to respond to individual HTTP requests. It’s really great.

How important has the Xojo community been in your development journey?

Absolutely vital. The community is a lifeline, everyone there truly wants to be helpful to others. You also never know when someone on the Xojo dev team may drop in to offer some advice too. I know this for sure, I would have never been able to create the things I have without the community.

Where do you typically go when you get stuck?

Depends on what I get stuck on! If it’s a language or framework question, it’s either the Xojo Documentation site, or Google to end up on a Xojo forum post. If it’s an approach or algorithm question, StackOverflow has a lot of answers. Chatbots are also getting quite adept at answering some of these question as well.

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

I really only need one word: Versatile. I really believe that versatility is Xojo’s greatest strength.

What features or improvements would you most like to see in future Xojo releases?

Something I think Xojo could do better is to build in a lot of the controls or behaviors that we end up creating ourselves. Some control examples from .Net that ship with the framework include CheckedListBox, FileSystemWatcher, ListView, LinkLabel, PropertyGrid, SplitContainer, StatusStrip, TreeView, etc. These are all things that we could (and many of us have) build ourselves but it would be nice to have a larger collection of controls built in.

What advice would you give to someone just getting started with Xojo?

• Make sure you’ve got an open mind! The “Xojo way” of doing things is not always the same as the way you may be used to.
• Don’t use DoEvents! The temptation is huge, and I know it worked in VB, but there’s a good reason why everyone advises against it. There are a select few times when it’s appropriate and when you encounter one you will likely have enough experience with the language by then to know it’s okay. Until then, just say no!
• Have patience with folks in the forums. Everyone really does want to help, even when things get heated. There’s a wide mix of people with varying experience levels, spoken languages, neurotypical/neurodivergent, and varying stress levels, so keep in mind that everyone generally means well even if they may have a hard time expressing it at times.

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

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

Download Xojo

Which function should you use when your app needs to:

• remember a user’s password,
• save an API token in a local settings file,
• check that an API request was not changed, or
• verify that an update came from you?

The examples below answer those questions with small, focused scenarios. They show where each function fits. They are not complete security products.

A good starting point is:

• Use PBKDF2 when you need to check a password later.
• Use AES when you need to hide data that your app must read again.
• Use HMAC when two trusted systems share a secret and need to detect changed messages.
• Use Ed25519 when one side signs data and other parties only need to verify it.

Example 1: Remembering a user’s password with PBKDF2

Imagine a desktop or web app with a login screen. When a user creates an account, you need to save something that lets you check the password later.

Do not save this: correct horse battery staple

If somebody gets the database, they immediately have the user’s password. A plain SHA-256 hash is not a good replacement because attackers can calculate fast hashes very quickly and try large lists of common passwords. PBKDF2 is designed for this job. It combines the password with a random salt and repeats the calculation many times.

Var password As String = "correct horse battery staple"
Var salt As String = EncodeHex(Crypto.GenerateRandomBytes(16))
Var iterations As Integer = 100000
Var derived As MemoryBlock = Crypto.PBKDF2(salt, password, iterations, 32, Crypto.HashAlgorithms.SHA2_512)
Var storedHash As String = EncodeHex(derived)

Save salt, iterations, the algorithm name, and storedHash in the user’s record. The salt does not need to be secret. You need it again when the user logs in.

Var suppliedPassword As String = "correct horse battery staple"
Var calculated As MemoryBlock = Crypto.PBKDF2(salt, suppliedPassword, iterations, 32, Crypto.HashAlgorithms.SHA2_512)
Var calculatedHash As String = EncodeHex(calculated)

If calculatedHash = storedHash Then
  MessageBox("Password accepted")
Else
  MessageBox("Password rejected")
End If

The app never needs to recover the original password. It calculates the value again and compares it with the stored one.

The iteration count in this example is only an example. Test it on the slowest computer you support. Store the count with the hash so you can increase it later and update old records after a successful login.

Use Crypto.GenerateRandomBytes here because the salt must not be predictable. The same function is useful when you need a random token, nonce, or initialization vector.

Example 2: Saving an API token in an encrypted settings file

Now imagine a desktop app that lets a user connect to an online service. After the user enters an API token, the app should remember it without saving readable text to its settings file.

This is a job for symmetric encryption. The app uses the same secret key to encrypt and decrypt the value.

AES accepts keys that are 16, 24, or 32 bytes long. The initialization vector is 16 bytes for AES. This example uses a 32-byte key and a new 16-byte IV:

Var secretKey As String = Crypto.GenerateRandomBytes(32)
Var initializationVector As MemoryBlock = Crypto.GenerateRandomBytes(16)
Var apiToken As String = "token-from-the-service"
Var encryptedToken As MemoryBlock = Crypto.AESEncrypt(secretKey, apiToken, Crypto.BlockModes.CBC, initializationVector)

To read the token later:

Var decryptedToken As MemoryBlock = Crypto.AESDecrypt(secretKey, encryptedToken, Crypto.BlockModes.CBC, initializationVector)
Var apiTokenAgain As String = decryptedToken

The IV is not a password and does not need to be secret. Save it with the encrypted value. You need the same IV for decryption.

The key is the difficult part. If you generate a new key every time the app starts, the app cannot decrypt yesterday’s settings. A real application must store the key in a suitable secret store, derive it from a user-provided secret, or keep the sensitive value on a server. Do not put a production key directly in the source code.

The encrypted record might contain these fields:

version
iv
ciphertext

Store the IV and ciphertext as Base64 or hexadecimal text if the settings format cannot hold binary data. Store a version so you can change the format later.

CBC encryption hides the token, but it does not prove that the ciphertext was not changed. For real data, authenticate the encrypted record as well. With CBC, that means using an encrypt-then-MAC design with a separate MAC key. Another option is a vetted authenticated-encryption library or a service that provides an AEAD mode.

Do not reuse an IV with the same key, and do not use ECB mode for application data.

Example 3: Signing an API request with HMAC

Suppose you control both a client and a server application. The client sends an order to the server, and the server needs to know whether somebody changed the request while it was being sent.

The client and server can share a secret. The client signs the request with HMAC, and the server calculates the same HMAC. If the values differ, the server rejects the request.

Var sharedSecret As String = "replace-this-with-a-real-secret"
Var requestText As String = "POST|/api/orders|1714492800|{""id"":42}"
Var requestData As MemoryBlock = requestText
Var signature As MemoryBlock = Crypto.HMAC(sharedSecret, requestData, Crypto.HashAlgorithms.SHA2_256)
Var signatureText As String = EncodeBase64(signature)

Send requestText and signatureText to the server. The server must build exactly the same text before calculating its own signature. A different separator, line ending, or JSON layout produces a different result.

A signature by itself does not stop somebody from sending the same valid request again. Include a timestamp and reject requests that are too old. For an operation that must only happen once, include a unique request ID and record IDs that the server has already processed.

HMAC is a good fit for two backend services or a controlled client-server arrangement. It is a poor fit when you ship the shared secret inside an untrusted desktop or mobile app. A secret compiled into an app can eventually be extracted.

Example 4: Verifying an update with Ed25519

A different situation comes up when you distribute application updates. The update server should be able to sign a file, but the installed app should only need to verify it. The installed app should not possess a secret that could create fake signatures.

Use a public and private key pair:

• Keep the private key on the signing machine.
• Put the public key in the application or distribute it through a trusted channel.

Var privateKey As String
Var publicKey As String

If Crypto.ED25519GenerateKeyPair(privateKey, publicKey) Then
  Var updateInfo As String = "version=4.2.1|sha256=..."
  Var signature As MemoryBlock = Crypto.ED25519Sign(updateInfo, privateKey)

  If signature <> Nil And Crypto.ED25519VerifySignature(updateInfo, signature, publicKey) Then
    MessageBox("Update information is authentic")
  End If
End If

In a real updater, verify the signature before trusting the version or downloading the file. The signature does not prove that the update is safe by itself. It proves that the data matches the private key associated with the public key.

Keep the exact bytes stable. If the signing tool adds a line ending but the app removes it before verification, the signature will fail.

Which function solves which problem?

Start with the problem, not the function name. Ask what the other side needs to do:

• Does it need to check a password? Use PBKDF2.
• Does it need to read the original data? Use encryption.
• Does it need to detect a changed message and share a secret with the sender? Use HMAC.
• Does it need to verify a message without being able to create signatures? Use a public-key signature.

A short safety checklist

1. Never store plaintext passwords.
2. Do not use a fast general-purpose hash as a password-storage scheme.
3. Do not hard-code production secrets in source code or a desktop application.
4. Generate salts and IVs with Crypto.GenerateRandomBytes.
5. Use SHA2_256 or stronger for new hashes and HMACs. Avoid MD5 and SHA-1 for new security designs.
6. Do not treat AES-CBC ciphertext as authenticated unless you add an integrity check.
7. Keep the exact bytes being signed stable.
8. Test wrong passwords, wrong keys, changed messages, replayed requests, and corrupted ciphertext.
9. Check the Xojo compatibility notes for every algorithm you choose.
10. Use an established format or library instead of inventing a cryptographic protocol.

The Crypto module gives you the operations. Your application still has to decide where keys live, what gets signed, how data is formatted, and how keys are replaced. Those decisions determine whether the example can grow into something you can support.

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

Download Xojo

This guide walks you through the complete process of signing EXE and DLL files on Windows with Azure Artifact Signing.

Here’s the shape of it, so you know what you’re signing up for:

• One-time setup (Steps 1–9): Azure account, portal clicks, and identity validation. This is the slow part. Budget a day to a week for the identity check to clear.
• Every build (Step 10): one script that signs your exe and DLLs in seconds.

If you’ve already done the setup, skip straight to Step 10.

Why I Picked Azure Artifact Signing

• $9.99/mo for up to 5,000 signatures (Basic tier), with no USB hardware token to manage.
• Fully managed. Microsoft rotates the certificates daily behind the scenes. You never see or store a private key.
• Identity-based publisher reputation. Public Trust signing ties the signature to your validated identity instead of a certificate you manage yourself. SmartScreen warnings can still appear for first-time or low-volume downloads; signing does not guarantee they will disappear immediately.

A note on names: this service was called “Azure Trusted Signing” until recently. Same thing, new name. If you see “Trusted Signing” in older docs or screenshots, it’s the same service.

Prerequisites

1. A Microsoft account (you get one when you sign up with Azure).
2. A paid Azure subscription.  This is the #1 early blocker: Artifact Signing does not work on free/trial/sponsored subscriptions. Upgrade to pay-as-you-go first (Cost Management + Billing → your subscription → upgrade) – https://azure.microsoft.com/en-us/products/artifact-signing.

Step 1 — Register the resource provider

Quick orientation first: an Azure subscription is the billing container for everything you create. Azure charges your services to it, and it also defines where those resources live and who can access them. When you signed up, Azure created one for you automatically (often with a forgettable default name like “Azure subscription 1”).

A separate subscription is optional. If you want clean billing and access boundaries for signing, create or dedicate one; otherwise, use your existing paid subscription and keep the signing resources in a dedicated resource group.

Then:

1. Portal → Subscriptions → the subscription you chose.
2. Left menu → Settings → Resource providers.
3. Find Microsoft.CodeSigning → click the … → Register. Wait for Registered.

Step 2 — Create the Artifact Signing account

Keep the signing resources together in the same subscription and a dedicated resource group.

1. Portal search → Artifact Signing Accounts → Create.
2. Subscription: the paid subscription you chose. Resource group: new, e.g. rg-artifact-signing.
3. Account name: 3–24 alphanumeric, starts with a letter, globally unique (no consecutive hyphens). e.g. xojoappsigning.
4. Region: pick one you’ll remember; it determines your signing endpoint.
5. Pricing: Basic unless you’ll exceed 5,000 signs/month.
6. Create, then note the Account URI on the overview page. It follows the pattern https://<region-code>.codesigning.azure.net/.

Step 3 — Assign the Identity Verifier role

You need this before the identity-validation button becomes clickable.

1. From your Artifact Signing account, left menu → Access control (IAM) → Add role assignment.
2. Role: Artifact Signing Identity Verifier (use the search field) → assign to your own user account.

Step 4 — Identity validation (the real gate)

From your Artifact Signing account (the one you created in Step 2), go to the left menu → Objects → Identity validations → New Identity → Public.

Public is what you want for normal app signing (it’s what SmartScreen cares about).

Fill in your legal business name, website, emails, business identifier (tax ID / DUNS), and address. Two gotchas that bite everyone:

• The secondary email must be on the same domain as the primary.
• Individual developers: the form pulls from your Azure billing account, and its name/address must exactly match your ID.

What happens next: status goes In Progress → Action Required (this is the point when you may have to wait a few hours to days… In my case, it took only an hour). You’ll be routed through a third-party verifier (AU10TIX). You upload a government ID and a selfie from your phone, then add the resulting Verified ID to Microsoft Authenticator and share it back (another hour or so).

Timeline: officially 1–20 business days; in practice often hours to a few days. If it stalls, re-submit with a different identifier (tax ID instead of DUNS) and make sure your company name/address match your documents exactly.

Step 5 — Create the certificate profile

1. From your Artifact Signing account, left menu → Objects → Certificate profiles → Create.
2. Type: Public Trust.
3. Name it (5–100 chars), then pick your completed identity validation under Verified CN and O.
4. Create. You never see or hold the certificate. It’s rotated daily behind the scenes. The public cert is embedded in every file you sign.

Step 6 — Assign the Certificate Profile Signer role

This is the role that lets you actually sign. Because we’re using the Azure CLI, it goes on your user. No app registration is needed (this is a separate/alternative process, but we’re not talking about that in this article).

1. From your Artifact Signing account, left menu → Access control (IAM) → Add role assignment.
2. Role: Artifact Signing Certificate Profile Signer → assign to your own user account.

Give role assignments a few minutes to propagate. If you try signing immediately and hit a 403, wait ~5 minutes and retry.

Step 7 — Install the signing tools

First, the Azure CLI: winget install Microsoft.AzureCLI

You’ll use it in Step 9 to authenticate with Azure.

SignTool comes with the Windows SDK. Install it with: winget install --id Microsoft.WindowsSDK --exact

 Run this to find the newest x64 signtool.exe:
Get-ChildItem "C:\Program Files (x86)\Windows Kits\10\bin" -Recurse -Filter signtool.exe | Where-Object { $_.FullName -match '\\x64\\signtool\.exe$' } | Sort-Object FullName -Descending | Select-Object -First 1 -ExpandProperty FullName

Note the path down.

.NET 8 runtime (x64).

Microsoft Visual C++ Redistributable.

Artifact Signing Client Tools:winget install -e --id Microsoft.Azure.ArtifactSigningClientTools
This installs Azure.CodeSigning.Dlib.dll (the plugin signtool uses to talk to Azure).

 Locate the actual dll path after install:
Get-ChildItem -Path "C:\Program Files","$env:LOCALAPPDATA" -Recurse -Filter Azure.CodeSigning.Dlib.dll -ErrorAction SilentlyContinue | Select-Object -First 1 -ExpandProperty FullName

Note the path down.

If signtool gives you “command not found”, that’s normal; it’s not on PATH. Use the full path, or add ...\10\<version>\x64 to your PATH.

Step 8 — Create the metadata file

This is a small JSON with three values. Name it anything you like, e.g. artifact-code-signing.json:

{
	"Endpoint": "https://<region-code>.codesigning.azure.net",
	"CodeSigningAccountName": "xojoappsigning",
	"CertificateProfileName": "...."
}

This JSON file will be used a lot, so save it somewhere safe.

• Endpoint = your account URI (region-specific; must match where the account + profile live, or you get a 403).
• CodeSigningAccountName = the Artifact Signing account name from Step 2.
• CertificateProfileName = the certificate profile name you created in Step 5.

Step 9 — Authenticate with the Azure CLI

az login

This opens your browser; sign in with the Microsoft account tied to your Azure subscription. When signtool runs, the dlib picks up your logged-in Azure CLI session automatically.

If you have multiple Azure subscriptions, point the CLI at the right one, then confirm it took:

az account set --subscription "<your subscription id>"
az account show --query name -o tsv

The second command should print your code-signing subscription’s name. If you also have multiple Microsoft tenants (a personal account and a work account, for example), log straight into the right one:

az login --tenant "<tenant id>"

You may occasionally need to re-run az login after long idle periods.

Step 10 — Sign your Xojo app

Just remember, you need to sign the compiled application after each new build.

What to sign (and skip)

Your Xojo Windows build folder looks roughly like this. Sign the binaries you build or distribute under your publisher identity; leave Xojo, Microsoft, and other vendor-signed dependencies alone.

Windows 64 bit/
└── YourApp/
    ├── YourApp.exe              ← sign
    ├── <your own DLLs>          ← sign
    ├── XojoGUIFramework64.dll   ← skip, Xojo provides signed DLLs
    ├── YourApp Libs/            ← skip, Xojo provides signed DLLs
    ├── msvcp140.dll, vcruntime*.dll …  ← skip (Microsoft runtime)
    └── YourApp.exe.WebView2/    ← skip (WebView2 cache)

The script

Save this as sign.ps1, next to the Xojo project, update the paths at the top, and run it from PowerShell:

$ErrorActionPreference = "Stop"

$Signtool    = "C:\...\signtool.exe"                            # path from Step 7
$Dlib        = "C:\...\Azure.CodeSigning.Dlib.dll"              # path from Step 7
$Metadata    = "C:\...\artifact-code-signing.json"              # from Step 8
$BuildFolder = "F:\...\YourApp"                                 # folder containing YourApp.exe

# Installer (Inno Setup) — optional. Set $EnableInno to $false to skip this part.
$EnableInno  = $true
$InnoSetup   = "C:\Program Files (x86)\Inno Setup 6\ISCC.exe"
$IssScript   = "F:\...\YourAppSetup.iss"                        # your Inno Setup script
$Installer   = "F:\...\YourAppSetup.exe"                        # output from the .iss

# Sign binaries you build or distribute under your publisher identity.
# Leave Xojo, Microsoft, and other vendor-signed dependencies alone.
$FilesToSign = @(
    "$BuildFolder\YourApp.exe"
    "$BuildFolder\MyPlugin.dll"
    # add any other files you own here, one per line
)

function Invoke-SigningCommand {
    param([string[]]$Arguments)

    & $Signtool @Arguments
    if ($LASTEXITCODE -ne 0) {
        throw "SignTool failed with exit code $LASTEXITCODE."
    }
}

foreach ($f in $FilesToSign) {
    Invoke-SigningCommand @(
        "sign", "/v", "/fd", "SHA256",
        "/tr", "http://timestamp.acs.microsoft.com", "/td", "SHA256",
        "/dlib", $Dlib, "/dmdf", $Metadata,
        $f
    )
}

if ($EnableInno) {
    # Build a fresh installer, then sign it.
    & $InnoSetup $IssScript
    if ($LASTEXITCODE -ne 0) {
        throw "Inno Setup failed with exit code $LASTEXITCODE."
    }

    Invoke-SigningCommand @(
        "sign", "/v", "/fd", "SHA256",
        "/tr", "http://timestamp.acs.microsoft.com", "/td", "SHA256",
        "/dlib", $Dlib, "/dmdf", $Metadata,
        $Installer
    )
}

What the flags mean:

• /tr http://timestamp.acs.microsoft.com: the timestamp server. The http:// (not https) is intentional.
• /fd SHA256 and /td SHA256: SHA-256 for the file and the timestamp.
• /dlib: the Azure plugin from Step 7. /dmdf: your metadata JSON from Step 8.

Confirm it worked

Two checks:

1. Signtool:$Signtool verify /v /pa "$BuildFolder\YourApp.exe" You want to see Successfully verified.
2. Or: right-click YourApp.exe → Properties → Digital Signatures → your org name should be listed.

Rules of thumb

• Sign after every build. Each new .exe is a fresh unsigned binary.
• Sign before you zip. Sign the files, then package them. Signing inside a zip does nothing.

Troubleshooting

Recap

One time (Steps 1–9): register the Microsoft.CodeSigning provider → create the account → assign the Identity Verifier role → complete identity validation (slow’ish) → create the certificate profile → assign the Signer role → install tools → write the metadata JSON → az login.

Every build (Step 10): run sign.ps1.

The bottom line

Azure Artifact Signing is a low-cost managed option for signing Windows apps, and Azure CLI authentication means local builds do not need a stored signing private key. The setup has some Azure bureaucracy, and identity validation is the slow part. After that, it is one script per build.

Related discussion

For an alternative approach that automates Xojo application signing and Inno Setup installer creation, see Jürg Otter’s Xojo Forum topic, Windows Code Signing & Installer Creation with Inno Setup. The topic includes Jürg’s open-source code, which supports both Azure Artifact Signing and traditional .pfx certificates.

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

Download Xojo

The class has been improved through several Xojo releases, offering more options and modernizing its look and feel to match recent iOS releases. In this post, let’s talk about using one of those small but useful improvements to MobileImagePicker with Xojo 2026r2, the SelectionLimit property.

On previous releases, when using the MobileImagePicker to select pictures from the device gallery (using MobileImagePicker.Sources.Photos), the user was allowed to choose as many pictures as they wanted to… but maybe that was not what your app logic expected!

Now you can use MobileImagePicker.SelectionLimit to set that expectation, so the user must comply with the limits your app needs.

If the logic of any of your existing apps allows the user to select as many pictures as they want, then there is nothing you need to do, the existing code will continue to work as expected. That is because the default value of the MobileImagePicker.SelectionLimit is 0. Or if you want to be more explicit, you can set the property to MobileImagePicker.UnlimitedSelection.

When setting the MobileImagePicker.SelectionLimit property to any other value, the iOS modal dialog will display that limit to the user so they know exactly what is expected.

Do you want to see it in action? Open the iOS > ImagePicker example project from the IDE. Once opened, select the Pressed event handler from the Button1 item in the project navigator to access the associated Code Editor. Then, modify the existing code like this:

ImagePicker.Source = MobileImagePicker.Sources.Photos
ImagePicker.SelectionLimit = 2
ImagePicker.Show()

We set the maximum limit of selected images to two. Run the app in the simulator, click on the Pick Pictures button, and the following modal will be shown, allowing you to choose a maximum of two images:

In summary

Alongside the big features highlighted in each Xojo release, there are a lot of other improvements and helpful additions. Take a look at the full list of updates in the Release Notes.

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

Download Xojo

Opening every window and updating each control individually works, but it gets tedious quickly, especially when testing different fonts or adding new UI elements. So I created a small module that applies a font to all supported controls in a DesktopWindow, including controls placed inside DesktopContainer instances.

Module AppWideFont
  Public Sub SetFont(Extends window As DesktopWindow, fontName As String)
    ApplyFontTo(window.Controls, fontName)
  End Sub

  Protected Function GetMonospaceFont() As String
    #If TargetWindows
      Return "Cascadia Mono"
    #ElseIf TargetMacOS
      Return "Menlo"
    #ElseIf TargetLinux
      Return "DejaVu Sans Mono"
    #Else
      Return "Courier New"
    #EndIf
  End Function

  Private Sub ApplyFontTo(controls As Iterable, fontName As String)
    For Each c As Object In controls
      If c IsA DesktopContainer Then
        ApplyFontTo(DesktopContainer(c).Controls, fontName)
      End If
      
      Select Case c
      Case IsA DesktopLabel
        DesktopLabel(c).FontName = fontName
      Case IsA DesktopTextField
        DesktopTextField(c).FontName = fontName
      Case IsA DesktopTextArea
        DesktopTextArea(c).FontName = fontName
      Case IsA DesktopListBox
        DesktopListBox(c).FontName = fontName
      Case IsA DesktopButton
        DesktopButton(c).FontName = fontName
      Case IsA DesktopCheckBox
        DesktopCheckBox(c).FontName = fontName
      Case IsA DesktopRadioButton
        DesktopRadioButton(c).FontName = fontName
      Case IsA DesktopPopupMenu
        DesktopPopupMenu(c).FontName = fontName
      End Select
    Next
  End Sub

End Module

The SetFont method is an extension method, so I can call it directly on any DesktopWindow.

For example, in a window’s Opening event:

Self.SetFont("Arial")

Or, if I want to use a monospace font:

Self.SetFont(AppWideFont.GetMonospaceFont)

The GetMonospaceFont function is just a simple additional helper that returns a suitable monospace font for Windows, macOS, or Linux.

The module uses the window’s Controls collection and recursively checks any DesktopContainer controls, so I only need one line of code per window. It currently handles labels, text fields, text areas, list boxes, buttons, checkboxes, radio buttons, and popup menus.

If I add another control type later, I can extend the Select Case statement with another branch.

This saved me from repeatedly changing font settings throughout the project and gave me one central place to control the application’s typography.

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

Download Xojo

Performance: Beyond 13,000 Requests Per Second

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

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

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

SEO Improvements Done Right

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

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

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

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

DatabaseConnection Gets a PerSession Mode

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

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

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

WebGraphics Gets DrawPath and FillPath

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

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

WebImageViewer: Goodbye, Flicker

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

Wrapping Up

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

Happy coding!

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

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

Download Xojo

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

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

Debugging with Entitlements in Action

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

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

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

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

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

Creating a Synced Password

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

Var newItem As KeychainItem

If System.KeychainCount > 0 Then

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

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

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

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

All in all, this means two things:

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

In Summary

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

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

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

Download Xojo

Copying

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

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

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

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

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

  Public Property Label As String

  Public Property Shape As Integer

  Public Property Value As Integer

  Public Property X As Integer

  Public Property Y As Integer

End Class

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

Pasting

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

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

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

Public Property State As String // State code

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

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


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

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

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

End Class

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

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

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

End Class

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

End Class

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

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

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

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

Download Xojo

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

Why WebView2 Matters

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

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

WebView2 changes that equation considerably.

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

WebView2 Runtime Requirements

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

Windows 11

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

Windows 10

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

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

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

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

WinUI Targets Use WebView2 by Default

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

Enabling WebView2 in older projects or non-WinUI Windows targets

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

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

This gives you the flexibility to choose between:

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

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

Differences from CEF

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

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

Final Thoughts

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

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

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

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

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

Download Xojo

Behind the Scenes…

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

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

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

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

MobilePopupMenu Arrives to iOS

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

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

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

MobileMenuItem

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

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

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

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

MobileButton

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

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

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

MobileToolbarButton

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

Badges

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

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

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

In Summary

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

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

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

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

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

Download Xojo

These changes focus on two main areas:

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

Smarter Icon Handling with Symbols

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

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

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

Example

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

How it works

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

The lookup order is:

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

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

Where to find the list of supported symbols

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

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

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

Better Control Over Toolbar Layout

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

DesktopToolbarStyles options:

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

In Conclusion

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

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

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

Download Xojo

Settings

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

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

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

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

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

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

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

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

Services

Anthropic Claude

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

Access to project context is supported with Anthropic Claude.

OpenAI GPT

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

Access to project context is supported with OpenAI.

OpenRouter

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

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

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

Local LLM

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

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

http://127.0.0.1:1234

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

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

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

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

Which Should You Use?

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

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

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

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

I hope you find these Jade improvements useful to you!

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

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

Download Xojo

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

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

Step 1: Designing the UI

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

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

Step 2: Creating the Thread Subclass

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

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

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

Defining Custom Events

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

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

Step 3: The iterative approach

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

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

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

Step 4: Sending Updates to the UI safely

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

Add the UserInterfaceUpdate event to your FileSearch class:

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

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

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

Step 5: Wiring the UI

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

Implement the Event Handlers to your new seeker control:

seeker.Complete:

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

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

seeker.MatchFound:

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

seeker.StatusUpdate:

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

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

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

        listResults.RemoveAllRows

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

        Me.Caption = "Cancel"

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

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

Summary

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

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

Special Thanks

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

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

Happy coding!

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

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

Download Xojo

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

Mac, Windows or Linux?

Mac + Windows of course. Evaluating Linux demand.

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

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

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

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

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

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

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

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

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

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

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

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

What do you build with it now?

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

Do you earn a living with Xojo?

Yes.

What’s your biggest Xojo success?

OfficeTime

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

Easy cross platform

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

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

Download Xojo