Recent

Author Topic: Mobile development - Android & iOS  (Read 20285 times)

MarkMLl

  • Hero Member
  • *****
  • Posts: 3648
Re: Mobile development - Android & iOS
« Reply #30 on: December 08, 2021, 08:16:23 pm »
Ah ok so I misunderstood this, I thought this was about that the application of the LCL frameworks for android and/or ios should be targetet at experienced programmers. This makes sense

I've always been torn between whether or not it's wise to have a single language like Object Pascal which is proficient at both application- and system-level programming, or if a split as with VB and VC++ was preferable. Now that so many people demand automatically-managed memory I think I'm moving towards the split approach: Rust (as a specific example) appears to succeed at doing both safely but the cost is having assignment semantics which are rather non-ALGOL.

Quote
I think the most important part isn't the language itself, it's the tooling. I think one of the great features of Javascript, and why it is so popular, is because, basically you can just open up any editor, write 3 lines, double click it and it works.

Javascript is also remarkably popular as a language that benefits enormously from something more rigorous layered on top of it.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

dseligo

  • Sr. Member
  • ****
  • Posts: 429
Re: Mobile development - Android & iOS
« Reply #31 on: December 08, 2021, 09:34:06 pm »
e.g. WhatsApp the most widely used chat application is not available for Desktop

Yes, it is available. And Viber also - probably all popular chat applications.

Warfley

  • Hero Member
  • *****
  • Posts: 654
Re: Mobile development - Android & iOS
« Reply #32 on: December 08, 2021, 10:38:37 pm »
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.
« Last Edit: December 08, 2021, 10:47:37 pm by Warfley »

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 9766
  • FPC developer.
Re: Mobile development - Android & iOS
« Reply #33 on: December 08, 2021, 11:09:33 pm »
Also whatsapp still requires a phone

Whatsapp basically uses your telephone number as your login. Changing that for a desktop app would be massive, but also makes it an exception, and IMHO a bad model for comparison.

I tried to get mobile development to get rolling several times in the company I work for, but in practice the customers really want it, but consider it a nice to have that they don't want to pay for. IOW it faltered already before the divisive discussion about platforms :)

That said, I have some doubts about single source GUI for mobile and desktop. The form factors and UI culture are simply quite different.
« Last Edit: December 08, 2021, 11:12:17 pm by marcov »

Blade

  • Full Member
  • ***
  • Posts: 176
Re: Mobile development - Android & iOS
« Reply #34 on: December 09, 2021, 12:06:49 am »
I think the most important part isn't the language itself, it's the tooling. I think one of the great features of Javascript, and why it is so popular, is because, basically you can just open up any editor, write 3 lines, double click it and it works.

Lazarus for Windows is also quite great, you just download the exe installer and everything works out of the box. But only if you develop on windows for windows. Even things like compiling for Linux on a Windows is pretty complicated

It's needed, but don't think JavaScript is all that wonderful.  Let's not forget how widely popular that TypeScript has become, because of the perceived inadequacies of JavaScript.  Then of course you are not usually dealing with just JavaScript, but 2 other "almost languages", CSS and HTML.  Thus the dizzying array of constantly changing and new frameworks to try to tame the "3 headed monster".

Object Pascal can do things that JavaScript can't and offers various specific advantages by allowing the direct targeting of the OSes.  With Free Pascal/Lazarus, it's usually more a matter of what percentage of your code will be reusable among the OSes targeted.  For the desktop OSes, that's going to be extremely high, with only small alterations.  If the Object Pascal programmer wants HTML5 applications, there is the pas2js transpiler for Free Pascal/Lazarus, and some other Pascal dialects have similar (Smart Pascal).

It's arguably about what to do with creating mobile applications with Lazarus.  Android is partially embraced by Lazarus, so we have this "middle of the road" situation.  Why not cross the road, and fully embrace mobile development?

Yes, mobile development is going to be bit different, but there are some lesser known programming/scripting languages (free and commercial) that have figured it out to various degrees.  I'm talking about mobile development on the Windows OS, with IDEs for their language, creating applications for other OSes.  They even have built-in mobile device simulators/screen simulators on Windows, for both Android and iOS.

Our favorite IDE, Lazarus, is more than capable of doing such.  We have seen Delphi do it (in their own way) for years.  If anything, Lazarus has numerous advantages in how to implement it.  And it doesn't have to be anything particularly radical.  There appears to be various paths with Qt5 and above or custom-drawn. 

Even a general call for volunteer developers that have the skills to make it happen, could be enough to cross over enough where its not in limbo, but there is a way forward where people can read about it on wiki and in help documents.  It appears that various developers have quietly used Free Pascal/Lazarus for mobile development in the past, using various undisclosed/not widely known methods.  It's debatably about time to make such knowledge more publicly known or have projects that show the way, for a more healthy future.
« Last Edit: December 09, 2021, 08:00:59 am by Blade »

Blade

  • Full Member
  • ***
  • Posts: 176
Re: Mobile development - Android & iOS
« Reply #35 on: December 09, 2021, 01:05:24 am »
Thank you for entering the discussion.  Much respect, as I realize it's a bit tricky from your perspective.

...but in practice the customers really want it, but consider it a nice to have that they don't want to pay for...

Maybe refer to the post by Chronos on the 2nd page.  Clearly developers might want to PM him for clarification.

Quote
That said, I have some doubts about single source GUI for mobile and desktop. The form factors and UI culture are simply quite different.

I agree about the form factor and cultural elements involved, but would say there is possibly more at stake.  Mobile is becoming increasingly more important, where more people are going to continue to notice Lazarus hasn't embraced it, and a lot of people would be looking to create applications on both.  I don't want to be so "look at them" about it, but other languages and IDEs seem to increasingly be providing both mobile and desktop development options.  Among what's out there is of course Delphi, and Lazarus is almost automatically going to be compared with it.  Culture is definitely tricky, but at least when it comes to form factors and simulating mobile screens, it appears solvable.  Various IDEs have solutions and even their own simulators for developing on Windows, for both Android and iOS.

Looking at Lazarus, many can already see the seeds of potential mobile development.  Even if just only the custom drawn interface path, there is LCL-CustomDrawn-Android, so that there isn't LCL-CustomDrawn-iPhone seems a bit odd.  Moving in only that direction would seem helpful.

What I was wondering, as QT5 supports Mobile, wouldn't it be possible to use the already existing widgetset for mobile. But I am simply not knowledgable enough about QT and the corresponding widgetsets for that matter

Could you elaborate about Qt5 mobile platform support, as it could possibly pertain to Lazarus mobile development?

trev

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 1786
  • Former Delphi 1-7, 10.2 user
Re: Mobile development - Android & iOS
« Reply #36 on: December 09, 2021, 03:52:28 am »
When I retitled and split this thread off from the original, I should probably have added iPadOS to the title. A lot of acquaintances in my older age group have forsaken computers altogether and, while most have mobile phones, it is tablets that have been filling the gap.

It is unfortunate that Lazarus has little, if any, support for these mobile devices, but quite understandable given the volunteer nature of the beast. Even when someone takes up the challenge, there are few early adopters in the existing audience and, I'd guess, that results in such efforts being ultimately abandoned. Yes, it's the chicken and the egg dilemma.

Android development seems to be progressing reasonably with jmpessoa and his LAMW addon, though it could do with better promotion and Wiki documentation.

iOS/iPadOS development seems all but dead: one forum thread in 2019, two in 2020 and one this year.

The harvest is rich, but the workers are few.
Lazarus 2.3, FPC 3.3.1 macOS 12.1 x86_64 Xcode 13.2
Lazarus 2.3, FPC 3.3.1 macOS 12.1 aarch64 Xcode 13.2
Lazarus 2.3, FPC 3.2.2 FreeBSD 13.0 amd64 VM
Lazarus 2.3, FPC 3.2.2 FreeBSD 12.2 amd64 VM
Lazarus 2.1 r61574 FPC 3.0.4 Ubuntu 20.04 VM
Lazarus 2.0.10 FPC 3.2.0 Win10 amd64 VM

Blade

  • Full Member
  • ***
  • Posts: 176
Re: Mobile development - Android & iOS
« Reply #37 on: December 09, 2021, 08:48:09 am »
Android development seems to be progressing reasonably with jmpessoa and his LAMW addon, though it could do with better promotion and Wiki documentation.

Totally agree.  Jmpessoa and team have done a fantastic job for unofficial Android development with Lazarus.  It's because of the success on the Android side that it brings up the question as to what's going on with iOS.

Quote
iOS/iPadOS development seems all but dead: one forum thread in 2019, two in 2020 and one this year.

Maybe because there isn't any officially supported or at least obvious paths to iOS development, like there is on the Android side, that we don't see any talk of it.  It appears from past forum posts that when a more definitive way forward with Android development was shown, it then attracted interest.  "Oh OK, that's how we can do it."  "Hey, I tried your method of building Android apps and it works great." 

There are a number of unofficial and unsupported paths to iOS development with Free Pascal and/or Lazarus.  A former "team member" of jmpessoa, Simon Choi, has clearly shown it's very possible and has been so for awhile.  Some of his blog posts: https://m.blog.naver.com/simonsayz/220485321971, https://m.blog.naver.com/simonsayz/221209784815.  I think the issue was that it wasn't known or "rolled up" into something like LAMW, as what jmpessoa and his other team members did for Android.

There is also the Castle Game Engine (https://castle-engine.io/), which people might want to notice has now got the attention of Delphi (so who knows what they may be up to).  It's possible to use it for development for both Android and iOS, through OpenGL, but clearly there is more with a game engine than particular developers might be looking for.  And I can't help but to wonder if Lazarus should have/still can do some type of collaboration with him.  What he has done does show another possible path.

If there is no official promotion of such capabilities by Lazarus, then it's arguably fair to say that many people will overlook what it can do.  Probably only the more frequent forum visitors or just through the sheer luck of an Internet search (and keep in mind that Google has its own languages and agenda) that users would come across some bit of information.  It's quite easy to overlook or not mention something that you believe the thing in question is not capable of.
« Last Edit: December 09, 2021, 09:12:26 am by Blade »

Warfley

  • Hero Member
  • *****
  • Posts: 654
Re: Mobile development - Android & iOS
« Reply #38 on: December 09, 2021, 10:52:46 am »
Whatsapp basically uses your telephone number as your login. Changing that for a desktop app would be massive, but also makes it an exception, and IMHO a bad model for comparison.

I tried to get mobile development to get rolling several times in the company I work for, but in practice the customers really want it, but consider it a nice to have that they don't want to pay for. IOW it faltered already before the divisive discussion about platforms :)
It is highly dependent on the kind of app. For example Uber Eats, even though it has a website, requires you to create your account via their app. Gorillaz the grocery delivery service, is completely only on app. Another great example is Spotify, while it has a Desktop version, the App is much more used.
In many areas you need an app and the desktop version is optional. For example, no one needs a music player that doesn't work on their phone, where most people listen music to. Of course there are other areas where it's the other way around, but the thing is mobile is extremely important, and I think there is no arguing around fact that Lazarus is in dire need of better (and more importantly unified) support for mobile platforms

That said, I have some doubts about single source GUI for mobile and desktop. The form factors and UI culture are simply quite different.
Yes and no. It is of course very different, but there are a lot of things that can be automated. Windows UWP apps, Angular webapps, Xamarin and even FireMonkey already support this quite good with a high degree of automization.
The thing while this works so well is, because mobile apps already need to support different form factors. There is no fixed format for phones. With the new Samsung folding phones, you can have a nearly rectengular screen size. You  need to support tablets and phones in both vertical and horizontal mode, etc. This is actually a problem that already exists since decades in the web. There you need to support all kinds of different monitor sizes, 4:3, 16:9 16:10, 23:9, since the last decade also all the different phone and tablet sizes.
This is both highly supported through the architecture of HTML and CSS, but also dynamic frameworks like Angular are developed to target exactly this problem. Generally speaking, this is a problem that was already successful solved by many different frameworks. I don't see that as really a problem.

It's needed, but don't think JavaScript is all that wonderful.  Let's not forget how widely popular that TypeScript has become, because of the perceived inadequacies of JavaScript.  Then of course you are not usually dealing with just JavaScript, but 2 other "almost languages", CSS and HTML.  Thus the dizzying array of constantly changing and new frameworks to try to tame the "3 headed monster".
Javascript is a terrible language. It was created by one person in a week and afterwards always extended but could never be redesigned as it requires to be backwards compatible to the very first version. The new features are often actually quite nice, but that is the main problem with JS, it has a lot of terrible features and a lot of good features and as a developer you are responsible for only choosing the good features (what of course isn't that easy, especially for beginners). If you like to have a good laugh, watch the talk "Javascript the good, the bad and the ugly".

But that about CSS and HTML5 is not necessarily true. For example many modern web applications are today build with AngularJS. These are fully JS based websites, no single line of HTML is needed (still CSS for styling, but you can also just import existing styles), and is therefore much more comparable to QT or Xamarin GUI applications.

Could you elaborate about Qt5 mobile platform support, as it could possibly pertain to Lazarus mobile development?
I don't know much about how QT is integrated into the LCL, but on Desktop you can basically the QT-Creator to create C++ GUI applications to run on mobile. The QT Creator form editor is a run of the middle WYSIWYG form editor and the applications work on both desktop and mobile. It is probably the closest to how an LCL integration would look like for the user.
But I must admit the last time I used QT is also a few years ago

Warfley

  • Hero Member
  • *****
  • Posts: 654
Re: Mobile development - Android & iOS
« Reply #39 on: December 09, 2021, 12:47:43 pm »
I've always been torn between whether or not it's wise to have a single language like Object Pascal which is proficient at both application- and system-level programming, or if a split as with VB and VC++ was preferable. Now that so many people demand automatically-managed memory I think I'm moving towards the split approach: Rust (as a specific example) appears to succeed at doing both safely but the cost is having assignment semantics which are rather non-ALGOL.

This is quite an interesting question. I myself think that most of the time manual memory management just introduces unnecessary complexity, especially considering that in most cases, performance (which is the main counter point to automatic memory management) does not really play a role. I often brought this up, but there was this great analysis by Mozilla when they rewrote their CSS engine in Rust, where they analyzed all the bugreports regarding that code, and found that of the 34 bugs tagged as critical security issues, 32 where due to errors in manual memory management (dangling pointers, use after free, etc). So it is clearly very hard to get it right, something everyone seems to have problems with, and when you get it wrong it is a very serious issue.
And I think on some level most pascal developers agree with this, because I've never seen anyone complain that C-Style strings with manual memory management are better then the reference counted pascal strings (same for arrays). And it also shows that it is not that hard to make this work

And this is why I think pascal is an a very weird situation. It tries to be a high level language and a low level language at the same time. We have reference counted strings and arrays, but classes need manual memory management, which is especially weird if you think about that classes already try to go the Javaesque way of hinding the fact that they are pointers in the first place.

A language that manages to incorporate high level and low level concepts simultaniously is C++. For example automated reference counting is done fully on top of already existing language means, by utilizing their stack based classes:
Code: C  [Select][+][-]
  1. auto ptr = std::make_shared<SomeType>(constructor_args);
  2. ptr->somemethod(...);
What also makes this neat in C++ is that you can overload the dereferencing operator, so you can create classes that for the user behave exactly like a pointer, but internally do other stuff like reference counting.
If management operators would be working correctly this could also be implemented (even though we don't have a dereferencing operator).
Another thing I really like in C++ is the usage of references to hide pointers. Similar to var parameters in pascal functions, but with the difference that this can be appied to any type, parameters, variables and even function return values:
Code: C  [Select][+][-]
  1. int &operator [](int index) { return self.items[index]; }
As this returns a reference, you can read and write to it, and also take the pointer. In pascal you would need a getter and setter for the indexed property, and this wouldn't allow you to get a pointer to the underlying memory, which would require another property. E.g. from the Tvector class emulating this behavior:
Code: Pascal  [Select][+][-]
  1.     property Items[i : SizeUInt]: T read getValue write setValue; default;
  2.     property Mutable[i : SizeUInt]: PT read getMutable;
This hides pointers while also still allowing access to them in the rare cases you need them.

But this comes at the cost of complexity C++ is not an easy language to learn and just behind this one line:
Code: Pascal  [Select][+][-]
  1. auto ptr = std::make_shared<SomeType>(constructor_args);
is a lot of complex code that requires a rather advanced understanding of C++.

Other modern languages that have been designed from scratch with high level development in mind, usually don't go this low level route anymore at all. Even languages like Swift that are still compiled "on the metal" languages like Pascal, show how through language design you can combat some of the larger problems and causes of bugs in programming. I really like swift in that regard, even though I don't use that language like at all (I haven't had a mac in years) but it has some really neat new ideas (like optionals at the language level), while also sticking to what has been proven (e.g. static typing). This is the advantage of having to design a language from scratch, something that for "grown" languages like C++ or Pascal is not really possible. But still interesting to consider and I can only recommend for people interested in this sort of stuff to take a look at the language guide: https://docs.swift.org/swift-book/LanguageGuide/TheBasics.html


But with respect to the original question, if it is good to have such an in-between language between very low level C like and high level languages like Swift, I think that this can work out. C++ shows that it is possible, but Pascal is not C++. I think generally Pascal is used in areas more associated with high level languages than C++ and I think the language should reflect this. Because at the moment Pascal targets the use cases usually associated with very High level languages (e.g. RAT GUI development) while still being very low level in use.
« Last Edit: December 09, 2021, 12:52:04 pm by Warfley »

MarkMLl

  • Hero Member
  • *****
  • Posts: 3648
Re: Mobile development - Android & iOS
« Reply #40 on: December 09, 2021, 01:17:10 pm »
I'll keep my comments brief because this wanders away from what is already a somewhat rambling topic.

We have reference counted strings and arrays, but classes need manual memory management, which is especially weird if you think about that classes already try to go the Javaesque way of hinding the fact that they are pointers in the first place.

In the general case, reference counting works well, but once one gets to the lower implementation levels it's possible to define code and structures which fool it necessitating a lot of finalisation code. So mandating it might usefully be one of the distinguishing marks of "Application Pascal", while "System Pascal" allows it to be bypassed and reimplemented by qualified users.

Quote
What also makes this neat in C++ is that you can overload the dereferencing operator, so you can create classes that for the user behave exactly like a pointer, but internally do other stuff like reference counting.

Strongly agreed. But then C++ goes and spoils it by automatic casting: I'd rather see that controlled by a trait system (e.g. a byte has a trait which makes it a compatible lvalue for any other 8-bit type, but an unsigned 8-bit integer does not).

Quote
If management operators would be working correctly this could also be implemented (even though we don't have a dereferencing operator).

Noting that there's a modeswitch for that. I asked about having ^ overloadable, and Jonas was strongly against it. But I believe it works well where there is no automatic casting, and in fact renders a separate reference type largely obsolete (the remaining cases could probably be handled by traits).

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

PascalDragon

  • Hero Member
  • *****
  • Posts: 3624
  • Compiler Developer
Re: Mobile development - Android & iOS
« Reply #41 on: December 09, 2021, 01:48:06 pm »
In addition, by Lazarus already having LCL-CustomDrawn-Android, it then also creates the expectation to see LCL-CustomDrawn-iPhone.  It could be said that it comes off a bit weird to somewhat embrace Android, but not iOS.

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.

MarkMLl

  • Hero Member
  • *****
  • Posts: 3648
Re: Mobile development - Android & iOS
« Reply #42 on: December 09, 2021, 02:12:16 pm »
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.

Wasn't there also something at one point about Apple's policies being actively hostile to anything other than their designated tools?

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 9766
  • FPC developer.
Re: Mobile development - Android & iOS
« Reply #43 on: December 09, 2021, 03:12:40 pm »
Thank you for entering the discussion.  Much respect, as I realize it's a bit tricky from your perspective.

...but in practice the customers really want it, but consider it a nice to have that they don't want to pay for...

Maybe refer to the post by Chronos on the 2nd page.  Clearly developers might want to PM him for clarification.

I assume you mean this:

The problem is that more people use mobile and tablets now than desktops. The desktops are more suitable for real work but still most of the people simply have their smartphone with themselves all the time. So inability to target that audience by Lazarus is pretty huge deficiency. Sure, not every development environment support all modes like desktop, mobile, web and console. But with Lazarus we have that expectation "Build once, compile anywhere" which is simply not true for entire mobile segment.

I usually just ignore such statements.  This was all already debunked in the pre IPhone java phone period, and discussions around marketplaces.

There are several problems with this:
[
  • The numbers are artificially inflated by an humongous amount. Not every phone sold should count as a potential sale for a SMB app maker. Most people's phones only have Fortune 500 and a few local apps (I have like the garbage schedule app, and the Dutch Corona QR code app and Marktplaats, but that is an Ebay subsidary). I've looked at the phones of my friends (some of which are developers, and all of them are technically educated) and the variation of apps is extremely low. I don't think I saw anything not from a global and local shortlist except maybe for open source ki9 email app)
  • And more importantly I saw no apps that were not explicitely designed for mobile, at least as far as GUI goes. Probably they even fully confirm to the vendors platforms.

So basically the global marketplace where every device counts as a potential audience for a 3S (single language, single source, single GUI) apps simply doesn't seem to exist, except in polemics.

Quote
Quote
That said, I have some doubts about single source GUI for mobile and desktop. The form factors and UI culture are simply quite different.

I agree about the form factor and cultural elements involved, but would say there is possibly more at stake.  Mobile is becoming increasingly more important, where more people are going to continue to notice Lazarus hasn't embraced it, and a lot of people would be looking to create applications on both. 

It will be interesting to see what you and Chronos come up with then :)

We have had such discussions umpteen times before, but somehow people don't seem to understand that FPC and Lazarus don't have resources that they can redirect or focus. The developers are volunteers and do what they want.

And this volunteer (which is a bit in repose atm actually) has tried to up sell his customers to both cloud and tablet/phone apps for over a decade, and hasn't generated one single euro revenue from it. I tried to bundle as freebee with higher value SLA contracts, and even that didn't fly. And that was a Delphi licensee with the base technology already there.

People talk the enterprise way, but when it comes to selecting features and stomping up the cash, it suddenly goes in a different direction. Differentiate very carefully between them. As said look at your friends/customers etc phones, and count the number of apps from companies that you can realistically see as "competitors".

If you are in some extreme lucky situation that you actually find one, try to find out what it is made with.

Quote
I don't want to be so "look at them" about it, but other languages and IDEs seem to increasingly be providing both mobile and desktop development options. 

You are begging for a single GUI library solution here. Which of those IDES provide that? IOW which also leverage their prime native desktop solution on mobile ? Does MS support MFC on mobile? Does Delphi support VCL ?

Delphi does in theory with FM, but in reality most customers have dedicate FM GUIs for mobile and good old VCL on the desktop, simply because FM is buggy as hell. Or at least that is what I hear.

Quote
Among what's out there is of course Delphi, and Lazarus is almost automatically going to be compared with it.  Culture is definitely tricky, but at least when it comes to form factors and simulating mobile screens, it appears solvable.  Various IDEs have solutions and even their own simulators for developing on Windows, for both Android and iOS.

Quote
Looking at Lazarus, many can already see the seeds of potential mobile development.  Even if just only the custom drawn interface path, there is LCL-CustomDrawn-Android, so that there isn't LCL-CustomDrawn-iPhone seems a bit odd.  Moving in only that direction would seem helpful.

Are customdrawn apps acceptable on phones INYO? Good chance that they won't even be accepted into the IPhone store if there is only one little thing a bit off, look and feel wise. Delphi just fixes such issues continuously, financed  from your next year's subscription, but I think a FPC/Lazarus devel would burn out after two years. This simply is not sustainable.

I think there is a future for a good customdrawn backend for various solutions, as a zero order fallback solution for various reasons. But finding somebody to put in the time is the difficulty. I also don't expect such solutions to compete with IDEs sponsored by Fortune 500 companies and Embarcadero (  ;) ) any, any time soon.

(QT)

afaik mobile is based on QT quick, while lazarus does old fashioned QT


In summary, I don't see a practical route to something like that. We can't develop fast enough, and the solution will require permanent heavy duty maintenance to keep up with the yearly iterations. Moreover we already have a shortage of interested developers for even the rock bottom solution (customdrawn/lamw, the latter which is the labour of love of one developer).

I can be wrong of course. Maybe one of you has a 10 person team in his pocket just chomping at the bits to contribute :-)
« Last Edit: December 09, 2021, 03:28:51 pm by marcov »

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 9766
  • FPC developer.
Re: Mobile development - Android & iOS
« Reply #44 on: December 09, 2021, 03:25:01 pm »
When I retitled and split this thread off from the original, I should probably have added iPadOS to the title. A lot of acquaintances in my older age group have forsaken computers altogether and, while most have mobile phones, it is tablets that have been filling the gap.

How many have custom applications made by SMB on them other than maybe games?

 

TinyPortal © 2005-2018