[Meta] Support for mobile

I was encouraged by @thedavidprice to move the support for mobile forward so I’m fleshing out an implementation plan in this issue.

1. Init

We need to extend the initialization workflow to create the mobile side. I suggest building an opt-in feature. I’m not entirely familiar with the implementation of that workflow but I guess we can extend it with some argument or prompts during the process. The command would create a mobile directory with the standard structure of a React Native application. The mobile side would be part of the Yarn workspace defined at the root, like it’s done for the web and api sides:

mobile/
  package.json
  index.js
  App.js
  src/
  ios/
   Podfile/
    ...
  android/
    ...

Open questions

• Do we hide the configuration files (Metro, Jest)?
  • I’d to hide them originally and expose APIs as needed. Metro is like Webpack, if you expose the entire API to developers there’s an increased likelihood of developers introducing complexity and potentially conflicting with the framework.
• Do we want to provide default packages?
  • I’d include React Nativation
• If we include React Nativgation, should we wrap it inside @redwoodjs/mobile?
  • I think so, it’s the same as RedwoodJS providing the routing for web. If we decide the implementation, we can optimize it and improve the developer experience easily.
• Do we provide a GraphQL client?
  • Yes! I’d add Apollo. The question here is again the same. Should we wrap it inside @redwoodjs/mobile? Or even further, should we aim for reusing the client for web?
• Do we install CocoaPods if it’s not installed?
  • Until we can remove the friction introduced by CocoaPods, the initialization of the mobile side will require having CocoaPods installed, and running the pod install command. The question is how should the creation flow handle the scenario where CocoaPods is not installed? Should we install it ourselves? Should we fail the initialization and let the user know that they need CocoaPods?

2. Build

Since there’s a new side, we need to extend the build command to build the mobile side too. I think the interface could be something along the lines of:

rw build mobile # builds ios and android native, and js
rw build mobile ios # builds only iOS native (Compilation with Xcode)
rw build mobile android # builds only Android native (Compilation with Gradle)
rw build mobile js # builds only JS (transpilation with MetroJS)

3. Test

Similarly, we’d need to extend the test command to account for mobile:

rw test mobile # tests ios and android native, and js
rw test mobile ios # tests only iOS native (using Xcode)
rw test mobile android # tests only android native (using Gradle)
rw test mobile js # tests only JS (using MetroJS)

4. Dev

Then we should extend the rw dev command to be able to run the mobile and the api side. It’s important that we own the initialization of the network stack in the app to make sure it points to the right URL. When the app is run locally, the network client needs to point to the locally-running instance of the api side.

yarn dev mobile

Future areas of work

• Remove CocoaPods: We can either contribute to the official CLI or execute the idea proposed on that issue on the RedwoodJS side. That’ll remove a lot of indirection from having to have a Ruby and CocoaPods environment, and therefore improve the developer experience.
• Deployment: Unlike a web or an API side, for which we have services like Netlify that builds and deploys them, in the case of mobile developers have traditionally resorted to client-side automation through programmable-DSLs like Fastlane. I think redwood could provide at least a command for archiving the app for release, and then letting a server-side service or CI pipeline to sign and upload it to the right channel (e.g. App Store / Google Play)

Tasks

• Vendor template into the create-redwood-app package https://github.com/redwoodjs/redwood/pull/1637
• Write up a tutorial for building a mobile side
• Extend init to include the mobile side
• Extend build to account for the mobile side.
• Extend test to account for the mobile side.
• Add setup task to add the mobile side to an existing project.

[orta]

This conversation lives in https://community.redwoodjs.com/t/redwoodjs-and-react-native/3339 ATM

[pepicrft]

I would love to chat to you about “sides” and how I envisioned hooking in the rw dev/ rw build/ rw test commands into the project. I think that would form a good foundation for integration of the mobile side, as well as any other sides in the future.

I like the idea of modeling the sides, especially considering that your plan is to add support for mode sides to the project.

Init

I’ll then add an argument to opt into generating the mobile side. I also added a task at the top to add a setup task. I think this will be useful for the projects that are already using Redwood and might want to add the mobile side.

Hiding configurations

I’ll start by hiding them and expose them as needed. I’ve seen those files becoming a huge source of complexity so I’d prefer Redwood to own and optimize them.

Default packages

How about working backward via a kind of mental Tutorial Driven development — when we create a Tutorial for people to learn the Mobile Side of Redwood, what will they need to go from zero to having a working, running, local app? Hopefully, this helps guide toward decisions about what to include or not.

Good idea. I’ll focus on creating that tutorial first and that’ll give me ideas about what makes sense to include as default. I noticed RedwoodJS doesn’t have a lot of strong opinions, but just a few that I believe are necessary. I think the same applies to mobile. There are certain libraries for which it makes sense for RedwoodJS to be opinionated.

@redwoodjs/mobile

I like this idea. I think after designing the tutorial that @thedavidprice suggested, I’ll have a better idea of what are the most suitable defaults for Redwood.

@redwoodjs/data

Like this idea! I think GraphQL client is a good example of a piece that can be reused across sides. The question that I have though is whether the caching components are reusable. In the case of React Native they might depend on some native implementation for IO.

Pod install

Sure! I think when running the side we can detect whether it requires the installation of pods and we could then run it for them.