2025r2 – Xojo Programming Blog

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!

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.

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.

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!

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.

Identify Yourself with UserAuthentication for Android

Paul Lefebvre — Tue, 08 Jul 2025 18:01:00 +0000

Mobile devices typically have a way for the user to identify themself. This can be using a fingerprint sensor, face detection or even with an old-school passcode or password. The UserAuthentication class, now also available for Android, is a great way to do this authentication.

UserAuthentication works similarly to how it is used on iOS. You can drag the control from the Library onto your layout and then implement the AuthenticationSucceeded event.

To request authentication, call the Request() method with a short string asking the reason why you need authentication.

UserAuthentication1.Request("Authorize me, HAL")

Because this is using system-level APIs, you and your app never know the details about the authentication. You will not know the password, passcode or have any specifics about a fingerprint or face. Instead, if the system determines that the authentication was successful, then the AuthenticationSucceeded event is called.

Here’s a quick video of it in action.

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.

Get There From Here with the MobileMapViewer for Android

Paul Lefebvre — Tue, 08 Jul 2025 18:01:00 +0000

A new control added to Android for Xojo 2025r2 is MobileMapViewer. This control uses the Google Maps SDK to display mapping data in your apps.

Before you can use MobileMapViewer you will need to have a Google Maps account configured so that you can generate an API Key. Instructions for doing this on available from Google: Google Maps Platform, Get Google Maps API Key.

Google Maps is not free to use. Although there is some free usage available for testing your app, your account does get billed based on usage once the small amount of free testing credits are used up.

When you have your API Key, you can add it to your Xojo project using a new App property. Select App in the Navigator and in the Inspector, put the key in the Google Maps API Key field. Note that the key is not saved with text projects and is instead saved as part of the UI state file that is local to the development machine. This prevents the key from being accidently committed to a source code repository.

With the configuration work out of the way, you can now use the control. Drag a MobileMapViewer from the Library onto a screen. When you run the project you’ll see an interactive map that you can swipe, zoom and move around as you like.

This code shows Fenway Park in Boston:

FenwayLocation = New MapLocation("Fenway Park, Boston, MA USA")
FenwayLocation.Title = "Fenway Park"

MapViewer1.ZoomRadius = 5
MapViewer1.GoToLocation(FenwayLocation) // Center map within radius km

MapViewer1.AddLocation(FenwayLocation) // Drop a pin

The MobileMapVIewer API matches what has already been in use for iOS. You can also use the MapLocation class to track specific locations. Although the overall API matches what has been used for iOS, there is one exception: MapLocation.PointsOfInterest() is not yet implemented. Implementing this requires another Google SDK and API Key (the Places API) and is being reviewed for a future release. We may also consider adding alternative mapping engines as well.

Note: You can’t get there from here is an old Maine saying.

Web Framework Updates in 2025r2

Ricardo Cruz — Tue, 08 Jul 2025 18:01:00 +0000

Featuring WebStyle state support for creating more polished user interfaces, enhanced event handling capabilities, and a collection of bug fixes and utility improvements, 2025r2 continues improvements to your Web Application development experience with Xojo.

Added Support for WebStyle States

Working on Desktop projects is all fun and jokes. You can just change how the whole application looks every time your application users move their mouse one pixel to the left. Latency? Who cares!

In order to achieve the same results, WebStyle has been improved to support states. Hover, Pressed and Visited.

WebStyle.Hover
This is the style that will be applied when the mouse is over the element
WebStyle.Pressed
This is the style that will be applied when the user is pressing a mouse button in the element
WebStyle.Visited
This style can be used with WebLink instances. Used to let the user know the browser has visited that link in the past

Consider the following WebContainer:

In this case, it’s just a container with a WebLabel inside.

The Opening event contains the following code:

Please note I’m using named colors. You can read more about named colors in Introducing Named Color and CSS Classes in Xojo Web. If you try using another Bootstrap theme, the same code will use the new color palette without modifications.

Here is the result:

Combined with WebStyle.AddTransition, it opens the gates for more interesting GUIs. Let’s add some transitions to our code:

Let’s try the project again:

Neat! Let’s go crazy for a second with more complex effects:

The result:

You should definitely avoid going that crazy, this is just to show the possibilities. As Dr. Ian Malcolm said … “Your scientists were so preoccupied with whether or not they could, they didn’t stop to think if they should.”

WebContainer.Pressed

Speaking about pressing on things, WebContainer.Pressed event is now available, so you don’t need to place a WebLabel or a WebContainer on top just to capture that event anymore. The event comes with some coordinates, just in case you need them.

The result:

Other changes

WebToolbar.Resized

Trying to tweak your design for different screen sizes? If WebToolbar’s automated behavior is not enough, you can implement the new WebToolbar.Resized event and adapt the contents. This is useful when you are reusing the same WebToolbar subclass in multiple WebPages. You will be able to place this code in just one place.

Exporting maps with WebMapViewer

Same as with MobileMapViewer. You can now use WebMapViewer.ToPicture method to export the current map. Like WebChart.ToPicture, due to the asynchronous nature of Web projects, the picture will be available in the new WebMapViewer.RequestedPicture event.

Updated DataTables

Last, but not least, DataTables has been upgraded from v1.13.4 to v2.2.2.

That’s (not) all!

As always, please make sure to check the release notes for a detailed list of new features and bug fixes. The Web framework is built on top of Xojo, new global features or bug fixes also applies to Web, including improvements to Console projects. Xojo Web is “just” a big Console project.

Thank you everyone for reporting, testing beta builds and giving us feedback.

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.

A XAML Driven UI

William Yu — Tue, 08 Jul 2025 18:01:00 +0000

If you’re building rich, maintainable and scalable user interfaces on Windows, XAML is a great choice. Its clean, declarative syntax and solid separation between design and code can make things easier to manage, and since it’s tightly integrated with the Windows UI system, it can really help take your app from basic to polished.

Migrating Towards XAML

We are slowly and selectively updating our Win32 UI to the more modern WinUI with the help of XAML. You’ll notice some incremental updates in 2025r2 to this effect when you’ve got the Use WinUI (Experimental) build setting selected.

For those who can’t wait for our Win32 UI updates or need more advanced XAML layouts today, the DesktopXAMLContainer provides a powerful and flexible solution with virtually unlimited possibilities.

For a quick refresher, please take a look at a blog post we did when we first introduced the DesktopXAMLContainer control.

A Deeper Dive into XAML

While previous blog posts have showcased the potential of using DesktopXAMLContainer, there’s still much more to explore when it comes to effectively using and understanding XAML within Xojo.

XAML is Asynchronous

Understanding that XAML operates asynchronously helps explain why setting or retrieving a property might not behave as expected—especially when a control hasn’t fully finished constructing. To reliably detect when a XAML control is ready, use the EventTriggered event and check if the eventName is “Loaded”. This is particularly important when working with complex layouts that include XAML controls containing embedded XAML content.

Due to the asynchronous nature of XAML control rendering, the DrawInto mechanism also needed an enhancement. For DesktopXAMLContainer, we’ve added an asynchronous variant DrawIntoAsync, which renders the control and returns a Picture via the supplied callback method.

Sub RenderXAMLPreview(container As DesktopXAMLContainer, targetCanvas As DesktopCanvas)
  // Pass the canvas as the user data so we know where to draw
  container.DrawIntoAsync(AddressOf XAMLDrawComplete, targetCanvas)
End Sub

Sub XAMLDrawComplete(image As Picture, data As Variant)
  If image <> Nil And data IsA DesktopCanvas Then
    DesktopCanvas(data).Backdrop = image
  End If
End Sub

Translating your XAML Experience

Rotating and scaling a XAML layout is as simple as applying the appropriate RenderTransform. In the following example, we rotate a XAML CheckBox within a Timer.Action event. Even though the entire XAML content is updated on each timer interval, the result remains smooth and fluid, demonstrating how well XAML handles dynamic visual changes.

Sub Timer1.Action()
  Static angle As Integer = 0

  angle = angle + 10

  If angle >= 360 Then angle = 0

  Var isChecked As Boolean = True

  If XAMLContainer1.Content <> "" Then isChecked = XAMLContainer1.Value("CheckBox.IsChecked")

  Var xaml As String = "" + _
	"" + _
	"" + _
	"" + _
	"" + _
	"" + _
	""

  XAMLContainer1.Content = xaml
End Sub

Child Controls Inherit the Parent’s Background Brush

When embedding a Transparent DesktopXAMLContainer on top of another, the child will inherit the parent’s background brush. This is useful for basic brushes, but note that it does not support acrylic brushes and won’t automatically adjust offsets for linear gradient brushes.

Layering XAML

WinUI and Win32 controls are rendered on separate layers. WinUI content is composited first, then Win32 controls are drawn on top. As a result, any Win32 control will always appear above WinUI content unless you directly parent a DesktopXAMLContainer control on a Win32 control.

Setting Focus for Embedded XAML Controls

Starting with 2025r2, you can now set focus to a specific control in your XAML layout. Here’s how this looks:

This layout uses a StackPanel with three vertically arranged buttons inside a single DesktopXAMLContainer. To set the focus to Button2, you would invoke Button2.SetFocus

XAMLContainer1.Invoke("Button2.SetFocus")

Extended XAML Features

As mentioned in a previous blog post, we’ve extended XAML with a new markup syntax unique to Xojo. The primary goal of this extension is to improve the reusability of XAML controls. For example, consider a layout that includes three different XAML buttons:

Updating the caption or changing the button’s color would require manual edits to the XAML content string. Wouldn’t it be more convenient if those properties were available directly in the Inspector? With a custom subclass, some tweaks to its Inspector behavior, and the Xojo-specific {XojoBinding} syntax, you can make that happen.

First, create a subclass of the DesktopXAMLContainer, we’ll call this our XAMLButton, and add the properties that you want to expose in the inspector.

We’ll modify the XAML content to use the new {XojoBinding} syntax, which dynamically replaces the placeholder with the corresponding property value from the Inspector based on its name.

Now you can just drag out your subclassed control and adjust its properties directly in the Inspector without needing to manually edit the XAML content.

Make sure to check out our XAML Subclasses example project to see the other possibilities.

Having Fun With XAML

With a better understanding of XAML and how it integrates with Xojo, you’re now ready to build a XAML-driven UI on Windows. In fact, our IDE already makes use of XAML in several areas, like the Splash Screen, the XAML Control Chooser dialog and the toolbar in the Documentation window. The possibilities with XAML are vast, so dive in and explore what it can do for you!

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.

Windows Barcode and HTMLViewer Updates

William Yu — Tue, 08 Jul 2025 18:01:00 +0000

The Barcode Scanner received a significant upgrade in Xojo 2025r2 on Windows, with support for more aspect ratios and video mirroring. The DesktopHTMLViewer also saw improvements with the ability to print to PDF.

Consistent Barcode Scanning Experience

Not to be outdone, the Barcode scanning experience on Windows has been brought up to par with other platforms, now including support for video mirroring in the scanning window. Also, if you were seeing a “squished” video before, we’ve now added support for a wider range of video devices and aspect ratios.

DesktopHTMLViewer Improvements

Thanks to some feedback we received, the DesktopHTMLViewer now supports raising the FocusReceived, FocusLost, KeyDown, and KeyUp events.

While DesktopHTMLViewer.Print works well, there are times you might want to go straight to PDF. If you’d rather skip the default print prompts, you can now use the new DesktopHTMLViewer.PrintToPDF(file As FolderItem) method to print HTML content directly to a PDF file. Just pass in the destination file and everything else works just like the regular Print method, including the PrintComplete event firing on success.

We’re always working to make Xojo better, and your feedback plays a big part in that. So from all of us here at Xojo—thank you! We truly appreciate your input as we continue to improve the product for you and everyone who uses it.