Jump to content

Chris Pim

Members
  • Content Count

    59
  • Joined

  • Last visited

Posts posted by Chris Pim


  1. 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.

    • Like 1
    • Thanks 1

  2. 12 hours ago, Dave Nottage said:

    No official fix as yet, however I have come up with the following workaround - Note: this has had no testing beyond a blank app:

     

    1. Copy FMX.Platform.iOS from source\fmx into your project folder.

     

    2. In the TApplicationDelegate.applicationDidFinishLaunchingWithOptions method towards the end, make the following change (i.e. add the one line of code indicated😞

    
        // Creating window
        WindowManager := PlatformCocoaTouch.WindowManager;
        WindowManager.Window := TFMXWindow.Create(MainScreen.bounds);
        WindowManager.RootViewController := TFMXViewController.Create;
        // *** iOS17 SDK crash issue - Add the following line: ***
        WindowManager.RootViewController.Super.init;
        WindowManager.NativeWindow.makeKeyAndVisible;

    Note also that this measure is needed only if you are building against the iOS 17 SDK - it is not required when building against earlier SDKs.

    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!

    • Like 3

  3. 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!


  4. 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!

     

    IMG_11.2.thumb.PNG.d539e0f3a6dcf22dd3e9cb57251c0c90.PNGIMG_11.3.thumb.PNG.5b47843308d251319e8c7e461d68acb3.PNG


  5. 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.


  6. 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!


  7. 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;
    • Like 3

  8. 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.


  9. 17 hours ago, Rollo62 said:

    Not looked into ios17 yet, but usually crashes were caused by changed permission stuff.

    Have you checked which parts have changed, is there already the documentation available ?

    Maybe looking into the changed parts might give a clue. 

    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.


  10. On 7/4/2023 at 2:13 PM, Lajos Juhász said:

    Your report has a status Open. It's not rejected (yet).

    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.


  11. 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


  12. 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)

  13. 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


  14. 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.


  15. 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.

    • Like 1

  16. 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.

×