The General Settings pane allows you to set the top level properties for your standalone.

1. Standalone name - Set the name of your standalone application. This should be the name you want your finished application to have. Don’t include a file extension (.exe on Windows or .app on Mac OS X) as the standalone builder can create standalones for multiple platforms and will add the appropriate extension automatically.
2. Inclusions selector - Choose the components you want to include in a standalone. You may either choose to search for required inclusions automatically, or manually select the components you want to include.
   • Search for inclusions - This is the default option. When selected, LiveCode will search your application stack file (main stack and sub stacks) to attempt to determine what components your application uses. It will then include those items.
   • Select inclusions - Select this option if you want to specify the components to include manually. You may wish to use this option if your application dynamically loads components that cannot be searched at this point automatically, or if you know exactly what components your application uses and wish to speed up the standalone building process by skipping the automatic search step. It is important that you choose to include all the components that your application uses or it may fail.
3. Property Profiles selector - Choose between the Property Profile settings options. You only need to alter settings in this area if you have used Property Profiles
   • Remove all profiles on objects - Removes all profiles and builds the standalone using the currently active profile on each object. Select this option if you don't need to change profile in the standalone and want to save disk space by removing extraneous profile information.
   • Set all objects to profile - Set all objects to a specific profile then remove the profile data from objects.
   • Include profiles on objects and the profile library - Include the profile library and allow switching between profiles in the standalone application. You can choose whether to include specific profiles or all profiles.
   • Include all profiles or include only selected profiles
4. Default build folder - Set the folder the standalone will be built in. You can choose to automatically build to this folder every time the standalone is built (5).

Use this section to add additional stack files to your application. Any stacks you add to this section will be added to the stackFiles property of the main stack of your standalone. This means that any scripts within your standalone application will be able to locate and reference these stacks by name.

1. List of stack files included in the standalone
2. Buttons to add and remove stack files
3. Advanced Options - Use this section to control exactly how multiple stack files are managed in your standalone.
   • Move substacks into individual stackfiles - If you select this option, each of the sub stacks in the stack files you select will be moved into their own individual file, located in the data folder or within the application bundle of your standalone.
   • Rename stackfiles generically - Renames each sub stack file using a number on disk (instead of using the name of the sub stack). Select this option if you do not want the names you have selected for stacks to be visible to the end user in the filing system.
   • Create folder for stackfiles - Creates a folder and places the stack files into that folder, instead of storing them at the same level as the standalone executable. All references in the stackFiles property will refer to this folder using a relative path so the stacks can still be located by the standalone application.
4. Individual stack options - Select a stack file on the left then an individual stack from within the file to set options on that stack.
   • Set destroyStack to true - Set this option if you want the selected stack file to be removed from memory when it is closed. This option is useful if you are loading large stacks into memory and want them to be removed when they are closed.
   • Encrypt with password - Secures the scripts within the selected stack file with a password. This provides a basic level of encryption that prevents someone from casually reading the scripts in the stack by opening the file in a binary file viewer.

Note: If iOS or Android are selected in the Standalone Builder settings, the Stacks pane is grayed out. To work around this and password protect a stack, or add stack files, uncheck iOS and Android, check any desktop platform, and make your changes. Then uncheck desktop and recheck iOS or Android to build your standalone.

Use this section to add other files to be included in the standalone, this could be images, sound files, fonts etc.

1. List of files - List other files to be included in the standalone. Use this feature to include help documents, read me files and other resources that you want to include with your standalone each time you build.
2. Buttons to add files, add folders and remove entries from the list. Adding a folder adds the selected folder and all its contents.
3. Copy Referenced Files - Loops over all image and player objects in stacks and copies any files referenced in the fileName property of these objects into the standalone then automatically sets the fileName property of these objects to reference these files in the standalone using referenced file paths.
4. Destination Folder - Create a subfolder within your standalone to copy the image and move files to.

The list of resources available to select for inclusion in a standalone application are a combination of currently installed LiveCode Builder extensions, externals and database drivers (both built-in and those found in user folders), and built-in resources and script libraries.

If you selected "Select inclusions" in the General section you use this section to select the widgets, libraries and externals to include in your standalone.

This section allows you to set the Mac specific settings for your standalone.

1. Choose which version of Mac OS X to build for
   • Build for Mac OS X 32-bit - Build a standalone that will run natively on Mac OS X Intel machines. This standalone will not run at all under PowerPC.
   • Build for Mac OS X 64-bit (EXPERIMENTAL) - Build a standalone that will run natively on Mac OS X Intel machines. This standalone will not run at all under PowerPC.
2. Application Icon - Choose an application icon to represent the application in the Finder. The icon should be in icns format.
3. Document Icon - Choose a document icon to represent your application's documents in the Finder. The icon should be in icns format.
4. Icons for ask and answer dialogs - Choose an icon to display whenever you use the ask or answer commands to display a dialog. On Mac OS X, the convention is that these dialogs should display your application icon. The icon should be stored in your stack as an image, or selected from LiveCode's built-in icons. If you have used a built-in icon, be sure to select the relevant inclusion on the General tab (if you are selecting inclusions manually).
5. PLIST - The PLIST is a settings file stored in XML format as part of every Mac OS X application. It contains information about the application, including its name, version number, copyright notice and document associations.
   • Enter information and have LiveCode write the PLIST - Have LiveCode fill out the PLIST for your application automatically.  Having LiveCode create this file for you is the recommended option. For more information about PLISTs consult Apple's developer documentation.
   • Choose a file to import into the application bundle - Choose to import a PLIST file instead of having LiveCode create one. Select this option if you have created your own highly customized PLIST that you want to use for your application in each build you create.
6. Short/Long version - The version information to be included with your standalone.
7. Get info string - The visible text displayed in your application's Get Info window by the Finder.
8. Copyright notice - The copyright notice for your application.
9. Bundle identifier - A unique identifier for your application used by Mac OS X to identify your application.

This section allows you to set the Windows specific settings for your standalone.

1. Build for Windows - Check to build a standalone for Windows.
2. Application Icon - Choose an application icon to represent the application in Windows. The icon should be in .ico format.
3. Document Icon - Choose a document icon to represent your application's documents in Windows. The icon should be in .ico format.
4. Version Information - The version information to be stored as part of your application and displayed in the Windows property inspector and dialogs.
5. UAC Execution Level - Select the user account control level that applies to your application. For more information, consult MSDN
6. Hi-DPI support - Check to enable Hi-DPI scaling, stacks will be automatically scaled to match the system display.

This section allows you to set the Linux specific settings for your standalone.

1. Build for Linux/Linux x64 - Check to build a standalone for 32-bit and/or 64-bit Linux
2. Include - Select built-in LiveCode dialogs to include. These dialogs are useful if your application may be run on a system that does not include these dialogs as part of the OS. You do not need to include these dialogs if you are running a recent version of GTK.

This section allows you to set the iOS specific settings for your standalone.

This section allows you to set the Android specific settings for your standalone.

1. Build for Android - Check the architectures the standalone is to be built for.
2. Label - The string to display as the label of the application on the Launcher screen.
3. Identifier - The unique identifier to use for the application, using the standard reverse domain name convention.
4. Version Name - A human readable version string for the application.
5. Version Code - An integer indicating the version of the application – this is used by the OS to compare versions of packages as opposed to the human readable string.
6. Icon - The PNG image file to use as the icon on the Launcher.
7. Splash - This is a legacy setting only, for very old versions of LiveCode. It will have no effect in recent versions and should not be used. Android does not require a splash screen in the same way that iOS does.
8. Signing - Whether APKs are to be signed with the development key, a custom key or no key (this is only used when using ‘Save as Standalone application’).
9. Key - The key-store file to use to sign the application when “Sign with my key” is selected at step 7 (this is only used when using ‘Save as Standalone application’).
10. Install Location - The preference for application storage on the device – This can be internal storage only (device memory), allow external storage (user can select to install to device memory or SD card), prefer external storage (install to SD card)
11. Custom URL Scheme - The custom URL that allows the app to be woken up when the URL is selected on a device.
12. Push Sender ID - The Project ID of the Google APIs Console project
13. Status Bar Icon - The icon to be used in the status bar. This must be a png image.
14. Hardware Accelerated - Hardware acceleration is necessary to play videos in the Native Browser. However, it causes a general screen update slowdown.
15. Initial Orientation - The initial orientation to start the application up in.
16. Status Bar - The initial visibility of the status bar.
17. In App Purchasing - Check to enable In App Purchasing.
18. Store - Select the store to use, either Google or Samsung.
19. Minimum Android Version - The minimum Android version required by the application.
20. Android features - The features that should be added to the manifest. A required feature will only be visible to users who have devices that support the feature. A used feature will indicate to the user that this application uses the feature. A used feature will still be visible to devices which do not support the feature.
21. Application Permissions - The permissions to be added to the manifest.
    • Write external storage is required if your app will read or write files on external storage (e.g. an SD card)
    • Internet is required if your app is accessing the internet.
    • Camera is required if your app is using any camera features.
    • Read contacts is required to read from the phone contacts.
    • Write contacts is required to write to the phone contacts.
    • Fine Location is required if you wish to use GPS to triangulate device location (requires coarse location)
    • Coarse location is required if you wish to use mobile networks to triangulate device location
    • Vibration is required to use the vibrate action of the phone.
    • Idle timer is required to allow the device to dim the screen and eventually lock the device after periods of no user interaction.
    • Ad Support is required if your app uses ads.

1. Build for HTML5 - Check to build an HTML5 standalone.

1. Include Error Reporting Dialog - Include an error reporting stack in your standalone. You should select this option if you are testing your application and want details of any errors in your standalone, or if you have not included your own error reporting routines in your stacks.
2. HTMLText for dialog - The text to display to the user in the dialog that comes up when an error is encountered. This text should be in LiveCode-compatible HTML format. Create and format the text in a LiveCode field then copy the field's HTMLText property.
3. Dialog icon - The icon to display in the error dialog. This should be stored as an image in your stack.
4. Allow user to enter comments - Display a box for the user to give you more information. This information will be included in the report.
5. Allow user to save report to file - Allow the user to save the report to a file. Select this option if you want users to save an error report and send it to you.
6. Allow user to email report - Allow the user to email the report. Select this option if you want the user to be able to send you or your technical support department details of the error. This option loads up the system default email client and populates the email with the contents of the error report and the user's comments. The To: field is sent to the email address specified in the email address field.