OutSystems Mobile Developer Specialist common mistakes
OutSystems Mobile Developer Specialist · Understand the traps and how to avoid them.
Treating a Screen's local variables and aggregates as if they persist when the user navigates away, then wondering why data resets on return.
Candidates carry over server-side web mental models where session state survives navigation. In OutSystems mobile apps, screen state is destroyed on navigation unless explicitly preserved, so local variables are re-initialised each time the screen loads.
What to do instead
Learn the difference between Screen scope, Client Variables, and Session Variables. Use Client Variables or a local storage entity for values that must survive navigation, and re-run the preparation/aggregate on every screen entry rather than assuming cached values remain.
Designing offline-first flows that call a server action directly from the UI and assume it works without connectivity.
The exam tests understanding of the offline sync model. Server Actions and server-side aggregates fail or return stale data offline; only client actions and local entities work. Candidates who prototype with connectivity always on miss this.
What to do instead
Structure the app so reads/writes go to local entities first, then sync via the built-in sync mechanisms or explicit server calls triggered when online. Identify which data must be local and model those entities accordingly.
Placing business logic in the Screen's Preparation or OnReady and then trying to reuse it across screens.
Screen-level logic feels convenient during rapid prototyping, but it cannot be reused and bloats screens. Candidates underestimate how much of the exam focuses on proper layering (actions in modules, not screens).
What to do instead
Move reusable logic into Server Actions or Client Actions in the module, keep screens thin, and reserve Preparation for orchestrating data fetch. Practise refactoring a screen-heavy design into action-based layers.
Ignoring the distinction between Client Actions and Server Actions when choosing where to implement a feature.
Both look similar in Service Studio, and the performance/offline implications are not obvious from the editor. Candidates pick whichever is faster to wire up and then fail questions on execution context.
What to do instead
Memorise the rules: Client Actions run on the device (offline-capable, no server entities/aggregates), Server Actions run on the server (full data access, require connectivity). For each feature, decide the execution context first, then pick the action type.
Assuming a mobile app automatically refreshes its data when the underlying server data changes.
Candidates expect web-like live data. Mobile apps cache locally, so changes made elsewhere are invisible until a sync or explicit refresh occurs, which trips up questions about data freshness and sync triggers.
What to do instead
Know the sync triggers (on login, on app foreground, manual pull-to-refresh, scheduled) and how to configure them. Design UI that surfaces last-sync time and offers explicit refresh where freshness matters.
Building screens without accounting for device variability - screen sizes, orientation, and platform differences - and then answering layout questions as if one design fits all.
Service Studio previews look uniform, so candidates forget that mobile UIs must adapt across devices and OS conventions. Exam questions probe responsive layout and platform-specific behaviour.
What to do instead
Use the responsive layout tools (columns, containers, screen-size breakpoints) and test in the device simulator/preview across sizes. Learn which widgets and patterns are platform-adaptive versus fixed.
Mishandling the app lifecycle - backgrounding, resuming, and logout - so that sensitive data or stale state leaks between sessions.
Lifecycle events are easy to overlook in a demo, and candidates do not connect them to security and data-freshness requirements. Questions on session handling expose this gap.
What to do instead
Study the lifecycle events available and where to hook logic (on resume, on foreground, on logout). Clear client-side sensitive data on logout, re-validate session on resume, and re-sync where required.
Confusing local storage entities with server entities and expecting local data to be queryable with server-side aggregates.
The entity model looks the same in the editor, but local storage entities behave differently - they are device-scoped and use client-side querying. Candidates who treat them as identical fail data-access questions.
What to do instead
Learn which aggregate/query features are available client-side versus server-side, and model relationships accordingly. Use server aggregates only in server context; use client-side data access for local entities.
Neglecting error handling and offline failure paths - no handling for sync conflicts, timeouts, or failed server calls.
Happy-path development dominates practice, and the exam deliberately tests resilience scenarios. Candidates who never design failure paths cannot answer questions about sync conflicts or retry behaviour.
What to do instead
For every server call and sync operation, define the failure behaviour: user feedback, retry, queueing, or conflict resolution. Practise designing a sync-conflict scenario end to end.
Treating security as a server-only concern and leaving role checks, input validation, and sensitive-data handling out of the mobile client design.
Candidates assume the server enforces everything, but mobile clients expose data locally and can be tampered with. Exam questions test defence-in-depth thinking for mobile.
What to do instead
Apply role-based checks at both client and server, validate input on the client for UX and on the server for trust, avoid storing secrets on-device, and encrypt or clear sensitive local data. Review the security checklist for mobile apps before the exam.