When you build with Applin™, your app will have two parts:

  1. A frontend that fetches pages from the backend and displays them to the user. To make a frontend, copy an example app and change its name, icon, and server URL.
  2. A backend server that handles requests for pages and performs actions triggered by the user. To make a backend, use an HTTP server (like Ruby on Rails), import an Applin library, and add request handlers that process user-entered data and return page definitions.

Applin is like ReactNative without JavaScript.

Server-Driven UI

Applin is a Server-Driven User Interface (SDUI). This means that the server code defines app UI content, layout, and behavior.

Traditional app architecture: Traditional Architecture

Applin app architecture: Traditional Architecture

Benefits for you as an app maker:

  • Frontend code is eliminated. You need to learn, write, and maintain only the backend code. For example, you can use Rails to build and release an iOS app without help from an iOS developer.
  • When you deploy the backend, the frontend updates instantly.
    • You can delete old APIs right away, since there are no old versions of the app in use.
    • You can release features and fix bugs immediately, without waiting for app review.
    • When things go wrong, you can immediately roll back your app frontend & backend together.
  • Backend tests can exercise UI flows and backend code together. These run on normal test runners, not expensive macOS test runners.
  • Get support with GitHub Issues. You can easily find answers.
  • The source code is public. You can dig into the code and see how things work.
  • PRs are welcome! If you need a bug fixed ASAP, you can fix it and upstream your fix. No need to maintain a fork for more than one release.
  • To support a new version of iOS, just rebuild with the latest version of the Applin frontend.

Benefits for your users:

  • Users always have the latest version of the app.
  • The app starts and runs very fast.
  • It uses little battery power. Processing happens on the server.
  • It runs on the cheapest devices. The SDUI boilerplate uses little RAM and CPU.
  • The app downloads quickly and takes very little space on their device (1.2MB).


  • Custom UI elements are not easy to make in Applin.
  • Some bad UI designs are impossible to make in Applin. This is a benefit, depending on your perspective.
  • Applin is new. All new software has bugs.
  • Styling support is still under development.
  • The Android frontend is still under development.
  • The library of UI elements is still small.
  • Applin costs money.


When the frontend starts up, it makes an HTTP request to the server for the home page. It expects to get a JSON response with content-type application/vnd.applin_response. It parses the response into a page definition. Then it dynamically creates native iOS (UIKit) objects and composes them to match the page definition. Later, if the page updates, the frontend gets a new page definition and smoothly updates the page.

Currently, there is one frontend: iOS Frontend.


The backend of an Applin app is an HTTP server. It handles these kinds of requests:

  • GET requests for pages
  • POST requests for pages with user-entered data (text boxes, checkboxes, etc.)
  • POST requests triggered by the user (buttons, camera, etc.)

Applin provides libraries for building backend servers. See Backend Libraries.

Applin is not a no-code app builder. You must write backend code.