Tips – Xojo Programming Blog

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

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

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

What Is Conditional Compilation?

Conditional compilation allows you to include or completely exclude sections of code from the final application based on a condition. Unlike an If statement at runtime, this decision is made at compile time. Code excluded through conditional compilation simply does not exist in the compiled application.

#If False – Completely Excluding Code

#If False
  MessageBox("This line will never be compiled")
  Var result As Integer = DoSomething()
#EndIf

When the condition is False, the entire block is ignored by the compiler. It is not compiled, not included in the application, and not even checked for syntax errors. The code is effectively invisible to the compiler.

Why Not Just Comment It Out?

At first glance, #If False seems to do the same thing as a comment. But there are key differences:

1. Nested Comments Are No Problem

If a code block already contains comments, commenting out the entire block quickly becomes messy:

' Var x As Integer = 42 ' Default value
' Var y As Integer = x * 2 ' double it
' ' This is already a comment

With #If False, everything stays clean:

#If False
  Var x As Integer = 42 ' Default value
  Var y As Integer = x * 2 ' double it
  ' This is already a comment
#EndIf

2. Incomplete or Broken Code

Sometimes you want to keep an unfinished code draft without it preventing the build. Since the compiler completely skips the contents of an #If False block, the code inside may even contain syntax errors:

#If False
  ' Experimental approach – not finished yet
  Var data As  = LoadFromServer(
  ProcessResult(data
#EndIf

This code would be useless as a comment because you’d have to comment out each line individually. With #If False, it’s safely stored away.

3. Quickly Disabling Large Code Blocks

For larger sections, #If False / #EndIf is far more practical than prefixing every line with '. Plus, the block can be reactivated instantly by simply changing False to True.

#If True – Always Including Code

#If True
  MessageBox("This line will always be compiled")
#EndIf

An #If True block is always compiled — it behaves identically to regular code. This might sound useless at first, but it does have practical applications.

When Is `#If True` Useful?

1. Quick Toggling During Development

Imagine you’re working on a feature and want to quickly enable or disable certain code sections:

#If True ' <- Set to False to disable the new feature
  ' New feature
  Var service As New CloudSyncService
  service.SyncNow()
#EndIf

By simply changing True to False, you can disable the feature without deleting or commenting out any code.

2. Placeholder for Future Conditions

Sometimes you already know that a code section will later be tied to a condition — such as a platform or build type. With #If True, you can prepare the structure in advance:

#If True ' TODO: Change to TargetMacOS once Windows alternative is ready
  Var folderPath As String = SpecialFolder.Applications.NativePath
#EndIf

3. Visual Code Grouping

In longer methods, #If True can serve as a visual structural block to highlight related code:

#If True ' --- Initialization ---
  Var db As New SQLiteDatabase
  db.DatabaseFile = dbFile
  db.Connect
#EndIf

#If True ' --- Load data ---
  Var rs As RowSet = db.SelectSQL("SELECT * FROM users")
#EndIf

Defining Custom Compiler Constants

Xojo also allows you to define your own constants for conditional compilation.

#If kEnableLogging
  WriteToLog("Application started")
#EndIf

This lets you control features or debug functionality centrally through a constant without having to modify the code itself.

Best Practices

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

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

Don’t use permanently: #If False blocks should not remain in the code indefinitely. If the code is no longer needed, remove it. If it is needed, activate it.
Prefer platform directives: When dealing with platform-specific code, use the specific constants (TargetMacOS, TargetWindows, etc.) instead of #If True or #If False.
Avoid deep nesting: While nested #If blocks are possible, use them sparingly as they quickly reduce readability.

Conclusion

#If False and #If True are simple yet powerful tools for everyday Xojo development. They offer a cleaner alternative to commenting out large code blocks, enable quick feature toggling during development, and lay the groundwork for a structured, cross-platform codebase. Used thoughtfully, they save time and help you stay organized — even in larger projects.

If you want to automatically convert a selection into a #If/#EndIf block, you can do so via the context menu: “Wrap In > #If / #EndIf”

Happy coding.

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

Custom Control Rendering with DrawControlInLayoutEditor

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

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

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

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

Why this matters

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

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

How it works

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

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

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

A note about XojoScript limitations

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

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

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

Support for more Graphics

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

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

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

Class LinearGradientBrush

  Sub Constructor()

  Sub AddStop(stop As Double, c As Color)

  Property StartPoint As Point
  Property EndPoint As Point

End Class

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

Turning off this feature

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

Finally

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

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

Watchpoints in Xojo: A Smarter Way to Track Your Data

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

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

What Are Watchpoints?

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

This is especially useful when:

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

How Watchpoints Work

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

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

This gives you immediate visibility into:

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

Why This Matters

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

Watchpoints eliminate that friction by:

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

Conditional Watchpoints

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

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

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

Handling Object Lifetimes

One important detail when working with watchpoints is object lifetime.

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

What works and what doesn’t

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

Final Thoughts

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

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

Xojo + XAML + Goto = 🔥

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

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

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

At a high level, the workflow looks like this:

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

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

Visual States in XAML

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

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

Example XAML

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


  
    
      

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

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

      
    

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

In this XAML:

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

Triggering the Transition from Xojo

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

XAMLContainer1.GotoState("Top")

And to move it back down:

XAMLContainer1.GotoState("Bottom")

Why This Is Powerful

What makes this feature especially useful is that:

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

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

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

XAMLContainer1.GotoState("On")

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

Detecting UI Compatibility Mode in macOS Apps with Xojo

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

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

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

IsCompatibilityModeEnabled As Boolean

Then add the following code to the method:

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

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

Testing the Method

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

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

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

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

In Summary

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

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.

Tip: Customize Toolbars on macOS apps

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

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

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

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

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

It’s that simple!

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

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

macOS and iOS: UI Compatibility Mode

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

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

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

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

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

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

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

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

The Last Word

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

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

Introducing Jade, the Xojo AI Assistant

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

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

Getting Started

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

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

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

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

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

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

Using Jade

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

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

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

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

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

Other Tips

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

Wrap

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

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

Welcome to the Grid

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

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

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

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

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

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

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

Is the DesktopGrid a replacement for DesktopListBox?

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

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

Performance Caveats to Consider

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

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

Wiring the Grid

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

Xojo 2025r2.1: Publishing macOS Apps Under Tahoe

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

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

There are two possible solutions:

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

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

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

RegEx Examples: 10 Practical Patterns You Can Copy and Paste

Gabriel Ludosanu — Thu, 18 Sep 2025 11:00:00 +0000

Looking for RegEx examples you can drop straight into your project? This practical cheat sheet focuses on the most searched tasks, such as find/replace, extracting values, lookahead/lookbehind, and non-greedy matches, using Xojo’s RegEx class with concise, ready-to-run snippets. Copy, paste, ship.

Setup (3 lines you’ll reuse)

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

1) Replace all occurrences (word boundary)

Goal: a → the (whole word)

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

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

2) Strip HTML tags

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

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

3) Extract the first number (capture groups)

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

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

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

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

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

5) Find all words (simple iterator)

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

6) Replace only the second occurrence

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

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

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

7) Lookarounds

Match “foo” not followed by “bar”

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

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

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

7.2 Positive lookbehind + optional decimals: amounts right after $

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

Tip:

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

8) Smallest span between tags (non‑greedy)

re.SearchPattern = ".+?" ' or: opt.Greedy = False

9) Extract emails (simple demo)

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

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

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

Quick replacement references

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

Options you’ll use most

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

Common gotchas

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

Wrap‑up

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

Happy matching!

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

DesktopTextArea Without Soft Wrapping Lines on macOS

Javier Menendez — Tue, 09 Sep 2025 19:31:26 +0000

When adding a DesktopTextArea to your macOS app, just drag it from the Library into a Window (or Container) in the layout editor of the Xojo IDE. It works out of the box with native macOS behavior. But what if you want to change that native behavior, like, for example, disabling soft wrapping? Keep reading to learn how.

On macOS, DesktopTextArea uses the native macOS control. When you need to tweak its behavior, Declares can help. For example, by default text lines are soft-wrapped to the control’s width. But sometimes you may want to turn that off so each line displays in full, making the text easier to read line by line.

If you need to do just that, without resorting to other options because the use of a DesktopTextArea is what you really need to use, then put the following snippet of code into the Opening event handler for the DesktopTextArea instance:

If that’s exactly what you need to do and you want to stick with DesktopTextArea, just add the following code to the Opening event of your DesktopTextArea:

#If TargetMacOS Then
  // At this point we are getting really the handle to
  // the wrapping object: NSScrollView
  Var tAObj As Ptr = Me.Handle
  
  Declare Function Subviews Lib "AppKit" Selector "subviews" (obj As Ptr) As Ptr
  Declare Function ObjectAtIndex Lib "AppKit" Selector "objectAtIndex:" (obj As Ptr, index As Integer) As Ptr
  
  // We need to get the real NSTextView view that is set
  // inside the clip view set inside the NSScrollView
  Var subViewsFromScroll As Ptr = Subviews(tAObj)
  Var clipView As Ptr = ObjectAtIndex(subViewsFromScroll, 1)
  Var subViewsFromClipView As Ptr = Subviews(clipView)
  
  //…and here it is
  Var textAreaView As Ptr = ObjectAtIndex(subViewsFromClipView, 2)
  
  // At this point we have the real NSTextView from the wrapping NSScrollerView!
  
  Declare Function TextContainer Lib "AppKit" Selector "textContainer" (obj As Ptr) As Ptr
  Declare Sub SetWidthTracksTextView Lib "AppKit" Selector "setWidthTracksTextView:" (obj As Ptr, value As Boolean)
  Declare Sub SetContainerSize Lib "AppKit" Selector "setContainerSize:" (obj As Ptr, size As CGSize)
  Declare Sub SetMaxSize Lib "AppKit" Selector "setMaxSize:" (obj As Ptr, size As CGSize)
  
  // Retrieving the NSTextContainer
  Var tcObj As Ptr = TextContainer(textAreaView)
  SetWidthTracksTextView(tcObj, False)
  
  Var newSize As CGSize
  newSize.Width = 100000 // Arbitrary value… we only need to set it to a really high value!
  newSize.Height = 100000
  
  // And setting a new max width size to it.
  SetMaxSize(tAObj, newSize)
  
  // …and also using the same value for the size of the NSTextContainer
  SetContainerSize(tcObj, newSize)
#Endif

The code above uses the CGSize data type, a Struct added to the Window (though you’ll likely want to place it in a Module instead). It has two members:

Width As Integer
Height As Integer

We need to use this Data Type / Struct because some macOS framework methods from NSScrollView and NSTextContainer expect it.

After adding the code, enable the ‘Has Horizontal Scrollbar’ property in the Inspector for your DesktopTextArea. Run the app and you’ll see that soft wrapping is no longer applied!

What other customized behaviors have you added to macOS DesktopTextArea instances via Declares? Go ahead and share the code so other users can benefit from them.

Happy coding!

4 Setting the Badge Color for Tabs on iOS

Javier Menendez — Wed, 20 Aug 2025 14:00:00 +0000

This is the final article in our series on customizing the appearance of the NavigationBar and TabBar. In this post, we’ll go a step further and show how to change the default color of the tab badge which is red by default.

As you might expect, we’ll need a few more Declares to accomplish this. Continue reading to learn how!

Since we’re building on the example project from the first blog post in this series, I strongly recommend completing that post if you haven’t already, then continuing with the second and third articles before proceeding here.

Select the “DeclaresForiOS” module and add a new method to it, using the following values for its signature in the Inspector Panel:

Method Name: TabBarBadgeColor
Parameters: Extends tab As iOSTabBar, Assigns value As ColorGroup
Scope: Global

And put the following snippet of code in the associated Code Editor:

Var tabController As Ptr = tab.ViewControllerHandle

If value = Nil Then Return

Declare Function GetTabBar Lib "UIKit" Selector "tabBar" (obj As Ptr) As Ptr
Var tabBar As Ptr = GetTabBar(tabController)

Var colorPtr As Ptr = ColorGroupToUIColor(value)

Declare Function BarAppearance Lib "UIKit" Selector "standardAppearance" (obj As Ptr) As Ptr
Declare Sub SetAppearance Lib "UIKit" Selector "setStandardAppearance:" (obj As Ptr, value As Ptr)

Var appearance As Ptr = BarAppearance(tabBar)

Declare Function StackedLayout Lib "UIKit" Selector "stackedLayoutAppearance" (obj As Ptr) As Ptr
Declare Function InlineLayout Lib "UIKit" Selector "compactInlineLayoutAppearance" (obj As Ptr) As Ptr
Declare Function NormalState Lib "UIKit" Selector "normal" (obj As Ptr) As Ptr

Var stackLayout As Ptr = StackedLayout(appearance)
Var inLayout As Ptr = InlineLayout(appearance)
Var normalState As Ptr = NormalState(stackLayout)
Var normalInlineState As Ptr = NormalState(inLayout)

Declare Sub SetBadgeColor Lib "UIKit" Selector "setBadgeBackgroundColor:" (obj As Ptr, value As Ptr)

SetBadgeColor(normalState, colorPtr)
SetBadgeColor(normalInlineState, colorPtr)

SetAppearance(tabBar, appearance)

If System.Version.MajorVersion >= 15 Then
  Declare Sub SetScrollEdgeAppearance Lib "UIKit" Selector "setScrollEdgeAppearance:" (obj As Ptr, value As Ptr)
  SetScrollEdgeAppearance(tabBar, appearance)
End If

Next, select the Screen1 item in the Navigator and add a new property to it using the following values in the Inspector Panel:

Name: MyTabBadgeColor
Type: ColorGroup
Scope: Protected

Setting the Badge Text Color

What’s next? I’m sure you guessed it! Now that we can customize the badge color, the default white text color on the badge may not always provide the best contrast.

Let’s add a new method to our “DeclaresForiOS” module with the following signature values in the Inspector Panel:

Name: TabBarBadgeTextColor
Parameters: Extends tab As iOSTabBar, Assigns value As ColorGroup
Scope: Global

And type (or paste) the following snippet of code in the associated Code Editor:

Var tabController As Ptr = tab.ViewControllerHandle

If value = Nil Then Return

Declare Function GetTabBar Lib "UIKit" Selector "tabBar" (obj As Ptr) As Ptr
Var tabBar As Ptr = GetTabBar(tabController)

Var colorPtr As Ptr = ColorGroupToUIColor(value)

Declare Function BarAppearance Lib "UIKit" Selector "standardAppearance" (obj As Ptr) As Ptr
Declare Sub SetAppearance Lib "UIKit" Selector "setStandardAppearance:" (obj As Ptr, value As Ptr)

Var appearance As Ptr = BarAppearance(tabBar)

Declare Function StackedLayout Lib "UIKit" Selector "stackedLayoutAppearance" (obj As Ptr) As Ptr
Declare Function InlineLayout Lib "UIKit" Selector "compactInlineLayoutAppearance" (obj As Ptr) As Ptr
Declare Function NormalState Lib "UIKit" Selector "normal" (obj As Ptr) As Ptr

Var stackLayout As Ptr = StackedLayout(appearance)
Var inLayout As Ptr = InlineLayout(appearance)

Var normalState As Ptr = NormalState(stackLayout)
Var normalInlineState As Ptr = NormalState(inLayout)

Declare Sub SetBadgeTextAttr Lib "UIKit" Selector "setBadgeTextAttributes:" (obj As Ptr, value As Ptr)

Declare Function NSClassFromString Lib "Foundation" (name As CFStringRef) As Ptr
Declare Function DictionaryWithObjectForKey Lib "UIKit" Selector "dictionaryWithObject:forKey:" (obj As Ptr, value As Ptr, key As CFStringRef) As Ptr

Var dict As Ptr = DictionaryWithObjectForKey( NSClassFromString("NSMutableDictionary") , colorPtr, "NSColor")

SetBadgeTextAttr(normalState, dict)
SetBadgeTextAttr(normalInlineState, dict)

SetAppearance(tabBar, appearance)

If System.Version.MajorVersion >= 15 Then
  Declare Sub SetScrollEdgeAppearance Lib "UIKit" Selector "setScrollEdgeAppearance:" (obj As Ptr, value As Ptr)
  SetScrollEdgeAppearance(tabBar, appearance)
End If

Next, select the Screen1 item in the Navigator and add a new property to it using the following values in the Inspector Panel:

Name: MyTabBadgeTextColor
Type: ColorGroup
Scope: Protected

Then, select the Screen1.Opening event handler and add these lines of code to it:

MyTabBadgeColor = New ColorGroup(Color.Green, Color.Blue)
MyTabBadgeTextColor = New ColorGroup(Color.Black, Color.Yellow)

Me.ParentTabBar.BadgeAt(0) = "33"
Me.ParentTabBar.BadgeAt(1) = "42"

Lastly, select the Screen1.AppearanceChanged event handler and add this line of code at the end:

Me.ParentTabBar.TabBarBadgeColor = MyTabBadgeColor
Me.ParentTabBar.TabBarBadgeTextColor = MyTabBadgeTextColor

Testing the App

Everything is set! Run the app on your iPhone or in the Simulator, and you’ll see each tab in the TabBar displaying its own badge with the custom background and text colors we configured in the Opening Event.

Download the example project from this link.

Happy Xojo Coding!

3 Coloring the Tab Bar on iOS

Javier Menendez — Tue, 19 Aug 2025 15:37:37 +0000

In the first two blog posts, we saw how important it is to customize the NavigationBar when theming your iOS app. However, that’s only part of the equation, especially if your app also uses a TabBar. In that case, you’ll likely want to customize not only the background color of the TabBar, but also the text color of the selected tab and the color used for the unselected tabs.

Continue reading to learn how to do all of this thanks to the powerful flexibility of Declares!

Before we dive in, keep in mind that we’re building on the example project introduced in the first blog post of this series. If you haven’t read it yet, I encourage you to start there. Then, follow up with the second post to make sure you’re fully up to speed and ready to continue adding even more color customization to your iOS screens!

Background Color for the TabBar

In order to colorize the TabBar background, we need to add a new method to the “DeclaresForiOS” Module using the following values:

Method Name: TabBarBackgroundColor
Parameters: Extends tab As iOSTabBar, Assigns value As ColorGroup
Scope: Global

Add the following snippet of code in the associated Code Editor:

Var tabController As Ptr = tab.ViewControllerHandle

If value = Nil Then Return

Declare Function GetTabBar Lib "UIKit" Selector "tabBar" (obj As Ptr) As Ptr
Var tabBar As Ptr = GetTabBar(tabController)

Var colorPtr As Ptr = ColorGroupToUIColor(value)

Declare Function BarAppearance Lib "UIKit" Selector "standardAppearance" (obj As Ptr) As Ptr
Declare Sub ConfigureWithOpaqueBackground Lib "UIKit" Selector "configureWithOpaqueBackground" (obj As Ptr)
Declare Sub SetBackgroundColor Lib "UIKit" Selector "setBackgroundColor:" (obj As Ptr, value As Ptr)
Declare Sub SetAppearance Lib "UIKit" Selector "setStandardAppearance:" (obj As Ptr, value As Ptr)

Var appearance As Ptr = BarAppearance(tabBar)
SetBackgroundColor(appearance, colorPtr)

SetAppearance(tabBar, appearance)

If System.Version.MajorVersion >= 15 Then
  Declare Sub SetScrollEdgeAppearance Lib "UIKit" Selector "setScrollEdgeAppearance:" (obj As Ptr, value As Ptr)
  SetScrollEdgeAppearance(tabBar, appearance)
End If

Essentially, we’re setting the color by assigning it to the backgroundColor property of the appearance object associated with the TabBar.

Setting the Text Color

Now let’s add the code responsible for setting the text color of the selected tab in the TabBar. To do this, we just need to set the tintColor property. So, go ahead and add a new method to the “DeclaresForiOS” module with the following values:

Method Name: TabBarTextColor
Parameters: Extends tab As iOSTabBar, Assigns value As ColorGroup
Scope: Global

And put the following snippet of code in the associated Code Editor:

Var tabController As Ptr = tab.ViewControllerHandle

If value = Nil Then Return

Declare Function GetTabBar Lib "UIKit" Selector "tabBar" (obj As Ptr) As Ptr
Var tabBar As Ptr = GetTabBar(tabController)

Var colorPtr As Ptr = ColorGroupToUIColor(value)

Declare Sub SetTintColor Lib "UIKit" Selector "setTintColor:" (obj As Ptr, value As Ptr)

SetTintColor(tabBar, colorPtr)

Setting Unselected Tabs Text Color

To set the text color for unselected tabs, we’ll need to use a few additional Declares. This is because the color must be applied to the normal state of the stackedLayoutAppearance object from the TabBar’s appearance. Additionally, we need to set the same value for the compactInlineLayoutAppearance, which is used when the device is in landscape orientation.

Add a new method to the “DeclaresForiOS” Module using the following values for its signature:

Method Name: TabBarUnselectedTextColor
Parameters: Extends tab As iOSTabBar, Assigns value As ColorGroup
Scope: Global

And add the following snippet of code in the associated Code Editor:

Var tabController As Ptr = tab.ViewControllerHandle

If value = Nil Then Return

Declare Function GetTabBar Lib "UIKit" Selector "tabBar" (obj As Ptr) As Ptr
Var tabBar As Ptr = GetTabBar(tabController)

Var colorPtr As Ptr = ColorGroupToUIColor(value)

Declare Function BarAppearance Lib "UIKit" Selector "standardAppearance" (obj As Ptr) As Ptr
Declare Sub SetAppearance Lib "UIKit" Selector "setStandardAppearance:" (obj As Ptr, value As Ptr)

Declare Function StackedLayout Lib "UIKit" Selector "stackedLayoutAppearance" (obj As Ptr) As Ptr
Declare Function InlineLayout Lib "UIKit" Selector "compactInlineLayoutAppearance" (obj As Ptr) As Ptr
Declare Function NormalState Lib "UIKit" Selector "normal" (obj As Ptr) As Ptr

Var appearance As Ptr = BarAppearance(tabBar)
Var stackLayout As Ptr = StackedLayout(appearance)
Var inLayout As Ptr = InlineLayout(appearance)

Var normalState As Ptr = normalState(stackLayout)
Var normalInlineState As Ptr = NormalState(inLayout)

Declare Function NSClassFromString Lib "Foundation" (name As CFStringRef) As Ptr
Declare Function DictionaryWithObjectForKey Lib "UIKit" Selector "dictionaryWithObject:forKey:" (obj As Ptr, value As Ptr, key As CFStringRef) As Ptr

Var dict As Ptr = DictionaryWithObjectForKey( NSClassFromString("NSMutableDictionary") , colorPtr, "NSColor")

Declare Sub SetTextAttributes Lib "UIKit" Selector "setTitleTextAttributes:" (obj As Ptr, value As Ptr)

SetTextAttributes(normalState, dict)
SetTextAttributes(normalInlineState, dict)
SetAppearance(tabBar, appearance)

If System.Version.MajorVersion >= 15 Then
  Declare Sub SetScrollEdgeAppearance Lib "UIKit" Selector "setScrollEdgeAppearance:" (obj As Ptr, value As Ptr)
  SetScrollEdgeAppearance(tabBar, appearance)
End If

Testing the TabBar Color

Add a new screen to the project so that our example app includes at least two screens. You can do this by selecting Insert > Screen from the IDE toolbar.

To test the new methods, we need the app to use a TabBar. To enable that, select the iPhoneLayout item in the Navigator. Then, in the Inspector Panel, locate the Content label and choose Tabs from the associated popup menu. Finally, set Screen1 as the content for Tab 0 using the “Tab 0 Content” popup menu.

Next, with Screen1 still selected in the Navigator, click on the “Tab 1” label in the Layout Editor. Then, in the Inspector Panel, use the popup menu next to the “Tab 1 Content” label to select Screen2.

With Screen1 still selected in the Navigator, add a new property to it using the following values:

Name: MyTabBarUnselectedTextColor
Type: ColorGroup
Scope: Protected

Now select the Screen1.Opening event handler and add this line of code:

MyTabBarUnselectedTextColor = New ColorGroup(Color.White, Color.LightGray)

As the last step, select the Screen1.AppearanceChanged event handler and add this line of code:

Me.ParentTabBar.TabBarBackgroundColor = mNavigationBarColor
Me.ParentTabBar.TabBarTextColor = MyNavigationBarTextColor
Me.ParentTabBar.TabBarUnselectedTextColor = MyTabBarUnselectedTextColor

All set! Now it’s time to run the example project in the Simulator or on your iPhone. You’ll see that the TabBar background color matches the one set for the NavigationBar, and the selected tab text color is consistent as well. The unselected tab text appears white in Light Mode and light gray in Dark Mode, reflecting the ColorGroup settings.

As we’ve seen, Declares are a powerful way to tap into native iOS framework functions and routines. The most challenging part is often figuring out which ones to use since that requires digging into Apple’s developer documentation.

Download the example project from this link.

Happy Xojo coding!

2 Coloring the Navigation Bar Text on iOS

Javier Menendez — Mon, 18 Aug 2025 21:53:11 +0000

In a previous blog post, we covered how to set the color of the NavigationBar on a MobileScreen in iOS projects. However, if you’re customizing the Navigation Bar’s background, you’ll likely want control over the title text color and the color of any buttons added to it as well.

Continue reading to learn how to customize those elements too.

Just like in the previous blog post, we’ll need to use several Declares to access the necessary iOS framework functions and retrieve the underlying objects we want to modify.

If you haven’t followed the previous post yet, be sure to check it out first—we’ll be building on the same example project to add these new customizations.

Let’s add a new method to our previously created “DeclaresForiOS” Module using the following values:

Method Name: NavigationBarTextColor
Parameters: Extends screen As MobileScreen, Assigns value As ColorGroup
Scope: Global

And add the following snippet of code in the associated Code Editor:

If value = Nil Then Return

Var controller As Ptr = screen.ViewControllerHandle

Declare Function NavigationController Lib "UIKit" Selector "navigationController" (controller As Ptr) As Ptr
Declare Function NavigationBar Lib "UIKit" Selector "navigationBar" (controller As Ptr) As Ptr

Var nc As Ptr = NavigationController(controller)
Var nv As Ptr = NavigationBar(nc)

Var colPtr As Ptr
colPtr = ColorGroupToUIColor(value)

Declare Function DictionaryWithObjectForKey Lib "UIKit" Selector "dictionaryWithObject:forKey:" (obj As Ptr, value As Ptr, key As CFStringRef) As Ptr

// https://developer.apple.com/documentation/foundation/nsclassfromstring(_:)?language=objc
Declare Function NSClassFromString Lib "Foundation" (name As CFStringRef) As Ptr

Declare Function StandardAppearance Lib "UIKit" Selector "standardAppearance" (obj As Ptr) As Ptr
Declare Sub SetStandardAppearance Lib "UIKit" Selector "setStandardAppearance:" (obj As Ptr, value As Ptr)
Declare Sub SetScrollEdgeAppearance Lib "UIKit" Selector "setScrollEdgeAppearance:" (obj As Ptr, value As Ptr)

Declare Sub SetTitleTextAttributedText Lib "UIKit" Selector "setTitleTextAttributes:" (obj As Ptr, value As Ptr)
Declare Sub SetLargeTitleTextAttributedText Lib "UIKit" Selector "setLargeTitleTextAttributes:" (obj As Ptr, value As Ptr)

Declare Sub SetTintColor Lib "UIKit" Selector "setTintColor:" (obj As Ptr, value As Ptr)

// We need to create a NSDictionary with the attribute we want to set on text for the NavigationBar Appearance
Var dict As Ptr = DictionaryWithObjectForKey(NSClassFromString("NSMutableDictionary"), colPtr, "NSColor")

Var appear As Ptr = StandardAppearance(nv)

// Setting the new appearance settings both for the regular-sized title
// and the Large one
SetTitleTextAttributedText(appear, dict)
SetLargeTitleTextAttributedText(appear, dict)

// And we apply the modified appearance to the StandardAppearance
SetStandardAppearance(nv, appear)

// And to the scrollEdgeAppearance if the app is run on iOS 15+
If (System.Version.MajorVersion >= 15.0) Then
   SetScrollEdgeAppearance(nv, appear)
End If

// The TintColor is applied on the text of the added buttons to the NavigationBar
// So we need to use the same color for them!
SetTintColor(nv, colPtr)

And that’s all the code we need.

Colorizing!

Select the Screen1 item in the Navigator and add a new property to it using the following values:

Name: MyNavigationBarTextColor
Type: ColorGroup
Scope: Protected

Now select the Screen1.Opening event and add the following line of code:

MyNavigationBarTextColor = New ColorGroup(Color.Yellow, Color.Red)

Finally, select the Screen1.AppearanceChanged event handler and add the following line:

Me.NavigationBarTextColor = MyNavigationBarTextColor

Run the example project, and you’ll see that the title text remains correctly displayed, even when switching between Light and Dark modes.

Download the example project from this link.

1 Coloring Your iOS App Navigation Bar

Javier Menendez — Mon, 11 Aug 2025 18:08:31 +0000

This is the first of a series of 4 posts about customizing the Navigation and Tab Bars. One of the best ways to give your iOS app a custom look is by theming the Navigation Bar. While it’s possible to do this using a ContainerControl or a Rectangle with carefully applied constraints, there’s a better and more direct approach—using Declares.

Keep reading to learn how to style your Navigation Bar.

Declares in Xojo allow you to access functions and constants from compiled libraries and system frameworks such as those provided by iOS or third-party developers. They’re a powerful way to extend your app’s capabilities beyond what is available in the Xojo framework.

In this case, we’ll use Declares to tap into the native iOS APIs and customize the appearance of a MobileScreen‘s NavigationBar, specifically to set its background color.

Start by adding a new module to your existing or empty iOS project. I’ve named this DeclaresForiOS. Within this module, add a new method using the following values:

Method Name: NavigationBarColor
Parameters: Extends Screen As MobileScreen, Assigns Value As ColorGroup
Scope: Global

Add the following snippet of code in the Associated Code Editor:

// Getting the ViewController for the received Screen
Var controller As Ptr = Screen.ViewControllerHandle

// https://developer.apple.com/documentation/uikit/uiviewcontroller/navigationcontroller?language=objc
Declare Function NavigationController Lib "UIKit" Selector "navigationController" (controller As Ptr) As Ptr

// https://developer.apple.com/documentation/uikit/uinavigationcontroller/navigationbar?language=objc
Declare Function NavigationBar Lib "UIKit" Selector "navigationBar" (controller As Ptr) As Ptr

// Getting the NavigationBarController associated with the ViewController
Var nc As Ptr = NavigationController(controller)

// …and the NavigationBar itself from the NavigationBarController
Var nv As Ptr = NavigationBar(nc)

Var colPtr As Ptr
If value <> Nil Then
  colPtr = ColorGroupToUIColor(value)
End If

// https://developer.apple.com/documentation/uikit/uinavigationbar/standardappearance?language=objc
Declare Function StandardAppearance Lib "UIKit" Selector "standardAppearance" (obj As Ptr) As Ptr
Declare Sub SetStandardAppearance Lib "UIKit" Selector "setStandardAppearance:" (obj As Ptr, value As Ptr)

// https://developer.apple.com/documentation/uikit/uinavigationbar/scrolledgeappearance?language=objc
Declare Sub SetScrollEdgeAppearance Lib "UIKit" Selector "setScrollEdgeAppearance:" (obj As Ptr, value As Ptr)

// https://developer.apple.com/documentation/uikit/uibarappearance/backgroundcolor?language=objc
Declare Sub SetBackgroundColor Lib "UIKit" Selector "setBackgroundColor:" (obj As Ptr, value As Ptr)

// Getting the StandardAppearance object from the NavigationBar
Var appear As Ptr = StandardAppearance(nv)

// Setting the BackgroundColor to the StandardAppearance…
SetBackgroundColor(appear, colPtr)

// …and assigning the Standard Appearance again to the NavigationBar
SetStandardAppearance(nv, appear)

// If our app is running on iOS >= 15.0, then we need to set
// the same appearance to the scrollEdgeAppearance attribute on the NavigationBar
if (System.Version.MajorVersion >= 15.0) then
  SetScrollEdgeAppearance(nv, appear)
end if

As shown in the previous code, we’re calling the ColorGroupToUIColor method to convert a ColorGroup instance into a pointer to a valid UIColor. To support this, let’s add that helper method to our DeclaresForiOS module using the following values:

Method Name: ColorGroupToUIColor
Parameters: value As ColorGroup
Return Type: Ptr
Scope: Global

And type (or paste) the following snippet of code:

Var colorPtr As Ptr
Var c As Color

Select Case value.Mode
  
Case ColorGroup.Modes.Dual
  Var valueColors() As Color = value.Values
  If Color.IsDarkMode And valueColors.LastIndex > 0 Then
    c = valueColors(1)
  Else
    c = valueColors(0)
  End If
Case ColorGroup.Modes.Single
  Var valueColors() As Color = value.Values
  c = valueColors(0)
End Select

If colorPtr = Nil Then
  
  // https://developer.apple.com/documentation/foundation/nsclassfromstring(_:)?language=objc
  Declare Function NSClassFromString Lib "Foundation" (name As CFStringRef) As Ptr
  
  // https://developer.apple.com/documentation/uikit/uicolor/1621930-colorwithred
  Declare Function RGBA Lib "UIKit" selector "colorWithRed:green:blue:alpha:" (cls As Ptr, r As Double, g As Double, b As Double, a As Double) As Ptr
  
  colorPtr = RGBA(NSClassFromString("UIColor"), c.Red/255, c.Green/255, c.Blue/255, 1-(c.Alpha/255))
  
End If

return colorPtr

Let’s Color That!

And that is all the code we need! Now select the Screen1 item in the Navigator for the iOS project and add the following property to it:

Name: MyNavigationBarColor
Type: ColorGroup
Scope: Protected

With the Screen1 still selected in the Navigator, add the Opening event to it and add the following line of code:

MyNavigationBarColor = New ColorGroup( color.Red, color.Yellow )

As the last step, add the AppearanceChanged event to the Screen1 item; and add the following line of code to it:

me.NavigationBarColor = MyNavigationBarColor

Make sure the “Has Navigation Bar” attribute is enabled in the Inspector for Screen1, then run the project. If your Simulator or device is set to Light Mode, the Navigation Bar will appear red; if it’s in Dark Mode, it will appear yellow. You can switch between Light and Dark modes to see the Navigation Bar color transition between the two colors defined in your ColorGroup.

Download the example project from this link.

Happy coding!

How To Share Your Local Xojo Web App to the Internet Using ngrok

Gabriel Ludosanu — Thu, 07 Aug 2025 14:52:22 +0000

Have you ever built an amazing Xojo web application locally on your machine and wished you could instantly share it with a client, test it on a real mobile device outside your local network, or integrate it with a webhook service like Stripe or Twilio? If so, you know the pain of needing a publicly accessible URL for your locally running app.

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

What is ngrok and Why Xojo Developers Need It?

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

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

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

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

Getting Started with ngrok

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

Step 1: Download ngrok

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

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

Step 2: Unzip and Place

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

Preparing Your Xojo Web App

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

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

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

Tunneling Your Xojo App with ngrok

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

Step 1: Open Terminal/Command Prompt

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

Step 2: Navigate to ngrok Directory (if needed)

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

cd /path/to/your/ngrok/folder

Step 3: Run the ngrok Command

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

ngrok http 8080

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

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

ngrok                                                                            (Ctrl+C to quit)

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

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

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

Testing Your Public Xojo App

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

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

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

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

Conclusion

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

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

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

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

MobileImagePicker Gets More Flexible

Javier Menendez — Tue, 08 Jul 2025 18:01:00 +0000

For years, the MobileImagePicker control has allowed users to choose between the Camera and Photos as the source. So far, so good—but there was one major limitation: when the source was set to Photos, users could only select one photo at a time from an album. Not anymore.

Select Multiple Images

Starting with Xojo 2025r2, we’ve updated the MobileImagePicker for iOS to use a more modern controller under the hood. As a result, users can now select multiple photos at once (depending on the needs of your app) and also take advantage of additional features available in the new image selector.

In addition, as a result of this change, we’re now able to capture and provide more complete EXIF metadata for each selected image.

The best part is, you don’t need to change a single line of code to take advantage of these new capabilities. However, due to the asynchronous nature of iOS, the Selected event handler of the MobileImagePicker will now fire once for each image the user selects. Be sure to account for that in your app’s logic. You may want to check out the updated “MobilePicture-Metadata” example project for guidance.

Choose Your Camera Source

When MobileImagePicker.Source was set to Camera, it defaulted to the device’s rear camera, which works well for most scenarios. However, some apps may need to use the front camera by default. While users could always switch cameras with a tap, it’s even better if your app can save them that extra step.

Now, if your app requires the front camera by default, you can set the source to the new enum value: Source.FrontCamera.

Share More with the Improved MobileSharingPanel

Javier Menendez — Tue, 08 Jul 2025 18:01:00 +0000

Starting with Xojo 2025r2, you can share more than ever before using the MobileSharingPanel. Keep reading to discover the exciting improvements waiting for you!

In previous releases, the MobileSharingPanel control allowed your app to share a single picture, a URL, or text with any registered iOS system service or app. Now, you can share multiple pictures at once and also share as many files as you want (including entire folders)!

To share multiple pictures, we’ve overloaded the SharingPanel.SharePicture method so its first parameter can accept an array of pictures. It’s that simple. When the panel appears, the same action will apply to the whole group.

For sharing files, you now have two methods available:

MobileSharingPanel.ShareFile(file As FolderItem, parentScreen As MobileScreen = Nil, parentControl As MobileUIControl = Nil)

MobileSharingPanel.ShareFile(files() As FolderItem, parentScreen As MobileScreen = Nil, parentControl As MobileUIControl = Nil)

The first method is designed to share a single FolderItem instance. If that FolderItem points to a folder, the entire contents of the folder will be shared.

The second method accepts an array of FolderItem instances as its first parameter. This is likely the best choice when your app needs to share a group of items from different sources, offering greater flexibility.

Overall, the enhanced SharingPanel is now more powerful and versatile. We’re excited to see how you’ll put it to use in your mobile apps!

iOSLayoutConstraints … Less Constrained

Javier Menendez — Tue, 08 Jul 2025 18:01:00 +0000

Until now, the only way to work with named iOSLayoutConstraint instances was by assigning a name in the Inspector Panel. This allowed you to reference them later in code, for example, to deactivate, reactivate, or remove them from a MobileScreen or MobileUIControl. Very handy!

But what about iOSLayoutConstraint instances created in code? Starting with Xojo 2025r2, that’s been improved! Keep reading to learn how.

Of course, there have always been ways to manage iOSLayoutConstraint instances created in code (for example, by storing references to them) so you could interact with them just like the named constraints created at design time. But with Xojo 2025r2, we’ve made that even easier.

The MobileScreen.AddConstraint and MobileUIControl.AddConstraint methods now include an optional name parameter. This means you can assign a name to constraints added in code and later activate, deactivate, or remove them by name, just like design-time constraints!

Of course, you can’t assign the same name to multiple constraint instances on the same screen or UI control. If you try to do so, an UnsupportedOperationException will be raised.

We’ve also overloaded the MobileScreen.RemoveConstraint method to accept a String parameter, allowing you to remove a named constraint directly. No need to keep track of iOSLayoutConstraint instances using property references or other custom methods.

All in all, starting with Xojo 2025r2, you no longer need to implement your own logic to manage constraint instances. This makes it much easier to build responsive, polished UIs that adapt well across platforms and device orientations.

A Guide to Managing Multiple Apple Developer Accounts in Xojo 2025r2

Javier Menendez — Tue, 08 Jul 2025 18:01:00 +0000

Usually, you only need to manage one Apple Developer Account when publishing your macOS or iOS apps. However, as many Xojo users have pointed out, there are situations where you need to work with multiple Apple Developer Accounts – perhaps you are publishing macOS apps for different companies (with different Team IDs). So, how do you handle this using the App Specific Password setup introduced in Xojo 2025r1?

The good news is that starting with Xojo 2025r2, you’ll be able to manage multiple Apple Developer Accounts! By default, everything will work just as it did in Xojo 2025r1. That means Xojo uses a global App Specific Password tied to the Apple Developer Account login (usually an email), the Team ID, and the password generated at appleid.apple.com.

So, if you don’t make any changes, everything will continue to work as before for your existing and new macOS projects published to the Mac App Store. But if you need to publish other macOS projects under a different Apple Developer Account or Team ID, you’ll need to create a new App Specific Password at appleid.apple.com (giving it a unique name), enter the new credentials in Xojo’s App Specific Password setup dialog, and then enable the “Save with Project” checkbox.

When you do this, the App Specific Password will be saved with the project itself, and its settings will be used whenever you click the Publish button.

If you ever need to switch back to using the Global App Specific Password for that project, select the “Global” option from the popup menu at the top of the same dialog.

And of course, don’t forget: if you’re publishing macOS apps using multiple Apple Developer Accounts, make sure all the necessary certificates for those accounts are installed in your Mac Keychain!

Thank you to everyone who provided feedback and suggestions about this feature!

Build Your First iOS App with Xojo: 10 Practical Steps

Javier Menendez — Fri, 16 May 2025 15:45:00 +0000

Xojo is an extremely useful, fast and fun development environment for building your first (or next) iOS app. In this article, I offer a series of practical steps to guide you from idea to app.

1. Define Your Idea

Start by summarizing your app’s purpose in a single, clear sentence. The more concise it is, the better defined your objective will be. This clarity will help guide your screen designs, navigation structure and code architecture.

This sentence can also double as your app’s short description in App Store Connect.

Focus on the essential features that form your app’s Minimum Viable Product (MVP). It’s easy to get sidetracked by new ideas during development. Resist the urge! Instead, keep a list of potential features for future updates and base priorities on user feedback.

2. Choose The Platform(s)

Xojo supports both iPhone and iPad, but your app doesn’t have to. Choose the device type that best fits your app’s use case.

iPhone apps often support quick, task-based interactions.
iPad apps are better suited to immersive, content-rich experiences.

To target a specific device only, set the unused layout (iPhone or iPad) to “None” in the App item’s Inspector Panel.

You’ll also need to decide the minimum iOS version to support. Xojo currently defaults to iOS 14.0, but as of writing, over 60% of users are on iOS 18 or later.

3. Prototyping

Xojo’s visual layout editor makes it easy to dive in designing your app. But take time to prototype your app first, especially if it has more than basic functionality.

Use tools like Figma or MockUp, or simply sketch your ideas with pencil and paper. Choose whatever helps you plan best and clearly.

Also, review Apple’s Human Interface Guidelines to align your app with native iOS expectations.

When designing in Xojo, you can fine-tune layout behavior using the iOSLayoutConstraint class to adapt to orientation and screen size changes at runtime.

4. Database Design

Most apps use a database. For local storage on iOS, use SQLiteDatabase, and save your database file in SpecialFolder.Documents.

Two key best practices:

Add a Metadata table to track the database schema version.
Create a custom SQLiteDatabase subclass to manage all read/write operations in one place.

This setup allows you to always know which version is installed on the user’s device and to react accordingly as your app evolves.

5. Graphic Resources

For icons, buttons and tab bar images, use Picture.SystemImage with symbols from Apple’s SF Symbols app. These scale beautifully across devices and adapt to light/dark mode. Just ensure compatibility with your minimum iOS version.

When using custom images, add them at multiple resolutions for optimal display across all screen sizes.

Typography also matters. Use system fonts thoughtfully, ideally no more than two font families. Vary sizes and weights to establish content hierarchy. Keep text readable with a minimum font size of 11pt.

Tip: When testing in the Simulator, set the window to physical size (Simulator > Window > Physical Size) to preview real-world readability.

6. Localization and Accessibility

Nothing prevents you from publishing an app in a single language, whether it’s your native language or English; but supporting multiple languages can increase downloads by over 100x.

Start localizing early to avoid design issues later. Add a module to your Xojo project with localized String constants for all app text, and enable the “Localized” option for each one.

Suggested languages (in order of impact):

Core: English

High-impact additions: Chinese, Spanish, German, French, Japanese, Italian, Portuguese, Russian, Korean

Also, localize accessibility labels and App Store listings, including screenshots and descriptions, for each supported language.

7. Testing the App

Xojo provides multiple ways to test your app, both from a design and user experience perspective, as well as from a functionality perspective:

Simulators: Ideal for design, layout and localization testing. You can also use them to take App Store screenshots.
On-device Debugging: Offers realistic input experience and access to hardware-only features.
Build to Device: Lets you run the app outside the debugger, simulating real-world use.

Once you’ve finished fixing bugs in your code and app design, move on to testing in the real world by compiling your app and using Xcode to copy that bundle to a physical device. Testing like this, you’ll likely find some optimizations, especially around design and usability.

TestFlight is your gateway to external beta testers. After uploading a build to App Store Connect, create a public link to invite testers. Remember to increment the version number with each new build.

Tip: Add ITSAppUsesNonExemptEncryption = False in your Property List to streamline build approvals.

8. Publish it!

Publishing with Xojo is straightforward. The most time-consuming step is preparing your App Store Connect listing including text, artwork, screenshots, keywords and possibly localized pages. Read more about this in my earlier post How to Publish macOS and iOS Apps to the App Store Directly from Xojo.

Make sure you select the correct build when submitting your app for review.

9. Marketing

Something you should be doing simultaneously is preparing the related materials to introduce your app to the world. Start your marketing efforts early. A simple website can significantly boost discoverability. Use it to:

Provide tutorials and FAQs
Link to App Store and social media
Highlight features and updates

Consider creating a YouTube channel for app demos and support videos, and maintain active social media profiles to stay visible.

Don’t forget to take advantage of the Marketing tools provided by Apple to help you create badges, assets, links and even QR codes to promote your app.

10. The Next Steps …

After launch, gather user feedback and track any bugs that slipped through. At this stage, it’s common to manage:

A public release (on the App Store)
A development version (next major update)

Save your Xojo iOS project in text format and use a version control system. This helps you manage multiple branches and collaborate efficiently.

To Summarize

Even the simplest iOS apps require a fair amount of time and effort, but thanks to Xojo, both aspects are significantly reduced.

What iOS apps have you created with Xojo? What’s your methodology or any tips you’d like to share? Feel free to comment on the Xojo forum!

Updating macOS Keychain Passwords

Javier Menendez — Thu, 24 Apr 2025 15:00:00 +0000

The Keychain is a system-wide feature on macOS that securely stores account passwords for applications. Until Xojo 2025r1, updating the password for an existing KeychainItem—that is, for a given Service Name—required first removing the item from the Keychain and then recreating it from scratch. Not exactly the most efficient process. But with the introduction of the KeychainItem.UpdatePassword method in 2025r1, things have gotten much easier. Read on to see how you can take advantage of this new functionality.

Starting with 2025r1, there’s no longer any need to delete an existing Keychain item just to update its password. All you need is a KeychainItem instance with a non-zero Handle, in other words, a properly initialized item. And the best way to get a reference to an existing KeychainItem is by using the System.Keychain.FindPassword method. For example, the following code snippet from a method with the signature FindPassword(serviceName As String) As KeychainItem:

Var itemToFind As New KeychainItem
Var password As String

// Name to find
ItemToFind.ServiceName = serviceName

// Get the password
password = System.Keychain.FindPassword(itemToFind)

Return itemToFind

Catch e As KeychainException
  Return Nil

This retrieves the password for a given Keychain item stored under the Service Name passed as the serviceName parameter. If the call to System.Keychain.FindPassword raises a KeychainException, it means there’s no password stored in the Keychain for that Service Name so we return Nil. But if the method successfully retrieves a password, it means we have a valid, properly initialized KeychainItem we can use to call UpdatePassword.

For example, create a new method with the following signature:

Public Sub CreatePassword(pass As String, label As string, serviceName As String)
  // Let's see if we have a password for the item already.
  // If that is the case, we need to update it instead of
  // creating it!
  
  Var itemToFind As KeychainItem = FindPassword(serviceName)
  
  // If we don't get a Nil KeychainItem, that means that we should
  // update the password for such KeychainItem, instead of creating a new one!
  
  If itemToFind <> Nil Then
     itemToFind.UpdatePassword(pass)
  Else
    // We got a Nil KeychainItem… what means that there is not
    // such item in the user Keychain yet, so let's create it.
    
    itemToFind = New KeychainItem
    itemToFind.Label = label
    itemToFind.ServiceName = serviceName
    System.Keychain.AddPassword(itemToFind, pass)
  End If
  
  Catch e As KeychainException
    MessageBox("Keychain error: " + e.Message)
    
End Sub

As you can see, this method takes three string parameters: the password you want to set or update, the label to use for the Keychain item (particularly useful when adding a new password for a given Service Name) and the Service Name itself, which is associated with the password.

The first thing this method does is call the FindPassword method we saw earlier. If it returns a non-nil object, we simply update the password. However, if the FindPassword method returns a nil object, we create a new KeychainItem from scratch using the provided label and serviceName parameters, then add the new password to the user’s Keychain.

Download this example project to experiment adding, deleting and/or updating passwords to your macOS Keychain.

The MobileColorPicker Control Now Available for iOS Projects

Javier Menendez — Tue, 25 Mar 2025 15:34:19 +0000

Starting with Xojo 2025r1, you’ll find a new control in the iOS Library panel: MobileColorPicker. This control brings a native color-picking experience to your projects, allowing users to choose from a wide range of colors, save their favorites, or use a ‘loupe‘ to select a color directly from the screen.

Using the new control is similar to how you would use the same type of control in Desktop projects. For example, drag the control from the Library panel and drop it onto the Layout Editor of a Screen, where it will be added to the Tray area.

Next, you need to call the Show method on the MobileColorPicker instance to display it to the user, and implement the ColorSelected event handler to capture the selected color.

Note: This control’s functionality is available only when the app is run on devices with iOS 14 or later (the minimum recommended version for iOS projects starting with Xojo 2025r1).

Modal vs Popover

When calling the Show method without parameters on the MobileColorPicker instance, it will be displayed as a modal panel on both iPhone and iPad devices. If you provide the ParentControl parameter, the MobileColorPicker will be shown as a popover panel on iPad devices. However, on iPhone devices, it will still be displayed as a modal dialog, regardless of the ParentControl parameter.

In Summary

The addition of the MobileColorPicker control in Xojo 2025r1 simplifies color selection in iOS apps, providing a native and intuitive experience for your users. This control makes it easier than ever to implement color pickers in your iOS projects. So, give it a try in your next app, and enhance the user experience!

Property List Editor, Integrated in the IDE

Javier Menendez — Tue, 25 Mar 2025 15:34:12 +0000

Starting with Xojo 2025r1, a new Property List Editor is available for both Desktop (macOS) and iOS projects under Build Settings > macOS and Build Settings > iOS. This editor simplifies the process of adding custom entries that your app may require, beyond those automatically included by Xojo.

Some projects require additional entries in the generated Info.plist file. Previously, the only way to include these entries was to create the file manually using an external text editor, then drag and drop it into the project’s Navigation area. This allowed its contents to be merged with the entries automatically generated by Xojo in the final Info.plist file within the app bundle.

Now, the Property List Editor in the Xojo IDE provides a simpler way to add these entries. Once added, you can even export the contents to an external file, making it easy to reload them later for other projects that require the same set of entries. This saves time by eliminating the need to manually re-enter them.

What about projects that already reference an external Info.plist file? No worries—Xojo will automatically merge its contents with the entries added via the Property List Editor. If the same key exists in both the external file and the Property List Editor, the value from the Property List Editor will take precedence, overriding the one in the external file.

As for the types of data that can be added to the Property List Editor, the expected options are offered:

For collections:

Dictionary
Array

For primitive values:

Number
String
Boolean

For primitive value entries, the Editor allows you to convert them to any of the other two supported primitive types. For example, if you add a Number entry, you can later select it and convert it to a String or Boolean type as needed.

Of course, the entries added through the Property List Editor are applied and saved to the project file in addition to any changes made using the Property List Editor. The next time you open the project in Xojo, you’ll find the previously applied Info.plist entries already in place.

Tip: If you’re using the new Publish feature to send your macOS apps to App Store Connect, you can simplify Apple’s encryption compliance process by adding a new Boolean entry in the Property List Editor with the following values:

Key: ITSAppUsesNonExemptEncryption
Value: False

By doing this, you won’t need to manually go through the “Manage” option for Apple’s encryption compliance on the App Store Connect website—provided your app does not actually use encryption that requires disclosure.

In Summary

Whether you’re developing macOS or iOS projects, the integration of the Property List Editor in the Xojo IDE streamlines the process of managing additional Info.plist entries. You no longer need to manually create and import external files —now, you can add, edit, and reuse entries directly within the IDE. This not only saves time but also ensures consistency across multiple projects!

Tips – Xojo Programming Blog

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

What Is Conditional Compilation?

#If False – Completely Excluding Code

Why Not Just Comment It Out?

#If True – Always Including Code

When Is #If True Useful?

Defining Custom Compiler Constants

Best Practices

Conclusion

Custom Control Rendering with DrawControlInLayoutEditor

Why this matters

How it works

A note about XojoScript limitations

Support for more Graphics

Turning off this feature

Finally

Watchpoints in Xojo: A Smarter Way to Track Your Data

What Are Watchpoints?

How Watchpoints Work

Why This Matters

Conditional Watchpoints

Handling Object Lifetimes

What works and what doesn’t

Final Thoughts

Xojo + XAML + Goto = 🔥

Visual States in XAML

Example XAML

Triggering the Transition from Xojo

Why This Is Powerful

Detecting UI Compatibility Mode in macOS Apps with Xojo

Testing the Method

In Summary

Tip: Customize Toolbars on macOS apps

macOS and iOS: UI Compatibility Mode

The Last Word

Introducing Jade, the Xojo AI Assistant

Getting Started

Using Jade

Other Tips

Wrap

Welcome to the Grid

Is the DesktopGrid a replacement for DesktopListBox?

Performance Caveats to Consider

Wiring the Grid

Xojo 2025r2.1: Publishing macOS Apps Under Tahoe

RegEx Examples: 10 Practical Patterns You Can Copy and Paste

Setup (3 lines you’ll reuse)

1) Replace all occurrences (word boundary)

2) Strip HTML tags

3) Extract the first number (capture groups)

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

5) Find all words (simple iterator)

6) Replace only the second occurrence

7) Lookarounds

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

7.2 Positive lookbehind + optional decimals: amounts right after $

8) Smallest span between tags (non‑greedy)

9) Extract emails (simple demo)

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

Quick replacement references

Options you’ll use most

Common gotchas

Wrap‑up

DesktopTextArea Without Soft Wrapping Lines on macOS

4 Setting the Badge Color for Tabs on iOS

Setting the Badge Text Color

Testing the App

3 Coloring the Tab Bar on iOS

Background Color for the TabBar

Setting the Text Color

Setting Unselected Tabs Text Color

Testing the TabBar Color

2 Coloring the Navigation Bar Text on iOS

Colorizing!

1 Coloring Your iOS App Navigation Bar

Let’s Color That!

How To Share Your Local Xojo Web App to the Internet Using ngrok

What is ngrok and Why Xojo Developers Need It?

Getting Started with ngrok

When Is `#If True` Useful?