Rollo62

Perhaps, but I assume if there is already one custom control, then its very likely that there are several custom components units too, like MyCustomCalendar.pas MyCustomThis.pas MyCustomThat.pas wouldn't it be cleaner to combine the registration for the designer in a common registration unit? MyCustomReg.pas procedure Register; begin RegisterComponents('My Delphi Tools', [TMyCustomCalendar, TMyCustomThis, TMyCustomThat]); end; Just saying, I haven't looked too deep into this, its also fine as-is.

TL;DR; You should consider to separate the combined unit into separate designtime and runtime units. procedure Register; begin RegisterComponents('My Delphi Tools', [TMyCustomCalendar]); end;

Yes, that is strange. I never tried to get a runtime permission for a "normal" permission, but I had expected that the IsPermissionGrant would also work in same way. Since it is not explicitely forbidden anywhere in the docs, at least I find no rule for that, maybe the best place to logically derive this from is here: https://source.android.com/docs/core/permissions/runtime_perms?hl=en It states more or less, that the runtime expressios are intended for >= dangerous permissions, from this we could logically deduct that "normal" permissions doesn't need (or better doesn't allow) such requests. Negative logic is sometimes confusing ...

Aaaah, I see. Its a new business model, using AI for writing poor code, that students will have to correct in their exams. Thats how AI can be perfectly used, you will be incredible rich soon

You could ask me too, thats cheaper

I do ( 3rd from left )

Isn't that a little discriminatory towards other pets? Write a haiku about cats and dogs Whiskers meet wet nose, Silent grace and joyful bark, Peace beneath the sun.

I'm afraid a "move" from older to newer is not possible, but I also would always recommend a new, fresh VM anyway, even if it would be possible, to ensure the always best performance on a new platform. Since the setup of such new machines always may take up to one week, until a setup is fully configured on all platforms, I usually proceed a strict checklist for that. There is a 2 year old post from Germany, about running Delphi on Apple Silicon, maybe that's helpful too ( should be able to be auto-translated ). https://www.youtube.com/watch?v=vc2mLROXWcQ

Yes, that is true, but a reasonable timeframe and roadmap should be there. I would like to see full support for such mission critical topics, either from Embarcadero or other from companies. Now the whole risk is laying on the single developers shoulders, to find a reasonable solution, which will maybe result in many different problematic solutions out there. Our clients have some expectations and we cannot provide solutions to all mobile features right now. I was sure that TMS also had an integrated a solution in their TMS FNC too, but perhaps I was wrong with that, at least they have support for all major external Cloud Payment providers.

Scripts are perhaps not powerful enough or too clumsy to use them easily. Maybe DosCommand is a bridge between both worlds, that works for you and can bring the best of both worlds close together. https://github.com/TurboPack/DOSCommand/blob/master/Demo/Unit4.pas

I wonder why Embarcadero is not offering an easy and stably native payment solution, or at least a valid tutorial howto get there. This unclear technical base and very high risks prevents me from even looking much deeper into this topic. Thats a pity, because the Payment is an essential feature in mobile, same as location, sensor access and web access, IMHO. Perhaps the TMS FNC solutions are a more stable alternative, but I have not looked into this either. https://blogs.embarcadero.com/create-native-and-secure-ios-wallet-enabled-apps-with-delphi-and-c-builder/ I'm afraid the preferred way will be to use external providers, such as Stripe or PayPal, to make things easier. https://blogs.embarcadero.com/rapidly-deploy-blazing-fast-payment-solutions-on-windows/ I hope one day there will be a rock-solid, tested and approved solution for GooglePay and ApplePay anywhere, not just "proof-of-concepts".

I'm not on Azure subscription, but according to this article I can see 9.99USD / month. https://melatonin.dev/blog/code-signing-on-windows-with-azure-trusted-signing/ That would be not completely bad, since also Apples developer fee is 99 USD / year, so its playing in the same league, Or did I miss any other "Azure fees" adding up costs here? Generally I would say this is an acceptable price for such service, similar like Apple's 99 USD / year which is at an reasonable rate, offering even more than just code signing. Considering that if I estimate "codesigning only" from all those Apple services, I maybe get down to 25 USD / year as the "real" price for such service, don't you think? Exactly, all those "money-makers" from CodeSigning miss the main point: ! CodeSigning's purpose is to reduce the (virus-) danger of unsigned, untested apps and tools in the wilderness. If Microsoft and others would really care about, they would deliver codesigning services at <= 25 USD / year, so that also every hobby-programmer would choose that. With certificate cost at >= 500,00 USD you only prevent many formerly codesigned, free open-source apps from prolonging. All that considered, it should be in Microsofts core interest, to offer a reasonable or even free CodeSigning service, just to accelerate their Windows platform reputation, IMHO. Similar like Apple does.

I would say no, this seems to be SSL ceretificates, which are free from LetsEncrypt, but no proper CodeSigning certificates, IMHO. Please proove me wrong

https://blog.grijjy.com/2020/10/07/an-xml-dom-with-just-8-bytes-per-node/

Nice idea. I understand this is for your personal phone, that will be fine, but if this is for the AppStore and the apps whole purpose is like this, then I'm afraid the reviewer will have a few questions ...