The Future of Native Mobile Apps on Blockchain — What They Should Look Like, and How to Build One…

There are a lot of good reasons to have a standalone native mobile app for your token/smart contract/DApp (Decentralized App): ethereum Just a single tap away from the home screen means more frequent usage Accessibility: You can provide custom user experience just for your users who sign in with the app specific private key. You control your own user experience and don’t have to depend on generic web browsers or generic wallet UI. Independence: Relying on generic wallets or generic DApp browsers means you delegate all the transaction-related UX to the browser. This means you can’t provide an optimized, dead simple user interface specific to your DApp. With your own dedicated app, you can build a streamlined interface with no confusing parts. Optimized UX: You can make use of features like push notifications, bluetooth, camera, etc. which can significantly improve user experience. Mobile specific features: But as you start thinking about building mobile apps, you will find yourself immediately confronted with some critical challenges: You probably have too much on your plate already with your protocol/smart contract/token and don’t have the time or resources to build an app, not to mention maintaining it. And having a dedicated mobile code base that only a few people can understand and maintain is a risk and a liability when your main business should be in the protocol. Risk: You probably want to build something that will last forever, even after your current team moves on. The goal is for the community to build clients on top of your protocol instead of you being the sole developer of a single gateway. Pushing a single dominant implementation from the “official team” only discourages participation from 3rd party developers and doesn’t help with decentralization. You really shouldn’t be the one building the app: You don’t want to build a single app, you want your protocol to be a fabric of the decentralized Internet. Ideally it should be used by all kinds of different apps, not just a single monolithic one that you developed by yourself. Fabric vs. Single App: These are real problems with no clear answers, with few people willing to talk about them. It occurred to me that one solution may be to rethink what an “app” is. To that end I tried to create a dead simple framework to bring us closer to that realization. I started by building a simple mobile app that looks like this: ERC20 token Throughout the rest of this article, I will discuss: Walk through all the technologies used in this project, from backend to frontend. Ingredients: High level overview of how I built the mobile app Implementation: what I learned from building an app this way and what I think mobile apps on blockchain will look like in the future. Lessons: While I use specific tools and frameworks throughout this post, the general principle and the lesson should be applicable for anyone who’s thinking about building mobile apps on Ethereum. Ingredients Before getting to the mobile app, let’s take a look at all the ingredients we need to build the full stack: Smart contract Backend: Web + Mobile Frontend: Solidity Smart Contract Since this post is not a tutorial about how to write smart contracts, I will just share a simple ERC20 token contract I deployed to Rinkeby (an Ethereum testnet). You can find it in production here (remember to connect to Rinkeby): https://gliechtenstein.github.io/erc20/web/ And the source is here: https://github.com/gliechtenstein/erc20/tree/master/contracts The code itself is 99% copy and pasted from contracts for simplicity and 1% customized. OpenZeppelin The cool thing about standards like is you can write once and use it everywhere, so most developers don’t have to worry about coming up with their own secure implementation, they can just reuse most of it and customize only what they need to. The entire community shares the benefits. ERC for Ethereum This is very in line with what I am trying to achieve with the solution I’m about to discuss in this article. The difference is and Zeppelin and friends are focused on the backend (smart contract) I am focused on the frontend (mobile app). Web3.js DApp I wrote a simple web3.js Dapp for dealing with the ERC20 token I deployed in the previous section. For simplicity, I didn’t use complex tools and frameworks like , et al. It’s literally just a single flat HTML file. You can check out the code here: Truffle https://github.com/gliechtenstein/erc20/blob/master/web/index.html A Trusted Node, trusted by many, including MetaMask. INFURA : Most DApp developers nowadays acknowledge that it’s unrealistic to expect all users to download the entire blockchain which is hundreds of gigabytes. In fact, most users use a 3rd party trusted node instead. This is where the desktop browser extension comes in. MetaMask takes a “thin client” approach. Instead of downloading the full blockchain, it connects to a trusted node called Infura. Because of the public key cryptography that powers the whole blockchain — you sign each transaction with your local private key before broadcasting to the network so the network can’t forge it — it is generally considered safe enough to use trusted nodes just for broadcasting. MetaMask For mobile development, it makes even more sense to use trusted nodes like Infura because nobody wants to download tens of gigabytes of blockchain, waste network traffic and kill their battery from constant peer to peer synchronization. So . let’s use Infura _Secure, reliable, and scalable access to Ethereum APIs and IPFS gateways._infura.io Infura - Scalable Blockchain Infrastructure Cross-platform Native Mobile App Framework Jasonette: The first building block is the native UI. We’ll use Jasonette, a markup driven approach to building cross-platform native apps. _Jasonette turns JSON into iOS and Android native components._www.jasonette.com Jasonette — Native App over HTTP Jasonette is like a web browser but for building native apps. Just like how web browsers interpret HTML on the fly and render it on the browser screen, Jasonette interprets a JSON markup to construct a native app on the fly on iOS and Android. The markup syntax supports expression of everything from to to , so just a single JSON markup is all you need to build a native app. Model View Controller Quick intro to how Jasonette works: In-depth tutorial: Microservice on the Mobile Frontend Agent: One important built-in feature for that’s critical for our use case is . Jasonette agent An agent is like a microservice that you can embed in your native app frontend. It automatically forms a two way communication channel between the parent native app and itself, allowing them to communicate via a . JSON-RPC protocol For example, you can take any web app that works in a browser, embed it in a native app as an agent, and instead of rendering some API data into the DOM, send it to the parent app as an event. Then the app can render it natively. We will use agent to embed our existing web3 DApp into a native app and use it as a data source (and use the native part to render the data). Take a quick look at the following page to learn more about agents: _Turn any JavaScript app into a cross-platform native mobile app_www.jasonette.com Jasonette Agent Implementation Now we’re ready to build the mobile app. The above diagram is a quick overview of the overall data flow. The user interacts with the native UI. The native UI makes a request to the “DApp container” (which contains your web3 DApp agent) The DApp container makes a request to the “Wallet container” agent (for now, just think of it as a mobile equivalent of MetaMask) The wallet container then connects to Ethereum. All of these are inter-connected through the JSON-RPC protocol, and the application — all three modules — is entirely described in JSON markup. Before we jump in, just a reminder that you can find the entire source code at: _erc20 — Full stack ERC20 Token App (Contract + Web + Mobile)_github.com gliechtenstein/erc20 With that said, now let’s take a look at each module. 1. Native UI The first building block is the native UI. Jasonette has a built-in templating engine — also written in JSON — that can take any JSON object and render into a native layout and UI components, as well as express native API function calls in JSON markup. In this case we‘ll use the DApp container — which we’ll discuss in the next section — as data source, so we define the template and wait for a response from the DApp container. Once the DApp container triggers an event we’ll render the data against our template. Here’s the full markup: https://github.com/gliechtenstein/erc20/blob/master/mobile/app/main.json The cool thing about the markup driven approach is that the This means you can store and serve the app from anywhere (like how web browsers do it). It could be stored in a remote server, locally on the device, or even on decentralized storage like IPFS. application logic is completely separated from the device. Let’s step back and think about what this means. By separating application from the device, we can make sure that regardless of whatever happens to Apple or Google in the future, our app will be portable to a new platform as long as the framework itself is ported to that new dominant platform. And this is why Jasonette chose JSON as the markup language, , therefore it is likely that the hypothetical “new platform” of the future will also support JSON as first class citizen. JSON is the most popular format for machines to store and communicate data with one another For our MVP app, we serve it from a remote JSON hosted on github. 2. DApp Container The second building block is the DApp container. There are a couple of things to note from this diagram: The user ONLY interacts with the native UI. To the user the DApp is invisible and it simply functions as a data source. The native module forwards the user request to the DApp container through JSON-RPC. The DApp container then makes a request to Ethereum network (thanks, Infura) and when it gets a response back, forwards it back to the parent native app, which is rendered with the native template mentioned above. We instantiate the DApp container as an agent. Declaring an agent involves simply adding 3 lines of JSON to the existing app markup: {"$jason": {"head": {"title": "Web3 DApp in a mobile app", }}} "agents": { "eth": {"url": " https://gliechtenstein.github.io/erc20/web _"}_ },... In this case we initialize the DApp container and name it , which we will use as the ID when we make JSON-RPC calls. eth Here’s the full source: https://github.com/gliechtenstein/erc20/blob/master/mobile/app/main.json Note that we have not touched the original web app. To be clear, you don’t have to do this and just keep a separate agent just for embedding into the mobile app, but I just wanted to show how you can reuse the same DApp for mobile. We simply embedded our DAPP as an agent and are using it as an instant pseudo-backend for the mobile app. 3. Wallet Container Writing to Ethereum is trickier than reading. We must be more careful because it deals with creating actual transactions and sending real money. Normally when building a regular DApp, we use the library to make an API call like this: web3.js contract.transfer. (receiver, tokens, {to: contract.address,gasLimit: 21000,gasPrice: 20000000000}, function(err, result) {// Render the DOM with result}) sendTransaction This method actually does two things: sendTransaction Create an encoded transaction object for a contract method called . "transfer" Sign and broadcast the transaction object to Ethereum via JSON-RPC. For our project instead of having the DApp handle both, we will: Let our DApp container handle only the first part and create a separate container called to “Wallet container” handle the second part By separating the two, the DApp container doesn’t have to deal with private keys, but delegates it to the wallet container just like how deals with this issue automatically on desktop. That way the DApp developer can focus on the application logic. MetaMask So instead of using the method, we first use an API called to get a transaction object: sendTransaction getData var tx = contract.transfer. (receiver, tokens) getData And then pass that back to the parent app through : the [$agent.response](https://docs.jasonette.com/agents/#2-agentresponse) API $agent.response({ tx: tx }) The parent native app then will . pass it along to our new wallet view The wallet view (and the wallet agent it contains) will take this unsigned transaction data, sign it, and then broadcast it through Infura. You can check out the wallet view source code here: https://github.com/gliechtenstein/erc20/blob/master/mobile/wallet/wallet.json Here’s the wallet agent code: https://github.com/gliechtenstein/erc20/blob/master/mobile/wallet/wallet.html Note that the “wallet view” is a completely separate sandboxed view of its own, just like how MetaMask opens up in a new popup browser. This is by design. This insulates the DApp developer from ever having to deal with private keys. Why build this way? To recap, here’s how our entire mobile app works: The user ONLY interacts with the UI, which is native The native UI is constructed from a markup in realtime, instead of a hardcoded compiled program. The native UI embeds multiple microservice-like web containers running isolated HTML/JavaScript apps, communicating with one another through JSON-RPC. The only “program” the developer needs to write is the JSON markup that describes the UI and the instructions. What’s the benefit of building an app this way, especially for a decentralized network like Ethereum? 1. Easy It’s simply much easier to build the app this way. You don’t have to rewrite your DApp to work on mobile, you don’t need to hire a mobile developer, you don’t need to maintain a separate mobile code base. All you need to do is: Write a couple of markup files representing each view Embed your own DApp as an agent like an iframe Let your DApp and the parent native app communicate through a protocol such as JSON-RPC. This gives you a single codebase that works both as your website and for mobile. . But even the markup — since it’s public — can be shared by different apps. The only thing you need to maintain is the markup We can look at how the ERC standards for Ethereum work in order to understand the implication of this. Most ERC20 token developers simply inherit from ’s — the most audited and therefore most secure ERC20 token contract — and implement their own customization on top, which makes it much easier to build smart contracts while keeping it safe. Zeppelin zeppelin/solidity And I predict that same type of standards may emerge for building secure mobile frontends. 2. Everlasting Every view is expressed as a single standalone JSON markup — just like all web pages are expressed as a single HTML markup — nothing hides behind complex dependencies that can make a piece of code hard to understand. None of the JSON markup syntax is device specific. Every view is standalone and sandboxed which also contributes to simplicity. Simplicity begets transparency. To build a protocol that will last forever, you want your clients to be as transparent as possible, so a free market can form around clients for your protocol. This way your protocol can live on forever even after you move on from the project. _And that's not because everyone is afraid to touch it_levelup.gitconnected.com How To Write Code That Will Last Forever 3. Customizable The example below uses exactly the same DApp we used above, but just with a different view markup to create a completely different interface. I didn’t have to do anything fancy to make this change. What you see above is literally a single JSON markup which I forked from the earlier version. It took me less than 5 minutes to write: https://github.com/gliechtenstein/erc20/blob/master/mobile/app/simple.json What’s really cool about this is that YOU TOO can take the same markup and customize it for because all ERC20 tokens share the same backend protocol. Even the DApp container can be reused simply by switching out . your own ERC20 token the contract address What would mobile apps of tomorrow look like? The mobile apps of tomorrow will be built on top of cryptographic protocols that connect to decentralized networks such as Bitcoin and Ethereum, instead of connecting to a centralized network like Facebook. In this world, we may need to rethink the very notion of what a “mobile app” is, and how to build one without compromising a user’s security when their identity is baked into the protocol. 1. The Rule of Least Power There is a concept called “The Rule of Least Power”, coined and implemented by Sir as the fundamental design principle for the World Wide Web. Tim Berners-Lee _The World Wide Web is unique in its ability to promote information reuse on a global scale. Information published on…_www.w3.org The Rule of Least Power The idea is that such as the Web. The rule states that : simple is superior to complex in a potentially dangerous environment, a “descriptive” language is stronger than a “procedural” language “…given a choice among computer languages, … ” the less procedural, more descriptive the language one chooses, the more one can do with the data stored in that language. Also, a simple language is than a complex one: more secure “… … Because programs in simpler languages are easier to analyze, it’s also easier to identify the security problems that they do have” Less powerful languages are usually easier to secure Summary: . A wild wild west environment like the world wide web should be implemented with the simplest language possible, such as HTML. Simple is more powerful than complex. Simple is more secure than complex “a variety of characteristics that make languages powerful can complicate or prevent analysis of programs or information conveyed in those languages, and it suggests that such risks be weighed seriously when publishing information on the Web. ” Indeed, on the Web, the least powerful language that’s suitable should usually be chosen. Fast forward to today, and we’re dealing with a new Internet over which we send real money and where we want our apps to securely function with minimal maintenance long after their original creative teams move on. The “Rule of least power” design principle has never been more relevant than today. This is why I believe a “less powerful” standardized on crypto-protocols, instead of building “powerful” apps that end up being more of a liability in the long run. is better for building mobile apps markup-driven approach 2. Fabric of the Decentralized Internet As a protocol developer, your goal shouldn’t be to build a single monolithic app — you’re not an “app developer”. Instead, and open it up as widely as possible. your focus should be 100% on making it easy for anyone to embed your protocol into their apps Hypothetical example: Augur In the hypothetical example above, has multiple smart contracts that make up the entire experience. The Augur team *could* go for building a single all-in-one app themselves, but what good would that do for decentralization? Augur The cool thing about building a protocol is that you can let anyone build their own interpretation of it, optimized to specific needs. The adoption should be determined by the free market. Building a “reference” implementation might be good, but that shouldn’t be your goal. The goal is to make it as easy as possible for your community members Alice, Bob, and Carol to build their own custom apps on top of it. The best way to do that is to write your app in a language that’s as forkable as possible, which in my to my eyes is a markup approach. 3. Monolithic vs. Mashup Let’s take this even further. Today, we have only a single dominant protocol — HTTP. However, the mobile apps of tomorrow will be multi-protocol. The current paradigm of “mobile apps” is all about building a single monolithic app which the developer has 100% ownership over. This was a natural choice in a “client-server” world where it is assumed that the developer of a mobile client also owns the server. For example, Facebook app connects to Facebook server, Twitter app connects to Twitter server, etc. In that world, it totally makes sense for the client developer to build a monolithic app, and that’s what we’ve been accustomed to until now. But in the age of decentralized protocols, . One app can be a “mashup” of multiple ownerless protocols. one app can be powered by multiple protocols There is no , , , etc. That’s an old way of thinking. “Augur app” “0x app” “Decentraland app” Instead there will be apps that use all of these protocols together within a single app. 4. Security through Dependency Free Implementation The problem is, achieving all this is not as easy as it sounds. We’re dealing with real money here and integration is surely not as easy as running . The conventional approach for building any kind of app today is: npm install Tightly coupled modules With complex dependencies That assume a monolithic centralized app This has been great for the age of , but in the world of , it’s too risky because so many things can go wrong on the app developer side no matter how secure the protocol is. centralized and trusted app providers decentralized and trustless protocols After all, it is no secret that highly coupled dependencies can introduce a cascade of security vulnerabilities: The best way to avoid this problem is to… avoid dependencies, and simplify! _Ask any 21 experts to predict the future, and they're likely to point in 21 different directions. But whatever the…_www.schneier.com A Plea for Simplicity As Bruce Schneier preaches in the article, you can’t secure what you don’t understand. Based on these assumptions my proposal for building mobile apps is to build them as , , sandboxed loosely coupled dependency-free containers: _How sandboxed views talk to each other in Jasonette_medium.com Native Mobile View as Microservice Each view is a sandboxed container just like a web page. Each view’s state doesn’t carry over to another “page” unless explicitly stated (View A and View B are completely separate) Sandboxed: Each view is loosely coupled through inter-container protocols ( for moving forward, and for returning backward) and sometimes app-wide shared global variables. Loosely coupled: $href $ok All views are completely self contained and dependency free, so one view can be integrated into multiple different apps without having to rewrite anything (You can turn this app into a completely different app simply by changing the attribute to point to View C instead of View B) Dependency free: href This design principle makes sure that: One implementation bug leading to a huge disaster. ( ) can’t cause a domino effect See leftpad Apps can be without having to rebuild the entire app. Without this, one bug will mean every app developer who’s used the protocol will need to rebuild and update their apps immediately, which will never happen. “upgraded per view” The protocol developer can that app developers can easily embed into their apps (instead of as a monolithic app) distribute their “app” as a secure atomic unit 5. Seamless Integration of HTML into Native App If you’re a developer, you’re probably aware of the whole battle between . Proponents of these two factions have been fighting over which will become the single dominant platform for building mobile apps. “Native vs. HTML5” A better way to look at this problem is to and therefore the question becomes irrelevant. think of how to blend them together so seamlessly that the integration is almost unrecognizable The rule of thumb is to build apps as natively as possible, but for certain cases where it makes sense to integrate HTML components — such as graphic-heavy visualization —you should be able to do so in the most seamless manner. Imagine building a simple game app, you could: Build the graphic heavy parts of your game with an HTML5 based game engine But use native views for the rest of the app And this is only possible when you move away from the mindset of “only one approach wins” and focus on integrating the two in the best way possible. Below are examples of how native components and HTML components blend in perfectly together, WITHOUT having to modify the HTML at all: I talk about this further in another article: _A New Approach for Blending Web Engine into Native Apps_medium.freecodecamp.org How to Turn Your Website into a Mobile App with 7 Lines of JSON Interested? In this article, I explained how I took an existing web3 DApp and turned it into a native mobile app. The key takeaways from the approach: Markup-driven Sandboxed Views Loosely coupled through protocol The first two is similar to how work, and the third is like how work. Combining these I have proposed . web browsers microservices a unique architecture for building secure mobile apps The purpose of this post was NOT to claim this is the “ultimate solution”, but to propose a mental framework for thinking about this topic, as well as an actual functional implementation to support the hypothesis. I think this topic of is not really talked about much in the community because: “what would the frontend in the age of decentralized protocols look like?” Most people are focused on building the backend, and people don’t really want to have to worry about centralized platforms. Most of those who HAVE thought about it are building centralized products. , and we need to start thinking differently about how an app will work in the blockchain world. But mobile apps are inevitable if you want mainstream adoption I am excited about decentralized technologies because it’s very aligned with my view of the future, and am planning on exploring this field further. Here are some of the themes I am thinking of: Take the app I’ve built and (so all you need to do as a developer is “embed” your DApp with 3 lines of JSON, for example) turn this into a “plug-and-playable” framework Create high level overlay frameworks on top, for example ERC20 or ERC721 token specific agents. Support other chains: , etc. (Suggestions welcome) Bitcoin Look into integration with like and . hardware wallets Ledger Trezor If you have any suggestions or feedback, please share. Also, stay in touch if you’d like to follow the journey. I’d love to hear from you! Where to find me: Chat with me on : Slack https://jasonette.now.sh/ Follow me on : Twitter https://twitter.com/gliechtenstein Follow me on : Medium https://medium.com/@gliechtenstein Contribute to Jasonette on : Github https://github.com/Jasonette Follow Project Jasonette on : Twitter https://twitter.com/jasonclient Subscribe to Jasonette : Newsletter https://docs.jasonette.com/#mc-embedded-subscribe-form