TL;DR: Smartphones are a very hard no; I do not believe they are suitable for content authoring at the level Grafida targets. Android tablets are a hard no for me; too few of them could run the software, while requiring me to develop an entirely separate application – I cannot afford it, plain and simple. iPadOS is a maybe, mostly because I want to find out if it's even possible.
I did a feasibility study on running Grafida on iOS / iPadOS and Android.
It is not possible to do that with the PHP / Boson architecture, for multiple reasons.
First and foremost, Boson does not run on mobile OS. Porting that is non-trivial. We'd have to start with cross-compiling PHP which has a lot of caveats for the very same extensions we'd actually need. Beyond that, we'd need to re-implement everything Boson provides, including the file picker.
The second major problem is the licensing of the Joomla Framework dependencies. They are GPL-v2-or-later which doesn't work on the Apple App Store. We'd have to replace them with MIT-licensed code. Doable, but creates a lot of instability in the meantime.
The UI and UX of Grafida is designed for a desktop application consumed on an at least 13" 10:9 landscape display. This does not translate well to 11" or 8" tablet form factors, let alone portrait mode or mobile phones. It would need a complete UI re-implementation and a lot of UX re-thinking.
The only viable way to do that is a re-implementation of the entire application as a native mobile application.
There's a dearth of cross-compatible frameworks which can work on both iOS/iPadOS and Android. This made me think about this problem on two axes.
Does it make sense to run on a smartphone? No. You are limited by the available screen real estate even on large phablets and foldable phones. These are the kind of devices you're more likely to create a quick skeleton or record a few disjointed ideas for further processing. You can already do that in Markdown editors and import the Markdown to Grafida. This makes smartphones an unappealing target for this kind of software.
Does it make sense to support Android? Even though the volume of units shipped for Android tablets is nominally higher than iPads of any kind, the vast majority of Android tablets are cheap, underpowered devices used mostly for education or content consumption. The kind of tablet powerful enough to run Grafida – or even Joomla's article editor web interface – is the top 2% of that market. I know, I have an OnePlus Pad 3 myself; excellent device, but it's a veritable unicorn in a planet full of cheap Chinese sub-180 Euro "tablets" with laughably outdated Android versions. Targeting this kind of device is a fool's errand without some serious financial backing – of which I have none.
Is it even possible, even if I really wanted to? The answer, again, is a big fat nope. There's Kotlin and Flutter. Kotlin would require developing a common backend and two separate frontend / UI applications, one per mobile OS. Flutter looks great... except putting an HTML editor in a WebView – our use case – has been chronically broken especially in the context we need it: using hardware keyboards eats most of the keypresses, and hardware arrow keys don't work.
Between these three concerns the idea of a cross-platform mobile Grafida is dead and buried.
That said, I do have a demented idea. I could certainly try getting an iPad-only version written in Swift.
The challenge here is that I only know very basic Swift. I would be leaning heavily on AI-assisted code generation with limited oversight. I do not know if any of my experience is transferrable, but I am curious to find out. For this reason, I can promise neither a timeframe nor even feasibility – but I will certainly give it a go.
As to why not use NativePHP: it's not single-source between desktop and mobile anyway. It only abstracts the mobile interface behind React-like syntax in Blade templates. It would still be a reimplementation, and it would depend on a third party project with murky licensing: the PHP binary for iOS/iPadOS/Android is ostensibly MIT-licensed, but there's no source code available I could find. It also locks me into Laravel which is fine, but not my cup of tea. If I am going to use something that's not my cup of tea I might just as well use Swift and try to learn yet another programming language instead of yet another PHP framework.
Finally, the most important part: a mobile Grafida application would not have feature-parity with the desktop application. It's not a port, it's a reimplementation. Trying to go for feature-parity is the road to madness. The mobile application has different goals altogether. It's more about content authoring on-the-go, with flakey Internet, on a cramped display. It will assume you're using a hardware keyboard; software keyboard will be possible, but it won't be as usable or look as nice. Writing content on the go is a different use case to using your laptop or desktop.
TL;DR: Smartphones are a very hard no; I do not believe they are suitable for content authoring at the level Grafida targets. Android tablets are a hard no for me; too few of them could run the software, while requiring me to develop an entirely separate application – I cannot afford it, plain and simple. iPadOS is a maybe, mostly because I want to find out if it's even possible.
I did a feasibility study on running Grafida on iOS / iPadOS and Android.
It is not possible to do that with the PHP / Boson architecture, for multiple reasons.
First and foremost, Boson does not run on mobile OS. Porting that is non-trivial. We'd have to start with cross-compiling PHP which has a lot of caveats for the very same extensions we'd actually need. Beyond that, we'd need to re-implement everything Boson provides, including the file picker.
The second major problem is the licensing of the Joomla Framework dependencies. They are GPL-v2-or-later which doesn't work on the Apple App Store. We'd have to replace them with MIT-licensed code. Doable, but creates a lot of instability in the meantime.
The UI and UX of Grafida is designed for a desktop application consumed on an at least 13" 10:9 landscape display. This does not translate well to 11" or 8" tablet form factors, let alone portrait mode or mobile phones. It would need a complete UI re-implementation and a lot of UX re-thinking.
The only viable way to do that is a re-implementation of the entire application as a native mobile application.
There's a dearth of cross-compatible frameworks which can work on both iOS/iPadOS and Android. This made me think about this problem on two axes.
Does it make sense to run on a smartphone? No. You are limited by the available screen real estate even on large phablets and foldable phones. These are the kind of devices you're more likely to create a quick skeleton or record a few disjointed ideas for further processing. You can already do that in Markdown editors and import the Markdown to Grafida. This makes smartphones an unappealing target for this kind of software.
Does it make sense to support Android? Even though the volume of units shipped for Android tablets is nominally higher than iPads of any kind, the vast majority of Android tablets are cheap, underpowered devices used mostly for education or content consumption. The kind of tablet powerful enough to run Grafida – or even Joomla's article editor web interface – is the top 2% of that market. I know, I have an OnePlus Pad 3 myself; excellent device, but it's a veritable unicorn in a planet full of cheap Chinese sub-180 Euro "tablets" with laughably outdated Android versions. Targeting this kind of device is a fool's errand without some serious financial backing – of which I have none.
Is it even possible, even if I really wanted to? The answer, again, is a big fat nope. There's Kotlin and Flutter. Kotlin would require developing a common backend and two separate frontend / UI applications, one per mobile OS. Flutter looks great... except putting an HTML editor in a WebView – our use case – has been chronically broken especially in the context we need it: using hardware keyboards eats most of the keypresses, and hardware arrow keys don't work.
Between these three concerns the idea of a cross-platform mobile Grafida is dead and buried.
That said, I do have a demented idea. I could certainly try getting an iPad-only version written in Swift.
The challenge here is that I only know very basic Swift. I would be leaning heavily on AI-assisted code generation with limited oversight. I do not know if any of my experience is transferrable, but I am curious to find out. For this reason, I can promise neither a timeframe nor even feasibility – but I will certainly give it a go.
As to why not use NativePHP: it's not single-source between desktop and mobile anyway. It only abstracts the mobile interface behind React-like syntax in Blade templates. It would still be a reimplementation, and it would depend on a third party project with murky licensing: the PHP binary for iOS/iPadOS/Android is ostensibly MIT-licensed, but there's no source code available I could find. It also locks me into Laravel which is fine, but not my cup of tea. If I am going to use something that's not my cup of tea I might just as well use Swift and try to learn yet another programming language instead of yet another PHP framework.
Finally, the most important part: a mobile Grafida application would not have feature-parity with the desktop application. It's not a port, it's a reimplementation. Trying to go for feature-parity is the road to madness. The mobile application has different goals altogether. It's more about content authoring on-the-go, with flakey Internet, on a cramped display. It will assume you're using a hardware keyboard; software keyboard will be possible, but it won't be as usable or look as nice. Writing content on the go is a different use case to using your laptop or desktop.