We can broadly categorise applications into two main types: web apps and native apps. In this post, we'll explore how each type works, their core capabilities, limitations, and the benefits they offer. First, some definitions:
App
A software program designed to perform specific tasks for a user on a device.
Web app
An application that runs in a browser over a network and is not installed on the device.
Native app
An application that is installed on a device and does not require a network connection for core functionalities. It might require a network for tasks such as synchronisation and updates.
Browser-based app
An application that runs in a web browser. The app could be web or native.
Progressive Web App (PWA)
A website/app that can be launched in a standalone full-screen window to provide an app-like experience. I'm not fond of this term. I think it's unnecessary.
The functionality that PWAs offer, like offline caching, push notifications, and desktop/home screen installation, is just part of modern web capabilities. There's no need for a label like PWA to describe websites that use these features.
Website
A set of interconnected web pages under one domain name that provide information for visitors.
PWAs
A Progressive Web App is a website/app that can be opened full-screen without the toolbars (chrome). This is achieved by linking to a web application manifest file in the HTML <head> section.
When a web page loads, if a manifest file exists, an icon is displayed in the address bar. Click the icon to "install the app" ‐ an icon will be placed on your device's desktop/home screen. Clicking the desktop/home screen icon opens up the website/app full-screen with no toolbars, just like a native app.
Other functionality associated with PWAs, such as offline caching and push notifications, are available to all websites via Web APIs. Adding an icon to a home screen is also possible in mobile browsers without needing a manifest file – 'Add to home screen'.
Being able to open a web app full-screen and use Web APIs such as service workers (for offline caching), enables a native app-like experience. View web app manifest for browser support information.
Browsers
The web browser allows users to access, retrieve, and display content written in web technologies such as HTML, CSS, and Javascript. I use Firefox, Brave, and Vivaldi web browsers.
Browser engine
The overall system that encompasses everything needed to run a browser. It includes handling the network, user input, history, UI, rendering engine, Javascript engine, and more. Example browser engines include Chromium project and the Mozilla platform.
Many web browsers are forked versions of Chromium – Microsoft Edge, Opera, Brave, Vivaldi...
Rendering engine
Handles rendering and displaying web content. Chromium uses Blink. Mozilla uses Gecko. Safari uses WebKit.
Javascript engine
The Javascript engine executes the Javascript code. Chromium uses V8, Mozilla use SpiderMonkey. Safari uses JavascriptCore.
Javascript support
Browser engines have varying levels of support for Web APIs.
CSS support
Support for CSS features varies between browser engines.
Why support varies?
Priorities. Business interests. Differing views on web standards. Browser vendors vary in the speed at which they implement new features, and the quality and depth of their implementation.
Apple limitations
Apple's iOS (iPhone), iPadOS (iPad), and other Apple platforms, require all software to be installed through their respective App Stores. All web browsers must use Apple's WebKit browser engine, unless the country has passed laws prohibiting this restriction.
Companies can change the UI and add some features, but underneath it's a WebKit browser engine – the same one Safari uses. Essentially, no browser competition.
The WebKit browser is less feature-rich, has slower adoption of new Web APIs, and is more prone to bugs. Apple are not particularly inclined to be speedy in browser feature implementation, since they would rather you build an app for their App Store, where they receive a portion of your revenues.
Custom browser
For this project, we provide a custom Chromium-based web browser. Default full-screen mode, privacy features, and other enhancements. The browser is included in our application's installer package.
Web APIs
A Web API is an interface provided by the browser that allows Javascript code running on the web page to interact with the browser, the device, or the web itself. All standard Web APIs are available to all websites, except browser extension APIs, which are restricted to extensions. Web APIs can be grouped into the following categories:
- DOM and UI
- Storage and caching
- Networking and communication
- Device and hardware
- Notifications and background
- Media and graphics
- Security, privacy, and authentication
- Input and user interaction
- Offline and PWA
- Performance and measurement
- Webassembly
Industry groups such as the W3C, WhatWG, and IETF create specifications after extensive discussions, research, and collaboration. A specification defines how a Web API should behave, specifying the methods and properties it should expose, as well as how it should interact with other APIs and components.
Browser vendors implement the API based on the specification, translating the defined standards into functional code. Javascript is used to expose the Web API to developers. C++ and other low-level languages are used for performance-critical parts of the browser engine.
OS APIs
Operating system (OS) APIs are a set of functions, routines, and protocols provided by an operating system that allow software applications to interact with the underlying hardware, system services, and system software. OS APIs provide native functionality.
Hardware
Access hardware resources such as memory (RAM), CPU, GPU, disk storage, input devices, network interfaces (Wi-Fi, Bluetooth), sound devices, communication modules, haptics, cameras, sensors, ports, power management, GPS modules, and more.
System services
Access system services such as file management, process control, memory allocation, networking, hardware devices, security, and user interfaces.
System software
Higher-level system applications, eg calendar, contacts, mail, notifications, photos, reminders, notes, weather, wallet, health, music, clock, maps, settings, voice assistant, files, cloud storage, and search.
Web and OS API interaction
Web APIs can interact with OS APIs to provide access to OS-level features. For example, Web APIs like Geolocation, Media Devices, File System, and Push Notifications serve as a bridge between the web and the underlying OS.
Some Web APIs, such as the Media Devices API, directly interact with native OS functionality. When a web app makes a request through an API, the OS decides whether access is allowed based on security policies and permissions.
OS-level
For a Web API to function correctly with OS-level features, the OS must expose the appropriate interfaces for the browser to access. The OS typically provides developer documentation to guide this interaction. In some cases, the OS API communicates with hardware to perform low-level tasks, like managing resources or controlling hardware-specific functions.
The browser acts as a translator, converting Web API requests made by Javascript into native OS calls, which are often written in low-level languages like C++. Ultimately, the OS provider controls which OS-level features are available to both Web APIs and native applications.
App store native apps
Apps installed via an app store, eg Apple App Store. Apps must be verified and reviewed by the app store.
Sideloaded native apps
On closed operating systems with app stores, sideloading refers to manually installing an app by downloading an APK (Android) or IPA (iOS, iPadOS, watchOS...) file and bypassing the official app store. A non-store install.
Native apps
When referring to apps installed outside of closed systems with official app stores, they're called 'native apps'. For example, when you download and install a software program on your desktop computer, it's referred to as a 'native' or 'desktop' app.
Native app – code openness
The codebase can be open source, closed source, or both (hybrid), ie choose which parts of your codebase should be closed. If you opt for closed source, you should compile the code to binary.
Native app licensing
Different parts of a codebase can be licensed differently – for example, some components may be open source (eg MIT), others, source available (eg SSPL, BSL), and others, proprietary (closed source).
Code conversion
When creating a native application, you can choose to translate your existing code into a lower-level langauge like C, C++, Rust, or Wasm. This is often done for performance (compiled code typically runs faster than interpreted code), portability, and IP protection.
Code compilation
Compile or transpile code into a binary executable file, eg a .exe, .dll, .out, .so, .app, or dylib. Human-readable code gets transformed into machine-readable code.
Compilation interface
We provide an interface for compiling your code into native applications. Choose which parts of your code you want to protect and select the target languages for compilation.
Binary benefits
Compiling source code into a binary file offers numerous benefits:
Faster execution
Executed directly by the CPU, without needing an interpreter.
Portability
Can be executed on any compatible system without needing the original source code or an interpreter.
Smaller file size
The file is highly optimised – machine-readable code is more efficient and compact.
Protection of source code
The source code is compiled into machine code, which is not easily human-readable or editable, safeguarding intellectual property. Other protections include licensing, activation keys, and hardware binding.
Better memory management
Allows direct control over memory allocation and reduces the overhead of interpretation.
Shared libraries
Binary files can link to shared libraries.
Signed binaries
Binaries can be authenticated using a cryptographic signature, ensuring the code's integrity and verifying that it hasn't been tampered with.
Javascript protection
You can obfuscate Javascript by replacing variable names, adding redundant code, obfuscating code flow, encrypting strings, inlining, and other techniques.
Native – offline functionality
Native code can access system resources. For this project, you can download an installer package containing the following:
- Installer file
- Open source codebase
- Nginx web server
- MariaDB database
- ElasticSearch
- Redis
- Project data, eg images, videos...
- Our custom browser
The server side code (eg Python) can interact with and utilise system resources. The user interface runs in the browser, with content served by the web server. Updates can be synced with the central online server when you have an internet connection.
Customise localhost URL
Configure the URL you want to access the application. Examples:
- https://localhost
- https://localhost:8000
- https://localhost/superapp
- https://superapp
Desktop/home screen icon
On setup, you can optionally add an icon to the desktop or home screen.
Activate
Double-click the desktop/home screen icon to open the application, full-screen, in our custom browser. No toolbars. Native app.
Expand your workspace by opening multiple tabs, dragging items between them, and seamlessly move tabs across different monitors.
Conclusion
Web apps can be sufficient for many use cases. Most apps don't need deep OS integration. Native apps provide robust offline capabilities, deep OS integration, and for certain type of apps, higher performance.
Closed operating systems such as Android and all Apple OSes (except macOS) disallow or limit installing native apps outside their app stores. Ideally, operating systems without these restrictions will become more prevalent. I'll discuss operating systems in an upcoming blog post.