Page MenuHomePhabricator

Native Applications
Open, LowPublic

Description

Today, Phabricator works reasonably well on phones by using responsive design. It's not perfect, but: it's generally pretty usable; the development and maintenance costs are very low; you can do essentially everything; and mobile support always ships at the same time as browser support.

There are some things we can not do with responsive design. Desire for these capabilities may eventually motivate the development of native applications.

I am generally not excited about developing native applications which duplicate all of the browser application features, but developing "utility" applications which give Phabricator access to system capabilities feels like it may be a more promising way to iterate here. A minimal desktop/mobile application which supported login and push notifications would be materially useful without stumbling into the next of vipers that supporting all Phabricator applications natively represents.

Because the most interesting capabilities are generally low-level (screenshots, NFC, NFS), these applications probably need to be built in raw native code. If we use a framework like React Native or Electron I'd guess we'll run into a wall sooner or later, although if you can drop through the porcelain reasonably easily maybe something like Electron would be fine for the core and we can do the NFC reader module in Cocoa/C/Java depending on the platform. I haven't touched desktop applications in about a decade so I have no clue what the state of the world is.


Push Notifications: We generally can't do offline/push notifications without native applications. We can get some of the way with SMS (T920) but this is very limited compared to native push notifications. See also T8924.

Screenshots: See PHI1001. We can't do things like "pick screenshots from a gallery of thumbnails" or "screenshot and upload directly to Phabricator" without native applications.

NFS: See T11367. We can't mount Files as a local folder without a native application.

MFA: See T8787. We can not do push MFA or read NFC hardware keys without a native application.

Persistent Chat: It's hard for Conpherence to stack up against other chat applications without native application persistence. Push notifications would help slightly, but the best ease-of-use we can get out of a browser-only chat application has a lot of rough edges.

Local Encryption: See T4721. It's hard to convincingly do local key management in a user-friendly way without a native application.

Offline Mode: I very much doubt we'll ever build this, but if we did, I think it's not practical to pursue without a native application.

Reliable "Currently Online": We can fake this to some degree with browser activity signals, but if we're making behavioral decisions based on online status (see T7004) we probably need the reliability of a native application.

Install/Update arc: You double-click Arcanist.exe/Arcanist.app and it installs arc for you. You never realize arc is written in PHP.

URL Handlers / System Services: Can we add "Open in Phabricator" to this context menu?

Could phabricator:// do anything useful? (No?)

Event Timeline

epriestley triaged this task as Low priority.
avivey renamed this task from Native Applications to Native Mobile Applications.Dec 31 2018, 6:07 AM
avivey renamed this task from Native Mobile Applications to Native Applications.Dec 31 2018, 6:10 AM
avivey added a subscriber: avivey.Dec 31 2018, 6:24 AM

Some of these things are supposed to be implemented in a reasonable way via browsers "eventually" (offline push notifications have a bunch of attempts, Screenshots use case has some solutions that sometimes work, and there's rumor about MFA and NFC floating around.)

For offline chat, IIRC Slack are just using Electron on desktop, so the market is probably ok with paying a gig of RAM for chat.

epriestley updated the task description. (Show Details)Jan 2 2019, 5:42 PM

Does anyone have experience with an existing Push Notifications As A Service provider? I would naively suggest AWS SNS, because we already depend on other AWS services and it's free for the first 1m pushes, and then $0.50/1m pushes after that. It also wouldn't raise any new data privacy issues for Phacility customers since we wouldn't have to deliver pushes outside of our existing VPC infrastructure. List of supported push targets:

  • Amazon Device Messaging (ADM)
  • Apple Push Notification Service (APNS) for both iOS and Mac OS X
  • Baidu Cloud Push (Baidu)
  • Google Cloud Messaging for Android (GCM)
  • Microsoft Push Notification Service for Windows Phone (MPNS)
  • Windows Push Notification Services (WNS)
  • SMS

I think OneSignal is what all the cool kids are supposed to be using though.

We could also start from bare metal and talk directly to Apple/Google via APNS and GCM, respectively, but in a previous lifetime I've been impressed with AWS SNS's durability and behavior under failures.

epriestley updated the task description. (Show Details)Feb 25 2019, 8:03 PM
epriestley updated the task description. (Show Details)Apr 11 2019, 4:29 PM