The Standalone Application Settings

The Standalone Applications Setting dialog allows you to create settings for your standalone application. This dialog can be found in the File menu. The settings you enter are applied to the current front most editable stack and are saved with the stack. This means you only need to enter the settings once for each application you create. The same settings will apply if you do another build in the future.

General Settings

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

Stack Files

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.

Copy Files

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.

Basic Settings

  1. Build for iOS - Check to build a standalone for iOS.
  2. Supported devices - iOS uses this to determine if an application should launch on iPod/iPhones and whether it should run in iPod/iPhone emulation mode on iPads (UIDeviceFamily).
  3. Minimum iOS version - The minimum iOS version required by the application (MinimumOSVersion).
    Note: If you are using Xcode 11.4+ you will need to set the minimum iOS version to at least 9.0 or your app will be rejected when uploading to the App Store.
  4. Build 32 bit slice only
  5. Settings Section Tabs - Choose the section you want to edit
  6. Basic Application Settings
    • Display Name - The string to display as the label of the application on the SpringBoard (CFBundleDisplayName).
    • Version - The version of the application (CFBundleVersion).
    • Beta version - Check to mark the version as a beta(test) version. This is used with Testflight.
    • Internal App ID - The bundle identifier to use for the application, in conjunction with the App ID present in a provisioning profile. This uniquely identifies an application (CFBundleId).
    • Profile - The provisioning profile to use when building the application to run on a device.
  7. Status Bar Options
    • iPhone Status Bar - visible or hidden (UIStatusBarHidden).
    • iPad Status Bar - visible or hidden.
    • Status Bar Style (UIStatusBarStyle) - one of
      • Default
      • Black Opaque
      • Black Transparent
      • Solid
  8. Orientation Options
    • iPhone Initial Orientation - The initial iPhone and iPod orientation to start the application up in. One of
      • Portrait
      • Portrait Upside-Down
      • Landscape Left
      • Landscape Right
    • iPad Supported Initial Orientations
  9. Custom URL Scheme - The custom URL that allows the app to be woken up when the URL is selected on a device.
  10. Font mapping - A return-delimited list of the form FontName=PostScriptName.
  11. These options determine what facilities the application requires or prohibits on the device in order to be launched (UIRequiredDeviceCapabilities)


  1. Location Authorization Type - The type of location authorization to be used in the app. Either "Always" or "When in use"
  2. Requirements and Restrictions - Determines which iOS features are required or prohibited.
    • Persistent WiFi - Determines whether the application requires a persistent WiFi connection (UIRequiresPersistentWiFi)
    • File Sharing - Determines whether the Shared Files feature of iTunes is enabled for this application (UIFileSharingEnabled)
    • Local Notifications - Determines whether your application can receive local notifications
    • Push Notifications - Determines whether your application can receive push notifications
    • Disable ATS - Disables App Transport Security(ATS) in your application
    • Background Audio (experimental) - Allows your app to play background audio (this feature is experimental)


The icon files to be used on different devices. The icon files must be the correct resolution for the device

Splash Screens

The image files to be used as splash screens on different devices. The images must be the correct resolution and orientation.


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.

An android manifest merging mechanism has been added to the android standalone builder. This enables manifests to be included in extension jvm-android code folders which are then merged into the main manifest at build time.

Previously, it was possible to override the template manifest by providing a new template in a file called AndroidManifest.xml and including it in the Copy Files list. Since the merging mechanism is more general, enables multiple manifests and does not require users to update template manifests with new template replacement strings, this feature has been removed - instead any AndroidManifest.xml files included in the Copy Files list will be merged into the main manifest at build time.


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

Bug Reports

  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.



This appears to be similar to the User Guide documentation.Wondered if there is there any more detailed help about the options? In particular I'm currently looking at Copy Files pane and would like some clarification on paths, file locations and how the Copy Referenced Files option works. Thank you.

Elanor Buchanan

Hi Jim1001, we don't have any other documentation but I'll do my best to answer you here.

Any files you include here will be included in your standalone, where the files are stored depends on the platform but you can use specialFolderPath("resources") to get the location of any included resources. This will return the correct resources folder for the platform the app is running on.

If you include any folders, or files that are inside folders, the folder will also be created in the resources folder, so the relative path in the app bundle will be the same as the relative path in the Copy Files pane.

The "Copy Referenced Files" options loops across every referenced file on your stack (images, players etc) and includes the referenced file in the standalone. These files will all be added at the top level of the resources folder .

I hope that helps, please let us know if you have any other questions.

Kind regards



Is there a way to alter the standalone application settings by script? Especially version data (which is set in several fields) would be time-saving to be able to set by script, and not manually.

Elanor Buchanan

Hi Andreas

Yes, the standalone settings are stored in a custom property set of the stack that is being built so you can set them in script. For example

on setUpStandalone pVersion
set the customPropertySet of this stack to "cRevStandaloneSettings"
put the customProperties of this stack into tStandaloneSettings

// Set the version number in the Standalone Settings
put pVersion into tStandaloneSettings["ios,bundle version"]
put pVersion into tStandaloneSettings["android,version name"]

set the customProperties of this stack to tStandaloneSettings
end setUpStandalone

I hope that helps.

Kind regards



Can a script read the App version? In other words in the "About" message of my mobile App I would like to show the stand alone version of that particular build, not the LC version. Can I do that? How?

Elanor Buchanan

Hi Simon

Since the cRevStandaloneSettings custom property set is not copied over to the standalone you can't use those values directly, but you could create your own custom property when the standalone is built using the values from Standalone Settings properties. This would then be accessible in the standalone. So if you wanted to use the Short Version value from the Mac Standalone Application Settings you would add a savingStandalone handler

on savingStandalone
local tStandaloneSettings

put the customProperties["cRevStandaloneSettings"] of this stack into tStandaloneSettings
set the customPropertSet of this stack to empty
set the cStandaloneVersion of this stack to tStandaloneSettings["MacOS,shortVersion"]
end savingStandalone

This gets the value set in the Standalone Settings and stores it as a custom property the standalone can access.

on mouseUp
answer the cStandaloneVersion of this stack
end mouseUp

The savingStandalone message is sent when a standalone is built so changing the value in the Standalone Application Settings will cause the custom property to be automatically updated when a new standalone is built without any additional work for you.

You can see all the standalone properties by opening the Stack Inspector, selecting the Custom Properties pane and changing the set to cRevStandaloneSettings.

I hope that helps.


Simon Schvartzman

Many thanks Elanor this is very helpful.


Enable the Override for Standalone setting to assign a custom icon for your standalone game. You can upload different sizes of the icon to fit each of the squares provided.


Hello, I build a simple server client using live code and run it on the same computer, it works. I coded a simple python server receiver. When I run a livecode client and a python server, it works. However when I build my livecode client as a standalone application, running on android, it doesn't work. I couldn't find a solution online.

Elanor Buchanan

Hi Aamuel

It sounds like one or more of the inclusions your app needs are not being included when the standalone is built. I would try selecting "Select inclusions for the standalone application" on the General pane of the Standalone Application Settings and then manually ticking the inclusions your app needs on the "Inclusions" pane.

I hope that helps.

Kind regards


Carlos Deleon

Just going to get started ill put this to the test

Rainer Jauernig

Excellent lesson!! However if you put in 8.0 as minimum iOS version (point 3 in iOS base settings) you will get error ITMS - 90184.
Thanks to DR Whites post 517 I put in 10 instead and it worked.
Thank you anyhow for the wonderful job you did with this lesson.

Elanor Buchanan

Hi Rainer Jauernig

Thank you for your kind and helpful comment. I have added a note to the relevant section of the lesson.

Kind regards


David Simpson

Panos provided me with an excellent description about using the .app/Contents/Resources/_MacOS directory of the macOS bundle and why this is required on macOS. I am including a SQLite db with some demo apps, though for production apps I use a folder outside of the app bundle. I am pasting the info here:

Apple does not allow
other files sitting next to the executable (i.e. in the /Contents/MacOS/

As stated in their Technical Note 2206
Apple does not allow application to have unsigned code in the MacOS folder.

To comply with this new rule, every non-executable file is now copied in the
folder .app/Contents/Resources/_MacOS.

As for the executable files, they are still copied alongside the engine, and
located in specialFolderPath("engine").

This change does not impact any of the engine functions, which automatically
redirect any path targeting the former location of the resource files.

However, the same does not apply to the externals, as they cannot determine if
a path belongs to the app bundle or not; that affects also LiveCode external,
such as revDatabase, this relocation breaks any script calling externals with a
resource file.

In order to help with this overcoming this issue, the option Resources has been
added for specialFolderPath on Desktop platforms, in LiveCode 6.7.2.

That will allow you to get the right path to the resources, being in
development or standalone mode.

So, in other words, you have to replace the function:

function GetPathToFile pFile
local theFile

put the filename of this stack into theFile
set the itemdelimiter to slash
put pFile into the last item of theFile
return theFile
end GetPathToFile


function GetPathToFile pFile
return specialfolderpath("resources") & slash & pFile
end GetPathToFile


It would be helpful for the iOS settings (icons tab) to list what sizes the various icons need to be. The guide notes that they must be the proper size, but at the moment you only see the proper size in the error message when you upload the wrong size icon.

Here's the list of the icon sizes in pixels as of LC 9.6.9-rc2.

AppStore: 1024x1024
iPhone: 57x57
Hi-Res iPhone: 114x114
iOS 7 Hi-Res iPhone: 120x120
iPhone 6 Plus: 180x180
iPhone X: 180x180
iPad: 72x72
Hi-Res iPad: 144x144
iOS 7 iPad: 76x76
iOS 7 Hi-Res iPad: 152x152
iPad Pro 12.9: 167x167
iPad Pro 11: 167x167

Panos Merakos

Hello Jeff,

Thanks for the list. Note that you can see the expected size for each entry if you hover the mouse over the "..." icon - then you should see tooltip with the required icon size.

Hope this helps.

Kind regards,


Is there any way to keep the Standalone Application Settings for iOS when I move the stack from a Mac to develop on another Operating System? If I copy a stack from Windows to Mac, all the my Windows, Linux, Android, etc. Standalone Application settings stay the same. But if I copy a stack from Mac to Windows, then all my iOS settings disappear.

So when I do development on Windows or Linux and then take that stack to a Mac to create an iOS application, I have to enter in all the iOS information (all the icons and splash screens) again.

I'd love to know if there is some trick where the iOS settings will "stick" when the stack is opened in Windows or Linux. Or is there some easy way to keep the iOS settings elsewhere and "apply" them when it's time to build for iOS.

Thank you.

Panos Merakos

Hello Jeff,

You can build an iOS app - and configure the iOS settings **only** on a Mac. This is a restriction imposed by Apple - not LiveCode. So, when you open this stack on a Windows or a Linux machine, the iOS settings are disabled. This is expected.

Hope this helps.

Kind regards,


Thank you for the explaination. I totally understand that iOS Standalone Settings need to be disabled on non-Apple platforms per Apple's requirements. But is it possible to retain the iOS settings between OS versions, even if they are not accessible? Right now it appears that Livecode deletes all the iOS settings, not merely disables them.

I have no need to edit the iOS settings on Windows or Linux. But it would be very helpful if the iOS settings I entered on Mac were still present in the stack when I move it to Windows or Linux - not accessible, but present. Then if I make changes and move it back to my Mac, I don't need to re-enter all the iOS settings again.

I do my development on a Windows laptop. But every time I move a stack to Mac to build for iOS, I have to re-enter everything. I've tried using SmartCrumbs to export and import that stack between operating systems, but the iOS settings still seem to be deleted when coming into Windows.

It's a small problem and one that I certainly can live with. Re-entering a few icon locations, etc. is a small price to pay for the incredible ease of cross-platform Mobile development on Livecode! :-)


@Jeff - Try this:

Do all the iOS settings on Mac, then save the standalone settings to a custom property this way:

set the customPropertySet of this stack to "cRevStandaloneSettings"
put the customProperties of this stack into tStandaloneSettings
set the customPropertySet of this stack to empty
set the cMySavedStandaloneSettings of this stack to tStandaloneSettings

Whenever they have disappeared after moving the stack between operating systems, restore them this way:

put the cMySavedStandaloneSettings of this stack into tStandaloneSettings
set the customPropertySet of this stack to "cRevStandaloneSettings"
set the customProperties of this stack to tStandaloneSettings
set the customPropertySet of this stack to empty


THANK YOU! That worked beautifully. I've now got my iOS, Android, etc. standalone settings stored in custom properties, and I run a little handler to restore those settings when I want to build for that OS.

This is very helpful for me. Thank you for taking the time to write this out and show me how to to it. I was involved with tech support for many, many years, and I know that it can get very tiring. I really appreciate how responsive you all to every question.

Panos Merakos

Hello Jeff,

We are glad this works for you. Also, a big thanks to Andreas - who does not work for LiveCode support - but he is indeed a very knowledgable and helpful LiveCode user.

Kind regards,

Add your comment

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.