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

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

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

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

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

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

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

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

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

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

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

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

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

So what can Xojo do for you?

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

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

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

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

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

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

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

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

Paul learned to program in BASIC at age 13 and has programmed in more languages than he remembers, with Xojo being an obvious favorite. When not working on Xojo, you can find him talking about retrocomputing at Goto 10 and on Mastodon @lefebvre@hachyderm.io.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

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

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

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

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.

You absolutely can. Xojo creates native apps that are also cross-platform. It can be done. It’s just a matter of choosing the right framework. At Xojo, we didn’t take the easy path of drawing controls ourselves or using HTML5. We didn’t dumb things down to the least common denominator. We did the hard work of creating a framework with an API that manages the nuances, intricacies, and subtle yet important differences between 7 different platforms (macOS, Windows, Linux, web, Raspberry Pi, iOS and soon, Android) and multiple OS versions so you can focus on what makes your application unique. We have been doing it for over 20 years.

When discussing Facebook’s blog post, John Gruber of Daringfireball.net said, “…native apps are smaller, faster, and more reliable.”

Nearly every user interface element in Xojo is native. The one exception is the desktop Listbox because way back when, none of the desktop operating systems provided one. Everyone made their own. Having said that, the Listbox is made up of native controls. The scrollbar is a native scrollbar. If the developer makes the contents editable by their end user, a native TextField control appears. The headers are native controls. The advantages of native controls can’t be overstated, Facebook was right about that. Modern operating systems provide an ever-increasing array of features via their native controls and thus using them gives you immediate and nearly free access to these features. From focus rings to spellchecking to accessibility and more much, using native controls makes the most sense.

Event aesthetics come into play. Because the Xojo framework uses native controls, when Apple and Microsoft make changes to the look and feel of their controls, apps made in Xojo automatically change in appearance and behavior. Most recently, Apple added Dark Mode to both macOS and iOS and for most Xojo developers, adding this support required nothing more than indicating they wanted their apps to support it by clicking a checkbox.

While Xojo provides the developer with an easy drag-and-drop way to create their application’s user interface, it also provides a straightforward API for interacting with controls via code. The TextField control, for example, provides events that tell you when the control has appeared for the first time, when the user has changed the selection or the text itself, and even when they press down on a key or release it. There are properties to change the size, style and behavior of controls. And all of this is a level of abstraction that lets you focus not on the details of the platform but on what makes your application unique.

For example, under the hood for the desktop, Xojo’s TextField uses NSTextField on macOS, EditControl on Windows and GTKEntry on Linux. On iOS it’s the UITextField, on Android it’s EditText and on the web it’s <input type=”text”>. Each of these is very different but Xojo has done the hard work to provide a standard, straight-forward API so that you get the benefit of native controls without needing to learn the thousands of APIs and unique behaviors necessary to create a cross-platform app.

It’s not just controls. The Xojo cross-platform framework includes dialog boxes, menus, access to the file system, printing, sockets, database access and much more.

Native is more than the user interface. It’s also about performance. Xojo compiles to native code for each platform as well. Behind the scenes it uses LLVM, the same optimizing compiler that Apple, Google, Intel, AMD, Nvidia and many others use. Native code means native speed.

Thousands upon thousands of Xojo users have built cross-platform apps. The Xojo IDE itself and much of the Xojo framework are written in Xojo. So yes, we eat our own dog food. Studiometry and Property Me are just two of the many examples of commercial cross-platform apps written in Xojo. There are countless others.

We have also done this in a way that makes it easy for students and hobbyists to learn programming so they can take it into their workplaces and build business applications. In some cases, those citizen developers create something revolutionary and become full-time professional developers. That’s why the Xojo user community is so diverse.

So yes, you can create native applications that are also cross-platform. You just have to choose the right tool.

1. Xojo is for everyone

It doesn’t matter if you are just starting to learn how to develop software or if you are already a seasoned developer, Xojo is for everyone! If you are getting your feet wet in coding, then you’ll find that Xojo offers a programming language that is extremely easy to grasp from the start. In fact, you’ll find a lot of contextual help in Xojo while coding, and access to the global Help menu is only a click away.

In addition, the Xojo Documentation website offers really easy-to-follow QuickStarts, Tutorials and Guides letting you make your own Desktop, Web, Android, iOS, Raspberry Pi or Console apps in no time! Add that to the more than 300 video-tutorials you can find in the Xojo YouTube channel, and the fact that all the Xojo language documentation is packed with code snippets showing how to implement a particular feature- copy, paste and you are set.

Need some starting points for a better understanding of how Xojo Projects work? The Examples folder included with the Xojo Download includes dozens of complete example projects you can open, run and inspect to see in detail how to implement a particular task or behavior; then you can  adapt and use these for your own projects. Even you can use the Search feature for filtering the example projects by platform, operating system or other criteria.

One thing you’ll notice the very first time you run Xojo is that you aren’t inundated with features you don’t even know what to do with yet! Everything is clear and concise in front of you, hiding the complexity generally associated with the development workflow.

As you advance in your learning process and get more experienced in coding, you can discover more advanced features at your own pace. And even then, things like Web debugging, iOS or Android deployment or truly multi-platform development, are still effortless. Xojo does all of this without installing thousands of files on each operating system or requiring the additional installation of other components in order to properly work.

What if you’re an experienced developer coming from another development environment or language? Then you’ll be able to learn and master the Xojo programming language in a blink while watching your productivity increase! In fact, Xojo is an Event-Driven OOP (Object Oriented Programming) language, sharing the same “dot notation” syntax used by the most modern programming languages; and Xojo offers guides to port your existing projects, for example, from FoxPro or VB6 to modern and truly multi-platform deployment with Xojo. And even if you are coming from other development environments as FileMaker or 4D, Xojo makes your solutions available for a more wide range of platforms as native apps and without hidden or extra deployment costs.

Being an OOP language means that Xojo will share the same set of paradigms and/or syntax you are used to dealing with in other programming languages; ranging from PHP to C++, Objective-C, Swift, JavaScript, Python, and others. In fact, you’ll discover that several of the language keywords, instruction blocks and function or methods calling conventions are very similar to the ones found in those.

Add that to the rich and complete Xojo Framework and the fact that you can even use external libraries if you need to; and you’ll realize all the possibilities you have at your hands for creating apps and complete solutions that can be used by individuals or companies of all sizes.

2. Make all kind of apps!

While several languages and IDEs are more suited or focused on developing a particular kind of products (database driven, mobile, IoT, etc.), with Xojo you’ll be using the same IDE and programming language to create all of these and more!

For what it is worth, that means that even if you are a self-employed developer, a Citizen Developer or need to develop a solution for a company, you’ll be saving a huge amount of time, money and resources in order to get all these things done with a single development environment. That translates into reduced costs and increased ROI in your development investments; from the simplest ones to the more complex and demanding, including Console apps acting as Daemons, background processes, task helpers… or APIs development as the middleware to interact with both Mobile, Web, Desktop or Raspberry Pi clients!

Do you offer consultancy services or are you working as a freelance developer? With Xojo you’ll significantly reduce the amount of time you usually spend following multiple changes and evolutions in programming languages, frameworks, SDKs, technologies and, probably, third parties IDEs (among other resources) in order to keep going with your business.

At the same time, due to the fact that Xojo shares the programming language and IDE among all the supported platforms (Desktop, Web, Android, iOS and Raspberry Pi) and architectures (both 32 and 64-bit / Intel and ARM), you can also expand the kind of solutions you can offer to you current or potential clients and keep them running as the technology evolves!

3. Truly Native, Cross-Compiled, Multi-Platform Apps!

Some development environments or programming languages are focused (or are more appropriate) to a particular platform or target. With Xojo you’ll find that all of your apps will be compiled to native binary code on every supported platform.

That means that they will not incur the performance penalties imposed by byte code translations or that they can be easily reverted to source code, even your Web products!

What’s more important: the compiled apps will look and behave as you expect on every one of the supported operating systems.

In general, all of this means that you can be more confident about the fact that your intellectual property will not be the targeted or exposed by the most common techniques or exploiting attacks; and that translates into additional peace of mind regarding how you protect your investment in developing and deploying your solutions.

Even Xojo is created with Xojo! That is, the IDE offers the same look and feel and set of features from Windows, macOS and Linux.

4. Do more with less

During the designing, coding, testing or deployment phases of the product you won’t need to do complex set-ups or check for ever-changing dependencies! The Xojo IDE abstracts you from all the inherent and underlaying complexity, so you can focus on what really matters: the features that make your product truly unique.

This kind of complexity abstraction is evident not only for Desktop apps, but also for Android and iOS deployments and is especially evident when deploy web apps in combination with Xojo Cloud.

In this last case, you only need to click a button in Xojo to have your web app transferred from the IDE to your Xojo Cloud server. Your app will be up and running in a matter of seconds, without needing to deal with complex server configurations or investing all the required time in being sure that you have all the server security issues covered and under control. Think about that for a moment: if you are a small company or just an independent developer, you don’t need to invest  extra resources, time and money in order to have your web apps secured and running with confidence.

Of course, if you have the resources and/or the required knowledge, you can deploy your web apps yourself on any VPS or web hosting service of your choice that meets the Xojo Web deployment requirements.

But the best part is that it doesn’t mind if you’re developing for Web, Android, iOS, Desktop or Raspberry Pi: you can develop for any of the Xojo supported platforms from the operating system of your choice! In the case of macOS and iOS apps, development can be done on any platform a Mac computer is required for compilation.

In summary: it doesn’t matter what OS or platform you want or need to code for, you’ll be using the same IDE and programming language in all the cases, abstracting you from all the particularities and underlaying complexity on every case. And that means doing more in less time!

5. Rapid Application Development

It doesn’t matter if you are creating a Desktop, Web, Android or iOS app; or if you want to build your solutions for Intel or ARM based architectures. With Xojo you will be able to design the user interface via Drag & Drop from a rich set of controls ready to use. It’s that simple. In fact, the Layout Editor provides visual clues to precisely align every control in the Window, View or Page of the app; and if you’re targeting for macOS, Web, Android or iOS you’ll be able to see how your designs react when used in Dark Mode!

Reacting to users’ interactions in your apps is as easy as selecting a user interface control in the Layout Editor, adding the kind of event you’re interested in from a list (with contextual help about what it does and when it is fired), and writing the code you want to be associated and executed to that particular Event.

Add that to the fact you can reuse your already developed Classes, Modules and other resources; you can even reuse your code between different kinds of projects and targeted platforms!

6. No chains!

It doesn’t matter if the apps or solutions created with Xojo are intended to be used by dozens or thousands of users, even if they are database driven! With Xojo you don’t have to pay royalties for absolutely anything! Even better: you don’t need to buy a license in order to try, learn and use Xojo! There is no limited trial, feature limitations or other drawbacks when using the free IDE. Download Xojo and begin learning, developing, running and debugging your projects all without a license.

Features include, the access and use of the supported database engines: from SQLite to MySQL/MariaDB, PostgreSQL, or any other you can access using ODBC, and of course the included features to work with Reports.

You can buy a Xojo license when you decide that is the time to build your projects. Further, all Xojo licenses are covered by a 90-day money-back guarantee.

In addition, you don’t even need to pay for what you are not going to use (or going to use right now). What does this mean? Well, let’s say that if you only work with Windows and only want to create apps for Windows, then you only need to buy the Windows Lite Edition license for that ($99 USD), while if you need your apps to be run from all the supported Desktop platforms (including Raspberry Pi), then the Xojo Desktop Edition license is probably what you’re looking for ($299 USD); or if you really want to grasp all the Xojo power and target all the Xojo supported platforms (Desktop, iOS, Web and Raspberry Pi), then Xojo Pro is undoubtedly for you ($699 USD)! Oh and Xojo Pi, for building desktop and console apps, is free!

You can even upgrade to Xojo Desktop or Pro at any time if you decide that you need to use more advanced features not present in your current edition. In other words, you don’t need to buy a new license from scratch if you don’t want to. You can even change your Xojo Cloud plan at any time you require!

7. You’re not alone!

With more than 400,000 users around the world and more than 20 years on the market, the awesome Xojo community is one of the best programming resources you can find around to join to. In the Xojo Forum you’ll find the largest community and best place to get your questions answered by a large group of enthusiastic and seasoned Xojo developers.

It doesn’t matter if it’s a simple or a more complex problem, you’ll feel welcomed and probably have your problem solved in record time! In fact, many of the replies come from members of the Xojo Staff, ranging from Customer Service to anyone on the Engineering Team or even the Founder and CEO of Xojo himself!

Of course, you have other resources you can (and should!) visit, ranging from a dedicated publication about Xojo development, to Users Groups and Xojo Pages in Facebook, developers blogs about Xojo, and of course the official Xojo channels in Twitter, Instagram or Facebook. Don’t worry, you don’t need to search the entire web to find these, we have collected some of these valuable resources here and here.

And if you need to get a richer experience and more in-depth knowledge, in a face to face way, then you won’t want to miss any of the usual Xojo Events taking place in several American and European cities each year! There you can chat with other Xojo developers to exchange experiences, attend technical sessions, socialize and create new relationships that can lead in new work projects, etc.

The biggest of these Events is XDC, with Xojo developers coming in from all around the world, and where you will be able to attend sessions from expert Xojo developers and where you can talk with all the Xojo Team!

8. And you won’t be left behind

Did you know that Xojo is still able to open and run projects from earlier releases, even many, many years ago? Sure that in more complex projects you will need to upgrade code, and that’s because Xojo has evolved, and continues to evolve, to match the own industry changes and evolution.

In fact, the apps created with Xojo are 64-bit compliant (although you can still generate 32-bit code, if you need), with support for HiDPI graphics, Dark Mode support both on macOS and iOS, the latest iOS SDK, native Silicon and M1 compilation and meeting other non-visual changes imposed by any of the current operating systems.

You can expect several Xojo version releases every year, adding new features, improving existing ones and fixing bugs. But we also keep a bigger picture about the medium to long term evolution of Xojo, so you can always see the big features we are working on that will be coming in future releases of Xojo. That way, all the effort you’re putting in the apps, products and solutions you create today won’t be left behind in the future. You’ll be able to improve and enrich them for your users, keeping them current as operating systems evolve.

Need to request a feature is important for you or did you find a bug you can’t workaround? We listen to you. Go to our Issues tracker system to get in touch with us about the things you want to be added or improved.

9. Add your own features!

The Xojo Framework is large enough to accomplish most of the usual app requirements you may need; but sometimes you need to go a bit further, even the thousands of already existing external libraries around whose functions you can use directly from your code … and in these cases you’re covered too!

Xojo Provides SDKs (Software Development Kits) both for Desktop and Web applications; so you just need to start digging in the provided documentation and example projects in order to create your own Xojo Plug-Ins. These will be loaded from the IDE and you’ll be able to use their exposed features with the same simplicity you do when using the rest of the internal Xojo Framework.

10. Xojo Ecosystem

Don’t be afraid if you don’t have the time, resources or knowledge needed to develop your own plug-ins.

You can resort to the broad offer of excellent third-parties plug-ins, add-ons, libraries and classes you can choose from. These range from commercial software to Open-Source projects, or just plain free classes, modules or libraries ready to download and use in your own Xojo projects.

We are here to help!

All in all it’s time to give Xojo a try, isn’t? It’s just a click ahead right now, so download Xojo and rediscover the pleasure of coding!

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.

Just as people have varying levels of skill and interest in video games, the same is true of app development. There are those that are happy to devote enormous amounts of time to learning everything they possibly can. They don’t care how long it takes. They want to have control over everything and are willing to do whatever is necessary to make that happen. I’m so glad those people exist because there’s a lot of great software that might not otherwise have been created without them. I’m not one of those people. I really want to focus mostly on what makes my application unique, abstracted from the nitty-gritty of app development.

That’s why I have always been attracted to tools like Xojo. I am a citizen developer. Of all the job titles I have had over the years, all of them in tech,  none have ever included words like programmer or engineer. I do some software development but it’s just a part of my job. It’s something I do to help me in my work or to help my co-workers.

When I founded Xojo, Inc., tools like Xojo were called RAD (Rapid Application Development) tools. Now the term du jour is Low-Code. Put simply, it means that a development tool provides a lot of built-in functionality so you don’t have to write too much code compared to more traditional languages and tools. That’s Xojo. You can build your user interface visually via drag and drop.

The set of built-in commands (the framework) provides you with everything you’ll likely need to handle the things that do require some coding. Xojo is a cross-platform tool making it easy to create apps for different platforms such as MacOS, Windows, Linux, the web, iOS and even Raspberry Pi, without having to learn all the details of each one. Unlike some cross-platform solutions, Xojo builds complete native apps which means your apps have the look, feel and performance of those written in the more complicated tools that require so much more code.

It’s not all upside. There are sometimes very specific features for which Xojo has no built-in support. An example of this is notifications. The good news is that should you find yourself needing functions like this, there’s a vibrant Xojo community of users who have likely already created that functionality and you can just add it to your project. And Xojo is updated multiple times per year so new functionality is always appearing.

If you’re like me and you want to be able to quickly and easily build applications that make life easier for you and perhaps your co-workers, Xojo is something you should seriously consider. Xojo is also free to use and learn. You only need buy a license if you decide you want to deploy your application. We provide lots of free resources including a video library with over 250 videos, tutorials, and documentation as well as a textbook designed to help you learn app development.

It’s tremendously empowering to be able to build even a simple app that helps you accomplish tasks more quickly and efficiently. A low-code development tool like Xojo is a great place to start.

It’s Simple

Xojo makes it easy to get started with you first iOS app. When you select iOS in the Project Chooser, you get a clean, simple project with a default view:

From here you can start creating the layout for your user interface by simply dragging and dropping controls from the Library. Xojo has many iOS controls, including:

Xojo also supports different layout options including tabs and splits.

Because Xojo uses an event-driven programming model, you can simply add your code to event handlers on your controls. And speaking of code, the Xojo programming language is fully object-oriented, type-safe, easy-to-read and uses automated reference counting (ARC) for memory management.

The iOS framework is fully documented at the Xojo Dev Center and Xojo itself has over 50 iOS example projects included for you to modify and learn from. Below is the Xojo Notes example app running in the iOS Simulator (or you can check out the Xojo Draw app in the iOS App Store):

It’s Native

As mentioned above, Xojo only uses native iOS controls. This means your controls work like you expect and they match the look and feel of iOS. If Apple changes the way the controls look you won’t have to do anything more than rebuild your app.

Xojo also supports the powerful Declare command which allows you to directly access the underlying native controls and the Cocoa Touch framework so you can access methods and classes that Xojo does not yet include.

Speaking of which, there are several 3rd party and open-source libraries of iOS code that are already available to help you extend your Xojo iOS apps when necessary.

It’s Rapid Application Development

The development process with Xojo is incredibly fast, truly it’s Rapid Application Development. Click Run to nearly instantly run your project in the iOS Simulator for testing and debugging. The built-in debugger lets you step through your code line-by-line as you watch variables and values change.

Xojo uses the LLVM compiler, fine-tuned to produce high-performing native 64-bit apps without you having to learn arcane compiler settings.

It’s Multi-Platform

Xojo creates more than iOS apps of course. It also builds cross-platform desktop, web, console and Raspberry Pi apps. Often it is useful for an iOS app to have companion apps that work on desktop and web – with Xojo you can easily create all these apps using a single tool and language. And you can even share non-UI code between different types of projects allowing you to ship your apps faster.

Develop Faster With Xojo

All in all, you can develop faster with Xojo. Don’t get bogged down with multiple development tools and different languages. Download Xojo for free to see how easy it is to get started making iOS apps. Xojo is free for learning, development and testing. Develop your app, run and debug it for free, only purchase a license when you are ready to compile and distribute your app!

Xojo is the modern alternative to Microsoft Visual Basic. Xojo is a single language to build apps for Mac, Windows and Linux desktop, plus web, mobile and Raspberry Pi. Cross-compile desktop apps and use the same powerful language to develop for web and mobile too.

Develop Faster with Xojo

Xojo is more powerful than VB6 while at the same time more approachable than VB.NET. With Xojo, a single project can create desktop apps that work on Windows, macOS, Linux and Raspberry Pi. Unlike VB and Visual Studio, Xojo allows you to develop on your platform of choice- Windows, Mac or Linux.

Modernize Legacy Desktop Apps with Web and Mobile

Because Xojo can create apps for so many platforms, it is a great way to modernize and update your legacy desktop apps to web or mobile apps.

With Xojo, web apps are as easy to make as desktop apps. Use Xojo’s powerful language to create your web app instead of HTML, CSS, PHP, JavaScript, and AJAX and save tons of development time. Xojo web apps can be deployed to any server (Linux, macOS or Windows) and can also use the industry standard Apache web server.

These days mobile apps are often a necessity. Design your Xojo iOS apps using drag and drop in the layout editor, add your code and publish. Access the iOS-features you’d expect, like sharing panel and your photo library, and also the iPhone’s hardware-based features, like motion, location and camera. Xojo makes iOS development familiar and fast. Xojo Android is currently in development and will be testing soon.

Similarities between Xojo and Visual Basic

Language

The Xojo programming language is very similar to Visual Basic. It has commands like If..Then..Else, For..Next, and While..Loop. You will also find the object-oriented capabilities of Xojo quite similar to VB.NET.

Data Types

Xojo shares many of the same data types with VB6 and VB.NET, including: Integer, Double, String/Text, Currency, Boolean, Variant.

Controls

Xojo has many common controls including: Buttons, Labels, TextFields, TextAreas, ListBoxes (grids), PopupMenus, ProgressBars, toolbars and more.

Differences between Xojo and Visual Basic

Compiler and Run-time

Xojo apps are compiled to native code. They do not contain byte-code that is run by a virtual machine (as with .NET). The run-time library is included with your applications so there is nothing additional that needs to be installed on users’ computers.

Language and Framework

Xojo is fully object-oriented. Unlike VB6, you can have classes that use inheritance and other object-oriented features. The Xojo framework is designed to be simple to use and support cross-platform applications; it provides access to many things you’ve come to expect such as file handling, databases, graphics and more.

File I/O

One of the biggest differences between VB6 and Xojo is file I/O. Xojo consolidates all its file processing into a few classes: FolderItem, TextInputStream, TextOutputStream and BinaryStream. VB6 uses hard-coded file paths and less flexible file access methods, primarily because it only needs to work with Windows-specific file paths.

Data Types

Xojo is strongly typed, just like VB.NET. VB6 allows you to do some things the old-school, BASIC way, the most significant of which is using variables without declaring them (the type is inferred by a suffix on the name). Xojo does not allow this. Use the OPTION EXPLICIT command in all your Visual Basic code to have VB enforce explicit variable declarations.

Improved Error Handling

Xojo has modern exception handling using Try/Catch, Exception and App.UnhandledException.

Shared Libraries

Xojo cannot create DLLs, ActiveX controls, .NET assemblies or any kind of shared libraries. Since these are all Windows-specific technologies, that is somewhat understandable. You’ll either need to rethink your design or just re-use these components from within Xojo (and limit yourself to deploying only on Windows).

Switching to Xojo

Xojo is free for learning and development. Take your time to see how Xojo can help with your next project. Develop, run and debug your application with the free IDE, only purchase a license when you are ready to compile. Learn more about Xojo, read the User Guide and visit the Xojo Docs.

If you find yourself frustrated with VB.NET or are looking for something to replace VB6, be sure to test out Xojo. It might be just right for you. Watch the Migrating from VB video to see how a simple app is migrated to Xojo and visit our Migrating from Visual Basic page at the Xojo Docs for more details.

Updated June 2020