AdaptForge: Adaptive MDE for Flutter Apps

• AdaptForge is a model-driven engineering and low-code platform that enables scalable creation of adaptive Flutter applications tailored for seniors.
• It uses domain-specific languages for context and adaptation modeling, coupled with a transformation pipeline that automates source-code level modifications.
• Empirical evaluations show high developer acceptance and improved end-user experiences, addressing both regulatory compliance and diverse accessibility needs.

AdaptForge is a model-driven engineering (MDE) toolchain and low-code platform that enables systematic, large-scale creation of accessible and adaptive Flutter-based applications for senior users. Designed in direct response to the persistent accessibility and personalization barriers in mainstream software for older adults, it provides developers with domain-specific languages (DSLs) and a transformation pipeline to automate the adaptation of mobile user interfaces and behaviors at the source-code level. AdaptForge operationalizes accessibility as a first-class software concern driven by both regulatory and end-user needs, aiming to bridge the gap between general-purpose app development and population-tailored UX requirements (Wickramathilaka et al., 5 Aug 2025, Wickramathilaka et al., 26 Feb 2025).

1. Background and Motivation

The global increase in senior users with diverse aging-related declines—including vision, hearing, cognition, and mobility—exposes marked inadequacies in conventional app design, which tends to deliver “one-size-fits-all” UIs with limited personalization. Regulatory frameworks such as the European Accessibility Act (EAA) intensify pressure on developers to deliver compliance and individualized support, yet high manual implementation cost and complexity have impeded broad adoption. OS-level adaptations (e.g., font scaling, high-contrast themes) provide only partial relief and may often compromise app layouts. AdaptForge was introduced to offer a practical, low-friction mechanism allowing developers to define, manage, and apply accessibility and personalization adaptations systematically and efficiently at scale (Wickramathilaka et al., 5 Aug 2025, Wickramathilaka et al., 26 Feb 2025).

2. Architecture and Model-Driven Workflow

AdaptForge is architected around an MDE paradigm comprising three primary subsystems: a Context DSL editor, an Adaptation DSL editor, and a model-to-code generation engine targeting Flutter source. The pipeline is executed as follows:

1. Persona Instantiation: Developers define “personas” via the Context DSL metamodel, capturing user, platform, and environment as structured tuples.
2. Conditional Adaptation Modeling: The Adaptation DSL encodes rules as conditional mappings (“IF <ContextCondition> THEN <AdaptationOperations>”), referencing context nodes.
3. Widget Annotation: Base Flutter applications are annotated with unique Keys to ensure unambiguous adaptation targeting.
4. Transformation Pipeline: The combined models and source code are inputs to a code generation engine (Acceleo, Xpand). Adaptation rules are traversed and materialized as Dart code changes—yielding tailored app variants per persona or user group.
5. Output and Deployment: The result is a set of Flutter codebases ready for compilation and deployment, each optimized for distinct end-user contexts.

The end-to-end transformation can be formally described as $T: M \rightarrow C$, where $M = M_\text{ctx} \cup M_\text{adapt}$ encapsulates the full model specification and $C$ is the adapted code artifact. For $k$ adaptation rules $r_1,…,r_k$, the total transformation is $T(M) = \bigcup_{i=1}^k r_i(M, C_{\text{base}})$ (Wickramathilaka et al., 5 Aug 2025, Wickramathilaka et al., 26 Feb 2025).

Subsystem	Input	Output
Context DSL Editor	User/platform/env.	M_ctx model
Adaptation DSL Editor	Conditional rules	M_adapt model
Model-to-Code Generator	M_ctx, M_adapt, code	Adapted Flutter variant

The architecture supports extension to group-level or domain-agnostic adaptations, with dynamic placeholders to minimize code duplication (Wickramathilaka et al., 5 Aug 2025).

3. Domain-Specific Languages and Formal Models

Context DSL: Implements a metamodel representing context as a 3-tuple—user (age, impairment, preferences), platform (deviceType, screen), and environment (ambientLight, noise)—expressed in a tree-node hierarchy. For instance:

CarlJamesonPersona { userContext { age = 77; visionImpairment { type = "MacularDegeneration"; severity = "moderate"; } } platformContext { deviceName = "iPhone11"; screen.width = 375; screen.height = 812; } environmentContext { ambientLight = "low"; noiseLevel = "medium"; } }

Adaptation DSL: Encodes adaptation rules as JSON-style or object-based specifications, each comprising a condition (Boolean predicate over context), a widget target selector (by key/type), and a set of operations (property=value pairs). Example:

{ "ruleName": "LargeFontForLowVision", "wcagReference": "WCAG 1.4.4", "when": "context.userContext.visionImpairment.type == 'MacularDegeneration' && context.userContext.age > 70", "widgets": [ { "key": "*", "type": "Text" } ], "operations": [ { "property": "fontSize", "value": 24, "comment": "Increase font for readability" }, { "property": "fontWeight", "value": "bold" } ] }

These DSLs enable interactive, model-centric editing with real-time metamodel validation and explicit referencing of relevant accessibility standards (e.g., WCAG) (Wickramathilaka et al., 5 Aug 2025, Wickramathilaka et al., 26 Feb 2025).

4. Adaptation, Transformation, and Integration Techniques

AdaptForge’s transformation engine systematically parses context and adaptation models, locates corresponding widgets in the annotated Flutter abstract syntax tree, and rewrites or injects Dart code to apply the specified adaptations. Supported adaptation types include:

• Presentation (e.g., increased font size, bolder colors)
• Multi-modality (e.g., text-to-speech TTS, speech-to-text STT interface components)
• Navigation (e.g., splitting multi-step forms into wizard-style flows)

Each adaptation rule $r_i$ is a function mapping $$(\text{Condition}_i, \text{Operations}_i, C_\text{base}) \rightarrow C'_i$$. For instance, a rule increasing font size and boldness for vision-impaired users produces the required Dart code transformation, with inline comments referencing the governing WCAG clause.

Developers incorporate key: Key("<unique-id>") into Flutter widgets for precise targeting, and the generated code remains pure Dart/Flutter with no additional runtime library dependencies. This allows for seamless integration with standard CI/CD, QA, and code review pipelines (Wickramathilaka et al., 26 Feb 2025).

5. Empirical Evaluation: Developer and End-User Studies

A qualitative evaluation conducted with 18 professional Flutter developers and 22 senior end-users provides empirical validation:

• Developer Evaluation: Participants viewed demonstrations covering persona modeling, adaptation rule authoring, and complex adaptation scenarios. Findings indicate that 17/18 developers found the DSLs intuitive; 16/18 would integrate AdaptForge into their workflows. Perceived benefits included major reductions in repetitive adaptation effort, clear separation of roles (modeling vs. coding), and enhanced maintainability. Key limitations cited were the DSL learning curve, added cognitive load for numerous rules, and challenges with code interleaving and QA practices. Mitigations proposed include templates, guided examples, and leveraging OTA (over-the-air) patch services for app updates (Wickramathilaka et al., 5 Aug 2025, Wickramathilaka et al., 26 Feb 2025).
• Senior End-User Evaluation: Conducted across three focus groups (N=22), adaptations were tested on a reference Flutter app. All groups preferred higher-contrast, larger, bolder fonts; navigational adaptations (wizard-style forms) reduced cognitive load; and multi-modality features were generally welcomed with some situational reservations. Feedback was qualitatively positive for all adaptation categories (Wickramathilaka et al., 26 Feb 2025).

6. Design Recommendations and Best Practices

AdaptForge’s evaluative research distills nine design principles for industrial low-code accessibility tools:

1. Treat accessibility and personalization as first-class model constructs.
2. Minimize context-data onboarding friction—support profile import and group-level modeling.
3. Match DSL syntax to developer expectation (tree views, JSON objects, optional graphical sync).
4. Ensure DSL/domain extensibility beyond seniors.
5. Mandate and auto-inject inline metadata (WCAG/ISO links).
6. Provide context-aware modeling advisors and rule templates.
7. Prefer user-group adaptations over per-user divergence; use dynamic runtime injection to reduce codebase bloat.
8. Use remote/OTA update-friendly code generation to navigate app-store latency and bundle size limits.
9. Engineer artifact compatibility with automated QA; provide sandbox/preview modes (Wickramathilaka et al., 5 Aug 2025).

7. Limitations and Future Directions

Current AdaptForge implementations are Flutter-specific; adapting the platform for React/Angular ecosystems requires significant DSL and transformation pipeline refactoring. All adaptations are design-time; no run-time (user-triggered, dynamic) adaptation is currently supported. The pipeline’s rigidity may complicate round-trip model/code edits. Future technical directions identified include:

• Abstracting Adapt DSL for multi-framework support
• Adding run-time or LLM-driven personalization
• Integrating context-profiling and privacy dimensions
• Backend or API-driven adaptation logic to optimize client code size
• Formalizing “Accessibility Profile Services” for persistent cross-app user settings (Wickramathilaka et al., 26 Feb 2025).

A plausible implication is that integration with OTA update frameworks may become an indispensable requirement for personalized accessibility at scale, especially as regulatory landscapes evolve.

---

For further foundational models, evaluation metrics, and taxonomy details underlying AdaptForge, see (Wickramathilaka et al., 5 Aug 2025) and (Wickramathilaka et al., 26 Feb 2025).