DEV Community: complexityclass

Rustling Up Cross-Platform Development

complexityclass — Sun, 12 Mar 2023 21:26:11 +0000

My experience with cross-platform mobile development lacks some important elements, such as Flutter or Xamarin. Therefore, this article is not a comprehensive analysis of tools in this space.

Over the years, I've tried a few different tools for cross-platform development, including PhoneGap (which, in hindsight, I probably should have avoided), React Native, Qt, and a bit of Kotlin Native. Generally speaking, I firmly believe that the UI should be native, and that tools like PhoneGap just don't cut it for anything more than a simple app. While React Native has its pros and cons, it hasn't won me over as a developer. Instead, I prefer the idea of having a cross-platform core and native UI. As someone who switched from Android to iOS around the time of KitKat (4.4? 🤔), As I'm naturally more inclined towards llvm based languages, C++ was my first choice for a cross-platform code. On iOS it's relatively easy to bridge C++ and Objective-C through a mix of both called Objective-C++. I've worked on some big projects that were heavily based on this idea, and I can attest that it's a working solution. However, Objective-C is becoming less popular every day, and Objective-C++ is an even scarier beast to work with. I can't say that I found writing it enjoyable. Furthermore, I can't see any compelling reason to write application-level code in C++. Perhaps for OS-level code, but that's a topic for another discussion. After a few attempts with C++, I tried Kotlin Native (KN), which had much better tooling and IDE support, even in the earliest versions. Kotlin is a fun language to read and write, and with the "Native" part, we can even rid ourselves of the JVM. So if you're already immersed in the Android ecosystem, love Kotlin, and enjoy working in Android Studio, then KN should be a good choice for you. However, in this article, I'd like to explore a more "rusty" perspective. Let's dive in.

I've dabbled with Rust on iOS a few times, and it seemed a lot like C++. You build a static library, use C headers as glue, and end up struggling with debugging. This approach is straightforward when you're only extracting a small piece of logic into a shared library and interacting with it through a thin interface. But what if you want to put most of the app logic into the shared lib? That's when things get tricky.

Recently, I stumbled upon a project at the Rust London conference that caught my eye. It's called Crux, and it's a library that helps you implement a functional core and imperative shell paradigm. In other words, it allows you to separate your app logic from your UI code, and share it between platforms.

Although the idea of a functional core and imperative shell might sound straightforward, the actual implementation can be tricky. As you start working on it, you'll inevitably run into obstacles and challenges, especially when it comes to separating the core logic from the user interface.

Second biggest challenges after "variable naming" is finding the appropriate architecture to use. Traditional MVC/MVP architectures may not always be the best fit, and I found it difficult to keep track of all the data flows in applications I used to work with. Additionally, real-world user interfaces can be complex and dynamic, which adds even more states and interactions to the UI layer.

This is where functional concept of free from side-effects Core comes in. Crux helps to build foundation. For me, it's been really helpful in figuring out how to structure my code and how to isolate the core logic in a way that's both ergonomic and easy to read. In a few hours I created a small app that interacts with the DALL-E APIs (pretty obvious, right?) and works on 3 platforms (actually 2.5 as I haven't finished web 😅). In the following section, I'll share my initial impressions.

Setup

Since the project is in its very early stages, setting it up isn't quite as seamless as with React Native. However, it's not a big deal to contribute to the tooling in-house if you decide to go with this stack for a real project. In fact, most big projects, even single-platform ones, contain a zoo of different bash scripts and make files anyway. The book has a really good explanation of how it works and even provides example apps.

Personally, I found it better to set up the project from scratch using the book. That way, I was able to see all the places to look if something went wrong. It took me less than an hour to set up the core and iOS project, and the process was straightforward. Luckily, the core configuration is in .rs and toml files, which are very easy to follow.

For iOS, you need some bash scripts (oh, I hate writing bash). But in my case, copy-pasting was enough, and ChatGPT made life bearable even if some customisation in bash is needed. Long story short, you need to compile the core as a static library, generate UI languages bindings using the uniffi crate, and add these steps to the Xcode project so you don't need to rebuild and relink the core manually. The uniffi requires to write an IDL Interface Definition Language file describing the methods and data structures available to the targeted languages. I generated Swift/ Kotlin and TS for iOS/Android and Web respectively.

UDL looks like this:

namespace core {
  sequence<u8> handle_event([ByRef] sequence<u8> msg);
  sequence<u8> view();
};

At the end, the project structure looks like this (no Android and web on the screenshot):

Development

When it comes to development, you'll probably be splitting your time between Xcode/Android Studio and whatever you prefer for Rust and web development. I've seen some brave souls trying to do mobile development in Emacs, but at the end of the day, they were significantly slower than their teammates.

The good news is that it's quite convenient to work on the core first, crafting the interface and writing tests, and then switching to Xcode/Studio to polish bits of the Core in parallel. Personally, I use CLion for Rust and I don't dare to open more than 2 out of the 3 (CLion/Xcode/Android Studio) at once. Rust compiles quite slowly, which isn't a problem for me since my Swift/ObjC project at work took around 50 minutes for a clean build on a top configuration MacPro(not a MacBook 🐌). However, for web developers, this might be a bit of a drag. But proper project modularization can help with this.

Writing code in Rust can be a bit challenging at first, but I found that a lot of the ideas are similar to Swift, so it's not like a completely different experience. Enums like in Swift, isn't it? 😁

#[derive(Serialize, Deserialize)]
pub enum Event {
    Reset,
    Ask(String),
    Gen(String),
    #[serde(skip)]
    Set(Result<Response<gpt::ChatCompletion>>),
    #[serde(skip)]
    SetImage(Result<Response<gpt::PictureMetadata>>),
}

When it comes to debugging, you can use breakpoints through the lldb "breakpoint set" command to debug both the Swift and Rust code in your linked static library. It's not as convenient as debugging a pure Kotlin project in Android Studio, but it still gets the job done.

E.g missing .env variable error easily identifiable even from within Xcode.

Exact line in the logs:

However, I couldn't see any issues with debugging the core and shell separately. In fact, it can be quite helpful to be able to debug each component independently, as it can make it easier to pinpoint the source of any bugs or issues.

What about interop... I'm not going to lie, it's not ideal. In particular, interop between Rust and Swift isn't as seamless as it is between Swift/Objective-C and Kotlin/Java. For example, f64 can't be passed as is through the boundary ( which is logical, but still). However, there are some cheat sheets available to help make sense of the interop rules. For Swift, the following rules apply:

Primitives map to their obvious Swift counterpart (e.g. u32 becomes UInt32, string becomes String, etc.).
An object interface declared as interface T is represented as a Swift protocol TProtocol and a concrete Swift class T that conforms to it.
An enum declared enum T or [Enum] interface T is represented as a Swift enum T with appropriate variants.
Optional types are represented using Swift's built-in optional type syntax T?.
Sequences are represented as Swift arrays, and maps as Swift dictionaries.
Errors are represented as Swift enums that conform to the Error protocol.
Function calls that have an associated error type are marked with throws in Swift.

I remember similar rules for Kotlin Native. Actually, the interface between the core and shell should be laconic. I don't think these limitations are good, but they don't hurt too much either.

Architecture

Talking about architectural patterns. Have you seen mobile Eng who are not talking about patterns? Crux is inspired by Elm, there is quite good page in the book and also Elm docs worth reading, so let’s skip the description. In general I see movement to unidirectional and message passing architectures. They are clean and quite strict, which makes it easier to update code and not introduce inconsistency when one text field has three different states across layers. True that UIKit or Vanila android libraries are not the best fit (though still possible to reuse some ideas), but SwiftUI and Jetpack Compose fit quite nice. If you write gesture interaction and animation heavy UIs - this would be challenging. Like if you do some gesture driven transition, should you keep current state in UI or pass it to the core? Or UITableView (iOS) and RecyclerView (Android) have a bit different lifecycle for cells, hence for cell models, how core will be dealing with it. A bit challenging, but still possible, no silver bullets as always.

The part that I liked the most, though, was the capabilities feature. Capabilities provide a nice and clear way to deal with side effects, such as networking, databases, and system frameworks. Sure, you could write a single HTTP library in C and use it everywhere, and maybe you could even standardize persistence to use only SQLite. But there are so many different things to consider, such as audio/video, file systems, notifications, biometrics, or even peripherals like the Apple Pencil. And your system already has good libraries to deal with these things, which might even be optimized ( quality of service or URLSession configuration on iOS) to be more effective. That's where capabilities come in - they allow you to declare what you need, while keeping the implementation specifics for the platform code. It's a great way to keep your code modular and maintainable.

When core handles event that need to make an HTTP call, it's actually instructing Shell to do the call.

fn update(&self, event: Self::Event, model: &mut Self::Model, caps: &Self::Capabilities) {
        match event {
            Event::Ask(question) => {
                model.questions_number += 1;
                gpt::API::new().make_request(&question, &caps.http).send(Event::Set);
            },
...

And shell is sending request

switch req.effect {
            ...
            case .http(let hr):
                // create and start URLSession task
            }

The same logic can be applied to databases (just separate KV-storages and relational), biometric, whatever else.

Final Thoughts

Despite the fact that I'm new to Crux and not yet fluent in Rust, I was able to build a simple app that works on iOS, Android, and Web (almost) in less time than it would have taken to build all three from scratch.

Crux is still in its early stages, e.g. at the time of my note, the HTTP capability didn't support headers and body. But I have high hopes that this project will continue to grow and attract more contributors, as the idea behind it is really cool.

Even if you don't want to use Rust for cross platform development, I think it's worth taking a look at this project to see how you might be able to reuse some of the ideas in your favourite stack. At the end of the day, anything that helps us write better, more modular, and more maintainable code is a win.

Unveiling the Power of Proxies for Mobile Clients

complexityclass — Sun, 26 Feb 2023 21:17:21 +0000

It's pretty common for mobile applications to participate in client-server communication. As a mobile developer, you may build apps that communicate with your own trusted server. However, there might be cases when you need to communicate with third-party servers. In such situations, you may not want to expose the IP address of your mobile client. To solve this issue, using a proxy server appears to be an obvious choice. So in this article, I'm going to show you one way you can use a proxy in your systems to improve privacy. And, based on my experience, there are a few things that mobile engineers might find helpful to navigate this topic further.

Proxy 101

Proxy servers are quite helpful for a variety of reasons, such as content filtering or caching, but their main purpose is to provide privacy and security. While SSL and TLS already do a great job of securing communication, a proxy server can add an extra layer of protection.

Client-server with a proxy

In a typical HTTPS connection between a client and a server without a proxy in the middle, the traffic is secured with the Transport Layer Security (TLS) protocol. When a client sends a request to the server, the TLS protocol ensures that the data is encrypted before it is transmitted over the network. Once the server receives the encrypted data, it decrypts it using a private key that only the server has access to.

However, even though the traffic is encrypted, the server can still see the IP address of the client, which may reveal sensitive information about the client's location or network configuration. This is where a proxy server or other techniques come into play to provide additional privacy and security.

Proxy or VPN?

When you want to keep your IP address hidden, you have two popular options: a proxy server and a virtual private network (VPN). Here's how they work:

A proxy server acts as an intermediary between the client and the server. This means that it forwards requests from the client to the server and then returns the server's response back to the client. The server sees the IP address of the proxy server instead of the client's, which provides an additional layer of privacy.
A VPN creates a secure, encrypted connection between the client and a remote server. All traffic is routed through the remote server, which masks the client's IP address and provides an added layer of security. However, setting up a VPN can be more complex than using a proxy server. It may also conflict with the VPN proxy, block traffic that is not routed through the VPN tunnel, and require additional resources.

To set up a VPN proxy with the Network Extensions framework, you'll need to create a new Network Extension target in your Xcode project and implement a few delegate methods. You will also need to configure the tunnel provider with the details of your proxy server, such as its hostname and port number.

The Many Shades of Proxies

Proxy servers have a long history. There are actually a bunch of different protocols you can use with them, like SMTP, SOCKS, and FTP. But for now, let's focus on HTTP(s).

The main thing to know about HTTP vs HTTPS proxies is that HTTPS uses SSL/TLS encryption to keep your data safe. That means when you use an HTTPS proxy, your data is encrypted from the moment it leaves your device until it reaches the server, which makes it a lot more secure.

On the other hand, HTTP proxies don't encrypt your data, so it's visible to anyone who might be snooping around. While they can be helpful for caching and filtering web traffic, they're not great for sending sensitive information. So if you're doing something like online shopping or sending private messages, it's definitely a good idea to use an HTTPS proxy.

It's worth mentioning that proxies come in all shapes and sizes, not just protocols. Did you know that even http(s) can have different types? The most common ones are forward and reverse proxies. A forward proxy acts as a middleman between a client and a server, while a reverse proxy acts as a middleman between a server and the internet.

Forward proxy

Acts as an intermediary between a client and a server
Client initiates the request
Used to provide anonymity or bypass firewalls
Commonly used for content caching and filtering
Usually deployed in client networks

Reverse proxy

Acts as an intermediary between a server and the internet
Server initiates the request
Used for load balancing, content caching, and enhancing security
Commonly used to distribute traffic across multiple servers
Usually deployed in server networks

Ensuring a well-distributed infrastructure and protecting client anonymity are crucial. To maintain anonymity, a significant number of clients should be hidden behind the proxy address. In practice, a combination of reverse-proxy and forward-proxy is often used. For simplicity, the examples below will only use one forward proxy.

HTTP: Connecting people packets

Okay, so proxy servers are pretty popular these days. In fact, the HTTP protocol has a whole method just for them called HTTP CONNECT. This method helps you create a safe tunnel through an unsafe network, like the internet. When you're using HTTP Connect to connect to a server, you send an HTTP CONNECT request to the proxy server, and you just need to let the proxy server know the hostname and port number of the server you want to reach.

The proxy server then establishes a two-way communication channel with the destination server and passes data between the client and server, allowing the client to communicate with the server securely. This method is commonly used to establish SSL/TLS encrypted connections between a client and server. It can be used for a variety of purposes, such as bypassing firewalls, establishing secure communication channels, and enabling remote access to internal networks.

HTTP CONNECT setup

If you're a mobile developer, you probably use methods like GET, POST, and PUT all the time. But have you ever used CONNECT? Let’s explore how to get URLSession to use it, or whether you should go with a more hardcore library.

So check it, the first thing - you can totally set up a proxy address in the session configuration. No big deal, just wanted to give you the heads up.

// Create a session configuration object
let config = URLSessionConfiguration.default

// Create a proxy object with your desired host and port
let proxy = [kCFNetworkProxiesHTTPSEnable: true,
             kCFNetworkProxiesHTTPSProxy: "your.https.proxy.host",
             kCFNetworkProxiesHTTPSPort: 8080] as [String: Any]

// Set the proxy on the session configuration
config.connectionProxyDictionary = proxy

// Create an NSURLSession with the configuration
let session = URLSession(configuration: config)

One way to understand what's happening under the hood is by intercepting the traffic using Wireshark or any other tool you prefer. Alrighty, just fire off a GET request to your fave endpoint with this session and we're good to roll.

Tcp dump from the wireshark

So get this, tcp dump shows that the client is actually sending a CONNECT for us behind the scenes. Pretty good!

Setting up Android is just as easy and you'll still get the same results.

// Create a URL object for the destination server
val url = URL("https://www.example.com")

// Create a Proxy object with your desired host and port
val proxy = Proxy(Proxy.Type.HTTP, InetSocketAddress("your.https.proxy.host", 8080))

// Open a connection to the URL with the proxy
val connection = url.openConnection(proxy) as HttpURLConnection

Houston, We Have a Problem (Again)

Alright, so is the case all wrapped up? Or is there still more to it? Actually, on top of the VPN, iOS/Android has a nifty feature that lets you use a system-level proxy setting for a specific Wi-Fi network. This is mainly used by big-shot companies that have their own devices to manage. But this led us to a new issue with changing the system proxy configuration: when you set a new proxy config through session configuration, it overwrites the user's current settings for any requests handled by those sessions.

Note that by overriding, we only mean session-level requests (i.e., requests served during your app session) rather than app or device-level requests, which will not be affected.

You might decide to override the default settings, but this could have the following consequences:

No connectivity, as the ISP/network can require all traffic to go through the proxy.
Loss of privacy for the user, as they may be using the proxy for additional privacy.
Malfunction of some features (e.g. payment due to geo-blocking).

Okay, so let's say we want to keep both proxies, right? No worries, because the cool thing about network protocols is that you can layer them on top of one another, which makes them really powerful. One way to do this is by nesting one tunnel inside another. For example, you can open one connect tunnel through the system proxy and then nest it inside a second tunnel that goes through a forward proxy.

The diagram from before will be updated in the following manner

Double HTTP CONNECT setup

So, the diagram might seem a bit more complicated, but it's actually just duplicating the same mechanism for two proxies. The only issue is that the default iOS/Android libraries don't support this out of the box, so we'll need to put in some extra work. To get around this, we can go one level down and use Network.framework on iOS, subclass NWConnection, and handle it manually.

So Much to Proxy, So Little Time

Alright, let's wrap up this article so it doesn't drag on. We've gone over how using proxies on mobile clients can improve security and privacy for our users. We also talked about the differences between VPNs and proxy servers, and delved into the two most common types of proxies: forward and reverse proxies. Lastly, we checked out client libraries and how they can help with proxies, as well as their limitations.

Keep an eye on the next article where we'll try to mix and match proxies. We'll be using NWConnection and might even do some byte juggling. Stay tuned!