VertiGIS Studio Mobile Performance Guidelines

Overview: 

One of the most frequent questions we get about VertiGIS Studio Mobile (Go and Custom Apps) is "How do I make sure my users have a good experience with the app?" This is a great question, but not a simple one to answer. Studio Mobile is a platform that allows you to create customized GIS (Geographical Information System) apps, catering to small, simple uses cases like basic field data collection for local businesses and governments all the way up to complex utilities maintenance projects spanning countries. Given the wide range of applications, it makes sense that there would also be a wide range of things to consider when designing your mobile solution. The VertiGIS Studio Mobile team is always working to make improvements to our app, but there are many ways that you can improve the experience yourself! Let us look at a few of them below: 

1. Data Size 
2. Data Best Practices 
3. Web Map vs. MMPK 
4. Provisioning your Portal/Server 
5. Connection Strength 
6. Devices 

Data size:

GIS data come in a wide variety of shapes and sizes. Your organization has its own unique needs so of course your GIS data will be unique as well. Managing data for a city or single sector will be different than doing the same at a country level. Regardless of what industry you are in, however, the bigger your data the more difficult it can be to work with. The complexity of your projects will also factor into this. When attempting to optimize performance, you need to consider things such as: 

• Number of layers and how they're structured (e.g., group layers)
• Number of features 
• Complexity of geometry 
• Number of feature attributes 
• Complexity of coded value domains (e.g., dozens of options vs hundreds or even thousands) 
• Number of attachments
• Whether your users need to work offline or not 

All these things can impact how performant your app is. The bigger and more complicated all these factors are, the slower your app will be. It is therefore a good question to ask yourself "What is the least amount of data my workers need to accomplish their jobs?" 

Data best practices:

Esri has many documents and courses describing how to best manage your data to improve performance. A few highlights would include: 

• Restricting visible scale ranges appropriately (e.g., only show features when they become meaningful) 
• Turn off layers which are not frequently used. Layer presets are a great tool for managing this 
• Keep your data clean and up to date - remove old, stale, unnecessary data 
• Like scale ranges, only display labels when they provide value. Densely clustered labels make your map hard to understand and impact performance 
• Simplify symbology. ArcPro and Esri's Map Viewer offer many, many different options for symbols. Simpler symbols tend to perform better than complex graphics 

Web map vs. MMPK vs TPK/TPKX/VTPK:

Studio Mobile can include data in your app that come from a web map as well as optionally from an MMPK. Data stored in a web map can be considered ‘operational,’ in that users with appropriate permissions can add, edit, and delete it. Data stored in an MMPK can be considered ‘reference,’ in that it is read-only. If your workers only need to work with a small number of operational layers, dividing your data between your web map and an MMPK can be an invaluable strategy. 

A big advantage to MMPKs over online web maps is that they allow you to store the data locally, on the device, so it can load quickly. Further, because the MMPK data is already on your device, it does not need to be downloaded again for use with map areas. This will decrease map area size and corresponding download times as Studio Mobile drapes your select web map data over your MMPK data. Data coming from your web map needs to be streamed through to your device, both in real time for an online experience and when downloading a map area for offline usage. By reducing the data stored in the web map, you reduce those demands. 

Another option for storing non-operational data is through the use of TPK/TPKX/VTPK files. These files can offer visual reference to your data, on top of your chosen basemaps. The specific feature attributes are not available, so limit features here to those that you only want to display on the map for reference.

Another important question is about how to get the MMPK/TPK onto your users' devices. Downloading the MMPK/TPK on app startup if it is hosted in your Portal is one option. Portal-hosted MMPKs may also be updated, which Studio Mobile will check for on the next app launch, ensuring your users always have the latest data. Manually copying the MMPK/TPK or distributing it through your Mobile Device Management (MDM) system is another. The more compact your MMPK/TPK, the easier this will be to deploy to your users. 

Provisioning your Portal/Server:

When your users need to access your data, be it a web map or an MMPK, they need to interact with your hosting Portal/Server or AGOL. If your Portal is not performant, your app in Studio Mobile will similarly suffer. Some useful things to consider are: 

• How many users are going to be accessing your Portal? Do you have 10 users, or 10,000?
• Are they accessing it all at once or more evenly spread out? Do you have load balancing in place for periods of peak usage? 
• Are they connecting to it through a VPN? Is the VPN properly set up to ensure a stable connection? 
• Is your Portal's hosting environment sufficiently resourced? Does it operate on a powerful server with enough RAM and hard drive space to meet your needs? 
• Do you perform regular maintenance on your Portal? Portal environments steadily build up temporary files which can waste precious resources. Do you regularly clean out these files and reboot your environment to ensure a consistent experience?
• What security settings do you have in place? Additional layers of security can slow performance. Have you considered these?

A helpful trick to determine if your Portal is responsive enough is to remove Studio Mobile from the equation and log into your Portal via your device's web browser. If that is a poor/slow experience, Studio Mobile will similarly suffer. The recently released VertiGIS Studio Analytics product can also be used to offer powerful insights into your users’ experiences.

Connection strength:

Like the topic of storing your data in a web map or an MMPK, you need to be aware of how your device is connecting to that data source. If you are planning to use Studio Mobile online, you need to have a stable, strong connection to ensure a quality experience. If you are planning to use Studio Mobile offline, then the connection will not be important while offline, but it will be during the map area downloading process.

Is this being done in the office? Over cell data? Your internet connection is the bridge to your data. The bigger the data, the bigger the bridge you need. 

Devices:

As of the release of Studio Mobile 5.22, support is provided for Android OS (versions 8-13), iOS/iPadOS (versions 14-16), and Windows 10/11. However, not all devices running these different operating systems are created equal. A top of the line, flagship device with powerful RAM and lots of hard drive space will give you a much better experience than an old, underpowered, ill-maintained device. We have made some recommendations in our documentation about minimum recommended hardware specs but do keep in mind that these are referring to the minimum specs for an adequate experience. The better the hardware, the better the experience. Especially as you begin to build more complex apps with larger data sets, it becomes increasingly important to use the right hardware. 

Summary:

So, with all this information, how should we proceed? 

Primarily, it is important to realize that all these topics can be best thought of as spectrums rather than true/false statements. Data can be small, medium, or large. Your data complexity can vary tremendously. Your hardware selection can range from inexpensive Chromebooks to top of the line iPad Pro's. All these things will impact your experience, so you should try, if you can, to keep these factors in alignment. If you want to use big, complex data, you need well provisioned data hosting, solid internet connections, and powerful devices. If you can refine your data to be smaller and simpler, you will not need to invest as heavily in your infrastructure and devices. 

Second, consider performance as you design your solution. Your experience with a powerful desktop computer running ArcPro will be different from an app user in the field on a mobile device. You want to construct a data set and application that benefits both office and field workers! It can be helpful to put yourself in the field worker's shoes and ask the question "What is the least amount of data they need to do their job?" The smaller and more efficient the data set, the better the app experience will be. 

Lastly, just as importantly, test it out! As we have seen throughout this article, there are few simple answers to the question of how to ensure a quality app experience. When you are developing your project and applications, be sure to test your solutions against real devices, with real use cases, and in conditions like what your field workers will encounter as they are doing their jobs. They will thank you for it, and you will ensure the best and most efficient work possible.