Chris Pim

We've been having a strange issue using the TRESTRequest component with some of our users. When we call the request.execute on those devices, it always raises an exception with the message of "External Exception 0". Weirdly it only seems to happen on Samsung devices, particularly newer models such as the S22 Ultra (but not exclusively that device). It happens for every API call we make, but only affects our app. The user reports that all their other apps can talk to the internet fine, so not sure what this could be. We have a number of newer Samsung test devices but can't reproduce this issue. The error seems to be coming from the OS rather than Delphi, but I can't see any reason for it. We've been exploring device config-specific factors such as firewall apps, disabling data access to the app etc but there doesn't seem to be anything special. Most affected users keep their devices as factory default for these settings. I've extract a logcat from those devices (I don't have physical access to the device though), and it doesn't show any errors, warnings or messages related to network access, security or things I would expect if the OS was the cause. We're running out of ideas, and the users are becoming frustrated as they can't use the cloud features of our app. I'd really appreciate any thoughts, suggestions or even just troubleshooting theories that could help to figure this out. Thanks!

The app isn't a monolithic app (it's a large app but written to be modular) so that's not a problem we face. We always write apps properly - glad to head you do too Rollo 😄 It's just the sporadic nature of the exceptions on specific devices we can't figure out. We've had to order a few more Samsung test devices to see if we can reproduce it, as the users are in a different country so no way we could get access to their devices. They respond for a while to help but don't tend to like us sending test apps and debug versions, as we're a relative unknown to them so don't fully trust we won't steal their data or hack their devices I suspect. We'll figure this out I'm sure, but appreciate everyone's help and suggestions. I'll report back once we had a solution just in case anyone else has something similar in future.

Thanks Martifan, those are very helpful. I’m in the middle of working through these so I hope to figure it out soon.

A huge thanks to David Nottage! A fix has been found and I've included below for those that need it. The changes need to be made in FMX.inAppPurchase.iOS.pas (copied into your own project first as usual). I've confirmed that this fixes the crash in iOS 17 and also still works in iOS 16. Not sure why we didn't see the crashes in iOS 16 but may be random luck given the nature of bugs like this. The same fix has been sent to EMB in the Quality Portal to hopefully include in the next update. procedure TiOSInAppPurchaseService.QueryProducts(const ProductIDs: TStrings); var ProductIDsArray: NSMutableArray; ProductIDsSet: NSSet; ProductID: string; begin //Check FProductsRequest isn't already in use if FProductsRequest <> nil then raise EIAPException.Create(SProductsRequestInProgress); ProductIDsArray := TNSMutableArray.Create; for ProductID in ProductIDs do ProductIDsArray.addObject(StringToID(ProductID)); // changed from the very poorly named PStrToNSStr to StringToID ProductIDsSet := TNSSet.Wrap(TNSSet.OCClass.setWithArray(ProductIDsArray)); FProductsRequest := TSKProductsRequest.Wrap(TSKProductsRequest.Alloc.initWithProductIdentifiers(ProductIDsSet)); // ProductIDsArray.release; -- comment these out to fix the issue // ProductIDsSet.release; -- comment these out to fix the issue FProductsRequest.setDelegate(FProductsRequestDelegate.GetObjectID); // calling GetObjectID without the redundant cast //Set off network activity indicator SetNetTrafficIndicator(True); //Now initiate the products request FProductsRequest.start; end;

After more investigation, it looks like it's related to InAppPurchase (StoreKit specifically). Simple apps were crashing under iOS 17 beta 1 but seems to be ok now in beta 2 unless you have TInAppPurchase in your app. This is an improvement but still the same headache for my users unfortunately. I've raised a new QP issue with Embarcadero with all the crash details, logs etc as it feels like a separate issue to the original QP entry. https://quality.embarcadero.com/browse/RSP-41948 Hopefully Apple will fix the underlying issue in a future beta but it's logged just in case it's an Embarcadero issue.

Thanks for the suggestion, it's the first thing I tried. Their docs don't contain much of use but looking into the crash logs it looks like it may be related to StoreKit but not sure why that would be an issue for a new Firemonkey app. The challenge is that Apple haven't released the DeviceSupport binaries for iOS 17 which Delphi requires to run on the device, so the only way to reproduce the crashes is to build as release, deploy to TestFlight and use the crash logging in Xcode and TF to guess. Quite painful and slow.

It's never rejected unless they can't reproduce. My post was that they won't reject but also won't provide a fix until September which is too late for my users. It may be all well and good to stick to the hard line of "well, you shouldn't be using pre-release iOS versions" with my users, but it's VERY bad practice if I want to keep them as users and very bad customer service. At the moment, they're ok about it as they understand the iOS beta is very early, so we can blame it on an Apple bug, but once it becomes a public beta, more users will pick it up and it will be a customer service headache for us. This is why I'd like to try and find a fix asap - or at least a workaround.

Hello all, We've just deployed an update to our FMX app on the Play Store, but we're seeing a worrying number of ANRs reported in the Play Store vitals area. We've changed a lot in this latest update including much heavier use of styles from style books. We also can't reproduce the ANRs on any of our 10 Android test devices as it's only impacting < 1% of our user case (around 600 instances from 200,000 installs). I have a clear call stack (below) which is showing that the ANR is a block on a monitor when trying to apply the styles to my UI elements, loading the resource specifically. Does anyone have any ideas of how this could theoretically be caused? We do use a lot of threads so my first thing to check was that we weren't trying to update the UI from a thread without Synchronize or Queue but I can't find any case where we aren't. Any suggestions for what I could look for would be very welcome! Thanks Call stack: (System::Sysutils::WaitForSyncWaitObj(void*, unsigned int)+100) (System::Sysutils::WaitOrSignalObj(void*, void*, unsigned int)+96) (System::TMonitor::Enter(unsigned int)+528) (System::Rtti::TPoolToken::TPoolToken()+120) (System::Rtti::EnsurePoolToken(System::DelphiInterface<System::IInterface>*)::DoCreate(void*)+52) (System::Rtti::EnsurePoolToken(System::DelphiInterface<System::IInterface>*)+32) (System::Rtti::TRttiContext::KeepContext()+104) (System::Classes::BeginGlobalLoading()+20) (Fmx::Controls::TStyleContainer::LoadStyleResource(System::Classes::TStream*)+40) (Fmx::Controls::TStyleContainer::CreateStyleResource(System::UnicodeString)+92) (Fmx::Controls::TStyleContainer::FindStyleResource(System::UnicodeString, bool)+36) (Fmx::Controls::TStyledControl::LookupStyleObject(...)::LookupStyleInObject(void*, Fmx::Types::TFmxObject*, System::UnicodeString)+88) (Fmx::Controls::TStyledControl::LookupStyleObject(...)::LookupStyle(void*, Fmx::Types::TFmxObject*)+84) (Fmx::Controls::TStyledControl::LookupStyleObject(...)+336) (Fmx::Controls::TStyledControl::GetStyleObject(bool)+236) (Fmx::Controls::TStyledControl::GetStyleObject()+28) (Fmx::Controls::TStyledControl::ApplyStyleLookup()+124) (Fmx::Controls::Presentation::TPresentedControl::ApplyStyleLookup()+52) (Fmx::Controls::TStyledControl::PrepareForPaint()+32) (Fmx::Controls::TControl::PrepareForPaint()+656) (Fmx::Forms::TCustomForm::PrepareForPaint()+504) (Fmx::Forms::TCustomForm::PaintRects(System::Types::TRectF const*, int)+76) (Fmx::Platform::Ui::Android::TFormRender::Render()+124) (Fmx::Platform::Ui::Android::TAndroidWindowHandle::TSurfaceViewListener::surfaceChanged(...)+56) (System::Rtti::Invoke(void*, System::DynamicArray<System::Rtti::TValue>, System::Typinfo::TCallConv, System::Typinfo::TTypeInfo*, bool, bool)+556) (System::Rtti::TRttiInstanceMethodEx::DispatchInvoke(System::Rtti::TValue const&, System::Rtti::TValue const*, int)+1328) (System::Rtti::TRttiMethod::Invoke(System::TObject*, System::Rtti::TValue const*, int)+84) (Androidapi::Jnibridge::dispatchToNative2(...)+692) at com.embarcadero.rtl.ProxyInterface.dispatchToNative2 (Native method)

Sorry for the delay in responding Dalija, I added the KeepContext and the exception disappeared. Thank you for your help 😁

Thanks Dalija, that's very interesting solution I hadn't considered. I'll implement this and see what happens.

Hi everyone, I’m experimenting with the ability to allow users to change their app icon at runtime in iOS which is officially supported now. I have all the APIs etc to make it work but it requires the alternative icon graphics to be included in the Asset Catalog. The asset catalog is generated by Delphi during build using the Deployment Manager references but I can’t see how to include files in the DM which will be pulled into the Asset Catalog so not sure if it’s possible? Has anyone looked into this or managed to get Delphi to do this for additional images aside from the standard icon files? If not I’ll raise a QP request but wanted to check with the community first. Thanks

No problem, glad I could help and it’s really good to hear it’s now working for you. Good luck with your app!

If you’re getting no errors from the component, then I would check logcat as the Play services may be raising errors which would appear in the device logs. Failing that, I would suggest debugging your app in the IDE and browsing into the iAP sources to see if you can spot where your calls may be being terminated before the Play services are invoked due to something you’ve missed in your setup of the store. It doesn’t sound like you’re doing anything wrong and if it worked in earlier Delphi versions it should be fine, but without seeing your code for how you’re using the iAP component it’s hard to offer more suggestions.

That all looks correct. Are you getting an errors from any of the error callbacks in the iAP component when you QueryProducts?

After running my changes live for a few days, it looks like adding the permission back in has fixed the developer_error issue. I have absolutely no idea why as the official docs say you shouldn't need it. If anyone else has issues with Android billing from Delphi 11, I suggest you leave the legacy Vendor Billing permission turned on and see if it help you too.

I've finally managed to upload my app from D11 (Billing v4) to the Play Store. The manifest includes both the activity and meta-tag entry and I removed the legacy BILLING permission as described above. The app works perfectly when tested locally and through the Alpha and Beta test channels on the Play Store. I can successfully make purchases, restore them etc. I've implemented subscriptions and they work, renew and cancel correctly. However... as soon as the same build is promoted to Production, things go wrong. Every user who tries to make a purchase gets a "Error 5, DEVELOPER_ERROR" response from the PurchasesUpdated listener. These are likely be users new to the app rather than existing users who have upgraded (they usually buy pretty quickly if they're going to). From the logs I've captured, it's showing the purchase pop-up fine (launchBillingFlow returns OK) but when they actually try to buy the product, it shows the DEVELOPER_ERROR described above. I'm still investigating this and will post in here once I've figured it out. Almost all posts about that error in Google say that Error 5 is returned much earlier in most cases (e.g. when querying the inventory or initialising the store) but those return OK for me. They say it usually appears if the parameters passed into the purchase call are wrong (they're correct) or bad signing (it's correct and worked for all previous builds). I found the following which is exactly the same situation as I'm facing: https://issuetracker.google.com/issues/204353360 They solved it by adding the legacy BILLING permission back in, so maybe that's something. I've successfully uploaded a new build to Production with this permission turned on along with the meta-tag and activity, and it was accepted no problem. It will be a few days before the new release is reviewed and enough users get it to capture anything useful, but once I have some news I'll report back. Hopefully that's all it needs otherwise I'm really at a loss over this. If it works I'll add this to the QC report about the missing meta-tag.

I haven’t gotten that far due to the emoji colouring bug but it does sound like it needs fixing anyway so I’d recommend logging in QC.

I’ve just read this, which may be useful for the question: Remove: <uses-permission android:name="com.android.vending.BILLING" />from AndroidManifest.xml in android app folder. Since Nov 1st Google count that as a sign of V2 billing library and does not approve releases.

Ah, thanks Dave - that's really useful to know!

Hi John, I haven't tried uploading a D11 build to the Play Store yet, but when I do I'll let you know what mine says. Dave's suggestion is a good one and will hopefully solve it, but it's also worth mentioning there's a new item in the Entitlements section of the Project Options you need to tick for billing. What this seems to do is add the entry into the manifest for you (the one Dave mentioned, so you won't need to manually add it) but may do some other things you need. Good luck!

Hi John The new Android requirements from November also include a requirement to support SDK 30 (as well as the new billing APIs). To avoid having to upgrade to Delphi 11 just as it was launched (generally a little hit-and-miss) I looked into supporting the new requirements for Delphi 10.4 instead. Unfortunately I hit a brick wall with the SDK 30 update. Too many internal components of Delphi 10.4 don't work properly with SDK 30, so it wasn't feasible. The billing API support was fairly straightforward as it could be bolted into 10.4, but without SDK 30 support it wouldn't be allowed onto the Play Store anyway. Best to upgrade to Delphi 11 - it seems pretty solid and a good upgrade so far.

I’ve been exploring this for my Delphi app which needs to support WidgetKit (iOS 13-style) Home Screen widgets. Getting the widget built and working with my app was easy enough but I’m struggling to force it to update when data changes as the WidgetKit API is swift only. I’ve tried creating a native Obj-C static library which contains the bridging headers to call the swift code, and tried a swift static library with the @objc tags to expose the correct headers but Delphi just won’t see the exposed classes. If I pull the libraries above into native ObjC apps they both work fine but Delphi can’t seem to see the classes exposed, even though they link into the app using the fake loader method. I feel like I’m so tantalisingly close to getting this working so I’ll keep digging and post here if I get it working.

I have the same issue but don't want to have to create a new app as you have done as my project setup is really complex. Last time has to do what you suggest, it took a full day. I wonder if it's an issue with deployment caches etc which need to be reset? My app has been upgraded through 10.1, 10.3 and 10.4 so it's likely to have some residual junk which may be causing problems. Do anyone know how best "reset" all this back to a clean 10.4-style app without losing any of my project settings, deployment configuration etc?

I’ve just had an email from Parallels telling me that their latest update has official support for Windows ARM. From what I’ve read, Windows ARM can run x86 apps in emulation, so I wonder if Delphi 10.4 would run on a Windows 10 ARM VM. Before I spend a day setting this up to try it, I wonder if anyone else has already tried this to see if it works? It’s not for production use at the moment, just curiousity.

An update on the debugging issues on iOS - it's all working now. My VM just needed a restart and I can debug without problems now.