Until now, the only way to work with named iOSLayoutConstraint instances was by assigning a name in the Inspector Panel. This allowed you to reference them later in code, for example, to deactivate, reactivate, or remove them from a MobileScreen or MobileUIControl. Very handy!
But what about iOSLayoutConstraint instances created in code? Starting with Xojo 2025r2, that’s been improved! Keep reading to learn how.
Of course, there have always been ways to manage iOSLayoutConstraint instances created in code (for example, by storing references to them) so you could interact with them just like the named constraints created at design time. But with Xojo 2025r2, we’ve made that even easier.
The MobileScreen.AddConstraint and MobileUIControl.AddConstraint methods now include an optional name parameter. This means you can assign a name to constraints added in code and later activate, deactivate, or remove them by name, just like design-time constraints!
Of course, you can’t assign the same name to multiple constraint instances on the same screen or UI control. If you try to do so, an UnsupportedOperationException will be raised.
We’ve also overloaded the MobileScreen.RemoveConstraint method to accept a String parameter, allowing you to remove a named constraint directly. No need to keep track of iOSLayoutConstraint instances using property references or other custom methods.
All in all, starting with Xojo 2025r2, you no longer need to implement your own logic to manage constraint instances. This makes it much easier to build responsive, polished UIs that adapt well across platforms and device orientations.
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.