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

Can I develop iOS apps on Windows?

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

Do I need to install anything besides Xojo?

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

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

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

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

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

There could be a few reasons for this.

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

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

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

Do I need to keep Xcode open while using Xojo?

No. That is not necessary at all!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Helpful Resources

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

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

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

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

Specifically, the following properties can be used there:

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

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

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

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

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

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

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

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

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

Happy coding!

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

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

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.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

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.

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

macOS 26 and iOS 26

Over time, Apple has brought the user experiences of macOS and iOS closer together. macOS 26 and iOS 26, now aligned in version numbers, also share more similarities than ever in their user experience. These updates represent the most significant user experience changes from Apple since iOS was introduced in 2007 and Aqua for macOS seven years earlier. With such a big update, especially when designing elements to work on both large computers displays as well as small smartphone screens, it’s no surprise there’s some tweaking requiring after release. Clearly, Apple is still refining its platforms.

We continue to update Xojo as Apple defines its preferred user experience, ensuring that you can deliver the best possible experience to your users.

WinUI

We are also hard at work upgrading our Windows framework to WinUI, providing a modern user experience for Windows apps. You can see our progress in each release by enabling the Use WinUI (Experimental) option on the Advanced tab in Windows build settings. The “Experimental” label is a reminder that the feature is still evolving, and it will be removed once WinUI is fully ready. Our goal has always been to keep Xojo on a steady path, prepared for whatever challenges lie ahead.

Conclusion

On behalf of the entire Xojo team, I can say that we love what we do and we appreciate your support in allowing us to do it. We are Xojo users ourselves (after all, we make Xojo with Xojo) and we enjoy seeing what you make with it. With that in mind, feel free to tell us about your creations. Send your screenshots, descriptions and your story to hello@xojo.com.

What is a Library?

A Library is a collection of pre-written, reusable code containing methods, classes and UI. Up until now, the way to distribute a Library for use with Xojo was to create a Plugin or to manually re-use project items across projects. Both have pros and cons.

Plugins are compiled and do not expose source code, but plugins cannot be created using Xojo itself and are typically created using C/C++ along with the Xojo Plugin SDK. Sharing project items is fine for internal projects or open-source projects, but less ideal for commercial libraries. They can be harder to manually add to a project and are recompiled along with the project, slowing the debug process.

With a Xojo Library, you can now create your own compiled Library using Xojo itself. This Library can contain nearly any Xojo project item and can be easily used in other Xojo projects because it is distributed as a single file.

At a high-level, you create your Library in Xojo, add your project items to it and built it into a Library package file. Other projects can then use this Library package, which gives them access to the items you included in the Library.

Creating a Library

Here is a brief overview of how you create a Xojo Library:

1. In a Desktop, Web, Console or iOS project add a Library by choosing Insert->Library.
2. Add the project items you want to the Library. Any Xojo project item is supported, except for Worker.
3. Build the project. It will build the main app (which should serve as a test app for your Library) and a separate Library package file (with extension .xojo_library).
4. You can put this Library package alongside another project (on the drive) and it will be loaded when that project is opened by Xojo. You can then use the classes, methods and UI contained in the Library within your project. If you instead put the Library in the Plugins folder, then it will be available for all projects.

This is all best demonstrated by a quick example. Go ahead and create a Desktop project and add a Library to it, which adds a Library1 project item to the Navigator. Change its name using the Inspector to LibHello.

While LibHello is selected, choose Insert->Class. This adds Class1 to it. This new class is now part of the Library. With Class1 selected, change its name to StringStuff.

You can now add whatever methods or properties you want to the class. For our example purposes here we will add a simple method that reverses a string.

Public Function ReverseString(s As String) As String
  Var newString As String
  
  For Each c As String In s.Characters
    newString = c + newString
  Next
  
  Return newString
End Function

The Library could contain many other things of course, but to keep things simple this Library will have just the single class with its single method. Here’s what it looks like in the project:

The first thing to do is to test this Library ReverseString method. Add a button to Window1 and have it call the function, verifying the result.

Var stuff As New StringStuff
Var result As String = stuff.ReverseString("Xojo")

MessageBox(result)

When you run, you can see the output:

So far this is all not much different than you would normally be doing with a Xojo project. The next step is to create the Library package for use by other projects.

In the Build Settings area, select Shared. This is where you can enter some information about the Library that can be seen by those that use it.

• In the Version field, enter “1.0”.
• In the Copyright field, enter “Acme, Inc.”
• In the Description field, enter “A Xojo Library test.”

Also in the Build Settings area, check the boxes for the platforms you want the Library to work on. In most situations, you will want to select macOS, Windows and Linux.

Now click Build. This builds the app as usual, but also creates a separate Library package file (LibHello.xojo_library for this example) that can be used with other projects.

Using a Library

Now that you’ve created your Library package, you can use it with other Xojo projects. The Library built above was created within a Desktop project, so it can only be used with other Desktop projects. So the first thing to do is to create a new Desktop project (call it MyTest), save it and close it.

Once it is saved, go to Finder or Explorer and place a copy of the LibHello.xojo_library file (from its build location) alongside this saved project file.

Go back to Xojo and open the MyTest project. The project will open normally, but the Library will also be loaded up as well. You can see this by showing the Xojo About window and going to the Plugins & Libraries tab. There you will see the Library name along with the information you entered about it earlier. (Double-click on the Library row to show the description.)

Going back to the MyTest project, you can now use the Library with it. Add a button to the window and have it call the StringReverse function the same way you did before:

Var stuff As New StringStuff
Var result As String = stuff.ReverseString("Xojo")

MessageBox(result)

Now run the project and it will use the class and its method just as if it is part of the project.

That’s the basics of how to create and use a Library. You can of course include whatever you want in the Library, but as with any library it is usually a good idea to keep things well-organized.

Considerations

• A Library package (which uses ZIP) contains compiled code and definitions of the public API in that code.
• Only a single Library project item can be added to a project when developing.
• A project can use any number of Library packages.
• For a built library to work on all OS platforms, then those platforms must be selected before building it.
• Libraries only support 64-bit builds.
• Library packages are placed alongside the project file and are loaded when the project is loaded.
• Library packages can also be placed in the Plugins folder. These libraries will be loaded separately for each project.
• If items in your Library have dependencies outside the Library, then the Library package will not be usable in another project without those dependencies. For example, if a Library class method references a class in the main project, then it will build without an error (because the main project is available), but if you use that Library in another project you will get linker errors.

Why a Preview?

We are referring to this initial version of Xojo Libraries as a preview release because it is very new and we want to give more developers a chance to test with it so we can iron out issues. We encourage you to try moving your existing reusable code collections over to a Library to help test, while also improving your workflow. If you have any open-source projects that are essentially a Library, you might try building them into a Xojo Library package as well.

You can make Library packages available publicly, but you should probably tag them as a preview, beta or test version until we remove the preview label.

Read more about Libraries in the Xojo Documentation. Check out these open-source projects on GitHub that have recently been updated for API 2.0 and now have a Library that you can download from the Releases section:

• Visual Basic Library
• FileMaker Library
• WinAPI Library

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

Apple released macOS 26 and iOS 26 today, the first versions to ship with Apple’s new Liquid Glass look and feel.

The current release of Xojo (2025r2.1) runs smoothly on macOS 26 and can build apps that run on both macOS 26 and iOS 26. However, because 2025r2.1 uses an older version of Apple’s SDKs, many controls in both the IDE and the apps you build will still use the previous look and feel when running on these new macOS and iOS versions.

We’ve been working throughout Apple’s beta cycle to bring full support for Liquid Glass to Xojo. As you might imagine, Apple made a lot of changes to the OSs along the way — changes that affected things like our layout editor, control sizing, and behavior. Some of these changes were still happening very late in the process. Now that macOS 26 and iOS 26 are officially shipping, we finally know what the end result looks like and how it behaves.

Supporting Liquid Glass and the underlying system changes is a big undertaking and we still have more work to do. Since we build Xojo with Xojo, this means updating not only the Xojo framework but also parts of the IDE itself so it looks and behaves correctly on macOS 26 with Liquid Glass. Our goal is to let you use Liquid Glass in both built-in Xojo controls and third-party party plugins as soon as possible. That’s why the next release of Xojo, 2025r3, will be built for macOS 26 and iOS 26, giving your apps the latest look and feel while still allowing them to run on older versions of macOS and iOS. This includes projects still using API 1 windows and controls.

Because of the scope of these changes — along with other big, exciting features in the works — the testing cycle for 2025r3 will be longer than usual. As a result, 2025r3 will likely be our last major release of the year, followed by any needed point releases. The good news is that 2025r3 will pack in everything you’d normally see across two releases, plus more. It’s shaping up to be one of the biggest Xojo releases in recent years, with plenty beyond just Liquid Glass to look forward to. Additionally, the updates for 2025r3 aren’t limited to macOS or iOS — there are improvements and new features coming for all platforms, so every Xojo user benefits.

If you have a current license and would like to get early access, we’d love your help testing 2025r3. Just reach out and we’ll be happy to add you to the beta program. We can’t wait to hear your feedback once testing begins!

If you are a long time Xojo user, you know we have been through a lot of big changes like this. Sometimes we get it all done in a single release and sometimes it takes a few to get to 100%. Regardless, our goal is to make the transition for you a smooth one.

Geoff Perlman is the Founder and CEO of Xojo. When he’s not leading the Xojo team he can be found playing drums in Austin, Texas and spending time with his family.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

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!

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

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!

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

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.

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

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!

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

For this project, I created a small iPhone app to track my expenses – something I personally needed. While it’s designed for tracking holiday and travel spending, it works just as well for managing general monthly expenses.

Far from perfect, but useful for the described scenarios, this iPhone app lets the user set a trip location, add a description and even define a budget. That way, they can check in at any time to see how things are going during a trip or when tracking general monthly expenses. (It doesn’t make much sense to offer this kind of app for iPad.)

When it comes to entering new expenses, I wanted to keep it as simple as possible with minimal input and just a few taps. So, aside from entering the amount and the place where the expense occurred, the app automatically captures the geolocation. This helps me better remember places like restaurants, gas stations or points of interest I might want to stop at or visit again when traveling the same route.

When tracking monthly expenses, the app lets you duplicate existing entries so details like the expense location remain the same, and you only need to enter the new amount. This is especially handy if you tend to refuel at the same gas station or do your weekly grocery shopping at the same store.

So, what about charts? Honestly, this area has plenty of room for improvement and could eventually include a wide range of stats and visualizations. But for this initial release, I kept it simple to meet my own needs. In addition to the basic ‘Total Budget vs. Current Expenses’ stats, the app includes a Pie chart that breaks down spending by category.

Of course, you can download the full source code here and adapt or improve it so it suits your own needs.

Want to give it a try? The iOS app is available for free on the App Store: https://apple.co/3EGL33r

VoyageExpenses is built entirely with Xojo. It’s 100% Xojo code, with only two small exceptions where Declares were needed. It was published to the App Store using the Publish feature introduced in Xojo 2025r1.

Visit the Xojo Docs to learn more about using charts in Xojo. Visual elements like charts can make the data in your apps more memorable and impactful. We’ve written extensively on charting throughout the Xojo Blog.

Year of Code Project

• Year of Code: Kickoff
• January Project: Desktop Apps | Forum Discussion
• February Project: Database Apps | Forum Discussion
• March Project: Web Apps | Forum Discussion
• April Project: User Interface | Forum Discussion
• May Project: Mobile Apps | Forum Discussion
• June Project: Code Sharing | Forum Discussion
• July Project: Charting | Forum Discussion
• August Project: Console Apps | Forum Discussion
• September Project: Games | Forum Discussion
• October Project: Multi-Platform | Forum Discussion
• November Project: PDF | Forum Discussion

How to Play:

Each month we’ll announce a new theme and share an example project of our own. Share your projects to the Xojo Forum thread for that month via GitHub (all the links you need are posted above ↑ ). Learn how to use Xojo and GitHub.

The Prizes:

Monthly winners get $100 at the Xojo store. Every month you submit a project is another chance to win the grand prize. The grand prize is $250 cash plus a Xojo Pro license and a year of GraffitiSuite and will be announce in December. Learn more about the prizes.

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

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.

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

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!

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

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.

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

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.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

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!

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

But even though I have my own pets, I do love looking at pet pictures. It’s a simple pleasure, but there’s not much that I find more calming.

Years ago I made a Xojo app (CatsUp) that displayed random cat pictures and it was a lot of fun. And one thing that Xojo excels at is making it fun to create software! That’s what the Year of Code is all about, after all.

Speaking of that, here is the Year of Code topic for May: Mobile Apps.

You can already find CatsUp for iOS and Android included in the Xojo examples, but why stop at just cats? Being a dog guy, I want to see some dogs. All the dogs.

Since I’m not here to start a cats vs. dogs war, I thought, why not both? It turns out I’m not the only one that thinks this as there are actually public web services that serve up pictures of cats and dogs. Web services and mobile apps go together like peanuts butter and chocolate.

The web service for cats that I’ve previously used is called TheCatAPI and is available here: https://thecatapi.com

There is an equivalent dog one called, unsurprisingly, TheDogAPI: https://www.thedogapi.com

For my mobile app this month, I’ve created an all-new app that can show pictures of cats, dogs or both! I call it Pawz.

Actually, it’s two apps since I made versions for iOS and Android. Here’s a look:

Although they are separate projects, both use basically the same code. In fact there is only about 50 lines of code in each project! The UI itself is just a big ImageViewer that is used to show the picture and several toolbar buttons.

There are three buttons to request a cat picture, dog picture or a surprise picture that could be either. There is also an extra button that lets you share the picture, if you really like it.

You can find the source for the iOS and Android versions of Pawz on GitHub here:

https://github.com/paullefebvre/pawz

Year of Code is all about having some fun making an app. As you can see with Pawz, it doesn’t have to be anything extravagant. Even fun apps can be made quickly with very little code!

I can’t wait to see what great mobile apps you all create this month. Share your creations in the Forum topic.

One More Thing

Although phones and tablets are what we usually think of when talking about Mobile Apps, you know what else is rather mobile? A vehicle! And it just so happens that many vehicle manufacturers, such as Cadillac, Chevy, Ford, Honda, Polestar, Renault and Volvo are now using Android to run their infotainment systems. Technically it’s Android Automotive OS (AAOS), but it is very similar to regular Android.

Because Xojo builds standard Android Runtime (ART) apps, Xojo Android apps also work on Android Automotive OS as a “parked app”. You can test with this by using Android Studio to install an Android Automotive VM for the Emulator. Once you’ve added that you can run your Xojo Android projects on it just like any other device. Pawz works fine in an AAOS Emulator.

Why do I bring this up? No reason, although I believe Xojo 2025 Release 2 pre-release testing might be starting soon…

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

Year of Code Project

• Year of Code: Kickoff
• January Project: Desktop Apps | Forum Discussion
• February Project: Database Apps | Forum Discussion
• March Project: Web Apps | Forum Discussion
• April Project: User Interface | Forum Discussion
• May Project: Mobile Apps | Forum Discussion
• June Project: Code Sharing | Forum Discussion
• July Project: Charting | Forum Discussion
• August Project: Console Apps | Forum Discussion
• September Project: Games | Forum Discussion
• October Project: Multi-Platform | Forum Discussion
• November Project: PDF | Forum Discussion

How to Play:

Each month we’ll announce a new theme and share an example project of our own. Share your projects to the Xojo Forum thread for that month via GitHub (all the links you need are posted above ↑ ). Learn how to use Xojo and GitHub.

The Prizes:

Monthly winners get $100 at the Xojo store. Every month you submit a project is another chance to win the grand prize. The grand prize is $250 cash plus a Xojo Pro license and a year of GraffitiSuite and will be announce in December. Learn more about the prizes.

For the most part, writing drawing code will just work because you use Xojo’s Graphics class for Android, Desktop and iOS projects. Web projects, however, don’t use the Graphics class. The WebCanvas control’s Paint event is passed a WebGraphics object. While the Graphics and WebGraphics classes have a lot in common, sharing many of the same methods with the same parameters, they are two distinctly different classes from the perspective of the Xojo compiler. That means that while the code you write will look almost identical, you still have to use a Graphics object for Android, Desktop and iOS projects and a WebGraphics object for Web projects.

Your instinct might be to simply write the code for one and then copy it to the other projects, changing Graphics to WebGraphics for Web projects. This will of course work, but then you have to remember to do this copy/paste/change operation every time you update your code. That’s not ideal.

Graphics vs. WebGraphics

With Xojo, the code can be written in such a way as to automatically handle the difference between Graphics/WebGraphics. Most often your graphics methods will be called from something that provides a Graphics or WebGraphics object for you to draw into such as a Canvas control’s Paint event. From there your code will call your methods that do the drawing. The problem is that your methods can’t use a Graphics or a WebGraphics type as a parameter because Graphics is not going to work for your Web projects and WebGraphics doesn’t exist in any framework except the Web framework. Thus using it anywhere else will result in a compiler error.

Using a Variant

Getting around this limitation is, fortunately, quite easy. Instead of using Graphics or WebGraphics as a parameter type, you use Variant. A Variant can hold any type of data from Strings to Integers, to Graphics to WebGraphics and more.

Once your drawing method gets the Variant though, it can’t use it to draw. It can only use a Graphics or WebGraphics objects. The trick is to then copy it into a Graphics or WebGraphics class variable:

Var g As Graphics = context

or

Var g As WebGraphics = context

The problem you now face, as mentioned earlier, is that WebGraphics only exists in Web projects. That means you have to write your code in such a way that you will declare the variable g as a Graphics object in Android, Desktop and iOS projects and as a WebGraphics object in Web projects. This can be achieved via conditional compilation. This is a simple technique that tells the Xojo compiler to only compile code into your app if conditions you specify are met. In this case, if you’re targeting Desktop or Mobile, it should compile in the line that uses the Graphics type, and if you are targeting a Web app, the line that uses WebGraphics. To conditionally compile, you just need to add that conditional code around these two lines:

#If TargetDesktop Or TargetMobile Then
   Var g As Graphics = context
#EndIf

#If TargetWeb Then
   Var g As WebGraphics = context
#EndIf

Since a project must be only one of the above types, when you run or build your project, the appropriate line of code will be compiled in. From there, you now have a variable (g) of the right type can use this to draw whatever you like. For example, there are four identical example projects (one for each project type) that show off this technique. They can be found in the Xojo IDE by choosing File > New Project, clicking on Examples, choosing the Graphics folder in the list and then the Cross-Platform Drawing folder. The examples all draw a checkerboard that looks like this:

They all contain the an identical Checkerboard class that handles the drawing. This class has DrawBorder and DrawCheckers methods that both take a Variant as a parameter. In each project is a Canvas control whose Paint event calls these methods:

Var cb As New Checkerboard
cb.DrawBoard(g)
cb.DrawCheckers(g)

The full DrawBoard method looks like this:

#If TargetDesktop Or TargetMobile Then
  Var g As Graphics = context
#EndIf

#If TargetWeb Then
  Var g As WebGraphics = context
#EndIf 

Var boxSize As Integer = Min(g.Width/8, g.Height/8) 'The size of the box
'Draw the rows
For y As Integer = 0 To 7
  For x As Integer = 0 To 7
    'Switch colors for each box in the row
    If g.DrawingColor = Color.Black Then
      g.DrawingColor = Color.White
    Else
      g.DrawingColor = Color.Black
    End If
    'Draw a box
    g.FillRectangle(x * boxSize, y * boxSize, boxSize, boxSize)
  Next
  'Switch colors again for the beginning of the next row
  If g.DrawingColor = Color.Black Then
    g.DrawingColor = Color.White
  Else
    g.DrawingColor = Color.Black
  End If
Next

In the example projects, check out the DrawCheckers method as well. It uses the same technique. What is great about this is that this class can be copied into any Android, Desktop, iOS or Web project and it will indeed just work.

Checking Out the Examples

There are four example projects (one for each project type – Android, Desktop, iOS and Web) that demonstrate the technique explained here. You can find them in the Xojo IDE by choosing File > New Project, clicking on Examples, choosing the Graphics folder in the list and then the Cross-Platform Drawing folder.

Geoff Perlman is the Founder and CEO of Xojo. When he’s not leading the Xojo team he can be found playing drums in Austin, Texas and spending time with his family.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

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

Granular Control on DataSets

The ChartDataset subclasses add three new properties. Now you can choose to allow the interaction from the user (for example when clicking or taping on data points or over a displayed legend in the Chart), you can also choose what legends are visible at the top area of the Chart, as well as choosing to display a Popover when the user moves the mouse over a given rendered datapoint for the associated ChartDataset.

• AllowInteraction: When it is set to False, then the displayed legend for the ChartDataset doesn’t respond to interaction (that is enabling/disabling the associated data in the Chart) or raises the Pressed event for the Chart. Also, it doesn’t fire the Pressed event when the user clicks on any of the rendered data points in the Chart for that particular DataSet.
• IsLegendVisible: When it is set to False, the Legend for the associated ChartDataset is not displayed at the top area of the Chart (always that the Chart.HasLegend property is set to True). This allows a more granular control over the legends that are displayed, so you can have some of the rendered data sets with their legend displayed while others not.
• AllowPopover: When this property is set to False in the ChartDataset, then the Popover won’t be displayed when the user hovers the cursor over any of its rendered points in the Chart.

New Events for Chart on Desktop

Starting with Xojo 2024r4 you can decide how the Chart should draw the data points for any of the rendered ChartDatasets on Desktop. This is done by implementing the two new Event Handlers on the Chart instance:

• DrawPointAt(g As Graphics, x As Double, y As Double, data As ChartDataSet, index As Integer) As Boolean. This event receives from the “g” parameter the graphic context for the datapoint, so you can use any of the available methods and properties of the Graphics class to draw the datapoint. In order to know what datapoint and from what ChartDataset, these are given in the “index” and “data” parameters, respectively. Also, the “x” and “y” parameters receive the coordinates for the top-left corner of the data point to be drawn. These coordinates are relatives to the Chart control instance position. Returning True from this Event means that your code handled the datapoint drawing; otherwise the datapoint will be rendered as usual.
• DrawMouseOverPointAt(g As Graphics, x As Double, y As Double, data As ChartDataSet, index As Integer) As Boolean. This event behaves in the same way as the previous one, the only difference is that it will be raised when the user hovers the cursor over a given datapoint, so you have the chance to decide how to draw the highlighted version of the datapoint.

You can learn more about the Chart control in the Xojo Documentation at: https://documentation.xojo.com/api/user_interface/controls/chart.html#chart
You can learn more about the ChartDataset class (and subclasses) in the Xojo Documentation at: https://documentation.xojo.com/api/user_interface/charts/chartdataset.html#chartdataset

A big thank you for all of you providing feedback and suggestions about how to improve Charts on Xojo! All of these new additions are a direct response from request made from you, so we are happy to make it work the way you need to adhere even more to your needs!

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

The trick is to handle the data coming from any source with the right data structure, for example, an Array. This example uses a plain text file with several lines and columns separated by the Tab character as the source of the data.

In order to follow this tutorial, download the example project.

Getting the Data

As you can see in the example project, the text file has been added to the project using a Build > Copy Files Step (the file name is “Data.txt”), so it is copied to the Resources folder of the compiled app and available for both debugging and release builds.

Then, in the Pressed event of the Button1 control placed on the default Window1, we will access the contents of the file in order to store each of the lines in the Data Array of strings:

Var f As FolderItem = SpecialFolder.Resource("data.txt")
If f <> Nil And f.Exists Then
  Var tis As TextInputStream = TextInputStream.Open(f)
  Var s As String = tis.ReadAll
  data = s.ToArray(EndOfLine.macOS)
End If

PDFRenderer Subclass

The next step is to create a custom class that will implement the methods provided by the PDFTableDataSource Class Interface. We will name the class “PDFRenderer”. Then, from the Inspector Panel, click on the Interfaces button, check the PDFTableDataSource interface and confirm the selection.

Once done, the methods from the class interface will be automatically added to the class:

• AddNewRow
• Completed
• HeaderHeight
• MergeCellsForRow
• PaintCell
• PaintHeaderContent
• RowHeight

Over these we will add three more methods:

The class Constructor:

Public Sub Constructor(document As PDFDocument)
  // Simple constructor… just assign the received object
  // to the "Document" property
  
  Self.document = document
  proxy = New Picture(document.Graphics.Width, document.Graphics.Height)
End Sub

Assign the received PDFDocument instance to the document property. It also creates a graphics instance that will be used as a proxy for calculating the height of the processed text from the data (that won’t be necessary starting with Xojo 2024r4 where some PDFDocument bugs related with that are already fixed).

DrawTable:

This method is the one that will be called to start drawing the table. It will initialize some properties from the received Data (yeah, you can see a property named as “DrawingFromRowSet”, but I left that one on purpose because this project is based on the one dealing with the data coming from a RowSet, so you can see how similar all the process is):

Public Sub DrawTable(data() As String, headers() As String)
  // This is the method we call on the Class to draw
  // a table on a PDFDocument based on an Array of Strings
  
  If document <> Nil And data.LastIndex <> -1 Then
    
    // Assign the received Array to the "Data" property
    Self.data = data
    
    // Assign the received headers to the "Headers" property
    Self.Headers = Headers
    
    // Hey! We are going to create a table from an Array
    // so we use a Boolean property as a flag for that
    // (Yeah, we can do it using other techniques, but this
    // is easy enough for this purpose… while leave this
    // helper class "open" enough for drawing tables based on other
    // data sources).
    Self.DrawingFromRowSet = True
    
    // How many columns are we going to draw?
    // Well… as many as columns (TABs) in any of the Array items (for example, the first one).
    Var totalColumns As Integer = data(0).CountFields(Chr(9))
    
    // This is going to be the "drawable area" on the page
    // for the table = total page width less the left and right margins
    Var totalWidth As Double = document.Graphics.Width - 40 // 40 = 20 points left/right margins
    
    // Creating the PDFTable object here!
    Var table As New PDFTable
    
    // We want to repeat the headers on every page
    table.HasRepeatingHeader = True
    
    // Setting the column count for the table
    table.ColumnCount = totalColumns
    
    // …and the width for every column.
    table.ColumnWidths = CalculateColumnWidths(totalWidth, totalColumns)
    
    // The object from this class will be the responsible
    // of handling all the methods associated with the
    // PDFTableDataSouce Class Interface
    table.DataSource = Self
    
    // Setting the Top and Bottom margins for the drawing
    // of the table on every PDF page
    table.TopMargin = 20
    table.BottomMargin = 20
    
    // …and finally we instruct the PDFDocument object
    // to draw the table!
    document.AddTable(table, 20, 0)
    
    // Lastly, clearing the flag
    Self.DrawingFromRowSet = False
    
  End If
End Sub

CalculateColumnWidths Method

This one will calculate the widths for each column to be rendered in the final PDF document.

Protected Function CalculateColumnWidths(TotalWidth As Double, NumberOfColumns As Double) As String
  // Helper method to get a string for the column widths
  
  ColumnWidth = TotalWidth / NumberOfColumns
  Var s() As String
  
  For n As Integer = 0 To NumberOfColumns - 1
    s.Add(Str(ColumnWidth))
  Next
  
  Return String.FromArray(s, ",")
End Function

Class Properties

Because we need to track things like what the current row or column is to be rendered, the headers, etc., our class needs to add some properties:

• Protected Property ColumnWidth As Integer
• Public Property CurrentColumn As Integer
• Protected Property CurrentHeight As Integer
• Protected Property CurrentRow As Integer
• Protected Property data() As String
• Protected Property document As PDFDocument
• Protected Property DrawingFromRowSet As Boolean
• Public Property Headers() As String
• Protected Property LastRow As Integer
• Protected Property proxy As Picture

PDFTableDataSouce Methods

Time to visit the methods added by the PDFTableDataSouce class interface. These are the methods called by the PDFTable object each time it needs to retrieve a piece of information during the rendering on the PDFDocument, as for example if it needs to add a new row, the height for the Header or the current row… and the painting of the row itself!

AddNewRow Method

This one is called by the PDFTable object in order to know if it needs to render a new row in the table:

Protected Function AddNewRow(rowCount As Integer) As Boolean
  // Part of the PDFTableDataSource interface.
  
  If DrawingFromRowSet And data.LastIndex <> -1 then
    
    // We are going to draw as many rows as rows are in the
    // "data" array
    Return rowCount <= data.LastIndex
    
  End If
End Function

Completed method

This is the method invoked by the PDFTable object when it finished drawing the table, so it is your chance to take additional operations, for example, numbering every page of the PDFDocument (we can’t anticipate that before drawing the table itself):

Protected Sub Completed(x As Double, y As Double)
  // Part of the PDFTableDataSource interface.
  
  // This method is called once the table has been drawed
  // so let's "print" the page number on every page
  // of the PDF Document
  
  Static pageNumber As String = "Page: "
  
  If document <> Nil Then
    Var g As Graphics = document.Graphics
    
    For n As Integer = 1 To document.PageCount
      document.CurrentPage = n
      g.DrawText(pageNumber + Str(n), g.Width - g.TextWidth(pageNumber + Str(n)) - 20, g.Height - g.FontAscent)
    Next
    
  End If
End Sub

HeaderHeight Method

This is the method called by the PDFTable object the returns the height we want to use for rendering the header on the first page and, optionally, on every new page required (added to the document) by rendering the table. In this case we will return a fixed value:

Protected Function HeaderHeight() As Double
  // Part of the PDFTableDataSource interface.
  
  // Returning a fixed height value for the headers
  Return 20
End Function

MergeCellsForRow Method

The PDFTableDataSouce class interface also has the ability to merge cells in the current row, so you can create more elaborated tables. We are not going to use that feature in this example project so it will be empty, no code to be executed.

PaintHeaderContent Method

This is the method in charge of rendering the header for the table, so it receives its own Graphic context with the provided height from the HeaderHeight method and the width calculated from the total of columns (headers) needed to be rendered:

Protected Sub PaintHeaderContent(g As Graphics, column As Integer)
  // Part of the PDFTableDataSource interface.
  
  // Painting the headers for the table
  If column <= Self.Headers.LastIndex Then
    
    Var s As String = headers(column)
    g.DrawingColor = Color.Black
    g.FillRectangle(0, 0, g.Width, g.Height)
    g.DrawingColor = Color.White
    g.DrawText(s, g.Width / 2 - g.TextWidth(headers(column)) / 2, g.Height / 2 + g.FontAscent / 2)
    
  End If
End Sub

RowHeight Method

As the class interface provides a method so we can provide the height for the header, we also have a RowHeight method that the PDFTable object will call before it calls the method in charge of doing the row drawing itself. That way we can have rows of different height based on the height of the own text to be rendered!

Protected Function RowHeight() As Double
  // Part of the PDFTableDataSource interface.
  
  // We need to calculate the height for every row in the Table
  // so let's calculate that based on the taller of the texts (columns)
  // based on text wrapping
  
  If CurrentRow <= data.LastIndex Then
    CurrentHeight = 0
    Var s() As String = data(CurrentRow).Split(Chr(9))
    Var g As Graphics = proxy.Graphics
    Var itemHeight As Integer
    For Each item As String In s
      itemHeight = g.TextHeight(item, ColumnWidth - 40)
      If itemHeight > CurrentHeight Then
        CurrentHeight = itemHeight
      End If
    Next
    
    CurrentRow = CurrentRow  + 1 
    
    Return CurrentHeight + 20
  End If
End Function

PaintCell Method

Lastly, this is the method called by the PDFTable object when it is time to render a given cell for the current row in the table. It receives as parameters both a graphic context with the width and height already suited for the data to be rendered, and also the row and column values so you can get the appropriate data for a given cell from the data source:

Protected Sub PaintCell(g As Graphics, row As Integer, column As Integer)
  // Part of the PDFTableDataSource interface.
  
  // Here is where we really do the drawing
  // the received "g" parameter is for a particula table cell
  // based on the row / column parameters
  // so the origin for X/Y coordinates is at 0,0
  
  If DrawingFromRowSet And data.LastIndex >= row Then
    // Drawing the outer rectangle for the cell
    g.DrawRectangle(0, 0, g.Width, g.Height)
    
    // retrieving the text to be drawn from the Array,
    // using the row and column parameters for that.
    Var s As String = data(row).NthField(Chr(9), column + 1)
    
    // Centering vertically the text on the table cell
    // while the X offset is fixed at 5 points.
    g.DrawText(s, 5, g.Height / 2 + g.FontAscent / 2, ColumnWidth - 20)
    
    // Let's keep track of the last row drawed
    LastRow = row
    
  End If
End Sub

Time to push the Start button!

Everything is setup now in our PDFRenderer class, so let’s get back to the Pressed event of the Button1 control on the default Window1 window. You will remember from the beginning of this tutorial that this is the place where we retrieved the data from the text file. So let’s add the code to create a PDFDocument instance, a new PDFRenderer instance and do the rendering of the table itself from the data:

If data.LastIndex <> -1 Then
  
  // Creating a new PDFDocument Instance
  Var d As New PDFDocument
  
  // Creating the PDFTable renderer helper object (we pass the PDFDocument object to it in the Constructor)
  Var PDFRender As New PDFRenderer(d)
  
  // These will be the headers drawed in the Table
  Var headers() As String = Array("Name", "Surname", "Address", "City", "Email")
  
  // And let's instruct the PDFTable renderer helper to draw the table
  // based in the SQLite database rowset we got in the previous step
  PDFRender.DrawTable(data, headers)
  
  // …and save the resulting PDF File to the Desktop
  Var out As FolderItem = SpecialFolder.Desktop.Child("TableFromTextFile.pdf")
  
  If out <> Nil Then
    d.Save(out)
    out.Open
  End If
End If

Conclusion

As you see, and if this tutorial is compared with PDFTable from a RowSet, creating a PDFTable doesn’t differ too much when using a data source other than a RowSet. All you need, basically, is to keep track of the current row, know if you need to render more rows and a base data structure that can be used to retrieve the data to be rendered in a given Row/Column.

As always, you can learn more about other features provided by PDFDocument in the Xojo Documentation.

Happy Coding!

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

If there’s something you need to do in code when the orientation changes, you’re in luck. The MobileScreen class has an OrientationChanged event. When this event fires, that means the user has rotated their device and the orientation has changed. This is where your code would go should you need to respond to an orientation change.

Note: If you need to know when the screen has changed in size, that’s what the Resized event is for (at least on iOS – it’s not yet supported for Android).

What might not be immediately intuitive or obvious is that rotating your device does not automatically mean the orientation has changed. Consider the following example project that displays the Resized and OrientationChanged events in a table when they occur. While this is on iOS, it works the same way (without the Resized event) on Android. The device is starting in portrait mode.

We will focus on just the OrientationChanged events for now. It gets an initial OrientationChanged event. Then the user rotates their phone clockwise enough that the orientation is changed from portrait to landscape.

You can see that another OrientationChanged event has fired as you’d expect. Next the user rotates the phone clockwise again.

Now the phone is upside down. Notice, however, the orientation from the perspective of the OS has not changed. The layout is still in landscape orientation. This is not a bug. The device does not support portrait mode when the device is turned upside down. Thus the layout is still in landscape orientation and thus no OrientationChanged event has fired because there has been no orientation change.

Next the user rotates the phone clockwise yet again.

You might think that an OrientationChanged event would fire, but it doesn’t. Why not? Because as far as the OS is concerned, the layout is still in landscape orientation. It has not changed its orientation. Finally, the user rotates the device clockwise once last time.

This time the orientation has changed from landscape to portrait and thus the OrientationChanged event fired. Given that the initial OrientationChanged event fired when the app launched, out of the four 90 degree clockwise rotations, only two orientation changes occurred and thus only two OrientationChanged events fired.

This is one of those cases where what is initially intuitive turns out to be wrong until you look more closely at what is really going on.

Geoff Perlman is the Founder and CEO of Xojo. When he’s not leading the Xojo team he can be found playing drums in Austin, Texas and spending time with his family.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube