Don't keep it all to yourself!
Tools such as LiveCode can be used entirely for personal productivity applications, and it would more than pay for itself through the time that it would save every day. However, why not let the rest of the world benefit from your creations!
So far, we have created several little test rig apps and a few apps that are fleshed out. In all cases though, we've just tested the apps that are inside simulators or on your personal device. The time has come to get this app out to more people for beta testing at first, so that we can then upload it to different app stores.
In this chapter, we will:
- Examine all the standalone application setting options related to the process of creating mobile apps
- Create builds of an app so that it can be sent to beta testers
- Test service alternatives
- Build the final distribution version of an app
- Review how to upload apps to iOS App Store, Google Play, Amazon Appstore, and Samsung Apps
Note
There are some stages that should be performed on Mac while creating iOS apps for App Store; all the iOS steps described here should be followed using Mac. The Android steps can be applied to Mac or Windows. Note that this chapter is more of a reference and not a hands-on walkthrough. When you have an app that is almost complete and ready for submission to app stores and if you get stuck at any point, hopefully, you will recall reading about the issue somewhere in this chapter!
We have already tweaked the settings a few times by now, but we've only made the minimum amount of changes needed to test the app. There are a lot of options here that you need to fill before your app is ready for sale in an app store. We'll briefly go over the other standalone application sections and then go into more depth in the Android and iOS sections.
The General section of the standalone settings is primarily used to control the features of LiveCode that are to be included in a desktop standalone application. These options cannot be applied to mobile applications, but it is in the General section that you can set the name of the application file and the build folder:
The Stacks section will show you a list of the stacks that are already included in your project. This will of course include the current Mainstack and the stacks that have been added by plugins that you may have used earlier. As you can see, all the options are grayed out.
The Copy Files section is used to add additional files and folders to be used by your app. These are read-only files; if you need changeable files, you could still include these files and then write copies of the files to the special Documents folder. Here is how the dialog box looks with folders of images and sounds. These folders are in the same folder as the LC app:
The Mac, Windows, Linux, Web, and Bug Reports sections are not used while making iOS and Android apps, so now, we'll take a good look at the iOS section bit by bit…
The Build for settings determine which iOS devices the app will work on and which minimum iOS version should be used. In deciding what to choose, some things are obvious and others, not so obvious. If you are making an app that really needs a large area of workspace, then it might not be too successful on an iPod or iPhone screen. If it's a small utility that is geared for use on a hand-held device, perhaps you don't need to have an iPad version. You are able to choose iPod, iPhone, and iPad, or just iPod and iPhone, and even just iPad from this section.
The minimum iOS version you choose may depend on the particular features that you have used previously. You don't want users to buy your app only to find that a certain feature doesn't work correctly under the older iOS version. You may need to set and keep some devices for testing to use old versions of the OS on, so that you can be sure that your setting is correct. Also, Xcode allows you to download various versions of Simulator, and in LiveCode, you can choose a specific version to test
You can always leave these options at lower values for now and make up your mind after you have heard how your beta testers get on with the app.
Here is the Build for area of the settings along with the menus you can choose from:
We have used some of these settings a few times already. Here is the full set of options:
- Display Name: This is the name that will appear under the icon on the actual device
- Version: This is the version number that will appear in the iTunes description of the app
- Internal App ID: This is the app ID that you can use in the iOS Developer portal while developing or distributing the provisioning profile
- Profile: This is the provisioning profile that matches this app
- Externals: This is a set of optional external command files that you may have used in your app
You should try out different display names to see how it looks on different devices. There is a limit to how long the name can be before iOS truncates the name, placing ellipses in the middle of the text. For iPhone, the limit is roughly up to 11 or 12 characters.
It's important to make sure that an update to an app that you submit has a version number that is later than the version number of the existing app. Starting with 1.0.0 makes sense; just remember to increase the number when you do updates. Don't worry if you forget, you'll find that the upload process to the App Store fails! App stores in general require that the update be of a later version than the one that is being replaced.
For development purposes, you can use a provisioning profile that uses an internal app ID that contains a wildcard. When you do submit an app to iOS App Store, make sure that the provisioning profile is a Distribution one and that the App ID it uses exactly matches the Internal App ID. Also, make sure that the ID is different than any other app that you have in the store. Note that the ID, as shown in your developer account page, will show extra digits at its start, for example, 31415926.com.yourname.yourappname. The matching Internal App ID would be com.yourname.yourappname.
In this example screenshot, a development provisioning file was chosen and no external commands were used:
You are able to select a different icon for each device type that iOS and iTunes requires. The Icons section is straightforward; you click on the … button and choose the file from your filesystem. It would be possible for LiveCode to take one large image and create the various sizes for you, but there isn't an option for that! For what it's worth, you may have reasons to show a different icon for each case. For example, you could make an icon for Retina displays that had more detail in them than a non-Retina display. As you don't have a choice, just enjoy the flexibility this gives you!
Note the Prerendered Icon checkbox in the following screenshot. Here, you have a choice of creating an icon exactly as it should appear on devices. Also, you could produce a square icon with no shading and leave the system to make it look like a button with a highlight effect. Take a look at the various apps on your own devices; you will find that some people were happy to use Apple's beveled highlighted appearance and others preferred to do their own thing. The Prerendered Icon feature allows you to do your own thing. In this screenshot, you can see that icons for all the types of devices that have been selected, even iPad Retina, and they are prerendered:
In this case, the icons/ folder is in the same folder as the app, so you don't need to include the full path. An entry of icons/ is also included in the Copy File section.
A good reference for Apple icon and image sizes for iOS 7+ is available at:
This chart does not include the old sizes 57 and 72 for the older iPhones and iPads.
There are
plenty of tools that will help you create all the icon sizes available in the Mac App Store. When I last checked, there were about 40 icons resulting from a search for icon ios. One free tool that I have used is Icon Set Creator, which is available at
https://itunes.apple.com/us/app/icon-set-creator/id939343785?mt=12
Since the very first iPhone, iOS has had the ability to load and show a splash screen immediately when a user touches an app icon. This gives them something to look at while the app loads. All that was needed in those days was a default image and a name Default.png. When iPad came along, there became a need for more splash screens. At the very least, you needed a higher resolution default image, but you also needed custom images for landscape, as far as having different landscape images depending on whether the home button is to the left or right.
LiveCode doesn't give us access to that level of flexibility, but it is extremely rare that an app would need a different landscape for two variations; you can generally get by with just a single one. The same for the upside-down portrait variation, the regular default portrait image can be used for that too.
The Retina displays have their own entries for setting the splash screen, and by convention, these files would have names that include @2x.
Which of the splash screen options that are enabled is dependent on the orientation options described in the following section. In this screenshot, the Lscape options are grayed out because the app is set as Portrait. Here, the correct size Lscape image files were selected as well, for your reference:
You may notice that there isn't an iPhone portrait or landscape option here. That's because the Default.png is used for both. If your app is landscape only, then design the splash screen as landscape, but rotate the image 90 degrees clockwise to create a 320 x 480 or 640 x 960 Default.png or [email protected] image. One important entry in the list is the 4 inch iPhone entry that is used for iPhone 5. The Default.png file name is not used here since image file names can be anything as long as no spaces are included.
As discussed previously, you are able to specify the orientations supported by your app. If the app is used just for iPod and iPhone, then you can set only the initial orientation. The choices are Portrait, Portrait Upside-Down, Landscape Left, and Landscape Right. If the app is used on iPad, then you can also set the orientations that support the app while it is in use. The selections you make will affect which icons can be imported. The orientations are all set with just one drop-down menu and four checkboxes:
Sometimes while using an iOS device, you will touch a URL in a web page and suddenly, you will find yourself in Mail or looking at a page in the App Store. This is achieved using a custom URL scheme. In the case of the App Store, links begin with itms-apps:// and from that iOS knows that the link should be opened in the App Store app. You can do the same thing with your app. By setting a similar custom string, you can get iOS to open your app when the user touches a link that starts with the same string in the URL. Further information can be found in the lesson given at http://lessons.runrev.com/m/4069/l/58672-using-custom-url-schemes.
The value of the string is entered with a simple text input field, shown as follows:
Earlier, we talked about how setting the device, processor instruction set, and iOS version is one way to make sure that your users are able to use the features in your app. The Requirements and Restrictions options let you specify in great detail the abilities your device should have. At the very least, if you have an app that involves taking photographs, then having a camera in the device is necessary! If it's a video chat app, then having a front camera in your device would make sense. The reminders app that we made in the previous chapter should have its Location Services option selected to make sure that the sort by distance feature works. The following is the full list of requirements and restrictions:
As you'll see, the number of options to be set for Android are less than that for iOS. This isn't so much because Android is simpler, but because LiveCode exposes virtually all of the possible settings for iOS, including a lot that you will most likely not need. iOS also has the splash screen variations that are not available in Android.
In the Android world, there are some settings that you are required to set, in particular, the Permissions settings. iOS does ask the user for permission to use some features, but not until the time your app invokes that feature. You must have seen dialog boxes that ask: Fancy App wants to know your location. Android on the other hand asks for permission to use these features at the time the app is installed.
Let's look at the options for Android…
Several of the iOS options are given a different name in the Android OS. Instead of Display Name, Label is used, Internal App ID is called Identifier, and there isn't a provisioning file, but there is a Signing Key used in Android. Essentially though, they are the same options as in iOS.
The Icon is set as part of the basic settings because only one icon is needed, so we don't need a set of options. For this one icon, you would have to select a 512 x 512 sized version of the image and LiveCode will make the other sizes for you.
Android apps don't have a splash screen like iOS, but LiveCode can be given a splash screen that it will show as the first screen that the user sees after the app loads.
You are able to set the location where the app will be installed with choices of Internal Storage Only, Allow External Storage, and Prefer External Storage. The external storage being referred to is the SD memory that most Android devices have. Android users either don't care where the app is installed or they are fanatical about it being stored in the SD memory! You could select Allow External Storage and expect a lot of people to do the same or you could choose Prefer External Storage knowing that only a minority would change the option to force the installation to be in the internal memory. Overall, you upset less people by using the prefer external storage setting.
In-app purchasing and push notifications are handled in a different way in Android than they are in iOS. If you wish to use in-app purchasing, take a look at the RunRev online lessons and also the developer.android.com information. Lessons for Apple, Google, Amazon and Samsung are located at http://lessons.runrev.com/m/4069.
The Android developer information on in-app billing can be found at:
http://developer.android.com/guide/market/billing/billing_overview.html
As with iOS, an Android OS can be given external commands and it also has the custom URL scheme. One feature that is not found in iOS is the ability to set an icon to be used in the task bar.
Here is how the basic Application Settings options are presented:
Within this set of options, you can set the Minimum Android OS version and set the hardware features that are required. The columns of radio buttons are named differently in iOS. Instead of stating that a feature is required or prohibited, the buttons state whether the feature is required or used. This becomes information that the Android user is able to read and may play a part in whether they choose to buy your app or not. So, try to select any that can be applied to your app.
When an iOS app makes use of certain features, such as your location, there is an alert dialog box that appears when the feature is first used. With Android, any such features are listed during the installation of the app and the user gives permission for all the features in one go.
Here is the list of permissions you can choose from:
User Interface Options perform the same function as the orientation and status bar options in iOS. If you are submitting an iPad app that is landscape, you have to support both variations of landscape. The Android app stores don't have the same requirement, so the options are much simpler. You only have to choose whether the initial orientation should be Portrait or Landscape and whether the status bar should be Visible or Hidden:
