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

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

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

Electron is a framework for building cross-platform apps using HTML, CSS and JavaScript. Essentially, it’s for building web apps that run locally rather than from a server. They are cross-platform in as much as HTML is. Some elements of HTML can be native such as textfields but not all elements are.

This is where we see the advantage of writing a native application. Native apps utilize more of the look and feel of the host OS and thus appear and behave more inline with the end user’s expectation. At Xojo, we use Slack for text chatting. On desktop operating systems such as MacOS and Windows, Slack is an Electron app. As such it doesn’t look and feel like other desktop apps. It also suffers (needlessly as I understand it) from the fact that it does not auto-correct as you type the way nearly every other native desktop app does. It’s interesting to note that the mobile version of Slack, which is a native app, does auto-correct text as you type just as you’d expect. This makes the native version pleasant to use and the Electron-based version annoying. It’s unfortunate, because I use the Electron-based version far more than the native version simply because I spend a lot of time on my computer everyday. I’ve been told that the Electron-based version could be made to auto-correct but I’m suspicious of this because if it were easy, I have to believe that the fine folks at Slack would have done so long ago.

Slack no doubt chose Electron upon which to base their product because of the time it would save them building it. They could focus on what makes their app unique rather than all the details of Linux, macOS and Windows. While that’s a sensible goal, Electron may not have been the best choice. It’s possible (perhaps even likely) that Slack didn’t know Electron was using private APIs. I’m surprised that those behind Electron would not have the foresight to realize the significant negative impact of using private APIs but sometimes as humans we get so far down the path with something only to run into a show stopping obstacle at the last moment that we begin to become more morally flexible in order to reach our goal. This is of course short-sighted and can come back to haunt us. We could have done the same with Xojo, but we didn’t nor would we. We always strive for what is right over what is easy.

One of the comments on the blog post I linked to above said that perhaps Slack would now choose to write a native app. I’m doubtful about this. However, that is what Slack should do. A native app would provide a better end user experience and that’s what ultimately counts. It’s all well and good to save development time but if the result is a user experience that annoys the end user, then the saved development time wasn’t worth while.

There are options (Xojo among them) for building cross-platform native applications. Xojo has a lot of text-parsing functions and our TextField control has built-in support for both spellchecking and auto-correct because it’s a native control on all platforms. This is something that we provide to Xojo users nearly for free because we use native controls. It’s another example of why native applications are inherently better.

If you want your app to provide the best user experience, it should be native on whatever platform it runs. HTML is great for the web because that is the native way to create web pages. Anyone who ever tried a Java app running in a browser knows how unnatural that feels. On the desktop or mobile, the app should be written using native (and public) APIs. In the end, software is for the user and should be written first with their user experience in mind. Saving time with a particular tool or framework is a secondary consideration.

Update: Electron has submitted an update to resolve the private API issue.

This is all just to say that app-making is nothing like building a house. It’s more like building the first house ever in the history of houses, with a pile of rusty nails and your bare hands, in a non-stop tornado. It’s different every time, and it’s astonishingly complex, non-linear, and unpredictable … The only reason anything ever ships is because people just keep working until it’s ready.

*emphasis mine

And if you have any doubt of the truth of this, just look at software projects that ship on a pre-defined schedule rather than when they are ready.

Making sure everyone knows about your new app or latest update is really important. I have been in PR/Marketing for many years and have seen it all! The biggest mistake I see is developers forgetting to put a link back to their website or sitelet when talking about their app. In announcements and on social media it’s so important to make sure people can find you easily! Here are the 3 most essential steps you should take when announcing your app (or release) to the world.

Step 1: Generate Buzz

If your release has something interesting in it that customers or prospects might like or talk about, do what you can to generate buzz. The best thing to do is to create a preview trailer that can be shared on your website and social media. This can be done easily with inexpensive tools like iMovie’s trailer feature.

Don’t keep it a secret, people like to be informed – blog about the development process on your website if possible. Don’t start too early though, make sure you are at a point where you are fairly certain it will be shipped within the next few weeks.

Step 2: Spread the Word

Writing a good announcement is really important. It should communicate four primary things:

1. Your name (or your company’s name)
2. The app’s name
3. The URL to find your app
4. The main point of your app

All of these items should appear in in the first paragraph. If you have an announcement that goes into features, benefits and more, great. But keep in mind that the majority of your readers will not make it past the first paragraph. Get your main idea across early.

Know your audience: who is reading this announcement? Customize it to them and their goals. Are they your prospective users? Are they members of the media? Are they other developers? Speak their language. Keep it fun and have a sense of humor (if applicable), showcase your brand’s voice. People are generally more inclined to give you their attention if you keep it interesting.

Another thing to consider is where the announcement will be posted. It is good to have a list at the ready for when you are going to ship a release. It is important that you collected email addresses of people on your website and your customers so you can email them about the update, you can send it to bloggers, post it on complimentary forums, like the Xojo forum. See “How To Get Your Announcement Posted.” If you send it to me, it might make its way onto our social media feed or the Xojo newsletter.

Step 3: Write A Press Release

Press Releases should always be written in third person. A good model we like to follow is:

1. Summary of your announcement (main idea) in the first paragraph, callout main new features and number of fixes/improvements.
2. Next paragraph should be an overview of your app itself. What is the value proposition? How is your app useful and to whom? What does your app make easier?
3. Quote from a CEO/developer/employee or customer (or both) are great things to include here. They can showcase how the important new features are useful or innovative and give real life examples to support your main idea.
4. Include bulleted list of important features of the release
5. Contact information – how to find your app and yourself.

What to do with it? We recommend compiling your own media list of writers who have written about your subject before. You can submit news on tons of websites. Also, you can submit your press release on relevant newswires, like PR Newswire or prMac. Don’t forget to post it on your own website!

The marketing work is never done. It involves a lot of trial and error. But announcing your app is the first step – if people don’t know about it, then what is the point? Hopefully these tips will help you write better announcements and develop your own process for announcing releases.

When we changed our name from Real Studio to Xojo, we wanted to make sure we could find a name that we could own. Not only was Xojo a pretty wide open space in terms of search, but it also stands for something that describes what Xojo is – X is for Cross-platform and “OJO” is for Object-Oriented.

Be Your Own App Name Generator

It’s never too early to start the process. Your name might morph or change several times during the process, so the more time you have to think about it, the better. All you need is pencil & paper (or a notes app) and some time to start brainstorming. Start your list by answering the following questions.

1. What is the main purpose of your app?
2. Who is the target audience?
3. What’s the value proposition?

Write down every word that comes to mind. When you’re done, you have a great bank of words to brainstorm with.

First Impressions Really Do Matter

They say don’t judge a book by the cover, but … we do. We are more attracted to things that catch our eye. The name of your app and the icon are the first interaction a prospect user has with your app, it’s sort of like its book cover, it’s what makes people stop and think, “Oooh this is nice… Is this app right for me?”

While reviewing your list of words, start thinking about images and emotions that will resonate with your audience. Conduct some research to find descriptive words and imagery that correlate to your app, ask your friends, get input from potential users.

Pro tip: Make sure you research the meanings and different connotations of your words to make sure they make sense for your intended audience. Avoid words that evoke negative emotions.

Make It Recognizable

Try to find a name that might reveal the literal purpose of your app. In general, when a user can understand the point of your app just by the icon and name, they’re more successful. Names like Evernote and GrubHub are good examples of this. They are short and catchy, but also describe exactly what the app is or does. If your app can’t really be summarized, make sure the icon clearly and visually describes its purpose so they work together to catch the prospective user. Instagram is a good example of this – the name does not necessarily describe what it does, but coupled with it’s camera icon, it conveys the purpose of the app, that it has something to do with photos. App stores also give preference to names that are not totally arbitrary and appropriately describe the apps purpose.

Pro tip: If you are trying to put two words together that need to be pronounced separately (example – Instagram vs. GrubHub), it is recommended to use camel case, rather than all caps.

Though you do want to use words that describe your app, make sure you aren’t keyword stuffing. Picking applicable, even high traffic keywords, to go in your title is a good thing, but too many or too much repetition actually detracts from your preference and ranking. Google Keyword Planner is a great free tool to start your keyword search.

Its common for consumers to download an app just because it sounds interesting or fun, so try to find a name and design to make your app stand out.

Do Market Research

Don’t forget to check out your competition. See what others are doing, without duplicating their name or icon, of course. Identify what emotions their name and icon emote, are the words you use to describe them the same as what is on your list? Is there something you missed that you might want to add? Maybe you might see something that really works you want to try to incorporate into yours, maybe you’ll see some things that really don’t work, like a specific icon, word or color palette. But, make sure to differentiate your app from the rest. Your app could be outright rejected from an App Store if the name is too similar to other apps that are already there.

Pro tip: Make sure the name you choose is not trademarked by anyone else.

Other Considerations

In searching for your name, take a look to see if you can also get a reasonable domain and and social media account. If the name of your app is not available as a domain, don’t discount it, there are variations you can consider for your name (like GoXojo.com or XojoApp.com). 

There’s a lot of thought that goes into picking the best name for your app. These strategies only just scratch the surface. The ideal name sets the right tone, clarifies the purpose, and makes it easy to rank and market your app.

Good luck with your name-storming!

It was the desktop computer revolution that changed that. By the mid-to-late 1980’s, there were more and more desktop computers and developers wanted to target all of them. Soon, however, Windows became so dominant that many developers chose to focus on that one OS. Some Mac developers, not wanting to miss out on the potentially enormous Windows market, either went to the trouble of writing two versions of their applications or used a tool/language that would allow them to target both Mac and Windows from a single code base. This was the beginning of cross-platform development.

Recently, I was asked by tech blogger Chris Pirillo if cross-platform was really important anymore. Cross-Platform is actually more important than ever. Why? First of all, while the Windows PC market is seeing flat or declining sales, Apple’s Mac marketshare is growing. We are seeing this at Xojo. More and more Windows developers are coming to us because they can no longer ignore the Mac market. Linux is the predominant server OS. If you want to write server software that can run on some combination of Linux, Windows and OS X, you’ll want to be writing cross-platform code.

What about the web? It’s just a single platform right? Well, not really. Web developers using what I call the assembly language of the web (HTML, CSS, JavaScript, PHP and AJAX) must deal with at least 4 different browsers (IE, Chrome, Firefox and Safari). In theory, these browsers all interpret HTML, CSS and JavaScript the same way but anyone who’s ever created a web app knows that’s unfortunately not the case. Ideally, a cross-platform development tool greatly reduces these sorts of differences for you.

If you’re developing mobile applications there’s a good chance you’ll want to support iOS and Android. This is yet another place where cross-platform is important.

Finally, there’s a very good chance you’ll want your code to run on several of these types of platforms. You may need a desktop, web and mobile version of your app. And you might even want the core business logic of your app to run on a server somewhere and be accessed by client-side apps runing on these very different platforms. So being able to write code that is transportable across not just operating systems but from the desktop to the server, to the web and mobile, is arguably more important than ever before.

Our goal with Xojo has always been to abstract you from the details of these different operating systems, devices and computing platforms so you can focus on what makes your applications unique. Xojo provides you with a single programming language and tool that allows you to target them all. Why should you have to learn different languages and tools? With Xojo, you can build for OS X, Windows and Linux. And you can build for the desktop, the server, the web and coming soon, mobile with iOS (Xojo iOS was release in Xojo 2014r3 and Xojo Pi for Raspberry Pi was released in 2015). That’s cross-platform.

There are other tools that take short cuts with interpreted code, dependences on runtime libraries and by drawing all controls themselves. Xojo compiles to machine code, creates native apps and uses native controls so that your app takes on the look and feel of the target platform. That’s cross-platform.

Xojo started out supporting just the Mac. Not OS X but its predecessor, Mac OS. Xojo supported the Motorola 68000 and PowerPC processors back then. Next we added support for Windows and the x86 processor followed by Linux. Later, when Apple made the jump to OS X, we were right there as well. Now we support the web. Through all of these transitions, Xojo users have been, for the most part, shielded from these changes. Moving their projects from platform to platform, from processor to processor, has been relatively painless for Xojo users. We will be adding another OS and processor later this year with iOS and the ARM processor. ARM opens up some interesting additional possiblities.

There was a time when many would have said the world is standardizing and the future means fewer and fewer platforms. Look at what happened. Cross-platform is now more important than ever.