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

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

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

It’s that simple!

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

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

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.

There are two possible solutions:

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

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

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

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

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

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

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

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

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

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

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

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

Development or Distribution

There are two types of provisioning profiles: Development and Distribution. Development provisioning profiles are for builds sent to the AppStore Connect service that are not meant to be available on the Mac App Store. Development profiles allow apps to be tested by the eligible users associated with that app in TestFlight. For Development provisioning profiles, set the Stage Code value (under Build Settings > Shared) to “Development”, “Alpha” or “Beta”.

On the other hand, Distribution provisioning profiles for macOS are required for builds meant to be publicly available on the Mac App Store once approved by the App Store Reviewing Process, they are also available for TestFlight. For Distribution provisioning profiles, make sure the Stage Code value is set to “Final” under Build Settings > Shared.

Creating Provisioning Profiles

Regardless of which type of provisioning profile you are creating, you’ll need to do it from the Apple Developer website (using your paid developer membership).

In this example we will create a Distribution provisioning profile.

• Login into the Apple Developer Website.
• Select the Profiles option found under the “Certificates, IDs & Profiles” section.
• Click on the “+” icon found next to the “Profiles” header.
• Next, select the “Mac AppStore Connect” option under the Distribution section, and click on the “Continue” button.

• Select the “Mac” option under the Profile Type section, and select the App ID value from those available in the associated Popup menu. Make sure that the chosen one (without the value between parentheses) matches the one entered under Build Settings > macOS > Bundle Identifier. Then, click on the “Continue” button.

For example the selected one in the screenshot (that, is BW7PU32485.com.aprendexojo.vcardtoqr), matches the one used as the Bundle Identifier for the app in the Xojo IDE (com.aprendexojo.vcardtoqr).

• Next, select the “Distribution” Certificate to be included in the generated provisioning profile. The one selected must be the same one entered in the Developer ID field when building the App from the Xojo IDE (Build Settings > macOS > Sign). For example, I’m going to use the value (without the quotes) “Apple Distribution: Francisco Javier Rodriguez Menendez (BW7PU32485)” as the Developer ID value in Xojo, so I’m selecting that same Distribution certificate here. Next, click the “Continue” button.

• Name the provisioning profile using a significative name, so you can easily distinguish it later among the many available ones. Next, click the “Generate” button so the provisioning profile is generated and downloaded to your local Mac disk (probably in the Downloads folder).
• The downloaded provisioning profile will have the name you entered in the previous step. Select it and use the Finder options to rename it as “embedded.provisionprofile”.

Adding the Provisioning Profile to the Project

macOS provisioning profiles need to be added to the Contents folder on the app bundle, and that is easy to do from the Xojo IDE!

• Open your project in the Xojo IDE and add a new Copy Files build step under Build Settings > MacOS.
• Add the “embedded.provisionprofile” file to the just added CopyFile build step.
• Select the “Contents Folder” option from the Destination popup menu in the associated Inspector Panel for the Copy Files build step.
• Select the “Release” option from the “Applies To” popup menu in the associated Inspector Panel for the Copy Files build step, so only this file is copied to the Contents folder when the app is built as a standalone app.

Adding New Entries to the Entitlements File

In order for the provisioning profile to be recognized by TestFlight when the app package is sent to AppStore Connect, we need to add a couple more entries to the Entitlements file (see “Uploading macOS Builds to App Store Connect” for more details on the Entitlements file).

• Full Application Identifier. Use the “com.apple.application-identifier” as the Key for the entry. The value should be the Application Bundle Identifier (in our example com.aprendexojo.vcardtoqr) prefixed with the Team ID value of the Certificate we used both for signing our app and the provisioning profile itself. In this example it is BW7PU32485, making the string value for this key BW7PU32485.com.aprendexojo.vcardtoqr
• Team ID. Use “com.apple.developer.team-identifier” as the Key for the entry, while the value (following with our example) is just the Team ID from the certificate: BW7PU32485

All in all, the final Entitlements file will look like this:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>com.apple.security.app-sandbox</key>
	<true/>
	<key>com.apple.security.files.user-selected.read-write</key>
	<true/>
	<key>com.apple.application-identifier</key>
	<string>BW7PU32485.com.aprendexojo.vcardtoqr</string>
	<key>com.apple.developer.team-identifier</key>
	<string>BW7PU32485</string>
</dict>
</plist>

That is: Sandboxing enabled, plus the ability for the app to read/write the selected user files, plus the two new entries required so the provisioning profile is recognized by TestFlight when the package is submitted to the AppStore Connect.

Save the changes to the modified Entitlements file (in our example named as “myEntitlements.entitlements”).

Resign, Re-Package, and Uploading

If you followed the two previous blog posts in this series, you may have already guessed the next step! Yep, because we modified our “myEntitlements.entitlements” file, we need to re-sign the app bundle, package it and submit it to AppStore Connect.

So for re-signing, type the following in a new Terminal window:

codesign --force --timestamp --entitlements path-to-your-myEntitlements.entitlements-file  -s "Apple Distribution: whatever-name-you-use (BZXXXXXXX)" path-to-the-bundle-of-the-compiled-app.app

In order to create a package from the bundle, issue this command from the Terminal:

productbuild --sign "3rd Party Mac Developer Installer: whatever-name-you-use (BZXXXXXXX)"  --component path-to-the-bundle-of-the-compiled-app.app  /Applications path-to-the-generated-package-file.pkg

And in order to upload the package to the AppStore Connect, type the following command in a Terminal window:

xcrun altool  --upload-package path-to-the-package-file.pkg -u your-apple-developer-login-id-goes-here -p "your-app-specific-password-goes-here" --type osx -apple-id "6111111111" --bundle-id "com.yourcomany.yourIdentifier" --bundle-short-version-string "current-short-value" --bundle-version "current-version-value"

If everything went OK, open your Internet Browser and go to http://appstoreconnect.apple.com, select your app record from the Apps section and click on the TestFlight tab. You should be able to see the just submitted build ready for testing!

In Summary

As you see, adding provisioning profiles to macOS apps sent to the AppStore Connect website to be tested by in TestFlight, requires a bit of previous preparation for the provisioning profile generation itself, copying the file to the project using a Copy Files build step and, then, adding a couple more entries to the Entitlements file.

Once everything this is done, your testers will be able to use the TestFlight app to download and test your builds and report feedback, crash reports and other information about it!

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

More in this series on distributing Mac apps:

• Sandboxing, Hardened Runtime and Notarization arrives to the Xojo IDE
• macOS Apps: From Sandboxing to Notarization, The Basics
• Uploading macOS Builds to App Store Connect
• Provisioning Profiles for macOS Apps

There is a Xojo-made tool out there that can simplify the process, and if that’s your route, check out AppWrapper from Ohanaware. But if you are the kind of developer that enjoys “how things work under the hood”, then follow these steps to do it manually from the command line (or convert these instructions into Xojo Scripts that can be executed as part of the build process itself from the Xojo project).

There are some requirements for all of this to work, but you took care of them already if you already followed our previous post about how to apply Sandboxing, Hardened Runtime and Notarize manually to your Xojo macOS builds. Perhaps, the most important one is that this requires a paid Apple Developer Program membership (around US $99/yr). Additionally, Xcode needs to be installed on your Mac in order to use its included altool and productbuild command line tools. Create an app-specific password in order to execute the notarytool command line tool, which is also required when using the altool command line. You likely created one already for the notarytool command line tool which you can use as the password required by the altool command line tool.

If distributing your macOS apps from your website, these need to be signed using the “Apple Development” Certificate, but if you are compiling a macOS app for distribution through the Mac App Store, you need to sign it using the “Apple Distribution” certificate. So make sure to fill-in the macOS > Signing > Developer ID field properly.

Also important, in order to upload the app to App Store Connect, you need to create a package file from the app bundle, and that package file (.pkg) needs to be signed using the “3rd Party Mac Developer Installer”. Make sure you have this certificate installed in your Mac Keychain.

First things … First

Before you can upload you .pkg file to the App Store Connect website, there are some things you need to take care of that are required by Apple for apps to be distributed through the Mac App Store.

1. The first thing is to register an App ID (or Identifier) in the Apple Developer Portal. When doing it, make sure you are creating an explicit Identifier instead of a wildcard one. Also very important, make sure that the identifier (in the reversed DNS form) is the same one you are using in the field macOS > Build > Bundle Identifier of your Xojo project. If they don’t match, then you can expect errors throughout the process.
2. The second thing is to create a new record for the App itself in the App Store Connect website. This is the place where you need to provide all the information requested by Apple for two main things: 1. what will be available as the app information when the users reach your app in the Mac App Store (for example product description, price, images, etc.), and, 2. what is for internal and compliance use. All in all, make sure you create a new macOS app record and go through all the available sections to fill in the requested information.

Once these two steps are completed, we can focus on the command line itself to create the .pkg file and upload it manually (optionally, it is possible to use the Transporter app to select the .pkg file and upload it).

Sing, sing, sing … the re-signing song!

When building the macOS app from the Xojo IDE, it will be correctly signed based on the settings selected in the Build Settings > Sign section. But because of the way Apple requires some entries to be formatted (specifically those for the CFBundleShortVersionString and CFBundleVersion keys), and the fact that it also requires the LSApplicationCategoryType key to be present in the Plist file with the associated value (the app category value among those you can find here), we need to manually edit the generated Info.Plist file for the compiled app.

Yeah, sure we can create an additional text file named Info.Plist file with the appropriate/expected keys and values and drop such file in the IDE navigator for our project so this information gets added/modified, as for example this one:

<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "https://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>CFBundleShortVersionString</key>
	<string>1.0.0</string>
	<key>CFBundleVersion</key>
	<string>1.0.0</string>
	<key>LSApplicationCategoryType</key>
	<string>public.app-category.business</string>
</dict>
</plist>

The bad news is that the value for the CFBundleVersion key will not be replaced with the one from our Info.Plist file.

What’s the downside of manually editing the Info.Plist file for the already compiled app? Well, as soon you make a change and save it, the app bundle signature will be invalidated. But no fear! We know how to do it already, right? If not, I suggest you to take a look to the blog post about Sandboxing, Hardened Runtime and Notarization for macOS apps that I mentioned earlier.

Go ahead, select your compiled app in the Finder, click on its icon and select the option “Show package Contents” from the contextual menu. This action will show the “inner files” of the bundle that composes your app. Inside the Contents folder you will see the Info.Plist file. Click on it and select the option from the contextual menu allowing you to edit it with the text editor of your preference (mine is to use BBEdit from BareBones Software).

• Locate the CFBundleVersion key entry and change its string value so it doesn’t have more than three numbers separated by the dot character (as shown in the previous Plist example file).
• Locate the CFBundleShortVersionString and change its string to make sure it has three version numbers separated by the dot character.

Of course for both of the previous keys, make sure these match your expected version numbers for the app! In the example I used 1.0.0 as it’s typical for the initial release of an app.

Next, add the expected LSApplicationCategoryType key with the value that better fits your app among those available at the Apple Documentation website. In the previous Plist file example I’m using the one for the Business category:

	<key>LSApplicationCategoryType</key>
	<string>public.app-category.business</string>

Save the changes to our modified Info.Plist file. Now it is time to sign it again!

What about the Entitlements?

Heh… wait! Because we need to re-sign our app bundle again, we also need to attach the expected entitlements to it! That means at least one very-important-and-required entitlement: enabling Sandboxing, which needs to be done to any app sent for distribution through the Mac App Store.

While Xojo 2024r4+ is able to do it automatically when building the app, now we also need to do it manually. That means creating our own .entitlements file that will be used when re-signing the app. For example, for a very typical (and bare-bones) app that only needs to read and write files it would look like this:

<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "https://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>com.apple.security.app-sandbox</key>
	<true/>
	<key>com.apple.security.files.user-selected.read-write</key>
	<true/>
</dict>
</plist>

Save it as “myEntitlements.entitlements” to your Mac drive. Of course, if you app requires more entitlements, go ahead and add them to the previous “template” .entitlements file.

We now have our modified .Plist file and the required .Entitlements file… so we have everything we need to re-sign the app bundle again!

Open a Terminal window and type the following command:

codesign --force --timestamp --entitlements path-to-your-myEntitlements.entitlements-file  -s "Apple Distribution: whatever-name-you-use (BZXXXXXXX)" path-to-the-bundle-of-the-compiled-app.app

Look how we are using the reference to the entitlements file, and the “Apple Distribution” certificate instead of the “Apple Development” certificate.

Packaging Acme

So far so good. We have our app bundle signed again, so we are ready now to create a .pkg file from it! All you need to do is to type the following command from a Terminal window:

productbuild --sign "3rd Party Mac Developer Installer: whatever-name-you-use (BZXXXXXXX)"  --component path-to-the-bundle-of-the-compiled-app.app  /Applications path-to-the-generated-package-file.pkg

As you can see, we are using the “3rd Party Mac Developer Installer” certificate in order to create the package file.

Uploading it!

With the package file already created, we now have all we need to upload it to the App Store Connect website. At this point you can follow two paths. The first one is to use the Transporter App that you can download from the Mac App Store itself. In that case:

• Open the Transporter app.
• Click on the “+” icon. That action will bring a dialog where you can select the previously created .pkg file.
• Once it is added, Transporter will make some early checks on the package contents. If everything goes OK, you should see something like this:

The interesting thing about using Transporter is that you can select the “Verify” option from the associated contextual menu (the one with the three dots icon). That action will start some more deeply checking on the package (and its contents) so you can get some early information about things that need to be fixed prior uploading it to the App Store Connect Website. For example, this error generated when the bundle version is duplicated:

The second option involves using the aforementioned altool command line to automatically upload the package to the App Store Connect website. If you choose this path, all you need to do is to execute the following command from a Terminal window:

xcrun altool  --upload-package path-to-the-package-file.pkg -u your-apple-developer-login-id-goes-here -p "your-app-specific-password-goes-here" --type osx -apple-id "6111111111" --bundle-id "com.yourcomany.yourIdentifier" --bundle-short-version-string "1.0.0" --bundle-version "1.0.0"     

Some considerations about the provided options/values for this command:

• -u: This is the login name you use when accessing the Apple Developer website
• -p: This is the app-specific password you created from scratch following the steps provided in the aforementioned blog post.
• -apple-id: This is the numeric value you can find under General > App Information at the appstoreconnect.apple.com website for the record created for this app:

This information can also be retrieved using:

xcrun altool --list-apps -u your-apple-developer-login-id-goes-here -p "your-app-specific-password-goes-here" --output-format json

• –bundle-id: Make sure to provide the same value as the one used when creating the Identifier for the App and, thus, the same one used under Build Settings > macOS > Build > Build Identifier field in your Xojo project.
• –bundle-short-version-string: Make sure it’s the same value used for the CFBundleShortVersionString key in the .Plist file.
• –bundle-version: Make sure to provide the same value as the one used for the CFBundleVersion key in the .Plist file.

Once the command is executed, your package file will be uploaded to the App Store Connect website and, once completed, eligible as a new Build to be added to your app record so you can send it to review as part of the Apple reviewing process.

In Summary

There are several details to take care of, but Xojo has simplified the process of covering the “last mile” of sending you compiled app for review at the App Store Connect website.

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

More in this series on distributing Mac apps:

• Sandboxing, Hardened Runtime and Notarization arrives to the Xojo IDE
• macOS Apps: From Sandboxing to Notarization, The Basics
• Uploading macOS Builds to App Store Connect
• Provisioning Profiles for macOS Apps

Once you add this ability to your macOS apps, they will fit better when compared with other apps running alongside them. Even better, you don’t need to write additional code in order to handle these additional menu options.

Create a new Desktop project and add a new Module to it called “macOSExtra”. Then add a new method to it using the following signature, make sure to set the Scope of the property to Global:

AddMacOSWindowMenu(item as DesktopMenuItem)

As you can see, this method expects to receive a DesktopMenuItem instance; but before we write a line of code for this method, select the MainMenuBar item in the project Navigator.

The previous action will bring up the Menu Editor. Click on the toolbar button in charge of adding a new first level menu item to the menu bar:

Next, with the new menu item selected in the Navigator, change the following properties in the associated Inspector Panel:

• Name: WindowMenu
• Text: Window

Now, let’s go back to the AddMacOSWindowMenu method in the “macOSEXtra” module, type the following code in the associated Code Editor:

// This code will be only executed when compiling the project
// for the macOS target

#if TargetMacOS then
  
  // We declare the function allowing us to get the reference to a class
  // from the macOS framework (Foundation, in this case), from the parameter passed
  // to it as a String (the class name we want to get the reference to).
  // You can get additional information about this from the Apple Documentation at: https://developer.apple.com/documentation/foundation/1395135-nsclassfromstring?language=objc
  Declare Function NSClassFromString Lib "Foundation" ( name As CFStringRef) As Ptr
  Var theClass As Ptr = NSClassFromString("NSApplication")
  
  // Now that we have the reference to the class
  // we will use it to call the shared method / selector from the NSApplication
  // class in charge or returning a reference to the running app (that is "our" app in this case).
  // You can get additional information about this from the Apple Documentation at:
https://developer.apple.com/documentation/appkit/nsapplication/shared?language=objc
  
  Declare Function GetSharedApplication Lib "AppKit" Selector "sharedApplication" (Application As ptr) As Ptr
  Var theApp As Ptr = GetSharedApplication(theClass)
  
  // Now that we have a reference to the app object, we need to get a reference to the "submenu" hanging from the menu instance received as parameter by the method. For that
  // we need to call the method / selector "submenu" passing along the underlying native
  // menu object retrieved via the "Handle" property from DesktopMenuItem.
  
  Declare Function GetSubmenu Lib "AppKit" Selector "submenu" (menuReference As Ptr) As Ptr
  Var subMenu As Ptr = GetSubmenu(item.Handle)
  
  // The last step is to assign the previous reference to the window property from the app reference.
  // You can get additional information about this from the Apple Documentation at: https://developer.apple.com/documentation/appkit/nsapplication/windowsmenu?language=objc
  
  Declare Sub setWindowMenu Lib "AppKit" selector "setWindowsMenu:" ( appReference As Ptr, menuReference As Ptr)
  setWindowMenu(theApp, subMenu)
  
#EndIf

Testing it!

In order to see how this new method works, select the App item under the IDE Navigator and add the Opening event. Then, type the following line of code in the associated Code Editor:

AddMacOSWindowMenu(WindowMenu)

Run the app and click on the Window item in the main menu bar. You should see that the operating system has added several menu options, similar to the ones displayed in this screenshot (they will vary depending the macOS version the app is running on):

Choose any of the options added and you will see how macOS handles them, without the need to write a line of code in you Xojo project to do it.

Localizing the Window Menu

At this point, the Window menu with the added menu options will look great, but if your app is localized to other languages, then it will be a bit odd to read “Window” for the menu (as well as the English text in the added menu items). To improve this experience, let’s localize the WindowMenu item too!

Let’s add a new Constant to the “macOSExtra” Module and name it “kWindowName” setting its default value to “Window” and switching on the “Localized” field in the Inspector Panel:

Then, use the associated Constant Editor to add new entries (in as many as languages you support). In this case we will just add the entries to support both English and Spanish:

Next, select the WindowMenu item hanging from the MainMenuBar item in the Navigator, and change the value of the Text property to use the new constant:

Change the macOS Settings > General > Idiom and Region so the Spanish language is the main language. Then run the Xojo project again from the IDE and you will see how the “Window” menu entry now reads “Ventana”. Moreover, macOS will add the right localizations for the added menu items so they are in Spanish too.

In Brief

As you have seen, using just a few Declares we have been able to add the expected options for the Window menu to our macOS apps, without the need to write the code in charge of handling them! This doesn’t just mean more options for your users, it also means your Xojo apps will look and feel better when running on macOS.

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 fact, Apple recommends to Notarize the software even if you are going to distribute it from your own website, outside of the Mac App Store. But, don’t be scared! Currently there are good third parties options available that ease the path, like App Wrapper from Ohanaware, or some OpenSource options as for example Xojo2DMG; and through this article you will see how to enable Sandboxing, runtime hardening and even Notarizing on a simple example app. Of course, this will touch only the basics and it is up to you to read the related Apple Documentation to add the entries, both the Entitlements and additional keys/values in the app Info.plist file, required by the purposes of your particular app, for example file access, camera or mic access, network access, etc.

A Bit of Common Ground

At this point, your head may be spinning if you are unfamiliar with these app security terms; so, what do Sandbox, hardened runtime and Notarizing mean when they are applied to macOS apps?

Sandboxing

When a macOS app is sandboxed, that means that macOS will create an exclusive container for everything related to the app the first time it is launched. This is what happens when installing an iOS app, too! Such a container will have its own structure to access things like documents, pictures, downloads, etc. Think about it as the own private execution space for the app:

Of course, there are entitlements waiting for you so your sandboxed app can access the files created by other apps (including the Desktop, Downloads, Movies, Music and Picture folders), among other things.

Hardened Runtime

When enabled for your macOS app, hardened runtime adds an extra layer of protection to the running code itself. For example, it prevents certain classes of exploits, like code injection, dynamically linked library (DLL) hijacking, and process memory space tampering. This kind of protection is also enhanced by the System Integrity Protection (SIP).

Notarization

In brief, this is a third layer of confidence for the potential users of your macOS app. When the app is notarized, that ensures to the user that the Developer ID-signed software you distribute has been checked by Apple for malicious components. This is not related with the Apple Review process of your app when it is submitted to the Mac App Store, it’s related to the macOS Gatekeeper technology. So, when a Notarized app is downloaded from Internet, for example, Gatekeeper will use the notarization ticket attached to your app/DMG file to provide more meaningful information about the origin of the app, including if it is safe for the user to open it.

Preparation

In order to follow this article, you will need:

• Xojo. Download it for macOS if you have not done yet.
• macOS 11.3 or later.
• Xcode 13 or later. Run it at least one time and make sure that all its required components and SDKs are installed.
• Apple Developer ID. This needs to be a paid Apple Developer membership. Also, make sure you have your Developer certificates installed in the Mac.
• A working Internet connection.

With all of this in place, open Xojo to create a macOS Desktop project and do some basic layout in the by default window. It is not required to add any functionality to keep the focus in the task at hand. Then, use Build Settings > macOS > Mac App Name to give an appropriate name to the built application (for this example I named it “SandboxedApp”).

Lastly, save the project (for example into the Documents folder) and click the Build button to build the app! It is not required at this point to assign the Developer ID in the Build Settings > macOS > Sign section, because we are going to sign it (again) in the next steps.

Creating the Entitlements File

The entitlements file is pretty similar to the Info.plist file you probably already know that is in charge of storing the required keys and values for the app to properly work. Both of these are in XML format, and the only difference is that while the Info.plist file is created for you by Xojo, the Entitlements file needs to be, currently, manually created for you.

So, open your text editor of choice (there a lot of there out there, both free and paid ones; personally I tend to use BBEdit from BareBones Software). Add the following lines to the text document and save it with the name “Entitlements.plist” (if you keep it next to the saved built macOS app, the better). This is the file where you will probably want to add more entitlement entries as your app requires them:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist SYSTEM "file://localhost/System/Library/DTDs/PropertyList.dtd">
<plist version="0.9">
<dict>
  <key>com.apple.security.app-sandbox</key>
  <true/>
</dict>
</plist>

Sandbox Your App

With the compiled app and the entitlements file in place, open the Terminal app and type the following command and press the return key:

> codesign --force --deep --timestamp --entitlements <path-to-your-entitlements.plist-file> -s "Developer ID Application: <your-full-developer-name (including-the-team-id)>" <path-to-the-bundle-of-your-app>

Once executed, run the “SandboxedApp”, open the Activity Monitor app and make sure that the Sandbox option is enabled under the View > Columns options. Then, use the search box of the main window to filter the displayed processes so it only displays your app. Take a look to the value under the Sandbox column and you will see that the app is now Sandboxed, and the Container for it has been created under the Library/Containers path. Quit the app when you are done.

Hardened Runtime

With our app already sandboxed, let’s look how to add the hardened option to it. Once again, type the following command in the Terminal prompt:

> codesign --force --deep --options runtime --timestamp --entitlements <path-to-your-entitlements.plist-file> -s "Developer ID Application: <your-full-developer-name (including-the-team-id)>" <path-to-the-bundle-of-your-app>

As you can see, it doesn’t vary much from the previous command. All it adds is the “–options runtime” text in charge of enabling the runtime hardening. Also, as you might guess, using this command will enable the Sandboxing of the app and also the runtime hardening, at all once.

Do you want to check if it worked? Well, type the following command at the Terminal prompt:

> codesign --display --verbose <path-to-the-bundle-of-your-app>

It will produce an output similar to this one:

Executable=<path-to-the-executable>
Identifier=com.xojo.sandboxedapp
Format=app bundle with Mach-O universal (x86_64 arm64)
CodeDirectory v=20500 size=43297 flags=0x10000(runtime) hashes=1342+7 location=embedded
Signature size=9100
Timestamp=13 Aug 2024 at 12:51:28 PM
Info.plist entries=15
TeamIdentifier=************
Runtime Version=11.1.0
Sealed Resources version=2 rules=13 files=4
Internal requirements count=1 size=184

It is the “flags=0x1000(runtime)” which shows that, in fact, the app runtime is hardened. Congrats!

Notarizing the App

This is the final step, but is going to require an extra step from your side. Because the notarytool command line tool, used for notarizing the app, is going to require the ID and password from your Apple ID account, plus the fact that it uses 2FA authentication, it is very convenient to create an app specific password for it.

Creating an App-Specific Password

In order to create the password used by the notarytool process, follow this steps:

1. Sign in to appleid.apple.com
2. In the Sign-in and Security section, select the App-Specific Passwords option:

3. The previous action will bring a new dialog displaying all the app-specific passwords already created. Click the “+” button to add a new one:

4. Type a meaningful name for as the “Title” or description for your new password in the presented dialog (notarytool could be a good one):

5. Once you click the Create button it is possible that you will be asked to authenticate again using your Apple ID. Once done, a new dialog will present the generated password to you. Copy it and write it down (or paste it) into a safe place, because we are going to need it in the next step.

Adding the notarytool specific password to the Keychain

Because this app-specific password is going to be used by the notarytool command line tool, it would be very convenient to have it stored in the macOS Keychain. To do so, type the following command at the Terminal prompt, and press the Return key:

> xcrun notarytool store-credentials "notarytool-password" --apple-id "<your-apple-ID>" --team-id <your-developer-team-id> --password <the-password-copied-from-the-previous-step>

Once executed, you will be able to see the password added to the Keychain app under the name of “notarytool-password”:

Creating a Zip file for your app

The notarization process is handled by the Apple notary service running in the Internet, what means that notarytool needs to send (upload) the bundle of your app in an appropriate format. There are two options: as a DMG file (that needs to be signed before submitting), or as a zipped file, what is even faster and easier (Trivia: Did you know how easy it is to create Zip files in Xojo code?)

So, in order to upload our app for notarization, we need to create a Zip file first. Once again, it is time to type a new command at the Terminal prompt:

> /usr/bin/ditto -c -k --keepParent <path-to-app-bundle> <path-to-generated-zip-file/file-name.zip>

Uploading the app for Notarization

With our Zip file in place, we now have all the pieces to send it to the notarization process. The time spent by that process may (and will) vary depending of several factors.

In order to send the file, type the following command at the Terminal prompt:

> xcrun notarytool submit <path-to-zip-file/file-name.zip> --keychain-profile "notarytool-password" --wait 

After pressing the Return key, the process will start and the Terminal will output information about the progress; something similar to this:

Conducting pre-submission checks for <name-of-your-zip-file> and initiating connection to the Apple notary service...
Submission ID received
  id: <some-id-number-goes-here>
Upload progress: 100.00% (8.65 MB of 8.65 MB)   
Successfully uploaded file
  id: <some-id-number-goes-here>
  path: <path-of-the-zip-file>
Waiting for processing to complete.
Current status: Accepted........
Processing complete
  id: <keep-this-id-in-a-safe-place-you-will-need-it-later>
  status: Accepted

Have you seen the last line? The “status: Accepted” means that everything worked OK, and the notarization process has been successful, but it’s better if we check! Type the following command at the Terminal prompt. This one will ask the notarytool command to download the log file in JSON format to be saved at the desired path. It is a good habit to do it, because such a log file will include some eventual error and explanation about possible errors during the notarization process, including those related to the app itself:

> xcrun notarytool log <put-here-the-value-you-saved-in-a-secure-place-from-the-id-field-in-the-previous-output> --keychain-profile "notarytool-password" <path-to-save-the-log.json>

Staple the Ticket!

Assuming that everything worked OK, it is time to staple the notarization ticket to the app itself. It is not required, but is convenient to avoid online checks when the user runs the app, or Gatekeeper inspects it.

Yeah, that means using a new command from Terminal on the already signed, sandboxed and runtime hardened app bundle (not the Zip file you created for submitting using notarytool):

> xcrun stapler staple "<path-to-the-signed-sandboxed-and-hardened-app-bundle>"

After that, you can check that everything went OK using the following command:

> spctl -a -vvv -t install <path-to-the-signed-sandboxed-and-hardened-app-bundle>

And you should get something similar to this as the output:

source=Notarized Developer ID
origin=<your-full-developer-ID-Application>

App Distribution

That’s fine, but you will probably want to distribute your app from the Internet using a DMG container. In that case, follow these steps:

1. Create a DMG container (file).
2. Copy your already notarized app bundle into it.
3. Notarize the DMG file.
4. Staple the ticket to the DMG file.

That way the DMG container will be Notarized along with the app bundle inside it.

In Summary

As we did see, all the process of sandboxing, runtime hardening and Notarization involves a bunch of commands from the terminal, including the creation of the Zip file. But the good news is that all the process could be automated using Xojo itself! (take a look to the Shell class and the Zip method from the FolderItem class if you are not familiar with them).

As I said before, this article only on touches the basics and doesn’t dig into Provisioning Profile creation (associated with Capabilities required by the app), the Entitlements your app may need to properly work, among other topics; so you may find these Apple Developer Documentation of interest:

– Provisioning profiles.
– macOS Entitlements.
– macOS Sandbox.
– macOS Hardened Runtime.
– macOS Notarization.

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

More in this series on distributing Mac apps:

• Sandboxing, Hardened Runtime and Notarization arrives to the Xojo IDE
• macOS Apps: From Sandboxing to Notarization, The Basics
• Uploading macOS Builds to App Store Connect
• Provisioning Profiles for macOS Apps

First of all, if your apps only relies on the Xojo provided iOS framework functionality, then you don’t need to do anything at all. When building or running the iOS app, Xojo will create and add the required PrivacyInfo.xcprivacy file for you.

If you are using Declare calls or rely on iOS third party libraries or plug-ins, then you should check with the developer to know if any of the calls made fall into the Privacy Categories listed by Apple (keep in mind that these can change over time). If so, then it is time to visit the new Privacy Editor available under the Build Settings > iOS section, and click the Settings button in the associated Inspector Panel:

Here you will find the Edit button under the Privacy section. Click on it to bring up the Privacy Editor window:

In the Privacy Editor window, select both the API Type from the entries available in the ComboBox control, plus the associated API Reasons that meet your specific requirements based on the API Type selection.

Of course, you will be able to add as many API Type cards as you may need using the “Add Type” button, or delete any of the previously added cards. If any of your iOS apps share the same Privacy settings, you can simplify the process by creating and saving files in the Privacy Editor. Now you can add those files to your other iOS apps from the Editor via the “Open…” button or by dragging & dropping the file from its current location into the Editor itself.

Once you finish editing the Privacy settings for the iOS project, the PrivacyInfo.xcprivacy file will be created and automatically added when building the iOS app, allowing you to run it the Simulator, any connected iOS device or send it to the AppStore review approval. Learn more about this in the Xojo Documentation.

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

Last week, I attended the WWDC 2024 event in Cupertino. It took place in both the original Infinite Loop campus, as well as the Apple Park “spaceship” campus which opened in 2017 and cost $5 billion to build. Apple’s WWDC events are no longer a traditional developer conference. The developer session videos are all uploaded for free, and even the keynote is a prerecorded, so event attendees see it at the same time as the rest of the world. Instead, this is more of a social event – an opportunity to meet fellow developers, bump into some famous people, and take advantage of Apple’s hospitality. I found the event uplifting and exciting, and I was able to talk with many people and share perspectives with them. 

Inside the Infinite Loop campus – rumors of a free bar may or may not be greatly exaggerated

The event was a great opportunity to share ideas and plans with other developers

Now, you might think that the event is solely for Swift developers, but this is not entirely true. Of course, Apple are constantly pitching their chosen language and frameworks at the event, but there is also a recognition that many people develop software for Apple platforms in tools other than Swift and Xcode. Of the people I spoke to, quite a number of people were using something other than Swift (including an Apple engineer!). Many of the sessions from WWDC are naturally catered towards Swift developers, but there are still some that will be useful to Xojo developers. I’ve highlighted a selection of videos below, along with my own description.

I want more stuff

When browsing WWDC videos, if you come across new functionality or an API that isn’t exposed in Xojo, the best course of action is to create a feature request at https://tracker.xojo.com. But don’t stop there. Tell the community about your request on the forum and ask them to give the request a “thumbs up” if they agree. This helps the Xojo team gauge interest. For some requests, you may also want to rope in support from me or one of the other MVPs, so that we can potentially engage with the team directly on your behalf at one of our regular meetings.

At each WWDC, Apple releases beta versions of its new tools and operating systems. These are very early versions, especially at this point in the beta cycle, and should not be installed on your main machines without very good reason. Early anecdotal evidence suggestions few problems with Sequoia (the new version of macOS) and Xojo apps, but testing such software should be done in virtual machines or on machines that you don’t use for your daily coding. When Xojo support for the new OS and the new version of Xcode becomes official, the System Requirements page will be updated at https://documentation.xojo.com/resources/system_requirements_for_current_release.html

Highlighted WWDC 2024 videos

“What’s new in App Store Connect”

Take better advantage of the App Store, get your app nominated for featuring and more.

“Add personality to your app through UX writing”

This is a quintessentially Apple presentation, but it may be thought provoking. What is the tone of your app? Does it matter for your market?

“Implement App Store Offers”

Self-explanatory from the title. Most of this will require the use of MBS plugins.

“Platforms State of the Union 5-Minute Recap”

The full State of the Union presentation, which follows the main keynote each WWDC, is rather lengthy and not required viewing for Xojo developers. But the five minute recap is worth watching to get an overview.

“Build multilingual-ready apps”

A lot of this video involves Swift code but there is still useful information for everyone in this.

Notes: 

• Apple also have a “Expanding your app to new markets” document at https://developer.apple.com/localization/. 
• To take advantage of much of this in your Xojo apps, see https://documentation.xojo.com/topics/localizing_your_apps/introduction_to_app_localization.html

“What’s new in SF Symbols 6”

SF Symbols (SF stands for San Francisco) is a library of thousands of clean and simple symbols for use in Apple platforms only. Apple typically updates this yearly.

Notes:

• To take advantage of SF Symbols in your iOS apps, use the Picture.SystemImage method. See the docs at https://documentation.xojo.com/api/graphics/picture.html#picture-systemimage
• There is no built-in support for SF Symbols in Xojo Mac apps, but you can still take advantage of them. See this blog post for details: https://blog.xojo.com/2021/10/21/quicktip-using-sf-symbols-in-macos-revisited/
• Tell Xojo that this support should really be built-in! Lend your support to this case; https://tracker.xojo.com/xojoinc/xojo/-/issues/60751
• Whilst SF Symbols is Apple-only, there is also a library of images built into Xojo for Android developments, also using the Picture.SystemImage method.
• Browse SF Symbols on your Mac (and get their names for use in Xojo) by downloading the SF Symbols utility from https://developer.apple.com/sf-symbols/

More videos

Want to watch even more videos? (Shouldn’t you be coding?) Subscribe to the official Xojo YouTube channel and also see videos from the recent Monkeybread Software conference, including presentations from Xojo engineers and other MVPs. https://www.youtube.com/@MonkeybreadSoftware/videos

Gavin is a Xojo MVP and is based in the UK. He has been a Xojo developer since the first version in 1998.

With this in mind, here’s an infographic that illustrates how Xojo’s been continually updating and modernizing since 1996 while other development tools come and go.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

You still hear this same argument today in the software development world, where the big names are Microsoft, Apple and Google.

But how “safe” is their stuff, really? After all, they all seem to end support for products and tools rather often.

Microsoft recently announced that they are discontinuing Visual Studio for Mac, which was only just introduced in 2016. Last I checked, Microsoft is a Very. Big. Company. Yet they somehow cannot justify resources to keep a Mac IDE viable. Clearly, they have the resources so this is a decision about Microsoft’s focus and priorities, things that Big Companies change all the time.

Google drops products (or drastically changes them) often. Changing their “free for life” Google Apps (G Suite) product to a rather expensive monthly cost was not popular with many businesses.

Apple killed off iBooks Author, and although it was not a development tool, it was something that was heavily promoted for a while as the best way to make content for the iBooks Store. In the development world, Apple killed off their Carbon OS framework in favor of Cocoa after years of telling developers the two would co-exist.

In the 2000s before working here at Xojo, I did a lot of consulting (frequently migrating VB6 apps to Xojo) and one question that was often asked of me is “why should I go with a dev tool from a small company like Xojo instead of something from a big name like Microsoft?”.

The answer I always gave at the time was: “You’re coming to me to migrate a VB6 app. VB6 was from Microsoft and they killed the product off. Big companies do that all the time. A small company like Xojo focuses entirely on their product. It gets all their attention. If you had picked Xojo in 1999 instead of VB6, we would not be having this conversation right now.”

To that end, Xojo has been around since 1998 and has outlived many other development tools and platforms. Some of which come to mind are: Visual Basic 6, Metrowerks CodeWarrior, and (now) Microsoft Visual Studio for Mac.

Technologies are also regularly discontinued by the creators in favor of newer versions. It took years for the Python community to move from Python 2 to Python 3. But when Apple finally removed Python 2 from macOS last year, there were many apps and companies that had to scramble to update their code. PHP8 was release in 2020, but as of today adoption is only about 12%. In 2017, Google switched from Java to Kotlin as the official language of Android, impacting many. Apple promotes Swift and Swift UI over Objective-C and AppKit these days. They introduced Catalyst, but it appears to not be making much headway. Microsoft pushes out new frameworks at a rapid pace, which is exciting, but can be difficult for a development team to know what to pick.

I don’t bring these things up to point out mistakes. Change is inevitable in technology after all. I only bring these up to point out that, even with the big names, there are still risks.

All this is to say that if you are an enterprise company with a large investment in software and IT, you might want to take a look outside the big names and see what Xojo can offer. I realize that if you have standardized on a set of tools from a large vendor, say C# and Microsoft, you are probably thinking “there’s no way I’m switching to Xojo no matter what this guy says”.

We at Xojo agree. You probably should not be switching everything over to Xojo. That would be insanely expensive and risky. But Xojo can be a great complement to the tools you already use. Professional software developers (and their companies) keep lots of tools in their toolbox and Xojo should be one of those tools.

So what can Xojo do for you?

Xojo’s goal is to make programming easier, allowing you to get software made faster. Xojo saves you time and money. To that end, in enterprise environments Xojo is great for:

• Prototypes and proof-of-concepts
• Internal tools and utilities
• Testing
• Demos

With Xojo you can quickly build a desktop app (for mac, Windows or Linux) to test out REST APIs. You can build a web app to demonstrate some UI concepts or easily distribute information. You can build a mobile app (iOS or Android) to quickly try out ideas. Xojo lets you do All The Things without having to deal with a bunch of different complex tools and technologies. Xojo can give you the speed and power of low-code tools without all the limitations.

Xojo makes it quicker and easier to try out software ideas before you commit expensive development resources to your primary tools. A company’s biggest expense is usually salary and using an expensive IT department to slowly build everything is not a great value. You spend too much money on salary and sacrifice too much time on lost opportunities. Using Xojo instead can save you significant money that you can put towards the projects you determine are viable and worth more investment.

And don’t forget about internal tools. Every company needs internal tools of some kind and these won’t generate revenue on their own. Forcing these tools to go through an overworked IT department is slow and expensive. But not building them at all means your staff is less productive than they could be. Your advanced power users can use Xojo to create tools that will improve productivity at a fraction of the cost and avoid lost opportunities waiting for IT.

Like Apple, Google and Microsoft, Xojo isn’t perfect. We’ve made our share of mistakes, such as our transition from Web 1.0 to Web 2.0 which was not as smooth as we had hoped it would be. The team is only human, but we do our best to learn from mistakes and if nothing else we are perseverant and committed to always making Xojo better. The fact that we’ve been doing this since 1998 is a testament to that.

So join the many other enterprise customers that use Xojo as a secret weapon! You might find you like using a development tool from a small company that cares about its product and its customers.

You can try Xojo for free today. Licensing is available for as low as $399 per user (even lower when purchased in bulk). Contact us at hello@xojo.com for more information or to get a quote.

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 has released the developer documentation for Vision Pro, their recently announced mixed reality headset. So far, it looks promising that iOS apps written in Xojo will just work. Of course, we don’t yet have one of these to use for testing. If we did, we’d be too busy playing with it to write this blog post, however we have tried running some Xojo iOS projects in the Vision Pro Simulator and they work without modification so that’s a very good sign.

My new path has taken me deep into the world of iOS and macOS and I thought I would create some projects & products which would benefit Xojo apps on those platforms by creating some products which expose some of the larger frameworks which are not already available but also cannot be accessed by declares alone…

WeatherKit

About the time that Apple ended support for the Dark Sky API, forcing users to transition to their WeatherKit Rest API, I was thinking about an iOS project which would benefit from having access to the phases of the moon and barometric pressure on a historical basis. After a bit of research, I found that Apple’s WeatherKit framework was well-suited for the purpose, but found that it was a Swift-only framework and accessing it from Xojo was going to be challenging. I proceeded to create an obj-c bridge framework and a set of Xojo classes to make it available to everyone.

What resulted is a framework which currently provides developers access to the WeatherKit framework as well as some helper tools for:

• Location Geocoding, because WeatherKit requires Latitude/Longitude and humans don’t remember locations that way.
• Unit Conversion, for the units that are used in WeatherKit.
• Multicolor Symbols, for a quick and easy way to access the multicolor SFSymbols which are provided by Apple for weather.

You can read more information about this framework and download a demo from here, and it can be purchased from Xojo’s Extras Store.

Multipeer Connectivity

Another framework which caught my eye was MultipeerConnectivity. This framework allows you to make connections with up to 8 macOS and/or iOS devices simultaneously for use in games or business applications with multiple communicating workstations. It offers both automatic user-driven and manual programmatic device discovery as well as a few data transfer mechanisms. macOS devices use Wi-Fi and/or Ethernet and iOS devices use Wi-Fi and/or Bluetooth. Network selection is completely automatic so once the connection has been established, all your app needs to do is send data back and forth and disconnect when it’s done.

My port of the framework gives you access to nearly the whole framework, short of creating a direct socket connection between two devices, but text and file transfers are both implemented and working just fine. I was even able to transfer a 130MB file from a Mac to an iPhone in about 16 seconds.

You can read more information about this framework and download a demo from here, and it can be purchased from Xojo’s Extras Store.

Free Stuff

I also have several Github repos and a number of free xojo-related items available, including my Profile Triage tool for helping developers figure out why they get errors when trying to sign or notarize their apps. You can see that list on my site here.

More on the horizon…

There’s more to come. I have some other products which I think will benefit Xojo iOS and macOS projects in the future, so watch for posts on the Xojo forum!

Greg O’Lone spent eleven years as a member of the Xojo engineering team from 2011 through 2022. During his time at Xojo he worked on many of the parts of the product that make Xojo what it is today – from the IDE and iOS Framework to Xojo Cloud and both of the Web Frameworks. You can learn more about Greg and what he’s creating now at his website.

I first made a desktop Secret Santa app back in 2015 for an event with friends. We were tired of drawing names out of a hat and having couples being paired together. The app I created solved that problem because couples were excluded from offering a gift to each other. And we didn’t need a hat!

In November of 2018, I had the idea of making a Secret Santa iOS app so that anyone with an iPhone or iPad could benefit from the same features I had been enjoying for the past 3 years.

The app would need to be easy to use, avoid couples getting matched with each other, send notifications by email without letting the organizer know which pairs were matched, and of course make sure no name would be assigned twice.

After just 8 days of development, the app was ready to ship and sent to the App Store.

Within 5 days, the app had been downloaded from 35 different countries and was my fastest app to reach 1000 downloads!

Having the app translated to English, French, Italian, and Spanish in the initial release helped to reach more users.

Version 1.1 of the app was released a few days later with German and Portuguese translations.

That’s when I realized that Secret Santa is something extremely common in Latin America. Many families draw names for Christmas so that they can give and receive one big gift instead of smaller trivial gifts for each family member.

Most updates of the app came with new localizations, which really helped in realizing more and more downloads. After 3 years of updates, the app is now available in 32 languages.

A high quantity of downloads also meant that I received a lot of feedback from users. Many users were happy with the current features, but I started getting feature requests to send the gift pairs by SMS or WhatsApp instead of by email. We all have a parent or grand-parent who isn’t tech-savvy and doesn’t have an email address.

Leveraging the biggest advantage of Xojo – Sharing code across platforms

From 2018 until 2022, I had become used to updating the Secret Santa app itself to add new features and new translations while also fixing bugs. This year, I received a message from an unhappy user stating that they really need a wishlist feature and downloaded my app thinking it already had one.

A valid wishlist feature needed to be accessible to anyone with an Internet connection, whether they used a computer, an iPhone, or an Android device.

Using Xojo Web and a coding language I already knew was the obvious choice for this task. Sharing important bits of code from my main iOS project to the web wishlist project was as easy as copy and paste.

As with any Xojo project, copying classes from one project to the other was a real time saver, especially for the API layer required to communicate between Xojo and the online database that holds all the Secret Santa data.

The main difficulty working on a web project came from the UI. Not that Xojo Web’s UI is difficult, but I am so used to designing mobile apps that my brain didn’t know where to start.

I knew I wanted to display two columns of data:

• The user’s wishlist
• The wishlist from the person they are offering a gift to

The layout had to be responsive to be accessible on both mobile and desktop devices.

Graffitisuite from Anthony Cyphers came to mind, and within a few minutes of reviewing the online demo, I was convinced to use GraffitiKanban web control. I am a big fan of Trello for organizing my work, displaying cards in labeled columns. That’s exactly what I needed for the wishlist feature.

GraffitiKanban is “responsive” (Web Design term), meaning the display changes to adapt to smaller screens such as mobile devices.

GraffitiSuite also offers a wide variety of UI elements that made me save a lot of time.

7 days after the initial feature request, the wishlist feature was available to all.

Wishlist on a desktop browser:

Wishlist on a mobile browser:

Deploying the app to Xojo Cloud was extremely easy.

A single button press in Xojo, a subdomain DNS record, 2 minutes of configuration in Cloudflare, and the web app was up, running, and accessible through HTTPS.

Customer use of the wishlist feature has blown-up more than I ever would have expected. So far 30,000 gift ideas have been added to the wishlist (and counting).

The next feature request

With an app that sees 60,000 new users per month, I receive a lot of feature requests. Most recently, I received a one star review on the app store because my app isn’t accessible to the Visually Impared. When VoiceOver is activated, all it says is “button”, “button”, “button”, with no explanation.

Adding voice-over capabilities in Xojo is simple. The MobileUIControl class has two String properties, AccessibilityHint and AccessibilityLabel.

But it actually is a lengthy task to check each control on each screen and make sure that the translations are correct.

VoiceOver support will soon be released in English and French, but all other localizations will be only ready next year. It is currently a bad time to get 30 different translators to work on the project under such short notice.

Xojo has enabled me to create a business out of developing iOS apps for the App Store. Including all of my apps, I have had over 6.5 million downloads and counting. Secret Santa is a prime example of what is possible and how you can leverage your Xojo skills to expand to other platforms when you need to. I look forward to what’s to come and will be at XDC London to learn more about the future.

If you are organizing a Secret Santa event or just curious to see the app, download Secret Santa on the App Store.

Jérémie Leroy has been using Xojo since 2008, he won two Xojo Design Awards in the iOS App category and has released over 13 iOS apps made with Xojo on the App Store. He also released iOSDesignExtensions on Github to help style and polish your Xojo made iOS apps.

There’s a lot of neat new features coming in iOS 16. The kinds of customizations Apple is adding to the Lock Screen are quite nice both aesthetically and practically. While I’m personally not prone to sending text messages I later regret, being able to edit messages and more importantly unsend them, is going to save many relationships. That you can easily switch between dictation and the keyboard means I will probably use dictation a lot more than I have in the past. I have a friend that uses it constantly and I can’t tell you how many times a second text message arrives to explain the incomprehensible message that had arrived moments earlier. That it now adds punctuation will make me want to use it more as dictating punctuation has always felt awkward to me. It will however likely infuriate my kids who think punctuation in text messages is rude. That ApplePay is going to have integrated order tracking is really nice. I have been using an app for that and sadly quite recently several of the companies it allows you to track have dramatically reduced the functionality of their APIs making the app almost useless. That you will be able to easily share photos amongst family members via an iCloud Shared Photo Library is a feature my family will definitely be using. It’s very cool that you can have it automatically share photos that were taken when family members were close by or when they are in the photo itself. It’s a very nice use of Apple Neural Engine.

That Apple announcing a feature to help people escaping abuse says a lot about what they value and how important privacy is to one’s personal safety. It goes right along with features they have added in the past that allow you to reach into your pocket and dial 911 should you need to do that in secret. I’m big into making my home smarter so I was happy to see the Home app getting a facelift as well as Apple working with other companies on smart home interoperability. I’m also a huge fan of CarPlay and seeing Apple’s vision for it becoming nearly the entire way in which you interact with displays and controls in your car and being able to customize that to your liking was far more than I had ever thought would happen. That future is clearly years away because it requires a lot of cooperation with the automakers but as they adopt it, it will certainly sway my future car purchases.

I wear an Apple Watch and very much care about the quality of my sleep. That they have added the ability to see your REM, core and deep sleep cycles is very cool. I will definitely be wearing my watch to bed more often as a result. They are adding a medication reminder system which I can see as being a benefit. I only take one pill a day so it’s not something I would use but my wife takes several and on her busy days sometimes forgets to take them so it’s a feature she will definitely use.

The M2 was something I was fully expecting and it’s nice to see it incrementally getting better. Apple made it clear that performance per watt is the key metric for them and that makes a lot of sense. We need that kind of metric in many other places in society so that we better understand the impact we are having on each other and our planet.

The surprise feature in macOS Ventura was Stage Manager. it makes it easy to avoid the clutter of having a lot of windows open. I wasn’t expecting it and yet I’m sure I will use it. Like Messages, Mail is getting an unsend feature and lots of other nice improvements especially to search (which has always felt weak to me) but I’ll have to test it to know just how much it has improved. Passkeys is Apple’s name for their implementation of the Fido standard they are collaborating on with Google and Microsoft. It’s designed to get rid of passwords entirely, something of which I will definitely be an early adopter. They really have thought that one through. It will make all of our devices and data far more secure. Being able to use FaceTime with Handoff will be really nice. I’ve been on a FaceTime call and then hung up to call someone back from my Mac so it will be nice to be able to just transfer it from one device to another.

The new MacBook Air is a nice incremental upgrade. If you have an Intel-based MacBook Air, this is a good time to upgrade.

iPadOS 16 is bringing some more desktop-like features to iPad. Things like standard ways for accessing documents, renaming them, collaboration, etc., all make iPad feel a little more like a desktop without it being a desktop. It feels like Apple is striking the right balance. They also previewed a new app called Freeform which is essentially a digital whiteboard that you can use to collaborate with others. Though now that I say that, it seems to not really do it justice given that you can share so many different things in a common space, from text, drawings, photos, video and more. It would be great for brainstorming with a remote team.

Overall, this keynote demonstrated a lot of incremental improvements across the software side of the product line and that’s a good thing. We all want something big, new and flashy but those often come at the cost of a lot fewer incremental improvements. I’m actually quite happy that we weren’t blindsided by something that could potentially change our short term plans here at Xojo. I look forward to using many of the new features they are adding this year.

Setup

Debugging on device requires your device be connected to your computer using a lightning cable.

Computer
You’ll need to launch Xcode, plug your phone in using USB and open Xcode’s Devices and Simulators window. In the navigation pane on the left, select the device and check the Show as run destination checkbox.

Device
If you’ll be debugging over USB, go to the Settings app on your device, select Personal Hotspot and turn that on.

Apple Developer Portal

For on-device debugging, your app profiles must be set up properly. For help on this, read The Crazy Exercise That Is The Apple Signing Process.

1. Certificates: You will need a Development certificate for yourself. Download it and double-click the file to install it.
2. Identifiers: You will need an Application Identifier that matches the Bundle Identifier in your app.
3. Devices: You must register all of the devices that you intend to debug on.
4. Profiles: You will need to create a Development profile for the app and make sure it contains your Development certificate (from step 1) as well as each of the devices that you want to debug on (step 3). Download the profile and double-click the file to install it.

Xojo

Debugging on-device requires that you set the Team from your account as well as setting the Build For property to App Store.

When you’re ready to run on a device, from the menu select Project > Run On and select your device from the list. If everything is configured properly, your app should be transferred to the device and automatically run for you.

Notes

The first time you debug an app, you will get a dialog on the device asking if your app can connect to the local network. You will need to allow that and then run your app from Xojo again.

Don’t allow your device to go to sleep while waiting for the app to build and transfer or the app won’t be able to launch. You can increase the amount of time on the device by going to Settings > Display & Brightness and selecting a new Auto-Lock timeout. The options are 2, 5, 10 or 15 Minutes or Never.

Quick Look is the Apple technology in charge of creating icons and thumbnails based on a file contents. With Quick Look, the user can get a more precise preview of the contents stored in the selected file without having to open it.

You can retrieve this kind of information in your macOS Xojo Desktop apps using the Declare feature of the Xojo language, as we already have seen in other blog posts. As you probably already know, Declares give you the ability to, well, “declare” from Xojo any call to functions or methods provided by external APIs and libraries as it is the case with the Frameworks available in the macOS operating system itself.

Once we have “declared” these kind of functions from Xojo code, they will be ready to be used when calling any of your own defined methods or any of the methods directly available from the Xojo classes.

You can download the Xojo Project file from this link.

We will start by adding a new method to a Module in a Xojo Desktop project using the following method signature:

• Method Name: IconForFile
• Parameters: Extends f As FolderItem, tSize As Size, Optional QuickLookIcon As Boolean = True
• Return Type: Picture
• Scope: Global

If you are new to coding in Xojo, then probably you’ll be wondering what “Extends” means in the signature method. In brief, that means that the method will be treated as a method for the data type (or class) included next to the defined parameter; in this case the FolderItem.

The main convenience of extended class methods is that your code will be more readable and you’ll be able to call the method on a data type instance using the dot notation. So, instead of using the following syntax:

Var f As FolderItem = FolderItem.ShowOpenFileDialog("")
Var tSize As New Size
tSize.Height = 128
tSize.Width = 128

var p As Picture = IconForFile(f, tSize) // IconForFile as a regular method definition

We are able to call the method this way:

Var f As FolderItem = FolderItem.ShowOpenFileDialog("")
Var tSize As New Size
tSize.Height = 128
tSize.Width = 128

var p As Picture = f.IconForFile(tSize) // IconForFile as an extended method for the FolderItem class

Notice as the second chunk of code is calling the method using the dot notation on the FolderItem instance referenced by the f variable and how, in that case, we don’t need to provide the FolderItem variable as one of the parameters in the method call.

The second thing you’ll probably find of interest in the method definition is the use of the Optional keyword. We include that keyword in the method signature to indicate that such parameter is… well… optional; that is, you can provide the parameter in the method call or not. In fact, in the previous code snippets you might have noticed the last parameter was omitted in the method call.

In addition, we can also provide a default value for our Optional parameter; that is the value that will receive the method if we don’t provide a value of our own. In our method definition we are setting the QuickLookIcon parameter to the default Boolean value True.

Getting a Quick Look Icon… and a Regular one

With our method just added, the next step is to type in the associated Code Editor the code that will be executed when we call it. As you can see, we are using a lot of Declares here from several macOS frameworks. I have added a brief commentary about their tasks on each one of these, plus a link to the associated documentation webpage on the Developers area from Apple web, so you can continue learning or digging into their functionality and, specially, the parameters and return types declared in their original signatures so you can compare how these are translated or matched from Objective-C when declared in Xojo code.

#If TargetMacOS Then

  #Pragma DisableBackgroundTasks
  #Pragma DisableBoundsChecking
  #Pragma NilObjectChecking False

  If f = Nil Or Not f.Exists Then Return Nil

  Var path As String = f.NativePath

  // Declare for allocating (reserving memory for) an Objective-C object
  // https://developer.apple.com/documentation/objectivec/nsobject/1571958-alloc/
  Declare Function Alloc Lib "Foundation" Selector "alloc" (classRef As ptr) As ptr

  // Declare for autoreleasing (freeing from memory) an Objective-C object
  // https://developer.apple.com/documentation/foundation/nsautoreleasepool/1807021-autorelease/
  Declare Sub AutoRelease Lib "Foundation" Selector "autorelease" (classInstance As ptr)

  // Declare for getting a reference to an Objective-C class based on the received String
  // https://developer.apple.com/documentation/foundation/1395135-nsclassfromstring?language=objc
  Declare Function NSClassFromString Lib "Foundation" (className As CFStringRef) As ptr

  // Declare for getting a reference to the shared Workspace of macOS process.
  // https://developer.apple.com/documentation/appkit/nsworkspace/1530344-sharedworkspace/
  Declare Function sharedWorkSpace Lib "AppKit" Selector "sharedWorkspace" (classObject As ptr) As ptr

  // Declare for getting the Icon object from the recived file path
  // https://developer.apple.com/documentation/appkit/nsworkspace/1528158-iconforfile/
  Declare Function iconForFile Lib "AppKit" Selector "iconForFile:" (instanceObject As ptr, path As CFStringRef) As ptr

  // Declare for setting the size of an NSImage
  Declare Function setSize Lib "AppKit" Selector "setSize:" (instanceObject As ptr, size As NSSize) As ptr

  // Declare for Lock and Unlock an NSImage in Objective-C
  // https://developer.apple.com/documentation/appkit/nsimage/1519891-lockfocus?language=objc
  // https://developer.apple.com/documentation/appkit/nsimage/1519853-unlockfocus?language=objc
  Declare Sub LockFocus Lib "AppKit" Selector "lockFocus" (imageObj As ptr)
  Declare Sub UnlockFocus Lib "AppKit" Selector "unlockFocus" (imageObj As ptr)

  // Declare for getting a new Bitmap Representation based on the Locked view
  Declare Function InitWithFocusedView Lib "AppKit" Selector "initWithFocusedViewRect:" (imageObj As ptr, rect As NSRect) As ptr

  // Declare for getting an NSData object with the specified image format from a Bitmap Representation
  // https://developer.apple.com/documentation/appkit/nsbitmapimagerep/1395458-representationusingtype/
  Declare Function RepresentationUsingType Lib "AppKit" Selector "representationUsingType:properties:" (imageRep As ptr, type As UInteger, properties As ptr) As ptr

  Var targetSize As NSSize
  targetSize.Width = tsize.Width
  targetSize.Height = tsize.Height

  Var tRect As NSRect
  tRect.Origin.x = 0
  tRect.Origin.y = 0
  tRect.RectSize = targetSize

  Var data As ptr

  If QuickLookIcon Then

    //=================
    // Let's try to retrieve the icon from Quick Look

    Var dictClass As ptr = NSClassFromString("NSDictionary")
    Var numberClass As ptr = NSClassFromString("NSNumber")

    // Declare for getting an NSNumber object from the received Boolean value
    // https://developer.apple.com/documentation/foundation/nsnumber/1551475-numberwithbool/

    Declare Function NSNumberWithBool Lib "Foundation" Selector "numberWithBool:" (numberClass As ptr, value As Boolean) As ptr
    Var numberWithBool As ptr = NSNumberWithBool(numberClass, True)

    // Declare for getting an NSDictionary object from the received Key and Value
    // https://developer.apple.com/documentation/foundation/nsdictionary/1414965-dictionarywithobject/

    Declare Function NSDictionaryWithObject Lib "Foundation" Selector "dictionaryWithObject:forKey:" (dictClass As ptr, value As ptr, key As CFStringRef) As ptr
    Var dictInstance As ptr = NSDictionaryWithObject(dictClass, numberWithBool,"IconMode")

    Var fileClass As ptr = NSClassFromString("NSURL")

    // Declare for getting an NSURL object from the received path as string
    // https://developer.apple.com/documentation/foundation/nsurl/1410828-fileurlwithpath/

    Declare Function NSFileURLWithPath Lib "Foundation" Selector "fileURLWithPath:" (fileClass As ptr, path As CFStringRef) As ptr
    Var fileInstance As ptr = NSFileURLWithPath(fileClass, f.NativePath)

    // Declare for getting the Quick Look based icon thumbnail for the received file and with the specified size
    // https://developer.apple.com/documentation/quicklook/1402623-qlthumbnailimagecreate?language=objc

    Declare Function QLThumbnailImageCreate Lib "QuickLook" (allocator As Integer, file As ptr, size As NSSize, dictRef As ptr) As ptr
    Var imageRef As ptr = QLThumbnailImageCreate(0, fileInstance, targetSize, dictInstance)

    If imageref <> Nil Then

      Var BitmapImageRepClass As ptr = NSClassFromString("NSBitmapImageRep")
      Var BitmapImageRepInstance As ptr = Alloc(BitmapImageRepClass)

      // https://developer.apple.com/documentation/appkit/nsbitmapimagerep/1395423-initwithcgimage/

      Declare Function CGInitWithCGImage Lib "AppKit" Selector "initWithCGImage:" (bitmapInstance As ptr, CGImage As ptr) As ptr
      Var BitmapImageRep As ptr = CGInitWithCGImage(BitmapImageRepInstance, imageRef)

      data = RepresentationUsingType(bitmapImageRep, 4, Nil) // 4 = PNG

      AutoRelease(BitmapImageRep)
      AutoRelease(imageref)

      // Getting Xojo Picture instance from NSData object
      Var p As Picture = NSDataToPicture(data)

      data = Nil
      numberWithBool = Nil
      fileInstance = Nil
      dictInstance = Nil
      BitmapImageRepInstance = Nil
      Return p

    End If
  End If

  // If we reach this point is because there is no way to retrieve the
  // Quick Look icon for the file, it has returned a non valid object,
  // or we received the optional QuickLookIcon param set to False,
  // so we fallback to the regular one (FileType based).

  Var WorkSpace As ptr = NSClassFromString("NSWorkspace")
  Var sharedSpace As ptr = sharedWorkSpace(WorkSpace)
  Var icon As ptr = iconForFile(sharedSpace, path) // We get NSImage here

  Var resizedIcon As ptr = setSize(icon, targetSize)

  // Getting bitmap image representation in order to extract the data as PNG.

  LockFocus(resizedIcon)

  Var NSBitmapImageRepClass As ptr = NSClassFromString("NSBitmapImageRep")
  Var NSBitmapImageRepInstance As ptr = Alloc(NSBitmapImageRepClass)
  Var newRep As ptr = InitWithFocusedView(NSBitmapImageRepInstance, tRect)

  UnlockFocus(resizedIcon)

  data = RepresentationUsingType(newRep, 4, Nil) // 4 = PNG

  // Getting Xojo Picture instance from NSData object
  Var p As Picture = NSDataToPicture(data)

  data = Nil
  icon = Nil
  AutoRelease(newRep)

  Return p

#EndIf

As you can see, all the code is wrapped into a compilation conditional #If… #EndIf block. This means that the code will be compiled only if the condition is evaluated as true. In this case, it will compile only when we try to compile a desktop app for macOS as stated with the TargetMacOS keyword.

Next, we will use three #Pragma directives to speed things up a bit. In this case the pragma disable the tasks in the background, checking bound in collections like the Arrays and checking instances set to Nil, but only during the method execution, after which things return to their original settings.

The remaining code includes comments so you can see what happens at the more important points; for example whether to retrieve the Quick Look icon associated with the file or the regular one based on the file data type.

You’ll have probably noticed that we called a second method: NSDataToPicture. This method will be in charge of converting the data from an Objective-C NSDATA object to a Xojo Picture, using the technique used in previous blog posts (here and here). In this case we included it as a method call to avoid the duplication of code.

Let’s add a second method to our Module using the following values:

• Method Name: NSDataToPicture
• Parameters: data As Ptr
• Return Type: Picture
• Scope: Protected

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

Declare Function DataLength Lib "Foundation" Selector "length" (obj As ptr) As Integer
Declare Sub GetDataBytes Lib "Foundation" Selector "getBytes:length:" (obj As ptr, buff As ptr, len As Integer)

Var dlen As Integer
Var mb As MemoryBlock
Var mbptr As ptr

// Getting image data to generate the Picture object in the Xojo side
// We need to get the length of the raw data…
dlen = DataLength(data)

// …in order to create a memoryblock with the right size
mb = New MemoryBlock(dlen)
mbPtr = mb

// And now we can dump the PNG data from the NSDATA objecto to the memoryblock
GetDataBytes(data, mbPtr, dlen)

// In order to create a Xojo Picture from it
Return Picture.FromData(mb)

Adding Required Structures

As in previous tutorials dealing with Declares, we need to add several structures to the Module; these are required when calling to some of the declared functions in the IconForFile method. The required structures are:

• Structure NSOrigin
  X As CGFloat
  Y As CGFloat
• Structure NSSize
  Height As CGFloat
  Width As CGFloat
• Structure NSRect
  Origin As NSOrigin
  RectSize As NSSize

Creating the User Interface

We have prepared for retrieving the file icons on macOS, let’s continue creating a user interface for the app so we can test how it works! The final user interface will look like this:

Click on the Window1 window in the Navigator panel; that will display the window in the Layout Editor. With Window1 selected, go to the associated Inspector Panel and change the following properties:

• Name: MainWindow
• Title: Icon File Viewer

Next, with the MainWindow item still selected and displayed in the Layout Editor, drag a Button control from the Library and drop it in the top-left area of the window in the Layout Editor (you can rely on the displayed alignment guides to position the control).

With the button selected in the Layout Editor, change the following values in the associated Inspector Panel:

• Name: SelectFileBt
• Locking: Top and Left closed (locked)
• Caption: Select File

Return to the Library, drag a Label control and position it just under the button in the Layout Editor. Use the associated Inspector Panel to change the following values:

• Name: IconSizeLB
• Locking: Top and Left closed (locked)
• Text: Icon Size:

Drag a Slider control from the Library and position it just to the right of the label. Drag the right corner of the Label handler in the Layout Editor to change its width so it reaches the right margin of the window. Use the associated Inspector Panel to change the following values:

• Name: IconSizeSL
• Locking: Top, Left and Right closed (locked)
• Line Step: 32
• Allow Live Scrolling: Enabled
• Page Step: 32
• Tick Mark Style: Bottom Right
• Value: 128
• Minimum Value: 32
• Maximum Value: 1024

Once again, drag a CheckBox control from the Library and position it just below the Label in the Layout Editor. Use the associated Inspector Panel to change the following values for the CheckBox:

• Name: QuickLookCB
• Locking: Top and Left closed (locked)
• Caption: Quick Look Preview
• Visual State: Checked

The last control we need to add is an ImageViewer. Drag the control from the Library and position it just below the CheckBox. Use the ImageViewer resizing handlers in the Layout Editor so its width and height matches the right and bottom alignment guides in the window. Then, use the associated Inspector Panel to set the following values:

• Name: IconPreviewIV
• Locking: Top, Left, Right and Bottom closed (locked)

Adding Functionality to the User Interface

Let’s add the code to execute when the user interacts with certain controls. With the SelectFileBt button item selected in the Navigator or the Layout Editor, use the contextual menu to add the Pressed Event to it. Then, type the following code in the associated Code Editor:

file = FolderItem.ShowOpenFileDialog("")
If file <> Nil Then
  FileNameLB.Text = file.Name
Else
  FileNameLB.Text = ""
End If
GetIconForFile

With the IconSizeSL slider control selected, use the contextual menu to add the ValueChanged Event to it, and type the following code in the associated Code Editor:

If Self.File <> Nil Then
  GetIconForFile
End If

With the QuickLookCB checkbox item selected, use the contextual menu to add the ValueChanged Event, and type the following line of code in the associated Code Editor:

GetIconForFile

As you can see, all of these events will call the getIconForFile method, so we need to add it to the MainWindow window using the following signature:

• Name: GetIconForFile
• Scope: Public

…and type the following snippet of code in the associated Code Editor:

If file <> Nil Then
  Var tSize As New Size
  tSize.Height = IconSizeSL.Value
  tSize.Width = IconSizeSL.Value

  IconPreviewIV.Image = file.IconForFile(tSize, QuickLookCB.Value)

End If

In the final step, add the File property (as FolderItem type) to the window, because this will be the one responsible for storing the reference to the FolderItem selected by the user when they click the SelectFileBt button.

Once the File property has been added, run the app, click on the Select File button and change the slider value to retrieve the icon for the file using a different size. Try to click in the checkbox to change the retrieved icon from the Quick Look view (enabled by default) to the kind of icon associated with that particular file type.

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.

It’s All About Operational Security

Just so we’re all clear about why this process seems so complicated in the first place. What Apple is trying to do is to provide operational security, that is, separation of responsibilities so that on a big team, a single developer can’t just create and push out an app without anyone’s approval. While it adds a bit of complication for individual developers, it also means that as your product (and more importantly your team) grows, you’ll be able to deal with the changes gracefully.

Seemingly Disparate Pieces

There are six different parts that need to come together to successfully sign and deploy on iOS and macOS using the App Store (or Enterprise) which need to be configured properly for all this to work. If you’re just starting out, we suggest doing them in the order specified below to avoid having to go back and regenerate things later.

1. The Application Identifier – This is the identifier which Apple requires be unique for every application installed on an Apple device. Typically in the form: com.yourcompany.app-name You will have the best luck with this process if you decide what this is going to be up front because it affects nearly everything going forward. You will define any capabilities which require entitlements in this section. Enabling things in this section may mean that you need to check a corresponding capability in your Xojo project. Changing these capabilities will invalidate the Profiles below.
2. Testing Devices – This is a list of devices which are allowed to be used for testing. They are specified using the Apple Developer portal using the device UDID. For an iOS device, this can be found either in Finder or in iTunes when the device is connected. I suggest using a meaningful name for the device if you have a lot of them.
3. Certificates – Development and Distribution certificates are based on a public-private key-pair (like SSH) and are used for signing applications for testing and distribution respectively. See the Troubleshooting section below for more information.
   1. Development Certificate – Each person who is writing code for you on your projects and needs to be able to build for a testing device will need one of these which was created in your account. This means that if you have a contractor working for you, you’ll need to add them to your account, set their Role to Developer and specify the apps that this developer is allowed to work on. One certificate per developer, and these need to be renewed each year.
   2. Distribution Certificate – The person, group or machine that is responsible for building for the App Store (or Enterprise) has a separate key-pair certificate. One certificate per account, and they need to be renewed each year.
4. Profiles
   1. Development Profile – This file is used to link up the who, what and where of developing an iOS or macOS app. When creating a development profile, give it a name appropriate to the group you are creating. It’s important to understand that because these profiles rely on the testing devices and on the individual developers that changes to those groups will require regenerating this profile. If your developers and/or testing devices change often, I suggest creating individual profiles for each developer. If not, you’ll have better luck with just one profile that contains all of your developers and devices. These need to be regenerated at least once per year.
      1. The Application Identifier – Select the Application Identifier for the app to which this profile applies.
      2. Certificates – Select each of the developers that should be able to test this app on the selected devices.
      3. Devices – Select each of the devices that the developers should be able to use in their testing.
   2. Distribution Profile – This file links together the Application Identifier and the Distribution Certificate. Remember, there is typically one Distribution Certificate per account, so this allows you to grant or revoke the ability to distribute an app. These need to be regenerated at least once per year.

Dependencies

I’ve touched on this in places above, but I want this to be perfectly clear to anyone that is having trouble with certificates or profiles. The Development and Distribution profiles are highly dependent on the integrity of the Application Identifiers, Devices and Certificates. Any change to those items will mean that either or both of the profiles will need to be regenerated. Luckily (for the profiles anyway), it’s just a matter of editing the profile, adding or updating the data (if any) and clicking Save. Once that’s done, you can download the new profile, give it to anyone on your team that needs it (anyone whose certificates are contained therein) and just by double-clicking on the new file, it will be installed on your system by Xcode.

The table below shows the dependencies of the Development and Distribution profiles. Any changes to the indicated items (including expiration of a certificate) will render the profile Invalid and require that it be regenerated.

Troubleshooting

Overall

If you’re getting errors during the build process, there’s usually some information about whether it is a Profile or a Certificate that is causing the trouble. The first thing you should do is go to your Apple Developer portal and under Certificates, Identifiers & Profiles check to make sure that none of your Certificates have expired and that all of your Profiles for the current project are still Valid and have also not expired.

Certificates

If for any reason you do not have both parts of the certificate you are trying to use, whether it’s the user’s Development certificate when building for your test devices or the Distribution certificate when trying to build for the App Store (or Enterprise), you’re not going to be successful. Both the public and the private key must be present on your machine for them to work.

It’s important to remember that these certificates can only be downloaded from Apple’s Developer portal once, after which downloading will only give you the public key. If you need to transfer a development certificate from one account to another (like if you replace your computer mid-year), you should find the certificate in your keychain, right-click on it and select Export. When the save dialog appears, make sure the file format is set to Personal Information Exchange (.p12), and set a password for the key after you click Save. When you take the exported key to your new account/machine and double-click on it, the system will ask you for the password and you should be all set.

Enterprise Distribution

If you are a Xojo developer using an Enterprise developer account to distribute iOS applications within your own company without going through the App Store, we highly suggest checking out 2021r3 or later as some important changes have been made to make your builds more successful.

This technique is more on par with the current Picture.SystemImage you use in your Xojo iOS apps. With it you will be able to set the following attributes:

• Glyph name. You can use Apple’s Symbols SF utility to view all the available symbols and the name associated with each of these.
• Size (in points)
• Weight. The weight of the SF Font, ranging from Ultra-Light to Black. This is an Enumeration value.
• Scale. The scale of the SF Font symbol, ranging from Small to Large. This is an Enumeration value.
• TemplateColor. If you want to tint the resulting glyph, you can provide a ColorGroup parameter (Desktop apps) or a regular Color parameter (Desktop, Console apps).
• FallbackTemplateImage. You can provide a grayscale / black and white image to use as a fallback image, in case there is no way to create a picture from the received “name” string.

As it is the case with the existing iOS method, you will receive a Picture. For example you will be able to use code like this in your desktop projects:

Var c As New ColorGroup(Color.Red, Color.White)
Var p As Picture = SystemImage("highlighter", 120.0, SystemImageWeights.UltraLight, Symbolscale.Small, c, fallback)

IVSFGlyph.Image = p

The “fallback” parameter refers to an image added to a desktop project that will be used if the glyph is not found. This will produce the following glyph, assigned as the image to the ImageView control named IVSFGlyph:

In order to add this kind of functionality to your Xojo Desktop and Console projects on macOS, add a new Module to the Navigator (for example, with the name macOSLib). Then, with the macOSLib item selected in the Navigator, add two enumerations with the following values:

• Name: SymbolScale
• Type: Integer
• Scope: Global
• Values:
  Small = 1
  Medium = 2
  Large = 3

• Name: SystemImageWeights
• Type: Integer
• Values:
  UltraLight = 0
  Thin = 1
  Light = 2
  Regular = 3
  Medium = 4
  Semibold = 5
  Bold = 6
  Heavy = 7
  Black = 8

Now add to the macOSLib module the method that will run both on Desktop and Console macOS apps:

• Method Name: SystemImage
• Parameters: name As String, size As Double, weight As SystemImageWeights = SystemImageWeights.Regular, scale As SymbolScale = SymbolScale.Medium, templateColor As Color, fallbackTemplateImage As Picture = Nil
• Return Type: Picture
• Scope: Global

Click on the cog wheel icon in the Inspector to change to the attributes section for the method, and make sure to set only the options displayed in the following picture:

Finally, put the following code in the Code Editor associated with the newly created method:

#If TargetMacOS

  If System.Version >= "11.0" Then

    If name = "" Then Return Nil

    Declare Function Alloc Lib "Foundation" Selector "alloc" (classRef As Ptr) As Ptr
    Declare Sub AutoRelease Lib "Foundation" Selector "autorelease" (classInstance As Ptr)

    Declare Function NSClassFromString Lib "Foundation" (clsName As CFStringRef) As Ptr
    Declare Function ImageWithSystemSymbolName Lib "AppKit" Selector "imageWithSystemSymbolName:accessibilityDescription:" (imgClass As Ptr, symbolName As CFStringRef, accesibility As CFStringRef) As Ptr
    Declare Function ConfigurationWithPointSize Lib "AppKit" Selector "configurationWithPointSize:weight:scale:" (symbolConfClass As Ptr, size As CGFloat, weight As CGFloat, tscale As SymbolScale) As Ptr
    Declare Function ImageWithSymbolConfiguration Lib "AppKit" Selector "imageWithSymbolConfiguration:" (imgClass As Ptr, config As Ptr) As Ptr
    Declare Function ColorWithRGBA Lib "Foundation" Selector "colorWithRed:green:blue:alpha:" (nscolor As ptr, red As CGFloat, green As CGFloat, blue As CGFloat, alpha As CGFloat) As Ptr
    Declare Sub SetTemplate Lib "AppKit" Selector "setTemplate:" (imageObj As Ptr, value As Boolean)
    Declare Sub LockFocus Lib "AppKit" Selector "lockFocus" (imageObj As Ptr)
    Declare Sub UnlockFocus Lib "AppKit" Selector "unlockFocus" (imageObj As Ptr)
    Declare Sub Set Lib "Foundation" Selector "set" (colorObj As Ptr)
    Declare Sub NSRectFillUsingOperation Lib "AppKit" (rect As NSRect, option As UInteger)

    Declare Function RepresentationUsingType Lib "AppKit" Selector "representationUsingType:properties:" (imageRep As Ptr, type As UInteger, properties As Ptr) As Ptr
    Declare Function InitWithFocusedView Lib "AppKit" Selector "initWithFocusedViewRect:" (imageObj As Ptr, rect As NSRect) As Ptr

    Var nsimage As Ptr = NSClassFromString("NSImage")
    Var orImage As Ptr = ImageWithSystemSymbolName(nsimage, name, "")
    Var symbolConfClass As Ptr = NSClassFromString("NSImageSymbolConfiguration")

    // Getting the weight as the required SystemImageWeight float
    Var tWeight As CGFloat = SystemImageWeight(weight)

    // Creating a configuration obj for the Glyph
    Var symbolConf As Ptr = ConfigurationWithPointSize(symbolConfClass, size, tWeight, scale)

    // Getting the final NSImage from the Glyph + Conf (still in vectorial format)
    Var finalImage As Ptr = ImageWithSymbolConfiguration(orImage, symbolConf)

    // Can't create image from received glyph name, so we return Nil if fallback is not provided
    // or colorize the fallback image if there is one
    If finalImage = Nil Then

      If fallbackTemplateImage = Nil Then Return Nil

      Var fallbackData As MemoryBlock = fallbackTemplateImage.ToData(Picture.Formats.PNG)
      Var fallbackDataPtr As Ptr = fallbackData

      Declare Function DataWithBytesLength Lib "Foundation" Selector "dataWithBytes:length:" (dataClass As Ptr, data As Ptr, length As UInteger) As Ptr

      If fallbackData <> Nil And fallbackData.Size > 0 Then

        Var NSDataClass As Ptr = NSClassFromString("NSData")
        Var NSDataObj As Ptr = DataWithBytesLength(NSDataclass, fallbackDataPtr, fallbackData.Size)

        If NSDataObj <> Nil Then

          Declare Function InitWithData Lib "AppKit" Selector "initWithData:" (imageInstance As Ptr, data As Ptr) As Ptr

          Var NSImageClass As Ptr = NSClassFromString("NSImage")

          finalImage = Alloc(NSImageClass)
          finalImage = InitWithData(finalImage, NSDataObj)

          AutoRelease(NSDataObj)

        End If

      End If

    End If

    If finalImage = Nil Then Return Nil

    Var c As Color
    Var nscolor As Ptr

    LockFocus(finalImage)

    // Applying tint to the image if we receive a valid ColorGroup object

    c = templateColor

    nscolor = NSClassFromString("NSColor")
    Var tColor As Ptr = ColorWithRGBA(nscolor, c.Red/255.0, c.Green/255.0, c.Blue/255.0, 1.0-c.Alpha/255.0)

    // We need to set the Template property of the NSImage to False in order to colorize it.
    SetTemplate(finalImage, False)

    Declare Function ImageSize Lib "AppKit" Selector "size" (imageObjt As Ptr) As NSSize

    Var tRect As NSRect

    tRect.Origin.X = 0
    tRect.Origin.Y = 0
    tRect.RectSize = ImageSize(finalImage)

    Set(tColor)
    NSRectFillUsingOperation(tRect, 3)

    // Getting bitmap image representation in order to extract the data as PNG.

    Var NSBitmapImageRepClass As Ptr = NSClassFromString("NSBitmapImageRep")
    Var NSBitmapImageRepInstance As Ptr = Alloc(NSBitmapImageRepClass)
    Var newRep As Ptr = InitWithFocusedView(NSBitmapImageRepInstance, tRect)

    UnlockFocus(finalImage)

    Var data As Ptr = RepresentationUsingType(newRep, 4, Nil) // 4 = PNG

    AutoRelease(newRep)
    AutoRelease(nscolor)

    // Getting image data to generate the Picture object in the Xojo side

    Declare Function DataLength Lib "Foundation" Selector "length" (obj As Ptr) As Integer
    Declare Sub GetDataBytes Lib "Foundation" Selector "getBytes:length:" (obj As Ptr, buff As ptr, len As Integer)

    // We need to get the length of the raw data…
    Var dlen As Integer = DataLength(data)

    // …in order to create a memoryblock with the right size
    Var mb As New MemoryBlock(dlen)
    Var mbPtr As Ptr = mb

    // And now we can dump the PNG data from the NSDATA objecto to the memoryblock
    GetDataBytes(data, mbPtr, dlen)

    // In order to create a Xojo Picture from it
    Return Picture.FromData(mb)
  End If

#EndIf

As you can see, this method calls the SystemImageWeight method, and also makes use of some Structs. Let’s add to the method that will convert the received enum value to the required CGFloat value needed by the Declare:

• Method Name: SystemImageWeight
• Parameters: weight As SystemImageWeights
• Returned Type: CGFloat
• Scope: Global

Add the following code in the associated Code Editor:

Var tWeight As CGFloat = 0

Select Case weight
Case SystemImageWeights.UltraLight
  tWeight = -1.0
Case SystemImageWeights.Thin
  tWeight = -0.75
Case SystemImageWeights.Light
  tWeight = -0.5
Case SystemImageWeights.Regular
  tWeight = -0.25
Case SystemImageWeights.Medium
  tWeight = 0
Case SystemImageWeights.Semibold
  tWeight = 0.25
Case SystemImageWeights.Bold
  tWeight = 0.5
Case SystemImageWeights.Heavy
  tWeight = 0.75
Case SystemImageWeights.Black
  tWeight = 1
End Select

Return tWeight

And now add three new Structures to the macOSLib module using the following values:

• Structure Name: NSOrigin
• Scope: Global
  X as CGFloat
  Y as CGFloat

• Structure Name: NSSize
• Scope: Global
  Height as CGFloat
  Width as CGFloat

• Structure Name: NSRect
• Scope: Global
  Origin as NSOrigin
  RectSize as NSSize

Add an overloaded method only intended for macOS desktop apps. The main difference is that this one can receive a ColorGroup parameter instead of just a Color object:

• Method Name: SystemImage
• Parameters: name As String, size As Double, weight As SystemImageWeights = SystemImageWeights.Regular, scale As SymbolScale = SymbolScale.Medium, templateColor As ColorGroup = Nil, fallbackTemplateImage As Picture = Nil
• Returned Type: Picture
• Scope: Global

And type the following code in the associated Code Editor for the method:

Var c As Color

If templateColor <> Nil Then
  c = templateColor
End If

Return SystemImage(name, size, weight, scale, c, fallbackTemplateImage)

Click on the cog wheel icon from the method Inspector and set the attributes as shown in the following picture:

Setting SF Glyphs directly to Views

Let’s add now a third method to the module whose main difference is that it will not return a Picture; instead, it will set the specified SF glyph as the image for the received control handler. For example, this is neat if you want to set a SF symbol to a button in you UI interface (among other UI controls).

This is the signature for the new method:

• Name: SystemImage
• Parameters: name As String, size As Double, weight As SystemImageWeights = SystemImageWeights.Regular, scale As SymbolScale = SymbolScale.Small, controlHandler As Integer
• Scope: Global

And the code to put in the associated Code Editor:

#If TargetMacOS

  If System.Version >= "11.0" Then

    If name = "" Then Exit

    Declare Function Alloc Lib "Foundation" Selector "alloc" (classRef As Ptr) As Ptr
    Declare Sub AutoRelease Lib "Foundation" Selector "autorelease" (classInstance As Ptr)

    Declare Function NSClassFromString Lib "Foundation" (clsName As CFStringRef) As Ptr
    Declare Function ImageWithSystemSymbolName Lib "AppKit" Selector "imageWithSystemSymbolName:accessibilityDescription:" (imgClass As Ptr, symbolName As CFStringRef, accesibility As CFStringRef) As Ptr
    Declare Function ConfigurationWithPointSize Lib "AppKit" Selector "configurationWithPointSize:weight:scale:" (symbolConfClass As Ptr, size As CGFloat, weight As CGFloat, scale As SymbolScale) As Ptr
    Declare Function ImageWithSymbolConfiguration Lib "AppKit" Selector "imageWithSymbolConfiguration:" (imgClass As Ptr, config As Ptr) As Ptr

    Var nsimage As Ptr = NSClassFromString("NSImage")
    Var orImage As Ptr = ImageWithSystemSymbolName(nsimage, name,"")
    Var symbolConfClass As Ptr = NSClassFromString("NSImageSymbolConfiguration")

    // Getting the weight as the required SystemImageWeight float
    Var tWeight As CGFloat = SystemImageWeight(weight)

    // Creating a configuration obj for the Glyph
    Var symbolConf As Ptr = ConfigurationWithPointSize(symbolConfClass, size, tWeight, scale)

    // Getting the final NSImage from the Glyph + Conf (still in vectorial format)
    Var finalImage As Ptr = ImageWithSymbolConfiguration(orImage, symbolConf)

    // We need to know if the received Handler can respond to the setImage message (that is, it's a View)

    Declare Function RespondsToSelector Lib "/usr/lib/libobjc.A.dylib" Selector "respondsToSelector:" (obj As Integer, sel As Ptr) As Boolean
    Declare Function NSSelectorFromString Lib "Foundation" (sel As CFStringRef) As Ptr

    Var sel As Ptr = NSSelectorFromString("setImage:")

    // We check if it's a valid handler, we have an NSImage object and the handler can receive the "setImage" message
    If controlHandler <> 0 And finalImage <> Nil And RespondsToSelector(controlHandler, sel) Then

      Declare Sub Set Lib "AppKit" Selector "setImage:" (control As Integer, Image As Ptr)

      // We set the NSImage to the received control
      Set(controlHandler, finalImage)

    End If

  End If

#EndIf

So, for example, you can set now the Gear symbol as the image of a PushButton control added to the app UI using the following code in the Open Event Handler of the PushButton instance:

SystemImage("gearshape.2", 14.0, SystemImageWeights.Regular, SymbolScale.Small, Me.Handle)

Summary

And that’s all! As you can see, there are no hardcoded codepoints for the SF glyphs. You’ll be able to create a picture from any SF symbol at the desired points size, weight and scale. Plus, you’ll be able to colorize it and receive a fallback image if anything goes wrong in the process.

You can download the example Xojo project with the Module already created from this link.

Google is making the right move here. In the overwhelming majority of cases, the paramount issue is that the user interface is consistent with other user interface experiences the user is likely to have on this same device. You only get that if you use native user interface controls. That’s why Xojo has always provided native user interface controls, high-level access to native system functionality and compiled to native code. Native provides the best experience for the end user which is what matters most. With most development tools, doing so requires a lot of extra work for the developers but reducing that should never come at the expense of a poor user experience. Fortunately, developers don’t have to make that sacrifice with Xojo.

Creating the best user experience extends beyond native controls. Developers must also look at what the customary design and behaviors of apps are on the target OS. Native controls help quite a bit with this but developers still must be vigilant and dedicated to avoid degrading the user experience.

I applaud Jeff Verkoeyen for making this difficult but correct choice. While there are a few categories of apps where custom user interface makes sense (games, kiosk apps), for all others, native is the best choice for creating the best user experience.