Chris Pim

Hi everyone Does anyone know if it's possible to force the time picker of TTimeEdit to be 12 or 24 hours? I mean the actual picker in iOS itself, not the editor box (which you can manipulate using the "Format" property). By default, the picker matches the time format set in the phone settings, but I have a separate time format setting in my app which determines whether we show am/pm or 24 hour format in the app and I'm trying to make the experience consistent for my users. Thanks

I've just put your code into practice and it seems to work very well. Thanks again Dave. The only oddity I noticed, is that if the phone (Android) is set to 24 hour format, and I use the above to show my picker in 12 hour format, the AM/PM toggle doesn't appear in the picker dialog, even though the dialog is in 12 hours format. If the phone is set to 12 hour before showing the dialog, then it does show the AM/PM toggle correctly. Weird! I suspect this is a bug in Android as there aren't any APIs to directly impact the AM/PM option so just noting here in case anyone else needs this functionality. Thanks again Dave

Thanks Dave! As always you come up with the best solutions!

That’s an interesting solution! Thanks Dave, I’ll give that a go for iOS. For Android, the time picker native component supports a Boolean for the time format so I just need to check how I can get access without hacking the sources.

Fair enough! I was searching for “application run parameters” and other more general things - I should’ve just searched for cleaninstall! Curiously, if you type cleaninstall into the search box in the docwiki, it initially says “Nothing matches the search” until you actually press return, which also caught me out. That’s my excuse anyway 😂

Oh this is cool. I didn’t realise there were built-in command line parameters. Is there a docwiki page with all these documented? I searched but couldn’t find one

Fair enough. I did say it wasn't tested 😉 Thanks for the feedback though. I may have enough run through this when I have time and see if I can provide a better workaround, but won't be until next week. I'll post here if I come up with anything that works.

I believe the following should do what you need, but I've been unable to test this at the moment so can you please try and let me know if it works. Note: I've checked and it's only the Android version of the iAP components that cache the purchases, so the iOS version shouldn't be affected. FMX.InAppPurchase.Android.pas: 1. In TInventory, add: procedure ClearPurchases; And the implementation: procedure TInventory.ClearPurchases; begin FPurchaseMap.Clear; end; 2. In TAndroidInAppPurchaseService.QueryProducts, replace: procedure TAndroidInAppPurchaseService.QueryProducts(const ProductIDs: TStrings); begin FInventory.ClearPurchases; FProductDetailsResponseListener.QueryProducts(TProductKind.InApp, ProductIds.ToStringArray); end; 3. The component won't automatically re-query the products when a purchase changes (the billing API doesn't have this facility as far as I can tell) so you'll need to call iAP.QueryProducts() with your productIDs whenever you feel you need to, and it *should* now reflect the correct purchase status once it returns. Please try this and reply if it works. If so, I'll copy this into the QP ticket for Embarcadero's info.

Thanks for reporting this. I’ll take a look at the Delphi sources and see if I can find the bug to offer a workaround.

I understand your frustrations. As the author of that article I really shouldn’t have had to write it at all as they should’ve implemented subscriptions by now. They haven’t changed that code for at least 5 years and so basically abandoned within their own code base at the is point. I aim to update the article for the latest Android subscriptions (there are a few small changes you can make to support multiple base subscriptions). I hope that helps once I have. I hadn’t noticed the caching issue but suspect you’re correct. It’s worth checking the Delphi code first as that’s the easiest fix if so. It’s recommended that you use server side callbacks from the stores to capture subscription changes directly from Apple and Google and store them in a server of your own. That’s what I do as you can’t easily get the subscription expiry details from Google or Apple using their APIs. The only way is to decode the receipt file on Apple (which is difficult) or use their receipt validation APIs (which they’ve now deprecated). For Google you use their developer API to get details about the purchase but it’s only valid for 60 days then won’t return anything. I agree that this side of the Delphi mobile support is pretty poor and it would be better if a third party picked this up and released supported modern components for iAP instead, who knows, maybe someone will as we have a great community here.

I’ve noticed a weird bug in all Delphi versions since 12.0 when building an iOS app against SDK 18 (running on an iOS 18 device). If you have a TMemo set to ControlType=Platform, it can’t be scrolled! We’ve just updated our app for D12.2 built against SDK 18.2 and had users complaining. If we build against SDK 17 (as our app used to be) it scrolls fine. Unfortunately, Apple are mandating all apps must be built against SDK 18 from 24th April so we need to find a solution. Ive checked Delphi 12.3 and it’s still broken in there too. The memo has to use platform control type to support Arabic users and their existing notes data (R2L isn’t supported in the styled memo). I’ve logged a QP issue for this but wonder if anyone could suggest any other workarounds or options? We need a fix pretty quickly! https://embt.atlassian.net/servicedesk/customer/portal/1/RSS-3318 Thanks

Thanks Dave. Interesting to figure out what's conflicting on this...

That’s an interesting solution, thanks! By default a Delphi app will apply the font scale from the phone to text set to size 12, but not others, which is a shame.

This is a known bug in Delphi 12.2 and above. It’s caused by the new iOS linker and has been logged with EMB. It’s caused by increasing the min iOS version from 11 to 13 or higher. This breaks the linker and doesn’t matter what other dependencies you have in the app. A blank app will also fail to link. I’ve been seriously impacted by this too and have been assured they’ll be fixing in the next update (12.4? 13? Who knows). For now, the only workaround I found is to either keep the min iOS version as 11, or if you have a copy of Delphi 12.1 Pro or above you can copy the ld.exe file from the bin folder of the installation to replace the one in the version you’re using. I.e. downgrade the linker to a version that works. If you’re using community or don’t have an older version of Delphi, this obviously won’t help. I hope that helps.

We've had a few of our users on Samsung devices report that when typing into a TMemo control in our FMX app, after a random number of characters, the keyboard switches caps lock on and it can't be turned off again. The app is using Delphi 12.1 (latest patch) and Skia. We can't reproduce this issue on any of our test Samsung devices but seems to be happening on a range of Android versions and Samsung devices from A12, 13 and 14. There's nothing logged in the Logcat on those devices nor errors raised within the app. Has anyone else seen this behaviour? I'm trying to put a case together to report it to EMB but need something they can work from. Thanks in advance

Looks very serious. Can you please log it with Embarcadero in their quality portal so they can start investigating? We might get a quick patch from them with any luck. https://embt.atlassian.net/servicedesk/customer/portals

Hi everyone, We've started to receive bug reports from our users that the app crashes on start under iOS 17 beta 1. I've tried a new, empty Firemonkey app and it crashes too. I've reported it to Embarcadero to look into - so far no response. In the past, their response has always been that they don't support beta OS updates so won't provide fixes, but that means we don't get a fix under after September and even then, it's unlikely to be a patch for Delphi 11.3. I've tried to find the cause in the Delphi sources in a failed attempt to patch it up myself. If anyone has any suggestions, I would really appreciate it. I'm expecting a flood of critical bug reports once iOS 17 Public Beta is released in the next few weeks so really want to find a solution ASAP as it's a show-stopper and will badly impact us if left unfixed for too long. https://quality.embarcadero.com/browse/RSP-41853

I've been using Markdown in my other non-Delphi projects as a way to provide formatted docs in my apps. E.g. T&C documents, in-line help content etc. Seems like this is pretty standard in other platforms (Flutter, Swift, C# etc) I've tried a few alternative approaches such as using the web browser (too heavy-weight for in-line content), TDzHTMLLabel (excellent but HTML based an doesn't handle images well. Also not great for longer content as it's just a formatted label control). I found the HTML Component Library but it's very expensive for the small part of it that I need. I found an open source project to convert markdown to HTML which is an option I'm looking into but still falls back onto another component to actually display the content. Embarcadero referred to Markdown support in Delphi 12 but from what I can see it's only for use in the IDE itself, not in your own apps. It just feels like I'm missing something here. Does anyone know of a good solution I haven't found? Maybe it's just a great opportunity for someone to create one!

Thanks Kryvich, very helpful. I'll take a look through those.

We've almost completed our app transition from 11.2 to 11.3 but have one remaining strange issue. We include a Today Extension widget with our iOS app, which works perfectly with Delphi 11.2. When I take the exact same code (fresh clone from Github) and run it from Delphi 11.3, the extension no longer works (I explain what this means below). I created a simple test app to reproduce the issue, which is what this post refers to but it's the same for our main app on the App Store too. I run 11.2 and 11.3 in separate VMs but both are running the same versions of Windows 11, same component versions etc. The test app doesn't use any third party components. All latest patches for 11.2 and 11.3 applied to the IDEs. All generated files (e.g. generated entitlements file) identical on both 11.2 and 11.3 Provisioning profile used to build the app is identical across 11.2 and 11.3. SDK Manager in the IDE imports iPhoneOS 16.4 on both. I created a new test app to produce a simplified version of the setup and reproduce the problem. The app is an FMX Delphi app.It pushes an integer via NSUserDefaults to the widget. The widget reads the same value (using app groups) and displays that number. The Delphi app also reads back the same key on load to display the last value to test the app is reading to the correct key (which it is). On the 11.2 build it works correctly as shown below. On 11.3, the Delphi app is writing to the NSUserDefault key correctly but the widget always shows 0. From debugging the widget, I've seen that it can access the NSUserDefault key no problem but it's always reading 0 when deployed with 11.3 - as though the app didn't write any values (which I've proven it has). My thoughts are that this is an issue with how Delphi is building the app differently in 11.3. I wonder if it's injecting something into the entitlements or changing a permission somehow between generating the files in the Debug folder and deploying to the bundle to the phone. Or maybe I'm missing something obvious. For those who are interested, the Today Extension was created with Xcode natively in Objective-C. The built files are then copied into the Delphi project and set to deploy into the ./PlugIns/<extension name> folder in the bundle. Both the extension and the app bundle ID need to have the same App Group associated with them in the Apple Developer portal, so they can both share data through NSUserDefaults, which is how the widget is passed data. Our app has included this for years and worked perfectly until Delphi 11.3 which is why I doubt it's anything we're doing at code level (or in the widget) that's caused this. We've run out of things to try, so wonder if anyone has any suggestions? I'm going to log this with Embarcadero as a bug, but suspect they have bigger things to look into than something this specific outside their normal use-cases. This is why I'm reaching out to the community for ideas 🙂 . Thank you!

Hi Stanislav Did you find out what was causing this issue? We had the same problem recently after upgrading our project to Delphi 12. When running on devices (particularly older than Android 14) it crashed with the same Resource not found for drawable/splash_image_def. In our case, the problem was the colors.xml file not containing an entry for: <color name="splash_background">#FFFFFF</color> We replace the standard colors.xml file in our project deployment with a custom one to support a custom Android widget library. Our xml file was from D11.3, but from D12 it now needs to include the extra color entry for splash_background. I hope this helps if you're still having problems. Chris

The only solution we came up with for this was: 1. Copy the fully signed extension from XCode into the Delphi project (in our case deployed to the PlugIns folder). 2. Do a full build and deploy with Delphi (which damages the appex by re-signing with the wrong entitlements file) 3. Manually run a script which copies the original binary of the appex over the top of the one Delphi re-signs in the .app generated in the scratch-dir so it’s correct again. 4. The script then also has to re-run the iosinstall command to deploy the fixed app to the device. To help with step 3, I have the original binary from inside the .appex included in the deployment twice. Once into the PlugIns folder as expected and a second to ../ which puts a copy into the scratch-dir folder. By doing this, my script for stage 3 knows where to get the original file from and it’s always the pre-broken version. This works fine but has the manual step at the end which is a pain. Delphi doesn’t have a post-deploy stage in the project build options (like it does for post-build) which is a shame as the “copy-back” step could just be included there if it did. With any luck, EMB will undo the “fix” that broke this in 11.3 so it isn’t needed anymore. Maybe we should all vote for the issue to push it up their priority list.

I've tested this fix on a more complex app too and it also stops the crashing issue on iOS 17, so thank you as always Dave!

Delphi 11.x doesn't support building to an iOS 17 device from the IDE but apps built against iOS 17, which are deployed to the device via TestFlight seem to run ok from my testing. iOS 17 development is problematic with Delphi 11.x (full or CE) so you may need to wait for the next version to get full support, but your users shouldn't be having problems from what I've seen so far if you build against iOS 16.4 SDK and run on iOS 17 UPDATE: Scratch this - TestFlight builds also crash when built with iOS 17. I'm not sure why it appeared to work but I may have been testing an iOS 16 SDK build accidentally. You need Dave Nottage's fix regardless, but I'm doing a lot more thorough testing to make sure it doesn't have unexpected consequences!

They appear to be auto released which his why releasing again manually causes the crash.