My experience coding a React Native app from an iPad, using a remote work station
Introduction
I’ve been experimenting with how to code from an iPad connected to a remote work station for the last half a year, and after experimenting with it I decided to start a real side project with a friend, intending to play and push the boundaries when you only have a tablet acting as a display of a remote Raspberry Pi, an external keyboard and a 4g internet connection.
Fair to mention that I forced myself to work with certain constraints that wouldn’t exist in case of using my personal computer because the challenge was there: build a very portable set up (yes, more portable than a laptop), which would allow me to work on the development process of a multiplatform React Native app from anywhere. For that purpose, I decided to build the following setup:
- an Ipad pro-2020 with 4g connectivity.
- an Apple Magic keyboard which includes the keyboard and a trackpad.
- a Raspberry Pi 4 of 8GB of Ram, with a Raspberry Pi OS Lite of 64 bits, in beta mode.
The process
The process of configuring a remote stable work environment was hard at the beginning. I had no previous experience configuring a router, defining the forwarding ports, dealing with the carrier-grade NAT (CGNAT) or configuring a No-IP address which would allow me to communicate via ssh or mosh with my remote machine. It was also challenging experimenting with Vim, Neovim, Tmux, etc, since I’m used to working with the old VSCode friend, and because I decided to use the Lite version of the Raspberry Pi OS, which doesn’t provide you with a user interface, I was forced to learn more about how to code from the terminal.
It was hard but also funny and very profitable, even when I started pondering about abandoning the idea after I realized about the complexity of the process.
Now, six months later, I can say that the effort was worth it. As of now, I’m enjoying a lot the freedom to do whatever I want, by just taking only my iPad with me anywhere.
Expectations
Since I started this experiment I always had in mind reaching an adaptative and portable environment, so as not to miss my computer at all.
In that sense, the most important requirement was to reach a perfect balance between portability and capability. I tend to find inspiration out of my usual workspace. I can be inspired in the weirdest places, so this is one of the reasons that made me think on a set up as portable as possible.
On the other hand, my purposes of continuous learning and experiment with new technologies, new programming languages or whatever I want to learn, defined the minimum requirements in terms of power, velocity or processing.
Learning by doing
After buying a Raspberry Pi and renewing my old iPad with the latest 2020 pro model, I started investigating which is the most recommended way to build a portable development work environment.
I read a lot on the internet about connecting the Raspberry directly to the iPad via a USB-C cable, which provides internet connection to the former, but this configuration was not as portable as I would have liked it to be since that would mean I would need to bring the machine all the time with me, connect it to the iPad (something that increases energy consumption) and try to find the valid cable for establishing the connection, because not all USB-C cables are valid for that purpose.
Another option involved connecting the Raspberry via Ethernet directly to the router, and access it from the iPad via ssh. This is enough while working from home, where both devices are within the same network but this setup does not work when not working from home. This pushed me to install a desktop version of the Raspberry Pi OS and start using Real VNC, which provides a virtual desktop on my iPad when on the move, but also made me feel I was wasting resources rendering a desktop I didn’t need. It was at this point when I started doubting about the success of the experiment.
One Google search allowed me to discover the NO-IP service, but this meant that I had to put some effort into understanding how networks, IP addresses, port forwarding and many other topics work.
It was during this learning process that I noticed that the complexity was increasing exponentially which prompted me to ask for help from some colleagues. I discovered that the trick laid under a concept called CGNAT and how the dynamic IP of every router works.
Finally, I found the solution. I did the first remote connection between both devices via NO-IP, and here is where my journey starts.
After my environment was set up, a friend came to me and asked: why you do it whit a Raspberry Pi instead of using your computer as a remote machine? The answer came immediately: “Alexa, turn on the Raspberry Pi, please”. This is one of the main reasons. There’s no way to turn on a Mac unless you put it on sleep mode when you stop working, and that doesn’t convince me at all.
After the first Alexa device arrived at my home, I bought some smart sockets, and I assigned one to turn on or off my Raspberry using the Alexa app on my iPad. That gave me the freedom to connect or disconnect my machine remotely when not using it, and also avoid being hacked.
Dealing with the constraints
As I mentioned before, the experiment came with some constraints. The most relevant one involved defining the workflow to use since I had chosen the Lite version of the Raspberry Pi OS without a user interface. The answer was in front of me all the time: the terminal is your friend.
During the previous year, a colleague working as a backend developer challenged me to use Vim for my frontend daily tasks. I rejected the challenge every single time, but there was no way to avoid it once I started the experiment.
Honestly, this was a very painful experience, although I must admit that it was equally rewarding. I learned how to manage Vim (as of now Neovim), and Tmux, how to configure the environment and the required shortcuts, all of which so that I could get the best user experience.
With all the ingredients in place, it was time to get my hands dirty. I decided to use Blink Shell as the terminal emulator on my iPad, and connect via mosh to my Raspberry. It worked like a charm and I felt like working on an iTerm instance on my computer.
The side project
After this initial learning period in which I learned how to become efficient and productive on this new set up, a friend came up with the idea to work together on a side project, in which I would be responsible for developing a React Native app for multiple platforms. I accepted and immediately started investigating how to display results and how to emulate those results on different devices in a remote environment, based on a terminal and a text editor such as Neovim.
For my first approach, I started coding from my mobile device which involved rendering the default content you get after creating a new React Native project, This came with penalization issues in the form of accessibility since working from a remote environment brings accessibility issues to the local content. After searching on the Internet for a while, I found a solution that involved creating a tunnel by using ngrok. This allowed us to render in my cellular browser what was being shown in the Raspberry device when starting the app.
Time to play
After solving the previous hiccups, it was time to define the resources to use for the development process. The first choice was to use the Expo framework and test the app by using the web simulator and the mentioned ngrok API. I did some tests on physical devices by scanning the QR code provided when running the app, but since neither Xcode nor Android Studio were available on the remote machine, I was forced to do visual QA by rendering the content on the iPad browser.
One of the first questions that came to me was, is there any way of inspecting the content on the web browser? The answer came with the app Inspect Browser, which provides a similar environment to a desktop browser.
On the other hand, we decided to include the UI Kitten library to take advantage of using the amazing components they provide. We also decide to use the styled-components and the react-navigation packages as well.
The rest is mostly known and has no secrets.
Conclusions
You could be right in thinking that this is an overkill process and a laptop can give you the same or if not more advantages than this Frankenstein I decided to build, but what started as an experiment has ended up as my personal environment of choice for several reasons:
- A compact tool that can be ported to any place and gives me a dedicated work environment, with no distractions.
- No need to worry about the battery autonomy of my iPad due to a more efficient environment than that no Macbook model can match.
- In my case, apart from using the iPad for coding, I can use it for many other purposes, such as graphic design with a smart pencil, or even for music production.
- Splitting the environment into two single components that work as one single element, I can replace my Raspberry and continue using my iPad until it becomes obsolete, or even create a cluster of Raspberries if I need more processing power.
Of course, we can’t obviate the cons, namely:
- I invested a lot of time learning before I reached the solution I was looking for. In case of looking for a machine that is not going to be used when leaving your home, I don’t find the reasons for invest too much efforts in getting it working as I did.
- The Raspberry Pi OS Lite has many limitations for some purposes. In my case, it was impossible to emulate an Android or iPhone emulator from a terminal, which forced me to work with the web emulator. It might be enough, but you don’t get the same user experience as you would while working on a laptop with the proper tools.
- If you are not a big fan of text editors like Vim, this is something that you can not avoid. You can try to use a Raspberry Pi desktop version and Real VNC, but bear in mind that unless you decide to use an external mouse, many options require a secondary click action button, and are thus not possible to execute by using the trackpad that comes with the Magic Keyboard.
- Some of the apps or tools I mentioned before are not free. Blink or Inspector Browser should be purchased in the Apple Store. Others such ngrok come with free plans, but it’s fair to say that you will probably need to spend some money if you want to have a user experience as close as that of a computer.
