Jump to content

Recommended Posts

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

Edited by Chris Pim

Share this post


Link to post

Well, usually a new iOS version strangely precedes a new Delphi release. I would not count on anything other than the beta of said release to maybe fix that issue beforehand.

Share this post


Link to post

And customers can't open any kind of ticket when using a beta OS. They're on their own.
Why should you waste time supporting them when they don't operate in the conditions/requierements fixed by your software.
Why should you waste time adjusting your software to a beta OS that will dramatically change over the coming months? If you fix the crash, then maybe, in the next iOS beta release, it will come back because Apple changed something on their side?

Share this post


Link to post

iOS betas hardly change dramatically over the time. By the way, final release is in like 8 weeks. Having a development tool that is now unable to produce working executables, that is worrying, and not wasted time.

  • Like 1

Share this post


Link to post

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. 

Share this post


Link to post
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.

Share this post


Link to post
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.

Share this post


Link to post

Just out of curiosity: What kind of software are you developing and what kind of customers do you have, that causes them to check if your software runs on a more or less early beta of iOS? Most customers I know of, don't care about the installed iOS version and aren't even aware of impending new ones.

Share this post


Link to post
3 hours ago, Chris Pim said:

.. it may be related to StoreKit ...

That sounds a very likely candidate, have you tried to isolate the StoreKit parts in your app and tried to run without it ?

Does it still crash ?

Share this post


Link to post

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.

Share this post


Link to post

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

Share this post


Link to post
On 7/7/2023 at 10:38 AM, Chris Pim said:

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;

But ProductIDsArray is an object, it doesn't need to free memory?

Share this post


Link to post

Hi all.

After updating to ios17, the app closes at startup.

I have Delphi 11.3 Version 28.0.47991.2819 installed.

Updated XCode, installed SDK 17.0

I'm creating a simple "Hello world" application. When opened on iPhone, the program closes.

I changed the FMX.inAppPurchase.iOS.pas file on the advice of Chris Pim, but nothing helped.

Has anyone encountered this problem and how to solve it.

Thank you in advance!

Share this post


Link to post
2 hours ago, avesuvorov said:

I'm creating a simple "Hello world" application. When opened on iPhone, the program closes.

I changed the FMX.inAppPurchase.iOS.pas file on the advice of Chris Pim, but nothing helped

If it's just a simple "Hello world", you will not need to modify FMX.inAppPurchase.iOS, since it won't be using it. 

 

Does this happen if you start a completely blank project, and run that?

Share this post


Link to post
2 hours ago, Sherlock said:

Have you tried running your App in the simulator?

Just tried it.

I get error: Underlying error (domain=IXUserPresentableErrorDomain, code=4):

“test_ios17” Needs to Be Updated

This app needs to be updated by the developer to work on this version of iOS.

 

But I don't understand what I need to update?

For reference: I have a MacBook with an intel i5 processor.

Delphi has Target Platforms installed: iOS Simulator ARM 64b - iPhone 15 Pro (iOS 17.0)

 

 

 

2 hours ago, Dave Nottage said:

If it's just a simple "Hello world", you will not need to modify FMX.inAppPurchase.iOS, since it won't be using it. 

 

Does this happen if you start a completely blank project, and run that?

Created a new application - blank project
The application is installed on the iPhone.
I launch it and it closes immediately.

 

Edited by avesuvorov

Share this post


Link to post
57 minutes ago, avesuvorov said:

For reference: I have a MacBook with an intel i5 processor.

Sorry, but that wont do to run the simulator. It is ARM only - meaning you'll need Apple Silicone to run it.

  • Like 1

Share this post


Link to post
5 hours ago, avesuvorov said:

I launch it and it closes immediately.

What happens if you run it via the debugger?

Share this post


Link to post
36 minutes ago, Dave Nottage said:

What happens if you run it via the debugger?

Never mind - it seems debugging from Delphi is not possible for iOS 17 devices at the moment. I confirm that apps built against iOS 17 SDK crash on start. For now, you'll need to use an older SDK (e.g. iOS 16.4 SDK), if you had imported that earlier.

  • Like 1

Share this post


Link to post
14 hours ago, Dave Nottage said:

Never mind - it seems debugging from Delphi is not possible for iOS 17 devices at the moment. I confirm that apps built against iOS 17 SDK crash on start. For now, you'll need to use an older SDK (e.g. iOS 16.4 SDK), if you had imported that earlier.

After installing iOS 17 SDK, I uninstalled iOS 16.4 SDK. Is there any way to return it?

Share this post


Link to post
On 7/7/2023 at 10:38 AM, Chris Pim said:

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.

It's strange that we have not had any reports from iOS 17 users, and our own tests on iOS 17 also runs fine. Our analytics tells us that 400 unique users have started our software on iOS 17 until yesterday.

We use in-app purchases too and those two .release lines are still active in our copy of FMX.inAppPurchase.iOS.pas.

We have other modifications of the file though, so maybe it makes a difference just by compiling it your self?

Share this post


Link to post
39 minutes ago, Hans♫ said:

t's strange that we have not had any reports from iOS 17 users, and our own tests on iOS 17 also runs fine.

The In-App purchase issue might have been occurring only on earlier betas. Chris has extreme users 😉

 

  • Like 1

Share this post


Link to post

Has this issue been resolved? (Delphi app crashing on iOS 17)

 

I have installed the latest version of the CE edition installed:

Delphi and C++ Builder 11 Update 3
Delphi CE 11 Patch

 

Using XCode 15

 

App runs fine on simulator.  Will build and transfer to iPhone 14 Pro with iOS 17 installed, but when the application is launched the launch screen briefly appears and then the app terminates.  I was able to compile and deploy to an iPhone 11 with iOS 16.7 without any issue.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×