Flutter Dart

Yes—Flutter/Dart could be useful later for the iPhone and Android apps, but I would not use Flutter as the primary technology for customizing the MediaWiki web application.

The strongest architecture is:

MediaWiki remains the core platform and system of record
        ↓
MediaWiki skin and extensions provide the web experience
        ↓
MediaWiki APIs expose application functionality
        ↓
Flutter provides an optional iOS/Android client

For the web application: stay native to MediaWiki

For the web version, align closely with standard MediaWiki development practices:

• PHP for extensions, business logic, hooks, permissions, special pages, and server-side features
• JavaScript for interactive browser behavior
• CSS/LESS and a MediaWiki skin for visual customization
• extension.json and skin.json for standard extension registration

MediaWiki explicitly supports customization through skins and extensions. Its documentation notes that skins control appearance, while extensions customize how MediaWiki works. Basic skin work can be done largely with CSS, JavaScript, and JSON; PHP becomes useful for more advanced behavior. (MediaWiki)

That approach gives GoalStriving several advantages:

• MediaWiki developers can understand and contribute to it.
• Your code can potentially be distributed as conventional MediaWiki extensions or skins.
• You can reuse standard authentication, permissions, page history, templates, categories, notifications, and extension hooks.
• MediaWiki upgrades will be easier than if you replace the normal interface with an unrelated frontend framework.

I would avoid building the web version itself in Flutter Web. Technically Flutter supports web deployment, but it would make GoalStriving feel less like a native MediaWiki project and could complicate accessibility, search indexing, browser behavior, extension compatibility, and community contribution. Flutter’s cross-platform capability is real, but its strongest role here is as a separate mobile client. (Flutter Docs)

For mobile: Flutter is a reasonable choice

Once the MediaWiki web application and its data model are stable, Flutter could provide one shared codebase for:

• iPhone
• Android
• potentially desktop apps later

Flutter officially supports mobile, web, and desktop deployment from a shared Dart codebase. (Flutter Docs)

A GoalStriving mobile app could offer a more focused experience than the full wiki interface:

• View goals and current priorities
• Add progress updates
• Complete daily or weekly check-ins
• Receive reminders
• Record journal entries
• Upload photographs
• Work offline and synchronize later
• Display dashboards and progress charts
• Use mobile notifications and biometric authentication

The app would communicate with MediaWiki rather than replace it.

MediaWiki should remain the backend

MediaWiki provides both an Action API and a REST API. The Action API currently offers broader functionality, while the REST API provides newer, more structured HTTP endpoints. Extensions can also register their own REST endpoints. (MediaWiki)

For GoalStriving, you may eventually create API endpoints such as:

GET  /goalstriving/v1/goals
GET  /goalstriving/v1/goals/{id}
POST /goalstriving/v1/goals
POST /goalstriving/v1/checkins
GET  /goalstriving/v1/dashboard

Those endpoints could be supplied by a normal MediaWiki PHP extension. The Flutter app would consume them using JSON.

This separation is valuable:

MediaWiki extension
- Defines goals
- Enforces permissions
- Stores or retrieves information
- Implements workflow rules
- Exposes REST endpoints

Flutter app
- Presents the mobile interface
- Handles navigation
- Stores temporary offline data
- Calls MediaWiki APIs
- Uses phone-specific features

Important design decision: pages versus structured records

Before building the mobile app, determine how GoalStriving data will be represented.

You might store goals as:

1. Ordinary wiki pages with templates
2. Semantic MediaWiki properties
3. Cargo records
4. Custom MediaWiki database tables
5. A hybrid of pages and structured records

For community alignment, a hybrid is likely strongest:

• Human-readable wiki pages remain the durable content.
• Templates, Semantic MediaWiki, or Cargo provide structured fields.
• A GoalStriving extension provides workflow and API functionality.
• Flutter consumes the structured representation.

For example:

Goal page
├── Title
├── Description
├── Owner
├── Status
├── Target date
├── Motivational priority
├── Progress entries
└── Related goals

The same information could be edited through:

• standard MediaWiki forms,
• a customized web interface,
• or the Flutter mobile app.

How to remain aligned with the MediaWiki community

I would follow several principles.

Build standard extensions rather than modifying MediaWiki core

Do not directly edit core MediaWiki PHP files. Put GoalStriving functionality into independently installable extensions and skins. MediaWiki’s supported customization model is explicitly based on extension points, hooks, extensions, skins, gadgets, and APIs. (MediaWiki)

Keep the normal wiki usable

The project should still work through a browser without the Flutter app. Mobile users who do not install the app should be able to use a responsive MediaWiki interface.

Use open standards and documented APIs

Prefer:

• MediaWiki REST endpoints
• Action API where necessary
• OAuth or another supported authentication approach
• JSON
• standard MediaWiki page and revision concepts

Open-source the MediaWiki components

A clearly separated collection could be appealing to the community:

GoalStriving extension
GoalStriving skin or skin customization
GoalStriving templates
GoalStriving Page Forms
GoalStriving mobile app

Someone might adopt only the extension or templates without using the mobile app.

Treat Flutter as a client, not the platform

This distinction will help community acceptance. GoalStriving would remain a MediaWiki application that happens to offer a Flutter mobile client—not a Flutter product that merely uses MediaWiki as an incidental database.

Recommended development roadmap

Phase 1: Define the MediaWiki data model

Decide how these concepts are represented:

• goals
• projects
• progress updates
• habits
• motivational priorities
• users and groups
• privacy
• relationships among goals

Phase 2: Build the web experience natively

Use:

PHP MediaWiki extension
JavaScript
CSS/LESS
MediaWiki skin or skin customization
Page Forms / Semantic MediaWiki / Cargo as appropriate

Phase 3: Create an API boundary

Do not let the future app depend on scraping HTML pages. Expose stable structured API responses from the GoalStriving extension.

Phase 4: Build a small Flutter proof of concept

Start with only:

• login
• list goals
• view one goal
• add progress update

This will expose any weaknesses in the API and data model before you build the full app.

Phase 5: Add mobile-specific value

Add features that justify installing an app:

• notifications
• offline access
• quick check-ins
• camera uploads
• widgets
• biometric login
• calendar integration

My recommendation

Use this technology allocation:

Layer	Recommended technology
Core platform	MediaWiki
Server-side customization	PHP extension
Web UI behavior	JavaScript
Web appearance	MediaWiki skin, CSS/LESS
Structured data	Semantic MediaWiki, Cargo, custom tables, or hybrid
API	MediaWiki REST API plus extension-specific endpoints
iOS/Android	Flutter/Dart
Authentication	MediaWiki-compatible OAuth/session approach

Flutter is therefore a good potential fit, but only after the MediaWiki application, data model, and API are stable. Your immediate learning investment should probably remain PHP, MediaWiki extension architecture, JavaScript, and MediaWiki APIs. Dart becomes worthwhile when the mobile client becomes an active development phase.