Chapter 9: Bundling Resources and Preparing for Release

Go applications are known for building simple application binary files that make them easy to install. However, the additional data required for graphical applications can make this challenging and has resulted in complex package formats and the introduction of installers as well. Fyne provides an alternative solution that allows apps to once again be distributed as a single file on most platforms.

Completing the packaging of an application requires metadata and an additional build step to prepare the files for distribution. This step allows applications to be installed to the local system or development devices alongside system-native apps, which we will study in this chapter.

We will walk through adding the various files an app will need at runtime. We will cover the following topics:

• How to include additional files in your application
• Checking for common User Experience (UX) mistakes to improve your GUI
...

Technical requirements

This chapter has the same requirements as Chapter 3, Windows, Canvas, and Drawing: to have the Fyne toolkit installed and Go and C compilers working. For more information, please refer to that chapter.

For deployment to Android devices, you will need to install the Android SDK and NDK (refer to Appendix B, Installation of Mobile Build Tools). To build for iOS devices, you will also need to install Xcode on your Macintosh computer (a Mac is required for licensing reasons).

The full source code for this chapter can be found at https://github.com/PacktPublishing/Building-Cross-Platform-GUI-Applications-with-Fyne/tree/master/Chapter09.

Bundling assets

Go applications are designed to run from a single binary file. This means they can easily be distributed and do not rely on installation scripts. Unfortunately, this benefit results in a cost for developers—we cannot rely on resources being found along with our applications in the way that web or mobile app developers can (and as we have been doing during development). To ensure that our applications conform to this design, we must embed any required assets into the application binary. This includes fonts, images, and any other static content that is needed for the application to operate correctly.

The Fyne toolkit provides a tool for the bundling of assets that is recommended for any apps built using Fyne. The benefit of using this tool is that it generates fyne.Resource definitions for each embedded resource, which makes it easy to pass embedded assets into various Fyne APIs. This bundle tool is actually a command within the project's fyne command...

Checking for UI hints

As Fyne is built using Material Design principles, it is possible to make use of their recommendations for good and bad ways to use certain components and how you should and shouldn't combine elements for a great UX.

Built into the Fyne toolkit is the concept of hints. These are suggestions that widgets and other components can make about how an app could make changes to offer an improved user interface.

We will start exploring what these hints can offer by creating a simple example tab container application. This code snippet will load two tabs into a tab container (the makeTabs() function). We then include a main() function that will load a new app, create a window, and set the tabs to be its content. The function then runs our app in the usual way as follows:

package main
import (
    "fyne.io/fyne/v2/app"
    "fyne.io/fyne/v2/container"
    "fyne.io/fyne/v2/theme...

Choosing metadata, icons, and app IDs

Before we start on the technical aspects of creating an application release, there are a few prerequisites to consider. The application name is probably set by now, but do you have a great description for it? Do you know how to articulate the key features of your software in a way that will grab the attention of potential users? Have you (or your design team) created a great app icon that will be memorable and somehow indicative of its functionality?

If you won't distribute your app through a managed channel, such as an app store or platform package manager, you should consider how the application will be discovered by your target audience. There is a lot of discussion and information online about Search Engine Optimization (SEO) and a growing amount about App Store Optimization (ASO) to be found, so we will not go into detail here. What is clear in the current software climate is that the ease of discovery and memorability of your app...

Packaging applications (desktop and mobile)

To incorporate the metadata prepared in the preceding sections, we need to execute the packaging phase. This will take the standard Go application binary and attach or embed the required data based on the operating specifics. As each platform requires different data formats and produces different resulting file structures, we use the fyne tool once again to take care of the details.

Packaging for your current computer

To create a package from a Fyne project, we use the fyne package command. By default, this will create an application bundle or executable for the current operating system. When run on macOS this will create a .app bundle; on Windows it will be a .exe file (with additional metadata); on Linux it creates a .tar.gz file that can be used to install the app.

It is possible to build this for a different system as well, using the -os parameter, which we will explore later in this chapter.

Before packaging, it is a good...

Installing your application

If you just want to install the desktop app on your computer or development devices then you can make use of the helpful install subcommand. There are two modes for the install tool, firstly to install on the current computer, and secondly to install on a mobile device that is set up for development.

Installing on your current computer

To install your application onto your current computer and make it available system-wide, you could simply execute the following:

$ fyne install -icon myapp.png

The icon file is the minimum required metadata for installing an app to the desktop. If you would like to avoid passing the -icon parameter each time, you can simply rename the file to Icon.png and it will be used by default. Once the application is installed, you will see it in your computer's program list with appropriate icons showing.

Installing on a mobile device

At this stage, we can install apps to a mobile device if it is set up for development...

Cross-compiling with ease

The ability to compile for different operating systems or architectures than the current computer is called cross-compiling. We saw it used in the previous section to package and install a mobile app from a desktop computer. By cross-compiling, we can also build applications from one computer for other types of desktop as well, for example using Windows to build a macOS application.

There are two ways that this can be done. Firstly, we will see how developers familiar with platform-specific compilation can use their normal tools to build for multiple platforms. After that, we will look at the fyne-cross tool and how it hides all of the complexity using a Docker image to manage compiling.

Using installed toolchains

When taking the traditional approach to cross-compiling, the computer will require an additional compiler toolchain for each platform and architecture that the developer wants to support. This is what provides the ability to compile the...

Summary

In this chapter, we have seen the steps involved to take an application from running from the source code, through to packaged files ready for distribution. We saw the techniques and tools available to help make applications portable and how the Fyne toolkit can offer hints of how to improve your UX.

We also explored the world of cross-compiling and how to create application packages for different operating systems. As illustrated in this chapter, it is possible to set up your development computer to build for all supported platforms; however, we saw that this can be complicated. The fyne-cross tool was introduced as a way to solve this complexity and make it trivial to package builds for the multitude of potential target systems.

In the next chapter, we will look at how to distribute these files. We will explore how you can share packaged files with beta testers and then how to prepare the packages with the certification required for app store and marketplace uploads...