One of the capabilities introduced in recent versions of RAD Studio and AppMethod is App Tethering. Over a number of posts I want to explore App Tethering further, starting from an overview of the technology and then going further down… down eventually to the network packet level. My aim is you’ll come out with a quite thorough understanding not just how to use App Tethering, but also what you might use it for.

In the absence of anywhere else to start, let’s start with a question.

What is App Tethering?

In its simplest terms, App Tethering makes it easy for apps to find and communicate with each other. Now, I accept that is so generic an explanation as to be almost useless. You could say something similar about DataSnap, or EMS, or plenty of other distributed systems. So let’s shed a bit more light.

Firstly, App Tethering is Peer to Peer. You’ve probably seen diagrams that look like this:

This is your typical client/server-based architecture. Clients connect to a server to send and receive data, and usually if a client wants to talk to a different client, they do it via the server.

That’s not what App Tethering looks like. App Tethering is peer-to-peer, not client/server, so looks more like this:

There is no server involved. Any app can initiate a connection and any app can share data. Further, a single app might be connected to multiple other apps. So the first thing we need to do is drop the words Client and Server from the discussion, as it just becomes too restrictive. If you find yourself thinking “How does my server…?”, or “Should my client…?” then stop. All we have is one or more apps finding each other, exchanging some data and then disconnecting.

Secondly, App Tethering is not just about mobile. The apps involved can be on mobile or desktop platforms, client-facing apps or services/daemons, VCL or FireMonkey.

Lastly, they can also be on the same machine or on separate machines. When on separate machines, they are communicating either over an IP network or Bluetooth (Classic, not LE).

So what we end up with is App Tethering allows apps to discover other apps over IP or Bluetooth, and then exchange data and trigger actions between themselves, all in a peer to peer environment.

Why would I want to do that?

Fair question. Probably the best way I can answer that is to give you some examples of how I’ve seen customers using it.

App Tethering and the Pool

One of our customers writes software for professional sports coaches to help them capture and analyse data about their athlete’s performance. They have a very rich, Windows-based application that has been developed over many years. However, increasingly they were getting requests for a mobile version, as even laptops were too bulky/fragile to have in some environments where the coaches wanted to use the system, such as the end of a swimming pool lane.

When they dug further into these requests, it was only a subset of the full application that was needed on the mobile device. For example, a coach might want to log turns and stroke data for a swimmer on a tablet, pull up simple analysis on lap times for discussion with the athlete, without forcing the swimmer out of the pool and dragging them over to a laptop. However the more detailed historical analysis and training planning would still take place on the full desktop system.

What they ended up building was a FireMonkey tablet app that communicated using App Tethering directly with the desktop app. This provided a number of advantages:

The mobile app itself was quite quick to build, as it was only the specific functionality that was needed on the tablet.

The impact on the desktop app was minimal. As it was peer-to-peer, there was no need to introduce a server-layer and synchronise data between the two apps. In fact, all the App Tethering functionality was quarantined to a dedicated data module and the main parts of the app were not touched.

Because of the above two points, they shipped it quickly. They had a beta in their customers hands within a few weeks, and it has since gone on to be one of their biggest competitive differentiators.

App Tethering and the Dentist

I have another customer which creates Dental Practice Management software and they have an almost identical story. They quickly created a tablet app for dentists to use to discuss a procedure and review results with a patient in the chair, without having to suspend monitors above them or make them peer across at their desktop screen.

However, one massive added benefit here was that because the data was never stored on the tablet, the security risks of confidential patient data walking out the door was dramatically reduced. You could steal the tablet but once out of Bluetooth range all you had was an app, no data.

App Tethering and the Landlord

Another customer writes software for Real Estate agents, both to manage property sales and also rentals. They had an existing desktop app but wanted to add an application that their Property Managers could use when doing rental property inspections. The ideas was to take their phones out to the property, take photos of the condition, log any maintenance issues, record any comments, etc. Then when they return to the office the phone app connects to the desktop app, shares all the data across so that maintenance issues are created, and an Owner’s Report is generated and sent out automatically.

This app has been so successful they are now looking at creating another one for Open Houses. This idea is interesting because it is not a mobile app connecting to a desktop app, but two mobile apps, one for the agent conducting the open house, the other for the potential buyer/renter, allowing them to quickly register interest, get copies of the contract, and even get details of other similar properties the agent has available.

There are more examples I could give, but all of them share the same features:

There was an existing application and the desire was to build a companion application.

In all cases the companion app was smaller, quicker to build, and much more focussed than the existing app.

There was minimal impact on the desktop app, in some cases zero code changes to the existing forms.

In all cases they got it to market quickly and have had very positive responses from their customers.

Clearly there are circumstances where putting a server up in the cloud and following a more traditional client/server model is going to be more appropriate, but for building companion apps for existing applications, I’m seeing more and more clever use-cases for App Tethering.

App Tethering Concepts

The App Tethering API is actually pretty small. Conceptually it breaks down into four main areas:

Discovery – finding other apps, including whether you are looking for other apps over BlueTooth or IP Network

Pairing – connecting to other apps, once you’ve found them. This includes Authentication.

Resources – sharing data with connected apps

Actions – sharing Actions with connected apps

Further, these four conceptual areas are spread across only two components:

TTetheringManager Discovery Pairing

TTetheringAppProfile Resources Actions



Typically you’ll have only one TTetheringManager in an app, but you may have more than one TTetheringAppProfile. For example, in the Sports Coaching example above, you might have a bunch of Resources and Actions related to logging lap times and strokes grouped together in one TTetheringAppProfile, while all the Resources and Actions related to the analysis of the training session are in another. Doesn’t really matter to the App Tethering API, but can make it easier to manage your code if you can logically group things.

That will do us for this first post. Hopefully you now understand better what App Tethering is for. Next post, we’ll start to explore how to actually use it, by looking at the process of discovering and pairing with other apps.