Chris Pim

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!

I honestly don't know. To be honest, I didn't spend enough time on it to figure out whether it was a fundamental problem with having the framework embedded, just the way I was implementing it, or maybe I signed the framework incorrectly. My app uses iOS widgets too so I have to re-sign after Delphi has built it to apply the extra provisioning profiles which made things a lot more complicated and could have contributed to the errors I received. If I get time, I'll create a simple app which uses his components and try to upload again so I can try with something simpler and see if the same errors appear.

Just to confirm, you don’t need most of the frameworks mentioned in the JVE Manual. It assumes you’re going to be installing all their components from the suite which require different dependencies. For FBAN and Abmob I think you only need some of them but I couldn’t easily tell you which ones.

If you purchase the JVE ad component you get the sources so I suggest doing that if you’d like to see how Yegor has done it. It’s probably a fair thing to do if he’s put all the effort into figuring it out. But I can confirm that he is loading the framework at runtime but not in the way David says as that also fails to link. He’s loading the framework file directly from the bundle and invoking the initialiser at runtime. This means that the framework has to be deployed with your app and signed separately with the same provisioning profiles before it’s included as per his instructions. It works locally but when I tried to upload a sample app to TestFlight it raises errors from the App Store because you’re embedding a third party binary and the store isn’t a fab of doing this. I’m sure it’s all solvable but I haven’t had any time to look into it as I had to abandon Audience Network for now. hope this helps

I’ve not tried it yet but there’s an article in Chinese here which takes you through how to do it. https://translate.googleusercontent.com/translate_c?depth=1&nv=1&pto=aue&rurl=translate.google.co.uk&sl=zh-CN&sp=nmt4&tl=en&u=https://blog.csdn.net/delphiteacher/article/details/104344285&usg=ALkJrhizIuLwrZCrBE-qSZ-hlKqRfCeYKQ If you manage to get it working, it would be great if you could share your findings with the group! I think David Nottage was also looking into this but not sure if he got anywhere with it yet.

There are a number of reports of this on QP. Delphi 10.3.3 doesn’t support Android 10 (targeted with SDK 29) but Delphi 10.4 seems to work. I also hope someone finds a workaround for 10.3.3 before the Google deadline, as 10.4 isn’t an option for us until it’s been made more stable.

Hi all, This morning while debugging my FMX app in Windows I suddenly started getting an EOleException within the Notification Center while initialising. onecoreuap\base\diagnosis\platform\notifications\developer\toast.cpp(2389)\wpnapps.dll!63CC11A2: (caller: 63CB5660) ReturnHr(1) tid(14e0) 803E0105 The notification platform is unavailable. First chance exception at $776F9862. Exception class EOleException with message 'The notification platform is unavailable' I've never seen this before, but it may be related to my Windows setup having updated over the weekend to v2004 (19041.388). It looks suspiciously like MS have changed the way their notification APIs work in this update... Has anyone seen this before or know of a way to resolve it? There's nothing useful on Google about this error that I could find. Thanks

I’ve found a link to how to add a storyboard to a Delphi 10.3 project here: https://quality.embarcadero.com/plugins/servlet/mobile#issue/RSP-12931 Take a look at the 4th response from Sarina DuPont

I doubt you’ll be able to use storyboards in 10.3.3 projects but I would be very interested to hear if anyone has found a workaround. In terms of Apple, they won’t remove your app if it’s already approved, they just won’t let you upload new updates or new apps after the deadline. i suggest you report any and all issues you’re having with 10.4 to Embarcadero via the quality portal as they seem to be working quickly to review new bug reports and release patches so that’s the best way to move forwards.

I wonder if anyone else has seen problems with UI scaling on MacOS apps? I created a testing tool in Delphi 10.3.3 for Mac OS and it looks great on 10.15 (Catalina). My MacOS SDK in Delphi is 10.15.3. I passed the binary to a colleague running MacOS 10.13 to run, and although the window size was the same, the contents rendered 4 x larger and the app became unusable. After some trial and error I realised the problem was the NSHighResolutionCapable which was set to true. I changed this to false and it runs fine on both Macs ok. The only remaining oddity is that it renders the titlebar twice - the correct one and then a secondary one with the app name directly below it. I've searched Embarcadero's quality portal for any reference to this but can't find any. Has anyone else had this problem before? I'm happy to log it with them if it looks like a bug. I'm not even sure what having NSHighResolutionCapable = true does besides cause problems, so wonder if I'd be better keeping it turned off?

Thanks guys that’s really helpful. I was searching for the NSHighResolutionCapable flag so no wonder I didn’t find that article! I’ll give it a try.