By David Sun

By David Sun

Shaken Chat (iOS)

Dec 2015, Case Study




iOS, Swift, Core Bluetooth, JSQMessages


Created an iOS app that allows users to chat without internet.


Shaken Chat was my first personal iOS app; I always had a fascination with P2P and mesh networking technologies. I thought it fitting to create an app that revolves the power of mesh networking; hence, Shaken Chat is born.

Shaken Chat is a internet-less chatting app powered by a mesh networking framework. What is mesh networking? In a nutshell it is playing the game telephone with a lot of devices.


To make the internet-less chat possible, I used Bluetooth to connect each phone to each other. But the inherent problem with Bluetooth is it’s limited range (only 30 feet). This is where mesh networking comes in. If there are three phones in a network and each spaced 30 feet apart, each device can only connect to one other device. Instead, with a mesh networking algorithm, I can leverage the phone in between the two phones as a ‘middle man’ and route the data from one device to the next. This process would effectively expand the range to 60 feet.

This is a lot more complex then it seems; it has to be efficient, reactive to when devices drop out of the network, and have a low failure rate in sending messages. With more and more phones connected in a web, it is hard to determine the right path to route messages to the destination phone. I would eventually do extensive research into many built mesh networking frameworks to find one that would best fit the unstable nature of Bluetooth. I would eventually land on a protocol called BATMAN.


BATMAN, which became the main inspiration for my custom mesh networking framework for the app, uses the technique called ‘flooding’ for each device to understand the state of the network. At a set increment time, a phone will ‘flood’ all the phones directly connected to itself with a messaging telling them ‘Hey, I exist!’ This message is then sent by the receiving phone to all other phones, notifying them of the existence of the device who originated the message.

Credit to Wikipedia

Because this flooding process occurs very rapidly, the current state of what phones are in the network is kept up to date on each device. The problem lies in how data will be sent across the network. There can be many paths to the destination device. Which one to use? Which is the most stable? This is unintentionally accounted for with the ‘flooding’. Each phone, during a certain amount of time, receives many ‘I exist’ messages from all the phones it is directly connected to. Some of them are redundant; the ‘I exist’ message from a certain phone may come in 4 times due to the nature of the flooding. Using the number of received ‘I exist’, the device can get a general clue of which directly connected phone appears to have the most fast and stable connection. The more ‘I exist’ messages means the directly connected phone has possibly more connections or fast connections. The device would eventually ‘know’ which phone it is directly connected is the safest bet to send the data to. With this, each phone would continue to send to the ‘safest bet’ until it reaches the destination phone.

Such a technique to route messages, reflects the simplicity of the algorithm; there is no advanced routing algorithm that generates a ‘map’ each time the network is refreshed. Instead, it simply routes messages in the general direction, minimizing the complexity and reducing the chance of routing failure.

Making the app

Porting the algorithm to swift was a long and arduous process but was eventually done after 2 months of testing and debugging. I am very proud of the app, but I feel like the UI is a bit dated (Something I hope to fix at a later date).