Unable to upload an app with ExtensionFoundation

The Info.plist in my Extension is:

Is that the actual value? Or did you substitute this line in:

<string>com.example.example-extension</string>

I've tried tracking your build down on the App Review side but there have been a number so submission and it looks like they've all been approved, so I'm not sure where to find the build that's being rejected.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Thank you for your answer.

I tried with both "AsheKube.app.a-Shell.localWebServer" and "com.example.example-extension".

The only difference I could see is that sometimes it would fail when uploading (I would get the error message inside Xcode) and other time it would fail after uploading: I would get a kind e-mail from AppStore Connect, stating:

Hello,

We noticed one or more issues with a recent delivery for the following app:

a-Shell App Apple ID 1473805438 Version 1.17.0 Build 500 Please correct the following issues and upload a new binary to App Store Connect.

ITMS-90349: Invalid Info.plist value - The value of the EXExtensionPointIdentifier key, AsheKube.app.a-Shell.localWebServer, in the Info.plist of “a-Shell.app/Extensions/localWebServer.appex” is invalid. Please refer to the App Extension Programming Guide at https://developer.apple.com/library/content/documentation/General/Conceptual/ExtensibilityPG/Action.html#/apple_ref/doc/uid/TP40014214-CH13-SW1.

Apple Developer Relations

Builds 496, 497 and 500 are builds that I managed to upload, but were not approved. Builds 501 and 502 are approved because I gave up, removed all extension code from the app and moved on to other features (and apparently builds 498 and 499 are builds that I could not upload, where it failed inside Xcode).

Thank you for your answer.

So, having talked to App Review about this, the basic answer I have currently is that we don't currently support 3rd-party App Extensions on the iOS App Store. The framework itself is built to work across all of our platforms and is "public" (which is why new functionality is added that's available on iOS), however, the App Store policy has not changed.

If you haven't already, I'd appreciate you filing a bug on this and then posting the bug number back here. It sounds like you're trying to create extensions that are specifically for "your" apps’ usage, and that's a distinct use case that we need to more actively consider.

Clarifying a few details, I think the difference here is basically a "quirk" caused by slightly different handling paths:

The only difference I could see is that sometimes it would fail when uploading (I would get the error message inside Xcode) and other times it would fail after uploading: I would get a kind e-mail from AppStore Connect, stating:

For many years, the app store has had "block" in place that prevents specific bundle ID prefixes from being used in any "new" application. The block was added because many developers were carelessly submitting apps based on our app templates, which meant that "com.yourcompany." was one of the more common bundle ID prefixes. Existing bundle IDs were left alone, but the portal blocked any "new" bundle IDs from being used.

I believe that's what triggers this path:

sometimes it would fail when uploading (I would get the error message inside Xcode)

...as "com.example.example-extension" I think is any of the blocked ID, since it's the value Xcode uses in its template. The rejection happens so early* because the system is doing a very simple check against known "wrong" values.

*It's even possible the check actually happened in the local validator.

The later failure here:

other times it would fail after uploading: I would get a kind e-mail from AppStore Connect

...happens when the App Store actually processes your app "in detail", at which point the store determines that "AsheKube.app.a-Shell.localWebServer" isn't on our list of known bundle IDs. That then triggers the rejection you get.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Thank you very much for this detailed answer; that explains a lot of things.

Yes, my goal is to run iOS extensions that are specifically for my app's usage, not shared with any other app.

I've submitted FB20710338

I've submitted FB20710338

That's great, thank you. I've looked at the bug over and, if you have a minute, the one thing I would love to have you add is a bit more detail about why/what you're actually trying to use this "for".

With an issue like yours, the bug is less about the specifics of the technical issue and more about showing how you'd want to use this and the value this would provide to your app. Concrete examples about how developers actually want to use APIs are tremendously helpful when it comes to prioritizing our development work.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Thanks for the recommendation; I've added extra information. Basically my main concern is to isolate unstable code to make the app more stable, but also extensions are running as separate process, which would allow me to add a lot more commands to the terminal app.

I also have potential uses in mind if there is no memory limit, and if we can share extensions between apps, but I think these are hills too large to climb at the moment.