App Store – Xojo Programming Blog

Build Your First iOS App with Xojo: 10 Practical Steps

Javier Menendez — Fri, 16 May 2025 15:45:00 +0000

Xojo is an extremely useful, fast and fun development environment for building your first (or next) iOS app. In this article, I offer a series of practical steps to guide you from idea to app.

1. Define Your Idea

Start by summarizing your app’s purpose in a single, clear sentence. The more concise it is, the better defined your objective will be. This clarity will help guide your screen designs, navigation structure and code architecture.

This sentence can also double as your app’s short description in App Store Connect.

Focus on the essential features that form your app’s Minimum Viable Product (MVP). It’s easy to get sidetracked by new ideas during development. Resist the urge! Instead, keep a list of potential features for future updates and base priorities on user feedback.

2. Choose The Platform(s)

Xojo supports both iPhone and iPad, but your app doesn’t have to. Choose the device type that best fits your app’s use case.

iPhone apps often support quick, task-based interactions.
iPad apps are better suited to immersive, content-rich experiences.

To target a specific device only, set the unused layout (iPhone or iPad) to “None” in the App item’s Inspector Panel.

You’ll also need to decide the minimum iOS version to support. Xojo currently defaults to iOS 14.0, but as of writing, over 60% of users are on iOS 18 or later.

3. Prototyping

Xojo’s visual layout editor makes it easy to dive in designing your app. But take time to prototype your app first, especially if it has more than basic functionality.

Use tools like Figma or MockUp, or simply sketch your ideas with pencil and paper. Choose whatever helps you plan best and clearly.

Also, review Apple’s Human Interface Guidelines to align your app with native iOS expectations.

When designing in Xojo, you can fine-tune layout behavior using the iOSLayoutConstraint class to adapt to orientation and screen size changes at runtime.

4. Database Design

Most apps use a database. For local storage on iOS, use SQLiteDatabase, and save your database file in SpecialFolder.Documents.

Two key best practices:

Add a Metadata table to track the database schema version.
Create a custom SQLiteDatabase subclass to manage all read/write operations in one place.

This setup allows you to always know which version is installed on the user’s device and to react accordingly as your app evolves.

5. Graphic Resources

For icons, buttons and tab bar images, use Picture.SystemImage with symbols from Apple’s SF Symbols app. These scale beautifully across devices and adapt to light/dark mode. Just ensure compatibility with your minimum iOS version.

When using custom images, add them at multiple resolutions for optimal display across all screen sizes.

Typography also matters. Use system fonts thoughtfully, ideally no more than two font families. Vary sizes and weights to establish content hierarchy. Keep text readable with a minimum font size of 11pt.

Tip: When testing in the Simulator, set the window to physical size (Simulator > Window > Physical Size) to preview real-world readability.

6. Localization and Accessibility

Nothing prevents you from publishing an app in a single language, whether it’s your native language or English; but supporting multiple languages can increase downloads by over 100x.

Start localizing early to avoid design issues later. Add a module to your Xojo project with localized String constants for all app text, and enable the “Localized” option for each one.

Suggested languages (in order of impact):

Core: English

High-impact additions: Chinese, Spanish, German, French, Japanese, Italian, Portuguese, Russian, Korean

Also, localize accessibility labels and App Store listings, including screenshots and descriptions, for each supported language.

7. Testing the App

Xojo provides multiple ways to test your app, both from a design and user experience perspective, as well as from a functionality perspective:

Simulators: Ideal for design, layout and localization testing. You can also use them to take App Store screenshots.
On-device Debugging: Offers realistic input experience and access to hardware-only features.
Build to Device: Lets you run the app outside the debugger, simulating real-world use.

Once you’ve finished fixing bugs in your code and app design, move on to testing in the real world by compiling your app and using Xcode to copy that bundle to a physical device. Testing like this, you’ll likely find some optimizations, especially around design and usability.

TestFlight is your gateway to external beta testers. After uploading a build to App Store Connect, create a public link to invite testers. Remember to increment the version number with each new build.

Tip: Add ITSAppUsesNonExemptEncryption = False in your Property List to streamline build approvals.

8. Publish it!

Publishing with Xojo is straightforward. The most time-consuming step is preparing your App Store Connect listing including text, artwork, screenshots, keywords and possibly localized pages. Read more about this in my earlier post How to Publish macOS and iOS Apps to the App Store Directly from Xojo.

Make sure you select the correct build when submitting your app for review.

9. Marketing

Something you should be doing simultaneously is preparing the related materials to introduce your app to the world. Start your marketing efforts early. A simple website can significantly boost discoverability. Use it to:

Provide tutorials and FAQs
Link to App Store and social media
Highlight features and updates

Consider creating a YouTube channel for app demos and support videos, and maintain active social media profiles to stay visible.

Don’t forget to take advantage of the Marketing tools provided by Apple to help you create badges, assets, links and even QR codes to promote your app.

10. The Next Steps …

After launch, gather user feedback and track any bugs that slipped through. At this stage, it’s common to manage:

A public release (on the App Store)
A development version (next major update)

Save your Xojo iOS project in text format and use a version control system. This helps you manage multiple branches and collaborate efficiently.

To Summarize

Even the simplest iOS apps require a fair amount of time and effort, but thanks to Xojo, both aspects are significantly reduced.

What iOS apps have you created with Xojo? What’s your methodology or any tips you’d like to share? Feel free to comment on the Xojo forum!

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.

Property List Editor, Integrated in the IDE

Javier Menendez — Tue, 25 Mar 2025 15:34:12 +0000

Starting with Xojo 2025r1, a new Property List Editor is available for both Desktop (macOS) and iOS projects under Build Settings > macOS and Build Settings > iOS. This editor simplifies the process of adding custom entries that your app may require, beyond those automatically included by Xojo.

Some projects require additional entries in the generated Info.plist file. Previously, the only way to include these entries was to create the file manually using an external text editor, then drag and drop it into the project’s Navigation area. This allowed its contents to be merged with the entries automatically generated by Xojo in the final Info.plist file within the app bundle.

Now, the Property List Editor in the Xojo IDE provides a simpler way to add these entries. Once added, you can even export the contents to an external file, making it easy to reload them later for other projects that require the same set of entries. This saves time by eliminating the need to manually re-enter them.

What about projects that already reference an external Info.plist file? No worries—Xojo will automatically merge its contents with the entries added via the Property List Editor. If the same key exists in both the external file and the Property List Editor, the value from the Property List Editor will take precedence, overriding the one in the external file.

As for the types of data that can be added to the Property List Editor, the expected options are offered:

For collections:

Dictionary
Array

For primitive values:

Number
String
Boolean

For primitive value entries, the Editor allows you to convert them to any of the other two supported primitive types. For example, if you add a Number entry, you can later select it and convert it to a String or Boolean type as needed.

Of course, the entries added through the Property List Editor are applied and saved to the project file in addition to any changes made using the Property List Editor. The next time you open the project in Xojo, you’ll find the previously applied Info.plist entries already in place.

Tip: If you’re using the new Publish feature to send your macOS apps to App Store Connect, you can simplify Apple’s encryption compliance process by adding a new Boolean entry in the Property List Editor with the following values:

Key: ITSAppUsesNonExemptEncryption
Value: False

By doing this, you won’t need to manually go through the “Manage” option for Apple’s encryption compliance on the App Store Connect website—provided your app does not actually use encryption that requires disclosure.

In Summary

Whether you’re developing macOS or iOS projects, the integration of the Property List Editor in the Xojo IDE streamlines the process of managing additional Info.plist entries. You no longer need to manually create and import external files —now, you can add, edit, and reuse entries directly within the IDE. This not only saves time but also ensures consistency across multiple projects!

How to Publish macOS and iOS Apps to the App Store Directly from Xojo

Javier Menendez — Tue, 25 Mar 2025 15:34:03 +0000

Starting with Xojo 2025r1, you can publish macOS and iOS apps to App Store Connect directly from the Xojo IDE. Keep reading to learn how!

App Store Connect is where developers create app records as part of the process to make their apps available on the Mac App Store and/or iOS App Store. All apps must go through Apple’s review process for approval. Once an app record exists in App Store Connect, every new app build uploaded from the Xojo IDE will be available there!

First Things, First

Before exploring how to use Xojo’s new Publish feature, let’s review the requirements and previous processes to better understand how it works.

You may have already met these requirements, but it’s always a good idea to review them.

A paid Apple Developer membership (approximately US $99/yr).
Xcode installed on your Mac, preferably the latest version (Xcode 16.2 at the time of writing, which requires macOS Sequoia 15.2). However, Xojo also works with Xcode 13 or later, such as on macOS Ventura.
The following certificates are present in your Mac’s Keychain:
- Developer ID Application
- Apple Distribution
- 3rd Party Mac Developer Installer
An explicit App ID (Identifier) has been created for your app at developer.apple.com.
A Provisioning Profile has been created at developer.apple.com to ensure the uploaded build is available for testing via TestFlight.
No pending agreements are waiting for your approval at both developer.apple.com and appstoreconnect.apple.com.

Handling Certificates

The best way to ensure you have the correct certificates installed in your Mac’s Keychain is to manage them directly from Xcode. Open Xcode, go to Preferences > Accounts, and make sure you are signed in with your developer.apple.com credentials.

Next, click the “Manage Certificates…” button. A new window will appear, displaying the installed certificates—including expired ones or those missing a private key. From here, you can also download any missing certificates.

Once the required certificates are installed on your Mac, I recommend opening the Keychain app to remove any revoked, expired, or incomplete certificates (those missing a private key) to keep your Keychain clean and organized.

Handling App ID

The App ID, Identifier, or ‘Bundle Identifier’ is something you should be familiar with whenever you create a new macOS or iOS app in the Xojo IDE.

You also need to create the same App ID at developer.apple.com. Log in to the Apple Developer portal using your Apple Developer credentials, then click “Identifiers” under the “Certificates, IDs & Profiles” section.

Note: Keep in mind that you must create a new App ID and follow these steps for each macOS or iOS app you want to distribute through the Mac or iOS App Store.

On the page displayed after the previous step, click the “+” button next to the “Identifiers” header to register a new Identifier.
On the next page, ensure that “App IDs” is selected, then click “Continue”.
On the following page, select “App”, then click “Continue” again.
Now, you’ll reach the most important step—entering the explicit Bundle ID. Make sure it exactly matches the “Application Identifier” used when creating the project in the Xojo IDE.
Also, verify that the App ID Prefix matches the Team ID of the certificates installed in your Mac’s Keychain via Xcode.
Select any Capabilities and/or App Services your app requires. (For this example, none are selected.)
Click “Continue” to proceed to the summary page, where you can review all the entered details and selected Capabilities/App Services.
If everything looks correct, click “Register” to finalize the process.

Once registered, the new Identifier will appear in the list under the “Identifiers” section.

Handling Provisioning Profiles

TestFlight is an Apple service that allows developers to gather feedback from users and teammates while an app is still in development, before it becomes publicly available on the Mac or iOS App Store. When a new app build (version) is published from the Xojo IDE, it will also become available through TestFlight.

However, for this to work, the app must have a “Provisioning Profile” embedded. This profile needs to be created on the “developer.apple.com” website, as we did in the previous “App ID” section.

There are two main types of provisioning profiles: “Development” and “Distribution.” The key difference is:

“Development” profiles specify which devices an app can be installed on. They are primarily used for internal testing on user devices or, in the case of iOS apps, for running tests on a physical device using the “Run On Device” option in the Xojo IDE.
“Distribution” profiles are used for submitting apps to the App Store or making them available for TestFlight testing.

In this example, we will focus on creating a “Distribution Provisioning Profile” to ensure that apps published from the Xojo IDE are eligible for TestFlight testing.

Log in to “developer.apple.com” and navigate to the “Certificates, IDs & Profiles” section.
Select “Profiles” and click the “+” button next to the “Profiles” header.
On the next page, under the “Distribution” section, select “Mac App Store Connect” if you are creating a profile for a macOS app. For iOS apps, choose “App Store Connect” instead. Click “Continue.”
Select the “App ID” you previously created. Notice that the App ID is prefixed with the “Team ID” from when the App ID was created (e.g., “BW7PU32485”).
Under “Profile Type,” make sure the “Mac” option is selected instead of “Mac Catalyst.” Click “Continue.”
On the next page, select the same “Distribution” certificate that will be used when building the Xojo app (i.e., the “Apple Distribution” certificate installed on your Mac). Click “Continue.”
Give the Provisioning Profile a meaningful name so you can easily distinguish it later from other profiles. Click “Generate.”
After a few seconds, the Provisioning Profile summary page will appear with a “Download” button. Click it to download the profile.

NOTE: Provisioning Profiles for iOS
For iOS apps, you need to create both “Development” and “Distribution” provisioning profiles.

When creating the “Development” provisioning profile, be sure to include all registered devices you want to use for installing and testing the app directly from Xojo (using the “Run On Device” option in the IDE).

Once these provisioning profiles are downloaded to your Mac, double-click on them to ensure Xcode installs them in the correct location (as of this writing: “Library > Developer > Xcode > User Data > Provisioning Profiles”).

Adding the Distribution Provision Profile to your Xojo Project

Move the downloaded macOS Distribution Provisioning Profile to a more convenient location related to your Xojo project, and rename it to “embedded.provisionprofile”.

Next, open your Xojo project and add a new “Copy Files” step:

Right-click (or use the contextual menu) and choose “Add to ‘Build Settings’ > Build Step > Copy Files”.
Select the “macOS” item under “Build Settings.”

Next, click the “Add File” button in the “Copy Files” toolbar and select your “embedded.provisionprofile” file.

In the associated “Inspector” panel, use the following values:

Name: Distribution Profile
Applies To: Release
Architecture: Any
Destination: Contents Folder

NOTE: For Xojo iOS projects, provisioning profiles are applied automatically when building or publishing the app. This happens based on the profiles installed by Xcode when you double-click them after downloading from developer.apple.com.

App Store Connect: Creating the Record for the App

You need to create an App Record for every macOS or iOS app that will be distributed through the Mac or iOS App Store. To upload an app from the Xojo IDE, it is not necessary to complete every required field in the various sections right away—you can do that at your own pace. However, you must at least have an App Record created for the app.

To do this, log in to “appstoreconnect.apple.com” using your developer credentials. Once logged in, select the “Apps” icon. On the next page, click the “+” button and choose “New App” to create a new App Record. The previous action will open a dialog where you need to enter the essential app information required to create the record.

Platforms: Select “macOS.”
Name: Enter the same name used in your Xojo project for the app (Build Settings > macOS > Mac App Name). Apple can be strict about this during the app review process if the names differ, as this will also be the name displayed in the App Store listing.
Bundle ID: Select the App ID you created for the app by following the steps in the “Handling App ID” section.
SKU: Enter any arbitrary SKU value that makes sense to you for uniquely tracking this app.
User Access: If you are a solo developer, the choice doesn’t make much difference. However, if you are part of a team, selecting “Limited Access” allows more control over which team members can access the app.

Once you are confident with the information provided, click the “Create” button to generate the new app record.

If you receive an error stating that another app has already been registered with the same name, you will need to choose a different name for your app.

NOTE: Values such as the App Name and Bundle ID can be changed later, if needed, from the “General > App Information” section on the App Record page.

Once the App Record has been created, there will be a lot of required information to fill in before the app can go through the App Store Review Process and be publicly listed in the Mac/iOS App Store upon approval. However, as mentioned earlier, you can add this information at your own pace. The most important thing right now is that, once the record is created, you have everything set up to start uploading your app builds (versions) from the Xojo IDE.

Publishing Mac Apps From Xojo

General Information

Open your Xojo project in the IDE and go to Build Settings > macOS. Then, make sure the correct values are set in the associated Inspector Panel for the following fields:

Mac App Name: This should match the name entered for the App Record on appstoreconnect.apple.com.
Bundle Identifier: This should match the App ID created for the app.
Category: Select the category that best fits your app from the available options.

App Store Connect Setup

To allow the IDE to upload the app to App Store Connect, you need an app-specific password. You can add it by clicking the App Store Connect > Setup button. If you have already created this app-specific password in a previous version of Xojo (under Build Settings > Sign > Notarization > Setup), you don’t need to do it again. Also, keep in mind that this setup only needs to be done once for all your Desktop (macOS) and iOS projects.

Signing and Sandboxing

Select Build Settings > macOS > Sign in the project browser in order to access the associated Inspector Panel:

Developer ID: Type (or paste) the full string from the Apple Distribution certificate installed on your Mac. In this example, it is: “Apple Distribution: Francisco Javier Rodriguez Menendez (BW7PU32485)”. This certificate should match the one selected when the Distribution Provisioning Profile was created, and the Team ID (the value in parentheses) should match the one used when the App ID (Identifier) was created for the app at developer.apple.com.
Sandboxing: Apps uploaded to App Store Connect require Sandboxing to be enabled. Turn on this option and click the associated “Edit” button to enable the necessary sandboxed features for your app. In our example, we only enabled the ability to read/write the selected user files.

Shared Settings

Select Build Settings > Shared in the project browser to access the associated Inspector Panel:

If you are going to publish the final (release) version of your app after it has been thoroughly tested, you will likely want to set the Stage Code value to “Final.” Additionally, make sure to enter the short version string in the Version field and the copyright information for the app in the Copyright field.

NOTE: Did you forget something? Every time you click the Publish button (or select the equivalent “Build and Publish to App Store Connect” menu item from the Project menu), the IDE will run a “checklist.” If something needs to be set in the IDE before uploading the app to App Store Connect, any errors will be shown in the IDE’s Error Panel, pointing out “what” needs to be fixed and “where” to make the changes.

App Icon

Nothing new here, apart from building your macOS app for regular or “web-based” distribution. Your app needs an icon in the required sizes. However, when it comes to publishing to the Mac/iOS App Store, this requirement is even more strict. Xojo will catch this before starting the app building process to save you time spent on compilation and uploading. So, make sure you add all the required icon sizes by selecting the App item in the project browser, then clicking the Appearance > Icon option in the associated Inspector Panel.

That action will open the Icon Editor, where you can drag and drop the different icon files for each size or paste them directly from your preferred image editor.

Publishing!

Click the Publish button. Once the “checklist” passes without any errors, a confirmation dialog will appear. Click the “OK” button to begin the process and upload your app’s new build to App Store Connect.

If everything goes smoothly, you will see a “Success” dialog at the end of the process. However, if there is an error during any of the steps, an error message dialog will provide more details about the issue, and the process will be interrupted, returning you to the IDE.

In either case—whether your new app build was successfully uploaded to App Store Connect or not—you can find the generated Log file in the same folder as the built app. If there are errors, you can open the Log file to review the information about the issue(s), which will help you resolve them before trying again. For example:

2025-01-23 12:54:35.030 *** Error: [ContentDelivery.Uploader.6000028E01C0] The provided entity includes an attribute with a value that has already been used (-19232) The bundle version must be higher than the previously uploaded version: ‘1.0.6’. (ID: d422b9bf-049f-4263-af43-8357c2fe5f00)

In this case, the Log file entry indicates that we tried to publish a build with the same version number as an already uploaded build on App Store Connect. If this new build includes changes or new features, the way to fix this issue is simply by increasing the version number (and the short version string) before publishing it.

Testing with TestFlight

When you create a new app record in App Store Connect and access it, one of the tabs at the top of the page is named “TestFlight.” Click on it, and you will see all the uploaded builds of your app that are eligible for testing.

As you can see, there is a warning icon next to the app build we just uploaded (A). This is because Apple requires additional information from you regarding the app’s compliance with Encryption Export Regulations. To provide this information, click the associated “Manage” link to access the dialog where you can make your choice about it.

TIP: Use the new Property List Editor in Xojo’s IDE and add the following Key/Value pair to avoid manually going through the Encryption Export Regulations compliance process:

Key: ITSAppUsesNonExemptEncryption

Value: False

Once the requirement has been completed, the build status will change to “Ready to Submit.” As you can see, it also indicates that this build will be available to your testers for the next 90 days before expiring. This should be enough time before you send new test builds to them, anyway.

For each of your apps, you can create as many tester groups as needed. By default, there is only one entry: “Internal Testing.” You can create additional groups and add any members of your Apple Development Team to the groups you create. Click on the “+” icon to create your first group.

Give the new group a name and uncheck the “Enable automatic distribution” checkbox. Then, click the “Create” button.
Once the new internal testing group is created, you will be able to assign any uploaded (and not expired) builds of your app to it. You can also add members to the group (remember, these should be members of your Apple Developer Team!).

However, having internal testing groups might not be very helpful if you are a solo developer or part of a small team. The good news is that once you create the first, mandatory internal group, a new option will be added to the TestFlight sidebar.

External Testing

In this case, you will be able to invite up to 10,000 members to test your app. The main difference compared to internal groups is that once you select a build to be tested in any of the external groups, it must go through the Beta App Review process. This means the build won’t be immediately available to your testers until the review is complete. However, this process is only required for the first build—subsequent builds will be available immediately, just like in internal groups.

When inviting members to an external group, you have several options: you can create and share a public link, manually add testers, or even import them from a .csv file.

In any case, your testers will be able to download, install, and begin testing your app, as well as provide feedback!

In Summary

The new Publish feature simplifies the process of submitting your macOS and iOS apps to App Store Connect, making them available on the Mac App Store and iOS App Store directly from the IDE, without needing any external apps (such as Transporter).

Provisioning Profiles for macOS Apps

Javier Menendez — Thu, 30 Jan 2025 15:22:00 +0000

Continuing our series on distributing Mac apps, this post will take you through properly setting up a provisioning profile, which is required for your apps to get tested by others in TestFlight. To review or catch up on earlier steps in this process, see my posts on Sandboxing, Hardened Runtime and Notarization arrives to the Xojo IDE, macOS Apps: From Sandboxing to Notarization, The Basics and Uploading macOS Builds to App Store Connect. But if you have those steps done, let’s set up the provisioning profile you need.

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:





	com.apple.security.app-sandbox
	
	com.apple.security.files.user-selected.read-write
	
	com.apple.application-identifier
	BW7PU32485.com.aprendexojo.vcardtoqr
	com.apple.developer.team-identifier
	BW7PU32485

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!

More in this series on distributing Mac apps:

Uploading macOS Builds to App Store Connect

Javier Menendez — Tue, 14 Jan 2025 20:53:32 +0000

Since Xojo 2024r4 the IDE includes the ability to automatically compile macOS apps with Sandboxing, Hardened Runtime and Notarization. Continue reading to learn that extra step in order to submit the created bundle directly to the App Store Connect website!

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.

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.
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:




	CFBundleShortVersionString
	1.0.0
	CFBundleVersion
	1.0.0
	LSApplicationCategoryType
	public.app-category.business

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:

	LSApplicationCategoryType
	public.app-category.business

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:




	com.apple.security.app-sandbox
	
	com.apple.security.files.user-selected.read-write

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.

More in this series on distributing Mac apps:

Sandboxing, Hardened Runtime and Notarization arrives to the Xojo IDE

Javier Menendez — Tue, 10 Dec 2024 16:37:15 +0000

Starting with Xojo 2024r4 it is possible to apply Sandboxing, Hardened Runtime and Notarization on macOS apps built from the Xojo IDE on macOS and Windows.

These new options are available in the Inspector Panel when selecting the Sign step available under Build Settings > macOS.

Requirements

In order to apply Sandboxing, Hardened Runtime and go through the Notarization process for your macOS app, you will need to make sure that the following is installed on your Mac:

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.

Sandboxing

With the Sandboxing switch enabled, you can access the associated editor in order to enable the appropriate entitlements for the purposes of the app.

The Sandboxing settings will be applied even when the app is run from the IDE (debug mode). That means that Sandboxing can be applied both using an Ad-Hoc Certificate or the user Developer ID Application Certificate.

Hardened Runtime

When the Hardened Runtime switch is enabled, you will be able to access the associated editor in order to set the appropriate hardening entitlements for the purposes of the app.

Note: The Hardened Runtime will not be applied when the project is run from the IDE.

When building the app, if Hardened Runtime is enabled and no Developer ID Application value is entered in the Developer ID field (that is, signed as ad-hoc), then the following dialog will be shown and the build process will stop.

Notarization

When the Notarization switch is enabled, it will automatically enable the Hardened Runtime Switch if it is not already enabled (because the Notarization process requires Hardened Runtime!).

With the Notarization switch enabled, you will be able to access the Setup dialog in order to setup the app-specific password required by this process to properly work. Creating this password only needs to be done one time, because it will be saved to the computer keychain and even synced via iCloud to others Macs from the same user (that is, iCloud account).

Note: As with the Hardened Runtime feature, the Notarization process will not take place if the project is run from the IDE.

When building the app, if Notarization is enabled and no Apple Development value is entered in the Developer ID field, then the following dialog will be shown and the build process will stop.

The Notarization process does require an active network connection to the Internet because it needs to talk with the Apple Service responsible of checking the app bundle contents. This means that the required time to complete the process will vary depending of your Internet connection speed and the load or availability of the Apple Notarization service itself.

Custom User Entitlements

Besides the entitlements you may have selected in the Sandboxing and Hardened Runtime editors, you may need to add other ones not available in these editors. This is something you can do through the User Entitlements field (.Plist file format). Such custom entitlements will be merged with the ones selected in the editors. If the custom entitlements entries collide with the ones selected in the editors, then the ones from the editors will be applied, discarding the duplicated ones found in the provided file.

Building macOS apps… from Windows

When the macOS app is built from Windows, and Sandboxing, Hardened Runtime or Notarization is applied (and optionally custom entitlements), then the final compressed archive will include all the required supporting files including the shell script required to run from a macOS computer to complete the signing process using the provided Apple Developer certificate (except the option to create an App-specific password for the Notarization step, because that can’t be done from Windows).

Summary

As you can see, Xojo 2024r4 streamlines the ability to apply Sandboxing, Hardened Runtime and Notarization to your macOS apps, and even run them as sandboxed from the IDE, so you can get better feedback during the debugging process to everything related with the access to files, network user, camera access, etc. That is, the same behaviour your users will have once they run the app downloaded from the Mac App Store or from your website.

See detailed steps in the Xojo Documentation. If you need to know about what Sandboxing, Hardened Runtime or Notarization means, please take a look to the “macOS Apps: From Sandboxing to Notarization, The Basics” blog post.

More in this series on distributing Mac apps:

macOS Apps: From Sandboxing to Notarization, The Basics

Javier Menendez — Thu, 22 Aug 2024 15:45:28 +0000

You are likely already familiar with terms like Sandboxing, hardened runtime and Notarization. After all, these are required if you plan to distribute your macOS apps through the Mac App Store. But, starting with macOS Sequoia 15 (expected in the fall of 2024), Apple has tightened the runtime security protections even more. For example, it was common to Control + click on any downloaded macOS app from Internet that has not been signed and simply choose the Open option from the contextual menu to open it. That won’t be an option under Sequoia (although it still possible to run the unsigned app).

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:





  com.apple.security.app-sandbox

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  -s "Developer ID Application: "

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  -s "Developer ID Application: "

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

It will produce an output similar to this one:

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:

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

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

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

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 "" --team-id  --password

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

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  --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  and initiating connection to the Apple notary service...
Submission ID received
  id: 
Upload progress: 100.00% (8.65 MB of 8.65 MB)   
Successfully uploaded file
  id: 
  path: 
Waiting for processing to complete.
Current status: Accepted........
Processing complete
  id: 
  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  --keychain-profile "notarytool-password"

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 ""

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

> spctl -a -vvv -t install

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

source=Notarized Developer ID
origin=

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:

Create a DMG container (file).
Copy your already notarized app bundle into it.
Notarize the DMG file.
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!

More in this series on distributing Mac apps:

iOS: Privacy Editor

Javier Menendez — Wed, 26 Jun 2024 15:00:00 +0000

Back in March we wrote about Apple’s new privacy policy for AppStore approval and how, and when, your Xojo iOS apps would meet this new requirement. In Xojo 2024r2 we’ve included a new Privacy Editor in the Xojo IDE. Continue reading to discover how to use the iOS Privacy Editor.

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

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

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

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

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

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

Creating an Android Emulator in Android Studio

Geoff Perlman — Wed, 09 Aug 2023 13:30:00 +0000

In order to test the Android apps you create in Xojo, you either need to have an actual Android device (Xojo supports on-device testing/debugging) or you need to set up an Android Emulator in Android Studio. Read on or jump over to Xojo YouTube Channel to watch this process in our Creating an Android Emulator video.

If you haven’t already downloaded and installed Android Studio, do that now.
Launch Android Studio.
If you have already created a project in Android Studio, you can open that project. Otherwise, click the New Project button.
In the dialog box that is displayed, choose the default project type.
Click the Next button then click the Finish button.
Once you have a project open, choose Tools > Device Manager. The Device Manager pane appears on the right side of the project window.
Click on the Create Device button. The Virtual Device Configuration dialog box appears.
Choose the category for the type of emulator you need. Phone is chosen by default.
Scroll through the list of devices to find one that suits you. We recommend choosing one that has the Google Play Store icon in the Play Store column.
Click the Next button.
On the System Image page the appropriate system image for the device you selected should be automatically selected for you. Just make sure the version of Android is at least the minimum version supported by Xojo.
Click the Next button.
On the final page you can rename the device if you’d like. If you’re going to be creating a lot of Android apps, consider increasing the storage in your emulator by clicking the Show Advanced Settings button and then scrolling the lefthand pane down a bit until you see the Internal Storage field. It defaults to 2048MB so you might want to increase that a bit.
Click the Finish button. Your emulator appears in the Device Manager pane.
Quit Android Studio and go to Xojo. Android Studio cannot be running while you use emulators in Xojo.

Now you’re ready to use the emulator you created.

In Xojo, open an Android project, in the Navigator click on Android under Build Settings and you’ll see the Android Debugging section. If you have only created one emulator, it will be selected by default. If you’ve created several, they will all be listed.

The first time you use a new emulator it takes Android Studio it takes a bit longer than normal for it to launch. These emulators also sometimes stop working. When that happens, launch Android Studio, open a project or create a new one, go to Tools > Device Manager to display the Device Manager pane, delete the bad emulator and create a new one.

Don’t forget that Xojo supports on-device debugging (Video: Setting Up On-Device Debugging on Your Android Device) as well so if you have an Android phone or tablet, you can run your apps directly on the device which you may find to be a better overall experience for testing and debugging.

Learn more about using Xojo Android in the Android category in the Xojo Programming Blog.

The Versatility of Xojo

Jérémie Leroy — Tue, 06 Dec 2022 16:49:04 +0000

It is soon time for the end of year festivities. Many people around the world are celebrating the holidays by giving gifts, which means more and more people are organizing Secret Santa events. During these events, members of a group of friends, family, or colleagues will draw names to become someone’s Secret Santa and then give them a holiday gift, usually something fun.

Did you know?

Secret Santa is known by different names around the world, such as “Amigo Invisible” in Spanish, “Amigo Secreto” in Portuguese, “Тайный Санта” in Russian.

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

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

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

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

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

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

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

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

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

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

Leveraging the biggest advantage of Xojo – Sharing code across platforms

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

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

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

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

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

I knew I wanted to display two columns of data:

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

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

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

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

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

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

Wishlist on a desktop browser:

Wishlist on a mobile browser:

Deploying the app to Xojo Cloud was extremely easy.

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

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

The next feature request

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

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

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

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

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

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

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

The Crazy Exercise that is the Apple Signing Process

Greg O'Lone — Tue, 26 Oct 2021 20:31:46 +0000

Anyone who dabbles in macOS or iOS development in Xojo (and elsewhere) has encountered what seems to be the maddening voodoo of getting their development certificates and profiles “just right” only to have them fail the next time they try to build.

Today I’m going to try to clear up some of the mystery surrounding this convoluted process and give you some pointers not only for fixing but also for figuring out where your signing issues lie.

It’s All About Operational Security

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

Seemingly Disparate Pieces

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

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

Dependencies

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

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

Profile Type	Application Identifier	Devices	Development Certificates	Distribution Certificate
Development	X	X	X
Distribution	X			X

Troubleshooting

Overall

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

Certificates

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

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

Enterprise Distribution

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

Guest Post: What is ASO and Why is it Important?

Gummicube — Mon, 22 Jun 2020 16:00:00 +0000

App Store Optimization (ASO) is important for app developers to gain keyword visibility, downloads and retention on the Apple App Store and Google Play Store. ASO can provide an app developer with the insights into keyword visibility, best practices for designing app pages and mobile marketing strategies. A good ASO strategy will help drive users to the app and convert to installations from high quality users at a low overall cost.

There are several key aspects to App Store Optimization. One must assess all of them to fully understand what ASO is and why it’s important.

What is ASO?

App Store Optimization is the process of improving the entire marketing funnel of an app. This includes optimizing metadata to increase organic search impressions, running creative A/B testing to improve conversion across all marketing channels and aligning organic and paid campaigns to improve the overall cost per install (CPI) of a campaign. Yet this is just the tip of the iceberg; the optimization process is an in-depth analysis of all aspects of the app and user behavior on the app stores.

ASO is critical to any app marketing program as it sets the foundation for success. This can help apps get off the ground or provide new vitality for existing apps. The process includes optimizing keywords, designing an app listing to maximize conversions, retaining users and running researched and efficient paid marketing campaigns.

Keyword Optimization

One of the first aspects of the App Store Optimization process is optimizing your product page and the keywords you want the app to appear in searches for. The goal here is to improve your app’s discovery in search results. This is important since the majority of app discovery happens in search results, making it a vital channel for an app to reach new users.

Users typically search for terms focused on functionality, features or specific brands. With that in mind, the app metadata should include terms related to the functionality, demographics and branding. A photo editing app will want to focus on editing and photography terms, a streaming app on live stream and video terms, an app related to a popular brand will want to leverage its name recognition and so forth.

At the same time, not all terms are equally valuable. It is important to identify what terms have the highest relevance and search volume. Doing so requires accurate data sets using mobile search volume. Using web search volume, which only has a 20% overlap with mobile search, risks targeting terms with little to no value.

After the metadata is updated, it may take some time for the store to index the app. On average, this takes up to 30 days on the App Store and 45 days on Google Play. After this point, it is recommended to update again in order to continue helping the app index for keywords.

Conversion Optimization

Conversion optimization is another aspect of ASO that will help your app gain installs. One goal of conversion optimization is to improve your click-through rate (CTR). This signals to the stores that users are finding your app relevant for its keywords, thus increasing organic ranking and providing further visibility. Apps compete for clicks on a keyword-by-keyword basis, so the amount of clicks an app receives for each keyword plays a big role in how it ranks compared to the competition.

While keyword optimization focuses on organic search visibility, conversion optimization can help increasing app installs across all channels, including paid.

Conversion optimization takes place in both search results and product page. It requires designing all aspects of the app listing and testing to create variants that result in the maximum number of installs. This includes anything visible to the user that may impact conversion, such as the icon, title, screenshots, video and description.

When users see an app in the Apple App Store’s search results, they will see the icon, title, subtitle and first one-to-three screenshots. If the app uses portrait mode videos and screenshots, it will display the first three; if it uses landscape mode creatives, it will display the first one. On Google Play, users will see the icon and title, although for mobile games, Google has begun displaying screenshots and videos in the search results as well. The differences between how the platforms display search results and product pages is an important factor to consider when testing creatives.

Conversion optimization requires research into the app market to identify common trends and designs that could be contributing to high conversion rates. After identifying these elements, developers can run A/B tests on their own app listings to determine which variants result in the most installs. Continually testing new iterations helps developers create optimized listings that have a high CTR and conversion rate.

Paid Marketing

In addition to the benefits from advertising, paid marketing is an effective way to supplement your organic visibility. Beyond additional users to your app, paid marketing helps galvanize the store’s algorithms, which can help accelerate your organic indexation.

Apple Search Ads and Google Ads can have a direct impact on how an app ranks for keywords in the respective stores, whereas third party channels such as Facebook or ad network traffic impact how fast you can index for keywords. In both instances, the paid marketing traffic has a positive effect on your organic rankings as well.

The clicks gained from paid marketing helps improve organic rankings, so your traffic can improve even outside of the paid campaigns. The additional organic installs gained from this can potentially lower the overall cost per install.

Ultimately, paid app marketing plays an important role in a mobile marketing strategy. This is why many companies and developers run paid marketing as part of their ASO campaigns.

In-App Retention

Getting installs is an important part of the App Store Optimization process, but it does not end there. The next step is keeping users engaged.

It is key to monitor your in-app retention, including tracking how users are interacting with the app and for how long. These metrics will help you understand your audience’s behavior and where the drop offs are. This can help you retain new users you acquire and bring back users you may have lost.

Additionally, understanding your in-app metrics can help identify any areas where users are encountering hurdles or user retention begins to drop. These are pain points that you can address in updates to improve retention. Uninstalls are factored into app ranking algorithms, so low retention can negatively impact how your app ranks.

Using these metrics as part of the optimization process can help lead to overall improvements to your users’ experiences. That in turn can lead to a higher return on investment (ROI) and positive reviews as the campaigns produce more loyal users.

To Conclude

App Store Optimization (ASO) is the process of developing and improving all aspects of an app and its listing to maximize visibility, downloads and retention, making it critical for any mobile app marketing program. ASO best practices are designed to create the foundation for organic discovery and improve the efficiency of traffic leading to the app.

In order to properly implement an App Store Optimization strategy, it is critical that developers optimize for visibility, conversions and retention, as well as invest in paid marketing. Employing the right data and methodology can help lead to the highest quality users at the lowest cost and provide an app with the growth and visibility it needs to thrive. App Store Optimization can make the difference between an unknown app and the next success story.

In-App Purchases Tutorial on iOS

Ryan Hartz — Thu, 19 Dec 2019 10:00:00 +0000

This guide is going to walk you through the steps to set up in-app purchases in your iOS apps. It may be best to get things set up first on Apple’s side, following with the app configurations in Xojo.

Apple Developer

Go into Certificates, Identifiers, & Profiles.
Select Identifiers on the left.
Click the plus sign to add a new identifier.
Select App ID and hit Continue to Register an App ID.
Choose iOS under Platform, enter a Description, and enter an ExplicitBundle ID. This must be the same as your Xojo project’s Bundle Identifier. Make sure In-App Purchase is checked (it should be by default).
Click Continue, then click Register on the next screen after you verify the information.

Back in Certificates, Identifiers, & Profiles, make sure you have a physical device listed. This will be used for the IAP test purchase since you cannot test a purchase in Simulator.
Select Devices on the left. If your device is not listed, click the plus sign to add it.
Select iOS as the Platform, enter in a name for the device, and enter in the Device ID (UDID). You get the UDID by connecting your phone to the computer, opening Xcode, choosing Window >> Devices and Simulators, right-click on your device listed on the left and select Copy Identifier.
Copy this into the UDID box in Apple Developer Register a Device.

iTunes Connect

In the Agreements, Tax, and Banking section, make sure you have active agreements for Free Apps and Paid Apps. The process of getting these agreements set up can take a couple of days.

Set up the new app:

Go to My Apps and create a new app using the plus sign on the left.
In the New App box that appears, check the box for iOS.
Enter a unique name for the app.
Choose the primary language.
Choose the Bundle ID created in Apple Developer.
Enter a SKU number.
Choose Full Access.

To set up the in-app purchase product select Features at the top, then In-App Purchases on the left. Click the plus sign next to the In-App Purchases and choose which IAP you are using in your app then click Create.

There are 3 options when choosing which IAP is right for your app:

Consumable: Think of tokens to buy in a game. Once they’re spent, you need to buy more.
Non-Consumable: A one-time purchase to unlock a feature
Subscriptions: Auto-renewing or non-renewing

Fill out the necessary data on the following screen:

Reference Name: This is a name that is not displayed to the user. It is only for your reference.
Product ID: Enter in the Bundle ID you made in Apple Developer but also include an end tag of the in-app purchase product name. For example, your Product ID might look like com.mycompany.myapp.myinappproduct.
Check the box for Cleared for Sale (this should be checked by default).
Choose a pricing tier.
Scroll down, under App Store Information enter in a Display Name and a Description. These will be shown to the user.
Scroll down to Review Information. You can include a screenshot of your app now or you can save your IAP product and add in a screenshot later. If you skip adding a screenshot, you will see a message saying Missing Metadata. This message will go away after you add a screenshot. The screenshot needs to be at least 640×920, which is the size of the iPhone 5s. The screenshot I used is a display of my purchase view in the app. Not sure if that is what they expect, but the app and IAP got approved.

Next set up your sandbox testers. Choose Users and Access from the top drop-down menu then select Testers on the left under Sandbox. Add at least one sandbox user for testing, preferably two or three so you can try a purchase more than once. Your sandbox user accounts cannot be tied to an Apple ID account. Use a personal email address for yourself that is not with Apple or make a new account in Gmail or Yahoo. After you create a sandbox user, you will need to verify the account in the email box you created, so it is best to create the email account first to make sure it hasn’t been taken.

Turn on In-App Purchases Xojo

Under Build Settings in left panel, click iOS.
Then, in the Inspector, click the Entitlements (gear icon) and move the switch for In-App Purchases to on.

Include Jason King’s iOSKit folder.
In my sample project, I have a ModalPurchaseView to handle the purchase/restore pieces. If you want to activate this the same way, add to your project Jeremie Leroy’s iOSExtensions which has the method to call the modal in a neat way. The ModalPurchaseView from the sample project can be copied to your project and used to cover the purchase/restore functions. Be sure to change the pieces in the code that points to your in-app purchase product, such as com.mycompany.myapp.myIAPproduct
Build your app with all features, then choose which features you want to be included in your premium version. I have a boolean property ActivatePremium in Module1 to be set to true if the premium is purchased.

Testing the In-App Purchase

You won’t be able to test the IAP in Simulator, so don’t even try. Instead, you will need to test on a physical device.

Build the completed project in Xojo.
Connect your device to the computer and open Xcode.
In Xcode, select in the top menu Window >> Devices and Simulators.
Drag the app from your Builds folder to the bottom pane of the Devices and Simulators window in Xcode. It’s the one with that looks crossed out.

You will need to sign out of your Apple ID on your device. In the Settings of your device, go into the iTunes & App Store section, click your Apple ID at the top, then click Sign Out.

Open your app and click the Purchase option. You will be asked to sign in. Sign in with your sandbox account you created. After you sign in, you should see a Confirm Purchase [Sandbox Environment] box. Enter in your password and see what happens.

If you need to test it again, go back into Settings >> iTunes and App Store, scroll to the bottom, and sign out of the sandbox test account. Try with another account.
You should also test the Restore function of your IAP. It might be best to test this before testing a purchase to make sure you don’t end up getting the app for free without “purchasing”. When testing your Restore after purchasing, you will need to delete the app from the device and add it back through the Xcode method above in steps 2 through 4.

Credit to Jason King for creating iOSKit and to Jeremie Leroy for his personalized help with helping me get my first iOS app with in-app purchases off the ground. I hope you found this tutorial useful. You can download the project here.

Ryan Hartz has been a Xojo user for over 10 years. He is a registered dietitian with no formal education in software development, illustrating that anyone can learn development in Xojo with its ease of use and understandable language. In 2005, Ryan started his company, Visual Veggies Software, which offers software study guides to young nutrition students preparing to become registered dietitians.

Guest Post: Achieving Success As A Xojo Developer

Xojo — Thu, 14 Mar 2019 10:00:38 +0000

I’ve spent most of my career developing custom software. I’ve worked as an in-house developer creating custom “line of business” solutions. I’ve worked for software development firms that provide custom software for clients. And I’ve primarily been a self-employed custom software developer since first going out on my own in early 2000. Today, a lot of the work that I’m doing involves developing custom software solutions using Xojo.

I’m often asked by other developers – some who are already using Xojo and some who are not – where the opportunities for Xojo developers are, and how to find them. I also occasionally see these types of questions posted on the Xojo forum by developers who want to use their knowledge of and passion for Xojo to start their own business. So I thought I’d share some of my experiences and observations.

Custom Solutions

There are a number of Xojo developers who have been successfully selling commercial software solutions. For example, there’s EverWeb, Jeremie Leroy’s Packr, and the amazing color management applications provided by CHROMiX, to name just a few.

However, in my case, it’s all about custom software. Businesses turn to me for highly specialized software that simply doesn’t already exist. These are solutions that are tailor-made to meet their business needs and fit seamlessly into their processes. One of the many things that I love about Xojo is that regardless of what type of solution a client needs, I can build it for them. With Xojo, I can develop web, desktop, iOS, and even Raspberry Pi apps – and Android apps will soon be possible as well. But best of all, because Xojo is a rapid application development platform, I can deliver solutions quickly and affordably. And needless to say, clients love that.

Enhancing SaaS Solutions

To help reduce costs and increase efficiency, many businesses are moving “to the cloud.” They’re using Software as a Service (SaaS) and Platform as a Service (PaaS) solutions. Oracle’s NetSuite, a cloud-based ERP system, and SalesForce, are two popular SaaS examples that you may have heard of.

It’s probably not surprising that this move to SaaS has had a big impact on my business, and you’re probably thinking it has been a negative impact. But you’d be wrong. In fact, SaaS has actually opened up new – and very lucrative – opportunities for me.

Here’s why. These services try to be “all things to all people.” (Or, more accurately, all things to all businesses). They provide everything from contact management, quoting, order processing, inventory … you get the idea. And it’s that breadth of functionality, and the tight integration between those functions, that appeals to many businesses.

However, businesses often find that they have needs that these solutions don’t address. And that’s where the opportunities for custom software developers come in. We have the ability to develop external solutions that integrate with SaaS systems. And as I mentioned earlier, with Xojo, we can develop those systems quickly and affordably. It’s simply a matter of learning how those systems allow integration. At that point, with Xojo, wiring up to them is usually quite easy.

Of all of the opportunities that I’m running into these days, it’s the integration with SaaS that has me the most excited.

FileMaker

I’ve been developing with FileMaker for many, many years. At one point, I even wrote a book on it. But back in 2015, I saw changes coming to the platform that lead me to begin move away from it. Increased pricing. Licensing changes, and so on.

Today, while Xojo is my preferred development platform, I am still actively doing FileMaker work as well. But it’s very different. I very rarely develop new FileMaker databases. Instead, clients – many of whom are FileMaker developers – are coming to me and seeking help. Some are looking to make the most of their investments in the FileMaker platform. Others, including several FileMaker developers, are looking to migrate their solutions from FileMaker to Xojo.

While having experience with FileMaker certainly helps, I strongly believe that you don’t need FileMaker experience to be successful with these projects. The trick, I think, is to think of FileMaker as just another database. Sure, it’s different from the databases that you’re probably used to dealing with, like MySQL, SQLite, and so on. But FileMaker is, essentially, a relational database. And if you’re curious about how you can connect to it from Xojo, check out Temper, a Xojo-based, open source Web API for hosted FileMaker databases.

Finding and Attracting These Opportunities

I’ve discussed the types of opportunities that I’m seeing for Xojo developers. But you’re probably wondering how to actually find these opportunities.

I’m sure that if you try hard enough, you’ll eventually stumble upon these opportunities on job boards such as UpWork or even Craigslist. But I’ve found that the best way to get business is to have prospective clients come to you. In other words, don’t just look for business opportunities, also do things that will attract business opportunities to you.

To do that, you’ve got to give prospects something to be attracted to. A way to learn more about you, your skills, your experience, and so on.

While I’m not a fan of social media, I’ve found that LinkedIn is a great way to network with people, including people that you already know and new business contacts as well. (If you want, connect with me on LinkedIn.) Of course, you should also setup a professional Web site. This is becoming increasingly easy to do, with services such as SquareSpace and Weebly. And be sure to check out EverWeb, which I mentioned earlier.

When you get your site in place, consider adding a blog to it. Even if you only post occasionally, I think you’ll find that it helps to attract prospective clients. My advice: Write about technical topics (that developers like us will understand) as well as topics that a non-technical business person will understand.

I’m probably one of the shyest people that you’ll ever meet. However, I really try to move outside my comfort zone by attending conferences and user group meetings. And I’m really pushing myself when I present at these events. This is a great way to meet other developers, and you never know what might come from making those acquaintances. If I can do it, you can, too.

And finally, you should consider investing in a Xojo Pro license. With Xojo Pro, you not only get the ability to compile your apps for all of Xojo’s targets (desktop, Web, and iOS), but you’ll also get access to consulting leads that are posted to a special area of the Xojo Forum. My investment in Pro has more than paid for itself.

Wrapping Up

Whether you’re a Xojo developer that is already doing development for a living, or a developer that is considering it, I hope that the experiences, observations, and tips and tricks that I’ve shared will help you achieve success. If you have any questions, feel free to reach out to me on the Xojo forum. And I hope to meet you at XDC.

Tim Dietrich is a custom software developer based in Richmond, Virginia. To learn more, visit: https://timdietrich.me

Name Your App

Dana Brown — Wed, 25 Jul 2018 10:00:27 +0000

Naming your app may seem like the last step and the easiest part of the process, but it actually should involve some careful thought and consideration. A name needs to set the right tone for your app, should relate to it in some way, and should be searchable, meaning something that can be found easily in search engines. For example, you don’t want to name your app TravelTips – there are thousands of google searches that will come up before your app. You want a name you can own.

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.

What is the main purpose of your app?
Who is the target audience?
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!

App How To: Packaging, Selling & Marketing

Xojo — Mon, 16 Jul 2018 13:00:00 +0000

Are you ready to sell your app? Whether you have a web app, desktop or mobile app, it’s time to think about how to package and distribute that app, how get the word out and, of course, how to get paid for sales.

In this #longread blog post, we’ll walk you through preparing your app for distribution, offering your app on your website and in app marketplaces for sale, as well as first steps to marketing your app.

When designing a commercial app for sale, an important thing you need to consider is how you will get the app to people who buy it.

Packaging Your App for Distribution

Desktop and mobile apps will need to be distributed, whereas a web app usually requires the user set up a log in and sign up for a subscription and is not distributed separately.

Mobile Apps

To package your iOS app you’ll need an Apple Developer account to generate the certificates and provisioning profiles required by Apple. After that is set up, go to the iOS Build Settings and turn on the switch for Build For App Store and Build your app. This creates a special ipa file that can be submitted to the App Store using App Connect. You can read the steps in more detail here: Submitting to the App Store

You can also read this earlier post on how deploy iOS apps to your devices without an Apple Developer Membership.

Desktop Installers

You’ll definitely want to use an installer to distribute your Windows apps. We’ve previously blogged before about free and paid options for Windows installers in detail.

On macOS, many apps are distributed as simple ZIP files that you can create from the Finder. Or you can use Disk Utility (or another utility such as DMG Canvas) to create a DMG (disk image). If you need an installer on macOS, which is not often the case, try Packages or PackageMaker (included with Xcode).

On Linux, you can also distribute your apps as ZIP files or you can take the more complicated route of creating a specific distribution file (deb or rpm) for the versions of Linux you target.

Demo Mode or Limited Free Trial

People like to download and try out software before purchasing. We highly recommend that you offer some features of your app for free or for a limited free trial to entice people to give your app a shot.

For iOS apps, the App Store does not have great support for demo or trial apps. One option is to make two versions of your app: one that is a free demo and one that is a paid app. Another option is to make your app a free download and to use in-app purchase to unlock the full version.

Desktop and web apps offer more options regarding demos and trials so think about what will work best for your app. Do you want a free demo version? Will you limit the demo by time (14 and 30 days are common) or by number of uses (4 free uses)? Another common option is to limit the app to running with some feature limitations if no license key is entered. You can even combine the two so that a trial reverts to a demo after the trial expires.

Regardless of what you choose, you’ll need to make sure this is all designed into your app before you release it.

License Keys & Serial Numbers

Often, an essential part of commercial software is generating license keys or serial numbers. When a customer purchases your app, you can provide a license key to unlock the full features of your app or stop the timer on a time-limited trial. You can build your own license key generation and verification functions into your app. This is relatively simple to do by creating a web service with a Xojo web app. Two solutions that can help you get started are AquaticPrime and RegCode.

If you are need to save time, look into developed solutions offered in the Xojo Add-Ons Store such as the GuancheMOS Plugin, a cross-platform serial number creation and validation engine, for Windows check out Quick License Manager for licensing trials for perpetual or subscription licenses.

Selling Your App

Once you have your app packaged to distribute, you’ll need places to sell it and ways to get paid.

Selling on your Website

You should definitely have a Web site with a specific landing page that talks about the product and shows the price. This makes is easier for your page to be found when searching the web. A landing page is a stand-alone page that includes highlights of what your app offers, your demo video and a call to action. (Learn more about landing pages.) Make the page’s focus your “call to action”, whether that is to watch the demo video, download or purchase the app, or to create an account.

Even if you only have an iOS app that is sold via the App Store, a landing page is useful, some say essential, making it easier for people to find your app and for you to share it on social media.

Selling at a Marketplace

In addition to selling on your website, you may want to investigate getting your app into an appropriate app store. App stores are often where people look first for apps, plus most app stores make it really simple for users to install and upgrade apps. And they make getting paid a lot simpler. However, App Stores can take a percentage of the sale (commonly 30%) and may have significant restrictions and a lengthy approval process before your app can be ready for sale.

If you are selling a macOS app, you might want to make it available in the Apple’s Mac Store. Here are some examples of Xojo apps in the Mac Store. For iOS apps the only option is the App Store and we’ve blogged about how to get your Xojo iOS apps in the App Store.

To sell something in either the App Store or Mac App Store you need to be a member of the $99 Apple Developer Program. You also have give Apple 30% of each sale, wait for them to approve your app for sale and wait for approvals for any app updates. The App Wrapper tool can help make it easier to package your Mac apps to sell in the Mac App Store.

Of course there is the Windows Store for your Windows apps. If you use Advanced Installer, the Desktop Bridge Setup Converter can be used to convert an installer to one that is compatible with the Windows Store. More information is available in this article: Build an AppX Installer for Microsoft Store with Xojo.

If you are selling a Xojo-related tool, library or plugin, another option is to sell it in the Xojo Store in the Add-On Product section. There is no charge for this and you get to keep 70% of the sale. Contact us if you are interested.

Getting Paid

With apps sold in the app stores you’ll get paid by the store guidelines, usually once a month for the previous month’s sales, though some store may set a minimum payment before they pay up.

For desktop apps or web apps that have subscriptions you’ll need a way to handle payments. Rather than setting up your own merchant account and dealing with that, it’s increasingly common to use an existing payment processing service like PayPal or FastSpring.

If you are not already familiar with how PayPal works, you can learn more here. FastSpring lets you create a “store” with your products, pricing, a shopping cart, currency conversion and will take payments from credit cards and other means. FastSpring takes 8.9% per transaction with a minimum order fee of $0.75 or 5.9% + $0.95 per transaction; PayPal is 2.9% + $0.30 per transaction (rates from July 2018).

Regardless of the service you use, you will need to hook it up to an account to receive payment. Typically you hook it up to a checking account or PayPal. Other services you might want to check out include: Gumroad, Stripe, Paddle, and 2CheckOut.

Marketing Your App

Now your app is packaged and available for sale on your website and an app marketplace or two. How do you get the word out? Here are 3 musts when it comes to app marketing:

Press Release

You’ll need a Press Release that announces your app, explains what your app does and why people should buy it – here’s a template and example.

For a small fee, services like PR Newswire will send out your press release to a wide variety of websites for you. We also want to help promote your #XojoMade app! Email your press release to pr@xojo.com and we’ll post it on the Announcements channel in the forum and share it on Twitter.

Demo Video

Yes, you should definitely have a demo video! Either more of a traditional software demonstration, a commercial that lists your app’s top selling points or some combination of the two. Keep it short and sweet – feel free to follow up with a longer, more in-depth video, but to grab perspective users you’ll want something less than a minute. Video is much more digestible and easy to share than the written word and you can create a good one on your own.

Outside Listings & Reviews

Get your product listed on app download services, such as MacUpdate or Download.com. Once listed, you’ll want reviews because one of the most trusted forms of marketing is word of mouth. You believe the word of a colleague over that of a commercial, right? Ask your users to post honest reviews of your app in app marketplaces and on third party sites. If your app is new, or just needs the reviews, think about offering a discount or swag for a review.

Now What? More Marketing Tips from Dana and Alyssa

Here are some great posts to explore simple and often free options for marketing your apps:

Free Marketing! 4 Practical Tips for Developers New to Twitter

How to Record Video Demos for your iOS Apps

8 Ways to Market Your App for Free

Dana Brown — Thu, 16 Nov 2017 10:45:12 +0000

Though marketing may not be your forte, there are things you can do that are very effective in promoting your app and building your customer base. You can try some of the paid options and get varying results, but there are many free things you can do that can have a huge impact. We’ve already blogged about using Twitter to market your app for free.

Here’s a list of 8 additional ways your marketing team of 1 can promote your app at no cost:

1. Build a small website

Don’t compare your app or your website to the big fish in the market. You don’t need to have a big, fancy site to get started. Create a simple website (just 1-2 pages to showcase your app) or even use a pre-made template or website builder like Everweb, which is made with Xojo, to pre-announce your app. Launch your website about a month or two before you plan on releasing your app and collect email addresses of people who might be interested in hearing from you when your app launches. Keywords are important for search engines, so make sure that you play up keywords about your app when writing your text.

2. Have a blog

Blogs can be a great way to to attract readers and draw them into your website. Start a blog and update it often with content that relates to your audience. Do make a schedule for the month with the blog posts you think you can put together. Don’t fill your blog with filler content that has nothing to do with why your your readers visit your blog. Think about what they’d want to learn more about, or comment on industry news, talk about your app development progress or anything relevant.

3. Share your content

Use your social media outlets like Twitter, Facebook, LinkedIn to promote your app, blog posts, product updates, etc. at least several times a week.

4. Create a product video

Become your own video editor! Make a short, creative video to showcase your app and what it can do. Shoot for a funny or thought-provoking theme for your video. Share your video on YouTube and link to it via other social media channels.

5. Contact bloggers

Find bloggers who write about topics that relate in some way to your app or who are interested in app development, technology, etc. For example, if your app has something to do with music recording, contact bloggers that cater to musicians.

6. Always be collecting emails

An email list of people who have opted in (given their express permission to hear from you) can be a powerful marketing tool. Gather potential customer emails through social media sites and your website. You can use tools like Mail Chimp or Constant Contact to email your audience.

7. Use your email signature

This is often a missed opportunity, but your email signature is something that everyone you talk to sees and a great way to make sure you share a message with everyone. Provide a catchy short description of your app with a download link below your signature block to help your contacts know what you’re up to and get them to visit your website. All of your contacts could be potential customers!

8. Run a contest or promotion

Encourage people to tweet and share content on their social networks promoting your app. A random person each week can win a coupon to download your app for free, for example. Alternatively, run a contest to win a discount coupon for people who opt into your mailing list and build up your email database. Another idea is to offer a code to people who like your Facebook page or follow your Twitter account to grow your online community.

You don’t need a huge budget to get the word out about your app. There are so many things you can do to market your app for free, with a little creativity and will to invest some of your time into promoting your app! Join us at the Xojo Developer Conference for more tips and information on how to market your Xojo app.

How To Record Video Demos for your iOS Apps

Geoff Perlman — Tue, 05 Sep 2017 10:00:00 +0000

If you are making commercial iOS apps, you’ll want a video demo. Video demos can be added to the app store and are great to use in multi-platform marketing and promotions. Keep in mind, a demo is typically short, definitely less than 1 minute and should highlight the core benefits of your app.

For some apps, you can just record the iPhone or iPad screen with another camera especially if you feel you need to show an actual finger doing the tapping. In most cases, however, that’s not necessary and a actual screenshot video would be more effective.

The easist way to record your iOS device for a demo is with the Quicktime Player on macOS. This feature was added in macOS Yosemite.

Plug your iOS device into your Mac.
Launch QuickTime Player.
Choose New Movie Recording from the File menu.
When the Movie Recording window opens, you will see the Record button (a red circle). Next to it is a popup menu icon shaped like a small v. Click that.
Choose your iOS. You’ll see your device’s screen appear in the Movie Recording window.
If you’re going to record your voice while doing the demo, make sure you choose Internal Microphone or use an external one if you have one. Otherwise, the QuickTime Player will default to using the iPhone itself which won’t sound as good.
You have two choices for the quality level. I suggest using the default choice (High) unless that turns out to be unsatisfactory. For most uses it will be fine and produces much smaller files.
Click Record to record your iOS screen.
Do all the steps for your demo.
When you’re finished, click the Stop button.
Save your recording and later you can use File -> Export to save in various formats and sizes based upon how you’re going to use the demo video you’ve made.

Note: The name of the iOS device can be found on the device in Settings -> General -> About -> Name.

The QuickTime Player has some decent functions for clipping and trimming your video as well. If you need titles and more sophisticated features for your demo video, iMovie or Final Cut are great solutions.

Xojo Draw in the App Store

Paul Lefebvre — Wed, 12 Oct 2016 19:10:15 +0000

Want to see how easy it is to make an iOS app with Xojo? Check out Xojo Draw in the App Store. Released last week at the start of XDC 2016, Xojo Draw is an enhanced version of the Xojo Doodle sample project that is included with Xojo. Working on both iPhone and iPad, Xojo Draw lets you draw with touch and save your creations to the camera roll or send to other apps.

In addition, to help you learn how you can create your own iOS apps, the full source code for Xojo Draw is on GitHub (click the Clone or Download button to get it)! Grab the free version of Xojo and the Xojo Draw source code to see for yourself how you can quickly start creating your own iOS apps.

And stay tuned for more Xojo-made apps to appear in the App Store, along with full source code to help you get coding with Xojo iOS!

App Transport Security for iOS

Paul Lefebvre — Wed, 27 Jul 2016 07:10:36 +0000

Last year with iOS 9, Apple announced a new security requirement for your iOS and OS X apps: App Transport Security.

From Apple’s docs:

Starting in iOS 9.0 and OS X v10.11, a new security feature called App Transport Security (ATS) is available to apps and is enabled by default. It improves the privacy and data integrity of connections between an app and web services by enforcing additional security requirements for HTTP-based networking requests. Specifically, with ATS enabled, HTTP connections must use HTTPS (RFC 2818). Attempts to connect using insecure HTTP fail. Furthermore, HTTPS requests must use best practices for secure communications.

Starting with Xojo 2016 Release 2, this change matters to you because Xojo is now using the updated Apple libraries that have this requirement. Simply stated, it means that if your iOS apps use HTTPSocket or iOSHTMLViewer, then your URLs have to be secure (https). If they are not, you will get an error returned with HTTPSocket and no page displayed in the HTMLViewer.

If you are relying on other services or URLs that do not yet support https, then what do you do? Apple has provided a workaround: you have to specify an exemption in your plist file. In the plist you identify specific URLs for which you want to allow unsecured connections. To do this, create a text file called Info.plist, add this content to it and drag the file to the Navigator to add it to your project:





  NSAppTransportSecurity
  
    NSExceptionDomains
    
      firstsite.com
      
        NSIncludesSubdomains
        
        NSTemporaryExceptionAllowsInsecureHTTPLoads
        
      
      secondsite.com
      
        NSIncludesSubdomains
        
        NSTemporaryExceptionAllowsInsecureHTTPLoads

Replace the domain names (or add more) based on your needs. You can also allow all unsecured connections, but Apple may reject App Store submissions that use this without valid reasons:

NSAppTransportSecurity

  
  NSAllowsArbitraryLoads

For additional information, refer to the Using a plist, Xojo.Net.HTTPSocket and iOSHTMLViewer pages in the docs.

Update (August 10, 2016): Apparently there is a bug in iOS that prevents the use of IP addresses in this plist. So to enable http on your local computer for testing use “localhost” rather than “127.0.0.1” and be sure to use “http://localhost” in your URLs instead of “http://127.0.0.1”.

iOS View Navigation Tips

Paul Lefebvre — Wed, 18 May 2016 00:00:00 +0000

Your iOS apps uses Views to display information to the user and often your app will have multiple views to show different information. These views can be displayed in different ways.

PushTo

The most common way to display new views is to use the PushTo method.

With this method, the new view appears on top of the current view and a “back” button is displayed in the Navigation Bar (if it is enabled) to close this new view so that the original view is displayed.

Download the PushTo example to see how this works.

Refer to Views in the User Guide to learn more about PushTo.

Modal View

A modal view is a view that appears over a view, and is a bit more limited. The user cannot display a new view or go back to the original view until the modal view is closed. To display a modal view in your Xojo iOS apps, you have to use a Declare.

Download the ModalView example to see how it works.

Refer to Views in the User Guide to learn more about Modal View.

Change Current Screen

There are times where you may want to reset the view hierarchy so that the “back” feature is not available. An example of this might be an initial login screen displayed by your app. After the user logs in, you will likely want your true main view to replace the login view, but not allow the use of the “back” feature to go back to the login view.

A feature (iOSApplication.CurrentScreen) added to Xojo in 2016r1 allows you to do that by changing the current screen of the app to point to your new view.

Download the Navigation example to see how it works.

Refer to Views in the User Guide to learn more about this.

Splits on iPad

An iPad can be set up with a split view that allows two views to be displayed on the screen at the same time. The view on the left is the “master” and the view on the right is the “detail”. If you’ve used Mail on iOS then you’re familiar with this type of layout.

When you have a split view set up, you can access the base view for the master and detail areas by using the ParentSplitView property of any of the views. ParentSplitVIew is an iOSSplitView with its own properties (Master and Detail) that give you access to the content of the split area.

Download the SplitVIew example to see how it works.

These tips should help you provide great navigation for your iOS apps. If you have an iOS app in the App Store, be sure to tell everyone in the Xojo-made iOS apps in the App Store conversation of the forum and tweet us the link @xojo!

We’ve got lots of resources to get your iOS app started, check them out or click below to learn about building 64bit iOS apps for the App Store.

Getting Your iOS Apps Into the App Store

Paul Lefebvre — Fri, 21 Aug 2015 00:00:00 +0000

Since the release of Xojo for iOS, people have been asking if Xojo apps can be listed in the App Store.

The answer is simple: Absolutely.

Of course, you’ll have to pay heed to Apple’s rules regarding the Mac App Store and follow their very stringent requirements.

You can review Apple’s App Store Review Guidelines here. If your iOS app meets these guidelines, you can create your Xojo iOS app and prepare it for submission to the App Store. This does involve generating certificates, IDs, distribution profiles and then uploading to iTunes Connect. Detailed instructions are availble in the Submitting to the App Store page at the Xojo Dev Center.

I made a simple (and free) Tip Calculator with Xojo that is available in the App Store called TipVue. And lots of other Xojo developers have created iOS apps that are in the App Store. If you would like to see step-by-step instructions on how to submit your iOS app to the App Store, you can also watch this 4 minute video.

All The Ways: Deploying Your iOS Apps

Paul Lefebvre — Fri, 27 Feb 2015 00:00:00 +0000

We’ve been getting a lot of questions about available options for deploying iOS apps.

Geoff recently wrote about how to deploy iOS apps inside a company, but I’d like to collect all the various ways to deploy your iOS here for quick, easy reference.

Ad-Hoc Deployment to Devices

With Ad-Hoc Deployment, you build your iOS apps using an iOS Development Profile and manually copy the built app to the device. To create this profile you need to be a member of the Apple Developer Program (currently $99/year from Apple). You can deploy apps built in this manner on up to 100 devices.

There are step-by-step instructions on how to do this, which you can read about in the Xojo User Guide here: iOS Device Deployment.

TestFlight

For beta testing purposes, you can also use Apple’s TestFlight server to allow up to 1000 users to install a beta version of your app. Use of TestFlight also requires that you are a member of the iOS Developer Program.

Check out the Xojo Docs for instructions on how to use TestFlight: Submitting to TestFlight

App Store

To get your app in the hands of end users, you will typically want to use the App Store. To do so, you will build your app using an iOS Distribution Profile. You will have to be a member of the iOS Developer Program.

Check out the Xojo Docs for step-by-step instructions on how to build and submit an app to the App Store: Submitting to the iOS App Store.

Volume Purchase Program

As mentioned by Geoff in a previous post, the Volume Purchase Program provides a way for you to distribute apps to businesses or educational institutions without having to publish your app to the App Store. Apple has more information on this program:

Enterprise Deployment

Businesses can use the iOS Developer Enterprise Program to get tools and resources for developing proprietary, in-house iOS apps that you can distribute to your employees. These apps are distributed outside of the App Store.

For more information, visit the iOS Developer Enterprise Program.

Other Options

Other than jailbreaking your device, we are not aware of other options for deploying apps to iOS devices at this time.

Guest Post: Solving Sandboxing Issues and Improving Xojo Apps With Ohanaware’s Sandbox Kit

Xojo — Wed, 18 Feb 2015 00:00:00 +0000

Sam Rowlands has been developing Xojo apps since 1997. He and his wife, Joy Sha, make up Ohanaware and they have been building award winning apps since 2008, notably Funtastic Photos, HDRtist and Shine. Sam is an active Xojo developer and he also offers App Wrapper, which simplifies the process of preparing applications for submission to the Mac App Store and deploying on web sites, in the Xojo Third Party Store.

What is the App Sandbox and why is it a chore?

The App Sandbox is a great end user security concept. The Sandbox governs what an application can and cannot do. This means that a virally infected word processor, cannot go on to infect other applications nor rampantly damage files on the users disk. It can however affect files which the user has created or opened within the word processor.

The developers’ pain comes from the App Sandbox’s greatest strength. The app developer must perform additional work, just to reclaim functionality that the App Sandbox took away. If you want to sell an app in the Mac App Store, the app must adopt the App Sandbox security.

Note: There are some functions which simply cannot be done within a Sandboxed application.

Trying to figure out solutions to these new issues often results in much head scratching and consulting with other developers via the Xojo Forums. I’ve seen some really creative solutions to reclaim features when using this security mechanism. In this post, I’m going to cover a few Sandboxing issues and how to resolve them with the tools / code that I’ve built for the apps that we sell.

Chocks away…

Taking my latest, greatest app, which just so happens to be a really cool Text Editor built with Xojo.

1. If I simply Sandbox the application (using App Wrapper 3, with just the minimum), I can create new documents, but I can’t save or even open documents.

2. The Recent Items menu no longer works.

3. I personally like apps that re-open the last documents I was working on. The same issue persists, code that used to work, no longer does.

4. Even more scary, is that users can’t even print- what kind of text editor can’t print?

Problems 1 and 4

We’ll start with the simplest, problems #1 & #4 are easily resolved with the options (“Open & Save Panels” & “Printer”) on the “Capabilities” panel within App Wrapper.

Note: There appears to be a new issue with Yosemite, I’m not 100% certain of the cause, but it seemed that changing the case of the application’s bundle identifier solved it. So “com.ohanaware.mytexteditor” doesn’t work, where as “com.ohanaware.myTextEditor” does.

Problem 2: Recent Items list

In order to solve problem 2, we’ll use the “OWRecentItems” class from the Sandbox Kit. It’s a little more complicated than just selecting checkboxes, but not much more complicated.

Add the Sandbox Kit to your Xojo project.

In the “Open” event of the “App” object, add the following line of code

OWRecentItems.installRecentMenu( fileMenu, 1 )

This single line of code will tell the OWRecentItems class to install the recent menu, you pass in the menu on the to add to, and where in the menubar you’d like the “Open Recent” submenu to appear.

For my Text Editor, I added it to the file menu and in position 2.

3. Now all that’s required is when a document is saved or opened, another line of code needs to be called.

OWRecentItems.addToRecentMenu( file )

Simply call the OWRecentItems class again and use the addToRecentMenu method, passing in the Xojo folderitem where the document is being saved. It will be added to the Recent Menu (it’s okay to call it multiple times as it will only list it once).

That’s it. Now the application has a Sandbox safe recent items menu.

Note: Using this code will also add the Recent Item menu to the App’s dock item. It’s also pretty cool in the fact that the Apple Recent Item system work across Sandboxed and un-sandboxed versions.

Problem 3: Re-opening last open documents

There’s a bit more work involved to implement this solution, the great news is once you’ve mastered it for one window, it’s trivial to add to other windows.

1. In your Xojo application, you need to select your document window and click on the “Choose” button next to “Interfaces” in the Xojo inspector.

2. Some new methods will be added to the Window class.

classIdentifer as string
restoreData( data as JSONItem )
storeData as JSONItem

“classIdentifer” is where we return a identifier, to which our restoration service uses to determine what window instance to create when the data is restored. I tend to return the window class name.

Function classIdentifier() As string
  // Part of the OWRestorableWindow interface.
  return "documentWindow"
End Function

“restoreData” is used to populate the controls when restoring the window. For our word processor, we’ll use the code below.

Sub restoreData(data as JSONItem)
  // Part of the OWRestorableWindow interface.
  if data <> nil then
    if data.hasName( "text" ) then TextArea1.text = data.value( "text" )
  end if
End Sub

It’s important to check that the data object isn’t NIL and also to check for each setting (this will help to future proof your application).

“storeData” is the last method to populate in the Window class. For our purposes we’ll use the following code. It will simply store the TextArea into the property “text”.

Note: As we’re using JSONItems to save and restore the data, it’s not designed to contain vast amounts of data and some data types will need to be converted to text before storing.

Function storeData() As JSONItem
  // Part of the OWRestorableWindow interface.
  if me.folderitem <> nil then call saveFile
  Dim r as new JSONItem
  if textArea1.text <> "" then r.value( "text" ) = textArea1.text
  Return r
End Function

It’s important to know that if you’re writing Auto Save files, this is the place to do so. Once Window Restoration is properly configured, the window will never receive the “CancelClose” or “Close” events. Consider this the last place to save the user data.

Modify the Save routine of the window, to store the file into the Window, this is done by using the window.folderitem property.

me.folderitem = f

Note: This is one of the key elements, without this the Window Restoration will not work correctly. The folderitem must be attached to the Window using this method.

Modify your file open routine to also use this property.

3. Now we need to alter the App object.
In the “CancelClose” event of the “App” Object, add the code to store the open windows.

Function CancelClose() As Boolean
OWWindowRestoration.storeOpenWindows
End Function

Note: Once this line is executed, no more code will be executed after it, nor will the application’s “Close”, window “CancelClose” and “Close” events will not fire.

4. The next step is to create a subclass of the “OWWindowRestoration” class, name this class something appropriate (for “My Text Editor”, I used the name “MTERestoration” ).

Add the event “windowByClassIdentifier” and in here is where we create a new instance of our window when requested. Earlier on, I returned “documentWindow” from the Window’s classIdentifer method.

Function windowByClassIdentifier(classIdentifier as string) As window
  select case classIdentifier
  case "documentWindow"
    return new documentWindow
  end select
End Function

5. Back to the “Open” event of the “App” and we ask our subclass to restore windows. For example, this app uses the following code.

Sub Open()
  // --- Initiate the Recent Items Menu.
  OWRecentItems.installRecentMenu( fileMenu, 2 )
  // --- Initate Window Restoration.
  Dim nwrc as new MTERestoration
End Sub

In order to test this, make sure that “Close windows when quitting an app” is unchecked, in the “General” section of “System Preferences”.

Now run the application, leave some windows open, quit the application and re-launch it…

6. Cleaning up
In the final step, we need to restore window positions for files that were auto re-loaded (not just data that is stored). This is done by adding the following line to your file open routine.

OWWindowRestoration.restoreWindowBounds( myNewWindow, fileToOpen )

Replace “MyNewWindow” with the new instance of your window and “fileToOpen” with the file that was opened by the routine. Below is how it’s used in “My Text Editor”.

Sub OpenDocument(item As FolderItem)
  Dim theText as string
  try
    Dim tis as textInputStream = textInputStream.open( item )
    if tis <> nil then
      theText = tis.readAll
      tis.close
      Dim ndw as new documentWindow
      ndw.TextArea1.text = theText
      ndw.contentsChanged = false
      ndw.folderitem = item
      OWRecentItems.addToRecentMenu( item )
      OWWindowRestoration.restoreWindowBounds( ndw, item )
      ndw.show
    end if
  catch err as IOException
    MsgBox "Unable to open the file """ + item.name + """." + EndOfLine + endOfLine + err.message
  End try
End Sub

You may have noticed that your Xojo application is also creating new blank windows, which may be undesirable. This is can be solved by adding a property to the “App” class, name it “blockFirstNewWindow” and make it a boolean. Update the “NewDocument” event to use this new property.

Sub NewDocument()
  if blockFirstNewWindow = false then
    Dim ndw as new documentWindow
    ndw.show
  else
    blockFirstNewWindow = false
  end if
End Sub

Switch back to the “Open” event and add a line of code to set that property to the result of the window restoration code.

Sub Open()
  // --- Initiate the Recent Items Menu.
  OWRecentItems.installRecentMenu( fileMenu, 2 )
  // --- Initate Window Restoration.
  Dim nwrc as new MTERestoration
  blockFirstNewWindow = nwrc.restored
End Sub

Now, if you run the project, create some documents, open some, save others, then quit and re-launch, your app should restore the open documents as they were when the application was quit.

Benefits of using this code

Apart from solving some App Sandbox issues, you’ll also get some additional functionality for free.

Using the Apple Recent Item system, recent documents are also available from the dock menu.
The Apple Recent Item system is compatible with both the Sandboxed application and unsandboxed (while everything else is not). Users of either version can swap between the two and still be able to use the Recent Items.
Using the Window Restoration system will make an application follow and behave more consistently with other applications.
The Window Restoration system will also add the file icon to the Window titlebar, and if the user control clicks on the file icon, they can see where on the disk the file is located.

What’s included in the Sandbox Kit

OWRecentItems; Used to implement a Sandbox Safe Recent Items menu
OWWindowRestoration; The Window Restoration handler
OWRestorableWindow; A Class Interface adding the functions for Window Restoration
OW_Sandbox_Kit; A shared module that the Sandbox Kit object require
OWAppleScript; The preferred method of executing Apple Scripts from within a Sandboxed application
OWBookmark; A last resort function for storing references to files, use this only if OWRecentItems & OWWindowRestoration cannot solve the issue
SSBToken; Used by the OWBookmark class to ensure access to a referenced file is closed properly
OWShell; A Shell subclass that can also use NSTask, the only way to launch embedded “Helper” applications within a Sandboxed application

How to get the Sandbox Kit

The Sandbox Kit is sold via the Ohanaware web site for $99.99.

iOS App Icons and Launch Images

Paul Lefebvre — Wed, 17 Dec 2014 00:00:00 +0000

Before you submit to the App Store, you’re going to want to have app icons and launch images for your iOS apps. Here’s some information about them.

An iOS app requires app icons in up to 12 sizes to support the different iOS devices. In order for these icons to be included with your app, you have to copy them into the App Icon folder of your iOS project. More importantly, the icons have to have very specific names so that iOS recogizes them. You can read about the specific sizes and the names in the Launch Images and App Icons page of our documentation.

Update: Starting with Xojo 2016 Release 2, Launch Images are optional.

Launch Images are static images that iOS displays while your app is launching (or loading). These are often static images of the initial screen of your app, but they can also serve as “splash” screens.

There can be up to 9 different sizes of Launch Images that you can include with your app and, like with App Icons, they all need specific names. Launch Images are also important for displaying your app on iPhone 5 (4″) and larger screens. Because of the way iOS works, without an iPhone 5 Launch Image, your app will only display at the iPhone 4 (3.5″) screen size.

All this might seem a bit complicated, but we have a way to make this a bit simpler. In your Xojo installation you will find the ImageMaker tool. You can use this tool to quickly create a folder of App Icons and Launch Images that you can just drag into your iOS project.

On the App Icons tab, choose the image you want for your icon and select the sizes you want to create. Click “Create Icons” to create a folder of icons that you can drag into your project.

On the Launch Images tab, you can create blank (but in the selected color) launch images of the selected sizes to output to a folder you can drag to your project.

For more information about App Icons and Launch Images, you can also refer to Apple’s Human Interface topics on App Icons and Launch Images.