The Developer ID field was introduced in Xojo 2022r1, allowing you to fill in the developer certificate information needed for signing built macOS apps; however, it could be confusing to know exactly what information was expected.

• Developer ID Application
• Developer ID Application: Francisco Javier Rodriguez Menendez
• Developer ID Application: Francisco Javier Rodriguez Menendez (BW7PU32485)
• 7D767DB917A45A8976BEB5B92F04E8C18D09501A

And… which certificate should be used for Development builds, Direct Distribution, or Mac App Store publishing? That may not be obvious for someone new to all this.

Additionally, what happens if the entered data comes from an expired certificate or if the certificate isn’t in the Keychain?

The new approach: How it works

The Team-based signing chooser for the Mac Developer ID field follows these steps:

• Collects all the developer certificates found under the user Keychain.
• Groups the valid certificates by Team (what Apple designates as the TeamID).
• Based on the previous information, the new popup menu “Build For” will offer only the code-signing options available for the current selected Team:
  • Development. This is the equivalent to using the Apple Development certificate.
  • Direct Distribution. This is the equivalent to using the Developer ID Application certificate.
  • App Store. This is the equivalent to using the Apple Distribution certificate. In addition, the Publish feature will be enabled if, for the selected Team, there is also a valid 3rd‑party Mac Developer Installer certificate available.

If None is selected in the Developer ID popup menu, the macOS app will be built/debugged using Ad-Hoc signing.

Both menus update on the fly, so if new certificates are added (or removed) from the keychain, or if any have expired since last opened, both the Developer ID and Build For popup menus will reflect those changes.

macOS Certificates Inspector Window

Under the Teams popup menu, there is also an Inspect… option. When selected, it opens a new window where you can view and gather additional information for:

• Installed / Missing Apple Intermediate Certificates.
• Installed / Missing / Expired Developer Certificates, grouped by Team.

At a glance, you’ll see useful details for each certificate, such as:

• The expiration date
• The keychain where it is stored.
• Serial number, useful for identifying same-kind developer / intermediate certificates under different Macs.
• Issuer specific information.

Clicking any certificate provides more detailed information about the role it plays in the macOS signing process.

This Inspector is also useful in order to identify some of the most common issues related with the handling of certificates such as:

• Missing certificates for a given Team, determining thus the options that are available under the “Build For” popup menu.
• Expired certificates. These also determine the options that are available under the “Build For” popup menu for a given Team. In addition, if you want to do some cleanup, it is possible to delete these expired certificates directly from the Inspector without needing to open the Keychain Access app.
• About to expire certificates, so you are aware of it and the impact it could have on apps close to be distributed or on already created Provisioning Profiles, for example.
• Certificates with their private key missing. These can’t be used for signing purposes, so you will be able to re-install them in the keychain (if you have a backup) or install a new certificate.
• Developer Certificates where some of the required intermediate certificate is missing. You will be able to install the missing Intermediate (active Internet connection required).

Improvements to macOS Builds and Debugged apps

Although Sandboxing, Entitlements, and Provisioning Profiles have been part of macOS app development, this release brings several enhancements in these areas:

• Now it is possible debug Sandboxed apps directly from the IDE.
• Entitlements and Provisioning Profile are applied when the app is debugged from the IDE.
• Improvements in how the required Entitlements are added and signed when the macOS app is built; and also a better handling of the user-added entitlements and provisioning profile files (if required).
• Debugged and Built apps can be attached to the Instruments app. Among other things, Instruments can be used to detect issues such as memory leaks in the executed app. The IDE now automatically adds the required entitlement for this when: the app is debugged/built using the “None” (Ad-Hoc signing) from the Team popup menu, or, 2) when the app is built for Development (Build For) for a given Team.

When Build For is set to Direct Distribution or App Store, the required entitlement for Instruments to attach to the app, will be added only when the app is debugged from the IDE. If you want to use Instruments with a built app signed using these certificates, then you need to add that entitlement explicitly.

This decision is because when get-tasks-allow is set to True (the entitlement required in order Instrument being able to function), there are some well documented vulnerabilities that could be used to escalate privileges or inject code into your app. That’s not desirable for your distributed apps for sure (whether using Direct Distribution or if your app is installed through the Mac App Store).

Looking forward

We know there are still some areas to improve regarding code signing on macOS (and iOS) and we are working on some of them already. In the meantime, you’ll likely find the new Team-based Developer ID option more approachable, especially if this is your first experience dealing with certificates, signing, and distributing your freshly built macOS app.

A big THANK YOU to Richard Grafl for all his help and feedback during the beta-testing cycle of this feature.

Happy macOS code-signing!

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

Learn more about Code Signing in our recent series:

Code Signing on macOS: What Developers Need to Know

• Part 1, Get Started
• Part 2, Code Signing With Developer Certificates
• Part 3, Entitlements and Provisioning Profiles
• Part 4, How Xojo helps with Certificates, Signing and Distribution

For the past 20 years, Apple has increasingly tightened security measures when it comes to running apps distributed by third parties. Let’s take a look at this summarized timeline of code-signing and security measures added by Apple over years:

The most notable developments happened in 2011, 2012 and 2018, when terms like Sandbox and, especially, Containers, Gatekeeper, Hardened Runtime and Notarization were introduced and began to impact other pieces of the puzzle to consider when signing macOS apps. In fact, we could say that technologies such as code-signing, Sandboxing, Entitlements or Provisioning Profiles were among the first iOS technologies to make their way to macOS.

So here is an broad overview what these technologies mean:

• Sandboxing– When used, Sandboxing confines applications to a restricted, designated area of the system (its own “container”), preventing them from accessing user data, hardware or other apps without explicit permission. The system requires apps to ask for permission to use hardware resources or access user files. Sandboxing is mandatory for apps distributed through the Mac App Store.
• Gatekeeper- This technology is the primary security layer that checks whether a downloaded app comes from a verified/known developer, especially when the application has been Notarized by Apple.
• Hardened Runtime– Acts as a proactive, system-enforced shield that protects applications while they run, preventing malicious code from exploiting legitimate software. Enabling Hardened Runtime is required for Notarization.
• Notarization– Notarization is an automated security screening process run by Apple that scans software distributed outside the Mac App Store for malicious components and known security issues. Today, notarization is required for software distributed outside the Mac App Store that has been signed with the Developer ID application certificate. As a result of the process, notarization generates and staples a ticket, signed by an Apple certificate, to the app so Gatekeeper can trust it when executed.

So, basically, while Sandboxing is still optional for apps distributed outside the Mac App Store (i.e., signed with your Developer ID certificate), Notarization and Hardened Runtime are the recommended defaults. Enabling Sandboxing for your app is something you should consider based on the needs (features) and the privacy balance you want to offer your users.

If you plan to distribute the app through the Mac App Store as well, it will need to be Sandboxed and signed with your Apple Distribution certificate, while enabling Hardened Runtime is optional.

Entitlements and Provisioning Profiles

Entitlements and Provisioning Profiles are also required for many of these security measures, depending on the features and services your app uses, and they come into play during building and signing.

If you decide to go the Sandboxing route, then using Entitlements is mandatory. The good news is that Sandboxing entitlements are free to use (they don’t require creating or adding a Provisioning Profile to the project). However, if your app needs special access to the Keychain or uses iCloud, Apple Pay, or other services, you’ll need to create a Provisioning Profile in the Apple Developer portal.

Wait—what are Entitlements and Provisioning Profiles, and how do they relate to macOS app code signing?

Entitlements

Entitlements are XML-based .plist files (not unlike the app’s Info.plist) containing a set of key-value pairs. They are embedded directly into the app’s binary as part of the code signing process, typically using your Developer ID Application or Apple Distribution certificates.

Provisioning Profiles

While Entitlements are just a file, Provisioning Profiles are a different beast:

Provisioning Profiles must be created in the Apple Developer Portal. When you create one, you specify the App ID (the combination of your Team ID and the app bundle identifier which are case sensitive so pay attention). Even if you don’t plan to distribute your macOS app via the Mac App Store, you still need a Provisioning Profile, which requires creating an App ID first in the Developer Portal.

There are two kinds of Provisioning Profiles: Development and Distribution. As part of the provisioning profile creation, you must choose which type you will use.

• Development Provisioning Profiles are used while you’re developing your app; the app is signed with an Apple Development certificate and is intended to run on a set of Mac computers you’ve registered. During creation, you can add as many Apple Development certificates as you have under your Team ID.
• Distribution Provisioning Profiles are used when distributing your app. For direct distribution, sign with the same Developer ID certificate you’ll use for signing the app; for Mac App Store distribution, sign with the Apple Distribution certificate.
• Development and Distribution Provisioning Profiles do expire. This is something to keep in mind, especially when deploying new or updated versions of your app, because you may need to create new profiles.
• Development and Distribution Profiles are editable. If you make a mistake, note that both types can be edited in the Apple Developer portal, but only for certain fields: the App ID, the profile name, the selected certificate, and (for Development profiles) the included testing devices.

When Certificates and/or Provisioning Profiles expire…

We’ve already noted in previous articles that Apple Developer certificates expire one year after they’re created. We’ve also learned that if your app relies on a Distribution Provisioning Profile, that profile can expire as well. So, what does this mean for your already deployed apps?

No worries. Let’s focus first on directly distributed macOS apps (those signed with the Developer ID certificate) and pull one screenshot from the previous article:

Observe the highlighted Timestamp line. When the app is signed, the date is added automatically (retrieved from Apple’s servers). So, when a user runs an app whose embedded Developer ID Certificate has expired since its release, Gatekeeper will rely on that timestamp, compare it to the embedded certificate’s expiration date, and if everything matches—meaning it was signed before the certificate expired—the app will continue to work, provided the embedded certificate has not been revoked by the developer. In addition, if the app was Notarized, that helps a lot, because the stapled ticket includes its own timestamp and was signed with a longer-lasting Apple Certificate.

If the app is distributed through the Mac App Store, there’s good news. After you submit the app for distribution via App Store Connect and it passes Apple’s review, the app’s signing with your Apple Distribution certificate is replaced by Apple’s own signing. This means that users who install the app from the Mac App Store can continue to run it even if your original Apple Distribution certificate expired long ago.

Distribution Provisioning Profiles behave differently from others: once they expire, the app containing such a Distribution Profile will fail to execute.

The good news is that a Distribution Profile lasts for a very long time (around 18 years) so you’ll likely have ample time to create new distribution provisioning profiles and deploy updates that use renewed profiles well before users are affected.

Of course, as soon as any of your Apple Developer certificates expire, you already know how to request and install new ones in your Mac keychain.

Nearly Concluded

In the next, and last article, we will see how Xojo helps with everything related to signing and distributing your macOS apps. I’ll also show you how to deal with some of the most common issues related with certificates.

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

Code Signing on macOS: What Developers Need to Know

• Part 1, Get Started
• Part 2, Code Signing With Developer Certificates
• Part 3, Entitlements and Provisioning Profiles
• Part 4, How Xojo helps with Certificates, Signing and Distribution

But before we can reach our leaf developer certificates, we also need to have the Apple Development Intermediate certificates installed in our keychain. These are typically found in the Login keychain, though they can also be found in the System Roots or System keychains.

Installing Apple Developer Intermediate Certificates

Since Xcode 11.4.1 and later, these can be automatically downloaded and installed in the keychain, but if not, they can also can be downloaded from the Apple PKI webpage. The ones we are interested in are:

• Developer ID – G2
• Worldwide Developer Relations – G2
• Worldwide Developer Relations – G3
• Worldwide Developer Relations – G4
• Worldwide Developer Relations – G5
• Worldwide Developer Relations – G6

Note: The Developer ID – G2 certificate corresponds to the Developer ID Certification Authority. The WWDR certificates (G2–G6) correspond to the Apple Worldwide Developer Relations Certification Authority.

As you can see from the list, there are several versions (or generations) for the WWDR Intermediate certificate; so, which one should you download? The short answer: it depends.

On February, 7, 2023 the previous WWDR intermediate certificate expired; so Apple decided to rollout a new renewed version that will expire on February 20, 2030. As part of that update Apple issued additional Intermediate certificates to better segment the purpose of different certificates:

• G2: ECDSA signing for Apple Pay.
• G3: Software signing and Services.
• G4: Features supported by Apple Push Notification Service.
• G5: App Store Signing and Services.
• G6: ECDSA signing of Software and Services.

In practice, G3, G4, and G5 are sufficient for most scenarios.

Developer Certificates: The final goal!

To focus on the subject, what kind of leaf developer certificates are created from these two types of Intermediate certificates? This scheme will help:

As you can see from the above diagram, there are four main leaf certificates we will use to sign our macOS apps, based on their prefix:

• Developer ID Application. Use this one to code sign a macOS app distributed outside the Mac App Store.
• Developer ID Installer. Use this one to code sign the Installer, DMG or .pgk file of a macOS app distributed outside the Mac App Store.
• Apple Distribution. This certificate is required to code sign a macOS app sent to the AppStore Connect for its distribution through the Mac App Store.
• 3rd Party Mac Developer Installer. This Certificate is required to code sign the package of the app sent to the AppStore Connect. For example, when using the Publish feature from the Xojo IDE.

Creating and Installing the Developer Certificates

As stated in the first article of this series, you need a paid Apple Developer Program membership. Once that’s in place, the easiest way to install these required certificates in your macOS Keychain is through Xcode.

So, if it is the first time you need to install them on a Mac computer:

1. Go to Xcode > Preferences.
2. Select Apple Accounts.
3. Use your developer credentials to login into your developer account, or select it from the list if you are already logged.
4. Select the Team from the list.
5. Click the “Manage Certificates…” button.
6. Click the “+” popup menu in the lower-left corner of the resulting window, and select the developer certificate you want to install (all of these if it is the first time you install them).

Note: Under the hood, Xcode follows the same process described for installing the developer certificates manually.

If you prefer to go through the manual process instead:

1. Access the Apple Developer website.
2. In Certificates, Identifiers & Profiles, click Certificates in the sidebar.
3. On the top left, click the add button (+).
4. Under Software, select Developer ID, then click Continue.
   • Developer ID Application: This certificate is used to code sign your app for distribution outside of the Mac App Store Connect.
   • Developer ID Installer: This certificate is used to sign your app’s installer Package for distribution outside of the Mac App Store Connect.
   • Apple Development: Used to run and debug apps on macOS during development.
   • Apple Distribution: Used to sign apps for submission to App Store Connect.
   • Mac App Distribution: Used to sign macOS apps intended to be distributed through the Mac App Store.
   • Mac Installer Distribution: Used to send the macOS app to the App Store Connect for TestFlight or distribution through the Mac App Store.
5. Follow the instructions to create a certificate signing request.
6. Click Choose File.
7. In the dialog that appears, select the certificate request file (a file with a .certSigningRequest file extension), then click Choose.
8. Click Continue.
9. Click Download.
10. The certificate file (a file with a .cer file extension) appears in your Downloads folder.
11. To install the certificate in your keychain, double-click the downloaded certificate file. The certificate appears in the My Certificates category in Keychain Access.

It’s All About Identities

While Intermediate and Root certificates only have the Public Key on them, so they can verify other (leaf) certificates, the leaf certificates installed on your macOS Login keychain behave a bit different. Let’s see how.

Both if you use Xcode or create the CSR request manually to generate the developer certificates, using the Keychain Access app for that, in both of these scenarios a Private Key will be created and stored locally on your keychain as part of the process. Only the public key section of that private key is sent to the Apple servers so it can be included in the generated developer certificate. Once any of the possible developer certificates is downloaded and installed in the keychain, such certificate will have its private key associated with it:

The pair of the developer certificate and the associated private key is what is called an Identity.

Code signing With Developer Certificates

In fact, while we often say or hear “code signing with certificates,” the real signing of the app is done with the private key associated with that certificate. The certificate itself (and thus the public key portion of that key pair) is included in the signing process. This allows macOS to verify the signature each time the user runs the app

Do you remember the diagram showing how the “Ad-Hoc” code signing process works? Let’s compare it when the same process is done using a “Developer ID Application” Certificate… and, most important, the associated private key:

As you can see, in this case the data is cyphered using the private key from the developer certificate and, then, the certificate itself is stored as part of the app itself. So, if for example we build this time an empty Desktop app for macOS using the Developer ID Application, and open the resulting CodeResources file in a text editor we will see something different compared with the Ad-Hoc signed version:

In this case the field requirement associated with each file and hash value is significantly more strict. In fact, it makes reference to the Chain of Trust Gatekeeper is required to follow and validate. In plain English, the highlighted lines come to say something like:

1. Hey! make sure there is a Developer ID Application certificate (Apple Extension attribute —OID— 1.2.840.113635.100.6.1.13 for the X.509 certificate), for the developer with a TeamID BW7PU32485.
2. Next, verify such certificate is issued by the “Apple Developer ID Certificate Authority” (other of the Apple-specific X.509 extension, attribute or OID. In this case: 1.2.840.113635.100.6.2.6).
3. And finally, go down through the Chain of Trust and verify the previous one with the Anchor certificate (Apple Root CA, do you remember?)

So far so good. But how we can know if the app meets these requirements; and what about the certificates themselves? Well, it’s easy to check both using the codesign tool.

Open a Terminal window and type the following command:

codesign --verify -vvv "MyApp.app"

The output will be something similar to this:

As you can see in the highlighted lines, yes, it satisfies the Designated Requirements we saw in our CodeResources file! Also, the previous line states that it is valid on disk. That means:

• All of the expected files are present.
• There are no extra files.
• None of the files have been modified.
• A basic trust evaluation of the leaf certificate was successful.
• And it satisfies its own Designated Requirements (DR).

It is even possible to see the Chain of Trust for the code signature issuing:

codesign --display -vv "MyApp.app" 

And if you are curious enough, it is even possible to extract the embedded certificates stored in the CMS structure within the code signature:

codesign --display --extract-certificates "MyApp.app"

As result it will, usually, create three files. Take a closer look at the “Issuer” and “Subject” lines; specially on the Subject line for the OU value (Organizative Unit or, using Apple wording, the TeamID) for the codesign0 file. Do you remember the “leaf[subject.OU=BW7PU32485]” data from the CodeResources file? :

codesign0. This is the file for the Leaf certificate; in our example “Developer ID Application”.

codesign1. This one is for the Intermediate Certificate; in our example “Apple Developer ID Certificate Authority”.

codesign2. This one is for the Anchor Certificate; in our example “Apple Root CA”

As shown by the Issuer line in the codesign0 file for our “Developer ID Application,” it points to the previous certificate in the trust chain—the Developer ID Certification Authority. The codesign1 file for the extracted Developer ID Certification Authority points to the Apple Certification Authority in its Issuer field. Finally, the codesign1 certificate points to itself because, as the Root Certificate, it serves as the anchor for the trust chain.

Wrapping up

In this second article, we delved deeper into how Apple Developer certificates work, how a macOS app is signed (Ad-Hoc or with a specific developer certificate), and how the OS’s security features validate the signing when a user tries to run the app.

In the next article, we will cover more details about signing apps for the two main distribution types: Direct distribution and Mac App Store. We will also discuss what happens when certificates expire and how to troubleshoot the most common issues related to development certificates.

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

Code Signing on macOS: What Developers Need to Know

• Part 1, Get Started
• Part 2, Code Signing With Developer Certificates
• Part 3, Entitlements and Provisioning Profiles
• Part 4, How Xojo helps with Certificates, Signing and Distribution

This blog series provides a clear, practical overview of how certificates work, with a focus on signing and distributing macOS applications. Some concepts apply to digital certificates in general, while others are specific to the macOS code signing process. By the end of the series, you’ll understand what certificates are, why they matter, and the role they play when building and distributing a macOS app.

The Developer ID field in the Build Settings > macOS > Sign Inspector Panel is our starting point:

By default, this field is empty. When you click Build, the app bundle (and its contents) is signed using a more relaxed security configuration. This does not require an explicit developer certificate and does not verify that the app comes from a known, trusted developer.

This type of signing is called Ad-Hoc signing. It is perfectly fine when debugging from the IDE or when building apps you intend to run locally.

In earlier versions of macOS, it was even possible to distribute and run Ad-Hoc–signed apps on other Macs, as long as the user explicitly chose to trust them. While this is still technically possible on recent versions of macOS, Apple has continued to tighten security, making it increasingly difficult for users to launch Ad-Hoc–signed applications.

In most cases, Gatekeeper will intervene and prevent the app from launching. Since the system cannot verify the identity of a trusted developer, it treats the app as unverified. With Ad-Hoc signing, macOS can only confirm that the app has not been modified since it was signed, it cannot validate who created it.

Under the hood: How “Ad-Hoc” signing works

Every time an app is signed (including all the contents inside its bundle) macOS uses Apple’s codesign tool. When Ad-Hoc signing is applied, the simplified process works roughly like this:

• A hash value (a unique digital fingerprint) is calculated for every file in the app bundle, whether it is executable or not, as well as for the bundle itself.
• These hash values are stored inside the app bundle, in the _CodeSignature folder.
• If the app contains multiple architectures (for example, x86 and ARM), the process is repeated for each supported architecture.

When a user double-clicks the app to launch it, macOS performs a similar verification process:

• It recalculates the hash value for every file in the bundle.
• It compares the newly calculated values with those stored in the _CodeSignature folder and if any hash differs from the stored value, macOS determines that the bundle has been modified since it was signed and it will refuse to launch the app.

Want to see this in action? Create a new Desktop project in the Xojo IDE, save it to your Documents folder, and build it for macOS.

Next, locate the built app in Finder. Control-click it and choose “Show Package Contents.” Then open the Contents > _CodeSignature folder and inspect the CodeResources file using your favorite text editor. You’ll see a list of hash values and digests corresponding to every file in the app bundle.

Apple Developer Certificates: Establishing Trust on macOS

What must you do so your apps are recognized as first-class citizens on macOS and can be distributed without Gatekeeper intervening? The answer is likely familiar: enroll in the Apple Developer Program (currently US $99 per year).

Among its many benefits, membership in the Apple Developer Program allows you to create your own Developer ID certificates. When you use these certificates to sign your apps, macOS can validate the signature and identify you as the verified developer distributing the software.

But how is this trust established and verified? To answer that, we need to start at the very root, literally!

Every computer, smartphone, tablet, and many other devices come with preinstalled Root Certificates. These certificates are issued by trusted organizations known as Root Certificate Authorities (CAs), including Apple. They serve as the foundation of a chain of trust, allowing other certificates issued by those authorities to be verified.

Technically speaking, a Root Certificate Authority (CA) is the top-level trusted entity in a public key infrastructure (PKI). It issues self-signed root certificates that act as the trust anchor for verifying other digital certificates. In other words, it is the foundation upon which the entire certificate trust model is built.

It is easy to take a look to these installed on your Mac:

1. Open Keychain Access.
2. Select Certificates at the top of the window.
3. In the sidebar, choose System Roots.
4. You will then see the complete list of root certificates trusted by macOS.

You’ll notice that there are three different Apple Root CA certificates. Why?

Each X.509 certificate contains detailed metadata defining its cryptographic properties and permitted usage. This includes the key type (such as RSA or ECDSA), the public key length, and the signature algorithm used.

• Apple Root CA: Is a RSA type, with a public key length of 2048 bits that uses the SHA-1 algorithm.
• Apple Root CA-G2: Is a RSA type, with a public key length of 4096 bits that uses the SHA-384 algorithm.
• Apple Root CA-G3: Is a ECDSA type, with a public key length of 384 bits that uses the SHA-384 algorithm.

Intermediate Certificates and the Chain of Trust

Root certificates are highly valuable and sensitive, so they are rarely used directly to sign end-user certificates (also called “Leaf” certificates). In the case of macOS app development, the developer’s certificate is the Leaf. This is where Intermediate Certificates come into play.

In simple terms, Intermediate Certificates are signed by Root Certificates and, in turn, are used to sign Leaf certificates. This protects the Root certificate from direct exposure. Together, the Root, Intermediate, and Leaf certificates form what is called the “Chain of Trust.”

The Chain of Trust verification starts with the Leaf certificate and works upward through the Intermediate to the Root. This same process occurs whenever you visit a secure website, make an online payment, or transmit sensitive data securely.

For example, the Leaf certificate is validated against its Intermediate certificate. If the Intermediate certificate is missing or expired, the Leaf certificate is considered invalid. Similarly, the Intermediate certificate itself must be validated against the Root certificate. If the Root certificate is missing or expired, the Intermediate is invalid, and all Leaf certificates signed by it are also invalid.

The same process happens when you sign your macOS apps: macOS validates the entire certificate chain before allowing the app to run.

Finally, certificates closer to the Root generally have longer validity periods. Leaf certificates must be renewed more frequently, while Root certificates are valid for many years.

Wrapping up

In this first article, we covered the fundamentals of digital certificates and their role in macOS app security. In the next article, we will focus specifically on Apple Developer certificates and how they enable trusted app distribution.

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

Code Signing on macOS: What Developers Need to Know

• Part 1, Get Started
• Part 2, Code Signing With Developer Certificates
• Part 3, Entitlements and Provisioning Profiles
• Part 4, How Xojo helps with Certificates, Signing and Distribution

Starting with 2025r1, there’s no longer any need to delete an existing Keychain item just to update its password. All you need is a KeychainItem instance with a non-zero Handle, in other words, a properly initialized item. And the best way to get a reference to an existing KeychainItem is by using the System.Keychain.FindPassword method. For example, the following code snippet from a method with the signature FindPassword(serviceName As String) As KeychainItem:

Var itemToFind As New KeychainItem
Var password As String

// Name to find
ItemToFind.ServiceName = serviceName

// Get the password
password = System.Keychain.FindPassword(itemToFind)

Return itemToFind

Catch e As KeychainException
  Return Nil

This retrieves the password for a given Keychain item stored under the Service Name passed as the serviceName parameter. If the call to System.Keychain.FindPassword raises a KeychainException, it means there’s no password stored in the Keychain for that Service Name so we return Nil. But if the method successfully retrieves a password, it means we have a valid, properly initialized KeychainItem we can use to call UpdatePassword.

For example, create a new method with the following signature:

Public Sub CreatePassword(pass As String, label As string, serviceName As String)
  // Let's see if we have a password for the item already.
  // If that is the case, we need to update it instead of
  // creating it!
  
  Var itemToFind As KeychainItem = FindPassword(serviceName)
  
  // If we don't get a Nil KeychainItem, that means that we should
  // update the password for such KeychainItem, instead of creating a new one!
  
  If itemToFind <> Nil Then
     itemToFind.UpdatePassword(pass)
  Else
    // We got a Nil KeychainItem… what means that there is not
    // such item in the user Keychain yet, so let's create it.
    
    itemToFind = New KeychainItem
    itemToFind.Label = label
    itemToFind.ServiceName = serviceName
    System.Keychain.AddPassword(itemToFind, pass)
  End If
  
  Catch e As KeychainException
    MessageBox("Keychain error: " + e.Message)
    
End Sub

As you can see, this method takes three string parameters: the password you want to set or update, the label to use for the Keychain item (particularly useful when adding a new password for a given Service Name) and the Service Name itself, which is associated with the password.

The first thing this method does is call the FindPassword method we saw earlier. If it returns a non-nil object, we simply update the password. However, if the FindPassword method returns a nil object, we create a new KeychainItem from scratch using the provided label and serviceName parameters, then add the new password to the user’s Keychain.

Download this example project to experiment adding, deleting and/or updating passwords to your macOS Keychain.

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

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

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

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

Before we jump into the topic, it’s worth mentioning that this is new in Safari 17, but it is a W3C Standard that might work with other combinations of browser and operating system.

One of the biggest advantages of creating a web app is that users won’t need to update it manually. Once a new version is deployed, a browser refresh will be enough to update- which Xojo handles that automatically. If we are talking about a large company with hundreds of computers, it’s easy to see how having a web-based Intranet, for example, would reduce maintenance costs.

Step by step, browser vendors are allowing developers to access APIs that are traditionally reserved for native desktop or mobile developers.

Adding Icon Badges

When users add a web application to the Dock, developers have the opportunity to set a numerical badge. This helps let the user know the amount of items requiring attention.

Missed calls, unread message notifications or the minutes pending in a Pomodoro session. The meaning of the badge value is determined by you.

This Web API is pretty easy to use in Xojo. Add a few new public methods to the Session object, called SetBadge and ClearBadge, respectively.

SetBadge (amount As Integer)

Var js() As String

js.Add("if ('setAppBadge' in navigator) {")
js.Add("  navigator.setAppBadge(" + amount.ToString + ");")
js.Add("}")

ExecuteJavaScript(String.FromArray(js))

ClearBadge

Var js() As String

js.Add("if ('clearAppBadge' in navigator) {")
js.Add("  navigator.clearAppBadge();")
js.Add("}")

ExecuteJavaScript(String.FromArray(js))

That’s it. Whenever you need to display a badge for that user, call Session.SetBadge(42), for example.

Creating a Manifest File

While is not required, a web app manifest file will allow you to tweak the look and feel of the application when added to the Home / Dock.

In order to let the OS know there is a Manifest file, add a new HTML header. Go to App -> HTML Header and add this line:

<link rel="manifest" href="/manifest.json" />

Let’s fill in the contents. We have to handle that “/manifest.json” URL. Add a new Event Handler in the app object, select the “HandleURL” event.

This is an example of how to create that file:

Select Case request.Path
Case "manifest.json"
  Var manifest As New JSONItem
  manifest.Value("display") = "standalone" // Remove back/forward buttons
  manifest.Value("name") = "My Xojo Application"
  manifest.Value("short_name") = "Xojo App"

  response.MIMEType = "application/json"
  response.Status = 200
  response.Write(manifest.ToString)
  Return True
End Select

You can check the whole list of parameters available from this website:
Web app manifests

Debugging Web Apps

Hey! Where are my Developer Tools!?

You can’t directly debug a web app from the app itself. But if needed, you can still open Safari, press on the Develop menu and, from there, access a Developer Tools instance for any web app that is opened:

That’s All!

While a web app is far from a native desktop app, changes like this make the the gap a little smaller and the user experience a little better.

Happy coding!

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

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

Xojo creates native apps and uses the native user interface toolkit on each platform. This is important from the end-user’s point of view – we’ve all used apps that didn’t feel quite right, often Java or Electron-made apps. But it’s also important from the developer’s point of view because many of these design changes are effectively done for you.

A good example of this is Sheet Windows. A Sheet Window is a modal dialog that prompts the user to save unsaved work or print a document etc. In previous versions of macOS, it unfurled downwards from the title bar of the document in question. In Big Sur, this behavior changed and a Sheet Window is now a rounded window that simply floats on top of the parent window. Regardless of one’s personal opinion on whether this is a good change or not (hint: it’s not), a good app should appear and work as each platform dictates.

There is no need to “fake” these new rounded dialogs by trying to create them yourself – you simply continue to select “Sheet Window” as the window type in Xojo’s Inspector. On pre-Big Sur versions of macOS, a Window of type Sheet Window will unfurl as it always did. On Big Sur, it will appear as a floating rounded rectangle. 

MessageDialog is another good example of the benefits of developing native apps, with its stacked button design on Big Sur. Again, your MessageDialogs will look correct on each version of macOS, which means less work for you!

Gavin Smith has been using Xojo (and its predecessors) since 1998. You can email him at gavin@libertyapp.com or follow him on Twitter @gvnsmth.

Whatever solution we come up with in the future will ultimately require a Mac to build for macOS. If you are developing applications for any OS, testing them on that OS is highly recommended anyway. For those of you who use Xojo primarily on Windows and Linux we know this is far from ideal and if a solution is viable in the future, we will certainly explore it. Because the Xojo IDE is cross-platform, you can continue to develop on your Windows or Linux machines even though you’ll need a Mac when it comes time to test and compile for macOS.

UPDATE (Aug. 31, 2021) – We have found a solution for this and have now added building and remote debugging for macOS from Windows and Linux to the Xojo Roadmap.

Download mp3.

Topics

• Xojo 2020r2 Download
• Xojo 2020r2 Release Notes
• Xojo Team
• Windows & Linux on M1 Macs

Well, not to worry as both Apple and Xojo have your back.

For most people, you actually don’t have to do anything because of an amazing Apple technology called Rosetta 2. Built into Big Sur, Rosetta 2 is a translation technology that automatically converts most x86-64 (Intel 64-bit) app binaries so that they can run on an Apple Silicon Mac. To you and your users, this process is entirely transparent. Most apps won’t even have a noticeable performance difference. Because of Rosetta 2, moving to Apple Silicon Macs will be painless for all.

For the best possible performance you will want to take advantage of another Apple technology called the Universal Binary. A Universal Binary app looks the same as a regular app, but it contains one version of the app that can run on x86-64 (Intel 64-bit) and another that can run on Apple Silicon.

Starting with Xojo 2020 Release 2 (download now!) you’ll be able to build Universal Binary apps! All you’ll have to do is go to your macOS Build Settings and change the Architecture from “x64 (64-bit)” to “Universal” and re-build your project. Xojo does everything else for you.

Note that if you use plugins, you’ll have to get updated plugins that include Apple Silicon components from the plugin author in order to build a Universal Binary.

Uniform Type Identifiers (UTIs) are one of the many often misunderstood parts of building native macOS apps. While they’re not just for specifying file types, that’s what I’m going to focus on today. First, a little background:

Uniform Type Identifiers are the successor to Apple’s Creator and Type codes that were used in MacOS Classic 15+ years ago. Back then, every mac application had a creator code (Four characters) which had to be unique and therefore registered with Apple for use in an app. Then, each file type that you wanted to create also needed a unique code. Common types were TEXT for text files, APPL for applications and RTFd for RTF documents. This was their attempt to keep from having file extensions and while it “worked” there were some severe limitations.

When MacOS X appeared on the scene, file extensions became a necessity again what with their BSD Unix underpinnings and when 10.6 was released, Apple revisited their position on exposing users to extensions again. (Don’t get me wrong, macOS does an excellent job of hiding extensions from users that don’t need to see them and exposing them to users who do. As an old-school user, I’m grateful for that.) This meant that they had an opportunity to update their antiquated system for application and file type association. 

At first glance, wrapping your head around UTIs may seem a little daunting, but let’s break it down for you:

1. First, your application needs a valid Bundle Identifier. This setting is found in the macOS build target settings and its value is in reverse domain name format. While it’s not required, I suggest you use your personal or company domain name to form this identifier. If your domain was example.com, the bundle identifier would look like com.example.myappname.
2. Next, you’ll need to add a special kind of File Type to your app. Add a “File Type Set” to your project and add a new type by clicking the + button at the top of the editor.
   1. Give your type a name like “FolderWithIcon”.
   2. Assign a UTI Identifier. This must start with the same reverse name that you used for your bundle identifier when making file types for something that your app creates. For example: com.example.myfolder. This value must be unique within your app.
   3. Add “public.folder” to the Conforms To field. This value represents the other type(s) of files that your type is associated with. For more information see Apple’s list of public identifiers.
   4. Set the Extensions field to “.myfolder”. This value must be unique within your app.
   5. Set UTI Type to Exported
   6. Add a unique folder icon to your file type.
3. In places where you want to have these custom folders all you have to do now is add the extension and then hide the extension from the user:

   Dim f As FolderItem = SpecialFolder.Desktop.Child("Test.myfolder")
   f.CreateAsFolder
   f.ExtensionVisible = False

4. Build your app (running won’t always work). Note: macOS reads these specs right from the latest version of your app and caches them, so if you need to update your icon you’ll need to at least increase your app’s non-release version number.

That’s all there is to it! From now on, when you create a folder in your app, it’ll get your snazzy new icon!

If you have a 32-bit app on Catalina, it now looks like this in the Finder:

And if you try to run it you get this message:

As previously noted last year, Xojo will only support building 64-bit Mac apps in a future release.

So if you haven’t done it already, time is running out for you to get your own projects and apps updated to 64-bit. Fortunately this can be pretty easy with Xojo. First you’ll have to change the build architecture from “x86 32-bit” to “x86 64-bit” and then test and build your app. You may need to upgrade any 3rd party plugins you use and if you are using any Declares then you should also review them for possible updates.

To learn more about getting your projects ready for 64-bit, check out the 64-bit Guidelines topic in the User Guide.

Download mp3.

Show Notes

• tvOS 13
• iOS 13
• iPad OS
• Mac Pro
• MacOS Catalina
• Xojo iOS Dark Mode Support

In an engineering meeting, I mentioned a discussion I had with a user about the speed of the Layout Editor and Travis said he had recently been reminded of how slow it was too. While most of the time issues in Xojo are carefully calculated and prioritized for maximum bang for the buck (as we say around here), that’s not always how it happens. After the meeting, Travis decided to dive into the Layout Editor code and see what could be done to speed it up.

The results are pretty remarkable.

The video below tells the story best.

The difference is greatest for layouts with a lot of controls.

To optimize for speed, we made two changes:

1. On all platforms, selecting and dragging controls now only re-renders those controls that are selected. A buffered image (picture) is taken with everything but the selected controls, and thus only the selected controls have to be drawn on top of that as they move. This is an improvement from before, where every control was re-rendered in every frame whether it was moving or not.
2. The second optimization is Mac-specific. Some controls take a long time for macOS to draw and composite. In particular, controls like Group Boxes in Dark Mode can take a while. We now keep a cached copy of the rendered control from the operating system, and use that unless its size or properties change. That way, we don’t need to wait for macOS to draw the control every time we want to display or move it on the screen.

If you have layouts with lots of controls, check out 2019r1. You’re in for a pleasant surprise.

To activate dark mode in Mojave, go to System Preferences, click General and select the “dark” appearance. The entire UI will switch to a darker, more muted color scheme which can be easier on the eyes, especially at night.

Here is what the Xojo IDE looks like in dark mode:

In order for your apps to support dark mode you’ll have to rebuild them with Xojo 2018r3 with its support for dark mode. Once you open your project in 2018r3 go to Shared Build Settings and turn on the Supports Dark Mode property:

Note: This property defaults to OFF for existing projects and ON for new projects.

This will automatically cause the Xojo built-in controls to switch to dark mode when you run your app in dark mode on Mojave. Here is Eddie’s Electronics running in dark mode:

For your own graphics and custom controls you may need to update your drawing code so that you use darker colors and icons when in dark mode. There is now a new IsDarkMode global method that you can check to see if your app is running in dark mode so that you can choose a different color or image.

The App.AppearanceChanged event is called when the user switches between light and dark modes or when the accent color changes. You can use this to tell your UI to update or redraw as necessary.

Read more about this change and others coming to Xojo graphics and the IDE in this post. To learn how you can update your apps to work in dark mode, refer to the Dark Mode topic in the documentation.

With Apple’s announcements at WWDC 2018 and the introduction of dark mode it was time to revisit our graphics and the overall appearance of the IDE again. Here are some things which contribute to the changes that have been made and ones that you will see in the coming months.

Dropping macOS 10.9

Xojo 2018r3 drops support for macOS 10.9 and as the last version which had the skeuomorphic design elements all of our supported OS’s now have the flatter modern design. It’s not that this has held anything up per se, but it’s a good reminder that “it’s time”. 

To that end, we have taken that opportunity to remove some of the graphics that make the IDE look out of place and doing so subtly lowers the memory footprint and accelerates drawing of the IDE itself across all platforms. We’re also using a variation of Apple’s image templates which has somewhat reduced the on-disk footprint of the IDE itself.

macOS Dark Mode

Apple’s addition of a darker variant of the visual “Aqua” theme in macOS means that we needed to do an audit and update of several of our base framework controls so that your apps would render correctly as well as ours. 

Events

While it probably won’t be used very often (how often does one change themes while running a piece of software, besides the novelty of seeing it happen), we added an event to the App class named AppearanceChanged to notify you when the user changes from light to dark or changes their accent color. This is a good place to clear any graphic or color caches which contain theme specific UI graphics. 

Methods

There is also a new global method called IsDarkMode(Boolean) which will return True if your app is running with the Dark Mode theme on macOS 10.14 or higher. If your app is running on 10.13 or lower or in light mode on 10.14, IsDarkMode will return False.

Build Settings

Enabling Dark Mode in your apps is as easy as flipping a switch in the Shared Build Settings. Unfortunately, because Apple made the assumption that most apps would “just work” versions of your apps compiled with older versions of Xojo will either need to be recompiled with Xojo 2018r3 or you’ll need to push out a new version with a plist entry to prevent macOS 10.14 from showing your app dark in Dark Mode. 

Testing

When testing apps for use with Mojave’s dark mode, I seriously suggest that you test on a system that allows you to see the translucency effects of dark mode. Virtual Machines are usually really handy for testing, but in this case, Parallels Desktop 14, VirtualBox 5.2 and VMWare Fusion 11 do not show the subtleties of dark mode.

Colors

One of our goals at Xojo is to remove some of the headaches involved with the minutiae of each OS that you deploy for and to that end, we wanted to make drawing custom controls easier too. What this means is that the built-in global colors are largely theme aware now and will change depending on whether your app is running in light or dark mode on macOS. This affects things like TextColor, FillColor, FrameColor, HighlightColor, etc, so if you use those methods when drawing in pictures and canvases, you will want to audit that code. If you want a specific color, you should use a color constant. For instance, use &c000000 if you want black because TextColor will now return white in Dark Mode. 

In terms of the framework controls themselves, we are taking this opportunity to make some changes to make your apps appear better in the macOS 10.10+ ecosystem. Ever notice that a Label control and the text portion of a CheckBox or RadioButton control are not exactly the same color? Going forward, the default colors of controls which should automatically change between Light and Dark modes will do that. So if you have a Label using the default color of &c00000000 (Black with Transparency = 0), the color that is actually used is what Apple calls labelColor. It’s still black, but is a tiny bit translucent. TextFields and TextAreas will automatically change text, placeholder, selection and background colors to match the Apple prescribed colors for automatic Light/Dark compatibly. We think you’ll find that building your apps with 2018r3 will largely make them just behave and appear the way you expected them to.

IMPORTANT NOTE: These color and framework changes affect how your apps draw on all versions of macOS, so make sure you try them out on your 10.10 through 10.14 VMs before shipping!

Eating our own dog food

One thing we hear from users every so often is the desire for Xojo to use our own products for building apps. As most of you know the IDE itself is written in Xojo, but we also have several other apps (big and small) that are written in Xojo.

• Feedback – Our bug reporting system
• Xorders – Our internal order system
• Lingua – The Xojo localization app
• Remote Debugger – The remote debugger stubs for desktop and console

While the 2018r3 cycle was in progress, all four of these projects got updated for Mojave’s Dark Mode and definitely helped us find framework rendering bugs early on in the pre-release process.

What about Windows and Linux?

The TL;DR version is that we’re still looking into it. 

Currently there are several different ways to change Windows 7, 8 and 10 to use a dark interface, not all of which are compatible with the Xojo Framework controls and the Windows 10 2018 Fall Update promised yet another way but that ended up only being for UWP. We are looking into which method gets you the most “bang for the buck” so to speak. 

In January 2018 Apple stopped accepting 32-bit app submissions to the Mac App Store.

In February 2018, starting with macOS 10.13.4, Apple added a warning that displays the first time you launch a 32-bit app.

In June 2018 Apple stopped accepting updates to 32-bit apps in the Mac App Store. All new apps and app updates must now be 64-bit.

At WWDC 2018 Apple announced that macOS 10.14 will be the final version that support 32-bit apps. Although they did not announce a release date, based on the timing from the past few years macOS 10.14 will probably be released around the end of September 2018.

In addition, Apple also released the Xcode 10 beta at WWDC 2018. Although not widely publicized, this version of Xcode no longer supports building 32-bit macOS apps.

So this is now the situation for macOS apps:

• All versions of macOS currently supported by Xojo can run 64-bit apps.
• Xcode will soon only support 64-bit Mac apps.
• Apple now requires 64-bit apps on the Mac App Store.
• Apple does not spend time fixing bugs related to their 32-bit APIs.

Here at Xojo, there are new features we’d like to support, either directly in the framework or via Declares, but they require that we update to newer macOS SDKs and 64-bit.

Due to all these factors, Xojo will only support building 64-bit Mac apps in a future release. Before this happens we are working on some improvements, such as 64-bit incremental compilation, to continue to make this transition as smooth as possible.

Note that this does not affect the ability to build 32-bit apps for Windows and Linux, something that remains necessary as those operating systems still have 32-bit versions that are in wide, supported use today.

We recommend that all users who create Mac apps move them to 64-bit soon so that your apps remain compatible with Apple’s App Store rules (if you use that) and future macOS versions.

For those that continue to need to build 32-bit Mac apps, we will (as we have always done) keep available older versions of Xojo that you can use to build 32-bit macOS apps, accessible using the Archives section of the web site when you are logged in with your Xojo account.

Transitions often bring some headaches which are sometimes necessary for progress to continue.

Most of the time you will reference the Foundation and AppKit libraries, but there are many other libraries as well. Xojo Declares use the Objective-C names so be sure to refer to those in the documentation rather than the Swift naming.

When you call Cocoa methods, you supply the method name using the Selector part of the Declare command. The selector name has to end in a “:” if there are any parameters that are passed, an oddity of how Objective-C works. Unlike with Xojo methods, the case of the name also has to match exactly. For the Xojo Declare, the first parameter is always required and must be a reference to the class containing the method you are calling.

To start with a simple example, consider that you may to center a window on the screen. You can obviously do this by manually adjusting the window’s Top and Left properties by taking into account the window size and the screen size, but Cocoa has a simple center function that can be used on a window.

On macOS, a Xojo window is actually a native NSWindow. When you view Apple’s docs for NSWindow you’ll see there is a center method. This method is very simple as it does not take any parameters. Looking at the doc page you should note that this function is in the AppKit library. Now you can create a Declare command to map to the center method:

Declare Sub centerWindow Lib "AppKit" Selector "center" (windowHandle As Integer)

Remember, even though the center method does not take any parameters, you still have to add a parameter to the Declare so you can pass in the reference to the calling class, which in this case is the window to center.

You can call this method like this (such as from a button’s Action event handler):

centerWindow(Self.Handle)

Because this method is called for a window, you can put it in a Xojo Extension Method to make it easier to call. To do this, create a global method on a module like this:

Public Sub Center(Extends w As Window)
  #If TargetMacOS Then
    Declare Sub centerWindow Lib "AppKit" Selector "center" (windowHandle As Integer)
    centerWindow(w.Handle)
  #EndIf
End Sub

Note the use of the “#If TargetMacOS” line. This prevents this code from being compiled into Windows or Linux builds of your app where the code could possibly crash your app.

This now allows you to have code like this on a window’s Open event to center the window:

Self.Center

To learn more about macOS Declares:

• Calling Native macOS APIs
• Mac Declare Samples