Viability of FMX mobile applications

FMX
1

@hsvandrew asked me a question on an older thread and suggested I answer in a new topic. It seemed a reasonable enough request so here we are. :slight_smile:

If you’re a Delphi developer I don’t feel a lack of trust in Embarcadero being ready for new OS launches is justified.

They’ve actually done a very good job in either being ready, or in occasions when they weren’t ready, arranging exemptions for Delphi applications with Apple/Google. I might be forgetting some occasion but overall their record over almost a decade now is pretty good.

If you’re a C++ developer though, that lack of trust is certainly warranted. I don’t think you can even build C++ applications for Android right now, I believe they’ve even stopped mentioning it as a feature.

C++ is always a step behind Delphi though and to be frank, after using it a bit recently for some VCL development work quite broken in other important areas too.

Performance and visual appearance are reasons I would currently go elsewhere if I was looking to write the next TikTok or Twitter.

I’m mostly writing companion mobile applications for existing VCL based business software though and the using the same language and tools outweighs these disadvantages.

Specifically the startup time of Delphi mobile applications is longer than I’d like but other than that I find the performance of the rest of an FMX application acceptable. I agree they’re not quite as snappy as applications built with the native toolsets but they’re a long way from unusable.

The visual appearance of my FMX applications I do rate as poor. That is to a very large degree down to my lack of interest and skill in that area, but I also acknowledge that FMX doesn’t help in this area any where near as much as it should.

I’d dispute your categorization of “dead silence in the Delphi world”. There are a number of vendors with FMX components for sale and our own @davidn has an excellent library Kastri which makes integrating OS services into your application easier (plus many other useful things).

The greater point of not being able to use libraries written for XCode/Android Studio, well you could use a similar argument against VCL applications in relation to .NET based Visual Studio libraries. To incorporate those libraries into your VCL application requires jumping through more than a few hoops yet we’re still writing VCL code.

Again if I was writing the next TikTok, Twitter or Google Maps perhaps the ability to use a wider range of libraries would be a bigger deal to me. For the boring old business applications I’m writing though I don’t have a big need for them.

Also I guess I should say, are you sure you can’t use the libraries you need in a Delphi mobile application? If they’re visually based then yes that’s going to be quite difficult to integrate into an FMX application but if they’re non-visual libraries the effort required may be acceptable?

1 Like
2

I wasn’t comfortable with my assessment of the visual appearance of FMX applications (since I’m so bad at it) so I did a quick Google to see what more design oriented developers can do with FMX.

I found these two applications via the Embarcadero website which look reasonable enough to me. I’d be interested to know how much effort it took to make them look like that as opposed to using the native toolsets.

3

It has been improving in the past few years.

This can be because many developers use startup code (e.g. in OnCreate of the main form) that could otherwise be deferred until the application becomes “active” and/or done as a background task.

Thanks!

Delphi apps can use libraries written for Xcode and Android Studio, so I’m not sure what was meant by this.

These are a couple of my “go to” videos to demonstrate what can be achieved with Delphi:

There’s a more complete list somewhere out there…

4

There are also other factors that should be considered, including:

  • Initial and ongoing cost of the tool-chain, including IDE and any 3rd party libraries
  • Availability of developers with experience in the technologies to support the application
  • Amount of support for the technologies on open sources (Stack overflow, Medium blogs, etc.)
  • Speed of development (Delphi has some advantages here).
  • Whether cross platform capability is a requirement. (For example I developed a FMX app for a client that only runs on Android based bar-code scanners, so cross platform was not a consideration.)
5

Another factor is the extent to which rewrites to your code will be required as the underlying platform changes in the future.

Delphi has historically had a great advantage here as we found with VCL applications on Windows. As developers using Microsoft tools had to react to the rug being pulled out from under them every 5 years or so, the VCL insulated us from most of those changes. It gave us access to new features without having to throw out old code. Even when .NET came along, the migration path to VCL.NET was far simpler than any other platform.

FMX is fulfilling a similar role, code you wrote back in the very early days will run today with only tweaks around the edges.

With FMX we are a few more steps removed from the platform than VCL was, which can be a bit annoying sometimes and also means we lag behind with platform enhancements a bit more than VCL did with Windows.

6

From my perspective, I’d say Rad Studio is still the best choice for a deploying a mobile app and windows/Mac-
OS dashboard using the same codebase. Although FMX is game ready, truly harnessing it’s power requires years of esoteric knowledge and workarounds, as you VCL/Delphi devs are no doubt fully aware. This space is increasingly becoming crowded with other frameworks and languages, although with the demise of newsgroups/journals in favour of searching Dr Google → StackOverFlow, and their lack of maturity, I’m thinking they are likely to have similar/worse issues.

The decision to pull Google Play support a few years ago for C++ Builder stung more than a little. Although Emb’s strategy seemed perplexing because supporting it would AFAIK be pretty easy given the shared codebase, maybe C++ Builder was losing them Delphi licences?

If I get asked to deploy a Rad Studio mobile/desktop app again, the good news is that I think I could still do so by developing the GUI using Delphi and code the logic in C++, e.g. Mixing Delphi and C++ With David Millington - CodeRage XI - YouTube

As @StephenCorbett alludes to, a lot of the years of heard-earned fast-prototyping Delphi skills are being lost and not being replaced. The rate of attrition may even be accelerating, with MS now declaring C++ as being legacy due to our code’s poor reputation for memory safety (according to Google) Programming languages: It's time to stop using C and C++ for new projects, says Microsoft Azure CTO | ZDNET

7

I missed this at the time it happened though it’s hardly something they would have been trumpeting loudly. Since the support for C++/Android was there and working fine for a few years I can only assume it was a resourcing decision. Presumably too much effort for too few users of that particular language/platform combination.

Funny :grin:

8

Yep, more than likeley a resources issue - something had to give.

I suspect this also to do with them switching from being a C++ compiler developer to C++ compiler customiser - the newer compilers are using CLang - not the old BCC codebase.

There’s a lot of benefits to them doing this (modern c++ features) but also a lot of downsides - BCC had a lot of extensions to make it interop with delphi nicely - and those are a major pain point with CLang.

I don’t do mobile dev, so I can’t really comment much on the viability of FMX except to say that it would not be my first choice (neither would xcode or andriod studio from my limited experience with them).

Most mobile apps are complementary to existing business processes (so need a remote service to do anything useful) - so why go to the expense of creating native mobile and web apps, when a responsive web app can provide a very good mobile experience (using react or vuejs etc).

That said, there must be plenty of people trying to do mobile dev with delphi if the (non spam ones at least) posts on the delphi facebook groups are anything to go by :wink:

1 Like
9

That’s certainly not going to help - perhaps Embarcadero should create a Rust based IDE and cross platform UI framework (there are a few open source initatives trying to do this). Maybe they already are :thinking: - I have no inside knowledge - just speculating on something I would consider if I were in charge of setting product direction.

I’ve had a play with rust (and go) a few times over the years, I certainly like it more than C++ - but not more than C# - if there were a dev environment and cross platform UI framework like the VCL or FMX for creating desktop/mobile apps - that might be pretty compelling - but for now I’ll stick to Delphi on the desktop and C# on the server.

1 Like
10

I imagine if Embarcadero doesn’t get C++/Android back in the product soon it will also mean the slow death of C++/iOS.

There just won’t be that many mobile projects where the developers will say “we’re prepared to only target iOS”. If that’s not a problem for them, then why use FMX at all, just go XCode. If they need Android and iOS, they’ll use Delphi.

Even if they do get C++/Android back in there soon it will be a big risk to depend on it for some time. The past 2 years have shown us which language/platform combination they regard as most expendable.

11

I would imagine it already has slowed (if not totally killed) the C++ for mobile usage - a lot of people were burned by the dropping of android support - it’s not like windows where you can just stick with an older version - Google and Apple regularly break things in the mobile space and that breaks Rad Studio - the only way around that is to keep updating Rad Studio… except… well… you can’t. I guess there might be hacky ways around that if you invest enough time looking under the hood - but then you might as well just use the platform native tools.

12

I will be speaking to IT DevCon on precisely this topic. The amount of reuse you can achieve is… staggering, as long as you accept that you can’t design your app as you would a VCL-only one.
As long as you accept that, the sheer amount of reuse - even for UI bound code - is absolutely massive.
Then again, you have to give up on the idea of doing your VCL app the way you do VCL-only.

Cheers!

1 Like
13

BTW @Lachlan FMX C++ still deploys fine to Android! All I said was they dropped Google Play support.

14

Regarding Android deployment: I used to distribute the 32 bit arm binary easily using Gmail. Not sure if that has been disabled but I guess if I was writing an Govt app, I’d have an official mechanism

15

So the situation is currently?

  • You can add a 32 bit Android target for your C++ project in the project manager,
  • You cannot add a 64 bit Android target for your C++ project in the project manager,
  • The Google Play store no longer accepts any 32 bit apps that don’t also include a 64 bit version.
  • You can sideload a 32 bit app to a 32 bit Android device.
  • Can you sideload a 32 bit app to a 64 bit Android device?
  • If there are third party app stores that still accept 32 bit only applications you presumably could submit your app to those.
1 Like
16

Yes probably but I can’t be sure as they have lost my subscription and I won’t be renewing until they bring back Google Play support.

BTW just wondering if a Delphi FMX GUI app can be debugged in Linux. MS-VS now does this via WSL2 Build and Debug C++ with WSL 2 Distributions and Visual Studio 2022 - C++ Team Blog

17

Not something I’ve done myself but it appears that the PAServer is available for Linux so the answer should be yes.

18

A bit late to the party but I think that Delphi is (still) a good choice for mobile apps.

We have a moderately simple app (login, several pages/tabs with charts/tables of various data retrieved and periodically refreshed from our servers, push notifications) that is aimed at users of our larger desktop app and has maybe a few hundred regular users.

We only release a new version about every 8-12 months. Targetting Android & iOS with one code base is great (we do have some platform specific code, mostly around layout handling for notches/cameras, plus notification quirks, etc) and Windows for quick prototyping.

Adding new features/making changes is relatively straight-forward, however any specialised UI behaviour can take far too long to get right (pinch zoom in charts, swipe gestures on scrollable tables, the layout issues mentioned above) - more than you would get developing a VLC app purely for Windows.

Perhaps the biggest issue, for us at least, is that it seems every time we want to release a new version one or both of the app stores has new requirements and we have to upgrade SDKs/Delphi/Xcode/MacOS (we have experienced some of the pain/waiting for Delphi to catch up with store/SDK requirements), figure out new project settings, decipher new error messages, and muck around for days sorting it all out (on top of store layout changes, getting the CEO to sign a new agreement, creating new resolution screenshots, etc). There is definitely room there for a smoother upgrade experience. Luckily we have created a comprehensive doc for getting it set up end to end (especially helpful when there are multiple devs).

I’m happy where we are and if I were developing a new mobile app I would definitely go with Delphi but I am not up to date with the latest mobile app development alternatives these days.