Delphi 11.3 issue with iOS Today Extension widgets

[Chris Pim 32]

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!

 

[Allen@Grijjy 44]

Did you ever figure anything out with this issue?  I am exploring something similar and wondering if I should test an old Delphi version to see if it works.

[Dave Nottage 493]

1 hour ago, Allen@Grijjy said:

Did you ever figure anything out with this issue?

It was reported in https://quality.embarcadero.com/browse/RSP-42283, but there are a couple of other similar reports, e.g. https://quality.embarcadero.com/browse/RSP-42415

 

The problem is that PAServer signs the extension with the wrong entitlements, and in Chris' (and my) case, it's unnecessary because the extension has already been correctly signed, i.e. it does not even need to be touched. Replacing the extension in the .app bundle, and using iosinstall to install the it solves the problem, at least debugging-wise. I expect a similar process will be needed for repackaging the .ipa.

[Allen@Grijjy 44]

1 hour ago, Dave Nottage said:

The problem is that PAServer signs the extension with the wrong entitlements, and in Chris' (and my) case, it's unnecessary because the extension has already been correctly signed, i.e. it does not even need to be touched. Replacing the extension in the .app bundle, and using iosinstall to install the it solves the problem, at least debugging-wise. I expect a similar process will be needed for repackaging the .ipa.

 

Thanks, I have been racking by brain about this.  I wrote an article on how to do it back in 2018 for Grijjy but couldn't get any of it to work with Delphi 12 again.  I tried just about everything so I appreciate the insight!

Edited December 8, 2023 by Allen@Grijjy

[Dave Nottage 493]

3 minutes ago, Allen@Grijjy said:

couldn't get any of it to work with Delphi 12 again

The problem was introduced in 11.3 - a "bug" was reported that I strongly suspect was not even a bug, and "fixing" it actually broke the process. 

7 minutes ago, Allen@Grijjy said:

I tried just about everything so I appreciate the insight.

You can thank @Chris Pim for it - and it's because of him (and your article, thanks!) I'm finally on the track of making customized notifications on iOS work (though as far as user experience goes, it's pretty sucky compare to Android)

[Allen@Grijjy 44]

5 minutes ago, Dave Nottage said:

You can thank @Chris Pim for it

Thanks to Chris then!  I wonder if we could unbundle the package during the pre-link stage and copy over the original .appex over the top of the Delphi ones after Delphi completes it's codesign step and then rebundle it before it's deployed?  I imagine you already tried that though... have to give this some thought.

[Chris Pim 32]

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.