ArcGIS Web AppBuilder is an Esri tool for building configurable web mapping applications without writing code. You assemble an app from a map, a theme, and a set of widgets such as search, query, and print. It runs in both ArcGIS Online and ArcGIS Enterprise, and it is the predecessor to ArcGIS Experience Builder, which Esri now positions as the path forward.
If your organization already runs apps built in Web AppBuilder, or you are deciding which app builder to standardize on, this guide explains what the tool does, how its widgets work, where it fits among Esri’s app-building options, and when Experience Builder is the better choice. The goal is a clear, practical picture so you can plan rather than guess.
What ArcGIS Web AppBuilder is
Web AppBuilder lets you create focused web apps around a single web map or web scene. You start from a feature service or hosted layer, choose a theme that controls layout and color, and add widgets that give users specific capabilities. Because it produces standard web apps, the result works across desktop and mobile browsers.
It comes in two flavors. The first is the version built into ArcGIS Online and ArcGIS Enterprise, which runs entirely in the browser. The second is Web AppBuilder for ArcGIS (Developer Edition), which you host yourself and which allows custom widgets and themes. Most organizations use the built-in version because it requires no servers of their own.
How widgets work
Widgets are the building blocks of a Web AppBuilder app. Each widget adds one capability, and you configure it against your data. The most used widgets include the following.
- Search: lets users find features or addresses, configured against a feature service or a geocoding service.
- Query: returns features that meet criteria you define, for example parcels over a certain size.
- Filter: narrows what is visible on the map by attribute values.
- Edit: allows users to update a feature service directly, subject to the layer’s editing settings.
- Print: produces a layout-ready map using a print service.
- Attribute Table: shows the records behind the map in a sortable grid.
Widgets fall into two groups. In-panel widgets open inside the app’s side panel, and off-panel widgets sit on the map as icons. You decide which widgets load when the app opens and which the user activates on demand. Thoughtful widget selection keeps an app fast and easy to use, because every widget you add is one more thing a user has to understand.
Web AppBuilder and the Esri app-building family
Esri offers several ways to build apps without custom code, and Web AppBuilder is one of them. Leading with the cloud-first option, here is how the main tools relate.
| Tool | Best for | Coding required | Status |
|---|---|---|---|
| Instant Apps | Quick, focused apps from a template | None | Current |
| ArcGIS Experience Builder | Flexible, multi-page apps and full layout control | None (optional developer edition) | Current, recommended path forward |
| ArcGIS Web AppBuilder | Widget-driven single-map apps | None (optional developer edition) | Mature, succeeded by Experience Builder |
| ArcGIS Dashboards | Operational monitoring with charts and indicators | None | Current |
All of these are out-of-the-box configuration tools, not custom development. That distinction matters for cost and maintenance. A configured app stays supportable by your own staff, while a custom-coded app ties you to whoever wrote it. For a closer look at the flexible successor, see our guide on when to use ArcGIS Experience Builder and what it does.
When to use Web AppBuilder today
Web AppBuilder remains a capable tool, and many production apps still run on it. It is a reasonable choice in these situations.
- You already maintain Web AppBuilder apps. If they meet user needs, there is no urgency to rebuild them simply because a newer tool exists.
- You need a single-map app with familiar widgets. For a straightforward viewer with search, query, and print, Web AppBuilder is quick to configure.
- Your team knows the widget model well. Existing in-house skill has real value and reduces delivery time.
When Experience Builder is the better choice
Esri has made ArcGIS Experience Builder the recommended app-building tool, and for new projects it is usually the stronger option. Consider Experience Builder when:
- You need more than one page or panel. Experience Builder supports multi-page apps and far more layout freedom.
- You want full control over design. You can place widgets anywhere on a flexible canvas rather than within a fixed theme.
- You are building for the long term. New capabilities are landing in Experience Builder, so a new app there has a longer runway.
Moving from one to the other is a configuration project, not a data migration, because both tools sit on top of the same web maps and feature services. A planned rebuild can often reuse your existing layers and symbology with little rework.
Practical tips for reliable apps
A few habits keep configured apps healthy regardless of which builder you choose.
- Start from a well-built web map. The app inherits the map’s layers, pop-ups, and symbology, so time spent on the map pays off in the app.
- Set feature service editing carefully. If you enable the Edit widget, confirm the layer’s editing settings and consider using attribute rules to protect data quality.
- Limit widgets to what users need. Fewer, well-chosen widgets make an app easier to learn.
- Test on mobile. Field users often open these apps on phones, so verify the layout works on small screens.
Done well, an app-building project is one of the highest-value, lowest-risk things a GIS team can ship, because it puts spatial data in front of the people who need it. For a broader view of underused platform capabilities, see our list of ArcGIS features most organizations never use but should.
Getting help with app development
App configuration looks simple in a demo and gets nuanced in production, especially around editing permissions, performance with large feature services, and a clean migration path to Experience Builder. GeoLever’s ArcGIS platform consulting (GeoConsult, $5,000 to $15,000 per project) covers exactly this kind of work, delivered by a Certified ArcGIS Expert. You can scope a project through the GeoLever contact page.
Configuring a Web AppBuilder app, step by step
Seeing the workflow end to end makes the tool concrete. A standard configuration in the built-in version follows a predictable sequence.
- Prepare the web map. Author the map in ArcGIS Online or ArcGIS Pro, set layer symbology, configure pop-ups, and confirm the feature services behave the way you want. The app inherits all of this.
- Create the app and pick a theme. Start a new Web AppBuilder app from the map, then choose a theme that sets the layout and color scheme.
- Add and configure widgets. Drop in the widgets users need, such as Search, Query, Filter, and Print, and configure each against your layers.
- Set which widgets open on start. Decide what loads immediately and what users activate on demand, keeping the initial view clean.
- Configure attributes and pop-ups. Confirm that the fields shown to users are the ones that matter, using field aliases for clarity.
- Test and share. Test on desktop and mobile, then share the app with the right groups in your organization.
None of these steps require code, which is the point. The skill is in choosing the right widgets and configuring them cleanly, not in programming.
Common Web AppBuilder mistakes to avoid
Most problems with configured apps trace back to a handful of avoidable choices.
- Too many widgets. Loading every available widget overwhelms users and slows the app. Add only what the task needs.
- Heavy layers with no scale limits. Drawing very large feature services at every zoom level hurts performance. Set visible scale ranges and consider hosted feature layer views.
- Unprotected editing. Enabling the Edit widget without reviewing the feature service editing settings or applying attribute rules invites bad data. Decide who can edit what before you turn it on.
- Skipping mobile testing. Field users open these apps on phones. An app that looks fine on a monitor can be unusable on a small screen.
- Ignoring the migration path. Building a brand-new app in Web AppBuilder today means a likely rebuild in Experience Builder later. For new work, weigh that cost up front.
Avoiding these keeps an app fast, accurate, and easy to maintain, which is what turns a map into a tool people actually use.
Frequently Asked Questions
Is ArcGIS Web AppBuilder being retired?
Esri has made ArcGIS Experience Builder the recommended app-building tool and the path forward. Web AppBuilder remains available and supported for existing apps, but new projects are generally better built in Experience Builder, which offers more layout flexibility and ongoing feature development.
Do I need to know how to code to use Web AppBuilder?
No. The built-in version in ArcGIS Online and ArcGIS Enterprise is fully configuration-based. Coding is only relevant if you use the separate Developer Edition to build custom widgets or themes, which most organizations do not need.
What is the difference between Web AppBuilder and Experience Builder?
Web AppBuilder builds single-map apps from a fixed theme and a set of widgets. Experience Builder supports multi-page apps and a flexible canvas where you place widgets anywhere. Experience Builder is the newer, recommended tool, while Web AppBuilder is mature and widely deployed.
Can I move my Web AppBuilder apps to Experience Builder?
Yes. Because both tools sit on the same web maps and feature services, moving is a configuration rebuild rather than a data migration. You can often reuse your existing layers, pop-ups, and symbology, which keeps the effort focused on layout and widgets.
Does Web AppBuilder work with ArcGIS Enterprise?
Yes. Web AppBuilder is available in both ArcGIS Online and ArcGIS Enterprise. The built-in versions work the same way in each, so the apps you configure behave consistently across both deployment models.
