I suspect the nature of your question threw them for loop. You might as well of asked if Window 10 is compatible with their networks, the answer would be the same.

Network compatibility is about hardware compatibility. You need to ask something like: "is a Google Nexus 5 compatible"? But of course ask about whatever phone you plan to use.

As mentioned not all features may be supported by UT, but that is a different issue.

Or you could switch to dev channel and try it out. Frankly the dev channel seems more reliable as far as my usage has shown.

You can always switch back to stable should something be problematic.

The zoom behaviour of Morph is currently being improved. I'm not sure what changes are in stable, but webapps in dev channel certainly have access to zoom settings by the user.

There is no option to set it in the command line for webapps, but I recall seeing the suggestion out there. Maybe in time.

edit
for command line options that are available see:
https://docs.ubports.com/en/latest/appdev/webapp/guide.html#command-line-arguments

I think the reasons laid out by Marius are the very reasons UT is going to succeeded alongside the PinePhone.

People might start trying a linux on phone in many forms available thinking that is what they want, but when that disapoints there will be UT ready to offer them the experience they really want.

I think with open hardware access, UT will flourish.

Do we know the current camera does not support raw? Or is it that no one has implement such?

Happens on my OPO regularily.

Must be a bug in the code that saves draft text.

@makeixo I'm curious what gestures SFOS uses? As I see it there is really only 3 easy gestures per edge: quick flick, and long drag (perpendicular to edge), and sliding along the edge (parallel to edge). Currently only the indicator edge implements a parallel action.

I missed the 'back' button when I moved from Android, but these days I find it awkward when I use an Android device that the back button does inconsistent things... sometimes it move back in an app, sometimes it closes an app, sometimes it switches apps. My point would be that I like how UT has separated the concerns the 'back' button provides. App switching is on an edge, and induvidual apps are left to determine where and what a back functionality does (many don't even need it).

A global back gesture would have the same problem, what back action should be implemented in a given situation? Is this up to Unity8 or the app in question? If it is on the app, what happens if the app doesn't implement an action?

Thinking further about my example of Morph, the 2 basic gestures on the bottom edge would work, and could be just like the new app drawer coming in the next OTA; a short flick could show the address bar and a long drag could switch to the tab view. And all functionality would be maintaned with an easier to reach 'back' action.

If I was able to (and who knows, I might learn) I would add a parallel action to the right edge, so that sliding a finger up and down the edge would simulate a scroll wheel.

@AppLee I would agree that we don't want to force the UI of apps into any sort of cookie cutter form, but I think leaving one edge for app use and encouraging use of that edge in apps is a good path.

For my examole of Morph, I would love for there to be an app option to move the top bar to the bottom. In Pebusk, I think the design works great. However try out uText and it's swipe from left options menu, and you can see why apps should use the bottom edge (nothing against uText, I love the app).

I think this is mostly a promblem of app design. 60% of my back button usage on an Android device is to switch the previous app, and this is handled fine with a quick flick from the right in UT. The rest is mostly use as a navigation aid, especially navigating backwards in the browser history. I would rather Morph (and other apps) move the navigation bar to the bottom edge, than add complicated gestures to the screen edges.

Really the example of Pebusk is a good one because the simple fact is we have only 4 screen edges

top: indicators
left: app drawer and dock
right: app spread

leaving the bottom edge for apps.

Holding a phone one handed the bottom half is far more accessible to your thumb than the top half, so that's where important contextual actions should live.

If all apps moved the top bar away from the indicators (where there is accidental interference between the two) and simply to the bottom edge, UT would be better off for it.

Sounds like a dead battery to me. Id find a new one on fleabay or the like.