Mobile Structure

One solution gives every platform app one core to share, so a second platform reuses the domain model unchanged. Core projects under src/ separate shared code from the platform apps that consume it, and one app project per platform named {ProjectName}.{Platform} makes each platform's screens findable by name. A reader moves from the solution to a screen by rule rather than by search. This replaces the API solution path in litespec/workspace/structure#use-the-canonical-root-tree, because a client-only consumer has no API directory.

apps/mobile/
  {ProjectName}.Mobile.slnx
  src/
    {ProjectName}.Domain/
    {ProjectName}.Application/
    {ProjectName}.Infrastructure/
    {ProjectName}.Android/
  tests/
    {ProjectName}.Domain.Tests/
    {ProjectName}.Application.Tests/
    {ProjectName}.Android.Tests/

Framework-generated bin, obj, and publish folders remain untracked.

Reviewed forWhich mobile apps sit outside the one solution at apps/mobile/, or miss the core projects under src/ or the {ProjectName}.{Platform} app project? Look in the apps/mobile/ tree.

Marked guidance: a reviewer answers this question.

A product with no server carries its own domain model, so the app holds the Domain, Application, and Infrastructure projects that define it. A product with a server keeps its rules on the server, so the app holds a Client project with the generated API client and reaches every rule through that client rather than through a copy of the rules. A copied rule drifts from the server's rule on the first change, and the app then enforces a rule the server does not hold.

Reviewed forWhich client-only solutions miss a Domain, Application, or Infrastructure project, and which server solutions miss the Client project or hold a Domain copy? Look in the solution tree.

Marked guidance: a reviewer answers this question.

A core project that names a platform SDK type compiles only for that platform, so a second platform app copies the core instead of reusing it. Targeting plain .NET with no platform reference keeps the core compiling for every platform unchanged. Platform differences stay behind the interfaces Application owns, with the platform projects holding the adapters.

Reviewed forWhich core projects target a platform SDK or reference a platform SDK type? Look in the core project files and sources.

Marked guidance: a reviewer answers this question.

Screens grouped by module let a reader holding a module record find its screens by path, the way the frontend module mirror maps use cases to folders. A single-module product keeps its screens directly under Screens/, because one folder would add a level that distinguishes nothing. Use-case code reached from a screen lives in Application, so the screen folder holds the screen and the handler holds the behavior. This realizes litespec/frontend/structure#mirror-the-backend-use-case-path-in-kebab-case only as far as the screen path follows the module name.

Reviewed forWhich screens sit outside Screens/, or outside their module folder in a multi-module product? Look in the platform project tree.

Marked guidance: a reviewer answers this question.