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.

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

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

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!

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

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

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!

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

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

App Store Connect is where developers create app records as part of the process to make their apps available on the Mac App Store and/or iOS App Store. All apps must go through Apple’s review process for approval. Once an app record exists in App Store Connect, every new app build uploaded from the Xojo IDE will be available there!

First Things, First

Before exploring how to use Xojo’s new Publish feature, let’s review the requirements and previous processes to better understand how it works.

You may have already met these requirements, but it’s always a good idea to review them.

• A paid Apple Developer membership (approximately US $99/yr).
• Xcode installed on your Mac, preferably the latest version (Xcode 16.2 at the time of writing, which requires macOS Sequoia 15.2). However, Xojo also works with Xcode 13 or later, such as on macOS Ventura.
• The following certificates are present in your Mac’s Keychain:
  • Developer ID Application
  • Apple Distribution
  • 3rd Party Mac Developer Installer
• An explicit App ID (Identifier) has been created for your app at developer.apple.com.
• A Provisioning Profile has been created at developer.apple.com to ensure the uploaded build is available for testing via TestFlight.
• No pending agreements are waiting for your approval at both developer.apple.com and appstoreconnect.apple.com.

Handling Certificates

The best way to ensure you have the correct certificates installed in your Mac’s Keychain is to manage them directly from Xcode. Open Xcode, go to Preferences > Accounts, and make sure you are signed in with your developer.apple.com credentials.

Next, click the “Manage Certificates…” button. A new window will appear, displaying the installed certificates—including expired ones or those missing a private key. From here, you can also download any missing certificates.

Once the required certificates are installed on your Mac, I recommend opening the Keychain app to remove any revoked, expired, or incomplete certificates (those missing a private key) to keep your Keychain clean and organized.

Handling App ID

The App ID, Identifier, or ‘Bundle Identifier’ is something you should be familiar with whenever you create a new macOS or iOS app in the Xojo IDE.

You also need to create the same App ID at developer.apple.com. Log in to the Apple Developer portal using your Apple Developer credentials, then click “Identifiers” under the “Certificates, IDs & Profiles” section.

Note: Keep in mind that you must create a new App ID and follow these steps for each macOS or iOS app you want to distribute through the Mac or iOS App Store.

• On the page displayed after the previous step, click the “+” button next to the “Identifiers” header to register a new Identifier.
• On the next page, ensure that “App IDs” is selected, then click “Continue”.
• On the following page, select “App”, then click “Continue” again.
• Now, you’ll reach the most important step—entering the explicit Bundle ID. Make sure it exactly matches the “Application Identifier” used when creating the project in the Xojo IDE.
• Also, verify that the App ID Prefix matches the Team ID of the certificates installed in your Mac’s Keychain via Xcode.
• Select any Capabilities and/or App Services your app requires. (For this example, none are selected.)
• Click “Continue” to proceed to the summary page, where you can review all the entered details and selected Capabilities/App Services.
• If everything looks correct, click “Register” to finalize the process.

Once registered, the new Identifier will appear in the list under the “Identifiers” section.

Handling Provisioning Profiles

TestFlight is an Apple service that allows developers to gather feedback from users and teammates while an app is still in development, before it becomes publicly available on the Mac or iOS App Store. When a new app build (version) is published from the Xojo IDE, it will also become available through TestFlight.

However, for this to work, the app must have a “Provisioning Profile” embedded. This profile needs to be created on the “developer.apple.com” website, as we did in the previous “App ID” section.

There are two main types of provisioning profiles: “Development” and “Distribution.” The key difference is:

• “Development” profiles specify which devices an app can be installed on. They are primarily used for internal testing on user devices or, in the case of iOS apps, for running tests on a physical device using the “Run On Device” option in the Xojo IDE.
• “Distribution” profiles are used for submitting apps to the App Store or making them available for TestFlight testing.

In this example, we will focus on creating a “Distribution Provisioning Profile” to ensure that apps published from the Xojo IDE are eligible for TestFlight testing.

• Log in to “developer.apple.com” and navigate to the “Certificates, IDs & Profiles” section.
• Select “Profiles” and click the “+” button next to the “Profiles” header.
• On the next page, under the “Distribution” section, select “Mac App Store Connect” if you are creating a profile for a macOS app. For iOS apps, choose “App Store Connect” instead. Click “Continue.”
• Select the “App ID” you previously created. Notice that the App ID is prefixed with the “Team ID” from when the App ID was created (e.g., “BW7PU32485”).
• Under “Profile Type,” make sure the “Mac” option is selected instead of “Mac Catalyst.” Click “Continue.”
• On the next page, select the same “Distribution” certificate that will be used when building the Xojo app (i.e., the “Apple Distribution” certificate installed on your Mac). Click “Continue.”
• Give the Provisioning Profile a meaningful name so you can easily distinguish it later from other profiles. Click “Generate.”
• After a few seconds, the Provisioning Profile summary page will appear with a “Download” button. Click it to download the profile.

NOTE: Provisioning Profiles for iOS
For iOS apps, you need to create both “Development” and “Distribution” provisioning profiles.

• When creating the “Development” provisioning profile, be sure to include all registered devices you want to use for installing and testing the app directly from Xojo (using the “Run On Device” option in the IDE).
• Once these provisioning profiles are downloaded to your Mac, double-click on them to ensure Xcode installs them in the correct location (as of this writing: “Library > Developer > Xcode > User Data > Provisioning Profiles”).

Adding the Distribution Provision Profile to your Xojo Project

Move the downloaded macOS Distribution Provisioning Profile to a more convenient location related to your Xojo project, and rename it to “embedded.provisionprofile”.

Next, open your Xojo project and add a new “Copy Files” step:

• Right-click (or use the contextual menu) and choose “Add to ‘Build Settings’ > Build Step > Copy Files”.
• Select the “macOS” item under “Build Settings.”

Next, click the “Add File” button in the “Copy Files” toolbar and select your “embedded.provisionprofile” file.

In the associated “Inspector” panel, use the following values:

• Name: Distribution Profile
• Applies To: Release
• Architecture: Any
• Destination: Contents Folder

NOTE: For Xojo iOS projects, provisioning profiles are applied automatically when building or publishing the app. This happens based on the profiles installed by Xcode when you double-click them after downloading from developer.apple.com.

App Store Connect: Creating the Record for the App

You need to create an App Record for every macOS or iOS app that will be distributed through the Mac or iOS App Store. To upload an app from the Xojo IDE, it is not necessary to complete every required field in the various sections right away—you can do that at your own pace. However, you must at least have an App Record created for the app.

To do this, log in to “appstoreconnect.apple.com” using your developer credentials. Once logged in, select the “Apps” icon. On the next page, click the “+” button and choose “New App” to create a new App Record. The previous action will open a dialog where you need to enter the essential app information required to create the record.

• Platforms: Select “macOS.”
• Name: Enter the same name used in your Xojo project for the app (Build Settings > macOS > Mac App Name). Apple can be strict about this during the app review process if the names differ, as this will also be the name displayed in the App Store listing.
• Bundle ID: Select the App ID you created for the app by following the steps in the “Handling App ID” section.
• SKU: Enter any arbitrary SKU value that makes sense to you for uniquely tracking this app.
• User Access: If you are a solo developer, the choice doesn’t make much difference. However, if you are part of a team, selecting “Limited Access” allows more control over which team members can access the app.

Once you are confident with the information provided, click the “Create” button to generate the new app record.

If you receive an error stating that another app has already been registered with the same name, you will need to choose a different name for your app.

NOTE: Values such as the App Name and Bundle ID can be changed later, if needed, from the “General > App Information” section on the App Record page.

Once the App Record has been created, there will be a lot of required information to fill in before the app can go through the App Store Review Process and be publicly listed in the Mac/iOS App Store upon approval. However, as mentioned earlier, you can add this information at your own pace. The most important thing right now is that, once the record is created, you have everything set up to start uploading your app builds (versions) from the Xojo IDE.

Publishing Mac Apps From Xojo

General Information

Open your Xojo project in the IDE and go to Build Settings > macOS. Then, make sure the correct values are set in the associated Inspector Panel for the following fields:

• Mac App Name: This should match the name entered for the App Record on appstoreconnect.apple.com.
• Bundle Identifier: This should match the App ID created for the app.
• Category: Select the category that best fits your app from the available options.

App Store Connect Setup

To allow the IDE to upload the app to App Store Connect, you need an app-specific password. You can add it by clicking the App Store Connect > Setup button. If you have already created this app-specific password in a previous version of Xojo (under Build Settings > Sign > Notarization > Setup), you don’t need to do it again. Also, keep in mind that this setup only needs to be done once for all your Desktop (macOS) and iOS projects.

Signing and Sandboxing

Select Build Settings > macOS > Sign in the project browser in order to access the associated Inspector Panel:

• Developer ID: Type (or paste) the full string from the Apple Distribution certificate installed on your Mac. In this example, it is: “Apple Distribution: Francisco Javier Rodriguez Menendez (BW7PU32485)”. This certificate should match the one selected when the Distribution Provisioning Profile was created, and the Team ID (the value in parentheses) should match the one used when the App ID (Identifier) was created for the app at developer.apple.com.
• Sandboxing: Apps uploaded to App Store Connect require Sandboxing to be enabled. Turn on this option and click the associated “Edit” button to enable the necessary sandboxed features for your app. In our example, we only enabled the ability to read/write the selected user files.

Shared Settings

Select Build Settings > Shared in the project browser to access the associated Inspector Panel:

If you are going to publish the final (release) version of your app after it has been thoroughly tested, you will likely want to set the Stage Code value to “Final.” Additionally, make sure to enter the short version string in the Version field and the copyright information for the app in the Copyright field.

NOTE: Did you forget something? Every time you click the Publish button (or select the equivalent “Build and Publish to App Store Connect” menu item from the Project menu), the IDE will run a “checklist.” If something needs to be set in the IDE before uploading the app to App Store Connect, any errors will be shown in the IDE’s Error Panel, pointing out “what” needs to be fixed and “where” to make the changes.

App Icon

Nothing new here, apart from building your macOS app for regular or “web-based” distribution. Your app needs an icon in the required sizes. However, when it comes to publishing to the Mac/iOS App Store, this requirement is even more strict. Xojo will catch this before starting the app building process to save you time spent on compilation and uploading. So, make sure you add all the required icon sizes by selecting the App item in the project browser, then clicking the Appearance > Icon option in the associated Inspector Panel.

That action will open the Icon Editor, where you can drag and drop the different icon files for each size or paste them directly from your preferred image editor.

Publishing!

Click the Publish button. Once the “checklist” passes without any errors, a confirmation dialog will appear. Click the “OK” button to begin the process and upload your app’s new build to App Store Connect.

If everything goes smoothly, you will see a “Success” dialog at the end of the process. However, if there is an error during any of the steps, an error message dialog will provide more details about the issue, and the process will be interrupted, returning you to the IDE.

In either case—whether your new app build was successfully uploaded to App Store Connect or not—you can find the generated Log file in the same folder as the built app. If there are errors, you can open the Log file to review the information about the issue(s), which will help you resolve them before trying again. For example:

2025-01-23 12:54:35.030 *** Error: [ContentDelivery.Uploader.6000028E01C0] The provided entity includes an attribute with a value that has already been used (-19232) The bundle version must be higher than the previously uploaded version: ‘1.0.6’. (ID: d422b9bf-049f-4263-af43-8357c2fe5f00)

In this case, the Log file entry indicates that we tried to publish a build with the same version number as an already uploaded build on App Store Connect. If this new build includes changes or new features, the way to fix this issue is simply by increasing the version number (and the short version string) before publishing it.

Testing with TestFlight

When you create a new app record in App Store Connect and access it, one of the tabs at the top of the page is named “TestFlight.” Click on it, and you will see all the uploaded builds of your app that are eligible for testing.

As you can see, there is a warning icon next to the app build we just uploaded (A). This is because Apple requires additional information from you regarding the app’s compliance with Encryption Export Regulations. To provide this information, click the associated “Manage” link to access the dialog where you can make your choice about it.

TIP: Use the new Property List Editor in Xojo’s IDE and add the following Key/Value pair to avoid manually going through the Encryption Export Regulations compliance process:

• Key: ITSAppUsesNonExemptEncryption
• Value: False

Once the requirement has been completed, the build status will change to “Ready to Submit.” As you can see, it also indicates that this build will be available to your testers for the next 90 days before expiring. This should be enough time before you send new test builds to them, anyway.

For each of your apps, you can create as many tester groups as needed. By default, there is only one entry: “Internal Testing.” You can create additional groups and add any members of your Apple Development Team to the groups you create. Click on the “+” icon to create your first group.

• Give the new group a name and uncheck the “Enable automatic distribution” checkbox. Then, click the “Create” button.
• Once the new internal testing group is created, you will be able to assign any uploaded (and not expired) builds of your app to it. You can also add members to the group (remember, these should be members of your Apple Developer Team!).

However, having internal testing groups might not be very helpful if you are a solo developer or part of a small team. The good news is that once you create the first, mandatory internal group, a new option will be added to the TestFlight sidebar.

External Testing

In this case, you will be able to invite up to 10,000 members to test your app. The main difference compared to internal groups is that once you select a build to be tested in any of the external groups, it must go through the Beta App Review process. This means the build won’t be immediately available to your testers until the review is complete. However, this process is only required for the first build—subsequent builds will be available immediately, just like in internal groups.

When inviting members to an external group, you have several options: you can create and share a public link, manually add testers, or even import them from a .csv file.

In any case, your testers will be able to download, install, and begin testing your app, as well as provide feedback!

In Summary

The new Publish feature simplifies the process of submitting your macOS and iOS apps to App Store Connect, making them available on the Mac App Store and iOS App Store directly from the IDE, without needing any external apps (such as Transporter).

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

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

With Windows 10 version 1703, Microsoft introduced built-in ICU support, allowing applications to use the system provided ICU instead of bundling their own. By leveraging this, Xojo now benefits from automatic updates, a reduced app footprint, and improved compatibility with the latest Unicode and locale data.

Which parts of the framework use ICU?

One of the main areas where ICU is used is the DateTime class, which includes Locale and TimeZone support. This helps with formatting dates and times and handling timezone differences reliably. ICU is also used for number formatting and string manipulation, particularly when working with characters like emojis and other complex Unicode symbols.

What benefits can be observed?

• Fewer DLLs
• 45MB smaller app sizes
• Faster execution times, i.e. DateTime.Now is roughly 10% faster
• Daylight saving time no longer requires a rebuild of your Xojo app

What are the new requirements?

As mentioned, Windows began including prebuilt ICU libraries starting with Windows 10 version 1703, so your apps won’t run on earlier versions. However, if you’re using Windows Server 2019, you’ll need to be on at least version 1809.

Conclusion

By shifting to Windows’ built-in ICU libraries, Xojo has eliminated the need for manual ICU updates and reducing app file sizes. This change means your apps will always have the latest updates for date/time, locale, and character handling, thanks to Windows updates.

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

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

Introducing the Xojo IDE for Linux ARM64

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

What is Supported?

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

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

Xojo Loves Pi!

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

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

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

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

ColorGroups

Now available for Android, ColorGroups are a way to have a color that can differ between light mode and dark mode. There are three types of ColorGroups: Single, Dual and Named. Add a ColorGroup to your project using Insert->ColorGroup.

A Single ColorGroup is not really a group, it is just a single color. A Dual ColorGroup has separate colors for light and dark mode. A Named ColorGroup gets the color from the system or, in the case of Android, the app theme. You can see the available options in the Android submenu.

For the most part you can use ColorGroups just like you can with other project types. Android does have one addition, the ColorGroup.ToColor() method lets you specifically convert a ColorGroup to a Color. Normally this is done automatically by Operator_Convert, but support for that in Android is still young and this method serves as a workaround should you run into issues with it.

In the Inspector for controls with ColorGroup properties, such as MobileButton.CaptionColor, you can use the ColorGroup selector to manually choose a Color or a ColorGroup:

In addition to working with ColorGroups as project items, you can also create ColorGroups in code:

Var cg1 As New ColorGroup()
cg1.AddColorPair(ColorGroup.Platforms.Mobile, Color.Blue, Color.Teal)

You can also use Android system color names to create a named color:

Var cg2 As New ColorGroup()
cg1.AddNamedColor(ColorGroup.Platforms.Mobile, "holo_purple")

Refer to the Android docs for R.color to see what the system color names are. Keep in mind that not all names are available on all versions Android OS.

For more about ColorGroups, refer to the documentation.

Dark Mode Support

ColorGroups are particularly useful with dark mode and starting with 2025r1, Android projects now default to having Supports Dark Mode switched on.

Several controls have been improved to work better in dark mode at runtime.

In addition, the Android Layout Editor has been improved to look better when working in dark mode and now shows controls with dark mode variants.

Download the latest Xojo release and get access to these new features and more.

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

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

The History

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

A New Way to FolderItem Drag

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

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

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

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

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

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

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

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

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

An Added Benefit

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

Here’s how you could set it up:

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

Conclusion

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

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

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

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

Making Your App Stand Out

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

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

Modernize with WinUI

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

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

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

The End Result

The latest drag and drop example has a functional GUI that looks professional and feels intuitive. All without writing a single line of JavaScript (we will enhance it a bit with some CSS, though).

Please note this is a sample project created to explore drag and drop, not a full featured Kanban board. I’ll omit on purpose things like persistence. The complete project can be found in the Examples section of the IDE, under Platforms > Web.

Let’s walk through how to make it happen.

Creating the Required Components

First, we need to define the building blocks of our Kanban board. In Xojo, WebContainers are perfect for modularizing reusable UI elements. Here’s what we’ll create:

• KanbanCard
  A WebContainer to represent each task card. It’ll have a simple label for the task name (e.g., “Write blog post”) and maybe a colored border or handle to indicate it’s draggable. Add a WebLabel for the text and set its properties in the Inspector to make it visually distinct.
• KanbanCardContainer
  Another WebContainer to act as a column. It’ll hold multiple KanbanCard Containers and serve as both a drag source (where cards come from) and a drop target (where cards land). Include a WebLabel at the top for the column title (e.g., “To Do”) and a rectangular area below it to house the cards.
• Main Page
  A WebPage to host everything. This is where we’ll arrange our columns side by side.

In the Xojo IDE, drag a WebContainer onto your project for the Card, another for the Column, and set up three instances of the Column Container on the main WebPage (“To Do,” “In Progress,” “Done”).

KanbanCard

This component will be pretty easy to build. It is basically a WebRectangle with a WebLabel that we will use for the Title. To make it easier to update, I’ve added a Title Computed Property that will update the TitleLabel if needed.

For the background WebRectangle, we will use the following ColorGroup. Please notice Xojo added support for Named colors, that will rely on the current Bootstrap theme, supporting Dark Mode:

As you can see, BackgroundRectangle and TitleLabel controls are implementing the Opening event. This is just to set the mouse cursor that will be shown when we hover:

Me.Style.Cursor = WebStyle.Cursors.Move

The container itself is also implementing the Opening event. This is to make this control draggable, using the following line of code:

AllowTextDrag(WebDragItem.DragActionTypes.Move)

Any descendant of the WebUIControl class is draggable. And yes, that includes custom controls created with the Web SDK.

For the WebDragItem.DragActionTypes Enumeration, you can choose one these options:

In this case we will only be allowed to “Move” a card from one place to another.

There are cases where it makes sense to support multiple drag action types. In your operating system’s file browser, when you drag and drop files and folders, you can change between Move, Link or Copy by using Keyboard shortcut combinations. Depending on the drag action type, the element will be moved, a symbolic link will be created, or it will be copied, respectively.

Normally you will implement just Move or Copy, but keep in mind it’s possible to have more (at the cost of increasing the learning curve of your application for your users)

Allowing something to be dragged is the first of two steps. You also need a place to drop these items into.

KanbanCardContainer

This container will be more elaborate, but should be easy to follow. Let’s see how it works at runtime, with some annotations:

The WebLabel we used for the Title and the WebButton used for adding new cards are positioned manually in the IDE designer. Same as the invisible WebRectangle holding the KanbanCard items and the KanbanAddCard custom button.

But instead of placing our cards manually, we’ll take advantage of the browser’s capacity for doing this job for us. We just want to add them dynamically at runtime and let the browser stack them vertically, automatically. We also want the browser to display a scrollbar if the columns have several cards.

Here is the code we will add to the WebRectangle:

// Let the framework know we want to let the
// browser place the items automatically
Me.LayoutType = LayoutTypes.Flex

// This style will ensure cards won't be
// placed horizontally by the browser
Me.Style.Value("flex-direction") = "wrap"

// If there are more cards than available
// space, this style will allow the user
// to scroll
Me.Style.Value("overflow") = "auto"

Let’s add some methods to add and remove cards at runtime.

• AddCardWithTitle(title As String)
• AddCardWithTitleAt(title As String, index As Integer)
• RemoveCardAt

Moving Cards Between Columns

Here’s where Xojo’s drag and drop shines. Each Card Container needs to be draggable and each Column Container needs to accept dropped cards. In Xojo:

1. Make Cards Draggable: Open the KanbanListCard in the IDE and implement the Opening event. Enter this code:
   AllowTextDrag(WebDragItem.DragActionTypes.Move)
2. Accept Card Drops: Open the KanbanCardContainer and implement the Opening event. This is the code we need in order to accept drops:
   AcceptTextDrop(WebDragItem.DragActionTypes.Move)
3. Remove from Source: To move (not copy) the card, in the source Column’s DragEnd event, remove the dragged card from its original parent after a successful drop.

With this, you can drag a card from “To Do” to “In Progress,” and it’ll visually jump columns. Xojo handles the heavy lifting. No JavaScript or DOM manipulation needed!

The Hard Part: Reordering Cards

Reordering cards within a column, or dropping a card into another column in a specific position is trickier. You need to detect where the card lands among its siblings and adjust their positions. Xojo’s drag and drop doesn’t natively sort UI elements, so we’ll simulate it.

There are several ways to achieve this, let’s explore some options.

One would be to deal with X/Y coordinates. Once you drop a card, you could take a look to see where the card landed, compare the coordinates with the other cards and reorder them accordingly. In desktop and mobile projects this could be a valid solution. In web projects, dealing with specific coordinates might work, but there are more accurate and easier solutions.

The second way could be good enough in most cases. Cards could also accept drops so, if you drop one card on another, we just have to put the card being dropped in the position where it’s being dropped, and push down the rest of the stack. This way you won’t need to scratch your head and deal with screen coordinates or control dimensions. The end result will be based on this idea.

But what should we do to generate the gap between Cards? Maybe you can create a transparent Container that also accept Card drops, to simulate the gap between cards.

This would work for you, and I honestly recommend you to give it a try, it’s super easy to implement and it will just work. If you don’t want to explore the CSS rabbit hole, that’s fine, this can be your bus stop.

Two downsides:

• You won’t have animations
• You will double the amount of controls on screen (performance may suffer)

I went in another direction though. Using some CSS, you can add and modify margins on the fly, with neat transitions. In my sample project, the margin between cards is managed by the `margin-top` CSS style.

And here is where the Xojo Framework helps. To make styling easier, it adds a CSS class to the element being dragged and also to the element where the mouse is over, when it’s accepting a drop.

dragging – The HTML element being dragged will have this property
dragover – The HTML element under the other element being dragged

In this case, the “Bar” card will receive the dragging CSS class, while “Test #2” will receive the dragover CSS class, while the “Bar” car is above.

I’ve added some transparency to elements with the dragging class. As you can see in the screenshot, the “Bar” Card opacity is set to 30%.

For dragover class, I’ve added some margin and transitions. If you drag something into a card, the top margin will grow, simulating it’s making room for the card you are about to drop.

Here is how the HTML Header section of the sample project looks like. It isn’t too much code, but it does uses some somewhat advanced CSS tricks:

This approach keeps cards neatly stacked and sortable. It’s the “hard part” not because you will have to write a lot of code, but because you’ll actually have to think a solution that won’t require roundtrips between the browser and the server. Xojo’s event system makes it manageable without JavaScript, and with some CSS, the result will be great.

Some CSS Enhancements

In some cases I’m using shadows and border radius using the Bootstrap’s CSS classes.

As you can see, I’m using rounded-2 for the border radius, and shadow-sm to easily add a shadow to the cards.

You can read more about this in the following blog post:
Introducing Named Color and CSS Classes in Xojo Web

There is a related sample project you might want to check:

Closing Thoughts

This has been a fun experiment to explore the Xojo Web drag and drop feature. Give the sample project a try and explore each control to see how it’s been created. I can’t recommend enough that you try to build it from scratch (and ask in the forum if you get stuck!)

We can’t wait to hear about how you plan to introduce drag and drop into your projects. Don’t be shy and create a forum thread to show what you have built, or what you are working on.

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

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

In previous Xojo releases, the Window menu in macOS-built apps didn’t quite feel native when run on macOS. This was because newer versions of macOS introduced default options that allowed apps to leverage various features automatically, without requiring developers to write additional code. For example, macOS extended available screens by using the surface of any nearby iPad.

Of course, it was always possible to add these capabilities using Declares (as explained in this blog post), but this wasn’t the ideal solution for developers. It required additional effort and knowledge, making it more cumbersome than having the features available in the framework.

Now, with the Window menu item automatically included in your Desktop projects, you don’t need to do anything extra to take advantage of the macOS functionality. Without writing a single line of code, your Xojo-built Mac apps will feel much more native starting with Xojo 2025r1!

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

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

Drag and Drop Support

The biggest thing this time is that we’ve added general drag and drop support for web. From now on, any visual control can be dragged or accept drops.. That includes controls created using the Web SDK, allowing you (and third-party developers!) to increase the user experience on your web projects.

Now, imagine new ways of updating a Database application. For example, creating a “Form Builder”, a full “Website Builder” or even a “Database Schema” web application where the user can drag elements from a library and drop them into the editor. Are you scheduling posts on social networks using a WebDatePicker? What about using a calendar view with drag and drop support?

We’ve included a drag and drop Kanban board example. Take a look at the blog post to learn more about it.

How cool is that?

While drag and drop can make your app easier to work with for some users, it can also be an accessibility barrier for other users. Just remember to offer an alternative way for interacting with your application. In a full featured Kanban app, for example, the user should still be able to change the status of a task from the task details screen, using a regular WebPopupMenu (or any other accessible method)

WebListBox Updates

Speaking of dragging things, WebListBox also now supports reordering rows using the mouse. Just enable the new Allow Row Reordering property (which is Off by default) and you are all set.

This can also be set programmatically at runtime with AllowRowReordering. Once the user finishes a reorder, the RowsReordered event is called, allowing you to persist the changes in your database, for example.

Another requested feature was to allow users to perform inline edits. WebListBox received some new methods and events to handle this:

• ColumnTypeAt: To make a whole column editable
• CellTypeAt: To override the ColumnTypeAt on specific cells
• EditCellAt: A method you can use to begin the edit on specific cells
• CellAction Event: Allowing you to persist the changes made by the user

This is also supported when using a WebDataSource.

And not only are TextField and TextArea supported, CheckBox is also part of the WebListBox.CellTypes enumeration, to match what DesktopListBox supports:

Last, but not least, we’ve decided to split CellTextAt into two different methods. Until now, you could get and set the caption of a cell using CellTextAt, but also a WebListBoxCellRenderer. This could cause trouble because a Variant was being returned, that could be either a String or a WebListBoxCellRenderer so, when not being used carefully, it could raise IllegalCastException at runtime.

From now on, CellTextAt will only support String. If you want to get or set a cell renderer, you will have to use CellRendererAt instead. This makes the API more obvious.

If you were using CellTextAt for getting and setting cell renderers, you will need to update your code to use CellRendererAt instead.

Wrapping Up

This release empowers Xojo Web projects to meet more user needs, no JavaScript required. Drag and drop finally joins the party, filling a critical gap from the old Web 1 framework.

Be sure to dig into the release notes, as 2025r1 packs over 40 changes for the web target alone.

I’d love to hear how you’re weaving these updates into your projects! Drop some screenshots or screen recordings in a new forum thread or shoot me a private message if you prefer.

Happy coding!

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

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

This control is available in the Xojo Library panel and works similarly to iOSMobileUserControl: drag it onto a layout and implement the CreateView event.

Declare Function Button Lib "Kotlin" Alias "android.widget.Button(context as android.content.Context)" (context As Ptr) As Ptr

Var bp As Ptr = Button(App.AndroidContextHandle)

Return bp

The above code uses a Declare to create a native Button and returns it so that it can be displayed in a layout.

By using AndroidMobileUserControl and Declares to access the Android UI library, you can create your own UI controls. I look forward to seeing what the community creates!

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

• Facebook
• X
• LinkedIn
• GitHub
• YouTube