RFP: V2 with Offline Capabilities

[tpreusse]

We'd like to reboot our app effort.

Current pain points

• painful react native and generally native dependency updates
• bugs with synchronising web page url when opening notifications and universal links
  • caused by race conditions between web app and react native runtime
• decreased performance on slow devices compared to web only
  • some decrease is probably inevitable, but seems to large (laggy scroll in app, fast outside on iphone 5)
• unclear offline plan

Constrains

• needs to automatically update to the latest next.js frontend
  • the deploy process could be amended
• compatible with our GraphQL data stack – we don't want to introduce a new data stack
• clear path for offline, including caching images and full articles on device
  • we have over 3408 published documents already, ~60mb data without images, many GB of high res images, probably will need active cache management

Approaches we've thought about but not fully explored

• service workers via next-offline
  • keep react native wrapper for notifications and native audio player?
  • downside
    • requires iOS 11.3
    • can and will be purged when unused on iOS, «If your PWA or any website for that matter, goes unused for a few days (we think it is roughly 14 days, it is not documented) the device will remove all cached assets associated with the origin. This includes IndexedDB, service worker cache, localStorage, etc.»
    • 50MB cache limit on iOS – workaround via indexed db
    • cannot use cdn on separate host, probably can be worked around with prefixes
    • iOS does not allow it in WKWebView
• stick with react native
  • build our own file api via postMessage / injectJavascript
    • apollo gql file cache, advanced image loading approach with file first check
    • update / cache next.js assets via file api too?
• switching to Cordova
  • build offline on top of file plugin in frontend code base
    • apollo gql file cache, advanced image loading approach with file first check
    • update / cache next.js assets via file api too?
  • upside: Mac/Windows/Electron apps become easy
• just write our own native web view wrappers for iOS and Android?
  • with some web archive tech that fetches new version of the frontend when online?
  • whats the offline plan for content? what about active cache management?

Budget
Currently CHF 10k-30k feels right. The more solid the solution is the more we're willing to pay. Ideally it would become a well documented open source approach to wrap Next.js frontends in apps.

Research Notes

• Offix could enable offline mutations
• phonegap-plugin-push seems to be the way to go for push & cordova
• «PhoneGap Build is in maintance mode. Adobe is no longer accepting new accounts nor upgrading them.», one should directly use cordova, cordova cli 9.0.0 is one year old but there is active work in cordova cli 10 and other sub packages have more recent releases.

[tpreusse]

A few preliminary conclusions from @patte research:

• service workers are not enabled in web views on iOS—does not work as on offline solution for the app environment
• cordovas official wkwebview plugin has problematic cross origin restrictions, possible workaround offered by oracle/cordova-plugin-wkwebview-file-xhr

In my mind a next-cordova plugin would still be the nicest approach. Features:

• documented OTA setup for the next.js frontend code, maybe via next export that are co-deployed
• a cache API, ideally similar to the capabilities of service workers
  • OTA could also work off this API or not
  • allow to cache arbitrary files including images
    • maybe with a react image component or hook that decides whether to load an image via file or http
    • or a web server proxy with caching as a native cordova plugin?

[tpreusse]

Interesting WKWebView Limitations List from «Breaking changes coming to the iOS WebView in Apache Cordova»:

1. Cookies don't persist. This is a WebKit bug, but someone has created a plugin for a workaround. See CB-12074
2. Can't delete cookies. This is/was a WebKit bug (2015), we need to test for the iOS 11/12. See CB-11297
3. Can't execute JavaScript code in the background. There are several issues related to this. See CB-12815
4. XmlHttpRequests don't work, because of Cross-Origin Resource Sharing issue (CORS). There is a workaround plugin created by Oracle (UPL licensed, which is Apache-2.0 compatible). See CB-10143
5. Migration of localStorage from UIWebView. There is a migration plugin available. See CB-11974
6. iframes will not be supported any longer (they are now CORS restricted in WKWebView), and may be partially or completely broken. This may lead to incompatibilities with the same code in other Cordova platforms.
7. Known issues with WKWebView on iOS pre-11 which will be deprecated and dropped in a future Cordova release

Regarding cookies: most likely we've already sufficiently worked around those issue with additional cookie forwarding and reloads during sign in in the web frontend. As we're already using WKWebView in React Native. But we do also have this custom fix on our native web view wrapper code but as far as I remember it is no longer strictly necessary.

[tpreusse]

There is a Cordova plugin to support SW with UIWebView. But does not work with WKWebView.

Apparently SW do not work on Android with Cordova because Cordova Apps aren't served over https.

But also some good news: Cordova iOS 6.0.0 Released!
This seems to solved all the CORS issues. But also requires iOS 11.