Mobile development - Android & iOS

[marcov]

Well then, perhaps you don't see it because you are blind to new approaches

Citing global mobile numbers are not new approaches. We have heard that kind of drivel since 2005-2008. 

Let's discuss how to overcome those obstacles and weight various strategies to solve the problem.

We can discuss forever of course about how something realistic would go. I personally think shared GUI with desktop is a dead horse.  Too complicated, too many things holding you back if you have to anticipate on fast moving mobile platforms.

Keep in focused and as narrow in scope as possible to be able to "quickly'  (as in years rather than decade+) have something, while minimize the effort to keep it working. (all energy put into maintenance can't be used for new features/targets etc)

Let it be just open discussion with new ideas or revised old ideas. Everybody tried to tell to Elon Musk that it is impossible to start a new car company or to start new rocket factory. https://www.youtube.com/watch?v=k9zTr2MAFRg

That's the spirit and good out of the box thinking!  If you are comparable to Elon Musk, the problem is solved!  Just buy Embarcadero,.. At a rumoured mere 60million it is a steal and probably will be cheaper than most of Musk's adventures.

Back to the topic. Mobile platform is used more than desktop now and your numbers may vary but that is the fact https://gs.statcounter.com/platform-market-share/desktop-mobile-tablet Sure it depends if one is interested in mobile "market" or not. As I use my Android device daily, I really want to use my own applications or other open source applications which are available for desktop also on my phone.

But how representative are you for the numbers counted in that stat counter. I'd be surprised if it is 0.1% to be honest.

Sure, we can discuss many years about GUI differences between desktop, mobile and web. Every technology has own specifics and pros and cons. I even want to target Smart TV as a platform.

If it is a fantasising contest, don't forget the smart watches!

With Delphi FMX you can create mobile and desktop app with single code base. There will always be some platform specific things but normally it should be pretty easily possible. Delphi is kind of expensive and doesn't run on Linux so it is not an option for me.

But FMX was designed with that step in mind. I assume the same for Xamarin, which was in my post I talked about platforms that were expanded to mobile when the original target was already established.

And even it that would not be single application for those platforms, still Lazarus as IDE should offer ways to create mobile, desktop, web, console, tv, car, e.g. as separate applications. Just imagine an dialog window called "New project" where you can select needed GUI layout or possibly select generic dynamic layout. This ideal thinking is more like from top to bottom. That is the premise. To have development environment to allow develop an application/service/library/tool for any platform and GUI layout. That is where we can get in some distant future.

Yeah, adding menu options, THAT is the hard part. Seriously, the IDE integration and designer can be done if the proof of concept library is there. You need to start from the ground up. The first step is getting access to the target, but since LAMW does, that is  done.

The next step is not IDE work, but building a cross-mobile library and to further build and ease access to these mobile targets. (as in: conceptually ie. on the commandline). Like making it easier to get the relevant stuff (vendor libraries, like Android SDK) installed, managed multiple targets (fat binaries) etc.

Crosscompiling to iOS is afaik complicated from non Apple systems since Apple doesn't really encourage it.

Back to reality. How can Android application be currently created? By quick check of existing Android related wiki pages https://wiki.freepascal.org/Portal:Android I can say that it is quite a mess. A lot of long and some outdated tutorials with many manual steps and auxiliary GUI tools to do a simple thing. To build GUI application. Can it be as simple as creation of a new project and hitting F9 to run in Android emulator? Or without emulator at least to simply compile and create Android package apk. Also you may need trunk FPC or Lazarus, anything can break and will probably break. Upgrade to newer Lazarus and FPC will probably break everything and one will need to do that again. Does it look like only to me as a big waste of time? Would it be better to start implementing partial Android/mobile support directly into IDE? Perhaps as an experimental feature which can be activated from somewhere. Sure, I can answer this by myself, this would take too much effort and there are no volunteers, so whatever.

There currently is only the LAMW guy and a circle of occasional contributors around him. But yeah, simply starting to investigate and building out that target would be a logical first step. For any of the suggest solutions.

But simply using and documenting the stuff that is there is a first step, to get more intermediate users to access the target. Then maybe some investigation to how a cross-mobile library would look like.

Ok, Lazarus IDE can't support Android directly so what are other options apart from LAMW and other obscure ways described on wiki?

Commandline compiling. I did try once for my i386

Implement Delphi compatible FMX framework for FPC. After all, Delphi needed to solve the same problem. VCL was too Windows oriented and they could either break VCL compatibility to extended it to be usable across new platforms or to create(or buy) completely new more modern GUI framework. For sake of existing customers they decided to go with new framework. So in case of Lazarus and LCL this decision still needs to be done.

There are several problems with that.

• FMX wont be as easy to reverse engineer as the VCL, which was effectively a Winapi wrapper, so MS doumentation and component sources could be used to infer its working. None of those apply to FMX
• Too huge, and probably too costly in maintenance.
• Having two major visual libraries in the IDE. Who will do the desktop parts

That was the point of my last mail. Keep it realistic, both the audience and ambitions. It took decades to duplicate the VCL to a somewhat acceptable level.

Develop desktop app in Lazarus and mobile variant for Android and iOS in Delphi. How to sync GUI between those two environments? That is the tricky part. Perhaps one can create some Lazarus LCL to Delphi FMX converters. Or create LCL backend to target FMX as widgetset.

If you must buy Delphi, why bother with Lazarus at all? Just do the desktop app in Delphi/FMX

• Another way to solve this would be to create some cross-compiler or better say transpiler to convert pascal code into code of other platforms which support Android/iOS. It may be Java, Kotlin, C++ or something else. This may not be just about language but also about GUI frameworks. That would be pretty complex and time consuming task but it is possible.
  

I don't really think language is that much of a problem. The problem is creating a layer over multiple very different systems. (iOS, Android and Desktop and then some various incarnations (TV/tablet/phone).

That said, android can be done natively (ARM or i386 machinecode, perhaps RiscV in time), but also via ppcjvm, and to some lesser degree pas2js.

• Create complete new more modern Object Pascal/Delphi compiler to target multiple platforms. Indeed, not and easy task. But still one of way to achieve that. Over the years there were many Pascal compilers developed and new are still created to some degree. One example would be https://wiki.freepascal.org/Projects_using_Lazarus_-_Developer_utilities#PicPas which supports only limited pascal syntax and no GUI design support, but it is still pascal compiler. The list of other compilers https://pascal.fandom.com/wiki/List_of_compilers_and_interpreters

So now we going from unrealistic to unicorn territory.

• Stop using Pascal and use different better tool to create mobile/desktop application. One interesting open source project is Haxe https://haxe.org/use-cases/ which can also target desktop and mobile platforms. Although still not ideal. There are so many technologies which tries to solve that multi-platform problem. Mobile apps can be developed with C#/.NET, Python, JavaScript and many others. I am not aware of any what would fulfill all my needs. So I am still using Lazarus.

Since you are still here let's assume that that is not an option.

• Use Linux phone instead of Android. Linux phones are still slow, not fully functional, not widely available and they are expensive. But this may change in future. https://www.pine64.org/pinephonepro/

First you cite global sales in the billions, and then you want to use those to justify an extreme niche target that probably will never fully come to fruition  I'm still waiting for Linux on the desktop to dominate. Let's hold off dreaming of it dominating Phone hardware ;-)

I understand that there are many other Lazarus weak areas like to this date not implemented single window docked IDE like Delphi has (AnchorDocking is just a poor guy alternative). Also Gtk3, Gtk4, Qt5 or whatever new toolkit version not fully supported. This is never ending effort to catch up with upcoming technologies and ever changing world. But this topic is about Mobile development and in this regard Lazarus is lacking.

Open door.

But the question what is sane to pursue?  Even if we forget about who will do it, all you name here are pretty far out, and would require complete teams, not one or two interested parttime volunteers.

The only realistic direction  that I see would be to start something to just bridge Android/iOS based on some general FMX principles (without compatibility, too much hassle) or LCL customdrawn. (more headstart, but somewhat outdated). Or fully new with more CSS like approach, like Warfley advocates. (I'm no fan of that, but don't know enough about the praciticalities of such approach)

[/list][/list]

[marcov]

n, if I am already paying 150€/month to use delphi,

(does that figure include the mobile option, or is that extra?)
 

[Warfley]

(does that figure include the mobile option, or is that extra?)

Windows macOS and Mobile. Only Linux requires the bigger package and its around 330€/month.

[marcov]

(does that figure include the mobile option, or is that extra?)

Windows macOS and Mobile. Only Linux requires the bigger package and its around 330€/month.

At work I'm still Windows only on Seattle without subscription, but Embarcadero is constantly threatening to no longer allow more activations, so probably sooner or later I'll have to go on subscription.

[dseligo]

The new version is still in beta and the old version is not a real app. It's a slim interface that connects to your phone. All the messaging functionality is performed by the App on the Phone and the Desktop client has no functionality on it's own. I don't count that as a real desktop version.

Also whatsapp still requires a phone, you can only use the desktop app in addition to an already existing mobile installation.

Well, maybe it's in beta, and it's old version, and it's not a real app, and it's a slim interface, and ... all the rest you've said.
But you also said earlier that WhatsApp is not available on desktop, yet I use it and I found it very useful. And I don't know if it is a real desktop version or not, but it works (and it does that probably for millions of users).

[Warfley]

Well, maybe it's in beta, and it's old version, and it's not a real app, and it's a slim interface, and ... all the rest you've said.
But you also said earlier that WhatsApp is not available on desktop, yet I use it and I found it very useful. And I don't know if it is a real desktop version or not, but it works (and it does that probably for millions of users).

It isn't a desktop version. It's an interface to your smartphone. Sure it is useful, but whatsapp is still running on your phone. If you turn off your phone your desktop app stops working. You aren't using a desktop version of whatsapp, you are using your phone just through a remote control.
It's like saying I have docker on my phone because I can SSH into my server to execute docker container

[Mr.Madguy]

It isn't a desktop version. It's an interface to your smartphone. Sure it is useful, but whatsapp is still running on your phone. If you turn off your phone your desktop app stops working. You aren't using a desktop version of whatsapp, you are using your phone just through a remote control.
It's like saying I have docker on my phone because I can SSH into my server to execute docker container

I'm not 100% sure, as I haven't checked it myself, but according to some recent news WhatsApp should have full desktop version.

[Warfley]

I'm not 100% sure, as I haven't checked it myself, but according to some recent news WhatsApp should have full desktop version.

Yes there is one, but it is still in beta. The desktop client has the capabilities, but you need to opt in to the beta to use it (can be done from the whatsapp app).
But this is still not a standalone app on its own, you still need a phone app to authorize the desktop apps. When you disable your phone app, change your phone or simply just reinstall the app on your phone this will also invalidate all the desktop apps. So the desktop app is always just an addon to the mobile app and not a standalone app that can be used on it's own

[PascalDragon]

Developing for iOS is more involved than Android as not only you need a macOS computer, but also an iOS device (both of which aren't necessarily cheap). For someone like me for example that would be quite an investment (as I use Linux/Windows and Android) thus I prefer to do that investment somewhere else instead.

Understand the situation.  Difficult to develop for hardware that one doesn't possess.  So, are you also saying that yourself or possibly other developers might need macOS and iOS devices provided or donated by the Lazarus community in order to actively support mobile development for iOS?  It appeared that Chronos made an offer (page 2), that maybe should be discussed with him by PM.

Ha! No. I have too many topics on my plate already.

While I agree that Windows will be with us for many years to come, a lot has to do with Microsoft's hold on being used in the business world (thanks to Microsoft Office).  But, let's not forget that Microsoft Office is in the cloud and are apps that can run on Android and iOS.  I do think the percentage of Windows OS dominance on the desktop and/or for general use will dwindle.  When it comes to personal computing, a lot of people are relying on their phone and have become used to Android and iOS apps.

You forget one important market: gaming. High end games are available on either the gaming consoles or for Windows (and sometimes macOS), but not for phones. Take for example the various big MMOs like World of Warcraft or Elder Scrolls Online: they only work on PC and Mac (at least WoW works on Mac, don't know about ESO). That is an area that won't disappear so quickly. Also: app development itself. It requires a desktop system (Windows, Linux, macOS, etc.) and can't be done on Android or iOS (yes, I'm aware that there are some possibilities especially on Android, but that's not the point here; big IDEs like Visual Studio, Delphi, Lazarus, XCode, etc. only exist on desktop).

Ok, Lazarus IDE can't support Android directly so what are other options apart from LAMW and other obscure ways described on wiki?

• Implement Delphi compatible FMX framework for FPC. After all, Delphi needed to solve the same problem. VCL was too Windows oriented and they could either break VCL compatibility to extended it to be usable across new platforms or to create(or buy) completely new more modern GUI framework. For sake of existing customers they decided to go with new framework. So in case of Lazarus and LCL this decision still needs to be done.
• Develop desktop app in Lazarus and mobile variant for Android and iOS in Delphi. How to sync GUI between those two environments? That is the tricky part. Perhaps one can create some Lazarus LCL to Delphi FMX converters. Or create LCL backend to target FMX as widgetset.
• Another way to solve this would be to create some cross-compiler or better say transpiler to convert pascal code into code of other platforms which support Android/iOS. It may be Java, Kotlin, C++ or something else. This may not be just about language but also about GUI frameworks. That would be pretty complex and time consuming task but it is possible.

These are not in the scope of the Lazarus project.

• Create complete new more modern Object Pascal/Delphi compiler to target multiple platforms. Indeed, not and easy task. But still one of way to achieve that. Over the years there were many Pascal compilers developed and new are still created to some degree. One example would be https://wiki.freepascal.org/Projects_using_Lazarus_-_Developer_utilities#PicPas which supports only limited pascal syntax and no GUI design support, but it is still pascal compiler. The list of other compilers https://pascal.fandom.com/wiki/List_of_compilers_and_interpreters

FPC already supports multiple platforms including Android and iOS. So there is nothing that needs to be done regarding the compiler. It's library support that is missing (and in nearly all cases it's always library support that's the problem), in this case it's "LCL-Android" and "LCL-iOS" widgetsets.

I understand that there are many other Lazarus weak areas like to this date not implemented single window docked IDE like Delphi has (AnchorDocking is just a poor guy alternative).

AnchorDocking is the definite docking solution of Lazarus. There is nothing else, because nothing else is required. Sure, there are some bugs still, but other than this nothing more is needed. And it's simply not default, because there are many people that prefer the multi window approach.

Also Gtk3, Gtk4, Qt5 or whatever new toolkit version not fully supported. This is never ending effort to catch up with upcoming technologies and ever changing world. But this topic is about Mobile development and in this regard Lazarus is lacking.

Newsflash: “upcoming technologies and ever changing world” also applies to mobile development.

Generally, I think we should try to get a solution to this problem. I know that most people might not have the time or proficiency to do any development in these areas, but one solution might be to utilize the already existing Free Pascal and Lazarus foundation to collect donations for the implementation of such a project.
For example in your list above you mentioned using a transpiler. Well there is actually currently a project for integrating electron app development into Lazarus using pas2js: https://foundation.freepascal.org/projects/thread-pool-implementation
Electron works well on all major platforms, including mobile, so this is an effort theoretically anyone could support even without the corresponding skills and time.

I take it you mean this instead of the Thread Pool project?

[MarkMLl]

FPC already supports multiple platforms including Android and iOS. So there is nothing that needs to be done regarding the compiler. It's library support that is missing (and in nearly all cases it's always library support that's the problem), in this case it's "LCL-Android" and "LCL-iOS" widgetsets.

I don't think that anybody can realistically blame the compiler for the situation, unless there's some specific requirement to use e.g. a particular build tool and that's in some way incompatible with the FPC philosophy... which is unlikely.

MarkMLl

[Warfley]

As for Delphi's FireMonkey, have to strongly disagree with your assessment.  FireMonkey has been arguably a success for Delphi or at least it can be acknowledged as a good move by them to use as a mobile solution.  It put them very much into the mix of mobile app creation.  Delphi's true issue with FireMonkey is they bought it from somebody else, versus creating it in-house, thus they had to shoehorn it into their existing product.  The Lazarus team have the advantage of "20/20 hindsight", so can correct mistakes that FireMonkey has made, in addition to if they went that route then it would be their in-house solution that they developed.  What they would create, would likely more smoothly fit the Lazarus IDE and ways of doing things.

Yes it was a success for Delphi, but we must be realistic here, a success for Delphi is when people stop using it at a slightly slower rate. That doesn't mean that Firemonkey is a good solution. But what do you think how many people start learning Pascal just to use firemonkey? Well if you go by language popularity measures like the pypl index, Pascal doesn't even make it into the top 30 of most popular languages anymore so this number can't be that high.
So Firemonkey is a success for Delphi because it allows the existing Delphi developers to stick to Delphi (and probably a lot of already existing code) rather than having to switch to a new solution.
But if you are new to App development, the chances that you would choose Firemonkey over alternatives like React are basically 0.
If you look at top lists on what are the most popular languages for developing apps, you see Javascript on rank 1 usually followed by the native languages (Java/Kotlin or swift) and then the other cross languages like C# or C++ with QT. Delphi isn't even considered for most people (sure this also has something to do with the terrible buisness model of embarcadero, which is about twice as expensive as all the competitors, who usually also have a free version).

If I had to develop a mobile App, even if I was given Delphi for free, I wouldn't use it. I would rather use things like React Native, even though I have very little experience with it, because I know how terrible Firemonkey is.

Arguably, the JavaScript/HTML/CSS/browser route is best suited for web developers heavily involved and invested in that world.  And, there is an avenue for creating HTML5 applications already, which is Pas2JS or Smart Pascal.  That there is more that can be done with Pas2JS, I very much agree.  Not against web technologies, just saying that it's a different perspective for a desktop programming language to specifically make use of it when adding to what they are doing, versus being a web developer of that world where JavaScript is the primary language and are seeking to extend it's reach from browsers to desktop and mobile.

The usage of a widgetset is very different from how Pas2JS works. First Pas2JS is different from native objectpascal, simply due to the fact that it mapps onto javascript. For example the Pas2JS classes map onto Javascript classes. But Javascript classes are not classes but dynamic dictionairies so the Pas2JS classes also need to reflect this.
You can't simply translate normal pascal code to Pas2JS, at least nothing that is more than just raw algorithmic code.

The idea behind my solution is that as the pascal user you don't interact with the browser at all. You write native code for your platform and only the forms get displayed on the browser. This has for example the advantage that all the already existing pascal code would work out of the box. For example you could implement  networking with indy, which is not possible in Pas2JS because browser only support HTTP andwebsockets, but because it is native, it could simply use the native socket API.
On the other hand, this would always require a native app to run the pascal code, so unlike pas2js it would not run in the browser.

Pas2JS is it's own solution and not realy a part of the fpc-lazarus ecosystem. What I am talking about is a fpc-lazarus solution that uses the webbrowser simply as rendering engine.

Such a solution would require as much knowledge by the developer about web technology like HTML or Javascript, as you need today knowledge of the QT framework to use Lazarus on Linux (which is absolutely none)

[Blade]

Well if you go by language popularity measures like the pypl index, Pascal doesn't even make it into the top 30 of most popular languages anymore so this number can't be that high.

I wouldn't trust the PYPL data, it doesn't look right or there is bias involved.  The creator appears to have not known that Delphi was a dialect of Object Pascal, until this year.  Let me repeat that, he had this thing up for years, but didn't know such a basic thing.  Then when he was cornered about it and "forced" to combine Delphi and Pascal, clearly all of his historical data is screwed and needs to be recalculated.  That's when Delphi/Pascal (that got combined), which should have got a bump and correction for historical data, suddenly disappeared off his index.  And I think there is just nearly no way in hell that Ada is ranked 17 and kicking the butt of Delphi, Free Pascal, and all the other dialects of Pascal combined (Oxygene, PascalABC, Smart Pascal, etc...).

Just for fun, do a search of Ada on YouTube for tutorials, a very obvious thing to do.  Even if you just search for PascalABC (don't discriminate against Russian), you will be lit up with way more video tutorials than anything for Ada.  And by the way, PYPL's definition of what a tutorial is comes off as vague and confused, thus subject to being interpreted to whatever.

I would trust the TIOBE index way more (where Object Pascal is ranked #16 this month and above Go, Kotlin, Rust...). Which is not saying much, because of how easy it is for the owners to "tip the scale" with their bias or agenda, while getting views.  At least when the TIOBE index owner was confronted that Delphi was a dialect of Object Pascal, he did some grumbling about it, but reconsidered it and adjusted his Index.  Even so, check out TIOBE's "Very Long Term History".  Even though it has the top 15 languages since 1986, some how Pascal is not on there.  Let's think deeply about that for a minute.  He's showing Ada up there, which is not even presently ranked in his top 20, but not Delphi/Object Pascal.  From the late 1970's to 1990's, Pascal was definitely on the map as a top 5 language.  Turbo Pascal and Delphi made a hell of a run by themselves, where they didn't fall off until the early 2000's.  And Object Pascal is still a viable contender when the dialects are combined.

Yet TIOBE doesn't even acknowledge Pascal/Object Pascal in their "historical data", and probably because they messed up the language definitions so badly, where they don't know various compilers and IDEs were dialects of Pascal.

https://youtu.be/Og847HVwRSI
(Most Popular Programming Languages 1965 - 2019, multiple indexes)

https://youtu.be/M0vBoBqqjr0
(Most Popular Programming Languages 1965 - 2021, GitHub source)

So Firemonkey is a success for Delphi because it allows the existing Delphi developers to stick to Delphi (and probably a lot of already existing code) rather than having to switch to a new solution.

Why wouldn't this be true for Lazarus developers?  You are talking about a similar issue of programmers that may have existing Pascal code and expertise, and want to leverage that for mobile app development.  LAMW/Laz4Android is pretty much doing that, though taking a different route to get there.

But if you are new to App development, the chances that you would choose Firemonkey over alternatives like React are basically 0.

A person new to creating Apps would not automatically fall into using React.  If you are say computer repair or IT personnel, your goal can be to create applications to automate processes on the OS and existing applications.  No way would such a person touch or probably even think about React as their first choice.  They would look at tools for creating utility applications that solve their issues.  Along that trend would also be workers of or owners of small businesses that are creating such applications to make their jobs easier.  They aren't necessarily touching the Web or JavaScript first, but the computer hardware, desktop OS, existing desktop applications, etc... 

I think some things about this are also getting mixed up.  JavaScript is very popular, because it's the default language of browsers and the Web.  It's a forced standard, that until recently, was very hard to escape from.  As a Web developer, tools like React, Vue, etc... would be tools for them because they want to leverage their skills in web development and technologies to bring that to the desktop and mobile.  Their world is the Web, and when confronted on how to solve their "desktop and mobile problem", they are coming in from that direction and perspective.

A desktop developer or just a user on a desktop is coming in from a different perspective.  "I got the desktop app issue solved, so what to do about mobile?"  In that context, technologies like FireMonkey very much makes sense.  And your opinion about FireMonkey is not necessarily shared by others, as clearly there will be people that think it's great or good enough for their purposes.

From the perspective of Lazarus, it's used a lot for creating desktop applications, so the users are coming from a similar perspective as Delphi users in the wider Pascal community.  It's going to be about a more convenient and easier path to make mobile development just some additional steps to what they are presently doing and leverage their Pascal knowledge.

...Pas2JS is it's own solution and not realy a part of the fpc-lazarus ecosystem. What I am talking about is a fpc-lazarus solution that uses the webbrowser simply as rendering engine...

...Such a solution would require as much knowledge by the developer about web technology like HTML or Javascript, as you need today knowledge of the QT framework to use Lazarus on Linux (which is absolutely none)

Thanks for clarifying more specifically what you are aiming for.  You will get no argument from me on the merits of it, as it does seem viable.  I would just say that in the various directions that Lazarus users could go to do mobile development, your idea will have to prove itself in comparison.  It would be an advantage to have a way forward that could be applied for both Android and iOS.  Ultimately, it will be for the Lazarus community to decide.

[Handoko]

And I think there is just nearly no way in hell that Ada is ranked 17 and kicking the butt of Delphi, Free Pascal, and all the other dialects of Pascal combined (Oxygene, PascalABC, Smart Pascal, etc...).

Using Google Trends:
https://trends.google.com/trends/explore?date=today%205-y&q=%2Fm%2F05y49,%2Fm%2F0n6y,%2Fm%2F019p2

It said BASIC > Pascal > Ada. BASIC (yellow line in the graph below) is slowly losing its popularity. Pascal (blue) is trying to keep its position. And Ada (red) is dying.

[Warfley]

I would trust the TIOBE index way more (where Object Pascal is ranked #16 this month and above Go, Kotlin, Rust...). Which is not saying much, because of how easy it is for the owners to "tip the scale" with their bias or agenda, while getting views.  At least when the TIOBE index owner was confronted that Delphi was a dialect of Object Pascal, he did some grumbling about it, but reconsidered it and adjusted his Index.  Even so, check out TIOBE's "Very Long Term History".  Even though it has the top 15 languages since 1986, some how Pascal is not on there.  Let's think deeply about that for a minute.  He's showing Ada up there, which is not even presently ranked in his top 20, but not Delphi/Object Pascal.  From the late 1970's to 1990's, Pascal was definitely on the map as a top 5 language.  And Turbo Pascal and Delphi made a hell of run by themselves, where they didn't fall off until the early 2000's.

Yet TIOBE doesn't even acknowledge Pascal/Object Pascal in their "historical data", and probably because they messed up the language definitions so badly, where they don't know various compilers and IDEs were dialects of Pascal.

Yes the PyPL index has some issues with respect to the definition of the languages, another example is combining C and C++ is a bit icky because these languages are, while related, rather different and see very different use cases. But the TIOBE index is much worse as a measurement, because it simply does not measure what it aims to measure. TIOBE only tracks searches for "XXX Programming Language", which is not representative with language usage at all. To give you one example, this month I googled "APL programming language", "ML Programming language" and "Go Programming language". But guess what, I don't use any of them, never have and probably never will be. I googled this exactly because I didn't know anything about them and wanted the most superficial introduction about the basic paradigms (i.e. the wikipedia article). What I haven't googled was "Python programming language", "C++ Programming Language" or "Pascal Programming Language" even though these three languages was what I was actually using this month, but still for the TIOBE index I count as an APL, ML and Go developer but not as a Python C++ or Pascal developer.

So the TIOBE index is completely unusable as a metric of language popularity, like at all. And this is not just on an theoretical level, it can be easiely verified against other measures of language popularity. According to the TIOBE index C is still the second most popular programming language and JavaScript only makes it on place 7, this does not match any other statistic out there. If you look at GitHut, which tracks the share of github repositories per language: https://githut.info/ Javascript is on first place and C is on 8ths. If you look at direct surveys to developers like the ones performed by statista each year (https://www.statista.com/statistics/793628/worldwide-developer-survey-most-used-languages/) also reflects this with Javascript coming in 1st and C comes in 13ths. This also matches the PyPL index where Javascript is 3rd and C and C++ is 5ths.
So when comparing different estimates for language popularity with vastly different methods, generate quite similar results. Not only for C and Javascript, but generally these different findings show similar results.
The TIOBE index on the other hand is something that I was not able to verify against any other methodology. It is conceptually flawd as explained earlier and this is empirically measurable when compared to other approaches to measuring language popularity.

The inadequacy of the TIOBE index is actually what sparked the creation of the PYPL index, as it basically follows the same methodology, but rather than counting every search for "XXX programming language" they count "XXX tutorial" or "XXX programming tutorial". I don't think that this is a perfect metric either, I don't think it really measures the language popularity, but more the share of what new programmers are trying to learn (and therefore not measures already exisitng long term developers) but it is much better than the TIOBE index, and can be, to a certain degree, validated against other sources, something the TIOBE index spectecularly fails at.

I usually don't like to bring this up, because it always feels like people here are often gripping onto the TIOBE rank as if it is the only thing that keeps their interest in pascal validated, but except for this one index, which uses a clearly flawed methodology, I have not been able to find any other metric by which Pascal makes it even close to the top 20 of most popular languages. There are flaws in any such statistic, but TIOBE is just completely unusable for assessing the popularity of a language. And I don't like it either that Pascal has basically completely lost all of it's relevance in the modern programming world, but just closing your eyes and sticking to the only one statistic that does not show this, does not help either, especially if that statistic is so terrible like the TIOBE index is.

Fact is, for most developers, if you haven't been already using Pascal, either through prior work, education, etc. you will probably not end up using Pascal. And when we want to keep Pascal relevant, we should ask ourselves, what happend and why are the other languages so much more popular. And pretending like the situation isn't so bad, because one flawed statistic shows that it isn't so unpopular doesn't help at all.

Why wouldn't this be true for Lazarus developers?  You are talking about a similar issue of programmers that may have existing Pascal code and expertise, and want to leverage that for mobile app development.  LAMW/Laz4Android is pretty much doing that, though taking a different route to get there.

Because I think that this is not enough. We should strive for a solution that is actually good compared to other alternatives in different languages. Firemonkeys success is that it is good enough for keeping existing developers, but why be satisfied with this? Why not try to archive something that stands out and might attract new developers.
One reason why I started using Lazarus is because back when I started using it (the early 2010s), there simply was no satisfying cross plattform environment for creating GUI applications. I've started with learning Visual Basic and .Net GUI applications for Windows (and also C# as this is basically the same as VB.Net with different syntax), and later learned a little bit Delphi. Then a little bit later I started experimenting with Linux, and wanted a cross platform GUI development language like I knew from Visual Studio or Delphi. While there was this MonoDevelop with GTK#, which just has started incorporating Windows and MacOS (before it was a Linux only solution), but still was really buggy and complicated to setup on Windows. There was C++ with QT but it also was really complicated  (both C++ as a language and then also the usage of QT for building the GUI applications). When I discovered Lazarus I  was really amazed. The installation was basically just double clicking an installer (or three dpkgs on Linux) and it just worked. I already knew a bit of Delphi, and also Pascal was quite similar to Visual Basic so it was easy to get into it and start with it.

I chose Lazarus not because I was searching for a Pascal solution and Lazarus was good enough, but because I was searching a general solution and found that Pascal and Lazarus where the best solution I've seen so far. And thats what I want to get back. Not just good enough, but something that when people see it think: "That looks great I want to learn this". And I think this edge is something that Lazarus has lost over the past decade. I still think it's great, but with all the other solutions now available allowing for the same things Lazarus can, I don't think today I would make the same decision as back then, and I think thats a shame.

A person new to creating Apps would not automatically fall into using React. [...]

I just used React as an example, but this can be exchanged for any of the other solutions, let it be QT5/QT6 (which today can be easiely used with not only C++ but also Python or Javascript), Xamarin, you name it.

I just don't see how anyone who is not already a Pascal developer would start using Delphi for creating Firemonkey applications if their goal is to create mobile applications. If you search the net for "Cross platform gui framework" or "Mobile App development" or "Cross plattform app development" or anything similar you will get a lot of articles describing different platforms frameworks and languages, but I haven't found a single mention of Firemonkey.
This is not sustainable for the community long term. A lot of the people in this forum are here because thy already used TP or Delphi in the past. But how should this  look in 10 or 20 years? If all we focus on is serving already existing Pascal developers, there is no future.

The buisness model of Delphi is to stick to long term developers. Delphi still supports very old Delphi code and makes migrating from one version to the other very seamless. This works for Delphi as it targets mostly the professional world with large long living projects. The focus of Delphi is very narrow, and it can easiely be seen by the complete lack of options for small developers (the starter edition is a complete joke compared to VS community or similar alternatives for other languages), and this is the role Lazarus fills. And while this strategy is working quite well for Delphi, I have serious doubts that this would work for Lazarus.
Lazarus is not an Enterprise solution like Delphi is. It has a different user base and should therefore also try to cater to that userbase. Delphi compatibility has been one of the great strengths of Lazarus and FreePascal, and while I think on the language level this is still quite good, I don't think that Lazarus as an IDE and the LCL as a framework should follow the buisness decisions of Embarcadero.

[MarkMLl]

The only realistic direction  that I see would be to start something to just bridge Android/iOS based on some general FMX principles (without compatibility, too much hassle) or LCL customdrawn. (more headstart, but somewhat outdated). Or fully new with more CSS like approach, like Warfley advocates. (I'm no fan of that, but don't know enough about the praciticalities of such approach)

Although frameworks such as Electron and Uranium can end up being a bloated, undebuggable mess.

One of the strong points of Lazarus has always been well-integrated debugging. In that area it exceeds Delphi since even if it omits some details it works consistently across platforms.

MarkMLl