QField Feature Requests

I really would like to be able to search for features which consist of less then 3 letters.

What is the problem you are trying to solve? In QField, multi-select Value Relation dropdowns successfully display and group checked items when reviewing a previously saved/plotted feature. However, this behavior breaks when creating a brand-new feature while utilizing the "Remember Last Value" pin. When a field worker creates a new feature, the data carried over from the previous feature is active in the background cache, but QField treats the new record as completely blank visually. The carried-over items remain scattered throughout long lookup lists (e.g., a list of mixed species in forestry or biodiversity monitoring). Users are forced to scroll extensively through the entire list just to see what data has carried over or is already checked. In mixed environments (like woodlands containing a combination of conifer, broadleaf, native, and non-native trees simultaneously), splitting the data into cascading parent/child dropdowns isn't a viable workaround. What is your proposed solution? Update the user interface behavior within multi-select lookups so that carried-over data from the "Remember Last Value" cache is treated identically to pre-existing row data. When a new feature form opens, these active selections should automatically pin to the absolute top of the list view. This enhancement should: • Create a visual partition on new features: Group all carried-over/active selections at the very top of the widget immediately upon form creation, with the remaining unchecked options listed cleanly below them. • Preserve project sorting: Maintain the project's underlying sort order (such as alphabetical order or custom priority columns configured in QGIS Desktop) within those two separate blocks. • Update dynamically: Refresh the list order cleanly every time the dropdown widget is tapped open. What is the value of this feature? This fixes a major UX consistency gap between editing old features and creating new ones. It aligns QField with modern mobile UX standards, dramatically reduces form scrolling during rapid data collection, and eliminates critical data validation errors caused by carried-over selections being hidden deep within large lookup datasets.

Currently, QField appears unable to load GeoParquet layers packaged from QGIS projects. After syncing a project containing GeoParquet layers, those layers fail to load on the mobile app without diagnostic detail, even though they function correctly in QGIS Desktop. Adding at least read-only support for GeoParquet would be highly valuable for mobile workflows focused on visualization and situational awareness (e.g. safety maps, transit analysis, environmental context), where editing is not required. GeoParquet offers several advantages that are especially relevant on mobile devices: • Efficient columnar storage and fast spatial reads • Smaller file sizes compared to Shapefile / GeoPackage for large datasets • Increasing adoption across the geospatial ecosystem (QGIS, GDAL, DuckDB, GeoPandas) GeoParquet supports both WKB and GeoArrow geometry encodings. Supporting either would be useful, but GeoArrow in particular could enable significant performance and memory improvements on mobile due to zero-copy access patterns.

Is it possible to add audible alarms for Geofencing breaches? Currently just has a visual indicator some alarms would be nice for noisy machinery.

As a developer, I want to maximise the space available to design and customise forms. When using smaller screens and larger font sizes, the intended design can be altered, with detrimental UX. For example, the 'pin'/'calendar'/etc icons can occupy a large proportion of the width of the screen. It would be good to have the ability to scale these and adjust the padding between them. Perhaps even the ability to turn these buttons on and off per field within QGIS. Similarly, I would occasionally prefer an array of radio buttons to appear on the same row, rather than wrap onto the next row. This could be acheived if the height of the buttons could be scaled, but this is not possible. The following abilities would also be most welcome: adjust the padding between rows and columns and add gridlines between them; for checkboxes, show the label (or nothing if label is enabled) instead of 'True' or 'False' (the grey/green toggle switch is sufficient user feedback); per field, a tooltip popup when hovering over a field in a form

First of all, thank you to the QField team for the incredible work. QField + QFieldCloud is an extremely powerful tool, and it has significantly improved how we handle field data collection and synchronization workflows. I’d like to share some feedback based on real-world usage with field teams, specifically regarding the synchronization interface (Synchronize / Push changes / Revert local changes). ### Context One of the biggest challenges we face is not technical — it’s usability in the field. Operators often struggle to understand the difference between: * Synchronize * Push changes * Revert local changes These actions are critical and potentially destructive, yet they are presented at the same level in the UI. This creates a high risk of accidental data loss, especially for non-technical users working under field conditions (limited connectivity, time pressure, fatigue). ### Key Suggestions #### 1. Reduce exposure of destructive actions “Revert local changes” is a highly destructive operation, but it is visually presented alongside routine actions. Recommendation: * Move it into a “Danger zone” or “More actions” section * Rename to something clearer like: “Discard unsynced local edits” This would better communicate the real impact of the action. --- #### 2. Introduce a single primary action Most users don’t need to choose between multiple sync strategies. Recommendation: * Provide a single primary button like: “Sync now” * Internally handle: * Upload of local changes * Download of remote updates Advanced options (like “push only”) could remain available but hidden under an “Advanced” section. --- #### 3. Show a clear summary before actions Users should understand what will happen before they click anything. Example: * Local changes: 1 edited feature * Remote updates: 2 features available * Conflicts: none detected This would dramatically reduce confusion and increase confidence. --- #### 4. Improve confirmation dialogs for destructive actions Instead of generic confirmations, provide contextual warnings. Example: “You are about to permanently delete: * 1 edited feature * 2 photos These changes have not been uploaded to QFieldCloud.” This makes the consequence explicit. --- #### 5. Add basic recovery mechanisms Currently, reverting local changes is irreversible. Even a minimal safeguard would help: * Local snapshot before discard * Temporary undo * Local edit history This would significantly increase trust in the system. --- #### 6. Improve terminology Some labels are technically correct but not intuitive for field users. Suggested improvements: * “Synchronize” → “Sync (upload & download)” * “Push changes” → “Upload local edits only” * “Revert local changes” → “Discard unsynced edits” --- #### 7. Improve visual hierarchy Group actions by risk level: Primary * Sync now Advanced * Upload local edits only Danger zone * Discard unsynced edits --- ### Final Thought The current system is technically solid, but the UI assumes a level of understanding that many field users simply don’t have. In practice, the main issue is not how synchronization works — it’s how clearly the consequences of each action are communicated. Improving this flow would greatly reduce training overhead, prevent data loss, and make QField even more robust for real-world field operations. Thanks again for the amazing work and for maintaining such a valuable open-source project.

• I would like them to try if it were possible to capture raw data at least from the cell phone (hopefully from an RTK station for example), and it is of interest to me since I see cellular devices even with double frequency. • I believe that an important step of the existing ecosystem is to be able to take that raw data and post-process it with an open tool, which as far as I know does not exist. I would think it would apply as a plugin for QGIS, but I think it would be beneficial on all levels. • That the connection to an NTRIP service could be configured from the same application.