mWeb (iOS 12) - 1.0.2-54 - Chat - Blank screen is displayed after login [Pay on Friday 14th May]

[bfitzexpensify]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Expected Result:

User is taken to chat screen after logging in.

Actual Result:

Blank screen is displayed

Action Performed:

1. Open Expensify Cash on iOS 12.
2. Log in
3. Observe result

Workaround:

User is unable to use the app.

Platform:

iOS 12

Version Number: 1.0.2-54
Logs:
Device logs
Notes/Photos/Videos: Video

Expensify/Expensify Issue URL: https://github.com/Expensify/Expensify/issues/157735

View all open jobs on Upwork

[MelvinBot]

Triggered auto assignment to @Julesssss (Exported), see https://stackoverflow.com/c/expensify/questions/7972 for more details.

[Julesssss]

Unable to reproduce this. My test device gets stuck at the Splash screen, which sounds similar to the reported error, but as it's running iOS 13 I'm not convinced.

Asking for someone else with iOS 12 to verify.

[Julesssss]

@Beamanator confirmed the issue on an iOS 12 emulator 🙇‍♂️

[kidroca]

Hi, I've traced this to react-native-web onLayout relies on ResizeObserver or a polyfill

Addressing this need would successfully render the app, past the login screen

Safari 12 for older devices and versions of iOS
There are some devices from Apple which don't support iOS 13 and are thus forced to stick with iOS 12 - this means that the latest version of Safari is in the 12.x stream.
https://www.whatismybrowser.com/guides/the-latest-version/safari

ResizeObserver is only available from iOS Safari 13.7 and up: https://caniuse.com/resizeobserver

Proposal

The warning message is coming from react-native-web they are saying: "Hey we use some feature of JS that won't work on older browsers. We're not interested in supporting legacy code and we won't include polyfills ourselves, but you can still run our code on an older browser if you include the polyfill yourself" (Well... this is my interpretation 😉)

The easiest solution would be to include the polyfill and make it a part of the whole bundle. But in 99% of the cases on modern browsers this polyfill would never be used and will only take space.

Also this would not address other features needing a different polyfill.
For example the Login screen does not need any polyfills to render on iOS 12, but the screen after that requires the ResizeObserver. Perhaps something on the Settings screen would need a polyfilling as well.

Supporting older browsers

The easy way - polyfill.io

It's a service which accepts a request for a set of browser features and returns only the polyfills that are needed by the requesting browser.

Just include the polyfill in the index.html used for web

https://github.com/Expensify/Expensify.cash/blob/d77919924e732033539dc8e620a9fe0824b83773/web/index.html#L15-L18

Like so:

<link rel="stylesheet" type="text/css" href="/css/fonts.css" />
<script src="https://polyfill.io/v3/polyfill.min.js?features=default"></script>

That's it - you are covered

Polyfill.io is made available free of charge.

https://polyfill.io/v3/terms/#polyfillio-are-provided-as-is-and-without-any-sla

Manage needed polyfills using browserslist and babel

Supported list of browsers can be maintained in a separate file or inside package-json
Babel uses core-js and bundles all the necessary polyfills to cover the requirements listed by the browserslist
Babel inserts feature detection code and lazily applies necessary polyfills
Since the polyfills are part of the bundle the bundle size increases

Pro/cons

polyfill.io

• ✔️ easy add and forget.
• ✔️ polyfils are still applied lazily on demand
• ✔️ the app bundle is unchanged
• ⚠️ relying on external service
  • Scripts are cached. even in the rare event that the service is down if the client accessed expensify.cash at least once he'll get a cached copy of the polyfill
  • If the service is ever dropped you can switch to a similar service or the babel solution
• ⚠️ 1 extra request is made when people visit expensify.cash
  • though as explained for consecutive usages it will be almost instant

babel and browserslist

• ⚠️ not very easy to configure
• ⚠️ additional dev dependencies core-js v3 and maybe others
• ⚠️ feature detection code becomes part of the main bundle
• ⚠️ polyfills become part of the main bundle though they wont be used at all on modern browsers (99% of the time)
  • they can be configured as a separate bundle and injected on demand but this requires extra configuration. Judging by the fact that bundle splitting isn't yet configured for expensify.cash polyfills will probably be directly included in the bundle.
• ✔️ you are in full control of what polyfills are included

Alternative

• Drop support for mWeb on iOS 12.
  • all devices since iPhone 6s (including) can update to the current version of iOS
• There are other polyfilling methods like feature detection (in our code) and then fetching polyfills from a CDN - this is less complicated than babel, and keeps the polyfills out of the bundle as well. I guess if you want to discuss polyfill alternatives you'll ask.

[kidroca]

You can quickly verify the issue is fixed by the polyfill by checking out or making the changes here: kidroca@22b6be6

• you'll need npm install to add the polyfill
• this is just code to prove the concept

[Julesssss]

Thanks for the detailed write-up @kidroca!

The Polyfil solution seems reasonable, but we first need to work out if we wish to continue providing support for iOS 12. You mention dropping mWeb support from iOS 12, but wouldn't we need to drop iOS 12 support entirely?

[kidroca]

You're already not supporting mWeb on iOS 12, sinceExpensify.cash has no code for compatibility on older browsers.
My suggestion regarding dropping support was to make this official by including it in the project description and perhaps in a public page like "about" that would list minimum supported devices/browsers/OSes
Some apps would run a small check during init to detect if your are using an unsupported browser and render something like "Sorry our page does not work in your browser, please use ..." and a nice error image

You don't need to drop native support if the app works and can be installed on iOS 12, but it's up to You

• If latest react-native version is working OK on iOS 12 you don't need to
• Even if you drop native support for iOS 12 at some point - if you have a polyfill the webpage (mWeb) would still work on iOS 12.

My opinion is that as long as the OS/Safari receives security updates it should be supported.

[kidroca]

There are a lot of polyfill strategies and mixes, I've just listed some of the most easier and popular solutions.

I can see how you would probably move away from polyfill.io due to the lack of service level agreement. We can discuss some other options if you're interested in polyfilling to support older browsers