Chris Pim

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.

It works well. I've managed to build and run my VCL and FMX projects on Android, iOS, Windows and Mac without any problems. Note that both Windows ARM and the way it runs Delphi are still in preview so tread carefully! I can debug Windows and Android no problem. I'm having issues debugging iOS as it's stopping in the IDE but showing the CPU rather than code views. I believe this might be a badly built component I need to re-install rather than an issue with the environment but can't confirm either way at the moment.

UPDATE: I can confirm that Delphi 10.4.2 installs, builds and runs on a Mac M1 with a Parallels Desktop VM of WIndows 10 ARM (insider build). I successfully installed all my components (TMS, JVE, custom), build and ran both VCL (win32) and FMX (win32, MacOS64, Android32/64 and iOS64) perfectly. I'm going to keep using it for a while but if all goes well, this is a great solution and so much faster than my older Intel Macbook

That was exactly the point of my question! As it happens, I've decided just to try it myself so I'll post the end results here as soon as I have them.

Hi all, I've been trying to integrate Facebook Audience Network into my Firemonkey app for ads and I'm getting a very strange error when linking for iOS. I use the "fake loader" approach to linking the framework. const libFBSDKCoreKitBasics = 'FBSDKCoreKit-Basics.framework/FBSDKCoreKitBasics'; //required as it's a dependency for the FBAN library libFBAudienceNetwork = 'FBAudienceNetwork-5.2.0.framework/FBAudienceNetwork'; function LibFBCoreKitBasics: Pointer; cdecl; external libFBSDKCoreKitBasics name 'OBJC_CLASS_$_FBSDKURLSessionTask'; function LibFBAN: Pointer; cdecl; external libFBAudienceNetwork name 'OBJC_CLASS_$_FBNativeAdView'; The error when I try to link, is this: ld: file is universal (4 slices) but does not contain a(n) arm64 slice: ..\Libraries\FBAudienceNetwork-5.2.0.framework/FBAudienceNetwork for architecture arm64 I've Googled and the only reference to this kind of error is related to armv7 when trying to link frameworks into a 64bit app that only contain 32bit versions. So I try building a 32bit version of my app in Delphi and see: ld: file is universal (4 slices) but does not contain a(n) armv7 slice: ..\Libraries\FBAudienceNetwork-5.2.0.framework/FBAudienceNetwork for architecture armv7 Which doesn't make any sense! It looks like the FBAudienceNetwork framework is essentially empty with neither 32 or 64bit code which can't be true as it's 1.7Mb and fresh from the official download page. I've tried different versions of the framework but get the same error each time so I've ruled out a corrupted download. I've tried linking through the "Linker Options" in the project settings instead but get the same errors. Linking the FBSDKCoreKit libraries works using the same approach. Does anyone have any ideas or know why I'm getting this error? Thanks in advance!