Maybe Fyne should drop mobile support and focus on desktops

[Gys]

Some personal thoughts while I am investigating compiling Fyne cross platform for a commercial application (incl mobile) that I have in mind.

I came to realize the mobile versions do not support any mobile specific features at all? So the only reason to choose Fyne for mobile is re-use of code. While at the same time blocking off (easy) access to any mobile features, like camera, photos, notifications, geo location, BT, NFC, payments, contacts, etc, etc. Actually, I think that access is the main reason why a developer would make the choice to build a native app? A 'boxed in' mobile app is even worse than having a website, because a web browser does give access to many mobile features and offers the option of making a Progressive Web App.

It is unfortunate the 'app showcase page' by design does not show any commercial applications. Cross platform or not. It makes me think Fyne is in a commercially way mainly used for in-house applications? You should show how developers can make money by showing how others are now making money. Developers making money will support you.

Supporting the desktop versions seems already demanding and the mobile world is moving faster than Fyne. Strategic thinking is the ability to focus and say 'no' to most ideas.

[andydotxyz]

While at the same time blocking off (easy) access to any mobile features, like camera, photos, notifications, geo location, BT, NFC, payments, contacts, etc, etc.

We have support for notifications, there is a proof of concept for camera support, BT has an open PR being developed, and location is likely next. Any features we add will work across all platforms which is indeed extra work but we are solving those problems to save pain for app developers.

A 'boxed in' mobile app is even worse than having a website

Any other features can be added with device specific code if developers want - these apps are not "boxed in".

It is unfortunate the 'app showcase page' by design does not show any commercial applications

That is correct - it promotes open source apps to advance people's learning. Closed source apps are out there as well - though we don't have permission to promote them all. You could see the mobile app for shells.com or the app builder being created at https://fynelabs.com/creating-an-app-builder/. There are many commercial apps and some of the US Fortune 500 companies are using Fyne.

Supporting the desktop versions seems already demanding and the mobile world is moving faster than Fyne. Strategic thinking is the ability to focus and say 'no' to most ideas.

The core aim of Fyne is to be an easy to use toolkit for platform-agnostic apps. Working everywhere is the most important concept, adding platform features comes second to that. As I said above you can access all native APIs as well as the Fyne APIs if you desire so nothing is impossible.

[Gys]

We have support for notifications

Only local notifications I understand from the docs? This is the app itself sending a message to the user. Only possible if already running in the foreground I think (at least on iOS).

I did not see any options to register a phone with a service for sending remote notifications: a message send by a back end to a specific phone. That what normally is meant by notifications. But maybe I missed something?

proof of concept for camera support

That is interesting because this is my most important needed mobile feature. I tried searching but could not find this. Do you have a link?

[andydotxyz]

We have support for notifications

Only local notifications I understand from the docs? This is the app itself sending a message to the user. Only possible if already running in the foreground I think (at least on iOS).

It doesn't have to be foreground, but it does have to be running. Would scheduling notifications be helpful too?

I did not see any options to register a phone with a service for sending remote notifications: a message send by a back end to a specific phone. That what normally is meant by notifications. But maybe I missed something?

I think you mean "push notifications" then? I don't think it's reasonable to assert that this is the only type of notification, but I understand that is what you meant.

I might be missing the point - but isn't it the job of the server / push notification provider to register with the device rather than your GUI toolkit?

proof of concept for camera support

That is interesting because this is my most important needed mobile feature. I tried searching but could not find this. Do you have a link?

Unfortunately not - ironically considering one of your other messages, but the company behind it has not published the code yet. I think they had Android completed but not iOS. If you search our chat archives then you may be able to find the person who was discussing the work.

P.S. accessing a camera is not mobile specific (think webcam etc, standard on laptops as well).

[Gys]

I might be missing the point - but isn't it the job of the server / push notification provider to register with the device rather than your GUI toolkit?

I do not know the details, but in a nutshell: The app uses the local OS services to register with the remote service. The registration results in a unique id. The back end needs to know that id and uses the id to send messages to the remote service which passes them to the device. The local OS receives notifications and informs the app.

In most cases, like React Native, there are libraries available for registering with a remote service. See for example: https://www.npmjs.com/package/react-native-push-notification or a for more general cross platform, cross channel solution: https://documentation.onesignal.com/. Onesignal had a Golang SDK for the back end (server) but not for the client. It is probably relatively easier to write only one Golang Mobile Client SDK against their internal SDK. Or maybe just ask them to add one ;)

The app first needs explicit permission from Apple (nowadays Google/Android as well I think) and from the user (an OS popup) before notifications can be received.

[andydotxyz]

In most cases, like React Native, there are libraries available for registering with a remote service.

Agreed. So would it not be the job of a library when using Fyne as well? We should not increase the scope of our toolkit too far but can support external / add-on libraries to do what is necessary.

[Gys]

Hoping someone (or company) starts supporting any of the platform specific features is indeed one way of looking at it. Focusing on desktops is another one ;)

Earlier you wrote:

P.S. accessing a camera is not mobile specific (think webcam etc, standard on laptops as well).

Turns out that is already very platform specific. I am looking into a proof of concept to access the iOS camera. Also needs actual hardware to test because the simulator does not support it.

[Gys]

Btw, regarding third party libraries I want to repeat my earlier comment: why not talk to OneSignal and ask them to add a Golang client SDK for Golang / Fyne.

[andydotxyz]

Hoping someone (or company) starts supporting any of the platform specific features is indeed one way of looking at it.

This is not about platform specifics, you wanted push notification support and explained it is usually added in external libraries. Why is it not reasonable that we propose a similar model here?

Turns out that is already very platform specific. I am looking into a proof of concept to access the iOS camera. Also needs actual hardware to test because the simulator does not support it.

You misunderstand me. Yes of course adding camera access is platform-specific code - but the concept of a camera is not limited to the mobile platform. We don't have access to desktop webcams as much as we don't have support for smartphone cameras. Removing mobile does not somehow solve this.

[Jacalz]

Removing support for something just because it is missing functionality seems very counter intuitive and won't get us anywhere. More help to improve the mobile support and implement missing functionality is a lot more helpful.