Forem: App & Flow

Make your own Alexa Skill without using Lambda

App & Flow — Thu, 23 Jan 2020 20:55:33 +0000

“Your scientists were so preoccupied with whether or not they could, they didn’t stop to think if they should.” — Ian, Jurrasic Park

Why should you even bother making your own custom Alexa Skill without using Lambda?

Actually, a few reasons come to mind :

You don’t like depending on other services
You enjoy tinkering / you consider yourself a DIY-er
Your Alexa Skill will be used alongside an existing service that already has its own backend (like a mobile app or a web page) and you’d rather this backend handles everything.

It’s obvious from this list that doing all of this isn’t for everyone. Actually, more people would benefit from using Lambda, as long as you don’t go over their very generous 1 million requests / month free-tier. Check out Amazon’s list of why you should use Lambda just to get an idea.

You’re still reading? Good. Just before we dive deeper, here’s a fictional service that we’ll use as a reference point throughout this article :

Your startup has a mobile app that keeps track of bus schedules. Groundbreaking, never-seen-before, edgy, right? Anyway, this mobile app communicates with your backend that handles communication with the transit company’s API. Users can create their own account and keep track of their favorite bus routes. Your app is doing well already, but so many users are writing to tell you that it would perfect if only you had an integration with Alexa. This is how you embarked on this journey.

You’ll need the following to be able to complete this tutorial :

A node.js backend hosted somewhere like on DigitalOcean or AWS. (any backend would do, you can recycle the concepts used here on pretty much anything)
A website that lets users log in to their account
A few use cases for the skill
A mobile phone with the Alexa app installed (no need to have an actual Alexa device!)

Use cases

Coming back to our bus schedule startup, some good ideas for use cases could be :

Alexa, when is the next 105 passing? -> Should tell me the amount of minutes to the next bus passing. For example “The next 105 passes in 10 minutes”.
Alexa, are there any interruptions in the metro today? -> The transit company’s API can tell us wether or not there are interruptions at the present time. For example “Yes, the purple line is down until 9:15PM”.
Alexa, what is the next bus? -> If the user has set up 2 busses leaving from their home, this service could tell them which one of these busses is passing next. For example “The next bus is the 105 which is passing in 5 minutes”.

Setting up the Alexa Developer Console

Create an account if you don’t already have one on Developer Amazon
Go to the Alexa Developer Console
Create a new skill : give it a name, use the “custom” template and “Start from scratch”. You should see this :

This is where you’ll be doing most of the “Alexa developer” work. The following list is a short summary of this Alexa page :

Intents : An intent represents an action that fulfills a user’s spoken request
Utterances : A set of likely spoken phrases mapped to the intents
Custom slot types : A representative list of possible values for a slot

So coming back to our use case “Alexa, when is the next 105 passing?”, this utterance would be handled by an intent that we can call findNextBus for example. The 105 will be a custom slot type that we can define as busNumber that has the type number.

As this tutorial isn’t meant to be a “how to create an Alexa skill” but more how to make it work without lambda, I’ll let you read one of the many articles on the subject (or just figure it out as you go along, it’s really nothing special).

The endpoint section should be set to HTTPS and should point towards a route that handles Alexa’s requests (ie : https://api.mywebsite.com/alexaAction). During development, you can use ngrok to simulate an HTTPS connection, just make sure to set the SSL certificate type to the one that says “[..]is a subdomain of a domain that has a wildcard certificate[..]”.

The account linking section is optional in case you don’t plan on having users sign in to their account. For our example, we’ll need to set it up. These are the fields you’ll need to fill in this section :

Authorization URI : The URI where customers will be redirected to in the companion app to enter login credentials.
Client Id : Unique public string used to identify the client requesting for authentication. You can use your preferred way of generating strings (here’s some for inspiration) or just let your cat walk over your keyboard, your call. Just keep it somewhere as your backend will have to validate this client id.

That’s about it for the Alexa Developer stuff. Once you’ll have something functional, you can apply for certification.

Setting up your backend

Let’s assume for this example that you’re using a simple MVC-inspired “router → controller → service” kind of pattern on your backend.

Usually, this would mean your route /alexaAction would call a controller, who would in turn call the service; the service would do the job, return the information to the controller that takes care of sending the info back. But in our case, we first need to make sure that the network request is actually coming from Amazon, and the easiest way I’ve found is to use an auth middlewear. But it doesn’t end there. The only way to make sure that the request really comes from Alexa is to have access to the raw request body, before body parser does it’s job. This means that your Alexa route cannot be mixed in with your current router, it will have to be separate. Your app.ts will look like this :

app.post(‘/alexaAction’, alexaAuth, alexaActionPost);
app.use(bodyParser.json());
app.use(bodyParser.urlencoded({ extended: false }));

For the alexaAuth middlewear, I heavily inspired myself from the lib alexa-verifier-middlewear. It wasn’t exactly what I was looking for, so I made my own middlewear with the code :

import { NextFunction, Response } from 'express';

import { Request } from '../types';
import verifier from 'alexa-verifier';

const auth = (req: Request | any, res: Response, next: NextFunction) => {
  try {
    if (req._body) {
      const er = 'The raw request body has already been parsed.';
      return res.status(400).json({ status: 'failure', reason: er });
    }
    req._body = true;
    req.rawBody = '';
    req.on('data', data => {
      return (req.rawBody += data);
    });

    req.on('end', () => {
      let er: any;
      try {
        req.body = JSON.parse(req.rawBody);
      } catch (error) {
        er = error;
        req.body = {};
      }

      const certUrl = req.headers.signaturecertchainurl;
      const signature = req.headers.signature;

      verifier(certUrl, signature, req.rawBody, (error: any) => {
        if (error) {
          res.status(400).json({ status: 'failure', reason: error });
        } else {
          next();
        }
      });
    });
  } catch (e) {
    req.user = null;
    return res.status(400).json({ message: 'Unauthorized' });
  }
};

export default auth;

With this in place, your backend is listening to the route /alexaAction and we can be sure that anything that gets to it will be coming from Amazon.

Up next, you’ll need a way to handle the post itself. I’ll explain the bigger picture, but you should implement it in whichever way you want. Also, I’ll explain the flow that includes user authentification, so if you don’t intend on doing that you’ll be able to skip certain parts.

To start, you’ll need to get session, context, request from the body’s request. You’ll also need applicationId from context as well as type from request.

const { session, context, request } = req.body;
const { applicationId } = context.System.application;
const { type } = request;

Then follow these steps :

validate that the applicationId is the same as your alexaSkillId
check the type : a LaunchRequest type should return an introductory message that will ask the user what they’d like to know about your service (for example “How can I help you with the bus schedules today?”) whereas an IntentRequest signals that the user is asking a question that needs an answer (like “When is the next 105 passing?”)
if you get an IntentRequest, you’ll be able to find the user’s accessToken like this : session.user.accessToken . You should use your own validation system to validate the token (this token is what your frontend (where you handle your login) will be giving Amazon once your user logs in, more on that later)
remember the list of intents that you created such as findNextBus? You’ll need to provide an answer. The intent can be found here request.intent . Personally, I made a simple switch that covers all possible intents. If you have custom slots, they can be found at request.intent.slots .

A very barebones, watered down, happy-path, no error management version of all this would like something like this :


function handleAlexaQuery() {
  if (applicationId === config.alexaSkillId) {
    if (type === 'IntentRequest') {
      if (session.user.accessToken) {
        // authenticate your accessToken
        if (authenticated) {
          const { name } = request.intent;
          if (name === 'findNextBus') {
            const busNumber = request.intent.slots.busNumber.value;
            if (busNumber) {
              // generate logic that will answer when the next bus is passing
            }
          }
        }
      }
    }
  }
}

At the end of the day, you want to take the text you’ve generated and send it back to amazon. It needs to be in this format :

response = {
  response: {
    outputSpeech: {
      type: 'SSML',
      ssml: `<speak>${speechText}</speak>`,
    },
    reprompt: {
      outputSpeech: {
        type: 'SSML',
        ssml: '<speak>Could you repeat?</speak>',
      },
    },
    shouldEndSession,
  },
  version: '1.0',
  sessionAttributes: {},
};

In this example, speechText is the text that you want Alexa to say. There are many intonations and ways of pronouncing words using ssml but this way is the most basic one. shouldEndSession should be either true or false, depending on your use case : sometimes you want to close the skill after the user has answered, other times you want to keep it open.

If a user is not authenticated yet, or started authentification and didn’t go through with it successfully, Amazon forces you to show the user a card that pops up and asks the user to sign in. You have to add

card: {
  type: ‘LinkAccount’,
},

to your response, within the response attribute.

Setting up the frontend (website)

In the Alexa app, the user will add the skill and will see a big button “Enable to use”. This button will redirect to your website, the user will log in, and if successful, they’ll be synced.
Upon loading, your website will have to take three paramaters from the search params (or query params if you prefer) : state, client_id and redirect_uri
Amazon will give you a few acceptable redirectURLs, you need to make sure that your website verifies this and gives an error otherwise. You’ll find the list of redirectURLs in the Account Linking section.
You also need to verify your clientId (the one you generated earlier on) to make sure it’s valid
Once the user logs in, the last thing left is to create a new url based on the the params you isolated earlier (redirectURI, state, access_token as well as adding token_type=bearer) and navigate to that new url.

That’s it.

Recap

Now you’ll have your Alexa Developer Console, your backend and your website working together :

Your bus schedule user can sync their current account to Alexa by using the Alexa app and selecting “Enable to use”. This will open up your …
…website. They will log in to their bus schedule account. When they’ll ask “Alexa, when is the next 105 passing?”, this will talk with your…
…backend that will handle the query and answer back to Alexa. Your backend must handle all queries that you’ve defined in your…
…Alexa Developer Console.

“Now my boss is asking me to implement Okay Google as well!”

Fear not, most of the info here could be recycled into having your own Google Home action. Theoretically, on the backend side of things, the part that creates the speech response could be made generic enough to work for both services if the same intents are developed on Alexa and Google. The website part is also almost the same, it’s mostly the Actions on Google part that is different. The vocabulary is similar for many terms too, and you can deduce the other ones like Alexa Skill = Google Action.

One thing to keep track of with Google is that they have 2 types of Actions : Conversational Actions and Direct Actions. What you’ll be looking to implement is Conversational Actions, as Direct Actions are for cases when you have a smart device that you’d like to sync with your smart home and all that jazz. It’s a different ballpark altogether.

Google has their own Lambda equivalent called Dialogflow, which you won’t be using hehehe. Their documentation is also pretty straightforward. Enjoy!

ELI5: “Sign in with Apple” for React Native using Expo SDK35 & Node.js

App & Flow — Thu, 23 Jan 2020 20:55:14 +0000

Thanks to Vincent de Lafontaine, without his help this article wouldn’t exist.

We too usually skip to the code snippets, so we won’t judge if you do. Just keep in mind that there’s a bunch of configuration to do on the Apple Developer side of things.

The Expo documentation regarding “Sign in with Apple” is pretty straightforward : you create a button, it calls a function, the user puts in their Apple info, and la dee da you are authentified.

Here’s the button almost exactly as what Expo shows you

<AppleAuthentication.AppleAuthenticationButton
  buttonType={
    AppleAuthentication.AppleAuthenticationButtonType.SIGN_IN
  }
  buttonStyle={
    AppleAuthentication.AppleAuthenticationButtonStyle.WHITE
  }
  cornerRadius={5}
  style={{
    width: 150,
    height: 40,
    marginRight: 20,
  }}
  onPress={this._loginWithApple}
/>

note that you’ll have to pass it a width and a height, otherwise the button won’t show up (that’s the official workaround for now)

When you press the button, it should call this :


applePayload = await AppleAuthentication.signInAsync({
  requestedScopes: [
    AppleAuthentication.AppleAuthenticationScope.FULL_NAME,
    AppleAuthentication.AppleAuthenticationScope.EMAIL,
  ],
});

signInAsync returns a promise that resolves to an object containing an authorizationCode(among other things). This is what you want to send to your backend.

But what then? What do you have to do on the backend to handle this information?

You know the drill : your route gets an access token from the provider, you send the access token to their API, if valid it returns an object containing some info about the user such as name, email, etc. that you can use in your login or signup flow. You’ve already done it for Google, Facebook, Twitter, Myspace (yeah, no).

It should be easy.

Well it ain’t. Apple said “screw this, it’s not good enough for us” and did things a bit differently. You know Apple, they always need to do things differently.

Here are a few things to know about the apple sign in before we start :

If you want to validate your authorizationCode with Apple, you need to be enrolled in the Apple Developer Program (💰).
The user can decide to “Sign in with Apple” and choose not to share their email address, in which case you’ll receive a proxy email instead.
Apple will only send you back the user’s email (or proxy email) the first time a specific user authentifies themselves. This means that if the user logs out and logs back in, you won’t get their e-mail the second time around. So keep in mind that if you need the user’s email, you should persist it.
The whole frontend part of this flow will only work on standalone builds. It will fail if you try it within Expo.
“Sign in with Apple” only works for iOS 13, and the button will only appear if that condition is met.

To give you a bigger picture, these will be the steps to follow (all these points will be explained in detail later) :

Pre step : Do all the configuration on the Apple Developer portal

Step 1 : Create a route on your backend that will receive the payload
obtained from the Expo AppleAuthentification module (as shown previously in the signInAsync example). This payload contains an authorizationCode

Step 2 : Create your own json web token (jwt) which will be your clientSecret

Step 3 : Authenticate your authorizationCode

If successful, Apple will send you back a tokenResponse.

Pre step : Start with all the Apple Developer config stuff

Login on the Apple Developer portal
Go to Certificates, Identifiers & Profiles
Select Identifiers, choose your app and check the “Sign in with Apple” capability. If it’s your first time doing this, you’ll need to create a new app identifier. Make sure to use the same bundle id as in your app.json
Go to keys and create a new key, give it a pertinent name and make sure to check “Sign in with Apple”. Download the key when you’ll have the opportunity and keep it somewhere safe

Devs who implement “Sign in with Apple” on web have a few more steps to follow, but we don’t need to worry about them #mobileDevMasterrace (just kidding.)

You should then have the following items :

Team Id : you can find it if you go to Membership details, but it’s also on the app’s Identifier page

Key Id : You can get it in the Keys section you just created

A secret key file that has a “.p8” extension
Not related to the Apple Developer stuff, but make sure you also have a bundle id (the same as in your app.json file).

Step 1 : Your backend receives a payload from your mobile app

Not much to do here other than get the attribute authorizationCode out of the payload.

const { authorizationCode } = req.body.applePayload;

Step 2 : Create a clientSecret jwt

This part draws inspiration directly from this article (thanks Arjun Komath!)

You’ll need your key id, your team id and your bundle id, as well as your secret key file.

In the following code snippet, I’ll be using fs-extra as a drop-in replacement for the module fs from node. The advantage of fs-extra over fs is that readFile is already promisified and can be awaited.

import fs from 'fs-extra';
import jwt from 'jsonwebtoken';

const getClientSecret = async () => {
  const privateKey = await fs.readFile(process.env.PRIVATE_KEY_FILE_PATH);
  const headers = {
    kid: process.env.APPLE_KEY_ID,
    typ: undefined,
    alg: 'ES256',
  };
  const claims = {
    iss: process.env.APPLE_TEAM_ID,
    aud: 'https://appleid.apple.com',
    sub: process.env.APPLE_BUNDLE_ID,
  };
  const token = jwt.sign(claims, privateKey, {
    algorithm: 'ES256',
    header: headers,
    expiresIn: '24h',
  });
  return token;
};

Step 3 : Validate your authorization code

This part is flexible, feel free to fetch in whichever way you prefer. The idea is just to pass it authorizationCode, clientSecret and clientId (=== your bundle id). Also grant_type=authorization_code as we’re validating the authorization code.

const urlBody = `code=${authorizationCode}&client_secret=${clientSecret}&client_id=${clientId}&grant_type=authorization_code`;

const res = await fetch(`https://appleid.apple.com/auth/token`, {
  method: 'POST',
  body: urlBody,
  headers: {
    'Content-Type': 'application/x-www-form-urlencoded',
  },
});

That’s it. You either get a 200 and a tokenResponse or a 400.

“But if Apple doesn’t give me the user’s email every time, how do I keep track of users?”

Both the payload sent from your mobile app and the token sent by Apple contain an identity token (the expo module calls it identityToken while Apple calls it id_token). These tokens can be decoded using jwt.decode. Once decoded, they contain a sub attribute which is unique to each user. So you can simply add a sub field to your user, and validate them that way.

Why hiring an in-house developer for your seed funded startup is riskier than you think

App & Flow — Fri, 29 Nov 2019 16:54:05 +0000

I have been wanting to write about this topic for a long time now, but I have been sitting on the idea because:

a) I am obviously a little biased. We run a software consultancy!
b) I dislike confrontations, and I know this won’t fly with some of you.

Hear me out…

It’s a common belief in the startup world that you shouldn’t outsource the development of your first app. It’s better to hire an in-house team, the thinking goes, because an agency will never care as much as an employee. The quality of work won’t be as good. You’ll be just another client to them.

I couldn’t disagree more.

I understand this argument. I really do. There are a lot of truly terribly agencies out there. Even if you find a good one, committing your app to another company can feel really risky.
But if you’re a seed-funded startup, hiring a full-time developer is even riskier. Here’s why.

The Risks of Hiring an In-House Dev

We have helped 20+ teams by building scalable, maintainable and high quality applications. Some of those companies first approached us with a code base that was “95% finished” and hoped we could hop on and quickly finish the job. When we ask why they haven’t completed and launched the application, they almost always tell us the same story: they hired an in-house developer, and that person left, wasn’t working out, or just disappeared.

Unfortunately, as soon as we start looking at the code base, it’s often full of spaghetti code, hundreds of libraries, crashes here and there, no typing, no linting, the list goes on. We usually have to suggest a full rebuild. (Note: We don’t do this to make more money — in most situations, a full rebuild is actually faster and cheaper for the client than trying to fix the existing code base!)

If you’re a founder, you’re now in an extremely tough spot. You spent most of your seed funding on a developer. That developer didn’t work out, and now you have to start from scratch again with less time and less money than you started with.

The Best Developers Are Already Taken

I know what you’re thinking. Of course hiring a bad developer is a terrible mistake. But what about hiring a good developer?

According to Silicon Valley Bank 2019 Outlook US Report, the number one issue startups are facing is access to talent. “More than 80 percent of US startups say they plan to add employees in 2019, but 29 percent recognize it is extremely challenging to find talent with the necessary skills to grow their businesses”

Sure, there are lots of talented developers out there. The problem is that most (if not all) of these awesome developers, just like startup founders (more on that later), want to minimize risk. They have bills to pay, families to support, and an extremely in-demand skill set. Most of them won’t be interested in working for a seed-funded startup that could shut down at any time when they have the opportunity to work for bigger, established companies that can offer more stability, better pay and huge perks.

Note: If you have managed to find that one developer in 1,000 who’s extremely talented and willing to work for you, congrats! Feel free to ignore the rest of this article… until that person leaves for a higher-paying job. 😄

You Can’t Afford the Risks of In-House… Yet

Startup founders are often seen as people who are willing to take a huge amount of risk, which is absolutely true — working on a startup is extremely hard and the chances of success are slim.
However, in the day-to-day, seed stage founders should be doing everything they can to avoid unnecessary risk.

Seed-funded startups have the time and runway to build and market ONE great application — but not two.
These companies cannot afford to waste 5 months of time and money on a code base that needs to be scrapped. But I’ve seen this exact situation again and again with founders from all kinds of startups.
Hiring an established, reputable agency to build your app is actually the least risky choice.

Why an Agency is Less Risky than a Hire

The product you offer will make or break your company.
Getting users to actually download and use your application is both critical and really difficult to do. A great application will impress your users, keep them engaged and bring them back. A poorly-built application is the best way to make your users uninstall your app seconds after they downloaded it and never look back. Demoing your product to an investor and having it crash (or work in a very limited way) is a very good way to minimize your chances of getting that glorious Series A.
That’s why I truly believe the right choice is to work with a reliable agency, one that’s trusted by other startup founders and the development community.
(The only exception to this is if you or a co-founder can build the product yourself. In that case, I fully agree that you should keep development in-house.)

If you aren’t a technical person, it can be very difficult to determine whether a developer has the specific skills your company needs. Even if you succeed in hiring someone, there’s no guarantee that person will stay long enough to complete your app.
But if you partner with the right agency, you are pretty much guaranteed to come out the other side with a workable, functioning app that you can take to market.
You’ll have a product that’s functional and engaging to end users.
You’ll have a product that will look good and that you can demo to investors.

When the time is right, you’ll have an experienced agency that can help you smoothly transition your code base to your newly-hired engineering team.

When Is the Right Time to Build an In-House Team?

Being seed-funded is a great achievement. It means that the company you are building seems promising to people outside of your team.
With seed funding, you have the capital you need to take your company to the next level, transform your prototype into a real application and start growing. But it is absolutely the wrong time to hire an in-house developer.

So when is the right time?
We believe it’s when you raise your Series A. With Series A funding, you’ll be able to offer competitive salaries, great health benefits, free food, and many other perks to help you attract great developers.
But until you reach that milestone, remember that seed funding is the starting point of (almost) all great tech companies — maximize your chances of success by working with a reliable and established team to build your application.
And when the time comes to build out your team, you’ll have a solid code base that your future engineers will be able to build upon, maintain and scale instead of scrap.

“Design for developers” cheat sheet to make your next project look awesome

App & Flow — Fri, 29 Nov 2019 16:47:13 +0000

While it is always better to hire a professional UI/UX designer for your product, sometimes we do not want to spend too much money before validating our idea or concept (especially when it is a side project!)

However, it is still important that the product looks nice and clean 😎!
We made a short cheat sheet for developers out there that could benefit from learning a little more about design. Hopefully it will be helpful to some of you.

Keep up the hard work!

Yes, you should start your React Native project with Expo

App & Flow — Fri, 29 Nov 2019 16:44:10 +0000

This seems to be one of the most frequent questions on Reddit and on other developer communities: “Should I start my project with Expo?”. Some say yes, some say no. At App & Flow, every single React Native project is started with Expo, no questions asked. Because frankly, there is very little reason not to. What are the reasons? You can read them on Expo’s own website here. They are:

Your app needs background code execution
You need a native module that is not yet available in Expo (ie: Bluetooth)
App size is critical (needs to minimize the bundle size as much as possible)
You want to use a particular Push Notification service, other than what Expo offers

Other than that, why wouldn’t you use Expo?

Common misconceptions around Expo

Expo is good for prototyping, not for production
WRONG. I read this a lot on /r/reactnative, and I never understand why. We’ve built quite a few applications that are in production using Expo, some bigger than others, and it makes it so much easier. Updating to the latest React Native version? Handled by Expo. Over the air updates? Oh I’ll need to install Codepush. Nope! Handled by Expo. Want to share your progress with your team or your client? You can setup Testflight and go that way if you have enough time to spend waiting for the build to process every time you upload one, or you can share it instantly via an Experience in the Expo Client application. The idea that Expo cannot be used for production is, in our opinion, not founded on any good reasons other than the ones listed on Expo’s website. Not only will it make your life easier, but if you do client work they will also appreciate the fact that you are doing what you can to speed up the process.

If our needs change in the future, we will have to start over
Again, this is wrong. We’ve been in this situation multiple times and the solution is very straight forward. Both situations were because we needed Bluetooth connectivity along the way, which is not yet supported by Expo. All you need to do is eject your project from the Expo Client. Your project will still work the exact same way it used to, but it will now be depending on ExpoKit, which is a Java/Obj-C library that exposes every module from Expo’s API. From now on, your project will be like if you started it with vanilla React Native, allowing you to react-native link your heart out.

I have no other options but to link
So you and your team have been working on a project for a little while, in Expo, everything is going well, but now you want to have a nice, native looking picker for your users to use. You start to look around and you find the perfect library. It looks native because it is native, it handles both Android and iOS, this will definitely make our life easier. You npm install, and then you see step 2: the dreaded npm link. Now you have a choice to make: do you eject for a picker library, do you use another input type or do you create your own implementation in JS and make it open source for the Expo developer community? The last option of course! Sure it will a bit more time than ejecting, but not only will Expo save you time in the long run, you will also be helping a whole community by making your work open source. The next person looking for a picker for his or her Expo project will have one to use, all because of you! (Shout out to Vince for his JS implementation of the Picker)

TLDR: Expo offers you, out of the box

Over the air updates
An easy and more reliable way of upgrading React Native versions
Android Studio/XCode configurations
Certificates management with Apple or Keystores management with Google
Push Notifications
Additional, easy to use modules such as AuthSession or BlurView

Expo offers a great developer experience, and it is very valuable for any mobile startup since moving quickly is key. It is our opinion that starting a project without Expo is complicating things for no benefits at all. If you’ve ever dealt with Android Studio or XCode, you know for a fact that you can reasonably waste a day or two messing around with the IDE’s for trivial stuff that does not count as progress.
The team at Expo is incredibly active and responsive, you can easily reach out to them via their forums or Slack channel, and they also have a Canny up for feature requested by the community. Unless you have a specific case where Expo should not be used, per their own reasons, do yourself and your clients a favor and start your project with it!