Popovers anchor to a control, not a location, which has been somewhat tricky to do in the past. DesktopTable has a CellBoundsAt method which returns a Rect containing the selected cell’s geometry and position relative to the table control’s location on its parent. This allows us to anchor the popover container to an individual cell.

This is useful when you need to show the full contents of a cell whose displayed area can’t fit the underlying data.

In this example, the popover container is intentionally simple – it is a TextArea sized to fill the container.  The container is named PopOverContainer. The Window includes a property named AnchorControl As DesktopRectangle that we’ll use as the popover’s anchor.

In the Window Opening event, we initialize the anchor rectangle:

Sub Opening() Handles Opening
  AnchorControl = New DesktopRectangle
  Window1.AddControl(AnchorControl)
  AnchorControl.BorderThickness = 0.0
  AnchorControl.FillColor = &c000000FF ' Transparent on MacOS, Window background color on Windows

End Sub

This initializes the rectangle that we will anchor the popover to.

Lastly the CellPressed Event Hanlder:

Function CellPressed(row As Integer, column As Integer, x As Integer, y As Integer) Handles CellPressed as Boolean
  #Pragma Unused x
  #Pragma Unused y
  If column <> 1 Then ' We only want the popover to show on Column 1
    Return False
  End If
  
  // Move the Anchor control to the selected cell position.
  AnchorControl.Left = me.CellBoundsAt(row, column).Left + me.Left
  AnchorControl.Top = me.CellBoundsAt(row, column).Top + me.Top + me.CellBoundsAt(row, column).Height ' I want the popover to anchor to the bottom of the control
  AnchorControl.Width = me.CellBoundsAt(row, column).Width
  AnchorControl.Height = If(TargetWindows, 0, 1) ' Windows can handle 0 height, MacOS doesn't  

  // Now that we have an anchor point at the correct location we can popover

  Var poc As New PopOverContainer

  poc.TextArea1.Text = me.CellTextAt(row, column)

  poc.ShowPopover(AnchorControl, DesktopContainer.DisplaySides.Bottom)
  Return True
End Function

Cross-platform Adjustments

Some adjustments will need to be made for the different ways targets handle transparency.  Windows doesn’t visually render transparent controls in the same way macOS does, and macOS may require the anchor control to occupy a space.  By setting the anchor height appropriately, we can ensure the popover is positioned correctly on both platforms.

Download the project.

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

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

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

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

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

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

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

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

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

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

Can I develop iOS apps on Windows?

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

Do I need to install anything besides Xojo?

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

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

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

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

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

There could be a few reasons for this.

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

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

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

Do I need to keep Xcode open while using Xojo?

No. That is not necessary at all!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Helpful Resources

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

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

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

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

Download Xojo

Part 1: Building JSON

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

The Basic Payload

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

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

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

Making Arrays

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

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

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

Nesting Things

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

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

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

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

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

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

Part 2: Parsing JSON

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

Reading a Flat Response

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

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

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

Handling Optional Keys with Lookup

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

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

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

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

Looping Over an Array

If an API hands you a list of database records:

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

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

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

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

Digging out Nested Nodes

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

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

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

Part 3: Identifying the Structure

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

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

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

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

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

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

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

Download Xojo

The Goal

We want to:

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

Step 1: Move File Reading to its own Method

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

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

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

Step 2: Recursive Folder Traversal

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

To keep this safe, we Use maxDepth:

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

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

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

Step 3: Support Both Versions with Method Overloading

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

The default version (depth 0):

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

The recursive version:

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

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

Summary

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

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

The Complete Recursive Code

The SearchUtils Module

Module SearchUtils

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

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

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

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

    Var hits() As SearchHit

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

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

    Return hits
  End Function

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

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

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

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

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

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

Happy coding!

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

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

Download Xojo

Am I affected? What do I do?

If you only read one section, read this one.

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

The full details follow.

Timeline

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

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

What Happened

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

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

A few things worth being upfront about:

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

The Fix

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

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

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

What Xojo has already done for you

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

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

What you should do

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

If you’re on Web 2

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

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

If you’re on Web 1

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

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

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

Hosting-level mitigations

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

Apache:

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

Nginx:

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

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

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

If your Xojo app is exposed directly to the internet

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

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

If you use DecodeURLComponent in a non-Web project

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

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

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

Acknowledgments

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

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

References

• Release notes for 2026r1.2

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

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

Download Xojo

Specifically, the following properties can be used there:

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

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

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

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

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

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

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

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

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

Happy coding!

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

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

Download Xojo

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

Mac, Windows or Linux?

Mac.

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

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

Do you earn a living with Xojo?

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

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

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

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

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

What do you build with it now?

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

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

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

Do you use it for any hobbies?

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

What’s your biggest Xojo success?

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

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

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

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

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

Download Xojo