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?

Screen Shot 2019-04-11 at 9.29.12 AM.png (338×381 px, 131 KB)

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

Event Timeline

epriestley created this task.
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

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.

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.

As of macOS X 11 (Big Sur), php on the CLI emits:

$ php -v
WARNING: PHP is not recommended
PHP is included in macOS for compatibility with legacy software.
Future versions of macOS will not include PHP.
...

This seems to be communicated more broadly here:

SCRIPTING LANGUAGE RUNTIMES - DEPRECATIONS

Scripting language runtimes such as Python, Ruby, and Perl are included in macOS for compatibility with legacy software. Future versions of macOS won’t include scripting language runtimes by default, and might require you to install additional packages. If your software depends on scripting languages, it’s recommended that you bundle the runtime within the app. (49764202)

https://developer.apple.com/documentation/macos-release-notes/macos-catalina-10_15-release-notes


One possible approach here (short of, e.g., rewriting in Go) is to compile arc into an embedded PHP binary. This would retain compatibility with PHP extensions, and could likely bridge into native code through C later. This would leave "Phabricator.app" running a PHP interpreter internally, which is quite something, but I think this isn't really a greater sin than anything Electron does.