Simplicity is the ultimate sophistication
Most of these core concepts can be seen working in the prototype video.

This is a highly asynchronous model that doesn't make unrealistic assumptions; e.g. distributed computing fallacies.

Uses a highly asynchronous model - non-blocking that can work offline. The app continues to run without regard to the connection state.
The app appears to have access to all data, even data not yet on the device. This removes the concept of having to store or fetch data from a server; the underlying system automatically manage this. Thus data persistence and communication are hidden from the developer.
The app appears to have direct access to all hardware on remote devices (given permission). It uses a high level abstraction for hardware access.
It uses a collaborative model; not a client-server model. That is, your app should easily work with other devices & users as they come online and go offline.
It uses best effort functionality. If part of your app needs online live interaction with a server, then it automatically degrades that part of the app and allows the rest of the app to function - not freeze the whole app. Best effort is automatically managed by the underlying system.
Data is automatically persisted and synchronized with other devices.
Reactive model automatically re-runs functions when new data is available.
Developer focuses on data types & relationships, functionality and UI. The rest is managed by the underlying system.
Automatically manages offline, peer, mesh and Internet connections and data synchronisation.
System manages rollout of new versions of the app. App continues to run and can be used during the upgrade.
Platform agnostic, so write once and run anywhere.
Learned from the spreadsheet what-you-see-is-what-you-get live editing, always running, never crashes, easy-to-use model.
Use a screen-independent UI layout manager that automatically optimizes your layout for the current screen size and orientation. This requires a special and easy way to specify complex layout as you build your system.
On-device app editing. When you think of a change, just edit the app there and then.
The user decides how much data they want on their device, e.g. 10MB. The system automatically manages how much data is locally cached to achieve this and fetches further data from peer devices as needed. Thus the system automatically scales from complete database replication on a small number of devices to only keeping required data on a global system with billions of users.
You will have to look at some things a bit differently due to the asynchronous offline nature of this system.


This system aims at simplifying apps. The simplistic overview of the model is that the app can access, with permission, all data, cloud, all devices and all hardware directly (asynchronously) without direct consideration that some are on the network. Data in this model is automatically persisted to local storage and automatically synchronized to remote devices. The programming model is reactive; that is functionality runs when the dependent data changes. The datastore is reactive and runs appropriate dependent functionality when data changes.

This simplifies programming significantly and reduces the detailed communications and database knowledge required by the programmer. But the model doesn't make unrealistic assumptions; e.g. distributed computing fallacies. In fact, the solution described here assumes you will run into all these network fallacies problems and more while enabling the app to continue running uninterrupted. The approach here is different to traditional systems; although over time we are seeing more platform agnostic solutions, more reactive datastores and reactive functionality, more peer and mesh communication solutions, more offline solutions and more simplifying app building solutions. The approach taken here unifies all of these into one solution. We aren't really seeing on-device app editing or simple app update rollout solutions yet; but since they aren't that difficult you'd expect them to come in the not too distant future. The more advanced scenarios enabled by this system, like app merging, don't seem to be talked about at all.

When the developer creates a variable, it is automatically persisted and will be sync'd to other devices and cloud. The developer does not have to code comms protocols or set up a database on the cloud or any of that - the underlying system takes care of all of this. New values are sync'd to other devices whenever possible, automatically managed by the system. This also means that whenever the device's app lifecycle management decides to remove your running app from memory, your app's state is automatically persisted without the developer having to code for it. So your app will later continue from where it left off, when the system brings it back into memory.

This makes it very easy to write an interactive app that interfaces with online servers or other devices. You just write your app - persistence and data transfer are magically managed by the underlying system. You no longer have to consider client and server - you just consider that your app is part of all the data and all other devices. The underlying system takes care of how to manage this in online, peer, mesh and offline environments.

This does require a slightly different view of the world, as discussed below. You take a different approach to achieve the same result - similar to how imperative and functional programming approaches are different but can create the same program.


People sometimes feel hanging on to a thought is more important than enjoying life
The idea behind this system was to find a solution for sharing data across mobile devices that worked mostly offline. Sometimes they would work together as peers, other times in disconnected meshes or occasionally they would get an Internet connection and share data with a server. In the context of this system, a server is really considered a peer that is always on, globally findable, and has some restrictions on the way you communicate with it (HTTP req/resp). In reality the server can be made dumber than a peer, thus allowing data to be encrypted/decrypted on the devices and stored encrypted on a server that does not know how to decrypt the data.
Part of this system was the idea of providing a more robust solution by having immediate data replication whenever a device could connect to any other device. If the device you're using fails then you could immediately move to the one or more connected devices and continue to work. But you could also be using multiple connected devices at the same time, entering & reviewing data on each, and still get the data replication on all connected devices. This would work seamlessly, just pick up any connected device and keep on working. Devices could have intermittent connections, so data replication would automatically occur while the devices had a connection, allow all the devices to work offline and continue data replication whenever a connection was obtained. 

The solution needed to work seamlessly as the devices changed between all these different communication scenarios - which mean intermittently failing comms links wouldn’t upset the devices - they would sync data when able, but would continue to work uninterrupted while networks came and went. So the priority was for the devices to continue to work without the user knowing the communication state - unlike a web browser and many apps that stop working with an error message or even lock up your device when they cannot get a connection.

Of course, if your devices are mostly online, then they will continue to work seamlessly during the less common times when they are offline. User shouldn’t be aware that the device is offline, they keep working uninterrupted.

Note that this is peer-syncing, not the easier client-server syncing. There is no master device; everything in this system is a peer. This enables you to be running many small unconnected meshes and later have devices from different meshes peer-sync and all your data is merged as you would expect.

Having a peer-sync solution means you don’t have to run a server at all. You could be running ten smartphones that only ever Bluetooth directly to each other to share data - never ever connection to the Internet or running WiFi. Then, with exactly this same same app on this peer-sync solution, you could run it with local WiFi, Internet, 4G and cloud servers intermittently switching between each other and offline. Offline, peer, mesh and Internet connections are no longer a concern for apps written on a system like this. It’s the same system, the same app, and it runs in all these scenarios - seamlessly switching between offline and different types of connectivity.

So peer-sync means the underlying system will do the best effort to get your data from one device to another. The developer defines the data and no longer worries about it - the system will work offline and sync to the appropriate devices whenever possible - or if online then it works like any other online app. So data communication/sync is no longer an issue for the developer, they don't have to think about it, they can focus on app functionality.

Another aspect of the solution was to have platform agnostic apps that work on different devices with different screen sizes. This mean writing a special layout manager to provide optimal layout for different screen sizes and orientations. When you have this then you can even look at doing your own windowing system enabling you to run multiple different apps on the same device on the same screen at the same time.

Another aspect of the solution was to provide an easy way to push out software updates. It turns out you can update an app while it’s running - no need to reboot the device or even stop-update-start the app. You can have a running app and watch it update to a new version while you are currently using it. In fact, you can even be writing the app while multiple users are using it and entering data into it - as shown in the prototype video.
The nice part about this is that the app functionality is shared out the same way data is. This means you don't need to connect to the Internet to get updated functionality. If a peer device with a newer version is Bluetooth connected to your device, the new app version will automatically be sent to your device over the local connection.
Another nice feature is that older version of the app can be running in local connection alongside newer versions of the app. It's only when the new devices connect will the older version of the app be updated. But this does mean you have to be a careful about redefining existing data structures to mean something different in the updated version - creating new structures is safer.

This lead to the development of a simple what-you-see-is-what-you-get editor for editing the running app. The editor runs on the device running the app, e.g. a tablet. You don’t compile-test-run, you just edit and immediately see the changes you made running in the app.
Of course, with this flexible update solution it means you can update an offline app in the field to implement some new needed functionality and have that update rolled out when you get back online. It also means you can collaboratively develop an app. Different developers on different devices can develop different parts of the app at the same time, seeing the latest version as the changes are made. 
(While this collaborative app development works on the current prototype, it may be a good idea to add a switch to stop immediate rollout of changes - in effect, making the app appear offline during app editing - until you are satisfied with the changes).

Another aspect of the solution was for remotely monitoring and controlling devices. Some devices would be running this system, other external devices would be connected to one or more devices running this system. A device running this system can provide interfaces to local hardware as well as interfaces to connected hardware. Control & monitoring messages are just data being sent between the devices - which is what this whole peer-sync solution does quite well. So you just need to provide drivers to connect to that hardware/device that map into the peer-sync data structure - which effectively provides you the usual memory mapped device control interface we get with most computer systems, including PCs.
Of course, you don't need to think about this for long before you start to see that conceptually an app doesn't run on a device - it runs in a sort of peer-sync-cloud somewhere between the devices. The app could control any of the hardware on the connected devices (given permission). So the app on my tablet could as easily tell my phone to take a photo as it could to tell the tablet it's running on to take a photo. From the app's point of view, it's working with the same interface, it just happens that one is remote and another is local.
A nice feature of this is that I can choose where to send my display. The app may be actually running on my phone but I could send the display to your laptop. Then we get other interesting scenarios where I can send out my display to a number of devices at the same time - layed out optimally for each device - good for showing information you are seeing to another person.
Of course, having the developer try to give direct commands like take photo to hardware is very old-school and you wouldn't do it that way now days. You'd use the much simpler high level abstraction, essentially abstracting away the hardware.
Overall, you now have a core app building solution that will allow you to monitor and control lots of things. Since the Internet Of Things has things that are easy to connect to, you just need to code the mapping from the peer-sync data structure to the 
IoT device's interface and you then have interaction with it through this system. This then makes it easy to control IoT devices as they map into the this system.

This system runs on a multicore reactive system. That is, any functionality that uses data, say the formula a=b+c, will automatically recalculate a if the value of b or c change. So when any data changes, it could cause a lot of recalculation, which are handed off to as many cores on the system to run in parallel as quickly as possible. Again, this means the developer doesn't have to worry about when functions are run or refreshing the screen or anything. The functionality is entered and the system looks after running it when it needs to be run.
Along with this, the system provides caching of intermediate results. Developers may be tempted to cache partial solutions and summaries in the datastore themselves - this would be a mistake for them to do so - they just need to write the functionality and leave the optimizations for the system to manage. A peer-sync system that allows apps to run offline means trying to get clever about caching summaries or intermediate result may put incorrect conclusions into the databa
se since not all offline data has sync'd yet. The system knows how to handle this and it's just easier for everyone if the developer takes the easier approach and lets the system do the optimizations and caching.

People sometimes feel hanging on to a thought is more important than enjoying life
Similarly the datastore is managed by the system. The developer defines the data structure of interest. The system manages how this is stored on the different devices and manages sharing data between different devices. Data may be stored in an SQL database on one device and a file on another.

The developer is left with very little to do other than defining the functionality and layout of the display.

Interestingly, with the approach taken in this system, you can send a request over 4G, receive a response over Bluetooth and send a response to that over WiFi.