OutSystems Mobile Developer Specialist cheat sheet

OutSystems builds native mobile apps only for iOS and Android; a single mobile module generates platform-specific native UI, not a WebView wrapper.

Mobile modules run on the device; server-side logic executes on the OutSystems platform and is reached through exposed REST APIs generated from server actions.

Three module types matter: Reactive Web (browser), Mobile (native app), and Service (logic/API only); a Mobile module cannot be consumed as a screen target by a Reactive Web module.

Offline capability is enabled per module (Offline mode) and requires local entities; without it, screens depend on a live network connection.

Mobile apps use the OutSystems UI Mobile framework; screen templates and patterns (Bottom Bar, List, Detail) differ from Reactive Web equivalents.

Client-side logic runs in JavaScript on the device; Server Actions can only be called from client actions, never directly from screen expressions.

The app must be generated and installed through a native shell (OutSystems App) or a distributed build (MABS); previewing in a browser does not reflect native behavior.

Data-intensive mobile screens should use aggregates on the server and local storage on the device; mixing both requires explicit synchronization design.

Offline modules store data in a local SQLite database on the device; entities marked as offline-capable are replicated, others are not.

The synchronization model is defined per entity: Read Only, Create, Update, Delete, or Read/Write, controlling which local changes are sent to the server.

Sync is triggered by the SyncOnStartup setting, the Sync action, or the built-in sync manager; conflicts are resolved by the platform using last-write-wins unless custom logic is added.

Local entity identifiers are temporary; server-assigned IDs are reconciled after sync, so client logic must not assume stable IDs before synchronization completes.

Images and binary data in offline apps are stored as local files; large binaries increase sync payload and should be minimized.

The SyncManager exposes status (syncing, offline, error) via the SyncStatus system; screens should react to it to disable actions while offline.

Offline data is scoped per user login; logging out clears local data unless explicitly preserved, which affects multi-user device scenarios.

Testing offline behavior requires a real device or emulator with network toggled; the Service Studio preview does not simulate offline storage.

Mobile screens use blocks and screen templates from OutSystems UI Mobile; layouts are column-based with responsive breakpoints for phones and tablets.

Navigation patterns: Bottom Bar for top-level destinations, Tabs for related views, Stack navigation for drill-down; the back stack is managed by the platform.

Lists should use the List pattern with lazy loading; rendering large lists without pagination degrades native performance.

Screen lifecycle events (OnInitialize, OnReady, OnRender, OnDestroy) run on the device; heavy logic in OnRender causes frame drops.

Local storage variables and session variables differ: local storage persists across sessions on the device, session variables are in-memory.

Accessibility requires semantic roles, labels, and sufficient contrast; native controls expose accessibility traits automatically when configured.

Platform-specific behavior (safe areas, status bar, keyboard avoidance) is handled by the OutSystems UI Mobile framework and must not be hard-coded.

Mobile apps are distributed as native binaries; the app must be signed with platform certificates (iOS provisioning profile, Android keystore) configured in the platform.

Authentication on mobile uses the platform's login flow; tokens are stored in secure storage on the device, not plain local storage.

Role-based access is enforced server-side via exposed REST APIs; client-side role checks are advisory and must be duplicated on the server.

HTTPS is mandatory for mobile API calls; certificate pinning can be enabled to reduce man-in-the-middle risk.

App updates are delivered through the store or the OutSystems App shell; OTA updates apply to the shell-hosted app without store resubmission.

Sensitive data in offline storage should be minimized; local databases are not encrypted by default, so avoid storing secrets.

Deployment requires configuring the mobile app build (icons, splash, permissions) in Service Center/Service Studio before generating the native package.

Service Studio preview runs the mobile app in a browser-like environment; native-only behaviors (camera, GPS, biometrics) require a device or emulator.

Remote debugging connects the device app to Service Studio; logs, breakpoints, and the debugger console stream from the device.

Performance bottlenecks on mobile are usually server round-trips; batch server calls and cache results in local storage.

Screen rendering cost increases with DOM depth; flatten block hierarchies and avoid nested lists.

Network latency dominates mobile UX; show loading states and use optimistic UI where appropriate.

The platform's monitoring console shows server-side errors and slow queries; device-side errors appear in the app logs accessible via the debugger.

Image assets should be sized for device density (1x/2x/3x) to avoid memory pressure on low-end devices.

Native device features (camera, GPS, contacts, biometrics) are accessed through plugins from the Forge; each plugin wraps platform APIs and must be added to the module dependencies.

Plugins expose client actions; they run on the device and may require permissions declared in the app manifest (e.g., camera, location).

Client variables persist per device and are not synchronized; use them for UI preferences, not business data.

JavaScript can be injected via the JavaScript element for custom behavior; it runs in the app's WebView context for hybrid parts.

Push notifications require configuring the notification provider (APNs/FCM) and registering the device token on the server.

Deep links allow external URLs to open specific screens; they are configured per module and must handle unauthenticated entry.

Background execution is limited by the OS; long-running tasks should be offloaded to server actions or scheduled jobs.