TL;DR: The Microsoft App Center offers build servers in the cloud and allows for easy distribution and test running (on a real device). For Expo users, this is the best way I’ve found to build a standalone app while still retaining the ability to add custom native code.

This is a continuation from my previous article where I describe the essential functionality of the Expo platform. Expo can solve a lot of initial problems faced in mobile development, but it’s not an ultimate weapon when your app needs uncommon features. Be warned though that by detaching you are probably opening a huge can of worms being a JavaScript developer.

Update: If you feel like losing battle with ExpoKit, you can ditch it completely.

What is ExpoKit and why would you need it?

The Expo SDK contains a runtime called ExpoKit which is capable of downloading the JS bundle from Expo servers and running it for a user. Under normal circumstances, the ExpoKit is built into the Expo app, which will be used during the development, staging, and testing phases of your project.

Now imagine that you have gotten comfortable with Expo itself, and you love its ability to publish your code easily and share with other people. Building standalone apps has become a breeze. However, at some point, you decide to add a new feature to your app that is covered by neither the Expo SDK nor React Native. What to do now?

In this situation, you will need to detach to ExpoKit. In other words, it means that you can still use the ExpoKit’s capability to download and serve the JS bundle, but you can also modify the native code of your app. The ExpoKit will become just another part of your native application.

The apparent downside is, that from now on you will have to build the native part of an application yourself. Expo build servers cannot handle custom native code. That means back to Android Studio / XCode, right? Not exactly. :)

Detaching to ExpoKit is a simple and automated process. You probably won’t run into any issues on MacOS. For Windows and Linux people, there is definitely one big obstacle. You cannot bootstrap an iOS project without a Mac machine. Detailed reasons are unknown to me, let’s just say: It’s Apple.

Probably the easiest solution is to ask some friend with a Mac to do it for you, or try to rent a Mac machine in the cloud. The good thing is, you only need to do this once. Buying a Mac just for this reason is most likely overkill.

Microsoft App Center lifts some weight

I did not trust it either at first: how could Microsoft solve something like building mobile apps for Android and iOS? As usual, the path is not entirely obvious for iOS, and you won’t be able to avoid paying for a developer license. Enough promotion, let’s dive into the various issues I had while working with this platform.

The Microsoft App Center (AC from now on) is very easy to setup:

Create an account.

Add an app (for each platform separately).

Connect it to some source control (GitHub, BitBucket…).

Configure build (the default works just fine).

Every time you push the code into the linked repository, it will make a build for you and notify you when it’s ready. You can also have different configurations per repository branch. It’s kinda similar to building standalone apps with Expo, however you have much more fine-grained control, and you can also see full logs from the process. Isn’t that neat?

The official Getting Started guide will try to tell you to include additional modules (eg. mobile-center-crashes) into your project. Note that these are not mandatory. Add them only if you want to start using extended services provided by the platform. I recommend to try out a simple, basic build first.