Defense Dev Solutions- An ATAK plugin adds capability inside ATAK. A standalone app is its own app, on Android, iOS or both.
- Choose a plugin when your users already live in ATAK and the work belongs on the shared map.
- Choose a standalone app when your users do not all carry ATAK, need iOS, or the work is not centred on a map.
- There is a middle ground: a standalone app that sends Cursor on Target, so its data still appears in ATAK.
- The right answer depends on who the users are, how they work and how the capability will be maintained over time.
Two ways to put a capability in users’ hands
When a mission needs new capability on Android devices, there are two main ways to deliver it: as an ATAK plugin, or as a standalone app. Both run on the same phones and tablets, and both can be built to a high standard. They suit different users and different jobs.
- An ATAK plugin loads inside ATAK. It adds its own buttons, panes and map layers, and works alongside everything else on the team's shared map. Our guide to building an ATAK plugin covers how plugins are versioned and signed.
- A standalone app is its own app with its own icon, screens and release schedule. It can run on Android, iOS or both, whether or not ATAK is installed.
Neither is better in general. The right choice comes from asking who will use it, where and how.
When an ATAK plugin is the right choice
A plugin is usually the strongest choice when:
- Your users already work in ATAK. They keep using the app they know, with no switching between screens in the middle of a task.
- The work belongs on the map. Sensor feeds, tracks, overlays, targeting and navigation aids all make the most sense on the same map as the team.
- The capability should be shared. A plugin can use ATAK's connections to share its data with the rest of the team and through TAK Server.
- You want to build on what ATAK already does. Maps, offline imagery, contacts, chat and the TAK connection are already there, so the plugin can focus on what is new.
In exchange, a plugin follows ATAK's rhythm. It is built for specific ATAK releases, needs to be signed for the devices it runs on, and moves forward with each ATAK version your users adopt. Those are well-understood steps for an experienced ATAK plugin development team, and they are worth planning for from the start.
When a standalone app is the right choice
A standalone app usually fits better when:
- Not all of your users carry ATAK. Inspectors, support staff, partners and the public may never install it.
- You need iOS. ATAK plugins run only in ATAK on Android. A standalone app can serve iPhone and iPad users from the same back end.
- The work is not centred on a map. Forms, checklists, inventories, reporting and training tools often work best with their own screens and flow.
- You want an independent release cycle. A standalone app updates on its own schedule rather than with ATAK releases.
- It needs its own identity. A dedicated app can have its own look, sign-in and distribution, for example through your mobile device management system.
A standalone app has its own upkeep too: keeping pace with new Android and iOS versions, device policies and app store or MDM requirements. Our mobile development team builds these apps for field teams, including offline-first apps for rugged devices.
Side by side
| ATAK plugin | Standalone app | |
|---|---|---|
| Who uses it | People who already work in ATAK | Anyone, with or without ATAK |
| Platforms | Android, inside ATAK | Android, iOS or both |
| Best for | Map-centred work shared with the team | Forms, workflows and tools with their own screens |
| What it builds on | ATAK’s maps, contacts, chat and TAK connection | Its own design, data and back end |
| Release rhythm | Moves with ATAK versions and plugin signing | Moves with Android and iOS versions |
| Distribution | Through the channels your ATAK users already use | App stores or mobile device management |
The middle ground: an app that speaks TAK
The choice is not always either-or. A standalone app can still contribute to the TAK picture by sending Cursor on Target messages to a TAK Server. A field reporting app, for example, can give inspectors simple forms on their own phones, while every report appears as a marker on the map for the team using ATAK.
Other combinations work well too:
- A plugin and a companion app sharing the same back end, so ATAK users and everyone else work from the same data.
- A server-side integration that brings an existing system's data into TAK without any new app at all. Our TAK integration work often starts here.
- A plugin first, an app later. Start with the users who need it most on the map, then widen the audience.
Questions that settle the decision
Before choosing, get clear answers to these:
- Who are the users, and do all of them carry ATAK today?
- Which devices do they use: Android only, or iOS as well?
- Where does the work happen: on the shared map, or in a workflow of its own?
- Who needs to see the results, and do they need to appear on the TAK map?
- Which ATAK builds are involved, CIV, MIL or both, if a plugin is on the table?
- How will it be distributed and supported, and how often will it change?
Start from the user and the mission. The right platform follows from there.
We build both, so we can recommend the one that fits rather than the one we happen to make. See our ATAK plugin development and mobile development pages, or start with What is ATAK? if the TAK ecosystem is new to you.
Talk to the engineers who wrote this guide.