In theory, you should just see the same apps in Discover and in GNOME Software, assuming they both can access/install native Alpine and flathub apps. (And I recall they did at some point in time, but breakage unfortunately happens, and I mostly use the terminal to install and remove things…)

With Ubuntu Touch apps it’s different, the Open Store is its own thing. I want to look into whether adapting this to postmarketOS when I can find the time.

Regarding few apps: Yes, it could be more, yes, there are gaps, but we’re doing somewhat okay: https://linuxphoneapps.org/

Glad that works for you! With my bank (comdirect.de) I can use a mobile website, and if I were to use something AOSP- or Halium-based, I could also use their PhotoTAN app, which, as the name implies, needs a working camera in Waydroid (on my OP6 with pmOS, the cameras work via libcamera, but not in Waydroid), so I have a small gadget for all these TANs.

My main worry with the “let’s just use Play Store/Aurora store and the run that apk”-approach is that it does not really send a visible signal to banks that they need to keep considering customers that don’t use Android proper.

It also always means that the next update (e.g., after some consultancy or some audit happened) may not work any more, meaning, access may be revoked at any time. Complaining to customer service or in Play Store reviews may have an effect, but it will still hurt. I think I would feel a tad safer if a banking app lived on FDroid… but sill.

I hope this gets my point across.

As someone who spent some time on the topic (result), it’s not that every new app is adaptive. Even if someone uses the nice new widgets of libadwaita (or previously libhandy (GTK3)), that app is not necessary running well on mobile if width-reqests demand a higher minimal width or content is just too wide.

The same is true for QtQuick Components or Kirigami, which are the equivalent for adaptive Qt apps.

That said, yes, many new apps developed with these technologies work fine OOTB without the developer even knowing; and if they are too wide or tall, fixing that is usually rather simple and not a full rewrite/redesign.

Not directly, here’s what we have:

https://linuxphoneapps.org/categories/maps-and-navigation/

Of these, at least PureMaps does turn-by-turn - as a no-car-person that last drove in meaningful way when paper maps where a thing, I am the wrong person to ask about car navigation stuff.

Additionally, there’s the OrganicMaps desktop flatpak (not a great experience, only good for seeing where you are) and zooming around. Fortunately, a work on a mobile-friendly Kirigami app for OrganicMaps has been funded by nlnet.

Also, runnning some web Maps in a browser (e.g., via https://linuxphoneapps.org/apps/dev.heppen.webapps/) is always an option (e.g., for browsing Google Maps for an open restaurant nearby).

Just 2ct’s on the banking thing (sorry if it sounds rude, but I just can’t hear it anymore):

Just forget banking apps of you don’t want to stay on iOS or proper Google Android forever and ever and ever, even AOSP-based OSes struggle with that (a lot).

Go to a bank that still has a proper website and allows some kind of hardware device for TAN (and tell them that this is why you are leaving/joining) - we need to show market demand for alternative solutions or else these will disappear completely over time.

We also need to make regulators/politicians understand, that taking part in life must be possible without owning a device blessed by Google or Apple. We really need laws here.

Regarding Android apps: I hope that https://gitlab.com/android_translation_layer/android_translation_layer will make a difference here going forward. A Wine-like approach is just so much less of a resource hog.

Regarding the Camera on the PinePhone Pro: It somewhat works by now, if not on every OS. Be it with libcamera or Megapixels 2, we’re getting there. I suppose it’s just that nobody told the Wiki.

Having had both a Pinebook and a Pinebook Pro and two PinePhones and a PinePhone Pro at some point in time (I co-hosted a PINE64 podcast for a bit), I don’t follow. If your point is that the PinePhone (Pro) have never been a great for everybody, I think the same is true of Pinebooks (Pro), they’re definitely are among the worst laptops I have ever had. Various just as cheap ARM-based Chromebooks (especially the ASUS C101p) I’ve had were/are just so much better.

The PinePhone really helped with development of existing Linux on Mobile projects and caused the creation of some additional ones, as evidenced by the massive number of projects on https://pine64.org/documentation/PinePhone/Software/#software-releases.

The Community Editions helped projects like UBports or postmarketOS financially. Some people even daily drive the device (despite being slow, I’ve found Sxmo and Sailfish OS to be acceptable, with Phosh coming in third).

While I don’t recommend it anymore for anyone who wants to use GTK based stuff on it, I’d view it as a success (I don’t view the Pro as a success though, even though I believe they should have cancelled the A64-based PinePhone, not the Pro - a PP2 was IMHO overdue around 2023/2024). With better Quality Control, better relations between PineStore and the wider Community and a different default OS (putting the heavy Plasma Mobile on it was just nuts, and Manjaro definitely is not my favorite distro, to say the least) for the Beta edition, it could have been an even bigger success.

Yes, it didn’t work for everybody, but as getting to a working laptop is so much easier than getting to a working phone (think of calls: the device has to manage to wake up at any moment (and fast), audio routing must be switched, echoes must be cancelled etc.) with the sky-high user expectations attached to phones (and the shitload of semi-hostile phone carriers across the world), I regard the PinePhone as quite an achievement.

+1 for the Surface Go 2. I use on of these with NixOS GNOME, and it’s lovely. For Pen use I like Rnote. You could also use Plasma Mobile on it. The Go 3 is not really better, so don’t get it unless it is in the same price range, and avoid the 64 GB eMMC model.