Skip navigation
All Places > ArcGIS AppStudio > Blog > Author: MVertzonis-esristaff

ArcGIS AppStudio

13 Posts authored by: MVertzonis-esristaff Employee

Faking-it is generally frowned upon – but demonstrating an app that is designed to work outdoors with a GNSS receiver at say a conference, or for your colleagues in the office, warrants a little creative location simulation. For years we’ve hit this problem ourselves at the user conference in San Diego, and after various iterations of fake GPS, I’d like to share our latest offering, by way of an AppStudio sample.


As of AppStudio 4.2, the GNSS Discover sample has the ability for you to:

  • Record a NMEA log file from a connected location provider
  • Playback recorded NMEA messages as if they were coming directly from the connected location provider.


You can also play back files created from other apps – not just GNSS Discover. Some GNSS receivers have the ability to save these files and there are tools online that allow to create simulated files. You can also save the file on your phone and copy it to your desktop to playback. The same file is compatible on all platforms.

What is a NMEA log file?

NMEA 0183 is the data specification standard that AppStudio uses to communicate with GNSS receivers. NMEA messages contain lines of data called sentences. To cut a long story short, save these sentences to a file, and you can replay them in an AppStudio app just like when they are coming directly from a satellite system. The contents of the file will look something like this:



Record a NMEA log file

To capture a NMEA log file with the GNSS Discover sample, create an app with the sample and download it to Player. Connect a receiver to your device and head outside for a walk (or ride, or drive). For more information see Connect your receiver to your device.

  • Click the satellite icon at the top of the app and go to the GNSS location status page.
  • Switch to the Debug tab.
  • Click the Record button.



Whilst you are recording, you can return to the map screen or anywhere else in the app. When you are finished moving around, come back to the Debug tab and Stop recording.

Recorded log files are saved to the folder [User home directory]\ArcGIS\AppStudioPlayer. Each time you capture a new log a new file is created.


Playback a NMEA log file

Playback of a NMEA log file is almost indistinguishable from connecting to a physical receiver. On the location providers page, click Via File, browse to the NMEA log file and click OK.



On the About page of the file location provider there are two settings to consider: loop at end of file (great if you want to capture a short circuit that you can continuously loop through), and update rate. The default update rate is 1Hz which is typical of most receivers. This would mean the playback is in real time. Depending on your demonstration, it might suit to speed things up!



Once you have configured a file location provider, you can use the app in exactly the same way as you would with an external position source. The location status pages will show all the information as you would see from the external position source, and if your app is designed to capture locations, all the available metadata will be captured.



And of course – as this is now in AppStudio, you can expect for this feature to be coming soon in Survey123 and QuickCapture. Record a NMEA log in one app and use it in any of the others. Magic!

Although I’m generally not excited when I see a parking inspector on the side of the road, the technology nerd in me does always look around to see what gadgets they are using. Gone are the days of a notepad and pencil, instead they usually have an all-in-one device, or a phone with a printer hanging on their belt, to print out the tickets. 


Keen viewers of the AppStudio 4.2 highlights video  would have caught a glimpse of one of our newest samples - Print Location. This sample shows how your app can connect to a bluetooth printer, display a print preview, and send a print job directly to the paired printer. So, although you might not be designing a parking inspector app, you can now add the ability to print information from your app on the spot: a receipt of services completed, or evidence of data entered in the app. 


The printer used in the highlights video is a Zebra iMZ220. We’ve tested this printer on all our supported platforms and have had it whitelisted in AppStudio Player on iOS so you can use it on your iPhone or iPad, as well and Android, Windows, Mac and Ubuntu. Other printers can work in a similar way, and might only need a little tweaking of this current app. This app has not been designed specifically for, or tested with other printers, but can be used as a starting point for your own awesome app that prints to a bluetooth printer. 


Explore the Print Location sample 


The Print Location app is available in AppStudio for you to use as a sample. Of course, to fully test this app you will need a printer, but even if you do not have one, you can try out the print preview and get an idea of how you can use it. 

  1. Launch and sign in to AppStudio on your desktop. 
  2. Click New App, search for and choose Print Location and click Create. 
  3. Click Upload to make this app available in your ArcGIS organisation. 
  4. Launch and sign into Player on your device. 
  5. Browse for and download your new app, and click Play. 


There are three tools in this app: 

  • Settings 
  • Print Preview 
  • Print 


The Settings tool will be familiar to anyone who has worked with our GNSS Discover sample or any of apps that connect to a bluetooth GNSS receiver. The concept here is the same. You first pair the bluetooth accessory with the device, the app needs to then identify that paired device, and then once identified it can send or receive information to or from it. 


The Print Preview demonstrates what information will be sent to the printer. In this sample, see how there is a combination of things that were visible in the app – ie: the map – and things that were visible ie: the coordinates and time stamp. You choose what to print out independently of what is shown on the screen. 


The Print tool is self-explanatory. Whatever is shown in the print preview, is what is sent to the printer when you click Print. 


Things to consider  


  • An app that needs to communicate with a printer needs the Bluetooth capability to be set. 
  • This sample specifically filters for only devices that have ‘iMZ’ or ‘Zebra’ in their name. If you are experimenting with a different printer, remove (or comment out) lines 87 and 89 (leaving line 88) from /BluetoothPlugin/BluetoothManager/BluetoothSources.qml. 

When you do this, you will see that all paired Bluetooth devices will appear in the list. There isn’t a standard device type that can be used to filter for only printers, so once you get your app working with your printer, think of a good name filter to use to hide the noise of all possible pair devices. 

  • Whitelisting is required on iOS. In the case of Apple any hardware accessories that are to be used by an app, need to be identified by that app and vice versa. For details see Apples MFi Program, but the short version is that if you have a printer you want to use on iOS with your app, the printer manufacturer needs to identify your app, and your app needs to identify them. We have already whitelisted the Zebra iMZ220 with Player, but If you have a different printer you’d like to use with your app, I recommend testing it out on Android or Windows first, and then once you have it working on those, consider whitelisting. If you are using Player to run your app – please contact us with information about your printer and we will see it’s a device, we can have whitelisted. 


Have you made a great app for outdoor use, that would benefit from high accuracy location? Do your users want to improve the location that they capture or report in your app, by using an external receiver? Do you want to report a location in your app that is being fed from a receiver that is remote to you but available over a network? In each of these cases, you will want to add the ability to search for, and connect to, an external GNSS receiver in your app.


We have recently added this ability to a number of our apps – Trek2There, Survey123, QuickCapture – and now we have made that work available to you, as a small collection of custom components, so you can drop them into your own app.


There are a few considerations you need to evaluate before adding GNSS device discovery to your app – what hardware are you intending your app to be used on, what receivers you want to support – jump to the end of this post to explore those.


For now, I want to show you the mechanics of making this work. The code that you can add to your app is available as an AppStudio sample called GNSS Discover. You can download this directly to your computer and copy and paste contents of it to your app.


The following steps will demonstrate how to add GNSS device discovery to the Hello World (Runtime) starter app. I’ve deliberately chosen this lightweight app so you can see the few steps that it takes to add this complex functionality.


        1. Launch and sign in to AppStudio Desktop Edition.
        2. Search for and download, the GNSS Discover sample app.
        3. Click New App, choose Hello World (Runtime) and click Create.
        4. Select the app you just created in the AppStudio gallery, and from the side menu choose Files. This will launch a file browser showing you the files created for your new app.
        5. In the AppStudio gallery, select the GNSS Discover app that you downloaded already, and from the side menu choose Files. This will launch another file browser showing you the files of the sample app.
        6. Copy the subfolder called GNSSPlugin, from the sample app to the folder of your new app.
        7. Close both file browsers.
        8. In the AppStudio gallery, select your new app (created from the Hello World starter app) and from the side menu select Edit. Your app will now launch in your default code editor. You will make edits to the MyApp.qml file only.
        9. After the existing import statements at the top of the file, add the following reference for your app to be able to use the contents of the folder that you just copied to your project:

          import "./GNSSPlugin"

        10. Scroll to the bottom of the MyApp.qml file. Before the last curly brace, you need to add the following code. This code is also in the GNSSDiscover.qml of the GNSS Discover sample app. You can open this file and copy and paste from there if you prefer.

          // Manage connections to GNSS providers

          GNSSManager {

              id: gnssManager

              gnssSettingsPages: gnssSettingsPages


          // GNSS settings UI

          GNSSSettingsPages {

              id: gnssSettingsPages

              gnssManager: gnssManager


          // GNSS status UI

          GNSSStatusPages {

              id: gnssStatusPages

              gnssManager: gnssManager

              gnssSettingsPages: gnssSettingsPages


        11. The GNSSManager that you have just added provides a new position source that will communicate with both your internal position source and any configured external position source. To use this, change the positionSource of the existing locationDisplay component, to be gnssManager. It should look like this:

          locationDisplay {

              positionSource: gnssManager


          Save your work. If you choose to run your app at this stage (Alt+Shift+R), you will see the map launch and it will have two buttons, a home and location  button.

          Click the location button and see that the map will center on your current location. By default, the app is using your devices internal position source. To be able to use an external receiver, you need to be able to select one. We will next add a settings button , so you have somewhere to select a new receiver.


        12. Copy the existing locationButton component and paste a copy of it immediately below the original one.
        13. Change the id of the copied component to be settingsButton.
        14. Change the source to be


        15. Change the name of the parameters in the onHoveredChanged event of this button to be


        16. Remove the contents of the onClicked event and replace with


          Run your app. See that there is now an additional button with the settings icon. Click on this button and see the settings page. On this page you can choose to connect to a GNSS receiver that is connected to your device.


        17. As an optional bonus – would you like to make the color of the settings button match the others? You can do this with a color overlay.Start by adding the Qt Graphic Effects plugin so you can use the color overlay component.
        18. At the top of the file where the other import statements are, add the following:

          import QtGraphicalEffects 1.12

        19. Add an id of settingsButtonImage to your button image component.
        20. Add the following code immediately after your button image component:

          ColorOverlay {

          anchors.fill: settingsButtonImage

          source: settingsButtonImage

          color: "black"


          Ensure that the name for anchors.fill and source is the same as the name that your gave your settings button image in the previous step.

        21. Save your work and run your app. See that the settings button is now the same color as the other buttons.


          Instead of cloning and modifying an existing button, there is a settings button component in the GNSS Discover sample that you also could have used.  Steps 12-17 show how you add new functionality to your app whilst maintaining the existing presentation of tools.


          Also included in the GNSS Discover sample is a status button that indicates when the position source is connected, and when clicked, displays information coming from that position source. In the next step, we will add this button as is.


        22. After the last button in your app, paste the following (this code is also in the GNSS Discover sample)

          GNSSStatusButton {

          gnssStatusPages: gnssStatusPages


Save your work and run your app. The status button is only visible when the location is active, so first click the location button for the status button to appear.  See that the status button has different styling to your other buttons. You can choose to style it as you wish. Click on the status button to see information coming from the position source.



You can add the components from the GNSS Discover sample to any other app in a similar way. Just include the GNSSPlugin folder in your app and reference the GNSS Manager, GNSS Settings and GNSS Status pages in your app. You can choose how to launch the settings and status pages to suit your needs. For alternative examples on how to launch those pages, take a look at the code for the GNSS Discover sample itself. This sample shows buttons for the status and settings pages, that appear on the toolbar of the sample app.



Things to consider


An app that needs to communicate with external GNSS hardware needs the high accuracy location and Bluetooth capabilities to be set.

Also, to be able to work on iOS devices, the receiver must be part of the MFi program as well as support the output of NMEA sentences.


Whilst building your app, we recommend you test in AppStudio Player. Player already has many GNSS receivers whitelisted so you can test your app on iOS before whitelisting your own app.


To learn more about using GNSS receivers with your apps see


Building native apps using AppStudio for ArcGIS allows you to integrate all sorts of cool hardware with your app. The hardest part is knowing how to communicate with the hardware, and what to do with the information that you can get from (or send to) it. The following intends to be an overview of the three B's - Bluetooth, Bluetooth LE and beacons, which may help you decide which of these you might need to learn more about, to solve your hardware communication requirements.




In AppStudio 3.0, we introduced support for classic Bluetooth connectivity. The most common use of classic Bluetooth for many years has been by GNSS vendors to connect their receivers to devices. You can also communicate with other sensors using Bluetooth, such as laser rangefinders and environmental sensors. The GNSS Info sample in AppStudio demonstrates how you can connect to a device with Bluetooth. To learn more about this sample see this blog.


Bluetooth LE


In AppStudio 3.1, we added beta support for Bluetooth low energy (LE). A subset of Bluetooth, as the name suggests, Bluetooth LE uses less power and is ideal for more frequent transmission of smaller amounts of data. Code samples of these are a little harder for us to offer you, as typically the devices that transmit data via Bluetooth LE, do so with proprietary information. The most prolific Bluetooth LE devices in the community are fitness devices. To use your Garmin or Fitbit device you need to connect to a proprietary app to see the information: for example, steps, distance, and calories burned. You will be able to use AppStudio's Bluetooth LE components to detect Bluetooth LE devices, but typically you wont be able to interpret the data that is transmitted. Here is a sample that demonstrates connecting to a fitness device. You may not be able to use this exactly, but it shows how to get started. Once a known device is found: a known service, characteristic and descriptor is also detected by the sample.


Services, characteristics and descriptors are how devices package information that they want to share via Bluetooth LE. For more information (including a diagram of how these are related) see the BluetoothLEDevice page in our API Reference. Note:  We are working to add more description and samples here!


One of our friends, GPS-IT, have already used AppStudio's Bluetooth LE support to create an app that communicates with their very own hardware! Their platemeter device is used to measure pasture volumes and the accompanying iOS and Android apps built with AppStudio, receive the measurement values from the hardware via Bluetooth LE.




In coming releases of AppStudio we will be adding specific support for beacons. You can consider beacons as a subset of Bluetooth LE devices. They use the same LE protocol, but make identifier information more readily available, suitable for create alerts and triggers when interacting with the beacons.


And because this is not complex enough, when reading about beacons, you will see two terms: iBeacon and Eddystone. In short, these are the Apple (iBeacon) and Google (Eddystone) ways of communicating with beacons, but they don't limit which device you use to communicate with the beacon. One is not necessarily better than the other, they are just different. In AppStudio we've made progress with iBeacon properties first, and will share more about our beacon support in coming blogs and releases.


You might be thinking: why beacons? The most common beacon use case is that of an interactive shop or gallery. Imagine entering a museum, and when you buy your ticket you are directed to launch the museum tour guide app. In the foyer area the app will show you general info about the museum. As you enter a gallery space, information about the room and the collection you are about to see, is shown (or dictated) to you. As you approach an individual object, information about that specific object is shown to you. This guided navigation can be achieved using beacons located near each object, or entrance to a space.  This is a great way for keeping propriety information on site. The user can only see or interact with the information, whilst they at your venue. Retailers also use a similar pattern to engage with a customer: as you approach an item or location in the store, targeted advertising or specials can be shared with the user.




Knowing whether to use Bluetooth or Bluetooth LE is very much dependent on the hardware you want to integrate with your app, and the hardware itself may restrict what type or amount of information you can receive from (or send to) it. We are keen to hear what Bluetooth hardware you have or would like to integrate with your AppStudio app, and look forward to expanding more on these concepts in more blogs and in our AppStudio help.

The new GNSS Info sample, included in AppStudio 3.0 Desktop Edition, brings together the components in Qt and the AppStudio AppFramework that you can use to build an app that interacts with GNSS (Global Navigation Satellite System) receivers.


Common features of this type of apps are:

  • The requirement to browse and connect to a receiver
  • Display a location on a map along with metadata about that location
  • Presentation of available satellite information
  • Presentation of key quality parameters that may indicate the usefulness of the data received
  • Display a raw feed of the data coming from the receiver for troubleshooting purposes


Each of these features are shown in this app on separate tabs. You may choose to use one or more of these tabs in your own app, or use this app as it is, to test out your own GNSS receivers with your hardware.


What type of receivers can be used?

This app will connect to, and display location information from, GNSS receivers that output NMEA sentences. For examples of recievers that we have tested with see GPS receiver support—AppStudio for ArcGIS | ArcGIS .


Qt and the AppFramework can also read and write data to other bluetooth devices using the same components used in this app. For example, you can connect to a bluetooth printer using the same device discovery component and send data from your app to the printer for immediate printing.


For more information on the key components in this sample refer to:


Receiver detection

This app can detect receivers that are connected to your device using:

  • Bluetooth pairing – to connect to a receiver in your app you must first pair it with your device. Note that some receivers have a limit to the number of devices they can be paired to at anyone time. For example, the Eos Arrow can only pair to one device at a time, while Bad Elf devices can pair with up to 2 devices at a time. For information on pairing your reciever see Use a high-accuracy GPS receiver—AppStudio for ArcGIS | ArcGIS .
  • USB/COM connection – A GPS receiver that plugs into a computer via USB is displayed in the app as a COM port. To confirm which COM port your device is represented by, look at the list of devices connected to your computer. For example, on Windows go to Device Manager > Ports (COM & LPT).
  • TCP/UDP network connection – A TCP (Transmission Control Protocol) connection is bidirectional and has limited error handling. On the other hand, UDP (User Datagram Protocol) is one way only and has no error handling. Creation of a UDP connection requires the hostname and port of the destination machine (where you are running the app), while creation of a TCP connection requires the hostname and port of the machine providing the GNSS information to the destination machine.


On the device tab, press to select a device. Next time you launch the GNSS Info app, it will attempt to automatically connect to the last device used. You can always return to the device tab and change which device you connect to.


Location display

The location tab shows the current location on a map. If your device has network connectivity, an online basemap is used. A limited offline basemap is also available in the sample.


Key metadata about the current location is displayed. The app also allows the user to change the units in which latitude and longitude are displayed.


Use the location tab to confirm that the location reported from your hardware is the expected location.



Satellite sky plot

The skyplot tab shows both a skyplot and a table view of the satellites reported by the receiver. Be aware that some receivers have a physical display that may sometimes display different values to this page. Other receivers have their own companion app that also may show different results. These differences are mostly likely attributed to manufacturer specific parameters and the way each manufacturer presents data from the receiver.


The GNSS Info app displays the number of satellites in view, and the amount in use to calculate your location. There can also be satellites in view (or in use) that have no signal. This is usually a temporary response and should not affect the quality of a location displayed in an app.


Use the skyplot tab to ensure you have positioned yourself or your hardware in the best location to capture a suitable position value.



Quality tab

The quality tab lists common meta data available from a GNSS receiver. These are values you may choose to capture during data collection as attributes of your feature. Alternatively, you may use these to indicate the quality of the position to the user. For example, you might warn the user that accuracy values are greater than a prescribed threshold and disallow them to capture data.



Log tab

The log tab shows a stream of the sentences that are emitted from the receiver. Different receivers output different sent

ences. The presence or absence alone of sentences is useful for troubleshooting a receiver connection issue. The inspe

ction of the presence or absence of individual sentences can also aid diagnosis of unexpected parameter results. For example, latitude, longitude and altitude errors are only calculated when the GST sentence is present. Not all receivers

output the GST sentence. If the GST sentence is not available, then ‘No Data’ is reported on the quality tab for latitude, longitude and altitude error.


Use the pause button on this tab to study the latest sentences. Use the delete button to clear the screen to make it easier to read new sentences.



Switching between the tabs of this app will display to you the continuous stream of data reported from the connected GNSS receiver in several ways: as text, on a map, as a graphical representation, and in its rawest form. You can choose which of these best suits your own app, or use this app to evaluate what information is available to you from your own receiver.

Trek2There is a smart compass that will always point to your destination. If you missed previous releases, read more about the app in 
To help you orientate yourself in your real world surroundings, Trek2There now has a first person view that displays your destination on the camera view of your device. Tilt your device up to face where your going, and see the existing direction arrow change to a camera view with your direction and distance overlaid on the image.
We think this heads up display is pretty cool on its own - but if your keen, there's more for you to try out. On the settings page you will see an option called Experimental Features - turn these on to try out the use of more sensors on your device. 
By default in Trek2There, we only use the location sensor to determine where you are in relation to your destination. When you enable experimental features, we also make use of the compass, gyroscope and other sensors. We have seen this work great on some devices in some scenarios, but also a little a strange in others. We are very keen to hear from you on how the experimental features work for you. Ideally this is what you will see when you are in experimental mode:
  •    When you are stationary (or moving very slowly) the compass will be used to determine the distance and direction to your destination. This should result in stationary or very smooth movements of the direction arrow. In the top right hand corner you will see the text CMP to indicate that the compass is in use.
  •   When you are moving steadily, the location sensor will be used to determine the distance and direction to your destination. This should result in steady changes in direction (not shakiness that can result when using the compass while moving). In the top right hand corner you will see the text GPS to indicate the location sensor is in use.
Please let us know how the experimental features work on your device by commenting here

Trek2There is a smart compass that will always point to your destination.  Unlike an ordinary compass, pointing to magnetic North, this app will use your direction of travel to tell you in what direction you should go to reach your destination. If you missed the original release of Trek2There, read more about the app in the Introducing Trek2There blog article.




Trek2There has now been updated to fix a few nuisances that users have found:

  • Copy and paste on iOS devices. You can now copy from another app: a single number value, a coordinate pair, or JSON coordinates. Copying a coordinate pair or JSON is really the best choice. If you’re unsure which number goes in which field – when you choose to copy and paste a coordinate pair or JSON, you are given an option to switch them!
  • A horizontal location accuracy indicator has been added. The bulls-eye in the top right hand corner will indicate the horizontal accuracy returned from your location sensor. As your accuracy improves the inner most rings are highlighted.
  • When you are not moving, the direction arrow now has a strike-through symbol to help remind you to move.
  • The scale of Setting icon in the 'no destination set' message has been improved.
  • The Contrast button has been changed to be more visually different to the Settings button.


We have also improved Trek2Theres accessibility. If you use accessibility tools – please try Trek2There, and let us know how it works with your preferred tools. Provide your feedback in the form of issues.


Trek2There is available in the iTunes and GooglePlay app stores and is now also available for download for Windows.

Release 1.1 of Tile Package Kreator is now available for download from the ArcGIS MarketPlace. You can also download the source code directly in AppStudio for ArcGIS Desktop Edition, or from GitHub.
Download this PDF document for a handy help guide for Tile Package Kreator.
In this release we have focused on two key improvements: using an existing area or path to define an extent, and searching for a tiled service.


Use json to create a path or area

Drawing a rectangle or line on the map is the simplest way to create a collection of tiles for export to a tile package. But now you can drag and drop json or geojson onto the Tile Package Kreator map to define your area or path. This is great if you already have a complex feature that defines the extent of your offline requirements. 
For example, you may wish to create a TPK file for your city extent. Save the city boundary as a json or geojson file and drag and drop it onto your Tile Package Kreator map. 
Creating a file for your polygon or line is one way to use json to create an extent, but if your feature is already in a feature service, you can copy and paste the json representing that feature directly from the feature service web page. Be sure to use keyboard shortcuts when you copy/paste from a web page, rather than using right mouse clicks.
Other tools can also be used to generate json or geojson - try On this website draw your extent on the map, then copy and paste the json directly onto the map in Tile Package Kreator.
Remember that the area or line feature that you copy to the Tile Package Kreator map must have a spatial reference of WGS84 - either 3857 or 4326.

Enter the URL of a tiled service

When you sign in to Tile Package Kreator and choose to Create a new tile package, all of the tile services available to you will be presented. You can select any one of these to create your TPK from. If your desired tile service is not listed, click the plus button in the top right hand corner and enter (either type or paste) the URL of your tile service. 
A tile service may not appear because it has not been registered with your ArcGIS organization, or you may have a large number of services. Once you have entered the URL of the service it will appear at the end of the catalog of services. Select the service to proceed to the next step of nominating an extent.
Remember that only tiled map services that have export tiles enabled can be used to create a TPK file.

This blog introduces Trek2There, a new mobile app from Esri Labs just published to the Google Play and iTunes app stores.  Esri Labs projects are developed by Esri employees and are inspired by our interactions with ArcGIS users like you.


Esri Labs projects are free to use but are not official Esri products. These projects do not go through the rigorous software development cycle so they are not holistically tested, documented or supported by Esri technical support. Despite all of these, you may find Trek2There not just awesome, but also pretty useful!


You can think of this app as a smart compass that will always point to your destination.  Unlike an ordinary compass, pointing to magnetic North, this app will use your direction of travel to tell you in what direction you should go to reach your destination.


Trek2There is particularly helpful when you are trying to find a location in an area where driving directions would not cut it. Say for example, you want to find a point of interest in a forested area with no trails. Say you are trying to find an archeological site, a pond or an asset for which you only know its geographic coordinates.


Trek2There only requires two things to work:

  • First, the destination where you want to go provided in geographic coordinates (Latitude/Longitude).
  • Second, it requires you to be outside and moving so your device can fix your location and determine your direction of travel.

Let’s first try the app and then I will explain details of how to make it work with your own apps.


Trek2There, a first quick test

Start by downloading Trek2There onto your Android or iOS device.  You need to feed the app with the coordinates of your destination, these can be typed in manually or more typically are sent from a separate application. For now, we will use a simple web-based app. On your device, launch this web app and tap on the map to select your destination. As you tap you will see a new dialog open from which you can launch Trek2There.


Now that the app is running, start walking in any direction and shortly the arrow will rotate to show you the direction and distance to your destination.  Walking with caution and avoiding physical obstacles is all on you! 


Trek2There custom URL scheme

Using the app is straight-forward as you can see. Launching it and passing the coordinates of your destination is what takes some thought but do not worry, it is not complicated at all. Trek2There can be launched remotely by invoking this custom URL scheme:

arcgis-trek2there://?stop=38.133, -117.2324

If you copy the above string and paste it into a browser on your device, you will be able to launch Trek2There and set its destination at the provided latitude and longitude. You could send this URL as a link in an email, or programmatically invoke this URL from a custom developed application.


Launching native apps like Trek2There through a custom URL scheme -also often referred to as a deep-link- works fairly well across all platforms when you invoke the URL from a custom native application.  If you invoke the app from a web browser it will work as expected on Windows, iOS and Mac. On Android you may find issues launching the URL scheme from some mail clients and the Chrome browser.


Working with Trek2There’s custom URL scheme from your own apps

The sample web app illustrates how you can launch Trek2There from your own web mapping app built with the ArcGIS API for JavaScript. If you're comfortable with this API, the source code is pretty straight-forward, showing how you can embed within a popup a Trek2There custom URL scheme.


If you build your own applications with AppStudio for ArcGIS, you can of course launch Trek2There as well.


Customizing Trek2There

The source code of Trek2There is shared under the Apache 2.0 License, so if you like you can take this app and make it your own. May be you want to embed this functionality within your own app, or re-brand Trek2There… your choice!

You can find the source code at


Esri welcomes contributions from anyone and everyone. Please see our guidelines for contributing.


The easiest way to download the source code is by using AppStudio for ArcGIS Desktop Edition.  Once installed, click on New App and search for Trek2There under the Enterprise category.  You can look at the code, modify it and run it in your Mac or Windows development machine. If you have an AppStudio for ArcGIS Standard license, then you will be able to compile your code for Windows, Mac, iOS, Android and Ubuntu Linux. 


With AppStudio for ArcGIS now officially released, its a good time to recreate any apps that you may have made during the AppStudio beta to be sure they are using the most up-to-date template code. In particular, do recreate your map tours as they may no longer work.


The change made to map tour was very small - we took out an import statement that was not being used. But the consequence is that when you attempt to run your app inside AppStudio Player (or attempted to build it with cloud make), your app will appear as a white screen.


If you have made many map tour apps - we have created a sample that can help you repair your existing apps.To download the sample,

  • Open AppStudio for ArcGIS (Desktop Edition)
  • Browse to Search > Groups > Sample Apps
  • Download the Map Tour Update sample


This sample will.

  • find all apps in your ~\ArcGIS\AppStudio\Apps folder, of the type map tour and in each of them,
  • remove the import ArcGIS.AppFramework.Runtime.Dialogs 1.0 from the top of the file MapTour/MapTourApp.qml, and
  • copy the file MapTour/PortSignInDialog.qml to your existing map tours MapTour folder


You could also do these steps manually without running the sample. Be sure to create a new map tour with version 1.0 of AppStudio to get a copy of the MapTour/PortSignInDialog.qml file to copy into your old app.

AppStudio for ArcGIS (Beta 4) is now publicly available, directly from the product site. Go to to and sign in with a Named User account to

  • create an app from a template, directly on the web, or,
  • download AppStudio for ArcGIS Desktop Edition.


To make your life a bit easier we created a handful of video-tutorials:


Some of you got stuck trying to understand how to publish your own apps into the Google Play and Apple app stores. So we also created new videos describing the process:


Changes in beta 4 include:


  • AppStudio is now built upon Qt 5.5. Qt 5.5 introduces new functionality that many users have been waiting for including improved and new modules of 3D, Charts, GUI, Network, Multimedia, WebView and Bluetooth. For a full list of new features in Qt 5.5 see Qt Creator has also been updated to version 3.5.
  • Windows 10 is supported.
  • Player has now been separated from AppStudio. When you install AppStudio, you can still choose an app and run it, but instead of launching Player on the desktop, you launch just your app. If you require Player on Windows, Mac or Linux it can be downloaded separately.
  • All apps created by the AppStudio team have now been converted to the new Native Application ArcGIS item type. This will mean you will no longer see the warning icon on our samples. Support for items of the type Code Sample will continue during Beta 4, but will be removed in the next Beta. To migrate your app, click the Menu on the app thumbnail and choose to Create new app from [App Name]. This will create a new local version of the app. When you add the app to ArcGIS using the Upload tool it will be assigned an item type of Native Application.
  • The properties page of the Settings tool no longer freezes when you attempt to edit it. The properties have been organized into multiple tabs to make it easier to browse the properties and descriptions added for each.
  • Quick Report template updates:
    • Secured feature services are now supported.
    • Features services with a spatial reference other than Web Mercator are now supported.
    • The baseFontSize property has been fixed to ensure that you can scale up or down all text in the app.
  • Map Viewer updates:
    • Improved legend support for map services.
    • Added chart support in popups.


There are a few known issues with Beta 4 that we are working to address, but with these few tips, you can still continue to work on your own great apps :


  • When installing AppStudio on a desktop whose is locale is one of the supported languages other than English, some text in the install wizard will appear with mixed characters. These are markers that indicate that the text is translatable but not yet translated. This text will be translated in the next release of AppStudio.
  • Standalone apps that use the new WebView component, and any app launched in AppRun or AppPlayer on Mac OS 10.8 and 10.9 will not display. An immediate fix for you is to upgrade to Mac OS 10.10. We will shortly release a fix for 10.8 and 10.9.
  • When you download an app in AppStudio for ArcGIS (Desktop Edition) or in Player, the thumbnail may not appear immediately. Click the refresh button to display the thumbnail.
  • The templates are not translated yet.

What are app properties?

Every app created in AppStudio can have properties that can be defined by the user (either desktop or web) that change the way the app looks or behaves. These allow you to customize an app without opening it in Qt Creator and navigating code.


Each of the app templates that Esri provide a wide range of properties that you can change. You can change colors, text sizes and font, and hide and display portions of the app. To change the properties in the desktop edition:

  1. Select the app in the AppStudio gallery
  2. Click the Settings tool on the toolbar
  3. Click the properties tab
  4. Change any of the properties, and click Apply

NOTE: There is a problem in Beta 3 when editing properties. Be sure to NOT BE SIGNED IN. We have discovered that signing in does interfere with the operation of the properties page, cause the page to freeze and sometimes not save your changes. We are working to fix this.



Where are app properties defined?

AppStudio displays the properties in a user friendly way, for example, presenting color and file dialogs for certain fields. However, the definition of what is displayed, is stored in a configuration file in the ArcGIS item of the app called appschema.json. This configuration can be edited in a text editor to change the descriptions of each property and also to change how a property is presented. For more information on this file see What is an app item?—AppStudio for ArcGIS Desktop Edition (Beta) | ArcGIS



Why is the content of this tab in English?

All text on the properties tab of the Settings dialog comes from the label fields of the appschema.json configuration file. Currently all Esri configuration files are in English only. Our intention is to have all Esri templates (and their configuration files) translated for the first full release.


If you are creating your own app that needs to be in a language other than English, be sure to translate the labels in your appschema.json file.

AppStudio for ArcGIS is now publicly available, directly from the product site. Application to join the Esri early adopter community is no longer required to use AppStudio. Go to http:\\ and sign in with a Named User account to start using AppStudio or download the Desktop Edition.


Over the coming weeks we will phase out using the early adopter community and move to disseminating information only via GeoNet.


Whats new in Beta 3?


You can also now create an app directly on the web. Choose one of the featured apps and configure it for your own use. Build installation files and a landing page all on the web, and get ready to distribute your own native app.


Player is now available in Google Play and App Store


Changes and new features in the Desktop Edition include:

  • The template Wizard has been replaced with the New App tool. Now you have more choices to get started creating your apps. You can choose on of the following:
    • Featured template—Map Tour, Map View or Quick Report.
    • Starter app—For example, 'Hello World'.
    • Layout—For example, a toolbar and content area.
    • Enterprise app—An enterprise version of Player that acts as a home to a collection of your apps.
  • The ArcGIS item type used for AppStudio projects has changed from Code Sample to Native Application. For the duration of Beta 3 these will co-exist, but at the next release code sample item types will not be supported. Code sample item types are only visible in Desktop Edition and not the web and are indicated with a warning icon on the thumbnail. You will not be able to manage your code sample item type apps online. To migrate your app, click the Menu on the app thumbnail and choose to Create new app from [App Name]. This will create a new local version of the app. When you add the app to ArcGIS using the Upload tool it will be assigned an item type of Native Application.
  • The ArcGIS item type used for installation files has changed from Code Sample to Native Application Installer. Installation files of type code sample will not be available in http:\\ To update your installation files, delete the existing code sample item types from ArcGIS and request a new build with Beta 3.
  • Introduction of Appschema, a configuration file that defines how to present the custom defined properties of an app to the user in AppStudio Settings. For additional details see What is an app item?
  • Improved localization, including better handling of left to right languages and more translations. The install wizard is also now translated.